用AI自动化链路重构需求评审，时间从4小时缩至2小时

前阵子我们评审一个订单中心的改造需求，我提前订了会议室，喊齐了产品、后端、测试、还有隔壁组的接口负责人。白板、思维导图、在线协作文档、需求管理平台，工具链算是拉满了。可会开到第三个小时，大家还在为“这个改动到底影响到哪些接口”吵架。我当时盯着满桌子的工具，突然意识到一个问题：我们不是缺工具，而是工具之间根本没有链路。信息从需求文档到影响面分析再到测试用例，全靠人肉搬运。这之后我花了几周时间，用一条 AI 自动化链路把评审流程重新串了一遍，结果很直接：需求评审时间从平均4小时压到2小时出头。这篇文章就把我这套思路和踩过的坑完整讲一遍，包括链路怎么搭、哪些环节最值得自动化、以及哪些地方千万不能全交给AI。

1. 先聊聊我为什么把团队里的“工具墙”拆了

我们团队之前的状态，应该能引起不少人的共鸣：需求管理用一套系统，画流程用白板，写验收标准用在线表格，接口文档单独维护在另一个平台，代码仓库的 TAD 里还有一份古老的模块清单。每个工具单看都没问题，问题在于它们是七座互不相通的孤岛。

1.1 信息孤岛带来的隐性成本

需求评审最耗时的不是争论本身，而是“把信息从一个工具搬运到另一个工具”的过程。评审会上，产品经理念一遍 PRD，后端去翻接口文档确认改动范围，测试对着表格现场脑补测试场景，需求写得好不好、影响范围有没有漏，全靠个人经验兜底。这种模式有三个明显的坑：

• 搬运过程丢失信息。PRD里一句“订单状态流转调整”，不同人理解出来的影响面完全不同。
• 认知负担全压在与会者身上。每个人都要在短时间内读文档、查依赖、想边界，大脑很快过载。
• 没有可追溯的中间过程。评审结论是“感觉没问题”，而不是“基于哪些事实得出没问题”。

我意识到，真正缺的不是第七个工具，而是一条能从“输入需求文档”直接走到“输出结构化评审报告”的数据管道。这条管道里嵌入的，才是标题里说的“AI自动化链路”——让 AI Agent 在关键节点上承担信息加工工作，而不是再买一个新工具回来供着。

1.2 为什么单点 AI 工具解决不了问题

有人可能觉得，那不简单吗？给每人装一个 AI 助手，让大模型帮忙读文档、总结要点不就行了。我早期也试过这个思路，结果效果很有限。原因是：单点 AI 工具只是把“人读文档”变成了“AI读文档”，但 AI 读完的结论依然是碎片化的，没有变成后续环节能直接消费的结构。

真正让评审提速的，是把 AI 嵌进一条工作流里：第一步输出的 JSON，是第二步影响面分析的直接输入；第二步检索到的模块清单，是第三步测试场景生成器的上下文。环环相扣，数据不落地、不搬运。这也是“AI 工作流”和“装一个 AI 插件”的本质区别——前者是一整条流水线，后者只是给某个工位配了把更快的锤子。

2. 需求评审这场“马拉松”，时间究竟花在哪了

动手搭链路之前，我先把团队最近六次需求评审的时间消耗做了统计。不度量就没法优化，这个道理放在流程上同样成立。统计方法很简单：会后让参与的人各自估算每个环节的耗时，再取个平均。

2.1 一次典型评审会的时间拆解

整体算下来，单次评审平均在4小时左右。有意思的是，真正需要“人”来判断的业务规则确认环节只占50分钟，其余170分钟都花在了信息加工上——读、查、想。这三个动作恰恰是现在的大模型最擅长的事情：阅读理解、跨文本检索、按模式生成。

2.2 高耗时的环节，恰好是 AI 最该接管的环节

我当时的判断是：通读文档、找影响点、脑补场景这三件事，本质上都是“把非结构化信息转成结构化决策依据”的过程。它们的输入输出非常明确——输入是一段文字，输出是列表、接口清单、用例表格。这种明确的转换关系，非常适合用 AI Agent 来承担。

