乔木博客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 参与代码审查，这场对话给出的答案很一致：先去建立自己的评估体系，用事故和真实反馈去喂养它，而不是靠直觉去猜测边界在哪里。
信任从来不是一次性授予的，是一点一点用具体的验证过程攒出来的。