AI编程

AI 写了 90% 代码后，Anthropic 怎么把 code review 做不崩 原文：How the Claude Code team does code review 作者：Addy Osmani, Morgan Westlee Lunt, Qing Wang（Anthropic Claude Code 团队） 来源：claude.dev 官方博客，发布于 2026 年 10 月 15 日 【关键词：#ClaudeCode #代码审查 #AI编程】 原文开篇连着问三个问题：每天 agent 产出这么多量，该怎么 review？还有人在读代码吗？真出事了谁来兜？ 这问题问得很准，因为 Claude Code 团队自己就是那个极端案例——Claude 写了约 90% 的 Claude Code 代码。我把原文和配套的工程博客、官方文档全过了一遍，最有价值的部分整理在这里。 01｜先看场景：AI 是主要作者时，review 为什么崩 三个数字摆出来，问题的量级就清楚了： Claude 自己写 Claude Code 约 90% 的代码 Anthropic 的 monorepo 每天落地的变更数，从 5 月的约 2,500 涨到 9 月的 30,000+（Claude Code 在独立仓库，不在这个 monorepo 里，但同样在承压） 6 月到 9 月，Claude Code 自己仓库的合并 PR 翻了一倍多，而需要 revert 的比例下降超过 40% 九成代码由 AI 写、每天三万次变更落地，人力逐行 review 在这个量级下不是"困难"，是"不可能"。 ...

国庆假日里想明白一件事：编程语言对 AI 来说，可能本身就是低效的，我们还在纠结编程语言吗？ 国庆第 1 天，没怎么出远门。下午我看着窗外，想着最近半年跟 agent 协作下来的体感，正好网上还在争论"AI 写 Java / Python / Go 哪个质量好"，忽然意识到一件事——这些争论，可能问错了。编程语言对 AI 来说，从一开始就不是它的母语。【关键词：#AI编程 #AI原生工程师 #上下文设计】 maybe，我们未来不再关心使用什么编程语言，AI的对语言的学习和使用是远胜于人类的，只要AI逻辑严密，AI或许会有自己的语言去驱动及驱动机器执行二进制程序吧。 01｜编程语言从来不是给 AI 设计的 打开 IDE 看到的 Python、Go、Java、JS 这些语言，它们被人为的"可读性、命名空间、类型系统、设计模式"绑了一身——这些是好东西，让我们能跨团队协作、能 review、能维护。 但 AI 不吃这一套。它不读注释、不在意缩进、也不会被你精心取的命名打动——它真正消耗的是 token、是上下文、是注意力分布。 最近一次让我愣住的：我让 Codex 改一段 Go 的并发代码，它把 channel、mutex、context 整段翻完，最后只用了两行；而我换成一段伪代码 + 关键约束描述喂过去，它一次就跑对了。 那一刻我才反应过来：AI 时代的"语言"，正在从"语法正确、人类可读"悄悄转向"信息密度高、上下文清晰"。Anthropic 内部数据里那 27% 的"agent 原本不会做的新工作量"——翻译需求、设计 prompt、整理上下文，本身正在变成新工种（Anthropic 研究页）。 02｜AI-native 工程师的默认单位，悄悄变了 借假期想明白的第二件事，跟我自己更相关——所谓 AI-native，不是会用 Cursor/Codex，是你脑子里默认的颗粒度变了。 老一代工程师脑子里装的是行、函数、模块；我自己这半年越来越意识到，AI-native 工程师脑子里装的应该是上下文窗口、任务切片、可验证的契约。 具体到每天的工作里，是三件事： 任务切片——把一个模糊需求拆成 agent 一次能跑完的小块，而不是把 2000 行的 PR 整段扔过去； 可验证的契约——每个任务都自带验收标准：什么算"做对"、什么算"做错"，让 agent 自己跑测试； 上下文设计——知道哪些信息 agent 必须看到、哪些是噪音、出错时才补什么。 说白了，AI-native 工程师写的不再是代码，是给 agent 跑的"剧本"。 ...