而“业务规则确认”这一类需要业务方拿主意、涉及利益取舍的环节，AI 顶多能帮忙列出选项，最终判断还是得留给人类。想清楚这个边界之后，整个链路的设计目标也就清晰了：把170分钟的机械性信息加工压缩到40分钟以内，把省下来的时间还给真正的业务讨论。

3. AI自动化链路的整体设计：从文档输入到评审报告输出

链路目标定下来后，我开始设计整体方案。核心思路是：一条链路、四个环节、全程JSON格式传输。下面把技术选型和架构思路讲清楚。

3.1 技术选型：为什么用 Python 编排 + 本地模型

技术栈上，我选的是 Python 做编排脚本，模型用 Ollama 拉起的本地开源模型（例如 Qwen2.5 14B 量化版）。选择原因是：

• 链路涉及文本切分、JSON解析、文件读写、调用检索命令，Python 写起来最顺手。
• 需求文档内容敏感度较高，本地部署可以避免数据外流。14B 量化模型在 8GB 显存的机器上就能跑，解析文档这种任务完全够用。
• 推理能力更强的场景（比如复杂影响面推理），可以按需切换商用大模型 API，代码层面通过统一接口兼容。

如果团队是 Java 技术栈，完全不必要照搬我的做法——Spring AI 和 TypeSafe AI 这类框架把 Agent 编排、模型接入都做了封装，链路逻辑是通用的，换的是载体而已。关键不是编程语言，而是“环节拆分”和“数据约定”这两个设计决策。

3.2 链路四环节：解析、影响标注、用例草稿、风险简报

整条链路分四个环节：

1. 需求规约解析：把原始 PRD 拆成结构化需求项，输出 JSON。
2. 影响面分析：每个需求项去匹配模块清单、接口文档、代码目录，输出受影响模块和接口列表。
3. 测试场景草稿生成：根据验收标准自动生成等价类、边界值、异常路径的用例草稿。
4. 评审简报复核：汇总前三步的输出，生成风险点、待确认问题、争议清单，作为评审会的讨论底色。

这个顺序的编排逻辑是：前一个环节的输出必须是后一个环节的合法输入。如果第一步只输出了一段散文式的摘要，第二步就没法去做模块匹配。所以我在设计环节时，先定义清楚了每一步的 JSON Schema，再去写提示词。

3.3 Agent 的编排模式：主 Agent 调度，副 Agent 干活

我没有用一个“超级 Agent”一次性读完整个 PRD 然后输出所有东西。原因是长文档一次性塞给模型，要么截断，要么细节丢失。我的做法是把链路拆成独立脚本，每个环节是一个小 Agent，由入口脚本依次调用。

这种“一人协调、多人分活”的模式，产出质量更好，也更容易定位问题——哪个环节输出异常，单独修哪个环节，不必整个链路返工。反直觉的地方在于：加了一个主调度层的代码量，反而比写一个庞大 prompt 要少得多，因为每个子环节的 prompt 都变短变专一了。

3.4 结构化数据是链路的粘合剂

整条链路上，唯一贯穿始终的数据格式是 JSON。需求解析输出 JSON，影响面分析消费 JSON 再追加字段，测试场景生成器读取验收标准数组，最终汇总脚本再合并成一份 Markdown 评审简报。

我可以明确说：没有结构化数据，这条链路根本跑不起来。初期我偷懒让模型直接输出 Markdown，结果第二步解析的时候被各种表格格式折腾得欲仙欲死。改成 JSON 之后，所有问题都消失了——程序可以稳定地操作数据流，而不是去猜测“标题下面有没有换行符”。

4. 三个最有性价比的自动化点

链路搭起来后，实际落地时我很快发现，不是每个环节的收益都一样大。如果让我排优先级，这三个点是最先值得做的，它们直接贡献了评审时长一半以上的缩减。

