--- layout: post.njk source: https://blog.qiaomu.ai/claude-self-coding speaker: 向阳乔木 title: Anthropic 内部实录：当 Claude 自己开始写 Claude 的代码 · 乔木博客 date: '2026-07-24' summary: 本文回顾了 Anthropic 内部关于 Claude Code 的实录，探讨了 AI 如何从辅助生成代码演变为自动落地生产力引擎的转变。核心观点包括：通过建立基于分类器的评估体系来替代逐字审查，以及通过精简系统提示词和提供背景信息来修正模型认知偏差。文章强调信任是积累出来的过程，而非一次性授予的，并指出工程师的角色正从单纯的代码实现者转向提升业务感和判断力。 area: tech-engineering category: ai-application tags: - code-generation - model-evaluation - prompt-engineering - team-collaboration people: - Cat Wu - Thariq Shihipar companies_orgs: - Anthropic products_models: - Claude Code media_books: [] draft: true status: evergreen --- Anthropic 内部实录：当 Claude 自己开始写 Claude 的代码 · 乔木博客 乔木博客 全部 AI工具 AI教程 AI生成 AI资讯 健脑房 播客解读 论文学习 # Anthropic 内部实录：当 Claude 自己开始写 Claude 的代码 AI资讯 · 2026年7月24日 · 99 次阅读 · 约 8 分钟 © 2026 · 向阳乔木 Anthropic 产品工程团队现在 65% 的 PR，是由一个叫 Claude Tag 的机器人直接合到主干的。 不是辅助生成代码，是真的自动落地，不需要人工确认。 这是 Anthropic 产品与工程负责人 Cat Wu 和 Thariq Shihipar 在一场炉边对话里聊到的。 两人的话题围绕着 Claude Code：这个工具从 Sonnet 3.7 发布会上一个不起眼的功能点，怎么在一年半时间里变成了公司内部真正的生产力引擎。 用这篇总结讲清楚三件事：工程师的角色到底发生了什么变化，团队怎么协作使用 AI，以及信任一个模型需要经历怎样的过程。 ## 从逐字审查到放手，中间发生了什么 Cat Wu 的回忆：Claude Code 刚出来那会儿，她会一字不差地检查每一条权限申请，动不动就摁"不行"。 现在她和团队几乎所有人都开着自动模式跑长任务，不再逐条确认。 这个转变靠的不是模型单纯变聪明了。 Anthropic 内部搭了一整套评估体系，用一个基于 Sonnet 的分类器实时判断每次工具调用是否符合用户意图和上下文，还专门请了外部红队构造提示词注入、恶意输入这类攻击场景，一条条验证自动模式能不能扛住。 这套东西从今年一月开始在内部打磨，磨了大半年。 团队给出的结论是：在提示词注入和数据泄露这类核心风险上，自动模式的表现已经优于人工审查的平均水平。 他们没有把话说满，两人都强调这不是百分之百的保证，也打算近期公开一批评估数据，让外界自己判断。 信任是攒出来的，不是一次性给的。 最开始所有代码变更都要人工过一遍，后来发现某些文件类型的改动，代码审查工具能百分百抓住问题，这部分就不再需要人工介入了。 每次线上事故复盘完，团队会把导致问题的那批 PR 加进评估集，确保以后同样的坑不会再摔一次。 ## 系统提示词砍掉八成 随着 Opus 4.8 和最新一代模型（内部代号 Fable）上线，Claude Code 的系统提示词精简了 80%。 原因不是技术优化，是认知上的修正：团队发现自己一直在过度约束模型。 早期模型需要大量示例才能理解任务，工程师们往提示词里塞了不少例子。 但新一代模型不需要这些了，反而这些示例会限制它的创造力，删掉效果更好。 这跟业界一个常见共识正好相反，也就是给模型举例子是最有效的提示技巧。 Thariq 自己说，这个发现打破了他原来的提示词方法论。 另一个转变是从禁止性指令转向提供背景信息。以前提示词里塞满了不要做这个不要做那个的硬约束，一旦这些约束和用户当下的具体指令冲突，模型会困惑，不知道该听谁的。 现在的做法是少下死命令，多给上下文，让模型自己判断。 关于验证这个指令有个具体的例子。 之前提示词写着改了前端就必须验证，但现实中如果用户说的是只是改个文案顺便更新一下测试，那种级别的验证就是多余的。 团队后来把措辞改成了更有弹性的表达，承认多数情况下建议验证，而不是一刀切要求。 道理其实很简单：一条会被百分百执行的指令，就必须想清楚它在哪些边缘场景下是错的。 这跟写代码考虑边界条件是同一件事，只是审查对象从代码变成了自然语言。 因为不同能力层级的模型对指令的理解深度不一样，Anthropic 现在给不同模型准备了不同版本的系统提示词。 80% 的削减只发生在最前沿的模型上，老模型依然用着完整版。 ## Claude Tag：把 AI 协作变成多人在线 Claude Code 解决的是个人生产力问题，Claude Tag 想解决的是团队协作。 它和 Claude Code 的区别集中在三点。 第一，默认多人协作。把它拉进一个 Slack 频道，团队所有人都能同时参与同一个任务的推进，不需要各自开各自的会话。 第二，主动而非被动。你可以告诉它监控这个频道里的每一个 bug 报告，自动提 PR 修复，并 @ 最后改动这部分代码的工程师，它会在频道存在的整个周期里持续执行，不需要每次手动触发。 第三，团队记忆。你在频道里用自然语言说过一次偏好，比如只处理服务中断类问题、不用管警告类，它会记住，并且这条记忆对频道里所有人生效，不只对提问的那个人生效。 Cat Wu 提到一个细节：Claude Tag 效果最好的前提，是公司内部大部分频道都是公开的。因为它需要跨频道搜索才能拿到足够的上下文，给出准确答案，权限越开放，它能调用的信息就越完整。 这其实是在倒逼一种组织文化：信息孤岛越少，AI 能帮上的忙就越多。 安全性上团队用了一个巧妙的设计，叫凭证注入。 如果想让 Claude 访问 Datadog 但不想让它真正持有密钥，可以走一套身份凭证管理系统，密钥只在请求发出的瞬间被动态插入，Claude 本身从头到尾摸不到真实凭证。 这跟 API 网关里代理替换 token 的思路是同一套逻辑，只是用到了 agent 安全场景里。 ## 工程师的价值不再是写对代码 这场对话里最值得工程师反复咀嚼的一段，是关于产品经理角色变化的描述。 两年前一个典型的产品迭代路径是：PM 找一堆客户聊需求，花六个月时间跨团队对齐，写一份详尽的 PRD，然后工程师才开始写第一行代码。 现在从想法到落地，可能只需要一周。 这意味着执行力不再是稀缺资源，判断力才是。 Cat Wu 说，工程师需要提升的是业务感和产品感，也就是知道什么东西值得做，而不是把精力耗在怎么把它做出来上。 因为怎么做这件事，Claude 已经能接管大半。 Thariq 补充了一个更颠覆的观点：重写现在是好事。 这跟软件工程里根深蒂固的永远不要重写的信条正好相反。 他的逻辑是，如果有一套完善的测试用例，重写反而会倒逼你把测试用例补齐，而且代码库本质上就是一份规格说明书，往往还是唯一一份，因为没人能记住所有分支逻辑。 重写等于把这份隐性的规格显性化。 一个佐证：Anthropic 内部已经把 Bun 用 Rust 重写了一遍，并且已经在内部生产环境跑起来了。 ## 那些意外好用的功能，都来自真实的狗粮文化 问到怎么决定做什么功能这个问题时，两人的答案朴素得有点意外，就是每天吃自己的狗粮。 团队内部想要某个功能而产品里没有，第一反应不是找替代方案，而是直接把这个功能补上。 有个例子很说明问题。remote control 功能刚上线时，Cat Wu 自己完全没搞懂它的价值，因为她习惯直接在移动端跑云端任务。但上线后她发现，大量同事的真实使用方式是：晚上把笔记本插上电源、合上屏幕，开几个 remote control 会话锁屏，然后窝在沙发上用手机远程操控。 这个用法完全出乎产品设计者的预料，却成了一个真实存在的高频场景。 这说明一件事：你以为自己懂用户需求，但真实使用场景往往会打破你的假设。 狗粮文化的价值不在于验证你的想法是对的，而在于暴露你根本没想到的用法。 ## 写在最后 这场对话里反复出现一个说法，叫不跟自己谈判。 意思是不要在脑子里预设一堆权衡取舍，然后自己说服自己放弃某个大胆的想法，而是先去试，让真实的代价自己显现出来，而不是靠猜。 这跟大多数工程师的直觉是反的。 二十多年的软件工程经验告诉你，默认答案应该是不，因为任何决定都有成本。 但当执行成本被 AI 大幅压低之后，这套直觉本身需要被重新校准。 如果你也在纠结要不要用自动模式、要不要精简系统提示词、要不要放手让 AI 参与代码审查，这场对话给出的答案很一致：先去建立自己的评估体系，用事故和真实反馈去喂养它，而不是靠直觉去猜测边界在哪里。 信任从来不是一次性授予的，是一点一点用具体的验证过程攒出来的。