从需求到落地：我用 AI 协作完成设计文档的七步工作流

把需求和模板交给 AI，不到一分钟就能得到一份章节齐全、措辞专业的设计文档。但当它进入评审，问题往往才真正出现：

文档里多了一个现实中并不存在的服务；
原本留给评审的技术选型，被写成了已经确定的结论；
监控、容量和排期看起来面面俱到，却没有一项经过现有系统验证；
每一章单独看都合理，放在一起却前后矛盾。

问题不在于 AI 不会写，而在于它降低了“写出来”的成本，却没有降低“想清楚”的成本。一份设计文档是否可落地，最终仍取决于人有没有把边界、事实、取舍和风险讲清楚。

经过多次实践，我把人和 AI 的协作过程整理成了七步：

这不是一条只能向前走的流水线。检查发现问题时，要敢于退回前面的步骤重新收敛。它也不是一套 Prompt 技巧：判断与取舍始终由人负责，扩展与校验才交给 AI。

第一步：明确需求边界

第一步的产出不是文档，而是共识。至少要回答四个问题：

这项需求服务于什么业务目标？
用户或系统从哪里进入，在哪里结束？
涉及哪些核心实体，它们之间是什么关系？
哪些内容明确不在本次范围内？

很多人会在这一步直接讨论字段类型、接口格式或中间件。框架尚未确定时，这些细节很容易随着边界变化而全部推倒。

我更习惯先整理一份边界清单：

类型	要记录的内容
已确认	有明确需求或现有实现作为依据的事实
不做	本次明确排除的功能和场景
待确认	需要产品、业务或技术评审决定的问题
暂时假设	为了继续讨论而采用、但尚未验证的前提

这时 AI 最适合扮演“反方参谋”。不要急着让它给方案，而是让它从异常流程、权限边界、数据生命周期、并发冲突和后续扩展等角度反问。人再根据业务目标决定：哪些问题现在解决，哪些推迟，哪些根本不属于本次需求。

第二步：按模板初步填充

边界有了以后，可以让 AI 按团队模板生成第一版。

这一版追求的是覆盖率，而不是正确率。章节都被填出来，才能尽早暴露数据库、接口、业务流程、配置、容量、测试和排期中尚未解决的问题。相比只写好前三章，一份“不完整但问题都可见”的全篇草稿更利于继续推进。

不过，初稿必须把不同可信度的内容区分开：

已确认事实：可以追溯到需求、代码、文档或讨论结论；
方案建议：AI 根据上下文提出，尚未经过人确认；
信息缺口：当前没有依据，不能用通用经验补成事实；
不适用章节：与本需求无关，应说明后删除，而不是为了模板完整而硬填。

AI 很擅长写出“通常合理”的内容，但“通常合理”不等于“在当前系统中成立”。让假设显式可见，是避免一份漂亮初稿被误当成定稿的关键。

第三步：逐章深化

第一版不可靠是正常现象，因为模板不知道这项需求真正难在哪里。

有的需求重点在数据一致性，有的重点在并发性能，有的重点在运营配置。逐章处理前，可以先给章节标记重要度：

高：直接影响核心链路、数据正确性或上线风险，需要深入拆解；
中：有明确实现方式，但仍需验证与其他模块的关系；
低：对本次需求影响有限，快速确认即可。

每一章都重复检查四类内容：

事实：现有系统真实是什么样；
决策：本次准备采用什么方案，为什么；
未知：还有哪些信息没有确认；
影响：该决定会改变哪些接口、数据、流程和测试。

人的任务是提供真实业务和系统信息，AI 的任务是基于这些信息重写、展开和提出遗漏。如果 AI 无法指出一段内容的依据，就应把它降级为“待确认”，而不是继续润色得更像事实。

逐章深化也不意味着保留模板的所有章节。删除与需求无关的套话，往往比补齐它们更专业。与此同时，如果深化暴露出模板没有覆盖的核心问题，就应该新增章节，再单独走一遍拆解和检查。

第四步：做全文一致性检查

随着思考深入，方案一定会演进。前面章节可能还停留在旧版本，后面章节已经使用新结论。这不是写作事故，而是思考深化的副产品。

人通读长文时容易被“局部合理”迷惑，AI 则很适合机械地扫描全篇：

