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

今天聊一个听起来有点冒犯的话题：AI 是否正在把“创作者”这个词从人类词典里删除。

艺术家 ZHO 在讨论 AI 与艺术创作的关系时，提出了一个更尖锐的判断——“AI 将人类从人类性中开除”。这里的“人类性”，不是一个生理概念，而是指人类长期默认拥有的一种身份：创作者、生产者、决策者。过去，我们写一首诗、画一张图、设计一个 App、写一段代码，背后都有一个自然的隐含前提——这件事必须由人完成。AI 出现以后，这个前提第一次被真正动摇了。

我理解这句话不是在否定人，而是在提醒我们：当机器能生成高质量内容，人类在创作流程中的位置就不再是天然的、唯一的、不可替代的。如果你正在使用大模型做内容、编程、设计或开发 AI 产品，这个问题不是你该不该关心，而是你已经身处其中。

这篇文章会把 ZHO 这句话从哲学拉回工程现场，从四个角度展开：第一，AI 如何改变创作主体的位置；第二，大模型“像人”的技术原理到底是什么；第三，如何实际搭建一条可运行的 AI 创作流水线；第四，在这个新流程里，人类还能守住哪些不可替代的边界。读完你会得到一个判断框架，也能跟着示例跑通一套最小可用的创作工作流。

1. 为什么“AI 将人类从人类性中开除”值得认真讨论

很多技术讨论有一个通病：把 AI 说成“一个更好用的工具”。这个框架本身没有错，但它隐藏了一个更关键的变化。

传统工具，比如画笔、打字机、IDE，它们能放大人的能力，但不能替代人的意图。没有画家，画笔不会自己画画；没有程序员，编译器不会自己产生业务逻辑。而大模型改变了这一点：你给它一句模糊的提示词，它能自动完成扩展、生成、组织、呈现的完整过程。在“创意输入”和“成品输出”之间，人类干预的颗粒度正在变小。

所以 ZHO 说“开除”，实际上指的是一个正在发生的事实：人类从创作链条的必经节点，变成了可选节点。

这句话在今天意味着三层含义：

• 能力层：模型已经能完成过去只有训练有素的人才能完成的工作，比如写代码、画插画、写文案、做视频脚本。
• 流程层：传统的“人想 → 人做 → 人改”流程，正在变成“人想 → 模型做 → 人审”的流程，有些环节甚至“人想”都开始由模型辅助。
• 身份层：当作品的生产过程不再依赖人类的基本功，社会对“创作者”的定义就会松动。人们将更关注结果，而不是结果背后的物种。

这三层变化不是未来预言，而是过去几年已经发生的事实。对普通开发者来说，最早感受到的通常是第二层：原来要花一整天的编码任务，现在交给 AI 只要几分钟。但真正需要警惕的不是“代码写得快不快”，而是我们是否仍然清楚：这个流程里，哪些判断必须由人来做。

2. 创作主体的转移：从“人使用工具”到“模型即主体”

为了说清楚这个变化，我们先回到一个基础概念：创作主体。

在传统创作中，“主体”是一个完整的人。一幅画之所以被认为是艺术，不仅因为画面好看，还因为观众能感知到背后的创作者意图、生活经验、审美判断和偶然性。这就是为什么美术史至今仍然强调“作者”这个身份。

AI 生成作品出现后，这个链条被打断了。模型不知道自己在创作，它只是在做概率计算，但它输出的结果却可以被解释为“有意图的作品”。于是我们面对一个尴尬局面：作品还在，作者不见了。

我把这个变化拆成一张表：

真正值得注意的变化是第三行：修改对象变了。

以前写代码，改的是代码；以前写文案，改的是文字。现在用大模型，你改的是提示词、温度、上下文、模型版本。这意味着人类正在从“直接生产内容”退到“设计生成条件”。这个角色的变化，比“AI 能画图”本身更值得关注。

