客户改到 V4，AI 还在跑 V1：给 Agent 装上「项目状态机」

凌晨一点，你盯着一支 AI 广告片。

画面挺漂亮。镜头也够快。

问题是，客户下午已经说了：暖金色改成冷白色，片头产品露出删掉，文案换成新卖点。

结果，画面 Agent 还在生成暖金色日落；文案 Agent 还在写旧卖点；剪辑 Agent 更离谱，拿着两小时前的分镜表开始拼片。

你看着满屏文件，脑子里只剩一句话：这 AI 到底有没有在听？

它听了。问题不在“听没听到”，而在于它不知道：哪些信息已经失效，哪些信息优先级最高，哪些任务必须立刻停掉。

很多团队给 Agent 拼命塞上下文，以为资料越全越聪明。实际项目一复杂，资料越多，Agent 越容易拿旧需求当圣旨。

真正需要管理的，不是一段越来越长的聊天记录，而是一个始终同步的项目状态。

一、上下文很重要，但它解决不了版本混乱

上下文是 Agent 的参考资料。

比如：

品牌介绍
产品卖点
用户画像
视觉风格
历史讨论记录
已生成的脚本和图片

这些内容当然要给。

可一旦客户频繁修改，光靠“把新消息追加到聊天记录末尾”就要出事。

原因很简单：模型看到的是一堆文字，它未必天然理解哪条要求已经作废。

来看一个常见场景。

V1：做一支 30 秒咖啡广告，暖金色晨光，突出“手冲仪式感”。
V2：产品改成即饮咖啡，节奏更快。
V3：不要晨光，改成深夜办公室。
V4：片头不要出现产品，核心卖点改成“加班也有好状态”。

如果你只是把 V1 到 V4 全扔进上下文，Agent 可能会这样理解：

暖金色晨光：出现过，似乎重要
手冲仪式感：出现过，似乎能用
深夜办公室：也要保留
片头不出现产品：可能只是一个补充意见

于是它端出一盘“四不像”。

画面是深夜办公室，灯光却暖得像早晨；人物在冲手冲咖啡；片头还给产品一个大特写。你想砸电脑，Agent 也挺委屈：资料里明明都有啊！

所以要记住一句：

上下文负责提供信息，状态负责裁决信息。

没有状态层，Agent 只能猜。

二、什么是项目状态机？把“最新要求”变成唯一事实源

别被“状态机”三个字吓到。放在 AI 项目里，它就是一份结构化、可更新、可追踪的项目总控表。

你可以把它理解成项目的“唯一事实源”。

任何 Agent 开工前，不是去翻 200 条聊天记录，而是读取这一份当前有效的状态。

一个实用的项目状态，可以拆成 6 个区域：

{
  "project_id": "coffee_ad_2025_04",
  "version": "V4",
  "status": "script_revision",
  "core_goal": "突出即饮咖啡在深夜加班场景下的提神价值",
  "active_requirements": {
    "duration": "30秒",
    "scene": "深夜办公室",
    "visual_tone": "冷白、克制、有少量屏幕蓝光",
    "key_message": "加班也有好状态",
    "product_rule": "片头禁止出现产品，结尾露出产品"
  },
  "forbidden_items": [
    "暖金色晨光",
    "手冲过程",
    "片头产品特写",
    "旧卖点：手冲仪式感"
  ],
  "deliverables": {
    "script": "pending_revision",
    "storyboard": "blocked",
    "image_generation": "blocked",
    "video_edit": "blocked"
  },
  "change_log": [
    {
      "version": "V4",
      "change": "修改核心卖点；删除片头产品露出",
      "impact": ["脚本", "分镜", "首帧", "剪辑节奏"],
      "approved": true
    }
  ]
}

看到这里你会发现，关键不只是存下“新需求”。

更关键的是明确写出：

当前版本是什么
哪些要求仍然有效
哪些内容已经禁止
哪些产物已经过期
哪些 Agent 必须暂停
这次修改会影响哪些下游工作

这才是项目管理。不是给 AI 记笔记。

