从一句想法写成 AI 能执行的开发任务书

把一句想法改写成可验收的用户流程

“做一个管理系统”没有用户、场景、动作、状态和完成标准。开发任务书先说明谁为什么来、要走完什么流程、成功和失败时看见什么，再谈技术栈。

定义用户和问题

写一个主要用户、真实场景、当前做法和最痛的阻塞，不用“所有人都能用”。

把涉及的文件、目录、版本、命令和实际输出写进记录；代码变化同时保留 diff 与测试结果。

写主流程与状态

按用户动作列入口、页面、数据、成功、空、加载、错误、权限和重复提交状态。

确认“写主流程与状态”已经有可回查结果，再进入“确定数据和边界”；依据仍然来自猜测时，把缺口单列并停在当前步骤。

确定数据和边界

列实体、必填字段、来源、保留时间、隐私、外部接口和明确不做事项。

确认“确定数据和边界”已经有可回查结果，再进入“切出最小交付”；依据仍然来自猜测时，把缺口单列并停在当前步骤。

切出最小交付

只保留能闭环的纵向切片，视觉增强、后台配置和自动化按价值推迟。

确认“切出最小交付”已经有可回查结果，再进入“为每项写验收证据”；依据仍然来自猜测时，把缺口单列并停在当前步骤。

为每项写验收证据

使用可运行步骤、测试、截图和数据结果，避免“功能完善”“体验良好”等不可检查措辞。

需要修改时先限定文件和行为范围，无法说明回滚方式或影响面的动作先不执行。 完成后把证据归入“产品任务书”。

任务书应允许开发者指出缺口

读完后能回答用户、流程、状态、数据、约束、范围外和验收。仍需猜的地方列问题并停止编码，不让 AI 自行选择关键产品规则。