当模型已经生成大部分内容，人的工作就变成了一个更抽象、更高层级的任务：定义问题、划定边界、审核结果。ZHO 所说的“开除”，并不是说人类从此无事可做，而是说人类过去熟悉的“生产者”身份被取消了，必须换一种方式参与创作。

3. 技术原理：为什么 AI 看起来“像人”

要判断“AI 将人类从人类性中开除”这个说法有没有道理，不能只停留在概念层面，我们需要理解大模型到底在做什么。

以文本大模型为例，它的核心机制可以概括为：预测下一个 token。

训练时，模型读入海量文本，学习的是“在一段上下文之后，下一个词最可能是什么”。推理时，你输入“今天天气”，模型会根据学习到的概率分布生成“很好”“不错”“很差”等内容。这个过程看起来很像人，因为它输出的语言和人类写出来的语言高度相似。

但这和人类写作有本质区别：

• 人类写作有真实世界体验作为支撑，模型没有。
• 人类写作有稳定的自我意识和立场，模型没有。
• 人类写作受制于物理时间，模型生成本质上是一个计算过程。

图像生成模型也是类似逻辑。Stable Diffusion、DALL·E、Midjourney 这类模型，学习的是“文本描述”与“图像特征”之间的对应关系。它生成的图像之所以好看，是因为训练数据里包含了大量人类筛选过的、符合审美的图片。模型学习到的是数据分布，而不是审美本身。

这就是为什么 AI 会“一本正经地胡说八道”。当模型遇到训练数据中没有明确答案的上下文时，它仍然会按照概率生成一个看起来合理的答案，但事实可能完全错误。这种现象也就是大家常说的 AI 幻觉。

理解这一点很重要。它提醒我们：AI 的“像人”，是一种表面相似，而不是本质上的意识或创造。它能够承担很多执行任务，但它没有价值观、没有真实体验、没有对后果的感知。因此，在 AI 生成的任何内容背后，仍然需要一个负责任的人类主体做最终判断。

这样一来，ZHO 那句看似极端的话就有了一个更精确的解释：AI 并不是把人类从物理世界开除，而是把人类从“创作必须由人完成”的旧有绑定中释放出来。问题只剩一个：我们有没有能力接住这种新的责任。

4. 创作者如何重新定位：从“生产者”到“判断者”

如果你正在用 Cursor、Copilot、ChatGPT 这类工具写代码或写内容，你一定会发现一个规律：输入高质量的提示词，往往比后续反复修改更重要。

这不是偶然。因为大模型的输出质量，取决于三样东西：

1. 上下文质量：你给它什么样的背景信息。
2. 指令清晰度：你有没有把任务目标、格式、边界说清楚。
3. 验证机制：你如何判断输出是否真的满足需求。

在这个新范式下，人类的核心竞争力不再是“亲手写得多快”，而是“判断什么是对的”和“能否提出好问题”。

我经常看到两类极端观点：

第一类认为“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/activate

Windows 下激活命令是：

venv\Scripts\activate

然后安装必要依赖。如果走 API 调用，我们只需要requests或者openaiSDK；如果走本地模型，可以使用 Ollama。

pip install requests

5.2 示例一：通过 API 调用大模型生成创作方案

先写一个最简单的生成脚本。需要说明的是，模型名和接口地址要以你实际使用的服务为准，我这里只演示通用结构。

# 文件路径：ai_creator/generate.py import requests # 请替换成你实际使用的 API 地址 API_ENDPOINT = "https://api.your-provider.com/v1/chat/completions" API_KEY = "你的密钥" headers = { "Authorization": f"Bearer {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, headers=headers, json=payload, timeout=60) 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 }, timeout=300 ) 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", encoding="utf-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. 运行结果与效果验证

搭建完流水线之后，很多人会直接开始用，但这就跳过了最重要的一个环节：效果验证。

你需要在固定输入集合上，反复测试模型的输出，并记录哪些结果能正常使用、哪些会出现幻觉、哪些风格不稳定。只有积累了几十条样本，你才能判断这个模型在你这套任务上是否可靠。