AGENTS.md 写对一次 ≈ 一次模型升级：60k 仓库总结的 5 段结构、6 个模式、5 类反模式 一句话定位：README 写给人看，AGENTS.md 写给 AI Agent 看。 AGENTS.md 不是文档，是 Prompt。你不是在写文档，是在做上下文工程。 —— Augment Code 工程博客 【关键词：#AGENTSmd #AI编程 #上下文工程】 01｜和模型强弱到底是什么关系：三种打架的结论 "我用了 Claude Opus 还需要写 AGENTS.md 吗？"——最近这一两个月，被问到这一句的次数，比过去一年加起来还多。 网上数据打架，我整理出三种主流结论。 我的判断一：好的 AGENTS.md ≈ 一次模型升级。Vercel 的 Next.js Evals 这套基准是所有数据里跑得最干净的——没有 AGENTS.md 的时候，Claude Sonnet 4.6 通过率只有 67%；加一份好的 AGENTS.md 之后直接到 100%。GPT 5.3 Codex 同样从 86% 拉到 100%。最反直觉的一行：——一份好文档的杠杆，比一次模型升级还大。 判断二：弱模型受益更大，但强模型也吃这套。The Prompt Shelf 综合 60k+ 仓库数据后画了一条更细的线——弱模型缺乏世界知识，必须靠显式上下文才能在同一个代码库上工作；前沿模型能自己推断大部分约定，但对非显而易见的项目约定（部署步骤、内部 API、仓库特有坑）仍然需要 AGENTS.md。边际价值不同，但没有哪个模型可以裸奔。 判断三：差的 AGENTS.md 比没有还糟。Augment Code 的实测 有点打脸：同一份 AGENTS.md，任务 A 提升了 25%，任务 B 反倒掉了 30%。——规则一旦自相矛盾，模型就开始犯傻。 ...

Trae、WorkBuddy 和 Agent:搞懂这三者,非程序员也能玩转 AI 我电脑里同时装着 Trae 和 WorkBuddy。一个长得像 VS Code,打开就是一整屏代码;一个长得像微信,打开就是个对话框。同一个"AI 助手"的名号,干的活差着十万八千里。关键词:#workbuddy #trae #agent 而 Agent 是另一回事儿。它不是一个产品,是个概念。你可以把它想成"汽车"这个品类——Trae 和 WorkBuddy 都是车,但一辆是越野车,一辆是家用 SUV。 先说最重要的一句话:Agent 是一个概念,Trae 和 WorkBuddy 是两个产品。 我用个不太恰当但好懂的比喻:Agent 相当于"汽车"这个品类,而 Trae 是"越野车"、WorkBuddy 是"家用 SUV"。都是车,但干不同的活儿。 那 Agent 到底是什么? Agent 直译过来是"智能体"。它和咱们平时聊的 ChatGPT、豆包、文心一言这类聊天机器人(Chatbot)不一样。 聊天机器人,你问一句它答一句,本质是"问答"。 而 Agent 是"干活"。你说"帮我订明天北京到上海的高铁,上午十点左右,二等座",它会自己拆任务、自己查车次、自己下单、自己填地址。整个过程你不用一步一步指挥。 一个能真正干活的 Agent,需要三样东西: 大脑:大模型(比如 DeepSeek、豆包、混元),负责理解和决策; 记忆:能记住你之前说过啥、做过啥,不会聊两句就忘; 工具:能调浏览器、调表格、调你电脑上的软件,这是干活的"手脚"。 缺任何一样,它就只能"陪聊",干不了正事。 那 Trae 和 WorkBuddy 又是啥? 懂了 Agent 是"汽车品类"之后,Trae 和 WorkBuddy 就好理解了——它们都是 Agent 的具体实现,但定位完全不同。 Trae 是字节跳动在 2025 年初推出的 AI 原生 IDE。所谓 IDE,就是程序员写代码用的"大本营"。它底层基于 VS Code,打开就能用,内置了 Claude、GPT、豆包等多个大模型,主打"中文体验最好、对开发者最友好"。 ...

