ARTICLE · 986422
我现在写需求文档,已经不是给人看的,而是给AI执行的
上一篇讲了 AI 开发的第一步：别急着写代码，先拆需求。
这一篇继续往下走。
需求拆清楚以后，不能只停留在脑子里，也不能只写成一段“人看得懂”的说明。
因为现在你的需求文档，不只是给产品、开发、测试看的。
它还要给 AI 看。
更准确地说，它要能被 AI 执行。
我这两年最大的变化之一，就是写需求文档的方式变了。
以前我写需求文档，更多是在写“说明书”：
这个功能是什么；
页面上有什么；
用户怎么操作；
大概有哪些规则。
现在我写需求文档，会更像写“施工图”：
模块边界是什么；
输入输出是什么；
接口约束是什么；
哪些情况不能发生；
怎么验证它做对了。
这不是为了把文档写得更正式。
而是为了让 AI 少猜、少补、少乱改。
一、给人看的需求，AI不一定能执行
很多传统需求文档，给人看没问题。
比如：
系统支持客户跟进管理。销售可以维护客户资料、记录沟通情况，主管可以查看团队客户进展，并对长期未跟进客户进行提醒。
这段话，人能理解。
但如果你把它直接丢给 AI 写代码，问题就来了。
销售可以维护哪些资料？
客户资料哪些字段必填？
销售能不能看别人的客户？
主管能看所有客户，还是只能看自己团队？
长期未跟进是几天？
提醒是页面提示、消息通知，还是待办列表？
跟进记录能不能删除？
客户成交后还能不能修改？
这些都没写。
对人来说，大家可以开会补充、口头解释、边做边问。
但对 AI 来说，它会直接开始猜。
它猜得越多，代码越像一座没有图纸的房子：看起来有墙有门，真住进去才发现水电都不对。
所以我现在判断一份需求文档能不能给 AI 用，只看一个标准：
它能不能直接变成任务、接口、测试和验收。
不能，就还不够。
二、AI可执行PRD，第一件事是写清楚目标和边界
写 AI 可执行 PRD，不是上来就堆细节。
第一步反而要先收住范围。
我一般会在文档开头写四件事：
这个功能解决什么问题；
这版做什么；
这版不做什么；
做到什么程度算可上线。
比如客户跟进系统，可以这样写：
本版本解决销售客户跟进记录分散、主管无法及时查看进展的问题。第一版只支持客户录入、客户归属、跟进记录、今日待跟进、主管查看团队进展。第一版不做线索评分、不做微信通知、不做复杂报表、不做自动分配。上线标准是：销售能完成客户录入和跟进闭环，主管能看到团队客户状态和超期未跟进客户。
这一段很重要。
它给 AI 画了边界。
很多时候，AI 写乱不是因为它不会写，而是因为你没告诉它哪些不要写。
“不做什么”在 AI 开发里特别关键。
你不写，它可能顺手加标签、加图表、加消息队列、加权限模型、加未来扩展字段。
看起来很勤快，实际上是在制造复杂度。
三、模块说明要写成“职责边界”，不要只写功能列表
很多需求文档会写功能列表：
客户管理；
跟进管理；
团队管理；
提醒管理。
这个列表太粗。
AI 看到后，还是不知道每个模块该管什么、不该管什么。
我现在写模块说明，会重点写三项：
模块职责；
输入输出；
不负责的事情。
比如“客户模块”可以这样写：
客户模块负责客户基础资料的创建、查询和归属管理。输入包括客户姓名、手机号、来源、负责人、初始状态。输出包括客户详情、客户列表、客户当前负责人、客户当前状态。客户模块不负责生成跟进提醒，不负责统计销售业绩，不负责发送通知。
再比如“跟进模块”：
跟进模块负责记录销售与客户的沟通内容，以及维护下次跟进时间。输入包括客户ID、跟进内容、跟进方式、下次跟进时间。输出包括客户跟进记录列表、最后跟进时间、下次跟进时间。跟进模块不负责修改客户归属，不负责成交审批。
这样写的好处是，AI 开始生成代码时，不容易把职责揉在一起。
客户模块就是客户模块。
跟进模块就是跟进模块。
提醒模块就是提醒模块。
边界越清楚，后面越好维护。
四、接口约束要比接口地址更重要
很多人写接口文档，只写这几项：
接口地址；
请求方式；
请求参数；
返回字段。
这当然需要，但还不够。
给 AI 执行的接口说明，必须写约束。
也就是：
谁能调用；
调用前必须满足什么条件；
调用后会改变什么数据；
什么情况下必须失败；
重复调用会不会产生副作用。
比如“新增跟进记录”接口，不能只写：
POST /customers/{id}/follow-ups参数：content、nextFollowAt
我会写成这样：
接口：新增跟进记录使用角色：客户负责人销售前置条件：客户存在，且当前用户是客户负责人请求参数：客户ID、跟进内容、跟进方式、下次跟进时间数据变化：新增一条跟进记录，同时更新客户最后跟进时间和下次跟进时间失败场景：客户不存在、当前用户不是负责人、跟进内容为空、下次跟进时间早于当前时间幂等要求：重复提交不能产生多条完全相同的跟进记录，前端或后端至少要有一种防重复机制
你看，这段比单纯接口地址长。
但它对 AI 非常有用。
因为代码里真正容易错的，往往不是 URL 怎么写，而是权限、状态、失败场景和数据变化。
接口约束写清楚，AI 才知道哪里不能省。
五、边界条件要单独写，不要指望AI自己补全
我现在写 PRD，一定会单独放一节：边界与异常。
原因很简单：正常流程最容易写，异常流程最容易漏。
客户跟进系统里，至少要写这些边界：
手机号重复时，不允许创建两个客户；
销售只能查看自己负责的客户；
主管只能查看自己团队的数据；
已成交客户不能被普通销售删除；
跟进内容不能为空；
下次跟进时间不能早于当前时间；
客户转移负责人后，旧负责人不能继续编辑；
客户不存在时，接口返回明确错误；
重复提交跟进记录时，不能产生重复数据。
这些内容看起来琐碎。
但这就是业务系统的骨头。
没有它，代码很容易只是“能跑”。
有了它，代码才开始接近“能用”。
我常用这个提示让 AI 帮我补边界：
请基于当前 PRD，站在测试和线上故障排查角度，列出容易漏掉的边界条件。按权限、状态、数据唯一性、时间、重复提交、删除与撤销、异常返回分组。只列第一版必须处理的边界，不扩展未来功能。
这个提示非常适合老程序员用。
因为 AI 列出来之后，你可以快速判断哪些是真风险，哪些是过度设计。
六、验收用例要写到“能执行”
很多需求文档的验收标准是这样的：
系统功能正常；
页面展示正确；
权限控制准确；
数据保存成功。
这类话，看起来像验收，实际上没法验收。
因为它没有告诉你怎么测。
我现在写验收用例，会尽量写成这种格式：
前置条件：销售A已登录，系统中不存在手机号为 13800000000 的客户。操作步骤：销售A创建客户，填写姓名“张三”、手机号“13800000000”、来源“展会”。预期结果：创建成功；客户列表出现张三；客户负责人为销售A；客户状态为“跟进中”。
再比如权限场景：
前置条件：客户张三负责人为销售A，销售B已登录。操作步骤：销售B访问张三客户详情。预期结果：系统拒绝访问，返回无权限提示；客户数据不被修改。
再比如异常场景：
前置条件：系统中已存在手机号为 13800000000 的客户。操作步骤：销售A再次用同一手机号创建客户。预期结果：创建失败，提示客户已存在；数据库不新增客户记录。
这样的验收用例，AI 能直接拿来生成测试。
开发也能照着做。
测试也能照着验。
这就是“给 AI 执行”的意思。
不是把文档写得更长，而是把文档写到可操作。
七、我常用的AI可执行PRD模板
如果你想直接套，可以用下面这份模板。
以后写需求时，先不要让 AI 写代码，让它按这个格式帮你整理。
我有一个需求：【这里写你的原始想法】
先不要写代码。请把它整理成一份 AI 可执行 PRD，结构如下：
目标与范围
解决什么问题 第一版做什么 第一版不做什么 可上线标准是什么
用户与场景
涉及哪些角色 每个角色在什么场景下使用 每个角色完成什么任务
模块说明
模块名称 模块职责 输入 输出 不负责的事情
数据结构
核心对象 关键字段 必填项 唯一约束 状态字段 对象关系
接口约束
接口名称 使用角色 前置条件 请求参数 返回字段 数据变化 失败场景 幂等要求
边界与异常
权限边界 状态边界 数据重复 时间限制 删除与撤销 异常返回
验收用例
正常场景 权限场景 异常场景 数据一致性场景每条用例都按“前置条件 / 操作步骤 / 预期结果”输出。
要求：只写第一版必须上线的内容；不扩展未来功能；不确定的规则单独列为“待确认问题”；不要写代码。
这份模板的价值，不在于格式漂亮。
而在于它能把一个模糊需求，变成 AI 可以继续执行的工作输入。
下一步你就可以继续让 AI 做：
根据这份 PRD 生成数据库表设计；
根据接口约束生成 OpenAPI 草稿；
根据验收用例生成测试用例；
根据模块说明拆开发任务；
根据边界条件检查代码风险。
这时 AI 的输出会稳定很多。
因为它不是在猜你要什么，而是在按你的规则施工。
八、写给AI的文档，越少形容词越好
最后补一个很实际的经验。
给 AI 写需求，少用形容词，多用约束。
比如这些话，对 AI 的帮助很有限：
界面要高级；
流程要顺畅；
权限要严格；
数据要准确；
系统要稳定。
不是不能写，而是太虚。
你要把它们翻译成可执行描述：
“高级”可以改成：页面只保留列表、筛选区、详情抽屉，不做大面积装饰。
“顺畅”可以改成：新增客户成功后，留在当前列表页，并高亮刚新增的记录。
“权限严格”可以改成：销售只能查询 owner_id 等于自己的客户，主管只能查询 team_id 等于自己团队的客户。
“数据准确”可以改成：新增跟进记录后，客户表 last_follow_at 必须同步更新。
“系统稳定”可以改成：重复提交同一条跟进记录时，不允许生成两条相同记录。
这就是 AI 可执行 PRD 的核心：
少一点感觉，多一点条件。
少一点描述，多一点输入输出。
少一点“应该”，多一点“必须”。
结尾
以前写需求文档，很多时候是为了让人达成共识。
现在用 AI 开发，需求文档还多了一个作用：让 AI 能按你的意图执行。
所以我现在不太追求文档写得漂亮。
我更在意它能不能回答这些问题：
边界清不清楚？
模块职责清不清楚？
接口约束清不清楚？
异常情况清不清楚？
验收用例能不能执行？
如果这些都清楚，AI 写代码就会稳很多。
如果这些不清楚，再好的提示词也只是让它更快地猜错。
下一篇，我会讲一个更容易踩坑的话题：
AI写代码很快，但你不懂架构，它只会更快地制造技术债。
需求文档能约束“做什么”，架构边界决定“怎么做才不乱”。