我建议用一个简单的验证表：

验证脚本可以用最简单的规则来实现。比如检查输出中是否包含指定关键词，或者输出长度是否在合理范围：

# 文件路径：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 创作流水线的过程中，有几个高频问题值得提前排查。

如果是一条通用的排查思路，我建议按这个顺序走：

1. 先确认输入无误。80% 的异常是因为提示词或参数设置不当。
2. 再确认模型版本。不同模型在相同任务上差异很大。
3. 接着看日志。不要只看报错，还要看请求和响应全文。
4. 最后再考虑调整模型、换模型或增加后处理。

8. 工程实践与内容安全建议

如果你的 AI 创作流程要进入团队协作或生产环境，只跑通示例是不够的。以下几条建议来自实际工程经验。

模型与配置版本管理

AI 项目最容易出现的问题之一，是“昨天还能跑的生成结果，今天突然变了”。大模型服务经常更新，本地模型也有不同版本。因此在项目里必须记录：

• 模型名称和版本号。
• 关键参数，比如 temperature、max_tokens。
• 提示词模板的修改历史和变更人。

有条件的话，把提示词和配置纳入 Git 管理，每次改动都有记录。

内容安全与合规边界

大模型生成内容并不天然安全。训练数据中可能存在偏见、错误和不合规的表达。你必须把内容安全当成系统的一部分，而不是事后补救：

• 在生成后增加内容过滤节点，支持关键词过滤和模型审核。
• 对涉及人物、医疗、法律、金融等敏感领域的内容，必须有人工审核。
• 版权问题要格外谨慎。不要直接把他人有版权的作品输入模型并重新分发。
• 涉及隐私数据时，优先使用本地模型或私有化部署，并遵循最小权限原则。

权限与审计

如果 AI 工具在企业内部开放给多人使用，一定要设置合理的权限边界。比如普通成员只能使用预设提示词，管理员可以修改工作流。AI 调用日志要保留，便于事后追踪。

灰度发布与回滚

不要在生产环境一次性替换全部人工流程。建议先选择小范围任务做灰度，观察输出质量和用户反馈。一旦发现问题，要能快速切回人工处理或旧版本模型。任何涉及生产环境的变更，都应该先在测试环境验证，并保留回滚方案。

失败处理与人工兜底

AI 生成结果的失败模式通常和人类不同：可能看起来完美但全是错误，也可能反复生成都不满足需求。因此流程设计必须包含“人类接管”的按钮。不要设计一个完全没有人参与的自动生成系统，至少要在质量评估和异常处理上保留人工节点。

9. 总结与后续学习方向

回到开头的题目。ZHO 说“AI 将人类从人类性中开除”，这个判断的真正含义，我认为是：人类过去那种“作品必须由人产出”的旧身份正在失效，我们正在被推到新的位置上。

被开除的，是“我写得慢所以我专业”的旧叙事。被保留的，是“我知道什么是对的，我知道为什么这样做”的判断能力。AI 越强，判断的责任就越大。

如果你看完这篇文章只想记住一件事，那就是：不要盲目相信模型的输出，不要完全放弃人的审核，不要忽略流程设计和版本管理。在当前技术阶段，最稳定的 AI 创作系统，一定是由“人定义问题、AI 高速生成、系统自动校验、人最终把关”四层组成。

接下来你可以继续深入三个方向：

• Prompt 工程与结构化提示词：学习如何用固定格式描述复杂任务，提高输出稳定性。
• RAG 与 Agent 工作流：让模型在生成前检索外部资料，在生成后自动调用工具验证，减少幻觉。
• 模型评估与微调：建立自己的测试集，量化评估模型表现；在必要时用真实数据做微调，让输出更贴合业务场景。

建议你先从今天的最小示例开始，把一条简单的生成链路跑通，再逐步加入自动校验、人工审核和更复杂的 Agent 流程。技术变化很快，但“人负责方向，AI 负责执行，人负责验收”这个协作模型，在很长一段时间内都适用。