“AI 让我这么做的”辩护：当代码审查悄然停止提出异议
Agent 编写的 PR 落地后的缺陷率高出 1.7 倍，而审查者往往会向模型那自信的措辞妥协。本文探讨了如何在事故率曲线飙升之前，通过结构性修复让高级工程师坚守合并路径。
Prompt 作者身份问题：三个角色同时编辑同一个文件
每个生产环境的系统 prompt 都有三个作者 —— 工程、产品和 ML —— 而且他们对什么是“变更”各执一词。这里有一套结构化的解决方案。
混合 PR 队列：审查者吞吐量已成为瓶颈约束
编程智能体消除了代码编写的约束，并将负载转嫁到了审查队列。如果不重新设计审查机制就直接上线智能体，团队交付的将只是一个积压工作生成器。
需求文档、代码、测试皆出自一人：你正在悄然失去的独立性
当同一个模型编写需求文档、代码和测试时，“所有测试通过”不再是功能正常的证据 —— 它仅仅证明了模型在逻辑上是自洽的。
Prompt 修改不只是措辞变动：将 Prompt 视为软件的代码审查规范
Prompt 修改看起来像是英语，但行为表现却像代码。通过配对评估与 Prompt 的 PR、行为差异注释以及划分审查角色等规范，在用户发现之前捕捉行为回归。
AI 代码审查倒置：当作者是机器时应关注什么
当 AI 智能体编写了你大部分的提交时，逐行代码的正确性审查会忽略那些关键的漏洞。这里有一套真正适用于机器创作代码的审查规范。
隐形作者问题：当 AI 编写大部分代码时如何进行 Git Blame
当 46% 的代码由 AI 生成且不包含溯源元数据时，git blame 止步于一位接受了自己可能并不理解的建议的开发者。本文探讨了哪些环节会出现问题，以及团队正在采取什么应对措施。
AI 数秒生成代码，团队却花数小时审查——这笔账根本不对
AI 编程工具让代码生成速度提升 55%，但高采用率团队的 PR 审查时间却增加了 91%。AI 编程工具真正的投资回报率取决于你如何处理验证开销——而大多数团队根本没有把这个算进去。
代码所有权衰减：当 AI 编写大部分提交时，团队知识会发生什么
当 AI 编写了你团队的大部分提交时，git blame 不再能回答那个真正关键的问题：为什么。本文探讨了代码所有权是如何默默衰减的，以及工程团队正在采取哪些措施来阻止这一趋势。
生产环境中的 LLM 代码审查：构建工程师真正信任的 Diff 流水线
如何将 LLM 作为代码审查层进行部署，以在不产生噪点的情况下减轻审查负担 —— 涵盖 Diff 预处理、误报预算、集成模式以及关键指标。
你的编程智能体是一个从不阅读测试的初级工程师
编程智能体的生产力源于模型周边的脚手架 —— 这些脚手架正是团队原本就为初级工程师准备的。本文将探讨需要记录哪些内容，以及为什么智能体最终会迫使你这么做。
将 Eval 作为 Pull Request 评论而非任务：在代码审查中嵌入 LLM 质量门禁
为什么只有当 LLM 评估（evals）存在于 diff 旁边的 PR 评论中时，才能有效捕捉回归。借鉴代码覆盖率如何从夜间任务迁移到内联审查界面的经验 —— 以及将“评估即任务”转变为“评估即合并门禁”的四个工程关键点。