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

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

标题备选

• 复杂任务别让 AI 直接开写
• 从一句需求到可验收产物，AI 应该这样走流程
• ACW 不是目录，而是一条可检查的任务链路

开场钩子

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

没有流程时，AI 很容易从一句需求直接跳到最终输出。

小任务没问题，但复杂任务这样做，返工概率非常高。

正文口播

比如你说：帮我写一本 1.5 万字的专业书。

如果 AI 立刻开始写正文，它可能会忽略读者定位、章节结构、术语边界、已有材料、最终文件位置。

等正文写完，你再发现方向不对，成本就很高。

一个更稳的流程是：

raw-input、requirements、structure、writing-spec、drafting、review、submission。

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

raw-input 保存原始输入。

原始输入很重要，因为它保留了用户最初怎么说。

整理后的需求可能更清楚，但也可能丢失语气、重点和限制。

保存原始输入，可以在后续发生争议时回看源头。

写作任务中，它可以是用户需求、素材、直播文本、参考目录说明。

软件任务中，它可以是 issue、报错日志、需求描述、用户反馈。

requirements 提炼任务要求。

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

很多 AI 输出失败，不是写作能力不足，而是需求没有被拆清楚。

structure 设计结构。

写书要目录，写文章要论证路径，写软件要模块设计，做研究要分析框架。

结构阶段的目标，是先确定骨架，再进入生产。

你审一份目录，比审一万字正文容易得多。

你审一个接口设计，比审几千行代码容易得多。

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

这里包括语气、格式、术语、素材使用、禁区、目标文件、质量标准。

如果是软件任务，它可以叫 implementation spec，写明修改范围、技术方案、测试要求和兼容性边界。

drafting 是起草或实现。

这是最容易被看见的阶段，但它不应该孤立存在。

好的 drafting 应该响应前面的需求、结构和规格。

review 是审校或验证。

复杂任务不能只生成，不检查。

写作要看结构、事实、风格、连续性、敏感风险。

代码要跑测试、看边界、看回归。

方案要检查目标、约束、证据、风险。

AI 参与 review 时，最好让它输出具体问题，而不是泛泛地说整体不错。

好的审校报告应该指出位置、问题、影响和建议。

submission 是交付准备。

当成果要投稿、发布、提交、上线、交付客户时，就需要准备标题、摘要、版本说明、邮件、发布清单、变更说明。

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

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

小任务可以直接处理。

中等任务可以只做需求和草稿。

复杂任务才需要完整 artifact。

真正成熟的工作区，应该让简单任务快，让复杂任务稳。

结尾引导

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

如果 AI 直接给最终答案，你只能判断答案好不好。

如果它同时保留需求、结构、规格和审校，你就能判断它为什么这样做。

下一集，我们用写作工作区举例，看 ACW 怎么迁移到不同领域。