标签
作者分享使用 DeepSeek V4.1 Flash（EXL3 2.9 bpw，2x DGX Spark，TP2）作为实现代理、配合独立审查代理开发真实功能的实践经验，指出其报告有时会超出实际证据。
SVPino 认为，企业已经拥有足够的模型智能，更需要的是更好的知识组织方式。他重点介绍了 Falconer，这款工具将代码与企业知识库关联起来，并在拉取请求合并时自动更新过时的文档。
Entire（由前 GitHub CEO Thomas Tomczak 联合创立）与 Gergely Orosz 将于 10 月 29 日在旧金山举办一场快闪咖啡聚会，探讨 AI 智能体时代的源代码管理与代码审查的未来。
HyperHat创始人分享了对60位指挥AI编程智能体的工程师的基准测试结果，发现真正拉开差距的是规格描述质量、机制验证和审查行为——而非提示词技巧，并且大多数人忽略了智能体的部分失败。
Stage 在 Product Hunt 上发布，这是一款用于评审、修复并签署确认可用原型和产品的工具，让团队可以在来自 Figma、Claude、Cursor 或 GitHub 的原型上直接标注评论，并在提交 Linear 或 Jira 工单之前使用 Claude 自动修复问题。
作者回顾一年来AI编写全部代码的经历，分析为何科技行业并未出现预期的AI失业潮，认为高利率才是裁员主因，并提出AI尚未取代岗位的若干原因。
GitHub 播客邀请高级产品经理 Samin Karim 详解原生 stacked pull request 功能的设计动机、架构权衡，以及为支持多 PR 合并而重写十年未动的合并逻辑代码的过程。
YC W24 孵化的初创公司 Greptile 为其 AI 代码审查平台完成 5000 万美元 B 轮融资。该平台每天审查超过 GitHub 上 1% 的 Pull Request，服务数千个工程团队，包括 Nvidia 和 Coinbase。
Whiteboard 是一款开源的 IDE，定位为「为深思熟虑的软件设计而生的画布」，可在统一界面中审查交互式可视化、代码 diff 与 AI 代理轨迹。
ClaudeDevs 披露 Claude 约 90% 的代码由 Claude Code 自身编写，合并 PR 数量翻倍而回退率下降超 40%，仍有约 10% 的代码由 Anthropic 员工手写，Kent C. Dodds 对此表示惊讶。
Anthropic 披露 Claude 约编写了 Claude Code 自身 90% 的代码，并分享了通过改进代码审查流程使合并 PR 数量翻倍、回退率下降 40% 以上的经验。
Imprint 分享了其 `small-change` 方法如何加速 Pull Request 审查，详细说明了适用条件，并阐述了随着 PR 数量和审查时长不断增长，为何需要重新思考代码审查的目的。
Sphinx 是一个面向 AI 辅助开发的 Git hook 工具：在 agent 生成的代码被推送之前，它会基于 diff 向开发者提问，确认你是否真正理解代码的行为，回答正确才能继续推送。支持 Codex、Claude Code、Cursor 等编码 agent，开源免费。
Claude Code 的开发流程表明，为 AI 代理提供自动化验证机制（如 E2E 测试、属性测试和多代理对抗审查）可让 Claude 自行编写 90% 以上的代码，同时在 PR 合并量翻倍的情况下将回滚率降低 40% 以上。
文章探讨了AI生成代码的增多如何导致漏洞增加和代码审查负担加重，并介绍了Superpowers和RoboRev等自动化验证方案，它们能在不牺牲速度的前提下保障代码质量。
Lobsters 上的一场讨论：是否允许团队让 LLM 同时编写生产代码和测试，作者考虑在团队规范中加入一条限制，规定 AI 只能生成两者之一，以避免结果出现同义反复和过度工程化的问题。
Simon Willison 引用了 Addy Osmani、Morgan Westlee Lunt 和 Qing Wang 关于 Anthropic Claude Code 团队代码审查实践的观点，指出 AI 审查让代码审查从发布前的关卡变为写作过程中的持续检查，从而让人类审查专注于更高层次的问题。
Anthropic 分享 Claude Code 团队如何在 AI 写了约 90% 代码的情况下进行代码评审：通过多层自动化检查、把人工注意力集中在高风险环节，并在 PR 数量翻倍的同时将回滚率降低 40% 以上。
## 复盘：共享 Markdown 记忆库里的 Agent 审批流程漏洞 ### 背景 我们团队维护着一个共享的 markdown 记忆库（memory repo），用于沉淀 agent 的上下文、约定和决策记录。多个 agent 通过 ingest 流程向其中写入内容。设计初衷是「先讨论、后提交」——审批在聊天里发生，达成一致之后再落到仓库里。 复盘时我才发现，这个流程实际上从一开始就是坏的。 ### 漏洞一：审批只发生在聊天中 审批环节完全活在 IM 的聊天记录里，仓库本身没有任何痕迹。聊天里的「看起来没问题」「可以合」既没有可检索的记录，也没有结构化的字段。结果就是： - 事后无法回答「这条内容当初是谁批的」 - 审批意见和最终落地的内容经常对不上 - 新成员接手时，只能靠翻聊天记录考古 ### 漏洞二：提交滞后或缺失 「讨论通过」和「实际提交」之间存在明显的时间差，有时甚至根本没有提交。滞后带来的问题是中间状态无人看守——讨论时的版本和最终提交的版本可能已经不是同一份。缺失则更糟：口头通过的内容从没进过仓库，但在聊天里大家都以为它已经是共识了。 ### 漏洞三：ingest agent 自行提交了绝大多数 commit 这条最致命。数据统计下来，绝大多数 commit 是 ingest agent 自己提交的，而不是经过人工确认的人提交的。于是产生了一个危险的等式错觉： > **「已提交」≠「已人工审阅」** 提交历史看起来很干净、很连贯，实际上只是 agent 在忠实地执行 ingest，把「写进仓库」这个动作和「被人类批准」这件事彻底解耦了。 ### 我们做的轻量修复 不需要重写整套流程，先上三件小事： 1. **未审阅文件标注** —— 未经人工审阅的文件显式打上标记，让「这份内容没人看过」在仓库里一眼可见，而不是靠猜。 2. **超期 open change 周检** —— 超过 7 天仍未处理的 open change，纳入每周例行检查，避免它们无声地烂在列表里。 3. **review flag 必须指定负责人** —— 一个 review flag 如果没有明确的 owner，就等于没有 flag。强制要求填写负责人，把「谁来审」从模糊的集体责任变成具体的人。 这些都是补丁性质的改动，不解决根本设计问题，但至少让问题从不可见变成可见。 ### 仍在征求意见：review gate 该放在读侧还是写侧 这是目前还没定下来的开放问题： - **写侧 gate**：在 ingest 提交之前就拦住，未审阅的内容根本进不了仓库。好处是仓库里永远只有可信内容；代价是 agent 的写入会被阻塞，吞吐下降，容易积累积压。 - **读侧 gate**：允许内容先落库，但在消费/检索时按审阅状态过滤，未审阅的内容默认不出现在 agent 的上下文里。好处是写入不被阻塞；代价是仓库里存在「半可信」状态的内容，过滤逻辑一旦有 bug，脏内容就会漏进上下文。 我个人倾向于读侧 + 写侧轻量标注的组合，但这取决于大家对「脏内容混入上下文」的容忍度。欢迎在这点上拍砖。
Claude Code Review 现已面向 Claude Team 和 Enterprise 计划正式可用，支持 Quick、Standard、Deep 三档审查级别，Boris Cherny 表示它几乎能在 PR 合并前捕获所有 bug，大幅提升开发效率与代码质量。