三、每次客户改需求，都要做一次「影响范围判定」

客户说“就改一句文案”，往往是项目里最危险的一句话。

因为一句文案背后，可能牵动整条生产链。

例如客户把卖点从“手冲仪式感”换成“加班也有好状态”。

看上去只是文案改动，实际至少影响：

| 模块 | 是否受影响 | 原因 | | --- | --- | --- | | 广告脚本 | 是 | 叙事主题变了 | | 人物设定 | 是 | 人物需要从晨间消费者变成加班人群 | | 场景设计 | 是 | 晨光厨房不再成立 | | 分镜 | 是 | 开场、情绪铺垫、转场都要调整 | | 首帧图片 | 是 | 光线、道具、构图需要重做 | | 配音文案 | 是 | 语气和节奏要更利落 | | BGM | 大概率 | 松弛感音乐不适合高压办公室 | | 剪辑工程 | 是 | 旧素材可能全部失效 |

别让 Agent 自己猜影响范围。

给它一条固定规则：需求变更发生后，先生成 Change Impact Report，再允许执行。

你可以直接把下面这段放进工作流：

当收到新修改意见时，不得直接生成内容。

请完成以下动作：
1. 提取本次新增、删除、替换的需求。
2. 与当前项目状态比对。
3. 标记冲突项和失效项。
4. 判断受影响的交付物。
5. 将受影响交付物状态改为 blocked 或 stale。
6. 输出变更影响报告，等待确认后再继续执行。

这样一来，客户一句“片头别露产品”，系统不会傻乎乎只改第一句旁白。

它会提醒你：片头分镜、首帧、产品图层、转场节奏，全部要重新检查。

这一步能少掉大量“改完才发现漏了三处”的深夜返工。😮‍💨

四、给每份产物加版本指纹，别再靠文件名硬扛

很多 AI 项目翻车，死在文件命名上。

你的电脑里可能已经出现：

脚本最终版.docx
脚本最终版2.docx
脚本最终版真的最终.docx
脚本最终版真的最终_客户确认版.docx

很有生活气息，也很容易出事故。

更稳的做法，是让每个产物携带自己的“版本指纹”。

例如：

{
  "asset_id": "storyboard_001",
  "asset_type": "storyboard",
  "created_from_version": "V3",
  "requirement_hash": "a8f1c2",
  "status": "stale",
  "stale_reason": "V4 修改了核心卖点和片头规则",
  "owner_agent": "StoryboardAgent"
}

这里有三个字段特别重要：

created_from_version：它基于哪个项目版本生成
status：还能不能继续用
stale_reason：为什么过期

当项目升到 V4，系统自动检查所有 V3 产物。

没有受影响的，保留。

受影响的，标成 stale。

严重冲突的，直接标成 invalid。

别小看这个动作。它能阻止剪辑 Agent 把过期素材塞回新项目，也能防止团队成员误把旧图发给客户。

五、Agent 开工前，强制回答 4 个问题

一个靠谱的执行 Agent，不该拿到任务就开跑。

它必须先做一次“开工自检”。

每次生成脚本、图片、视频、代码或设计稿前，让它回答：

当前项目版本是多少？
本任务依赖哪些有效需求？
有哪些明确禁止项？
我使用的输入素材是否仍然有效？

提示词可以写得很直接：

你是项目执行 Agent。
执行任务前，必须读取 Project State。

请在输出内容前展示：
- 当前版本号
- 本次任务引用的有效需求
- 禁止触碰的要求
- 输入素材的版本与有效状态

若发现版本不一致、素材状态为 stale/invalid、需求存在冲突，立即停止执行，输出“需要人工确认”的问题清单。
不得自行采用旧版本要求补全内容。

别嫌这几行字麻烦。

麻烦在开工前暴露，叫检查。

麻烦在视频渲染完、客户看完、老板问责时暴露，叫事故。

六、把 Agent 分成「决策层」和「执行层」

很多人做多 Agent 工作流，会给每个 Agent 一大坨上下文，然后让它们各自发挥。

