第七章：任务流程：从一句需求到可验收产物

ACW 不只是静态目录，还需要任务流程。

没有流程时，AI 容易从一句需求直接跳到最终输出。对于小任务，这没有问题。你让它改一个错别字、优化一句标题、解释一个概念，直接回答就是最高效的做法。

但对于复杂任务，直接跳到最终输出往往会制造返工。

比如你说：“帮我写一本 1.5 万字的专业书。”如果 AI 立刻开始写正文，它可能会忽略读者定位、章节结构、术语边界、已有材料、最终文件位置。等正文写完，你再发现方向不对，成本就很高。

一个更稳的流程是：

raw-input → requirements → structure → writing-spec → drafting → review → submission

这条链路来自写作场景，但可以迁移到很多领域。

raw-input 保存原始输入。

原始输入很重要，因为它保留了用户最初怎么说。整理后的需求可能更清楚，但也可能丢失语气、重点和限制。保存原始输入，可以在后续发生争议时回看源头。

在写作任务中，raw-input 可以是用户需求、素材、直播文本、参考目录说明。软件任务中，它可以是 issue、报错日志、需求描述、用户反馈。咨询任务中，它可以是客户访谈记录和原始资料。

requirements 提炼任务要求。

它回答：这次到底要做什么？目标是什么？读者是谁？字数范围是多少？验收标准是什么？事实边界在哪里？哪些问题必须确认？

需求提炼的价值，是把一句自然语言请求变成可执行任务。很多 AI 输出失败，不是写作能力不足，而是需求没有被拆清楚。

structure 设计结构。

写书要目录，写文章要论证路径，写软件要模块设计，做研究要分析框架。结构阶段的目标，是先确定骨架，再进入生产。

结构不是为了拖慢速度，而是为了让人类能用更低成本检查方向。你审一份目录，比审一万字正文容易得多。你审一个接口设计，比审几千行代码容易得多。

writing-spec 或执行规格，定义如何写、如何做。

这里包括语气、格式、术语、素材使用、禁区、目标文件、质量标准。对于软件任务，它可以叫 implementation spec，写明修改范围、技术方案、测试要求和兼容性边界。

规格的价值，是把“我大概知道要什么”变成“AI 可以按这个标准执行”。

drafting 是起草或实现。

这是最容易被看见的阶段，但它不应该孤立存在。好的 drafting 应该响应前面的需求、结构和规格。写作时，它生成正文；开发时，它修改代码；研究时，它形成报告；运营时，它产出内容计划。

review 是审校或验证。

复杂任务不能只生成，不检查。写作要看结构、事实、风格、连续性、敏感风险。代码要跑测试、看边界、看回归。方案要检查目标、约束、证据、风险。

AI 参与 review 时，最好让它输出具体问题，而不是泛泛地说“整体不错”。好的审校报告应该指出位置、问题、影响和建议。

submission 是交付准备。

并非所有任务都有这个阶段。但当成果要投稿、发布、提交、上线、交付客户时，就需要准备标题、摘要、版本说明、邮件、发布清单、变更说明等。

这条流程并不是每次都要完整执行。

ACW 的关键不是机械套模板，而是根据风险选择流程重量。

小任务可以直接处理。中等任务可以只做需求和草稿。复杂任务才需要完整 artifact。真正成熟的工作区，应该有分流机制：让简单任务快，让复杂任务稳。

任务流程还有一个隐藏价值：它让 AI 的工作可检查。

如果 AI 直接给你最终答案，你只能判断答案好不好。如果它同时保留需求、结构、规格和审校，你就能判断它为什么这样做。你可以在上游纠偏，而不是只在下游返工。

流程不是为了约束创造力，而是为了把创造力放在可控轨道上。