这套叫“自愈Agent系统”的东西，本质就一句话。AI自己干活，AI自己打分，AI自己修Bug，AI自己决定能不能上线。听起来像公司老板喝多了吹牛，但人家已经在生产环境里一天发3到8次版本了，而且没有QA，没有测试环境，也没人手动检查。
核心逻辑很简单，而且特别狠。只看结果好不好，出问题就立刻修，修完马上验证，没问题再继续上线。整个过程像流水线一样不停循环，完全不靠人盯着。你可以把它理解成一个自动修车的工厂，车开着开着哪坏了，系统自己发现，自己拆开修，修完还自己上路测试，没问题继续跑。
为什么传统开发流程在AI时代直接卡脖子
以前的软件开发是个啥流程。写代码，提交，测试，修Bug，再测试，再上线。听着挺合理，但有个致命问题，那就是慢。现在AI写代码的速度是啥水平，一个月的活，几个小时就写完了。问题来了，代码写得飞快，测试还在慢悠悠点鼠标。
这就像你开高铁，前面突然变成三轮车车道，直接堵死。
传统流程有两个大坑。一个叫评估和QA是两拨人干的，还有一个叫所有问题都要人来判断。结果就是AI干活越来越快，人越来越跟不上，最后瓶颈全卡在测试和验证。
在传统的SaaS公司中，这两拨人通常位于不同的地方：
- 评估：模型能否对实时交通状况给出准确的预测？机器学习或数据科学负责这项工作，他们负责制作仪表盘。
- 质量QA：产品在生产环境中是否能正常运行？工程部门负责这个问题。他们提交问题单、修复漏洞并发布版本。
所以本文分享了一件很暴力的事，直接把评估和QA合并成一件事，让AI自己干。
核心循环：一条能自己转的流水线
整套系统最重要的东西就五个动作。评分，分类，修复，验证，决定上线。这五步不停循环，像滚筒洗衣机一样转。关键点在于每一步都不需要人参与。系统的目标也很直接，发现问题越快越好，修复问题越快越好。
至于过程优不优雅，根本不重要。因为你花三天争论一个评估方法够不够科学，人家已经修了八个Bug并且上线了。现实就是这么残酷，速度就是一切。对于创业公司来说，一个今天能用的粗糙信号，比一个下季度才能出的完美报告值钱一万倍。
评分机制：AI当裁判，而且还是三个人一起判
这里是整套系统最核心的地方。以前怎么评估AI，人工看对话，打分，写报告。现在直接换成AI评委团。三个不同公司的模型同时上，Anthropic的Claude，OpenAI的GPT，Google的Gemini。这就像请了三个老师同时批作业，避免一个人偏心。因为如果只用自己的模型评分，它给自己打分往往会偏高，大概会虚高0.3分左右。
每次AI回复完一句话，系统立刻做一件事，把这段对话丢给评委打分。而且这个评分是异步的，不影响用户体验。用户还在聊天，后台已经在偷偷打分了。评分内容也很实在，回答质量好不好，有没有胡说八道，有没有用错工具，有没有漏信息。最后变成一个分数，从1分到4分，然后三个评委取个平均值。
重点来了。他们只看结果，不看过程。AI绕了一百个弯，只要结果对，就算好答案。这点特别关键，因为AI很多解法在人类眼里像邪门歪道，但就是好用。你要是强行规定它必须走某条路径，反而会把好答案给判成错的。这就叫评估结果，不评估路线。
分类系统：先搞清楚你在干啥再打分
在评分之前，系统会先做一件事，把任务分类。比如写代码，做研究，数据分析，聊天，写文章，任务自动化，构建Agent，构建传统应用，规划，创意工作，错误恢复。一共分成12类。为什么要这么干。因为写代码的好答案，和写作文的好答案，标准完全不一样。
你不能用文采好不好去评判代码。所以系统先判断类型，再用对应规则打分。这一步就像考试前先分科目，语文用语文标准，数学用数学标准，否则全乱套。比如在写代码这个类别里，工具调用错误就是大问题。但在聊天类别里，这个错误可能根本不存在。分类做对了，评分才有意义。
抽样的门道：小流量模型反而要全量采样
这里有个坑，很多人会踩。他们按流量比例抽样，比如所有请求都抽10%。结果就是主力模型占了90%的流量，抽样后还有9%的数据。而小模型本来流量就少，再抽10%就没几个样本了。等你想判断小模型好不好用的时候，数据不够，没法下结论。
所以他们的做法是反过来。主力模型因为流量特别大，只抽10%就够了。但所有小模型和实验模型，百分百全量采样。只有这样，你才能在几个小时内知道一个新模型到底行不行，而不是等上几周。这套逻辑特别反直觉，但特别有效。你要评估的不是流量，你要评估的是模型本身的表现。
工程流水线第一部分：问题聚类和严重程度判断
评分只是第一步，重点是后面。一旦分数低，系统直接把它当Bug处理。然后进入六步流水线。第一步是把所有低分问题收集起来，然后开始做聚类。简单说就是把同一类故障归到一起。比如一堆请求报错，一堆回答胡编，一堆接口挂了。这一步特别重要，因为一个根本原因可能造成几百个低分。
如果不做聚类，你看到的是几百个Bug，实际上就一个问题。系统还会算严重程度，看影响多少用户，持续时间多长，是不是核心功能，错误率多高，波及范围多大。然后给每个问题集群打分，分数高的优先处理。这就像医院的分诊台，先判断谁快死了先救谁，而不是谁先来谁先看。
工程流水线第二部分：AI自己调查现场找原因
第二步是调查现场。系统开始像侦探一样干活。它会查CloudWatch日志，看最近有没有新部署，翻数据库找异常，检查有没有API报错。然后给出一个结论，问题大概率出在哪。比如提示词被截断了，或者某个工具的Schema变了，或者底层ECS任务内存爆了。
最后把完整证据打包，包括日志片段、堆栈信息、时间线，全部一起扔给人类工程师。注意，这时候人才第一次出现，而且已经拿到完整材料。工程师不用再去翻半天日志，直接就能开始修。这就像你去修车，师傅已经把故障码读好了，零件也订好了，你过去只需要拧螺丝。
工程流水线第三部分：自动写代码修Bug
第三步是最刺激的，自动修复。如果问题够明显，严重程度够高，系统会直接动手。它新建一个分支，写修复代码，跑测试，然后提一个Pull Request到GitHub。但这里有很多刹车机制，防止它胡搞。每次运行最多只提三个PR，因为人工审核的人有限，不能把人家淹没了。
任何改环境变量文件或者权限配置文件的PR，直接自动关闭。测试跑不过的，自动关闭。代码有类型错误的，自动关闭。他们不是要让AI去修什么深层的架构问题，那些太复杂了。目标是修那些明显的、重复的、琐碎的Bug，把人类工程师从这些脏活里解放出来，去做真正需要动脑子的事。
工程流水线第四部分：用真实数据验证修没修好
第四步是验证，这一步特别狠。系统不会让人去手动测试，而是直接看生产环境的真实数据。比如修完一个Bug之后，系统会去查过去6个小时的CloudWatch日志。如果这个错误再也没有出现过，那就证明修好了，直接关闭Bug工单，并且在评论里贴上证据。
如果错误还在出现，那就更新工单，把最新的错误数量贴上去，然后继续循环。这里的关键是，验证的依据是真实流量，不是模拟测试。你骗不了系统，你说修好了没用，数据说没修好就是没修好。这就完全替代了手动的回归测试，人不用再点来点去了。
工程流水线第五和第六步：重新监控和日报
第五步是重新评分。修完之后，系统会对这个区域进行24小时的强化监控。原来可能只抽10%的样本，现在改成百分百全量采样。如果问题又冒出来了，系统会自动把Bug工单重新打开，甚至直接回滚那个修复。完全不等人发现，也不等人报告。
第六步是每天生成一份报告。报告会告诉团队，今天检测到了多少问题集群，发了多少个PR，有多少被回滚了，每个类别的分数变化是多少，每个模型的表现怎么样。但这个报告只是个记录，不是决策核心。很多人喜欢做漂亮的仪表盘，天天盯着看，但从来不行动。他们的想法很直接，行动已经发生了，报告只是留个存档而已。
发布桥接机制：上线这件事完全交给AI决定
前两个组件解决了已经上线的Bug。第三个组件解决的是即将上线的Bug。传统上线流程是测试通过，然后某个人点头说可以，然后上线。这里直接砍掉人。新版本上线流程是这样的，先放10%的流量试水。然后系统开始实时对比新版本和老版本的表现。
如果新版本的评委平均分比老版本低了0.15分以上，而且统计上显著，样本量超过200次交互，那么系统直接做三件事。第一，终止上线流程。第二，把流量切回老版本。第三，自动开一个Bug工单，附带上出问题的样本。这个工单直接进入前面的修复流水线。如果分数没问题，那就逐步扩大流量，从10%到20%再到50%最后100%。
整个过程没有我觉得可以上线这个环节，只有一个标准，数据说行才行。这替代了传统的预发环境和人工审批。很多人觉得AI决定上线有点恐怖，但仔细想想，人拍脑门决定上线才更恐怖。数据至少不会因为今天心情不好就乱来。
三个最痛的领悟：别走弯路
第一个领悟是评估结果，不评估过程。早期他们也犯过错，看到AI多调了一个工具就觉得不对，扣分。后来发现AI经常能找到人类想不到的解法，过程看着奇怪，结果特别好。你要是管得太细，反而把它绑死了。所以现在只看最终答案好不好，不管中间绕了多少弯。
第二个领悟是按模型抽样，不按流量抽样。这个前面说过了，不重复。总之记住一句话，你要评估的是模型，不是流量。用流量比例来抽样，小模型永远得不到足够的数据。
第三个领悟是分数不生成工单等于白干。很多人做个评分系统，搞个漂亮的仪表盘，然后就完了。结果没人看，也没人行动。评分如果不进入修复流程，就是一堆数字而已。反过来，修复流程如果没有评分给信号，就是瞎修。两个必须一起做，缺一个都不行。
这套系统干掉了什么：QA、测试环境、上线审批
这套系统干掉了三样东西。人工QA，因为有了AI评委团，不需要人坐那看对话打分了。测试环境，因为所有的验证都直接在生产环境用真实流量做，不再需要单独搭一套环境让人点来点去。上线审批，因为发布决定完全由数据驱动，不需要某个人点头。
你可以理解为以前是人监督机器，现在是机器监督机器。而人只在关键点介入，比如偶尔抽几个样本回来看看AI评委有没有跑偏，或者处理那些自动修复不了的深层架构问题。大部分人听到这个的第一反应是害怕，觉得自己的工作要没了。但实际的情况是，人的工作从重复劳动变成了更有趣的事情。
什么情况会翻车：系统不是万能的
当然这套系统不是完美的，它有自己的短板。比如当问题特别复杂，需要改好几个服务的时候，自动修复就搞不定了。或者当底层的模型本身出了大问题，评委团也跟着犯糊涂的时候，整个闭环就失效了。还有就是当网络特别卡或者外部API大面积超时的时候，评分本身都可能拿不到结果。
所以他们在设计的时候留了很多后手。比如评委团里有三个不同公司的模型，一个挂了还有两个。比如评分拿不到就降级，不影响用户主流程。比如自动修复有硬性的PR数量限制，不会让机器人把GitHub刷爆。所有看似很帅的自动化，背后都有一堆保命措施。这不是炫技，这是生产环境的求生欲。
普通团队怎么抄作业：从两步开始
别一上来就想全做，那不现实。先干两件事就够了。第一，把AI评分接到真实流量上，不用搞三个评委，一个也行。也不用搞12个分类，先分三五个就行。关键是让评分跑起来，能看到每个回答的分数。第二，让低分自动生成Bug工单。不用自动修复，不用自动验证，就生成一个工单，让人去看就行。
只做这两步，你的效率就已经碾压一半团队了。因为你第一次把评估和QA连起来了，而且完全是自动的。然后慢慢再补后面的环节，自动修复，自动验证，自动上线。记住一句话，流程才是壁垒，模型只是工具。模型会越来越强，但你能不能把模型组织起来干正经事，这要看你怎么搭这个流水线。
最后的实话：不是要不要做的问题，是跑不跑得掉的问题
很多团队现在还在干一件事，用Copilot写代码，然后走老流程测试。结果就是写代码像火箭，测试像蜗牛。差距越拉越大。这不是谁更聪明的问题，这是谁先意识到问题的问题。当AI把开发时间从一个月压缩到几个小时之后，你花在测试和评估上的时间就成了新的瓶颈。
真正的优势在于谁先把写代码加测试加上线这一整套全自动化。不是在老流程上缝缝补补，而是直接重做一遍。这套自愈系统，本质就是把开发流程从手动挡变成了自动挡。而且自动挡还在不断自己优化自己。谁先把流程跑顺，谁就开始滚雪球。至于还在争论评估方法够不够科学的人，抱歉，雪球已经从你身边滚过去了。