用AI-DLC三阶段法把业务想法变成可执行开发计划

做完这篇教程，你会拿到一份由AI生成、你自己逐条确认过的详细需求文档和可分配的工作单元清单——不是模糊的“做个智能客服”，而是像“用户输入‘查订单’时，调用订单API并返回最近3条记录”这样颗粒度明确

做完这篇教程，你会拿到一份由AI生成、你自己逐条确认过的详细需求文档和可分配的工作单元清单——不是模糊的“做个智能客服”，而是像“用户输入‘查订单’时，调用订单API并返回最近3条记录”这样颗粒度明确的任务。整个过程约需1.5小时（我上周帮一家电商老板实操耗时87分钟），适合不懂技术但必须推动项目的中小公司老板或产品负责人。如果你已经有现成PRD或技术团队在跑Scrum，这篇对你冗余；但如果你正卡在“想法很清晰，就是不知道怎么让程序员动手”，现在做最划算——因为AI-DLC的核心是把人类验证嵌入每个决策点，避免后期返工烧钱。

把你的业务意图喂给AI，让它追问到无法再模糊为止

打开你常用的AI对话工具（Claude、Copilot、Qwen都行），粘贴这段提示词：

你正在扮演AI-DLC方法中的Inception阶段协作者。我的初始业务意图是：[在此插入你的原始想法，例如“我想做个AI客服，能自动回答客户问题”]。

请按以下规则执行：
1. 先将我的意图拆解为3-5个核心目标；
2. 对每个目标，列出至少3个必须澄清的问题（聚焦用户身份、触发条件、成功标准）；
3. 不要直接给解决方案，只提问；
4. 输出格式：【目标1】... 【问题】... 【问题】...

比如我替一位宠物店老板输入“想做个AI客服”，AI立刻追问：“目标用户是已购客户还是访客？是否需要区分猫粮和狗粮咨询？回答错误时是否有兜底转人工机制？”——这才是有效澄清。为什么这步不能跳？因为AI-DLC的根基是“AI提问→人拍板→AI推进”，跳过追问等于让AI猜你的生意逻辑。做完这步，你应该看到一份带编号的问题清单，而不是一段漂亮但空洞的方案描述。翻车点：别把“提升用户体验”这种虚词当目标，AI会跟着你一起飘；必须逼它落到具体行为，比如“老客户3秒内查到上次购买的猫砂型号”。

组织15分钟“Mob Elaboration”快闪会，当场确认答案

拉上你最懂业务的人（不一定是技术岗，可以是客服主管或销售），对着AI刚提的问题逐条回答。每答完一条，立刻让AI更新需求草案。操作示例：

你对AI说：“目标用户是已下单客户，通过微信服务号接入；不需要区分猫狗粮，但要识别是否问售后；错误回答必须有‘转人工’按钮。”

然后命令AI：

基于以上确认，生成结构化需求文档，包含：
- 用户角色（Role）
- 触发场景（When）
- 系统动作（Action）
- 验收标准（Expected Result）
每条独立编号，例如 REQ-01。

这时你会得到类似这样的输出：

REQ-01
Role: 已购客户
When: 在微信服务号输入“订单状态”
Action: 调用订单系统API，返回最近一笔订单的物流进度
Expected Result: 客户收到含快递单号和预计到达时间的消息

为什么必须现场确认？因为AI-DLC要求每个工件可追溯、可复用——这些REQ编号会直接流入下一阶段的开发任务。做完这步，你手里的文档应该每条都带编号、无歧义、可测试。翻车点：别让AI自己补全“默认逻辑”，比如“如果查不到订单怎么办”——这种边界情况必须你当场定义，否则Construction阶段会崩。

让AI把需求条目转成带优先级的工作单元清单

现在给AI最后一道指令，把需求文档翻译成开发团队能认领的任务：

将上述REQ-XX条目转换为工作单元（Work Items），要求：
1. 每个工作单元对应一个可独立交付的功能点；
2. 标注依赖关系（如“需先完成用户鉴权模块”）；
3. 按MoSCoW法则标记优先级（Must/Should/Could/Won't）；
4. 输出格式：[ID] [Priority] [Description] | Depends on: [...]

你会得到类似：

WI-01 Must 实现微信消息接入与用户身份绑定 | Depends on: 无
WI-02 Must 开发订单查询API适配器 | Depends on: WI-01
WI-03 Should 添加“转人工”按钮及路由逻辑 | Depends on: WI-01

为什么这步决定项目生死？中小团队资源有限，Must项超过5个就该警惕范围蔓延——我见过太多老板因没卡住WI数量，最后花10万做了个半成品。做完这步，你的清单里Must项应≤5个，且每个都源自你亲手确认的REQ。翻车点：AI可能把“优化响应速度”这种非功能需求塞进工作单元，直接删掉——Inception阶段只处理明确的行为需求。

到这里，你已经有了：一份带编号的需求文档（REQ-XX）、一份带依赖和优先级的工作单元清单（WI-XX）。这两份文件就是AI-DLC Inception阶段的交付物，后续Construction阶段工程师会基于它们生成代码方案。换个场景怎么改？如果你做的是内部工具（比如“自动生成周报”），把提示词里的“用户角色”改成“使用部门”，“验收标准”改成“节省多少人工时”即可，其他流程不变。

十页的提醒：我最初以为让AI写需求能省时间，结果第一次没做Mob Elaboration，AI把“客户能查订单”理解成开放所有历史订单——差点引发数据泄露。从此我坚持所有业务意图必须经过人类闸口，哪怕多花15分钟。

完成自检

  • 需求文档中每条REQ都有明确的用户角色、触发条件、系统动作、验收结果四要素
  • 工作单元清单里的Must项不超过5个，且每个都能回溯到某个REQ编号
  • 所有依赖关系标注具体（如“Depends on: WI-02”而非“需后端支持”）
  • 文档中不存在“智能”“高效”“友好”等不可测量的形容词

素材来源

本文由十页AI从以下原始素材延展整理：

← 更多文章 · 加入十页AI学院