上个月答错的，这个月不会再错
老张发现团队里的 AI 系统"在偷偷进步"，纯属偶然。
事情的起因和客服 bot 有关——这是同团队另一套面向客户的 Agent，和阿行共享基础设施但各管各的事。有一天，老张在客户群里看到客服 bot 发错了一条回复——不是答非所问，而是把一个内部协作的草稿，原封不动发给了客户。客户看到的是"可以直接这样回复客户：……"这种本该只在内部出现的文字。
客户没说什么，但老张看到了，心里咯噔一下。这种事，丢人。
他本来想找客服 bot 的负责人说一声，让他改改。但他翻了翻记录，发现——客服 bot 上个月也犯过一模一样的错。 那次他也看到了，也想让人改，后来一忙就忘了。上个月的监督 AI 虽然出了日报、也给了优化建议，但那条建议落在了周报的候选清单里，还没被选中落地就又被新的候选挤掉了。换句话说，闭环在"建议→落地"这一环断了——不是没发现，是发现了但没跟进。
老张心里有点烦。他想：这个错，是不是要永远犯下去？
一个让老张意外的发现
老张决定这次不能算了。他去找客服 bot 的负责人——结果发现，负责人已经改过了。
不是老张提醒的。是另一个 AI 干的。
原来，团队里除了阿行，还有一个专门"监督"客服 bot 的 AI。它每天凌晨会拉取客服群过去一天的对话，逐条分析：客服 bot 哪句答得好、哪句答得不好、用户满不满意、问题是出在规则上还是知识库里。
老张翻了一下这个"监督 AI"的记录，愣住了。
从 2026-05-27 到 07-28，它累计跑了 49 次巡检，产出了对应的 49 份日报。49 次是这段时间内的实际运行次数，不代表每天都无中断。每次巡检的日报里，它都会挑出有问题的对话，给出精确到文件、精确到段落、可以直接粘贴的修改方案。
比如，针对"把内部草稿发给客户"这个问题，监督 AI 给出的建议是这样的：
问题：客服把本应发给内部协作者的代发文案，直接发进了用户可见的线程。
建议位置：规则文件中"在任何用户可见的发送前，先做一次内部草稿清洗检查"段落后。
建议文案（可直接粘贴）：如果当前回复里出现"可以直接回复客户""建议这样回复"等草稿触发词，不要发送原文。命中后必须整段改写成面向提问者的最终回复。
老张看完这份建议，第一反应是：这比我让人去改，改得还清楚。 它精确到了"在哪一段后面加""加什么文案"，从"发现问题"到"修复问题"，中间没有任何模糊地带。
但建议给了，真的改了吗？
老张的下一个问题是：这些建议，真的落地了吗？ 给建议谁都会，改了才算数。
他去查了客服 bot 规则文件的修改历史。
答案让他有点意外：真的改了，而且形成了相对稳定的节奏。 修改历史里大约每周有一次"根据本周客户反馈巡检，更新规则和知识"的记录。两个多月里，它完成了 6 次周度更新。每一次更新会把那段时间的日报汇总，提炼出真正值得固化的优化项，然后实际修改规则文件和知识库。
以其中一份周报为例，那一周实际落地了：规则文件里补充了 7 条新约束（比如"用户已经明确目标时不要再反问背景""已经收口后不要再改口说缺信息"），知识库里新增了 2 个常见问题的标准答案。
这些改动一旦落地，客服 bot 下一周的服务就按新规则执行了。上个月犯过的错，规则更新后同类错误的发生率下降了。
老张盯着那份修改历史，慢慢意识到一件事：客服 bot 上线时，远没有现在这么好用。 它是靠这套"每天发现、每周修改"的闭环，一点一点变好的。
为什么不直接"重新训练模型"
老张把这个发现讲给一个懂技术的朋友听，朋友问了一个很自然的问题：让 AI 变好，不是应该重新训练模型吗？为什么绕这么大一圈，去改规则和知识库？
老张想了想，说：因为对眼前这个具体错误，先改规则和知识库更直接、更可控。
如果说的是从头训练基础模型，确实需要海量数据、算力和专业团队，普通产品团队不会走这条路。fine-tuning 的门槛低得多，也能改善特定任务行为，但仍需要准备高质量样本和评估集，不能保证一次训练就修好某个具体场景。
而改规则和知识库，是精确的、低成本的、可立即验证的。发现"客服会把草稿发出去"，就在规则文件里加一条，下一轮就能验证是否生效。对大多数产品团队，先修规则、知识、检索和流程，通常比模型重训更现实、更便宜、见效更快；但在输出格式一致性、专门任务适配或成本优化等场景，fine-tuning 仍然有明确的适用价值。
老张说，这个闭环的本质是：承认模型本身是黑箱、是不可控的，所以把"让 AI 变好"这件事，从"改模型"降维成了"改规则和知识"——后者是人能掌控的。
这又是一次"用 AI 治理 AI"
老张后来把这个闭环和第 3 篇讲的"用 AI review 代码"放在一起看，发现它们是同一个思想的两次应用。
第 3 篇：阿行辅助写的代码，由另一层 AI 来 review。 这一篇：客服 bot 做的服务，由另一个 AI 来巡检。
共性是：让 AI 的产出被另一层 AI 持续审视，并把审视结果反馈回去，形成改进。 区别是，第 3 篇的反馈是一次性的（这次代码哪里有问题），这一篇的反馈是持续的、累积的——它让客服 bot 的同类错误发生率逐步下降。
这也呼应了第 4 篇那条铁律。监督 AI 如果判断"这个问题不是规则或知识库能解决的，是产品本身的缺陷"，它会明确标注"暂不处理"并说明原因，而不会去强行改规则来掩盖产品问题。该回给产品的，回到产品；该改规则的，改规则。边界依然清晰。
人在这个闭环里做什么
老张没让这个闭环完全自动跑。
目前，监督 AI 给出的优化建议，落地前会经过人的审阅。老张说，这不是因为 AI 的建议不可信——它写得比人还清楚。是因为：客服话术、知识库内容，是直接面向客户的，错一个字都会影响体验。 所以在这个高敏感场景，人保留了对"最终文案"的把关权。
但这不意味着人要写文案。AI 已经把文案写好了，人只需要判断"这段话能不能对外说"。从"写"到"审"，工作量和认知负担完全不同。
而且老张发现，随着闭环转得越多，监督 AI 给出的建议越来越准，人的审阅越来越快——这本身也是一个进化。
一个反直觉的结论
老张把这个发现想了几天，得出了一个让他自己都有点惊讶的结论。
传统软件当然也能根据反馈迭代——收集 bug、排期、开发、测试、发布。但这条链路通常以周或月为单位，而且每一步都需要人主动驱动。
这套进化闭环的区别在于：它把"从线上反馈到规则发布"的周期压缩到了天。客服 bot 服务过的每一个客户、犯过的每一个错、被监督 AI 捕捉到的每一次偏差，都会在下一周变成规则的一部分。两个月前的客服 bot 和今天的客服 bot，背后的规则和知识已经大不一样。
老张说，这意味着部署一个 AI 的长期回报，远高于它的初始能力所暗示的。初始能力只是起点；真正决定它价值的，是它背后的进化闭环转得多快、转得多稳。
一个初始 70 分但有进化闭环的 AI，半年后可能是 90 分。 一个初始 90 分但没有进化闭环的 AI，半年后还是 90 分——而且因为需求在变，它实际的有效分可能在下降。
老张后来跟团队讲了一句话，这句话他琢磨了很久：
没有进化闭环的 AI，是消耗品；有进化闭环的 AI，是资产。
老张的最后一个问题
把"持续进化"这件事想清楚之后，老张反而陷入了更深的沉思。
他回头看了看这几个月经历的所有事——阿行接手了人扛不住的工作，AI review 治理了代码产出，三角结构管住了流程，共享环境让人接得住活，门禁驱动守住了质量，进化闭环让 AI 越用越好。
阿行能干的越来越多，而且越干越好。
老张心里冒出了那个他一直回避、但现在不得不面对的问题：
如果阿行什么都能干，而且越干越好——那我们这帮人，还能干什么？
这个问题，他在第 1 篇那个周二早上就冒出来过。当时他把它压了下去。现在，经历完这七篇的所有事之后，他觉得是时候正面回答它了。
这是第 8 篇、也是最后一篇的故事。
一句话结论
AI 队员的价值不在部署时多强，而在有没有一套"每日巡检→精确建议→落地修改"的持续进化闭环；没有进化闭环的 AI 是消耗品，有的才是资产。
参考来源
- OpenAI：Model optimization — 说明评估、提示优化与 fine-tuning 各自的适用位置。