用 WorkBuddy 起草需求文档，先出结构再填内容

写需求文档最容易犯的错，是一上来就写细节。

写到第三章发现整体结构不对，前面全得推倒重排——而这时候你已经投入了两小时。

正确的顺序是：先出结构，你确认，再填内容。 这也是官方在使用技巧里讲的「小步快跑」：把大任务拆成独立小目标，一次推进一步，每步都能确认方向，发现偏了及时拉回，而不是最后整份推翻。

本文依据 WorkBuddy 官方使用技巧、专家中心与权限模式文档，核对日 2026-08-16。我们没有安装客户端，本文不含实测数据。

一、第一步：只要结构

【目标】为 <功能名称> 起草需求文档的结构

【背景】
- 这个功能要解决的问题：____
- 目标用户：____
- 已有的相关材料：D:\WorkBuddy\prd\素材\ 下的文件

【输出】只出目录结构（到二级标题），每节用一句话说明这节要写什么。
        ★ 先不要写正文内容。

【约束】
- 结构参照 <公司模板.docx>（如果有）
- 不要凭常理增加我没提到的功能点
- 不需要开场白

「先不要写正文」这句必须写。 不写的话它会直接给你一份完整文档，你就失去了在最便宜的阶段调整的机会。

如果公司有 PRD 模板，一定给它。 官方在使用技巧里说得很直接：一个好的参考样本胜过十行抽象要求，样本是明确的锚点。

二、第二步：分节填内容

结构确认之后，一节一节填，别一次要完整版：

只写第 3 节「功能详述」的正文。其余部分保持不变。
要求：
- 每个功能点写清楚：触发条件、处理逻辑、输出结果、异常情况
- ★ 不要发明我没提过的功能点；需要补充的地方标注 <待确认>
- 涉及数据字段的，列成表格

「标注 <待确认>」是这类文档最实用的一条约束——需求文档里最危险的不是写错，是把不确定的地方写得像确定的。留个占位符，你一眼就知道哪儿要去问。

三、哪些能交出去，哪些必须自己写

部分	能不能交	说明
文档结构与目录	✅	有模板更好
背景与现状描述	✅	基于你给的材料整理
功能详述的格式化表达	✅	把你说清楚的逻辑写成规范文字
数据字段表	✅	但字段定义要你确认
异常情况枚举	⚠️ 半交	它能列常见的，但业务特有的异常只有你知道
需求的取舍与优先级	❌	做什么不做什么，是产品判断
为什么这么设计	❌	设计理由涉及你对业务的理解
验收标准	❌	这是要拿去对齐的承诺

中间那条「异常情况」值得展开：它能列出「输入为空」「网络超时」这类通用异常，但**「用户在活动期间重复领取」这种业务特有的边界，它想不到**——因为你的业务规则不在它的输入里。

做法：让它先列通用异常，你再补业务特有的。

四、验收：重点看三处

第一处：有没有凭空多出来的功能点。

这是 PRD 场景最典型的问题。它会「合理地」补上一个你没提过的功能——比如你说要做列表页，它顺手加了「支持批量导出」。

这个功能一旦进了文档，开发就会去做。

查法：对照你最初给的功能清单，逐条核对。多出来的一律标注或删掉。

第二处：<待确认> 标注够不够多。

听起来反直觉，但一份 <待确认> 很少的初稿，通常不是写得好，是它把不确定的地方都编了。

查法：随便挑三个具体的技术细节或业务规则，问自己「这个是我说过的吗」。

第三处：验收标准那一节。

如果你在结构里留了这一节，确认它是空的或者只有占位符。验收标准是要拿去跟开发、测试对齐的承诺，必须你自己写。

五、涉及技术方案的部分要谨慎

需求文档有时会带一点技术方案描述。这部分要注意两件事：

一、别让它替你做技术选型。 「建议使用 Redis 缓存」这类判断需要对系统现状的了解，不该出现在你的需求文档里——那是研发要定的。

二、同门还有专门的编程形态。 如果你确实要写技术细节，官方这套体系里还有 CodeBuddy IDE 与 CLI 两个专门的编程形态，共用同一账号与积分（官方定价文档原文：同一账号积分共享，无需分别订阅）。技术侧的内容在那边处理更对口。

六、素材与目录

PRD 的素材通常包括：竞品截图、用户反馈、旧版文档、会议纪要。

按官方建议建独立目录，放副本：

D:\WorkBuddy\prd\
├── 素材\      （竞品资料、用户反馈、旧版文档、模板）
└── 成品\      （结构稿、各节内容、终稿）

官方原话：处理重要文件之前，先建独立的任务文件夹，把需要的文件复制进去，而不是把原始目录直接交出去。

一个额外提醒：用户反馈类素材里常带着联系方式和姓名——分析用不上的话，进目录前先删掉。

七、写完之后：换视角挑毛病

官方使用技巧里有一条「切换角色视角」，在 PRD 上特别好用：

用开发工程师的视角看这份需求文档，
哪些地方描述得不够明确、会导致理解歧义？只提问题，不要改写。

用测试工程师的视角看，哪些功能点缺少可验证的判断标准？

「只提问题不要改写」——你要的是它挑刺。这两轮挑出来的问题，通常正是评审会上会被问到的。

开工前给身份、做完后换视角，是官方技巧里配套的两招。

八、几件不该交给它的

• 需求取舍与优先级——这是产品的核心判断；
• 验收标准——要拿去对齐的承诺；
• 技术选型——研发的判断；
• 对外的需求确认邮件——起草可以，发送要人（发出去收不回来）；
• 替你判断「这个需求合不合理」——官方在专家中心明确提示 AI 生成内容仅供参考，无法替代专业判断。

小结

• 正确顺序：先出结构 → 你确认 → 再分节填内容。对应官方的「小步快跑」——每步都能确认方向，跑偏了当场拉回。
• 第一步指令里必须写「先不要写正文内容」；有公司模板一定给（样本胜过十行抽象要求）。
• ★ 最实用的一条约束：需要补充的地方标注 <待确认>——需求文档最危险的不是写错，是把不确定的写得像确定的。
• 能交的：结构、背景现状、格式化表达、数据字段表；必须自己写的：需求取舍与优先级、设计理由、验收标准。
• 异常情况是半交——它能列通用的，业务特有的边界只有你知道。
• 验收三处：有没有凭空多出的功能点（对照原始清单逐条核）、<待确认> 够不够多、验收标准那节是不是空的。
• 写完用「切换角色视角」让开发和测试视角各挑一轮毛病，只提问题不要改写。

功能与文档表述以官方为准，核对日 2026-08-16。