检查维度	常见问题
术语	同一概念有多个名字，或同名词在不同章节含义不同
方案	前文说同步处理，后文却按异步流程设计
数据	字段、枚举、状态、主键和关系在各处定义不一致
顺序	后文依赖的概念，在前文从未定义
约束	容量、性能和一致性目标与实现方式互相冲突

让 AI 输出“位置、冲突内容、影响、建议修改方向和判断依据”，不要直接让它静默改全文。真正决定以哪个版本为准、是否需要调整架构，仍然是人的责任。

第五步：以第一次阅读的视角重排

写作顺序通常是“想到哪里写到哪里”，阅读顺序却应该符合建立认知的过程：

为什么做 → 用户看到什么 → 系统里有什么 → 各部分如何协作 → 具体如何实现

一个常见错误是过早展示字段和接口。读者还不知道系统整体要解决什么问题，就已经被带进某张表的细节里，后续只能不断回看前文。

通读时，我会假设自己是第一天接触这个需求的人，每遇到一个概念就问：

它在前面定义过吗？
我知道它为什么存在吗？
我知道它和其他实体或模块的关系吗？
读到这里，我是否具备理解下面细节所需的全部信息？

文档不是作者思考过程的录像。必要时应移动、合并甚至重写章节，把“作者能看懂”变成“没有上下文的读者也能看懂”。

第六步：用不同上下文交叉审查

长期参与写作的 AI 会继承大量上下文，也可能不自觉地维护自己参与形成的方案。因此定稿前，我会把文档交给不同视角审查：

有完整上下文的 AI：检查文档是否偏离已经确认的边界和决策；
无上下文的新会话：模拟第一次阅读的人，检查文档能否自洽；
特定领域视角：分别从数据、接口、安全、测试或运维角度攻击方案。

“帮我审查一下”通常只会得到泛泛的优点和建议。更有效的方式是限定目标：只找会导致实现歧义、数据错误、上线风险或无法验收的问题，并要求给出原文依据。

对于审查结果，可以这样处理：

多个视角都指出的问题，优先级最高；
只有一个视角指出的问题，先核对事实再决定；
没有依据、只表达偏好的建议，不必为了“更完备”而采纳；
发现重大结构缺陷时，回到第三步，而不是在原文上打补丁。

AI 的审查结果是线索，不是判决。

第七步：接受有边界的不完美

AI 倾向于把所有边界情况、扩展能力和防御设计一次性塞进方案。如果照单全收，最常见的结果不是“更稳”，而是排期失控和复杂度提前到来。

“完美”不是设计文档的目标，风险已知且可管理才是。对于暂时不解决的问题，至少回答三个问题：

问题	需要记录的内容
为什么现在这样做？	排期、资源、优先级、规模或依赖等依据
这样做有什么风险？	可能失败的场景，以及影响范围
什么时候必须重新处理？	可观察、可判断的触发条件

例如，首个版本可以暂时不建设通用扩展层，但要写清楚：当前只有单一调用方；新增第二类调用方时，现有耦合会阻碍演进；当外部消费者出现，就必须重新抽象边界。

这种“不完美”不是被遗忘的技术债，而是一项有依据、有风险说明、有触发条件的工程决策。

一份可直接执行的最小清单

如果不想一开始就使用完整流程，可以先从下面这份清单开始：

用一句话写清业务目标；
列出“做、不做、待确认、暂时假设”；
让 AI 按模板铺出全篇，但明确标注事实与假设；
按章节重要度逐一补充真实信息；
扫描术语、方案、数据、顺序和约束是否一致；
用无上下文的新会话检查文档能否独立读懂；
为保留的风险补上决策依据、影响和触发条件。

这七项完成后，文档才算从“内容很多”走到了“另一个人可以照着执行”。

最后的判断标准

一份设计文档的终点不是写完，也不是评审会上没有人提问，而是：

实现者知道要做什么，也知道什么不做；
评审者能追溯关键结论的依据；
测试者知道什么结果算完成；
后来接手的人能看见当时的取舍与风险；
没有作者口头补充，文档仍然能够独立成立。

归根结底，人机分工可以浓缩成一句话：

AI 负责发散、补全和找茬，人负责边界、取舍和裁决。方向盘始终在人手里。