提示词：把零散笔记整理为可验收需求表

开始使用

把原始干系人笔记粘贴到提示词中 MY INPUT (paste below, replacing this line): 这一行的位置，然后在任何可接受文本的普通 AI 对话中运行该提示词。可在笔记后补充可选背景信息（项目名称、目标日期、已知约束、已在使用的需求编号）。

你会得到什么： 一份 Markdown 文档，包含 A–E 五个部分——需求登记表（编号、需求、类别、来源、验收检查、置信度）、冲突与重复、依赖关系、待确认问题，以及因笔记未支持而被排除的条目。

如何检查输出： 每一行都必须有来源和置信度；每条功能性或数据类需求都必须给出“给定/当/则”形式的验收检查，或标注 NEEDS DETAIL；冲突部分引用的编号必须真实存在于表格中。若某一行在笔记中找不到依据，请删除它。

适用场景

团队开完会常常只剩零散纪要和聊天片段，却没有一份可验证的需求清单。本提示词把这些笔记整理成结构化的需求草稿登记表，供人在确定范围之前评审。它只依据粘贴进来的文本，不会补充行业通用要求、编造指标阈值，也不会假设某人已批准某事；不确定的内容会被标注，而不是猜测。

面向办公与小型团队场景：记录纪要、需要可评审产出物的人。无需终端、API 密钥或任何集成。

前提与权限

• 一个可粘贴文本的普通 AI 对话界面。
• 你的笔记，以及可选的项目名称、目标日期、约束和已有编号。
• 获得把这些笔记提供给该工具的授权。笔记常含姓名、客户数据或报价：粘贴前请脱敏或匿名化，并遵守所在机构的数据规定。
• 若团队已有在用需求编号，请一并提供，避免新编号冲突。

局限

• 产出仅为供人工评审的草稿，不代表已批准、已定稿或已完整。
• 该提示词不会发送、安排或通知任何人，也不会更新任何跟踪系统。
• 若笔记内容单薄，会出现大量 NEEDS DETAIL 行——这是正确结果，而非失败。
• 粘贴更新后的笔记会重新跑一遍，而不是与先前登记表合并。
• 已审阅来源；未做运行测试——文档中的配置仅为说明，未执行任何命令，也未在此验证任何模型输出。

常见问题

我的笔记只是零散聊天记录，够用吗？ 够用，只要其中包含明确陈述或可清晰推断的内容。含糊的说法会变成低置信度行或待确认问题，而不是被编造成需求。

两个人似乎对同一件事说法不一致，会怎样？ 提示词会把两种理解都列入登记表，并把取舍放进待确认问题，由具名的人来决定。

来源与致谢

TokRepo 原创提示词（CC BY 4.0），任务：从干系人笔记中提取需求与验收检查。参考背景：ChatGPT release notes，查阅日期 2026-10-04；这些模板不依赖任何新发布的具体功能。提示词中的示例为虚构，非真实数据。

完整可复制提示词

你正在帮助我把原始干系人笔记转换为一份可评审、带验收检查的需求登记表。我会把笔记粘贴在下面。请只依据这些笔记中实际存在的内容进行工作；不要补充行业通用要求，不要推断缺失的数字，也不要假设某位干系人同意了其并未说过的事情。

MY INPUT (paste below, replacing this line):

• 原始干系人笔记、会议纪要、聊天片段或邮件片段。如可获得，请包含发言人姓名或角色。
• 可选：项目名称、目标日期、已知约束，以及任何已在使用的需求编号。

你的任务

1. 识别笔记中陈述或明确暗示的每一条独立需求。当复合句描述不同的义务时，将其拆分为多条独立需求。
2. 将每条需求归类为以下之一：功能性、数据、访问/权限、报告、合规/审计、可用性、运营。
3. 分配一个稳定的编号（R-01、R-02、……），并记录支持该需求的来源短语或发言人。若来源不明确，请在“来源”列中说明。
4. 为每条需求至少编写一项验收检查，形式为：给定 [上下文]，当 [动作]，则 [可观察结果]。若笔记未提供足够细节以编写可测试的检查，请写 NEEDS DETAIL 并明确说明缺失了什么。
5. 标记需求之间的冲突、重复和依赖关系。
6. 针对笔记中任何不清楚之处，生成一份待确认问题清单。

输出格式 使用 Markdown，按顺序包含以下部分： A. 需求登记表，列为：编号 | 需求（祈使句） | 类别 | 来源 | 验收检查 | 置信度（高/中/低）。 B. 冲突与重复，列出涉及的编号及一行说明。 C. 需求之间的依赖关系。 D. 待确认问题，每个至少关联一个需求编号。 E. 因笔记未支持而被排除的条目。

不确定性与缺失输入

• 绝不要编造截止日期、指标阈值、负责人或批准。
• 若某条需求可有两种理解，请在登记表中列出两种理解，并把选择放入“待确认问题”。
• 若笔记中没有某条需求的验收细节，请标注 NEEDS DETAIL，而不是猜测一项测试。

虚构的示例（仅为说明，非真实数据） 输入摘录：“Priya 说导出必须包含所有活跃客户，而不是已归档客户。Marcus 希望任何内容发出前都要财务批准。有人提到应该每周运行一次，但没人确认。” 示例输出形态：

• R-01 | 导出必须仅包含活跃客户，排除已归档客户。 | 数据 | Priya | 给定一份活跃客户列表，当导出运行时，则已归档客户不出现。 | 高
• R-02 | 导出在发布前需要财务批准。 | 运营 | Marcus | 给定一份已完成的导出，当在未获财务批准的情况下尝试发布时，则发布被阻止。 | 中
• R-03 | 导出可每周运行一次。 | 运营 | 未确认的群体发言 | NEEDS DETAIL：确认频率、日期和时区。 | 低
• 待确认问题 Q1，关联 R-03：由谁确认时间安排？

完成前的评审检查

• 每一行需求都有来源和置信度值。
• 每条功能性或数据需求都有验收检查或 NEEDS DETAIL。
• 没有任何需求是依据通用良好实践编造出来的。
• 冲突列表引用 A 部分中真实存在的编号。
• 待确认问题可由具名的人或角色回答，而不是含糊不清。

边界

• 本产出仅为供人工评审的草稿登记表。
• 不要声称这些需求已获批准、已定稿或已完整。
• 不要告诉我发送、安排或通知任何人；下一步是由人来评审这份草稿登记表。
• 若我之后粘贴更新后的笔记，请将其视为新输入并重复整个流程，而不是悄悄合并。

如果我还没有粘贴笔记和任何可选背景信息，先要求我粘贴。

参考资料与复用

• ChatGPT release notes · Reviewed 2026-10-04

TokRepo 原创提示词 · CC BY 4.0。参考资料保留各自原有权利。