把老员工的经验写进系统：规则、示例与反馈三条路

业务经验多只在人脑里。本文给出三条写入路径（规则/示例/反馈）各自适合什么与注意点、三者如何配合、怎么验证经验真的被写进去，以及一条「离职后能否复现」的判据。

老员工的经验，怎么变成系统的能力

业务里最有价值的往往是"**老员工的做法**" ✔：什么情况该拒绝、什么话术更合适、

哪些字段容易填错 ✔。但这些经验大多**只在人脑子里** ✗，AI 系统自然学不到 ✔。

**三条路把经验写进系统** ✔：规则、示例、反馈 ✔（按可靠性排序 ✔）。

适合**边界清晰**的经验 ✔：必填字段、金额上限、必须人工确认的情形 ✔。

写成**代码规则** ✔（可测试 ✔、可版本化 ✔）；

不要用自然语言写在提示词里 ✔（见"约束变校验"那篇 ✔）；

每条规则配一个**正例与反例** ✔（便于回归 ✔）。

**注意**：规则太密会僵化 ✗（新情况全被拒 ✔）→ 需要"例外通道" ✔（人工覆盖并记录 ✔）。

适合**风格与判断口径** ✔：什么算"部分相关"、什么语气合适 ✔。

从**真实历史案例**里挑（含**用户最终接受的版本** ✔ —— 这是最好的示例 ✔）；

每个示例写清"**为什么这样处理**" ✔（否则后人不知道边界在哪 ✔）；

示例**定期更新** ✔（业务变了，示例会过时 ✔）。

适合**持续演进** ✔：线上点踩、人工修改、转人工记录 ✔。

**必须接请求上下文**（否则无法归因 ✔ —— 见反馈回填那篇 ✔）；

**必须人工确认**（点踩 ≠ 错 ✔）；

**必须进评测集**（否则修了也不知道有没有复发 ✔）。

**关键**：反馈是"发现问题的雷达" ✗ ✔，"规则与示例"才是"解决问题的手段" ✔。

```

规则：兜住硬边界（安全、金额、权限 ✔）

示例：钉住软口径（语气、判断标准 ✔）

反馈：发现新情况 → 转成新规则或新示例 ✔

```

**只写规则** ✗ → 僵硬、体验差 ✔；**只给示例** ✗ → 边界不牢、易越界 ✔；

**只收反馈** ✗ → 永远在打补丁 ✔。

把老员工的"典型 20 个判断"做成评测样本 ✔ → 看系统是否与之一致 ✔；

不一致的地方**回到三条路**：是该加规则？加示例？还是系统确实该不同 ✔；

**定期请老员工复核** ✔（他们最容易发现"系统判断变了" ✔）。

> 一位资深员工离职后 ✔，他的判断经验还能在系统里**被复现**吗 ✔？

> 不能，说明经验还停在个人层面 ✗。