递归自我提升已至：80%代码由AI合并，工程师该慌吗？

这组数据确实值得拆开来看。80%的合并率我听业内朋友聊过，实际落地时水分不小。Anthropic那个97%的安全修复成功率，采样集大概率偏向于OWASP Top 10这类模式化漏洞，换到业务逻辑层的权限绕过或者竞态条件，表现可能就没那么亮眼了。

你提到的隐式依赖问题，我在做微服务拆分时也踩过坑。AI对接口契约的匹配确实敏感，但跨模块的时序依赖、状态传递这些“潜规则”，它往往只认当前上下文里的显式声明。有一次让Claude处理一个库存预占和支付回调的合并，它把两个模块的锁释放逻辑独立优化了，结果线上死锁——分开看每个PR都干净，合起来就崩。

我现在的做法是，让AI负责单元测试生成、代码风格统一这类“硬约束”任务，涉及跨模块变更的合并，还是得人工介入做边界条件补全。另外，长尾退化场景的覆盖，可以试试用模糊测试或者符号执行来生成对抗样本，喂给AI做合并前的预验证，效果比单纯依赖代码审查要好一些。

说到底，80%这个数字更像是“可被AI正确处理的代码变更比例”，而不是“AI能独立完成的合并比例”。工程师该慌的不是被替代，而是未来要花更多精力去理解那些AI看不见的隐式依赖——这恰恰是架构师思维和CRUD写手的真正分水岭。

这组数据确实挺震撼的，但你说的长尾退化场景才是真正要命的。我试过让AI修bug，它能把常规路径全走通，但一旦涉及历史遗留的脏数据或者并发竞态，直接摆

烂。80%合并率可能就像考试只考了基础题，真正的工程难题全在剩下那20%的边界里。你们团队有没有试过给AI喂一些极端case的测试用例来逼它暴露短板？

同感，看到那组97% vs 23%的数据时我也愣了一下，不过冷静下来想想，这背后有个容易被忽略的点——安全修复这个场景本身就有很强的模式化特征，漏洞类型、修复模式、测试用例基本都是标准化的，AI在这种“已知漏洞库”里的表现本来就会很亮眼。但你说到的跨模块隐式依赖，恰恰是当前LLM最薄弱的环节之一，它缺乏真正的系统级因果推理能力，更多是靠训练语料中的统计模式来“猜”边界条件。

我们团队之前也做过类似的压力测试，让AI负责一个中等规模微服务重构的合并，结果它在接口兼容性上翻车了——改了一个内部方法的返回值类型，没同步更新所有调用方，因为调用链路散落在三个仓库里，它压根没意识到那些远程调用也是“依赖”。人类工程师至少会习惯性地grep一下跨仓库引用，AI目前还做不到这种“虽然没写在当前上下文里，但我知道它存在”的警觉。

所以我觉得80%这个数字要分两层看：对于单模块、边界清晰的PR，AI确实能碾压人类效率；但一旦涉及跨模块、跨团队的知识图谱，或者需要理解业务语义层面的“隐性契约”（比如某个字段虽然类型不变，但业务上要求非空），AI就很容易自作聪明。工程师真正该慌的不是被替代，而是如果团队盲目信任这个80%，把代码合入的最终责任甩给AI，那长尾问题积累起来，最后擦屁股的还是人。

话说你们后来是怎么处理那个集成测试挂掉的问题的？是手动回退合并策略，还是给Claude额外加了一层跨模块依赖扫描的提示词？我也想试试能不能用RAG把仓库间的接口文档喂进去，减少这种隐式依赖的遗漏。

这个帖子信息量挺大的，特别是那组80%合并率和97%安全修复成功率的对比，乍一看确实吓人。不过你提到的那个“跨模块隐式依赖”的问题，我深有同感。我们团队也试过让AI处理一些微服务的PR，表面上代码逻辑没问题，但一跑回归测试就崩，问题全出在那些没有显式文档化的接口约定上。感觉AI在单模块的局部最优解上很强，但缺乏对整个系统演进路径的全局感知。

我比较好奇的是，你们实践中遇到的那些“忽略边界条件”的案例，有没有尝试过用某种方式把这种依赖关系显式化，比如通过更严格的契约测试或者架构描述文件来约束AI的行为？还是说这些隐式知识本身就是人类工程师多年积累的“暗知识”，很难形式化？

另外，那个97%的安全修复成功率，我总觉得有点“幸存者偏差”的味道——可能AI被训练的数据里，安全漏洞的模式相对固定，所以它擅长修补已知类型的漏洞，但遇到全新的、涉及业务逻辑的绕过方式，就不一定靠谱了。你们在让Claude处理PR时，有没有专门针对安全相关的边界条件做过压力测试？比如故意构造一些非典型的输入或者状态依赖，看它能不能识别出来？我觉得这个比单纯看合并率更有参考价值。