浏览 AI 知识库
AI 开发需求文档怎么写：把一句想法变成可验收任务书
“做一个客户反馈系统”还不是可以开发的需求。谁来提交、谁来处理、有哪些状态、什么算关闭，都要先写成可验证的规则。
沿完整工作流推进
前一阶段的可检查结果，是下一阶段的输入；中间证据不足时停在当前阶段。
一句产品想法，距离可开发的任务书还缺什么
需求只有一句“做一个客户反馈系统”。AI 立刻列登录、看板、通知和导出，没人说明谁提交、谁处理、何时算关闭。
- 用户、任务和结果明确
- 主流程与异常都可验收
- 不做事项和未决问题已记录
先确认这次任务的起点、边界和交付
| 需要确认 | 本例内容 |
|---|---|
| 现有材料 | 首期用户为客服和产品经理；已有企业登录；必须先支持反馈提交、状态处理和历史查询。 |
| 不能越过的边界 | 先写用户任务、主流程、异常和验收；首期不做公开社区、积分和自动情绪判断。 |
| 要交付的结果 | 产品任务书 |
从“定义用户和问题”走到“为每项写验收证据”
| 当前阶段 | 实际处理 |
|---|---|
| 定义用户和问题 | 写一个主要用户、真实场景、当前做法和最痛的阻塞，不用“所有人都能用”。 |
| 写主流程与状态 | 按用户动作列入口、页面、数据、成功、空、加载、错误、权限和重复提交状态。 |
| 确定数据和边界 | 列实体、必填字段、来源、保留时间、隐私、外部接口和明确不做事项。 |
| 切出最小交付 | 只保留能闭环的纵向切片，视觉增强、后台配置和自动化按价值推迟。 |
| 为每项写验收证据 | 使用可运行步骤、测试、截图和数据结果，避免“功能完善”“体验良好”等不可检查措辞。 |
把‘做一个报销系统’收窄成一条可交付流程
| 字段 | 本例设定 |
|---|---|
| 用户 | 员工提交一笔不超过 5000 元的差旅报销 |
| 输入 | 日期、金额、发票图片、费用类型；金额必须为正数 |
| 主流程 | 新建 -> 上传发票 -> 保存草稿 -> 提交 -> 查看审批状态 |
| 关键状态 | 上传中、解析失败、草稿、已提交、退回补充、已通过 |
| 不做 | 多币种、批量导入、自动付款和管理员规则编辑 |
| 完成证据 | 测试账号完成一笔提交；每个错误状态有可见提示；刷新后状态不丢 |
验收句子要写动作和可观察结果
| 场景 | 动作 | 预期 | 失败判定 |
|---|---|---|---|
| 空金额 | 点击提交 | 字段旁提示金额必填，不发提交请求 | 只弹通用错误或仍创建记录 |
| 发票上传失败 | 选择损坏图片 | 保留表单，其余字段不丢，提示重新上传 | 整页清空或显示已提交 |
| 重复点击 | 连续点击提交两次 | 只有一条报销记录 | 生成重复单据 |
| 刷新 | 提交后刷新页面 | 状态仍为已提交并显示单号 | 回到草稿或无记录 |
把一句产品想法交给 AI，先拆成可验收任务书
AI先负责追问场景、状态和异常，不直接生成完整项目。
可复制使用
把一句产品想法交给 AI，先拆成可验收任务书
请把我这句产品想法改写成工程团队可以验收的需求，而不是马上生成页面或代码。 用户原话【】；目标用户和发生场景【】；现有产品/技术限制【】；必须保留【】；明确不做【】。 先列出还会导致实现分歧的问题，最多问 5 个。其余信息足够后，输出：用户故事、触发条件、正常路径、空状态/失败状态/权限状态、输入输出、验收用例。每个验收项写成“给定…当…那么…”。不确定的交互决策标“产品待定”，不要擅自添加角色、页面或技术栈。
使用范围：AI先负责追问场景、状态和异常，不直接生成完整项目。不要自行增加功能、页面、角色或技术方案。
完成后的产品任务书
任务书定义客服创建反馈、产品经理分派与关闭、提交者查看状态；空标题、重复反馈和无权限访问有明确处理。每个故事配 Given/When/Then 验收，MVP 不做项单列。
为什么“功能清单齐全，开发仍不断问细节”还不能交付
功能清单齐全，开发仍不断问细节
- 原因
- 没有状态、角色和异常路径
- 怎么改
- 补页面状态矩阵与业务规则，未决问题交产品负责人而非由 AI 默认