4.1 需求规约结构化解析：把 PRD 变成机器可读的数据

这一步是整个链路的入口，负责把产品经理写的 Markdown 文档变成结构化需求项。

python复制import json
import re
from openai import OpenAI

# Ollama 本地服务，兼容 OpenAI SDK 协议
client = OpenAI(base_url="http://localhost:11434/v1", api_key="ollama")

def extract_requirements(markdown_text: str) -> list[dict]:
    system_prompt = """
你是一名高级需求分析工程师。请从需求文档中提取结构化需求项。
输出必须是一个JSON数组，每个元素包含：
- id: 需求编号，若原文没有则用R001、R002...依次编号
- title: 需求标题（一句话）
- description: 需求背景与目的，不超过200字
- business_rules: 业务规则列表，只提取确定性规则，推测性内容不要写
- acceptance_criteria: 验收标准列表，逐条引用原文
- related_systems: 文档中明确提到的关联系统；未提及的填 null
- data_fields: 数据字典字段，若文档无定义则填 null
- uncertainty: 文档中表述含糊、存在歧义的地方

规则：
1. 只抽取原文明确存在的内容，禁止编造
2. 缺失字段填 null，不要推测
3. 验收标准必须与原文一致，可适当拆分，不可改写含义
"""
    resp = client.chat.completions.create(
        model="qwen2.5:14b",
        messages=[
            {"role": "system", "content": system_prompt},
            {"role": "user", "content": markdown_text[:12000]}
        ],
        temperature=0.1,
        response_format={"type": "json_object"},
    )
    text = resp.choices[0].message.content
    data = json.loads(text)
    return data.get("requirements", [])

这个环节踩过的最大的坑：模型会把“背景描述”误当成“业务规则”抽出来。比如 PRD 里写“当前系统不支持部分退款”，模型把它当成新规则，实际上这是一句现状描述。后来我在提示词里显式强调“只提取确定性规则”，并加了几个 few-shot 正反例，才把误抽取率压到可接受范围。

另一个经验是温度参数要调低。解析任务不是创意写作，不需要模型的“发散”，我把 temperature 固定在 0.1。输出格式用 response_format={"type": "json_object"} 强制 JSON，这是省掉解析错误的最直接手段。

4.2 影响面分析：AI 推理和代码检索的“双保险”

需求评审会上 90% 的争论都集中在“这个改动会不会影响 XXX功能”。以前的解法是：有经验的老员工靠记忆拍脑袋，没有经验的新员工查代码查到崩溃。我做的影响面分析模块，把这变成了“AI 起稿 + 代码验证”两个步骤。

python复制# 影响面分析：候选模块推理 + 源码命中验证
def analyze_impact(requirement: dict, module_list: list[str], repo_path: str):
    # 第一步：LLM 根据需求和模块清单，推理候选影响模块
    sys_prompt = """根据需求描述的改动内容，从模块清单中选出可能受影响的模块。
直接输出JSON数组，不要解释，例如 ["order_api", "payment_gateway"]。
如果拿不准，仍然保留该候选，标注"uncertain": true。"""
    candidates = llm_output(sys_prompt, json.dumps(requirement))
    
    # 第二步：在代码目录中检索需求关键词，验证命中次数
    validated = []
    for module in candidates:
        hits = grep_keywords(repo_path, module, 
                             keywords_of(requirement), top=20)
        if hits:
            validated.append({"module": module, "hit_count": len(hits),
                              "evidence": hits[:5]})
        else:
            # 没有代码证据的一律标记，人工二次确认
            validated.append({"module": module, "hit_count": 0,
                              "evidence": [], "uncertain": True})
    return validated

为什么强调要做代码检索验证？因为纯让 LLM 猜影响面，它猜中的概率大概只有七八成，但漏掉的 20% 往往就是评审会上的定时炸弹。加上代码关键词检索之后，AI 的候选列表会被过滤一轮：检索命中的模块，注明证据文件路径；检索不到但 AI 认为相关的模块，打上 uncertain 标记交给人类二次确认。