语音替代键盘：我的vibe coding实践与Handy语音输入方案 键盘打字是程序员最传统的操作方式，但它的效率瓶颈在AI辅助编程时代越来越明显——我们和AI对话时需要大量输入上下文，而打字速度远远跟不上思维速度。本文分享我如何用语音彻底替代键盘，实现80%以上的coding指令下发。 为什么放弃键盘打字 传统的键盘输入有几个显著的效率问题： 速度瓶颈：说话速度远快于打字速度，尤其在描述复杂逻辑时 打断思维：打字需要同时关注拼写和内容，容易打断思路 上下文不足：打字时容易省略细节，而AI需要更丰富的描述才能准确理解意图 隐私顾虑：涉及密钥等敏感信息时，联网模型存在数据泄露风险 用语音输入时，我可以一口气说完整个需求，包括各种细节和废话，AI能获得的上下文远比打字丰富。这在实际项目中大大提升了沟通效率。 Handy语音输入方案 Handy是我在本地Mac上部署的语音输入模型，完全开源免费，支持全球各种语言的实时翻译。 核心优势 完全本地运行：所有数据不经过云端，隐私安全有保障 多语言实时翻译：说普通话、粤语、四川话还是英文、德语、法语，自动识别并翻译 无网络延迟：本地运行，翻译速度稳定不波动 模型选择建议 Handy提供针对不同语言优化的专用模型。如果你的母语或常用语言有对应模型，建议下载专用版本，速度更快、翻译质量更高。 通用模型约1.5GB，对机器内存和存储都有一定要求。如果你不确定要翻译的目标语言种类，可以用通用模型覆盖。 快捷键配置 建议提前绑定一个快捷键来触发语音输入。我使用F4键：按一下开始讲话，再按一下结束并立刻输出翻译内容。这个流程非常自然，几乎感觉不到工具的存在。 实际使用体验 在实际和AI配合coding的过程中，语音输入的优势体现得淋漓尽致： 时间成本更低：说话比打字快3-5倍，尤其适合长句和复杂描述 细节更丰富：不会因为懒得打字而省略细节，AI理解的上下文更完整 思维更流畅：不需要分心于拼写，可以完全沉浸在问题本身 当然，语音输入也有其适用场景。对于简短的命令、变量名修改等精确操作，键盘依然更高效。我目前大概是80%语音 + 20%键盘的配比。 未来展望 我认为语音交流终将取代键盘这种传统的机械式输入方式，尤其是在和AI协作的场景下。AI需要更丰富的输入才能提供更准确的输出，而语音天然比打字更能传递完整的思维过程。 当AI不再需要人类"喂料"，而是自己理解、自己决策、自己执行——这条路的起点，是让人类用最自然的方式表达意图。语音，就是最自然的方式。 本文全部通过麦克风语音交流，AI辅助完成撰写。

我的编程套餐尝试：对大多数个人开发者，OpenCode Go 套餐值得试 尤其是像我这种经常折腾 Docker、后端服务、AI 工具、UI 页面、脚本排错的人，$5 首月 / $10 每月的价格很有性价比。 OpenCode 官方说明：Go 是低成本订阅，首月 $5，之后 $10/月，可用于 OpenCode 或其他 agent，并支持充值兜底；它包含 GLM、Kimi、Qwen、DeepSeek、MiniMax、MiMo 等开放模型。(开源代码) 为什么值得 1. 价格低，但额度不算小 官方文档写得比较清楚：Go 套餐不是简单按"请求次数"限制，而是按等价用量限制： 限制周期 用量额度 5 小时 $12 usage 每周 $30 usage 每月 $60 usage 实际请求次数取决于你选的模型。比如官方估算，DeepSeek V4 Flash 每月可到 158,150 次请求，Qwen3.7 Plus 每月约 21,600 次，GLM-5.2 每月约 4,300 次。(开源代码) 这对日常 coding、改 bug、解释报错、生成脚本、写 Dockerfile、分析日志，已经非常够用。 2. 很适合作为"日常编码副驾驶" Go 套餐的定位不是替代最强闭源模型，而是提供稳定、便宜、可大量使用的开放 coding 模型。官方也说它主要解决的是开放模型访问不稳定、不同 provider 质量不一致的问题，OpenCode 会筛选和 benchmark 适合 coding agent 的模型组合。(开源代码) ...

