先建术语与底稿
行业术语、缩写与内部叫法不统一，模型很难稳定理解。怎么做：整理术语表，标注同义词与禁用表述；把核心制度、作业指导书整理成结构清晰的底稿，注明版本与责任人，后续按缺口补充，避免整理一次就停。
任务分层
把需求拆成检索、抽取、生成与计算四类，难度与验收方式不同。为什么先分层：不同任务适合的技术形态不同，混在一起会导致方案臃肿。怎么做：每类任务列出典型用例与期望输出格式，便于分别验收。
评测集与盲评
评测集由业务出题、专家定答案，评分人不知道配置来源。怎么做：每类任务至少一组题，覆盖常见与难例；记录错误类型，形成可复跑的回归集；定期更新，避免题目泄露给供应商导致成绩虚高，也要防止题目外流。
形态按序选择
顺序是检索增强、提示与工具调用、微调、继续预训练，成本与门槛依次上升。为什么按序：多数任务在前两步即可满足，跳过会增加维护负担。怎么做：每一步都用同一评测集比较，未达标再进入下一步。
更新机制与验收
约定知识更新触发条件、责任人、响应时限，并把验收指标写进合同。边界：验收由客户方业务负责人签认，实施方提供测试记录与方法说明，不替代业务判断，也不承诺具体效果数字，避免验收时各说各话。
适用与不适用
适合谁
- 准备启动行业模型项目的业务与技术联合团队
- 已有大量行业文档、希望提升复用率的企业
- 需要向管理层说明实施路径的负责人
不适合谁
- 没有业务专家参与、也无稳定文档来源的团队
- 期望直接采购一个现成行业大脑的组织
典型场景
某化工企业启动工艺知识助手，先整理术语表与操作规程底稿，把需求分成检索与抽取两类，各建一组评测题。第一轮用检索增强，抽取任务改用工具调用模板，评测达标后才进入试点。合同中写入季度更新与验收指标，业务负责人签认后方可扩大范围。
可执行步骤
- 整理术语表与核心制度底稿，逐份标注版本、责任人与生效日期，便于检索。
- 把需求拆成检索、抽取、生成与计算四类，逐类列出典型用例与期望输出格式。
- 每类任务各建一组评测题，由业务专家定答案，再组织盲评，评分人回避利益冲突。
- 按检索、提示与工具、微调、继续预训练的顺序逐级尝试，每级用同一评测集。
- 约定更新触发条件、责任人与响应时限，并一并写入验收条款，逐项签认。
常见坑
- 跳过术语整理直接上线，模型对内部叫法理解错误，回答频繁返工，用户逐渐不用，改造成本更高。
- 任务不分层，用一套方案覆盖所有需求，系统复杂且难以维护，故障也难定位，迭代随之变慢。
- 评测题泄露给供应商，测试成绩虚高，试点阶段问题集中暴露，验收结论失效，需要重新建题。
- 一上来就做微调，缺少评测基线，无法判断是否真的变好，投入与产出难以对账，容易误判。
自检与验收清单
- 术语表与制度底稿是否完成，并标注版本与责任人
- 任务是否分层，且每类都有典型用例与验收方式
- 评测题是否由业务出题、专家定答案并组织盲评
- 技术形态是否按成本顺序逐级验证、逐级比较
- 更新触发条件与验收指标是否写入合同条款中
常见问题
底稿要整理到什么程度？
先覆盖高频问题涉及的范围，不必一次整理全部文档。关键是结构清晰、版本可追溯、责任人明确；后续按使用中暴露的缺口补充，比一次性大整理更容易坚持。
评测集要多少题？
每类任务一组能覆盖常见与难例的题目即可起步，重点是能复跑与版本化。随着错误案例积累，把真实失败案例补进题库，评测集才会越来越贴近业务实际，结论也更稳。
为什么不建议先微调？
微调需要高质量标注数据与持续维护，成本高于检索增强。若检索已能满足多数任务，微调的边际收益有限；确有格式或术语强约束时再做，并用同一评测集验证提升。