会议记录变需求文档：五步法与AI辅助指南

每次需求评审会结束，手里攥着几万字的会议转录、一堆幻灯片和邮件往来，却不知道从哪下手？原始材料里确实藏着需求，但它们几乎从不以「需求」的格式出现。本文介绍一套五步法，用电子表格和高亮笔就能操作，AI 可以加速其中大部分环节，但有一条铁律：AI 生成的每一条需求，都必须回溯到原始材料逐句核对。

原始会议材料为什么靠不住

会议材料的信息密度很高，但有效信息的提取成本更高。常见的问题包括：

• 需求藏在故事里。「去年冬天技术员在地下室没信号，丢了一整天的表单」——这其实是一条离线工作需求，只是以抱怨的形式出现。
• 方案跑在问题前面。「我们要一个仪表盘」是方案，真正该记录的是背后的需求：主管需要在上午十点前看到哪些访问迟到了。
• 决策被淹没。「我们保留现有调度系统」是约束条件，影响后续所有决策，但它往往只出现在转录的某一行里。
• 来源互相矛盾。 销售幻灯片承诺当天出报表，运营负责人却说每周就行。两条说法都会进入你的笔记。
• 体量过大。 一小时电话会产生数千字转录，几次通话加几份幻灯片，没人会重读。

目标不是把材料总结一遍，而是提取出「有人要构建和测试」的部分，把其余内容显式标记为待解决问题。

第一步：收集并标记来源

在细读之前，先把所有来源放进一张清单，给每条一个短标签。标签格式可以是「类型字母+序号」，比如 T1 代表第一次电话转录，D1 代表第一份幻灯片，E1 代表邮件线程。清单需要记录：标签、来源内容、日期、参与者。

标签的作用在后面才会显现——你写的每一条需求都要带上一个或多个标签，方便任何人追溯出处和发言人。注意记录每段对话的参与者，因为预算审批人的一句话和路人的随口评论，权重完全不同。

如果来源是录音但没有转录稿，先转录。凭记忆整理通话内容是「凭空发明需求」的主要来源。

第二步：提取陈述、决策和问题

通读每份来源，标记三类行，并复制到工作表中，附上来源标签和简短引文：

• 需求：用户或业务必须能做的事，或必须具备的质量属性。「主管需要看到哪些访问迟到了。」
• 决策与约束：已经确定或不可谈判的事项。「保留现有调度系统。」「数据必须留在欧盟。」「夏季前上线。」
• 问题与疑虑：任何不清楚、有争议或被假设的内容。「分包商也用这个应用吗？」「每周报表够不够，还是必须当天？」

这一步先不要改写，保留说话人的原话。此时追求的是覆盖度而非精炼，引文还能在后续争论中定纷止争（「运营负责人在3月3日说过 X」）。

当两个来源说法不同时，两条都记下来，并新增一个问题。不要悄悄替人做选择。

第三步：改写成可测试的需求

现在把每条需求改写成测试人员能判定通过或失败的形式。好的一行需求要短、只覆盖一件事、陈述可观察的结果。ISO/IEC/IEEE 29148 标准列出了必要、单一、无歧义、可验证等质量属性；实操中，「有人能检查这条吗？」就能拦住大部分问题。

一个简单的句式来自劳斯莱斯开发的 EARS 方法：当［触发条件］时，［系统］应［响应］。

原始笔记（来源）	改写后的需求
「地下室没信号，丢了一天表单」(T1)	技术员应用应允许技术员在无网络连接时记录访问，并在连接恢复后同步。
「主管通过电话得知拒绝，太晚了」(T2)	当技术员拒绝访问时，调度板应在一分钟内将该访问显示为未分配并附拒绝原因。
「保留现有调度系统」(T1, E1)	约束：访问应通过现有调度系统的 API 创建和关闭。
「客户否认我们来过」(T2)	应用应捕获客户签名并附加到已关闭的访问记录上。

（以上示例为原文虚构，仅作演示。）

然后补充管理字段：类型（功能/非功能/约束）、优先级（MoSCoW，与发起人商定而非猜测）、验收标准（一到三条检查项）、来源标签、支撑的业务目标。

如果验收标准中的数字不是来自任何来源，标记为「提议」，需要有人确认，不能悄悄采纳。

