反馈是发现问题的雷达，规则与示例才是解决问题的手段。
老员工的经验，怎么变成系统的能力
业务里最有价值的往往是"老员工的做法" ✔：什么情况该拒绝、什么话术更合适、
哪些字段容易填错 ✔。但这些经验大多只在人脑子里 ✗，AI 系统自然学不到 ✔。
三条路把经验写进系统 ✔：规则、示例、反馈 ✔（按可靠性排序 ✔）。
一、规则（最可靠，最不灵活）
适合边界清晰的经验 ✔：必填字段、金额上限、必须人工确认的情形 ✔。
· 写成代码规则 ✔（可测试 ✔、可版本化 ✔）；
· 不要用自然语言写在提示词里 ✔（见"约束变校验"那篇 ✔）；
· 每条规则配一个正例与反例 ✔（便于回归 ✔）。
注意：规则太密会僵化 ✗（新情况全被拒 ✔）→ 需要"例外通道" ✔（人工覆盖并记录 ✔）。
二、示例（灵活，成本低）
适合风格与判断口径 ✔：什么算"部分相关"、什么语气合适 ✔。
· 从真实历史案例里挑（含用户最终接受的版本 ✔ —— 这是最好的示例 ✔）；
· 每个示例写清"为什么这样处理" ✔（否则后人不知道边界在哪 ✔）；
· 示例定期更新 ✔（业务变了，示例会过时 ✔）。
三、反馈（最贴近现实，需要工程化）
适合持续演进 ✔：线上点踩、人工修改、转人工记录 ✔。
· 必须接请求上下文（否则无法归因 ✔ —— 见反馈回填那篇 ✔）；
· 必须人工确认（点踩 ≠ 错 ✔）；
· 必须进评测集（否则修了也不知道有没有复发 ✔）。
关键：反馈是"发现问题的雷达" ✗ ✔，"规则与示例"才是"解决问题的手段" ✔。
四、三条路的配合（不要只走一条）
```
规则：兜住硬边界（安全、金额、权限 ✔）
示例：钉住软口径（语气、判断标准 ✔）
反馈：发现新情况 → 转成新规则或新示例 ✔
```
只写规则 ✗ → 僵硬、体验差 ✔；只给示例 ✗ → 边界不牢、易越界 ✔；
只收反馈 ✗ → 永远在打补丁 ✔。
五、怎么验证经验真的被写进去了
· 把老员工的"典型 20 个判断"做成评测样本 ✔ → 看系统是否与之一致 ✔；
· 不一致的地方回到三条路：是该加规则？加示例？还是系统确实该不同 ✔；
· 定期请老员工复核 ✔（他们最容易发现"系统判断变了" ✔）。
一条判据
> 一位资深员工离职后 ✔，他的判断经验还能在系统里被复现吗 ✔？
> 不能，说明经验还停在个人层面 ✗。
本文由云枢 AI导航整理，内容以官方来源为准。
相关文章
顺序阅读
← 上一篇：输入规范化：先把用户输入弄干净
下一篇：变更说明怎么写：给未来同事与现在用户的两份 →
第 108 / 171 篇