数字生产实践Codex：AI 编程助手进化到桌面办公智能体 AI 编程工具正在从代码生成器，进化为能够操作环境、验证结果、持续协作的软件开发智能体。 在过去，很多人对 AI 编程工具的理解还停留在"帮我补全代码""生成一段函数""解释一段报错"。但 OpenAI 最新版 Codex 的能力已经不止于此。 根据 OpenAI 官方对新版 Codex 的介绍，Codex 正在从一个单纯的代码助手，升级为贯穿软件开发生命周期的智能协作伙伴。它不仅能写代码、理解代码库、处理 PR 评审，还开始具备两类更接近真实开发者工作方式的能力： Computer Use，也就是操作系统级控制能力； 内置浏览器，也就是在 Codex 应用中直接打开、观察和操作网页的能力。 这两项能力的出现，意味着 Codex 不再只是"回答怎么写代码"，而是开始进入真实开发环境，帮助开发者完成更完整的任务链路。 一、Codex 正在从代码助手变成开发智能体 传统 AI 编程工具的核心能力是生成代码。用户提出需求，AI 给出代码片段，开发者再自己复制、运行、调试和验证。 而新版 Codex 的方向更接近 开发智能体。 所谓开发智能体，不只是会生成代码，而是能够围绕一个开发目标，主动完成多个连续动作： 读取项目文件； 理解代码结构； 修改代码； 运行终端命令； 打开页面； 复现问题； 检查界面； 验证修复结果； 根据反馈继续调整。 也就是说，Codex 的价值正在从"生成代码"扩展为"完成开发任务"。 这背后最关键的变化，就是它开始具备 操作电脑 和 观察网页 的能力。 二、什么是 Computer Use？ Computer Use 可以理解为一种让 AI 像人一样使用电脑界面的技术。 它不是简单调用 API，也不是只在编辑器里生成文本，而是让模型通过屏幕画面理解当前环境，并通过鼠标、键盘等方式执行操作。 它的基本能力包括： 看屏幕：识别当前界面中的按钮、输入框、菜单、弹窗和错误提示； 理解任务：根据用户目标判断下一步应该做什么； 执行操作：点击、输入、滚动、切换窗口、打开应用； 观察反馈：根据界面变化判断任务是否完成； 持续迭代：如果没有完成，就继续调整下一步操作。 可以用一句话概括： ...

Superpowers 14 个 Skills 全解读：AI 编程纪律框架的完整拆解 最核心的价值不是某个单独 skill，而是这条链路： 需求澄清 → 设计确认 → 计划拆解 → 隔离开发 → TDD → review → 验证 → 收尾 这条链路正好针对 AI coding 最常见的失败模式：过早实现、缺少测试、猜测修复、跳过验证、过早宣布成功。 注意：要经常更新 skills 的代码版本和自己结合实际使用，将自己的经验和要求增加到 skills，以便更好的编程和业务准确性，最好是将自身业务的要求单独作为 skills 引入到编程工具里。 Superpowers 是一个给 AI 编程 Agent 的完整软件开发方法论，由一组可组合 skills 和初始指令组成。它的基本工作流是：先澄清需求、写设计、写实施计划、TDD 实现、代码审查、验证、最后合并/PR/清理。 该不该装？三层判断 层面 判断 技术层面 不必须。没有它，AI coding agent 也能写代码。 工程质量层面 对复杂项目，强烈建议。它强制 TDD、审查、验证，能减少"AI 自信但没验证"的问题。 Superpowers 自身规则层面 一旦安装并启用，它的 using-superpowers 明确要求：只要有 1% 可能适用，就必须先调用相关 skill；README 也说这些是 mandatory workflows, not suggestions。 我的建议：重项目安装，轻任务选择性使用；团队协作/生产代码建议默认启用；纯探索、一次性原型可以不用或显式绕开。 1. using-superpowers — 入口规则 这个 skill 不是某个开发动作，而是**"调度所有 skills 的总开关"**。它要求 agent 在任何任务开始前先判断是否有相关 skill；只要有一点可能适用，就要先调用 skill，而不是凭经验直接干。它还规定了优先级：用户明确指令最高，Superpowers skills 其次，默认系统行为最低。 ...

我用 Superpowers 治好了 AI 写代码的"急躁症" 你有没有这种经历？ 跟 AI 说一句"帮我加个登录功能"，它三秒钟就开始生成代码了。你还没来得及说"我要 OAuth 不要密码登录"，它已经把整个 auth 模块写完了。跑一下，报错。让它修，改了三处引入两个新 bug。再改，需求理解全歪了。 折腾一小时，还不如自己写。 问题不在 AI 笨——现在的 Claude、GPT 编程能力已经很强了。问题是它太急了。还没搞清楚你要什么，就急着动手。没有设计，没有测试，没有验证，凭着"感觉"改代码，改完说一句"看起来没问题"就算完成。 我最近发现了一个开源项目，专门治这个毛病。 Superpowers 是什么 Superpowers 是一个给 AI 编程 Agent 装的插件。它不改变模型能力，而是给 Agent 加了一套强制执行的开发流程。 你可以把它理解为：一个严厉但好心的技术 Lead，站在 AI 后面盯着它—— "停，先搞清楚需求再写代码。" "计划呢？计划写好再动手。" "测试呢？测试先写，代码后写。" "代码审查过了吗？没过不许继续。" 它由 Jesse Vincent（Prime Radiant 公司）开发，目前版本 v5.1.0，MIT 协议。支持 Claude Code、Codex CLI、Gemini CLI、Cursor、GitHub Copilot CLI 等主流 AI 编程工具。 实际用起来是什么体验 装上 Superpowers 之后，你和 AI 的交互模式会完全不一样。我用一个实际场景走一遍。 场景：让 AI 帮你做一个用户通知系统 没有 Superpowers 时，对话通常是这样的： 你：帮我做一个通知系统 AI：（立刻开始写代码）我创建了一个 NotificationService…… 你：等一下，我要邮件通知，不是站内信 AI：好的，我重新写…… 你：还需要支持批量发送 AI：我再加一个…… ...

