用 ChatGPT 整理需求文档：先说清行为，再写功能列表 - AIPlan

需求文档能不能让开发直接动手，取决于有没有写清"输入什么、输出什么、出错怎么办"。ChatGPT 能把一段口头想法扩成 2000 字，其中约 60% 是功能清单和形容词，缺的恰好是这三件。做法是先让它按 5 个维度提问，你答完再写。 拿"订单查询"这个功能举例：7 个字段、3 种角色、2 类异常，写清这些大约 600 字，比一份 3000 字的功能罗列有用。 先回答 5 个问题，再让它动笔 让模型按这 5 项各问你 2 个问题，一共 10 个： • 谁用（哪些角色，各自能看到什么） • 什么场景下用（什么时候会打开这个页面） • 业务规则是什么（什么条件下能查到、不能查到） • 异常怎么处理（查不到、超时、权限不足） • 怎么算做完（验收标准，能量化） 提示词： 我要做一个"订单查询"功能。请按 5 个维度各问我 2 个具体问题，一共 10 个。问题要能直接回答，不要问"你的目标是什么"这类开放问题。等我全部答完，你再写文档。 第 5 项最常被跳过，也最要命。"做完"的标准如果是"能查到订单"，开发和测试对不上；写成"输入订单号 18 位，200 毫秒内返回 7 个字段，查不到时显示'未找到该订单，请核对后重试'"，才算可验收。 需求要写成行为，不要写成功能名 对比两种写法： 功能式写法 行为式写法 订单查询 输入订单号，返回状态、金额、下单时间、支付方式、商品名、数量、物流单号 7 个字段 权限控制 普通用户只能查自己的订单；客服可查全部；财务可查全部但不能看收货地址 错误处理 订单号不足 18 位时，输入框下方红字提示，不发请求 行为式写法的共同点是都能被测试。一条需求如果写不出对应的测试用例，说明它还没想清楚。 让模型做这个转换： 以下是我列的 8 条功能。请把每条改写成可测试的行为描述，格式为"当【条件】时，系统【动作】，结果是【可观察的输出】"。改不了的标"需要补充"，不要自己编。 最后那句"不要自己编"很关键。模型不知道你的业务规则，它会用通用电商的默认规则填进去，写出来的东西看起来完整，实际全是错的。 订单查询的完整规格长什么样 按上面 5 项答完，可以写成这样： 角色与可见字段 角色 可查范围 可见字段 下单用户 仅本人订单 全部 7 个字段 客服 全部订单 全部 7 个字段 + 备注 财务 全部订单 除收货地址外 6 个字段 未登录 不可查 — 查询条件 • 订单号：18 位，纯数字，必填 • 手机号后 4 位：选填，用于二次校验 • 时间范围：默认最近 90 天，最长 365 天 异常处理 情况 系统行为 用户看到 订单号不足 18 位 不发请求 输入框下红字"订单号应为 18 位数字" 订单不存在 返回 404 "未找到该订单，请核对后重试" 无权查看 返回 403 "该订单不属于当前账号" 查询超时（>3 秒） 中止请求 "查询超时，请稍后重试" 这张异常表值得单独强调。真实开发里，80% 的返工来自"这种情况怎么办"没写。把它列全，等于把返工提前消掉。 边界值要写到具体数字 模型写需求时倾向于写"较短的输入""较大的订单量"。这些词开发没法实现。让它在每个数值后面追问一次边界： 你写的"订单号 18 位"，请补：少于 18 位怎么办、多于 18 位怎么办、包含字母怎么办、前后有空格怎么办。每个情况给出具体的界面提示文案。 四个问题答完，一个输入框的校验规则就齐了。同样的方法适用于金额（最小 0.01 元、最大多少）、时间范围（默认 90 天、最长 365 天）、分页（每页 20 条、最多 100 条）。 这类数字最好让模型列成表，你逐行确认。表格式的确认比读段落快 3 倍。 非功能需求别写成形容词 "响应要快""系统要稳定"这类句子在文档里等于没写。可替换的写法： • 接口 P95 响应时间 ≤ 500 毫秒（不含第三方物流查询） • 物流查询单独设 3 秒超时，超时降级为"物流信息暂不可用" • 单日查询量按 20 万次设计，峰值 5 分钟内 3 万次 • 查询日志保留 180 天，含 user_id、订单号、查询时间、结果码 第 3 条的数字必须来自业务方，模型只能给结构。可以这样问它： 我预计日活 5 万、每人每天查 2 次订单，峰值集中在 20:00 到 22:00。请据此给出 QPS 估算过程和需要的缓存策略，写清假设。 它会把 5 万 × 2 = 10 万次日查询，其中 60% 落在 2 小时内，算出平均约 8.3 QPS、峰值按 3 倍算是 25 QPS。这个推导过程比一个孤零零的数字有用，因为假设可以被质疑和修正。 让模型扮演 3 个角色挑刺 文档初稿完成后，跑三轮对抗： 分别以开发、测试、运营的身份读这份需求，每个角色提 3 个问题。开发关注实现歧义，测试关注无法验证的条目，运营关注上线后的用户咨询点。每个问题引用原文那一句。 三类问题通常不重叠： • 开发会问"订单号 18 位是固定长度还是范围" • 测试会问"超时 3 秒是从点击算还是从请求发出算" • 运营会问"用户输错 3 次会不会被锁" 第三个问题最容易被漏，因为它不在功能范围内，却会在上线第一天变成客服工单。 拆成开发任务时，一条需求对应一个可交付 需求文档交付给开发前，让模型做最后一次拆分： 把这份需求拆成开发任务，每个任务满足：能在 1 到 2 天内完成、有独立的验收方式、不跨前后端。输出格式为"任务名 / 涉及文件或模块 / 验收方式"。 拆不出来的条目，通常是需求本身粒度太粗。例如"实现订单查询"拆不开，"实现订单号 18 位格式校验（前端）"就能拆。 拆分结果还能反查需求完整性：如果某个角色或某张异常表没有对应的任务，说明文档写了但没排期。 从需求到代码提示词 需求写清之后，交给编码工具会顺很多。Codex 这类工具吃的就是"输入输出明确"的任务描述，给 Codex 写任务提示词的结构里有一套对应的模板，可以直接把这里的验收标准搬过去。 一个衔接方式：把异常表整段贴进任务提示词，要求"逐个实现这 4 种异常，每种写 1 个测试"。比笼统说"实现订单查询接口"得到的代码完整度高很多。 会议记录就是需求原料 需求多数不是坐在桌前想出来的，是会上讨论出来的。把会议纪要里的"未决问题"直接转成需求条目，比重新回忆快。前提是纪要把"已决"和"未决"分开记，会议纪要的三栏结构正好是这份原料。 提醒一点：未决问题写成需求之前，要确认它真的要做。会上提过但没人认领的条目，写进文档只会让它看起来像已排期。 一份文档的合理长度 订单查询这个功能，完整需求文档 800 到 1200 字就够：1 张角色表、1 张异常表、5 到 8 条验收标准、3 条非功能指标。超过 2000 字的部分，通常是背景介绍和竞品分析，这两部分对开发没有约束力。 写完做个 30 秒自检：把文档里的所有"应该""尽量""适当"标出来，每一处要么改成具体数字，要么删掉。一份 1000 字的文档，这类词通常有 5 到 8 处。 这类文档工作一轮对话就能完成，用量很小。真正吃额度的是让它读历史文档、跑多轮角色挑刺。ChatGPT 的剩余额度在 设置 → 用量 查看，Plus 与 Pro 受 5 小时窗口与周窗口双重限制（截至 2026 年 10 月 18 日核对）。一个月写 2 到 3 份需求的，免费版够用；每周都要拆任务、跑对抗审稿的，按月付费更好估——参考价 115.50 元一个月，兑换用的是订单里的卡密，具体条件写在Plus 月卡商品说明里。 参考资料资料核对日期：2026-10-17 • Text generation 延伸阅读• 给 Codex 下任务怎么写？让目标、边界和验收都可检查 • 用 ChatGPT 整理会议纪要，别把讨论意见写成正式决定 • 用 AI 整理客服知识库：答案要有依据，也要知道何时转人工 • 用 ChatGPT 改简历：让真实经历更清楚，不替经历加戏