这里补充一个很实用的细节：检索关键词不要直接拿整个需求标题去搜，而是先让 LLM 从需求里提炼出 5 个左右的核心实体词（比如“订单号”“退款状态”“回调地址”），再拿这些词去代码目录里 grep。准确率会显著高于整句搜索。这也符合我一直在说的套路——把 AI 用在“提炼”上，把确定性搜索交给代码工具。

4.3 测试场景草稿生成：评审会不再现场脑补用例

测试场景讨论环节以前耗时最夸张，经常是测试同事临时翻阅需求文档，边看边想“这个字段没有填会怎么样”。接入链路后，测试用例草稿在会前就生成好了，评审会上大家的任务是“审阅”而不是“创作”。

python复制def generate_test_case_drafts(acceptance_criteria: list[str]) -> list[dict]:
    prompt = f"""
根据验收标准生成测试用例草稿，输出JSON数组：
[{{"id":"TC-001","title":"...","precondition":"前置条件",
   "steps":["1. ..."],"expected":"..."}}]

要求：
1. 覆盖正常路径、边界值、异常路径
2. 边界值数据用 {{BOUNDARY}} 占位，由测试人员会后填充，不要自己编造
3. 异常路径至少包含：非法输入、超时、依赖服务不可用
4. 严格基于验收标准推导，验收标准没有覆盖的场景不要强行编写
"""
    ...

这里最重要的一条约束是“边界值用占位符”。因为模型不确定系统的真实数据边界，让它自己编的话，生成的用例可能会抛出一个根本不存在的业务数值，测试照搬就会出错。用 {BOUNDARY} 占位，等于告诉测试同事：“格式我给你，数据你填。”这是把生成结果从“看似可用”变成“真可用”的关键一步。

实际生成的草稿质量，坦白讲有七成是可以直接用或者小改的，剩下三成有逻辑跳跃。但相比从白纸开始想，效率提升是数量级的。以前评审会上测试要现场想 20 个场景，现在只需要判 20 个场景对不对——判断比创作快得多。

5. 实测效果与数据：缩短一半是结果，不是口号

链路跑通之后，我连续记录了一个季度的数据。为了避免幸存者偏差，选取的都是常规需求评审，不包含那种一句话能说清的微小需求变更。

5.1 量化对比：从240分钟到110分钟

数据最扎眼的不是那些降幅，而是“业务规则确认”只从 50 分钟降到 45 分钟。这个环节几乎没怎么变——因为规则的拍板权始终在业务方手上，AI 能把选项和后果列得更清楚，但最终点头的还是人。这条边界一定要明确：AI 自动化链路做的是“把信息加工到可以直接决策的程度”，而不是替人类做决策。

5.2 意外收获：文档质量被倒逼提升了

这是我没预料到的收益。链路跑了几周后，有产品同事主动来问我“为什么我的 PRD 解析出来一堆 uncertainty 标记”。原因是模型诚实，把文档里含糊的描述都标成了“歧义点”。这个 feedback 某种程度上成了文档质量的体检报告——文档写得越烂，uncertainty 越长。后来产品在提需求时开始注意语句清晰、字段定义完整，因为大家都不想再次在评审会上被自己文档里的含糊描述问住。

5.3 评审会上最大的变化：争论从“猜”变成“查”

以前开会是“我觉得不影响”“我觉得影响”的来回拉扯，现在大家在链路给出的影响面清单里逐条确认，有疑问就直接点开证据文件。争论的层次提高了，讨论的是业务取舍，而不是技术事实。这是我觉得整条链路最值钱的地方——它把“人嘴对峙”变成了“证据对线”。

6. 踩坑记录：AI幻觉、上下文爆炸和“半自动”的边界

再讲几个实操中踩得比较深的坑。这些坑不踩一遍，光看架构会觉得链路很顺畅，实际上每一步都可能翻车。

6.1 幻觉问题：AI 把不存在的接口写进了影响面

