大模型重塑创作流程：从生产者到判断者的工程实践

今天聊一个听起来有点冒犯的话题AI 是否正在把“创作者”这个词从人类词典里删除。艺术家 ZHO 在讨论 AI 与艺术创作的关系时提出了一个更尖锐的判断——“AI 将人类从人类性中开除”。这里的“人类性”不是一个生理概念而是指人类长期默认拥有的一种身份创作者、生产者、决策者。过去我们写一首诗、画一张图、设计一个 App、写一段代码背后都有一个自然的隐含前提——这件事必须由人完成。AI 出现以后这个前提第一次被真正动摇了。我理解这句话不是在否定人而是在提醒我们当机器能生成高质量内容人类在创作流程中的位置就不再是天然的、唯一的、不可替代的。如果你正在使用大模型做内容、编程、设计或开发 AI 产品这个问题不是你该不该关心而是你已经身处其中。这篇文章会把 ZHO 这句话从哲学拉回工程现场从四个角度展开第一AI 如何改变创作主体的位置第二大模型“像人”的技术原理到底是什么第三如何实际搭建一条可运行的 AI 创作流水线第四在这个新流程里人类还能守住哪些不可替代的边界。读完你会得到一个判断框架也能跟着示例跑通一套最小可用的创作工作流。1. 为什么“AI 将人类从人类性中开除”值得认真讨论很多技术讨论有一个通病把 AI 说成“一个更好用的工具”。这个框架本身没有错但它隐藏了一个更关键的变化。传统工具比如画笔、打字机、IDE它们能放大人的能力但不能替代人的意图。没有画家画笔不会自己画画没有程序员编译器不会自己产生业务逻辑。而大模型改变了这一点你给它一句模糊的提示词它能自动完成扩展、生成、组织、呈现的完整过程。在“创意输入”和“成品输出”之间人类干预的颗粒度正在变小。所以 ZHO 说“开除”实际上指的是一个正在发生的事实人类从创作链条的必经节点变成了可选节点。这句话在今天意味着三层含义能力层模型已经能完成过去只有训练有素的人才能完成的工作比如写代码、画插画、写文案、做视频脚本。流程层传统的“人想 → 人做 → 人改”流程正在变成“人想 → 模型做 → 人审”的流程有些环节甚至“人想”都开始由模型辅助。身份层当作品的生产过程不再依赖人类的基本功社会对“创作者”的定义就会松动。人们将更关注结果而不是结果背后的物种。这三层变化不是未来预言而是过去几年已经发生的事实。对普通开发者来说最早感受到的通常是第二层原来要花一整天的编码任务现在交给 AI 只要几分钟。但真正需要警惕的不是“代码写得快不快”而是我们是否仍然清楚这个流程里哪些判断必须由人来做。2. 创作主体的转移从“人使用工具”到“模型即主体”为了说清楚这个变化我们先回到一个基础概念创作主体。在传统创作中“主体”是一个完整的人。一幅画之所以被认为是艺术不仅因为画面好看还因为观众能感知到背后的创作者意图、生活经验、审美判断和偶然性。这就是为什么美术史至今仍然强调“作者”这个身份。AI 生成作品出现后这个链条被打断了。模型不知道自己在创作它只是在做概率计算但它输出的结果却可以被解释为“有意图的作品”。于是我们面对一个尴尬局面作品还在作者不见了。我把这个变化拆成一张表维度传统创作流程AI 参与后的流程变化本质起点人的灵感和意图人的提示词或模型自动推荐意图被压缩成“一句话需求”执行人的技能与长期练习模型的参数与训练数据执行不再是人的核心竞争力修改人根据经验反复调整人调整提示词或参数修改对象从“作品”变成“生成条件”验收人的审美与标准人的审美 自动评估工具判断仍然是人的责任但更容易被绕过真正值得注意的变化是第三行修改对象变了。以前写代码改的是代码以前写文案改的是文字。现在用大模型你改的是提示词、温度、上下文、模型版本。这意味着人类正在从“直接生产内容”退到“设计生成条件”。这个角色的变化比“AI 能画图”本身更值得关注。当模型已经生成大部分内容人的工作就变成了一个更抽象、更高层级的任务定义问题、划定边界、审核结果。ZHO 所说的“开除”并不是说人类从此无事可做而是说人类过去熟悉的“生产者”身份被取消了必须换一种方式参与创作。3. 技术原理为什么 AI 看起来“像人”要判断“AI 将人类从人类性中开除”这个说法有没有道理不能只停留在概念层面我们需要理解大模型到底在做什么。以文本大模型为例它的核心机制可以概括为预测下一个 token。训练时模型读入海量文本学习的是“在一段上下文之后下一个词最可能是什么”。推理时你输入“今天天气”模型会根据学习到的概率分布生成“很好”“不错”“很差”等内容。这个过程看起来很像人因为它输出的语言和人类写出来的语言高度相似。但这和人类写作有本质区别人类写作有真实世界体验作为支撑模型没有。人类写作有稳定的自我意识和立场模型没有。人类写作受制于物理时间模型生成本质上是一个计算过程。图像生成模型也是类似逻辑。Stable Diffusion、DALL·E、Midjourney 这类模型学习的是“文本描述”与“图像特征”之间的对应关系。它生成的图像之所以好看是因为训练数据里包含了大量人类筛选过的、符合审美的图片。模型学习到的是数据分布而不是审美本身。这就是为什么 AI 会“一本正经地胡说八道”。当模型遇到训练数据中没有明确答案的上下文时它仍然会按照概率生成一个看起来合理的答案但事实可能完全错误。这种现象也就是大家常说的 AI 幻觉。理解这一点很重要。它提醒我们AI 的“像人”是一种表面相似而不是本质上的意识或创造。它能够承担很多执行任务但它没有价值观、没有真实体验、没有对后果的感知。因此在 AI 生成的任何内容背后仍然需要一个负责任的人类主体做最终判断。这样一来ZHO 那句看似极端的话就有了一个更精确的解释AI 并不是把人类从物理世界开除而是把人类从“创作必须由人完成”的旧有绑定中释放出来。问题只剩一个我们有没有能力接住这种新的责任。4. 创作者如何重新定位从“生产者”到“判断者”如果你正在用 Cursor、Copilot、ChatGPT 这类工具写代码或写内容你一定会发现一个规律输入高质量的提示词往往比后续反复修改更重要。这不是偶然。因为大模型的输出质量取决于三样东西上下文质量你给它什么样的背景信息。指令清晰度你有没有把任务目标、格式、边界说清楚。验证机制你如何判断输出是否真的满足需求。在这个新范式下人类的核心竞争力不再是“亲手写得多快”而是“判断什么是对的”和“能否提出好问题”。我经常看到两类极端观点第一类认为“AI 什么都能做人类没用了”。这个说法过度简化了工程现实。无论模型多强你依然需要有人定义需求、选择模型、设计评估方式、处理失败情况、对结果负责。这些环节的难度不仅没有降低反而因为生成能力变强而更容易暴露问题。第二类认为“AI 只是玩具真正创作者不需要它”。这个说法同样不准确。今天的 AI 工具链已经深入生产环境从代码补全、自动测试、文档生成到产品原型几乎每个环节都能找到实际落地的例子。完全拒绝使用 AI等于主动放弃一个生产效率提升的机会。更合理的位置是人类负责设定方向AI 负责扩大产量人类再负责筛选和打磨。这套定位模型对应的技术实践也逐渐成熟Prompt 工程把需求转成模型能理解的指令。RAG检索增强生成给模型接上外部知识库减少幻觉。Agent 工作流让模型在多个步骤中自主调用工具人只负责目标设定和异常干预。评估与护栏加入自动校验对模型输出做过滤、打分和追溯。你会发现所有这些实践都指向同一个结论AI 越强大对人的“定义问题能力”要求越高。所谓“将人类从人类性中开除”真正发生的其实是“生产性”退出中心“判断性”被推到台前。5. 实践搭建一条最小可用的 AI 创作流水线为了不让前面几节变成纯观念讨论这一节我给出一个真正可以跑通的最小实践。目标很简单用大模型生成一段创作方案再通过配置文件把“生成 → 校验 → 人工审核”三个环节串起来。5.1 环境准备我假设你使用的操作系统是 Windows 10/11、macOS 或常见 Linux 发行版。工具链如下Python 3.8 或更高版本pip 或 conda 用于安装依赖一个可以调用的大模型服务可以是云端 API也可以是本地模型命令行终端为了避免依赖冲突建议在项目目录下创建独立的虚拟环境mkdir ai-creator cd ai-creator python3 -m venv venv source venv/bin/activateWindows 下激活命令是venv\Scripts\activate然后安装必要依赖。如果走 API 调用我们只需要requests或者openaiSDK如果走本地模型可以使用 Ollama。pip install requests5.2 示例一通过 API 调用大模型生成创作方案先写一个最简单的生成脚本。需要说明的是模型名和接口地址要以你实际使用的服务为准我这里只演示通用结构。# 文件路径ai_creator/generate.py import requests # 请替换成你实际使用的 API 地址 API_ENDPOINT https://api.your-provider.com/v1/chat/completions API_KEY 你的密钥 headers { Authorization: fBearer {API_KEY}, Content-Type: application/json } payload { # 这里填你当前账户可用的模型 model: your-chat-model, messages: [ {role: system, content: 你是一名创作策划。你负责把用户的模糊灵感扩展成可执行方案。}, {role: user, content: 灵感一个关于城市夜景的短视频。请给出脚本大纲。} ], temperature: 0.8, max_tokens: 1000 } resp requests.post(API_ENDPOINT, headersheaders, jsonpayload, timeout60) print(resp.json()[choices][0][message][content])运行python generate.py这段代码做了什么它把系统提示和用户提示拼在一起发给模型然后从返回结果中取出生成文本。重点可以关注几个参数temperature控制随机性。值越低越稳定值越高越有创造力。max_tokens控制生成长度上限。system消息给模型设定角色和任务边界。如果返回报错第一件事看 HTTP 状态码。常见的是 401密钥错误、429请求频率超限、400参数有误。不要盲目改代码先把错误信息读完整。5.3 示例二用本地模型跑通离线生成有些场景不适合把数据传给云端 API比如涉及内部资料、隐私数据或离线环境。这时可以在本地部署开源模型。这里以 Ollama 为例实际安装步骤请以官方文档为准。Ollama 安装完成后在终端拉取并运行一个开源模型# 拉取模型模型标签以 Ollama 官方库为准 ollama pull qwen2.5 # 进入交互式对话 ollama run qwen2.5交互式对话适合测试。如果你想在脚本里调用本地模型可以走 Ollama 暴露的本地接口# 文件路径ai_creator/local_generate.py import requests # 默认本地端口是 11434 resp requests.post( http://localhost:11434/api/generate, json{ model: qwen2.5, prompt: 请生成一个关于城市夜景短视频的脚本大纲, stream: False }, timeout300 ) print(resp.json()[response])这里的核心价值是数据不出本机适合隐私敏感场景。但它也有代价模型能力和上下文长度受限于你的显卡内存和 CPU 性能。如果你是第一次接触本地部署建议先选择较小的模型跑通流程再根据实际资源调整。5.4 示例三用配置文件把创作流程串起来单次生成只是第一步。真正的创作流程需要“生成 → 校验 → 人工审核 → 二次生成”。我们可以用一个简单的 YAML 配置描述这个过程。# 文件路径ai_creator/pipeline.yaml pipeline: steps: - name: generate type: llm model: qwen2.5 prompt_template: 根据灵感{idea}生成一个创作方案 temperature: 0.8 - name: auto_check type: script script: check_result.py # 自动检查是否包含必填字段比如“脚本大纲” - name: human_review type: manual required: true # 关键步骤必须由人来确认最终结果对应的简单执行脚本如下# 文件路径ai_creator/run_pipeline.py import subprocess import sys import yaml with open(pipeline.yaml, r, encodingutf-8) as f: config yaml.safe_load(f) idea sys.argv[1] for step in config[pipeline][steps]: if step[type] llm: # 实际生成逻辑可以复用前面的模型调用函数 print(f执行生成步骤灵感{idea}) elif step[type] script: print(f执行自动校验{step[script]}) elif step[type] manual: answer input(人工审核通过吗(y/n)) if answer ! y: print(结果被人类否决) sys.exit(1) print(流程完成)在这个最小示例中人类并没有被开除而是被放在了关键节点最终质量由人来确认。6. 运行结果与效果验证搭建完流水线之后很多人会直接开始用但这就跳过了最重要的一个环节效果验证。你需要在固定输入集合上反复测试模型的输出并记录哪些结果能正常使用、哪些会出现幻觉、哪些风格不稳定。只有积累了几十条样本你才能判断这个模型在你这套任务上是否可靠。我建议用一个简单的验证表维度检查问题不合格示例处理方法事实准确性输出是否有客观事实错误把某个时间、人物、数据说错接入 RAG 或人工复核逻辑连贯性上下文是否自洽前后矛盾、论据断裂拆分问题、增加约束风格一致性是否满足品牌或项目要求语气时正式时随意在 system 中给出风格示例内容安全是否包含违规、歧视、低俗内容出现不当表述加入内容过滤和审核机制合规性是否符合版权、隐私要求直接搬运受版权保护内容审查训练数据来源人工把关验证脚本可以用最简单的规则来实现。比如检查输出中是否包含指定关键词或者输出长度是否在合理范围# 文件路径ai_creator/check_result.py import sys text sys.stdin.read() required_keywords [脚本大纲, 分镜, 夜景] for keyword in required_keywords: if keyword not in text: print(f缺少关键词{keyword}) sys.exit(1) if len(text) 100: print(输出过短) sys.exit(1) print(自动校验通过)运行验证时先固定一批测试输入比如 10 个不同主题的创作需求然后记录通过率。第一次通过率低于 50% 是正常的重点不是一次通过而是你能发现模型在当前配置下最容易犯哪类错误。7. 常见问题与排查思路在搭建和运行 AI 创作流水线的过程中有几个高频问题值得提前排查。问题现象可能原因排查方式解决方案调用 API 返回 401API 密钥错误或过期检查请求头和账户状态重新生成密钥并确认密钥不泄露模型输出内容与主题无关提示词太模糊或上下文被截断查看请求 messages 是否完整把任务和背景信息写得更明确生成内容有明显事实错误模型产生幻觉或缺少知识来源抽样检查引用数据接入外部知识检索增加审核节点本地模型推理速度很慢模型参数过大超出显存与内存查看 GPU 使用率和内存占用换更小模型或使用量化版本输出内容风格不稳定temperature 设置过高对比多轮输出调低 temperature或加入风格示例生产环境出现违规内容缺少内容安全过滤检查完整链路中是否有审核节点增加关键词过滤、模型分类器、人工抽检如果是一条通用的排查思路我建议按这个顺序走先确认输入无误。80% 的异常是因为提示词或参数设置不当。再确认模型版本。不同模型在相同任务上差异很大。接着看日志。不要只看报错还要看请求和响应全文。最后再考虑调整模型、换模型或增加后处理。8. 工程实践与内容安全建议如果你的 AI 创作流程要进入团队协作或生产环境只跑通示例是不够的。以下几条建议来自实际工程经验。模型与配置版本管理AI 项目最容易出现的问题之一是“昨天还能跑的生成结果今天突然变了”。大模型服务经常更新本地模型也有不同版本。因此在项目里必须记录模型名称和版本号。关键参数比如 temperature、max_tokens。提示词模板的修改历史和变更人。有条件的话把提示词和配置纳入 Git 管理每次改动都有记录。内容安全与合规边界大模型生成内容并不天然安全。训练数据中可能存在偏见、错误和不合规的表达。你必须把内容安全当成系统的一部分而不是事后补救在生成后增加内容过滤节点支持关键词过滤和模型审核。对涉及人物、医疗、法律、金融等敏感领域的内容必须有人工审核。版权问题要格外谨慎。不要直接把他人有版权的作品输入模型并重新分发。涉及隐私数据时优先使用本地模型或私有化部署并遵循最小权限原则。权限与审计如果 AI 工具在企业内部开放给多人使用一定要设置合理的权限边界。比如普通成员只能使用预设提示词管理员可以修改工作流。AI 调用日志要保留便于事后追踪。灰度发布与回滚不要在生产环境一次性替换全部人工流程。建议先选择小范围任务做灰度观察输出质量和用户反馈。一旦发现问题要能快速切回人工处理或旧版本模型。任何涉及生产环境的变更都应该先在测试环境验证并保留回滚方案。失败处理与人工兜底AI 生成结果的失败模式通常和人类不同可能看起来完美但全是错误也可能反复生成都不满足需求。因此流程设计必须包含“人类接管”的按钮。不要设计一个完全没有人参与的自动生成系统至少要在质量评估和异常处理上保留人工节点。9. 总结与后续学习方向回到开头的题目。ZHO 说“AI 将人类从人类性中开除”这个判断的真正含义我认为是人类过去那种“作品必须由人产出”的旧身份正在失效我们正在被推到新的位置上。被开除的是“我写得慢所以我专业”的旧叙事。被保留的是“我知道什么是对的我知道为什么这样做”的判断能力。AI 越强判断的责任就越大。如果你看完这篇文章只想记住一件事那就是不要盲目相信模型的输出不要完全放弃人的审核不要忽略流程设计和版本管理。在当前技术阶段最稳定的 AI 创作系统一定是由“人定义问题、AI 高速生成、系统自动校验、人最终把关”四层组成。接下来你可以继续深入三个方向Prompt 工程与结构化提示词学习如何用固定格式描述复杂任务提高输出稳定性。RAG 与 Agent 工作流让模型在生成前检索外部资料在生成后自动调用工具验证减少幻觉。模型评估与微调建立自己的测试集量化评估模型表现在必要时用真实数据做微调让输出更贴合业务场景。建议你先从今天的最小示例开始把一条简单的生成链路跑通再逐步加入自动校验、人工审核和更复杂的 Agent 流程。技术变化很快但“人负责方向AI 负责执行人负责验收”这个协作模型在很长一段时间内都适用。