ChatGPT需求文档学习：如何用AI技术提升需求分析效率

ChatGPT需求文档学习：如何用AI技术提升需求分析效率

需求文档动辄几十页，读完再拆功能点、找矛盾、写用例，没个两三天搞不定。
本文记录我如何把 ChatGPT 塞进需求流程，让 AI 当“第一遍过滤器”，把 80% 的机械活 5 分钟干完，留时间给人类做真正需要创造力的判断。

1. 传统需求分析的“三宗罪”

1. 耗时：一份 60 页 PRD，通读 + 标注 + 评审，平均 6.5 人时。
2. 主观：同样一段描述，前端读出“组件复用”，后端读出“接口重写”，谁对谁错？
3. 遗漏：人眼对“隐性依赖”极不敏感，上线后才发现“注册流程依赖优惠券状态”，返工成本爆炸。

一句话：人力做全文检索 + 语义归纳，性价比太低。

2. 技术选型：为什么最后留下 ChatGPT

我对比了三种常见方案（均用同一批 10 份英文/中文需求文档测试）：

结论：

• 若有成规模标注数据，BERT 系列更准；
• 需求文档常来自不同客户、领域，标注永远跟不上；
• ChatGPT 用提示工程就能切换上下文，省去训练、部署、运维成本，最适合“今天接需求、明天出分析”的节奏。

3. 核心实现：让 GPT 当“需求分析师”

3.1 流程总览

PDF/Markdown → 纯文本分块 → 意图识别 → 实体抽取 → 冲突检测 → 结构化 JSON → 人工复核

3.2 环境一分钟搭好

python -m venv venv source venv/bin/activate pip install openai pandas tiktoken pypdf tqdm

3.3 关键代码（可直接粘 Jupyter）

""" 需求文档智能解析器 依赖：openai>=1.0, tiktoken, pypdf """ import openai, tiktoken, json, re from typing import List, Dict openai.api_key = "sk-xxx" # 火山引擎也可直接替换 endpoint MODEL = "gpt-3.5-turbo-16k" # 长文本友好 ENCODER = tiktoken.encoding_for_model(MODEL) MAX_TOKENS = 16000 # 留 2k 给输出 def split_text(path: str, chunk_tokens: int = 6000) -> List[str]: """按句子边界分块，防止截断""" from pypdf import PdfReader text = "\n".join(page.extract_text() for page in PdfReader(path).pages) sentences = re.split(r'(?<=[。！？.!?])\s*', text) chunks, cur = [], [] cur_len = 0 for s in sentences: tk = len(ENCODER.encode(s)) if cur_len + tk > chunk_tokens: chunks.append("".join(cur)) cur, cur_len = [s], tk else: cur.append(s) cur_len += tk if cur: chunks.append("".join(cur)) return chunks def gpt_extract(chunk: str) -> Dict: """单块提取：意图、实体、矛盾点""" sys_msg = ("你是需求分析师，请严格按 JSON 输出：" "{\"intents\":[{\"name\":\"...\",\"description\":\"...\"}]," "\"entities\":[{\"type\":\"...\",\"value\":\"...\"}]," "\"conflicts\":[\"...\"]}") user = f"以下需求文本：\n{chunk}\n请提取意图、实体、潜在矛盾。" rsp = openai.ChatCompletion.create( model=MODEL, messages=[{"role": "system", "content": sys_msg}, {"role": "user", "content": user}], temperature=0.1 ) return json.loads(rsp.choices[0].message.content) def merge_results(results: List[Dict]) -> Dict: """多块结果合并、去重""" intents = {i["name"]: i for r in results for i in r["intents"]} entities = {(e["type"], e["value"]) for r in results for e in r["entities"]} conflicts = {c for r in results for c in r["conflicts"]} return { "intents": list(intents.values()), "entities": [{"type": t[0], "value": t[1]} for t in entities], "conflicts": list(conflicts) } # 一键运行 if __name__ == "__main__": chunks = split_text("requirements.pdf") mid = [gpt_extract(c) for c in chunks] final = merge_results(mid) print(json.dumps(final, ensure_ascii=False, indent=2))

运行后得到：

{ "intents": [ {"name": "用户注册", "description": "支持手机号+验证码注册"}, {"name": "优惠券领取", "description": "注册后自动推送新人优惠券"} ], "entities": [ {"type": "业务规则", "value": "优惠券有效期 30 天"}, {"type": "角色", "value": "普通用户"} ], "conflicts": [ "优惠券有效期在注册流程未提及，可能导致用户投诉" ] }

3.4 结构化输出到 Confluence

用atlassian-python-api把 JSON 一键写成表格，评审会前发给大家，人类只需聚焦红色冲突列，效率翻倍。

4. 性能实测：时间与准确率

测试集：

• S：30 页（≈1.2 万 token）
• M：120 页（≈5 万 token）
• L：300 页（≈12 万 token）

结论：

• 16k 模型一次可吞 6k token 输入 + 2k 输出，单块耗时 8-10s；
• 线性分块即可横向扩展，无需 GPU；
• 准确率随规模略降，但仍高过人工“第一遍”。

5. 避坑指南：让 AI 少“脑补”

1. 模糊需求
   在提示里加“若需求不明确，请输出 UNKNOWN，不要猜测”。UNKNOWN 高亮后人工回访客户，比让 AI 编故事靠谱。
2. 避免误解
   采用“角色+任务+输出格式”三段式提示，temperature 固定在 0.1；
   对数值型实体（金额、天数）加正则后校验，不符的自动标红。
3. 结果验证
   把冲突列表反向喂给 GPT，让它生成测试用例，再用文本相似度对比原始需求，覆盖率 <90% 的段落人工复审。
   形成“AI 初筛 → 测试用例回环 → 人工抽样”三层质量门。

6. 把流程嫁接到现有 DevOps

• 触发点：需求文档 Pull Request 创建时，GitHub Action 调用脚本，评论里贴结构化表格。
• 门禁：冲突数 >0 或 UNKNOWN 占比 >5%，PR 无法合并。
• 可视化：Redash 仪表盘每周统计“需求缺陷密度”，观察 AI 介入前后变化，我们团队 6 周内需求评审时长下降 42%，返工率下降 30%。

7. 小结与三个思考题

用 ChatGPT 做需求文档学习，本质是把“泛读”外包给大模型，人类保留“精读 + 决策”。
如果你也受够了通宵评审会，不妨把上面的脚本跑一遍，再逐步把提示、校验、可视化打磨成团队规范。

思考题：

1. 当需求文档跨多个语言（中英混合）时，如何设计分块与提示才能保证实体抽取不丢失？
2. 如果公司数据不能出内网，本地 7B 模型能否达到同等效果？你会怎样量化评估？
3. 在敏捷迭代中，需求每日变化，如何增量更新结构化结果而非全量重跑？

实验推荐：
想亲手把“实时语音对话”这套交互能力搬到自己的项目里？我顺手体验了从0打造个人豆包实时通话AI动手实验，跟着文档 30 分钟就能跑通 ASR→LLM→TTS 全链路，比自己拼接接口省事多了，小白也能顺利玩起来。