画面 Agent 理解一套。

文案 Agent 理解一套。

剪辑 Agent 又理解一套。

项目就像三个人戴着耳机开会，谁也听不见谁。

更合理的结构是两层。

1. 决策层：负责判断，不负责出活

决策层通常包括：

需求解析 Agent：把客户口语整理成明确需求
冲突检测 Agent：找出新旧需求打架的地方
变更影响 Agent：判断哪些交付物失效
项目状态管理器：更新唯一事实源

它们的工作是管住方向。

2. 执行层：负责生产，不擅自决策

执行层可以包括：

脚本 Agent
分镜 Agent
图片生成 Agent
视频生成 Agent
配音 Agent
剪辑 Agent
质检 Agent

它们只读取已确认的状态和被分配的任务。

一个很实用的原则：

执行 Agent 可以提出疑问，不能私自解释冲突。

比如需求里同时出现“画面要极简”和“首屏塞满 6 个卖点”。

画面 Agent 不该自己决定删哪个。

它应该停下来，抛出问题：

检测到冲突：
- 要求 A：首屏视觉极简
- 要求 B：首屏展示 6 个卖点

请确认优先级：
1. 保留极简风格，卖点后置
2. 保留 6 个卖点，接受信息密度提高
3. 提供新的版式要求

这才像一个靠谱同事。不会闷头干错活。

七、别把聊天记录当数据库：建立「需求卡片」

客户需求常常藏在语音、微信、飞书评论、会议纪要里。

如果你靠人工翻聊天记录，漏一条是迟早的事。

建议把每条有效需求都转成需求卡片。

模板很简单：

## 需求卡片 R-024

- 来源：客户 4 月 18 日会议
- 状态：已确认
- 优先级：高
- 内容：片头 3 秒不得出现产品包装
- 影响模块：脚本、分镜、首帧、剪辑
- 替代需求：无
- 生效版本：V4
- 负责人：创意负责人确认

需求卡片有几个好处：

每条要求有出处，不怕“我什么时候说过？”
每条要求有状态，不怕废话混进正式需求
每条要求有影响模块，不怕漏改
每条要求有生效版本，不怕新旧打架

这里要特别区分三类信息：

| 类型 | 要不要进入项目状态 | 例子 | | --- | --- | --- | | 已确认需求 | 要 | “片头不出现产品” | | 待讨论意见 | 暂时不要 | “要不试试霓虹灯？” | | 随口评价 | 不要 | “这一版感觉有点普通” |

很多项目混乱，就是因为客户一句“要不试试”，被 Agent 当成了必须执行的指令。

这锅真不能让模型全背。输入规则没立住，谁来都容易乱。

八、一个能直接照搬的 AI 广告片工作流

下面是一套轻量级流程。你用 ChatGPT、Claude、Coze、Dify、n8n，甚至飞书多维表格，都能搭起来。

阶段 1：接收修改

输入来源可以是会议纪要、客户聊天记录、语音转写文本。

需求解析 Agent 输出：

### 本次修改摘要
- 删除：暖金色晨光氛围
- 删除：片头产品露出
- 替换：核心卖点由“手冲仪式感”改为“加班也有好状态”
- 保留：成片时长 30 秒
- 新增：场景限定为深夜办公室

### 待确认问题
- 深夜办公室是否需要出现明确品牌 Logo？
- 产品在第几秒露出？

阶段 2：更新项目状态

项目状态管理器完成：

版本号从 V3 升级到 V4
更新有效需求
写入禁止项
记录修改来源

阶段 3：生成变更影响报告

系统扫描已有产物：

### 受影响资产
- V3 脚本：失效
- V3 分镜：失效
- 晨光厨房首帧：无效
- 产品包装 3D 模型：可保留
- 配音音色方案：可保留，文案需重录

### 建议执行顺序
1. 确认产品首次露出时间
2. 重写脚本
3. 重做分镜
4. 生成首帧与关键镜头
5. 生成视频素材
6. 重新配音与剪辑

阶段 4：人工确认关键分叉

