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