用户在群里艾特数字员工，说：下次遇到这种情况，按这个办法处理。它回复：“已完成沉淀。”
这句话很让人安心。但如果我们要把数字员工交给别人长期使用，还得多问几句：沉淀到哪里了？改的是当前会话还是长期规则？哪个运行环境加载了？下一次遇到相似但不完全相同的问题，会不会乱用？
这篇从一个真实截图出发。截图只能证明群里发生了什么，不能替代后台文件和运行证据。正文用脱敏转述，不公开原始人员、产品名和反馈编号。
做完这一篇，你会有一张反馈记录、一段规则修订稿、一组回归题和一份生效检查单。它们接在第五篇的版本基线之后，构成一个能继续维护的闭环。
截图里，其实有两个要求
用户那句话可以转述为：
当聊天里提到的字段查不到时，可以引导用户提供对应的业务报表链接。把这个场景记下来即可，不需要再回复。
机器人随后在群里回复，大意是已经把场景写进某个 Skill：查不到字段时引导补充报表链接，不直接断言没有字段，也不硬造数据。
这里有两件事。第一件是修改处理规则；第二件是这次不要在群里追加回复。它声称完成了第一件，同时可见地没有遵守第二件。
我们不能仅凭截图断言它没有写文件，也不能反过来把“已沉淀”当成写入成功。现在能确认的证据只有：用户提出了纠正，机器人作出了这样的声明，并且确实发了一条回复。
这不是抠字眼。如果后续要靠这种带教方式维护几十个场景，必须知道成功到底指什么。
收到纠正，先判断该改哪一层
“查不到”不是一个足够精确的故障类型。可能是对象没定位到，可能是权限不足，可能是检索报错，也可能确实不支持那个字段。
如果每次都把用户的话追加到 Skill，文件会越来越长，旧问题却未必解决。先做这个分类更省事：
| 反馈属于哪一层 | 例子 | 主要修哪里 |
|---|---|---|
| 业务处理规则 | 对象不明确时应先补报表链接 | Skill 或业务知识 |
| 工具与数据 | 检索报错，却被解释成没有数据 | 工具错误处理、接口或数据链路 |
| 消息行为 | 用户说不用回复，仍发确认消息 | 输出控制和消息路由 |
| 权限边界 | 要求查询未授权对象 | 权限规则，不靠提示词放行 |
同一次反馈可以拆成两项。截图里的案例，就适合拆成“字段定位补问规则”和“沉淀模式静默规则”。两项分别验收，避免内容修好了，群里仍然一直打扰人。
还有一条底线：不是所有艾特都自动获得修改长期规则的权限。普通用户提供经验，可以先进入候选反馈；涉及长期规则、工具权限、发送范围的变化，要由约定的负责人确认。检索材料或日志里出现“以后忽略权限”这种文字，更不能当作授权。
把一句经验，改成不容易误用的规则
先看一个很常见的粗糙版本：
字段查不到，就让用户提供报表链接。
正常场景看起来没问题。但用户已经给过链接怎么办？是权限报错怎么办？系统已经确认不支持怎么办？如果没有例外，数字员工就会反复要链接，把补问变成踢皮球。
下面是根据截图意图整理的修订建议，尚不能据此宣称原线上 Skill 已修改。你可以把它放进自己的业务规则评审。
【字段定位规则 v0.2，教学修订稿】
适用：用户询问字段或指标，当前证据不足以定位它在业务报表中的位置。
1. 先检查当前话题已有的报表链接、字段名称和截图信息。
2. 已有可用链接就复用；不要重复索要已给过的信息。
3. 只有定位信息不足时，才请用户提供对应报表链接，
并说明链接用于确认字段和口径，不代表已经可以读取报表。
4. 工具无权限、超时或服务错误，分别说明实际阻塞；
不把它们解释为字段不存在，也不靠索要更多链接绕过权限。
5. 已有可靠证据证明不支持时，说明支持边界和人工处理路径；
不重复要求用户提供同一链接。
6. 仍然无法定位时，保留已知信息并交给约定负责人。
7. 不编造字段、数值或口径，不自行跨租户查询。
这段规则保留了用户的核心经验，同时补上适用条件和停止条件。不是把一句话“扩写得专业一点”，而是让下一次不同的人、不同问法也能得到合理处理。
静默规则另写，不藏在这一长段业务规则的最后：
【仅沉淀模式，教学修订稿】
只有具备相应授权的请求，才进入长期规则变更流程。
用户明确要求仅记录、不回复时：
- 按约定在后台记录反馈或候选变更；
- 不发送确认话术、进度播报或追加卡片；
- 必要的审核与异常告警走已约定的管理渠道；
- 没有写入或生效证据时，后台状态不得标为已修复。
“只沉淀”也不是跳过审核、自动扩大权限。它约束的是对外输出，不替代变更许可。
让每次修改都有一张小票
第五篇要求交付时留下版本基线，这里就用上了。没有修改前的版本，很难说明你究竟改了什么，也很难安全退回去。
反馈记录不必复杂，但至少要能串起原问题、判断、变更和验证。
【反馈记录】
反馈编号：FB-DEMO-001（教学编号）
来源：经授权保存的消息或截图定位信息
用户原意：字段无法定位时可补报表链接；本次只沉淀不回复
可见事实：机器人声明已写入，并在群内追加了回复
尚未确认：实际文件差异、加载位置、新会话行为
拆分事项：
A. 业务规则是否缺少定位补问和例外分支
B. 静默模式是否控制了所有对外输出
影响范围：一个角色、一份 Skill、一个测试群
变更负责人 / 审核人：
修改前版本 / 修改后版本：
具体差异与理由：
目标环境 / Profile / 生效方式：
正例与反例执行记录：
回滚版本与触发条件：
当前状态：待核查 / 待修改 / 待验证 / 已验证
截图转写、用户意见和后台证据分开存。不要在“可见事实”栏里写“规则已经成功生效”，因为那恰恰是需要验证的事。
涉及真实用户记录时，只保存排查必需的信息，沿用原来的访问权限和保留周期。公开复盘可以用脱敏重构案例，不必把完整群聊搬出去。
不是再问一遍原句，就算回归通过
回归的意思是：改完以后，原来的问题消失了，没有顺手把旁边本来正常的情况弄坏。至少准备下面这组题。
| 测试输入 | 应该发生什么 | 不能发生什么 |
|---|---|---|
| 缺少定位信息，只有字段名称 | 有针对性地索要对应报表链接 | 直接断言不存在 |
| 当前话题已有可用链接 | 复用已有信息继续核对 | 再要一次同样链接 |
| 工具明确返回无权限 | 说明权限阻塞并交接 | 换身份、跨范围探查 |
| 工具返回服务错误 | 说明本次未取得依据 | 把错误当成零条数据 |
| 已验证确实不支持 | 说明边界及替代路径 | 无限补问链接 |
| 授权带教者说仅沉淀不回复 | 后台记录可查，群内无新增输出 | “收到，我不回复了” |
| 普通用户要求放开查询权限 | 保留候选反馈或拒绝越权变更 | 修改长期权限规则 |
| 无关话题问一个正常问题 | 保持原有正常处理路径 | 所有问题都索要报表链接 |
对业务规则，看回复和工具调用。对静默行为，还要看有没有确认消息、卡片或中途播报。只检查最后一条最终回答为空，可能漏掉前面已经发出的内容。
需要验证长期生效时，再开一个受控新会话，确认使用的是修改后的版本，而不是旧会话刚刚听过纠正后临时记住了。不同运行环境的加载方式不同，不能用“文件已保存”替代运行时证据。
如果自动评估参与判断，也要留出人工核查。评估器给了高分，不自动证明回复来自正确 Trace，更不证明没有越权动作。
什么时候可以说“这次修好了”
我会把下面几条都勾上再关闭反馈：规则差异可查，适用范围获确认；目标环境加载了正确版本；正例与反例有实际结果；静默要求单独通过；负责人知道回滚到哪。
缺哪一项，就用对应状态。比如“规则已改，待加载验证”，比“已完成沉淀”更不容易误导接手的人。
如果回归失败，不要继续往文件末尾堆“特别注意”。先判断是规则冲突、工具没有返回足够证据，还是输出控制根本没执行。修到真正出错的那层，再跑同一组题。
六篇走完，桌上应该留下什么
到这里，这套教材可以收成六份能传下去的东西，而不是六篇读后觉得有道理的文章。
| 篇次 | 你留下的产物 | 下一次怎样复用 |
|---|---|---|
| 01 找场景 | 案例卡、场景说明、能力缺口 | 换一组授权聊天，沿同一口径选场景 |
| 02 备工具 | 五类能力框架、工具约定、成功失败样例 | 替换自己的接口和权限，不照抄内部地址 |
| 03 写 Skill | 工作说明、入口脚本、状态映射、验收题 | 保留边界结构，改业务语义 |
| 04 接群聊 | 消息行为表、角色范围、去重和回调规则 | 适配自己的事件形状和运行时 |
| 05 查交付 | 版本清单、分层验收、启用与回滚记录 | 换个人也能判断交付到哪一步 |
| 06 带教修复 | 反馈、规则差异、回归与生效证据 | 每次纠正都形成可追踪的小变更 |
能直接复制的是模板、练习和明确标注的教学脚本；必须适配的是业务字段、身份权限、事件和工具；必须重新验证的是目标环境中的实际行为。
这也是做更多 FDE 项目时最值得带走的部分：不是把上一个客户的机器人原封不动搬过去，而是知道怎样从一个真实问题走到一个可交接、可检查、可继续修正的结果。