技术协议与控制要求生成

业务痛点，讲人话

客户发来一份技术要求。工艺工程师要做的第一件事，是找出"我们以前有没有做过类似的"。

这一步几乎全靠人：翻旧协议、问老同事、在共享盘里按文件名搜。找到之后，比对差异、改几项、走评审、双方会签。整个过程按天计——而销售那头，客户在等报价。

比响应慢更麻烦的是下一步：把签好的技术协议要点，翻译成跨工序的控制要求。这一步要求一个人同时理解好几道工序的相互影响——为了这个低温冲击指标，炼钢要控什么、轧制要控什么、冷却要控什么。能讲清楚的人不多，讲清楚的过程也基本不落文档。

于是这条链上出现了一个典型的组织脆弱点：关键判断集中在少数人身上，且这些判断的依据没有留存。 人一走，能力就断层。

为什么它比看起来难

引用标准是活的。 协议里写"按某标准执行"，那份标准有版本、有条件分支、有引用其他标准的嵌套。同一个牌号在不同版本标准下的判据可能不同。所以解析协议不能只解析协议本身，还要把它引用的标准链展开。

"最像的一份"不好定义。 牌号相同不代表工艺可复用——规格差一档、客户用途不同、执行标准换了版本，都可能让复用变成陷阱。相似度得同时看牌号、规格、性能等级、执行标准、产线，而不是只看文本相似度。

错误代价不对称。 技术协议是签字件。写松了，做不出来要赔；写紧了，本来能接的单接不了。这不是一个"大致对就行"的任务。

要点→控制要求是跨工序推理。 它不是抽取，是设计。同一个性能目标，可以由不同的工艺组合达成，选哪一种取决于产线条件与成本——这一步没有唯一正确答案，只有"合理且可执行"的方案。

数据长什么样

# 技术要求解析后的中间态（教学示意）
source:
type: "customer_spec"
format: "pdf"              # 也常见 word / 邮件正文 / 扫描件
#
parsed:
product_form: "热轧钢板"
thickness_mm: 20           # 量级示意
grade_hint: "355 级低温结构用"
properties:
  - name: "屈服强度"
    min: 355               # 单位 MPa，量级示意
    confidence: 0.95
  - name: "冲击功"
    temperature_c: -40
    min: null              # ★ 原文未给出具体数值
    confidence: 0.30       # 低置信度 → 必须人工澄清
referenced_standards:
  - id: "STD-A"
    version: null          # ★ 客户未指明版本，需确认
#
retrieval:                   # 历史协议复用候选
- agreement_id: "TA-XXXX"
  similarity: 0.91
  diff_items: ["厚度 16 → 20", "冲击温度 -20 → -40"]
- agreement_id: "TA-YYYY"
  similarity: 0.84
  diff_items: ["产线不同", "执行标准版本不同"]

三类数据的现实状况差别很大：

协议与要求文本——量大，格式杂（PDF、Word、邮件正文、扫描件都有），但都在企业内部，取数障碍小。这是这个场景数据条件最好的一块。

标准原文——结构化程度比想象中低。条款有条件分支、有交叉引用，版本管理靠人。把标准做成可机读的约束集合，本身就是一项独立工程。

历史案例台账——理想情况下应该有"哪份协议对应哪个订单、做得顺不顺、有没有出质量问题"的完整关联。现实中这条关联链往往是断的，而它恰恰决定了"复用哪一份"能不能给出有依据的答案。

实施建议

先做检索复用，再做生成。 这个顺序不能反。检索能力单独就有价值，而且它的错误可被人一眼识别（"这份不像"）；生成的错误则可能一路潜伏到生产。先把"找到最像的三份并标出差异"做扎实，再谈生成。

差异项强制评审，不折叠。 复用的价值来自聚焦差异，风险也来自差异识别漏项。所以差异必须显式弹出、逐条确认，而不是收在附录里。参见差异评审。

把标准解析当独立工程做。 不要指望在协议生成的同一个流程里顺便把标准也解析了。标准的版本、条件分支、交叉引用是一套独立的知识结构，值得单独建、单独维护，被多个场景复用。

要点→控制要求这一步，先做草案不做定案。 让它产出一个带推理过程的草案交给工艺人员改。价值不在省下打字时间，在于草案里"为什么这么定"的部分被记录下来了——这是工艺知识沉淀真正可能发生的方式。

评估指标不要只看生成质量。 更值得盯的是：复用推荐的命中率、差异项的漏检率、人工修改量的下降曲线。第二个指标最重要——漏检一个关键差异项的代价，远高于生成文本不够漂亮。