第一次跑影响面分析时，AI 输出里出现了一个“对接 XX 第三方物流网关”的接口，我们团队当时评审的是纯内部订单模块，根本不存在这个接口。测试同事差点照着这份清单去补一条无效用例。

这个问题的根源在于：LLM 在推理时，会结合它训练语料里的“常见系统形态”来补全逻辑，哪怕我们的系统里没有这个模块，它也会把类似电商系统的经验投射进来。解决方式就是我前面提过的“检索验证”：所有影响面结论必须附带代码目录里的证据文件；检索不到证据的，一律标记 uncertain 并降级为“人工确认项”。同时，我在提示词里强制要求“未在模块清单中出现的系统，一律填 null”，从源头掐断编造的可能性。

6.2 上下文爆炸：长文档怎么切分才不丢关键信息

有一份 PRD 特别长，包含背景调研、历史沿革、完整字段定义、多期规划，加起来四万多字，远超模型可用上下文。第一次我图省事直接截断前 8000 字，结果后面章节里的验收标准全丢了。

后来我改成两层处理：先按一级标题切块，每块单独做摘要和关键信息抽取；再把所有块的摘要汇总成“全局摘要”，同时把验收标准和字段定义这类高价值信息单独做“强提取”。这个方案的核心原则是：摘要会丢细节，所以关键字段不能靠摘要带过，必须用专门的小 Agent 精确抽取。

6.3 “半自动”的边界：这些环节永远不要全自动

链路自动化程度很高，但有三件事我始终坚持保留人工确认节点：

• 业务规则最终确认：涉及钱、账、权限的规则，必须业务方逐条签字。
• 跨团队契约变更：接口字段改动牵扯外部系统时，链路只负责标出来，沟通由人来完成。
• 发布风险的最终判断：AI 可以列出风险清单，但 “能不能扛这个风险” 的决策，人类来拍板。

记住一条原则：自动化链路的输出永远是“建议”，不是“判决”。把会议从“读文档、找证据”压缩成“看建议、做决策”，这才是它的使命。

6.4 模型选型与成本取舍：本地部署不是万能的

最后提一句成本。我的方案里，文档解析和用例生成跑本地小模型，影响面推理偶尔调用更强的大模型 API。这样组合的原因很简单：解析任务是“忠实提取”，本地 14B 量级足够；影响面推理需要更强的关联能力，才值得按量付费去换更好的回答质量。如果所有环节都盲目上最强模型，链路照样能跑，但成本会把人跑破产。选模型的本质是选“任务复杂度”和“模型能力上限”的匹配点，而不是单纯追最强。

7. 一点经验之谈

最后分享几条我在这个项目里沉淀下来的实操体会。如果你也想在自己团队里搭类似的 AI 自动化链路，我的建议是：

第一，从最疼的 1 到 2 个环节开始，不要一下子铺开全链路。我们最先做的是测试场景草稿生成，因为这个环节的痛感最强、见效最快、路径最短——一个脚本、一个 prompt、一个输出示例，当天就能让测试同事用上。有了第一个成功案例，再推影响面分析、需求解析，团队接受度会完全不同。一上来就画一张巨型架构图，只会让所有人觉得这事做不成。

第二，先度量，再动手。我把团队评审耗时按月统计清楚后，优化目标才变成可验证的数字。很多团队做流程优化失败，不是因为方案不对，而是因为原本就没有基线数据，最后方案做完了也不知道到底改善了没有。

第三，给模型输出的每一行都留“出处”。线上跑链路的时候，所有 AI 生成的结论旁边都带上依据：文件路径、命中行数、原文引用。这样做一方面能反杀幻觉，另一方面也让团队敢去信任 AI——不信任的根源，永远是“不知道这个结论是怎么来的”。

这套链路到现在已经跑了两个季度，需求评审的节奏明显变了：会前大家拿到的是结构化简报，会上讨论的是业务决策，而不是现场花半小时猜影响范围。别再买了新工具就完事了，把已有的工具、模型和流程串成一条会自动跑起来的链路，才是真正提效的开始。