把 SOR 解析交给 AI 先做一遍，三百页规格书新人两周接得住
一句话 三百页的 SOR，AI 一晚拆成需求清单、术语表和门槛标注，新人照着清单接手、老人只抽查高风险条目；但清单写得出「客户要求什么」，写不出「我们该不该答应」——这一步仍要人做。
三百页的规格书现在是怎么交接给新人的
客户把 SOR 发过来，通常是一个两三百页的 PDF：前几章是商务和资格要求，中间是技术条款，后面挂着引用标准、图纸编号和一堆附录。真正决定「这单能不能接、成本多少」的条款，往往散在第 38 页、第 214 页和附录 C。
现在这份文件是怎么交接的？新人接手，对着屏幕逐页啃，术语不懂就逮谁问谁——DFMEA 要不要做、PPAP 提交到哪一级、IMDS 报告谁出。老人在赶自己的项目，没空系统地带，只能饭桌上见缝插针补几句。读到后面，前面记的笔记已经对不上页码了。
代价：
- 新人读懂一份 SOR 要 2–3 周，其中约一周耗在猜术语和找条款上
- 资格、认证类条款漏看一条，立项甚至投完标才发现，前面投入全部作废——这类条款长什么样，招标文件解析那篇里有相近的画象
- 老人口头交接一单占 20–30 小时，而且随叫随到，自己的活被切得稀碎
SOR 解析之后，新人第一天拿到什么
拆完之后，新人第一天拿到的不是 PDF，是三样东西。
第一张是结构化需求清单：每条需求有编号、原文出处页码、属于技术还是商务、优先级和验收口径，能直接分到具体的人头上。第二张是术语表：SOR 里出现的缩写和行业行话逐条解释，标注出现在哪一章——新人不用再逮人问。第三张是门槛标注：资格、认证、禁限用、保密要求，从十几个章节汇总到一处，每条带页码，老师傅按图索骥抽查就行。
之后的工作方式变成：新人按清单逐项核对、认领、标疑点；老人只看被标成「门槛」和「冲突」的少数条目。
| 现在 | 之后 | |
|---|---|---|
| 新人上手 | 逐页啃 2–3 周 | 按清单核对 3–5 天 |
| 术语问题 | 逮谁问谁 | 术语表先查一遍 |
| 门槛条款 | 散在各章靠运气 | 汇总一处带页码 |
| 老人角色 | 全程陪读 | 只抽查高风险条目 |
| 客户改版 | 整本重读 | 只读改动的条目 |
最后一行是长期价值。客户改版是常态，新旧版本差异比对做的就是把「改了什么、影响谁」变成一张对照表，而不是让新人再啃一遍新版本。
哪些判断 AI 替不了人做
诚实说边界。
拆得全，不等于判断得对。清单回答「客户要求了什么」，回答不了「我们该不该答应、报什么价、技术路线选哪条」——这些理解之后的工程判断只能人来下。AI 把依据摆齐，拍板还是你。
原文含糊的地方，它只标注「需确认」，不会替你编答案。客户写一句「需满足行业最佳实践」，机器负责标出来，谈成什么样是你的事。
前后冲突的条款它能标出矛盾，但让步还是找客户澄清，是商务决策，不在清单里。
还有一层它够不到：SOR 里引用的图纸、标准原文、附件，解析只到 SOR 这一层。要把整条引用链读透，属于更深的文档处理，是另一个话题。
上线前要翻出哪些东西、谁投入几天
- 数据：一两份真实 SOR（新旧版各一份更好）、过往投标或立项记录、老人的交接笔记。用真实文档测试，别用供应商的样例
- 人：研发负责人定「什么叫拆对了」的验收口径；一位熟悉业务的工程师花 2–3 天抽查核对结果。这是你要批的主要成本
- 系统：只读文档，不动 ERP/PLM，不改任何现有系统的配置
- 部署：涉密 SOR 走本地私有；脱敏样例可以先在云端验证效果
成本、周期，以及怎么判断值不值
这类项目按 SOR 的数量和篇幅估工作量，PoC 阶段用一份真实文档跑通验证，通常一到两周。
判断值不值，先算两笔旧账：一年接几个新项目，每次交接老人陪进去多少小时；过去几年有没有因为漏看条款废过标、返过工。一年新项目 6 个以上、每次交接老人投入 20 小时以上，当年回收是大概率事件。反之，团队三年不换人、一年只接一两个项目，让老人写一份导读就够了——这件事不该做。
案例：一年省回 160 个小时，和一次 6 万元的教训
一家给整车厂做配套件的工厂，一年接 8 个新客户项目，平均每个 SOR 280 页。假设如下，可以换成你厂的数字复算：
- 以前：新人读懂一份 SOR 要 2.5 周，其中约 1 周在猜术语；老人陪同交接 25 小时
- 之后：新人按清单核对 4 天，老人只抽查 30 条高风险条款，约 5 小时
一年 8 个项目，老人省下的时间是 (25−5)×8 = 160 小时，约 20 个工作日，重新回到他自己的项目里。新人每单早 8.5 天进入设计，一年累计多出约 68 个设计工作日。
另一笔账：过去两年，厂里有一次因漏看认证条款、投完标才发现不满足资格，标书投入约 6 万元作废。门槛标注把这类条款固定在清单第一屏，漏看的概率大幅下降——这笔账没法精确折算，但一次事故就够覆盖好几年的服务费。
假设里最关键的数字是「老人 25 小时」。如果你厂实际只有 5 小时，总账就要重算——先把自己的数代进去，再决定做不做。
常见问题
SOR 是什么，跟我们内部的需求文档是一回事吗？
SOR 是 Statement of Requirements，客户写的需求规格书，比内部需求文档正式得多：它决定你投不投、按什么报价、验收按什么标准算。两三百页里混着技术条款、商务门槛、认证要求，不拆开来读，很容易漏掉决定成本的那几页。
拆出来的清单，新人能直接用吗？
不能直接当最终结论。拆出来的是带原文出处的核对清单：每条需求标注在第几章第几页。新人按清单接手，老师傅只抽查高风险条目——认证、禁限用、验收标准，而不是把三百页重读一遍。AI 负责找全，人负责判断。
我们的 SOR 是中英文混排、全是表格，也能拆吗？
能，但这恰恰是最考验能力的地方。工业客户的 SOR 普遍中英混排，条款、引用标准、图纸编号夹在表格和附录里，通用聊天工具最容易在这里读丢结构。选型时拿你们一份真实的 SOR 当场测试，术语表准不准、条款定位对不对，一试就知道。
老人没空审核 AI 拆的结果，怎么办？
审核负担比想象小：老师傅不用通读，只处理被标为「门槛」「冲突」「需确认」的少数条目，一份三百页的 SOR 通常浓缩成二三十条要他点头。如果连这二三十条都没人看，问题不在工具，在这个岗位本来就没人负责。
客户经常改 SOR，拆一次就废了吗？
不废。客户改版后对新版再跑一次，和老版的结果做差异比对，改动集中在哪些需求、影响哪些任务，直接列成对照表。第一次拆出来的是资产，改版比对才是长期价值——新人从此只读改动，不再整本重啃。
我们研发团队十几个人，值不值得做？
看两件事：一年接多少新项目，老人带新人占多少工时。一年新项目少于五六个、团队三年不换人，必要性不大，写一份导读更划算；如果每月都有新项目进来、每次交接老人要陪一个月以上，这件事通常当年就能收回投入。
本文由 OnlyFDE 编辑部与 AI 共同创作，经人工审校。OnlyFDE 编辑部是 杭州妙用智能科技有限公司的工程师与创始人； 我们卖服务，也认真写「做不到什么」。