凡是涉及创意方向、预算、品牌风险的内容，别让 Agent 自动拍板。

比如：

片头究竟空几秒
深夜办公室要压抑还是热血
产品露出要自然植入还是强转场
是否允许使用夸张的提神表达

你确认后，再放执行 Agent 开始干活。

阶段 5：执行与回写

每个 Agent 交付后，都要回写状态：

{
  "asset_id": "script_v4",
  "status": "review_required",
  "based_on_project_version": "V4",
  "used_requirement_ids": ["R-021", "R-024", "R-026"],
  "excluded_requirement_ids": ["R-008", "R-011"]
}

这样你随时能查：这份脚本到底听了谁的话，又刻意避开了哪些旧要求。

九、最容易踩的 5 个坑

1. 把所有历史消息塞进 Prompt

历史记录不是越全越好。

旧版本需求、情绪化评价、已被否决的创意，全塞进去只会污染判断。

正确做法：

当前有效状态放在最前面
已废弃需求单独列为禁止项
历史记录按需检索，不要整包投喂

2. 修改后不冻结下游任务

客户改了核心场景，图片 Agent 还在跑旧图，视频 Agent 还在排队渲染。

钱和时间一起烧，真的很疼。

正确做法：

发生重大修改时，自动将下游任务设为 blocked，等影响分析完成再解锁。

3. 让每个 Agent 自己维护版本

这会制造多个“真相中心”。

文案 Agent 说自己是 V4，剪辑 Agent 说自己还是 V3，最后谁都没错，项目错了。

正确做法：

版本只在一个地方维护。所有 Agent 只读同一个 Project State。

4. 没有「废弃清单」

很多人会写新增要求，却忘了写删除要求。

于是“暖金色”“晨光”“手冲”会像僵尸一样，隔几版又从某个 Prompt 里爬回来。

正确做法：

每次替换需求，都写清楚旧要求是否废弃。废弃项进入 forbidden_items。

5. 以为自动化越多越好

自动化适合重复劳动。

品牌调性、创意取舍、客户模糊表达，这些地方需要人做决定。

别为了“全自动”让系统在错误方向上狂奔。跑得越快，返工越壮观。

十、给你一份可直接使用的总控 Prompt

如果你暂时不想搭复杂系统，用一个“项目总控 Agent”也能先把流程跑顺。

你是 AI 项目总控 Agent，负责维护项目唯一事实源。

你的职责：
1. 接收客户反馈，提取明确需求、待确认意见和情绪化评价。
2. 对比当前项目状态，识别新增、删除、替换、冲突的内容。
3. 更新项目版本号与有效需求清单。
4. 将被替换或删除的内容加入禁止项。
5. 分析本次变更影响的交付物，将其标记为 valid、stale、invalid 或 blocked。
6. 为执行 Agent 生成简洁、无冲突的任务简报。

工作规则：
- 未确认的意见不得写入有效需求。
- 发现冲突时停止自动执行，提出明确的选择题让人工确认。
- 不得依据旧版本需求补全新任务。
- 每次输出必须包含：当前版本、变更摘要、有效需求、禁止项、受影响资产、待确认问题。

当前项目状态：
{{project_state}}

客户最新反馈：
{{client_feedback}}

这套 Prompt 的价值，不是让模型写得更花。

它是为了让模型知道：什么时候该干活，什么时候该停。

结语：Agent 不缺记忆，缺的是一套能裁决的秩序

客户改到 V4，AI 还执行 V1，表面看是模型不聪明。

往深了看，是项目里没有一个地方能明确宣布：

V1 已经结束
V3 哪些资产还能用
V4 的核心目标是什么
谁可以继续干活
谁必须停下来等确认

上下文像仓库，什么都能放。

项目状态像调度台，决定什么该被拿出来用。

当你把这层调度搭起来，AI 才会从“会生成内容的工具”，变成真正能进项目组干活的执行者。

客户临时改需求？

可以改。

至少这次，不会再看到 V1 的暖金色太阳从 V4 的深夜办公室里冉冉升起了。🌚