两万字需求，怎样拆成 AI 团队能落地的施工图？
**系列导航：**本篇回答长需求怎样变成可执行施工图；接着阅读故障注入测试，再进入本地运行与手机控制面。三篇分别讨论怎样规划、怎样验证、怎样远程掌握。
一份两万字的任务书交给 AI，最危险的结果不是它说“做不了”，而是它很快给出一份看起来非常完整的计划。
标题、阶段、工期、责任人一应俱全。直到执行时，你才发现：最后三页的权限红线没有进入任务；“系统已经有网关”被误读成“重新开发网关”；两个 Agent 同时修改同一个核心文件；写代码的人又顺手宣布自己验收通过。
问题不在于 AI 不会列清单，而在于一份清单无法证明四件事：原文是否读全、要求是否分清、任务是否可执行、完成是否经过独立验收。
我们真正需要的不是另一份“工作总结”，而是一套能回答以下问题的施工图：
- 原始需求是哪一版，是否完整读到最后一行？
- 每条硬要求进入了哪张任务单、哪项测试和哪份证据？
- 谁可以开工，谁必须等待，谁有权验收？
- 需求或计划变化后，旧批准为什么必须作废？
- 执行失败时，从哪里恢复，而不是让另一个 Agent 重新猜一遍？
本文用 CodeFlowMu 已公开的长任务规划合同解释这条流水线，并把 FCoP 与 CodeFlowMu 的职责分开。前者规定协作事实如何落成文件，后者负责让这些工件进入真实的规划、派工、执行和验收过程。
长需求不是拿来摘要的材料，而是要被编译成施工图的工程输入。
先看结果：两万字最后会变成什么？
一轮合格的长任务规划，至少应留下五类可检查产物：
| 产物 | 它回答的问题 | 不能替代什么 |
|---|---|---|
| 来源记录 | 读的是哪一版、多少行、是否到达全文末尾 | 不能证明 AI 已正确理解全文 |
| 需求台账 | 每条要求来自哪里，属于硬要求、事实、目标还是假设 | 不能替有权的人处理冲突 |
| 工作包与先后依赖图 | 谁做、交付什么、先等谁、怎样测试、失败怎样退回 | 不能证明代码已经实现 |
| 经校验的产品计划 | 要求覆盖、预算、日程、依赖和风险是否自洽 | 不能替代人类批准开工 |
| 任务、报告、审查与证据 | 实际做了什么、测试是否运行、谁作出验收决定 | 不能由执行者自我声明完成 |
这五类产物不是五份重复文档，而是一条追踪链：
原文第 318—325 行
↓
要求 REQ-0042：开放版不得获得新的发布权限
↓
工作包 WP-05：定义手机端允许动作
↓
测试 T-18：开放版发布动作必须被拒绝
↓
证据 E-09：测试命令、退出码、输出与运行环境
↓
验收人：ADMIN链条中任何一格为空，都不能用“计划写得很完整”掩盖。
整条流水线：谁输入，谁处理，谁输出？
在当前实现中，系统、人和 AI 的分工不是“AI 全自动完成”，而是：运行系统守住可计算、可校验的边界，AI 负责语义提取与规划，人类处理冲突并决定是否放行。
两万字原始任务书
│
▼
① 锁定来源 ── 版本、行数、全文读取范围、SHA-256 校验码
│
▼
② 编制需求台账 ── 硬要求 / 目标设计 / 现场事实 / 估算 / 假设 / 权限边界
│
▼
③ 生成施工图 ── 工作包、先后依赖、预算、测试、证据、恢复方案
│
▼
④ 程序校验 + 人工审批 ── 校验计划自洽性；只批准当前版本的第一步
│
▼
⑤ 派工与验收 ── TASK → DEV / QA / OPS → REPORT → REVIEW / ADMIN 决定
图 1：五步工程链分别标出输入、责任主体、输出与阻断条件。需求台账和工作包属于 CodeFlowMu 规划层；正式协作阶段才进入 FCoP 的 TASK、REPORT 与 REVIEW。来源：CodeFlowMu 长任务规划合同、PM 规划治理规范、FCoP v3。
下面逐步拆开。
第一步：锁定来源——先证明读的是哪一份
**输入：**原始任务书及其引用的附件、规范、代码版本和旧方案。
**责任：**PM Agent 完整读取；CodeFlowMu 规划流程保存并校验来源身份。 **输出：**绝对路径、版本、SHA-256 校验码、字节数与行数、读取时间、已读范围、引用集合。
校验码可以理解成文件的“版本指纹”。原文哪怕只改一个标点，指纹也会变化。它不是为了加密，而是为了回答：当前计划和批准究竟绑定了哪一版原文？
行数和“读到文件末尾”的记录则回答另一个问题：输入是否在中途被截断。CodeFlowMu 的长任务规划技能要求从第一个字节读到文件末尾，必要时分段读取，并记录每段范围；只有到达末尾后才能把完整读取标记设为真。
这里必须克制：读到最后一行只能证明读取范围完整，不能证明模型理解了每一句话。理解是否可靠，要靠下一步的逐条台账、冲突记录和验收映射继续检查。
第二步：编制需求台账——不让事实、愿望和红线混在一起
**输入：**已锁定版本的完整任务书。
**责任：**PM Agent 提取和分类；人类处理不能自动裁决的冲突。 **输出：**带稳定编号、原文位置和后续去向的需求台账。
AI 在这里更像“编译器的前端”，而不是自由发挥的产品经理。按照当前规划合同，每个实质性陈述要被分类为：
- **硬性约束：**必须兼容 Windows；
- **目标设计：**希望增加手机查看入口；
- **现场事实：**当前已有局域网网关；
- **估算：**预计三天完成；
- **假设：**管理员会一直在线；
- **引用：**必须遵循某份现有安全规范；
- **权限边界：**开放版不得获得发布权限。
每一条还要保留原文行号、原句、强制程度、负责人、验收人，以及未来要进入的工作包、审批卡点、测试和证据。
本文中的 ADMIN 不是泛指维护服务器的系统管理员，而是拥有最终签发权的人类角色，例如技术负责人或被明确授权的安全审计负责人。
例如：
| 编号 | 原文位置 | 分类 | 可验收表达 | 后续去向 |
|---|---|---|---|---|
| REQ-0042 | 第 318—325 行 | 权限边界 | 开放版调用发布动作必须被拒绝 | WP-05、T-18、ADMIN 验收 |
| REQ-0043 | 第 326—331 行 | 现场事实 | 当前网关路径应先核验，不重复建设 | WP-01 基线检查 |
| REQ-0044 | 第 332 行 | 估算 | 三天只是待验证估算，不作为强制期限 | 预算与关键路径计算 |
如果一处写“手机可以直接发布”，另一处又写“开放版不得拥有发布权限”，AI 不得自行挑一句顺眼的留下。正确产物是一个阻断发现：列出最小冲突要求集合、影响和可选方案，然后停下来等 ADMIN 决定。
AI 可以发现矛盾，但不能替组织决定哪条红线失效。
第三步：生成施工图——从“要做什么”变成“怎样验收”
**输入：**需求台账、当前代码与运行环境事实。
**责任：**PM Agent 设计工作包；确定性脚本检查覆盖、依赖、预算与日程。 **输出：**工作包、先后依赖图、测试计划、证据要求、恢复与停止条件。
每个工作包至少写清：
- 满足哪些需求编号；
- 交给 DEV、QA 还是 OPS；
- 输入和具体交付物是什么；
- 允许和禁止修改哪些文件；
- 必须等哪些工作包完成；
- 要运行哪些测试，保存哪些证据；
- 由谁验收；
- 预算、返工上限和失败条件是什么；
- 失败后先保存什么，再怎样恢复或退回。
以“手机审批，但不得扩大开放版发布权限”为例，施工图可以长成这样：
WP-01 核验当前权限与网关基线
│ （完成后，基线结论成为下游工作的共同输入）
├──> WP-02 定义手机端只读与可写动作边界 ──┐
├──> WP-03 设计绑定版本与防重复的审批请求 ─┼──> WP-05 实现受控审批入口 ──> QA 独立验证
└──> WP-04 准备开放版权限回归测试 ───────┘这张图不是为了看起来像架构设计。它要接受程序检查：有没有一条硬要求没有去向；A 是否等待 B、B 又等待 A；两个并行工作包是否修改同一权威文件；预算总数是否等于各工作包之和；人工等待和外部冷却时间是否被错误算成 AI 工作日。
程序只负责算得出来的部分。它能发现环路和缺项，却不能决定原文中的一句话到底是硬要求还是愿望。语义判断仍由 AI 提议、由人复核。
第四步：程序校验与人工红灯——“没有发现漏洞”不等于“允许开工”
**输入：**完整规划中间结构、当前事实快照和渲染后的产品计划。
**责任：**CodeFlowMu 校验结构与绑定关系；ADMIN 作出业务决定。 **输出：**校验结果、当前权威计划版本、追加保存的审批决定。
CodeFlowMu 的长任务规划流程会检查需求覆盖、预算与日程、先后依赖、资源冲突、事实是否过期，以及实验、恢复和停止条件是否完整。校验通过后，系统形成一份自包含的当前产品计划，并把来源校验码、计划正文校验码和校验结果校验码绑定在一起。
随后才进入人工规划审批。批准记录必须绑定当前任务、对话、计划版本和正文、校验结果。需求或计划一旦变化，旧决定就变成过期记录，不能套用到新版本。
批准也不是“一键启动全部任务”。当前合同只允许打开 WP-00，也就是经过批准的第一步。后续工作仍要依据真实回执、依赖和新的风险逐步推进。
这能避免一个常见误区：程序证明依赖图无环，只说明计划内部没有发现这类结构错误；它没有替人类承诺预算，也没有替组织接受外部写入、发布或破坏性操作的风险。
程序校验回答“这张图是否自洽”，人工审批回答“我们是否愿意按这一版图迈出下一步”。
第五步：逐单派工与验收——执行者不能给自己盖章
**输入：**已批准的当前计划和允许开放的工作包。
**责任：**PM 派工，DEV / OPS 实现，QA 独立验证，PM 汇总，ADMIN 最终验收。 **输出：**正式任务、执行报告、测试证据、审查决定和生命周期记录。
PM 先通过正式入口写出任务，再显式唤醒下游 Agent。可立即执行的任务可以开工；有前置依赖的 QA 或 OPS 任务保持排队，直到上游产生有效的完成回执。
DEV 修改代码并运行实现相关测试；OPS 检查运行、交付和恢复路径；QA 在独立环境验证验收条件。执行者提交的是报告和证据，不是最终完成决定。只有下游真实交付、回执和验收完成后，PM 才能向 ADMIN 汇总最终交付。
失败也必须成为正式结果：测试未运行、环境缺包、依赖未满足、证据不足，都不能被绿色界面吞掉。报告至少要留下测试命令、退出码、关键输出、运行环境和对应任务版本。这样系统重启后才能依据工件恢复，而不是让新会话猜测上一次“可能做到哪了”。
FCoP 与 CodeFlowMu：一套写规矩，一套把规矩跑起来
读者最容易混淆的是：需求台账、工作包、任务文件和运行系统似乎都在“管理任务”，它们为什么不是一个东西？
FCoP：规定协作事实如何落成文件
FCoP 是基于文件的协作协议。它的核心心智是：文件承载协议，路径表示当前状态，事件留下迁移历史。
它规定正式任务、报告、问题和审查工件怎样命名和表达，任务怎样在 inbox → active → review → done → archive 的生命周期中移动，以及状态迁移怎样留下事件。
它不负责调用模型、计算关键路径、安排哪个 Agent 先工作，也不负责超时回收和故障恢复。这些属于运行系统或工作流层。
CodeFlowMu：负责规划、派工、会话和治理门禁
CodeFlowMu 是运行中的多 Agent 开发团队系统。它管理 PM、DEV、OPS、QA 的会话，执行长任务规划合同，运行确定性校验，维护先后依赖，派发任务，收集报告，并在需要人类授权时停下来。
需求台账、工作包和规划审批是 CodeFlowMu 叠加在 FCoP 之上的产品交付工作流，不是 FCoP 核心协议新增的文件类型。正式进入协作层时，CodeFlowMu 仍然使用 FCoP 的 TASK / REPORT / ISSUE / REVIEW 工件和生命周期。
两者的配合关系可以压缩成一张表：
| 环节 | FCoP 负责 | CodeFlowMu 负责 |
|---|---|---|
| 需求规划 | 不规定需求台账和工作包算法 | 读取长任务书，建立台账、工作包和依赖图 |
| 状态表达 | 规定任务文件、路径状态和迁移事件 | 观察状态并请求合法迁移 |
| 派工执行 | 不调用模型、不调度 Agent | 启动 PM / DEV / OPS / QA 会话并维护依赖 |
| 证据交接 | 规定报告、审查等协作工件 | 运行测试、收集结果并写入正式交付链 |
| 人工决定 | 让决定和交接留下可读工件 | 实施规划审批与具体高风险操作审批 |
| 故障恢复 | 提供当前状态与历史证据 | 依据工件、日志和运行策略重试、暂停或恢复 |
形象地说，FCoP 像建筑制图与公文规范；CodeFlowMu 像施工总包与现场调度系统。规范不负责搬砖，调度系统也不能绕过规范伪造交付。
这套方法最终得到什么效果？
它不能保证 AI 永远理解正确，也不能把概率模型变成传统编译器。但它能把原来含糊的失败，变成可以定位和复核的问题：
- **漏读可发现：**来源记录能显示是否到达全文末尾；
- **遗漏可追踪：**每条硬要求必须映射到工作包、测试、证据和验收人；
- **冲突不再被悄悄抹平：**阻断项必须交给有权的人决定；
- **并行边界可检查：**依赖图和文件范围能暴露循环等待与同时写入；
- **批准不会跨版本漂移：**来源或计划变化会让旧批准失效；
- **完成不再是自我声明：**实现、验证和最终决定由不同角色承担；
- **失败后有恢复依据：**新会话可以读取任务、报告、事件和证据，而不是重新猜测。
真正的效果不是“AI 更像人”，而是团队终于可以回答：哪条要求出了问题、哪一步没有证据、谁有权作决定、现在应该从哪里继续。
哪些情况不值得这样做？
一个熟悉模块里的三行修复，不需要先建立完整需求台账和工作包图。CodeFlowMu 当前也只对明确要求长期规划的任务，或超过一定长度、同时涉及多个模块、审批、恢复、实验与预算信号的复杂任务启用这套重流程。
这套方法同样不能消除模型幻觉。全文读取记录不等于理解证明；确定性脚本只能检查结构，不能替代语义判断；文件和 Git 记录也不天然等于完整审计链。跨机、网络文件系统和多写者环境还需要额外一致性层，不能把本地文件语义泛化为分布式保证。
因此，它最适合的不是所有任务，而是要求多、周期长、角色多、失败代价高，并且需要留下验收证据的工程交付。
开工前的十项检查
- 原文版本、行数、校验码和全文读取范围是否已记录？
- 每条硬要求能否回到准确的原文位置？
- 硬要求、目标、事实、估算、假设和权限边界是否分开？
- 冲突是否被明确阻断，而不是由 AI 静默裁决？
- 每条要求是否映射到工作包、测试、证据和验收人？
- 先后依赖是否无环，并行任务是否避免同时写权威工件？
- 预算和日程是否从工作包向上求和，而不是先定日期再硬塞？
- 程序校验和人工批准是否被当成两个不同动作？
- 批准是否绑定当前版本，变化后是否自动过期？
- 执行报告是否包含可复核的命令、退出码、输出和环境？
如果这十项都能回答，两万字就不再是一团只能交给模型“自由理解”的文本，而是一条人和 AI 都能检查、暂停、恢复和验收的工程链。