Bob Nystrom 在 Google 做 Dart 的 readability 代码审查，见过超过 60 字符的标识符。他给出四条删词规则：类型已由静态类型或参数列表说明，就不该再写进名字（nameString → name，holidayDateList → holidays）；对每个限定词追问“去掉它名字还成立吗”，recentlyUpdatedAnnualSalesBid 就这样逐词落马；类名和方法名已经提供了上下文，AnnualHolidaySale.promote 不必再叫 promoteHolidaySale；manager、data、state、engine 这类词不传递任何图像，可以直接删。文末用一个反面例子，把 DeliciousBelgianWaffleObject.garnishDeliciousBelgianWaffleWithStrawberryList 一步步砍成 Waffle.garnish，演示四条规则如何叠加生效。适合每天在 code review 里跟命名较劲的工程师。
作者面向软件工程师群体，总结了在项目中实践 AI 编程的通用行为准则，刻意弱化工具与技巧之争（如是否 Spec 驱动），聚焦于协作方式本身。核心主张包括：AI Agent 拓展了人的能力但不对代码担责，人始终是代码的最终责任人，不提交自己不理解的代码；用「协作」而非「委派」的心智模型与 Agent 共事，不做只提需求不问实现的产品经理；拆分 PR（推荐 600 行以内），创建前用 AI 前置 review；先启用 Plan 模式做前置探索，理解了需求再写码；工具函数与库倾向采纳成熟方案而非让 AI 从零手撸；改动必须可自动验证，避免让 Review 兜底。文章后半部分针对初级工程师给出定制建议：质量优先于效率、用聊天模式参与修 Bug 而非全自动委派、先花固定时间独立设计再与 AI 对答案、回归官方文档、补齐设计模式与 DDD 等设计能力、有意识关注安全与并发等非功能性需求。
Piglei 用「框架 vs 库」的区分来审视 AI 编程：框架掌握程序的整体结构，以极低的表面认知成本换取便利，而当下 AI 编程工具正被普遍当作这样的框架使用。文章以 Django REST Framework 为例——继承 ModelViewSet 只需一个 class 加三个属性就能生成整套 CRUD API，但要定制 create 的响应体、或给 list 加过滤条件，就得重写 get_queryset 等多个方法并堆上 if/else 补丁；改用不含魔法的 ViewSet 后代码变长，被藏起来的认知债务却浮出水面。作者认为框架的两个固有问题在 AI 编程上同样成立：抽象泄露（自然语言提示词失灵时，只能撕开抽象、精确到变量名去定位根因）与控制权丧失（Vibe Coding 把结构决策全交给 Agent）。他的建议是把 AI 当库用：寻找提示词的甜蜜区而非追求绝对最少的提示词，作为总设计师关注程序结构并把约束写进 AGENTS.md，并审查 AI 生成的代码。适合正在把 AI 引入日常开发的工程师。
Laravel 在 Socialite、Scout 等包仓库关闭了 issue 创建入口，改为引导贡献者直接提 pull request，主框架仓库暂未受影响。作者以开源维护者身份逐条列出顾虑：强制提 PR 确实能省下维护者的 triage 时间，但在 AI 辅助下提 PR 的成本已接近提 issue，而 LLM 生成的补丁需要更多审查精力；同一个 bug 引发的重复 PR 还会让 GitHub Actions 反复触发，这一点 issue 不存在。更关键的是，要求 PR 是把贡献门槛抬高而非降低，会用不起 AI 工具、或还没积累足够经验的开发者排除在外——而作者自己当年正是从给 Laravel 提 issue 起步的。全文没有硬结论，只把 trade-off 摆出来，适合关注开源维护、issue/PR 流程与 AI 编码影响的一线工程师阅读。
Michael Lynch 指出，多数代码评审文章只关心「找 Bug」，几乎不谈如何把问题讲清楚，结果把评审变成对作者的人身评判。本文把评审同时当作技术过程与社交过程，给出一组可直接落地的做法：把空白格式、构建、测试、lint 等机械检查交给 CI 和 formatter；用 style guide 终结风格争论；收到 changelist 后立即开始评审，单轮返工上限一个工作日；单轮批注控制在 20-50 条以内，先给高层设计意见再抠细节；用可运行的代码示例代替口头说明；批注里避免出现 "you"，改用 "we"、省略主语或改写为问句；把命令改成请求；把每条意见挂到具体原则上并附上风格指南或文档链接。适合正在设计团队评审流程、或想改善评审沟通方式的工程师。
React Doctor 是一个面向 AI 编码代理的 React 代码质量检查工具。它通过 CLI 对代码库做确定性扫描，从 state/effects、性能、架构、安全、可访问性和可维护性六个维度找出问题，并标记过度复杂的函数与可抽取的重复 JSX 树。核心思路是：不用 LLM 猜，先给出可复现的审计结果；再把规则装成 Claude Code、Cursor、Codex 等代理的 skill，让 agent 后续能按同一套标准修复代码。它还支持 GitHub Actions CI 门禁，只报告本次改动引入的新问题，并提供 Chrome 性能 trace 录制能力。适合用 AI agent 写 React 的团队，也适合想在 CI 里加一道 React 质量闸门的工程团队。
Zed 团队发布 Delta，一个面向 Agent 协作的多人编程环境，并开启私有 Beta。核心是 DeltaDB：它将对话和 worktree 实时复制给线程中的所有参与者，同时兼容 Git，所有编辑与对话都记录在 commit 之间，团队外成员看到的仍是普通仓库。评论可锚定在任何代码行上，随代码演进保持位置，agent 与人类评论共存于同一线程。浏览器端并非简化版，而是把同一个 Rust 应用编译成 WebAssembly 并通过 WebGL 渲染。Delta 还接入了 Claude Code 等第三方 agent harness，让终端会话实时同步进线程。界面设计把对话当作可编辑文档，光标可落在 diff 行、计划步骤或思考块上直接批注。适合使用 agent 编程、关注协作工具与 Agent 基础设施的工程师阅读。
GitHub 正式推出堆叠拉取请求（stacked pull requests）公开预览，将大型改动拆解为有序的小型 PR 层，每层可独立评审与检查，所有层可一键合并。支持通过 gh-stack CLI 扩展、github.com、移动端及 Copilot agent 工作。默认保留现有分支保护与必检检查，合并队列支持将在数周内逐步上线。Vercel、TED、WHOOP 等团队已先行使用。
Ultrareview 是 Claude Code 提供的一项深度代码审查功能，启动一组远程 reviewer agent 在沙箱中并行审查当前分支或 Pull Request。与本地审查相比，Ultrareview 的每个发现都会独立复现验证，因此更聚焦真实缺陷而非风格建议；覆盖范围更广，能发现本地审查遗漏的问题；且完全在远端运行，不占用终端资源。文章详细介绍了使用方法：通过 /code-review ultra 命令启动，支持指定 base 分支、PR 编号、自然语言描述上下文；提供非交互式子命令 claude ultrareview 用于 CI 集成。定价方面，Pro/Max 用户有 3 次免费额度，之后每轮审查约 $5-$25 按量计费，审查时长约 5-10 分钟。限制包括 diff 大小上限（默认 500 文件/8000 行）、部分平台不可用等。适用于合并前需要更深入检测的场景。
LangChain 团队开源了其内部使用的四个软件工程代理工具：本地编码代理 dcode、云端编码代理 OpenSWE、自动代码审查 OpenSWE Review 以及仓库知识文档 OpenWiki。文章详细介绍了每个工具的设计意图、使用场景和实际数据——OpenSWE 上周仅从 Slack 触发了近 1000 次，OpenSWE Review 在离线代码审查基准中以 47% 的成绩排名开源第一。所有工具基于 Deep Agents 框架，并利用 LangSmith 进行全链路追踪与优化。适合希望构建可控、可观测的软件工程代理流水线的工程师。
本文总结了一年多来在安全关键系统中使用 AI 代理编码的研究成果。作者提出“短绳法”：只有资深开发者才能使用，全程禁止 YOLO 模式，开发者必须逐 diff 审查 AI 提议的每次改动，及时打断跑偏倾向，每个子任务结束后提交，从而杜绝“氛围编程”带来的代码鬼祟。文章还给出了 AI 辅助代码评审的最佳实践——人类与 AI 共同审查 PR，AI 负责快速扫描常见错误，人类把关方向性决策；并且要求作者在提交 AI 辅助 PR 前必须自我逐行审查并加上 AI 使用声明。该方法即便使用非前沿模型，也能产出胜过 Fable 的高质量代码。适合希望用 AI 提升效能但不牺牲代码质量的资深工程师阅读。
当AI能以分钟级生成上千行代码时，工程的瓶颈从编写转向了信任决策。因此，审查成了软件领域最具杠杆能力的技能。文章指出，2026年的多方数据（Faros AI、CodeRabbit、GitClear、GitHub）均证实：AI使用量提升后，开发者的代码产出提高约4倍，但交付价值仅增长约12%，同时代码流失率飙升861%、缺陷率从9%升至54%、审查时长增加441.5%、零审查合并的PR增长31.3%。作者认为，问题不在于是否使用AI，而在于如何根据项目的「爆炸半径」分层分配审查力度：对个人无用户项目可轻审查，对大型企业级项目必须建立分级、证据驱动、异质化AI审查+人类最终负责的流程。文章还介绍了具体实践：分流PR、要求前置证据、关注测试变更、用两个不同构架的AI审查工具并行运行，以及让人类从「线级审查」升级为「抽样审计」。