我的AI模型使用情况分享 首先，大多数国内云厂商和模型服务商的模型我都接入和使用过，以下是根据实际体验得出的算力服务上自测评价，排序靠前说明体验感和实际使用效果很好； 我的模型体感（云厂商和模型商） 主要以稳定性、模型质量、使用体验为主的主观描述，国外模型不在表单里，因为属于算力能力和模型能力双领先； 排名 平台 我的推荐理由 我的使用劣势感受 1 火山引擎 / 火山方舟 我会把它作为线上生产环境的首选，尤其适合需要低延迟、高稳定性和持续调用的业务。 我觉得它的优势主要集中在生产稳定性上，如果追求极限低价，可能不是最便宜的选择。 2 阿里云百炼 我会把它作为企业级 AI 应用和多模型生态的主力平台，尤其适合需要工具链、Batch、长上下文和模型管理的场景。 我觉得它的产品体系比较完整，但也相对复杂，上手和配置成本会比单一 API 平台高一些。 3 DeepSeek 官方 我会把它作为低成本、高性价比调用 DeepSeek 模型的首选，适合大批量、成本敏感的任务。 我在高峰期可能会担心它的稳定性和响应速度，所以不一定会把它单独作为核心生产依赖。 4 腾讯云 我会把它作为腾讯云生态内项目的补充选择，尤其适合已经在腾讯云上部署业务的场景。 我觉得它在价格和综合体验上不算最突出，如果没有腾讯云生态绑定，吸引力会弱一些。 5 硅基流动 我会把它作为模型试验和多模型切换的平台，适合快速测试不同开源模型和低成本方案。 我觉得它更适合测试和非实时任务，强实时生产场景下我会更谨慎。 6 MiniMax 官方 我会在长上下文、多模态、语音或特定 MiniMax 模型能力上优先考虑它。 我不会把它作为通用推理 API 的第一主力，因为平台综合稳定性和生态证据不如火山、阿里这类云厂商充分。 7 智谱 GLM 官方 我会在中文场景、长上下文、工具调用和国产模型适配上考虑 GLM。 我觉得它的模型能力有特色，但公开的第三方平台级压测资料相对不足，所以生产主力选择上我会保守一些。 8 天翼云息壤 我会在政企、国产化、合规、央国企或电信体系项目里优先考虑它。 我觉得它更偏政企交付和合规场景，作为个人开发者或互联网产品的主力 API，体验和灵活度可能不是最优，当前缺失缓存机制，成本很高且模型上下文窗口阉割和算力不足。 我的主力模型 gpt + glm5.1 企业使用： 火山放在线上实时调用、Agent 后端、需要稳定低延迟的任务；阿里放企业生态、Qwen、百炼工作流、Batch、长上下文和多模型兜底 个人使用： Claude/Codex 更像"会干活的工程师" 或智谱的coding plans 政企客户： 尤其是电信、政务、金融、央国企场景，息壤价值在合规、国产算力、专网和交付，但个人开发者不推荐 国内模型 模型自测排行 GLM5.1（推荐，中等难度编程 或 自主任务执行） DeepSeek v4（可以赶上GLM5.1） MiniMax 2.7（在复杂任务执行，效果欠佳，比如openclaw的agent自主任务） Seedance 2.0（推荐，视频质量还可以，够用） MiniMax 2.5 和 GLM5（仅适合简单任务） 豆包 = 千问 > 元宝（网页使用推荐前2个） 模型用量数据 我的智谱AI，开通的是季度lite套餐，月度使用量截止到现在是31亿tokens； ...