关于 MoSCoW 方法：MoSCoW 是一种常用的需求优先级排序技术，由 Dai Clegg 于 1994 年提出。它将需求划分为四类：Must have（必须有）、Should have（应该有）、Could have（可以有）和 Won't have（本次不做）。Must 表示缺少即导致项目失败的核心需求；Should 表示重要但短期缺失有替代方案；Could 表示锦上添花、资源允许时再做；Won't 则明确划出本期范围之外，避免范围蔓延。文章强调「与发起人商定而非猜测」，正是因为优先级本质上是业务决策，而非需求分析者的技术判断。

关于 EARS 方法：EARS（Easy Approach to Requirements Syntax）由劳斯莱斯公司的 Mavin 等人提出，旨在用受控自然语言减少需求歧义。其基本句式包括：普适型（系统应……）、事件驱动型（当［触发］时，系统应……）、状态驱动型（在［状态］下，系统应……）、可选特征型（如果［特征］，系统应……）以及非期望行为型（如果［异常］，系统应……）。EARS 的价值在于把触发条件和系统响应强制分离，使每条需求都能被测试人员设计出明确的通过/失败判定，这与文章「有人能检查这条吗」的检验标准一致。

关于 ISO/IEC/IEEE 29148：该标准是系统与软件工程领域的需求工程国际标准，取代了此前的 IEEE 830。它定义了需求规格说明应具备的质量属性，包括必要（Necessary）、实现无关（Implementation-free）、无歧义（Unambiguous）、完整（Complete）、单一（Singular）、可行（Feasible）、可验证（Verifiable）、正确（Correct）和合规（Conformant）。文章引用该标准，是为了说明「可测试」并非主观感受，而是有行业共识的规范基础；实操中用「能否被检查」这一朴素问题来落地这些属性。

第四步：记录仍然未知的事项

这套流程的大部分价值，恰恰在于你写不出来的东西。第二步的每个问题、每条靠猜的需求，都进入待解决问题日志。每个条目记录：一句话问题、为什么重要（影响哪条需求或估算）、谁能回答、截止时间、在此之前假设什么。

示例：「分包商是否使用该应用？影响登录、权限和许可证数量。询问：运营负责人。未答复前：假设仅限员工。」

为了推进而做出的假设，也要放在同一位置可见。一个基于「仅限员工」的估算，如果答案是「还有40个分包商」，就得推倒重来。

最后，把需求清单对照来源再读一遍：找出转录中出现但需求里没有的条目，以及没有来源标签的需求。后者往往是写作时冒出的想法——可能没问题，但应该经过确认，而不是被夹带进来。

AI 能帮什么，你必须查什么

AI 擅长第二、三步中最慢的部分：读长转录、找陈述需求的句子、归并相似点、给出初版措辞。用它做二次检查（「这份转录里我漏了哪些陈述？」）也很有效。

它会在几个可预测的地方出错：

• 编造细节。 模型可能添加无人说过的数字、名称或阈值。每个数字都要对照来源核查。
• 把目标写成需求。「将漏访减少30%」是目标，模型可能把它改写成系统自身无法满足的需求。
• 丢失分歧。 摘要倾向于在两个来源冲突时选一个版本。你需要两个都保留，外加一个问题。
• 遗漏约束。 关于预算、法规或现有系统的简短评论很容易漏掉，后期发现的代价很高。
• 语气过于自信。 一条措辞漂亮的需求读起来像是已达成共识，即使它只是猜测。

以 Discovery Phase AI 为例（原文作者自建工具，存在利益披露），它的做法是：上传转录、幻灯片、文档或图片后，在内存中分析、不存储，AI 起草干系人、目标、用户、旅程和需求供人工审阅；被指示仅在来源明确陈述时才起草需求，绝不编造验收标准或数字，宁可留空也不猜测；每条草稿项在保存前由人工勾选保留。即便如此，第一步和第四步仍然是人的工作：搞清楚谁说了什么，以及写下没人回答的问题。

五步法的适用边界

这套方法适合需求发现的早期阶段，尤其是从非结构化材料中打捞线索。它不替代用户访谈，也不替代正式的需求评审。AI 加速的是阅读和初稿，判断和决策仍然在人这边。

一个务实的检查习惯值得坚持：任何一条需求，如果你不能在三十秒内指出它来自哪份材料的哪句话，它就不该出现在需求文档里。