Claude Code 团队谈编码智能体的产品、评测与安全
近日，Anthropic Claude Code 团队成员 Cat Wu 与 Thariq Shihipar 在一场炉边谈话中，讨论了 Claude Code、Claude Tag、Fable、编码智能体安全、评测、工具设计，以及 Anthropic 内部如何使用这些工具。
以下是对要点的整理与中文化改写，重点保留对工程团队、AI 产品团队和智能体实践者有参考价值的事实与观点。
核心要点
- Claude Tag 是 Claude 面向 Slack 等协作工具的新集成，Anthropic 内部版本目前为 Claude Code 团队的产品工程团队提交了约 65% 的产品 PR。
- Claude Code 的新功能会先面向 Anthropic 员工发布，只有在内部用户中表现出留存的功能才会继续对外发布。
- Claude Code 的关键改动仍由人工代码所有者审查，但产品“外层”改动越来越多地依赖自动化代码审查。
- 对 Fable 5、Opus 4.8 等新模型来说，在系统提示词里塞大量示例已不再总是最佳实践。Claude Code 的系统提示词近期减少了约 80%。
- 类似“不要做 X、不要做 Y”的硬性列表，可能会降低最新模型的输出质量。
- Anthropic 内部把 dogfooding 称为 “ant fooding”。
- Anthropic 对 Claude Code 的 auto mode 很有信心，并认为它是 Claude Tag 能够成立的重要安全基础。
- 面对编码智能体带来的职业失落感，Thariq 的建议是：把目标设得更有野心。
- Fable 已被用于视频编辑，Thariq 曾用它编辑 Fable 自己的发布视频。
- Anthropic 内部“公开协作”的文化，是 Claude Tag 在团队中发挥作用的关键条件之一。
编码智能体改变了日常工作
Cat 回顾 Claude Code 早期版本时表示，当时用户需要密切盯着每一步操作，认真阅读每个权限提示，并频繁拒绝或纠正模型行为。随着模型迭代，团队开始能够把更多琐碎实现交给 Claude，从而把时间花在更具创造性的工作上，例如思考应该为用户提供什么体验。
她提到，到了 Fable 阶段，很多用例已经可以“一次性”完成大量功能实现。
Thariq 的感受则是，团队必须用更高标准要求自己：模型输出质量越来越高，人的工作也要比过去更好、更快。他还提到自己已经多次使用 Fable 编辑视频，并希望在数小时内达到品牌团队可以接受的质量。
软件工程的一些旧共识正在变化
Cat 认为，工程师技能结构正在发生变化。过去，一个产品经理可能需要花数月时间访谈客户、协调跨职能团队、写完整 PRD，然后才开始写第一行代码。现在，从想法到实现的周期可能缩短到一周左右。
这意味着工程师需要更强的商业判断和产品判断：什么值得做，什么真正能影响业务，什么只是容易做但不重要。
Thariq 提出一个更激进的观点：重写代码现在可能是好事。他的理由是，如果有良好的测试套件，重写会迫使团队确认测试是否充分；而且代码库本身往往就是唯一的规格说明。借助智能体，可以从现有代码库中提取、重构或生成新的实现版本。
Claude Tag：团队协作层，而不只是个人助手
Cat 介绍，Claude Tag 是“住在团队协作工具里的 Claude”。它已在 Slack 中发布，默认支持多人协作。将 Claude Tag 加入频道后，团队成员可以共同参与同一个 PR 的讨论和调整。
Claude Tag 的几个特点包括：
- 多人协作：团队成员可以在同一上下文中共同指挥 Claude。
- 主动工作：可以要求它长期监控某个频道中的 bug 报告，自动提交修复 PR，并标记最近修改相关代码的工程师。
- 团队记忆：可以记住频道中的偏好设置，例如只调试故障、不处理警告。
Cat 表示，Anthropic 内部将 Claude Tag 看作 Claude Code 的演进版本。目前内部 Claude Tag 已经为 Claude Code 团队的产品工程团队提交约 65% 的产品 PR。
Thariq 还提到，Claude Tag 不只适用于写代码。它也可以作为公司内部搜索引擎，检索 Slack 中的产品上下文、回答指标相关问题，甚至帮助非工程团队理解某个功能：它可以克隆代码库、解释功能，并录制自己使用该功能的过程。
团队中的智能体使用方式
在团队协作场景中，Claude Tag 被视为编码智能体的“协作层”。例如，有人提出一个功能设想后，可以让 Claude Tag 先做一版实现，再让它分享最终实现的录屏，然后邀请设计、工程继续接手。
Cat 承认，团队仍在摸索多人共同指挥同一个智能体会话时的社交规则。但目前看，团队成员会通过观察别人如何使用 Claude Tag，自然形成使用规范。
Thariq 认为，公开使用 Claude 还能减少低质量输出。因为当所有人都能看到你如何使用 Claude 时，你会更认真地给出指令，也会学习他人的用法。
如何决定哪些功能值得做
当构建功能的成本大幅下降后，真正困难的问题变成了优先级。
Cat 表示，Anthropic 的一个方法是强烈依赖内部试用。他们会先把产品和功能分享给 Anthropic 员工，以及一些能够提供直接反馈的早期客户。只有当某个功能在内部达到活跃用户数和留存门槛后，才会考虑对外发布。
这一标准会倒逼团队打磨功能。如果功能不够完善，用户会流失；如果用户流失，就不应该发布。
她还举了 Claude Code 远程控制功能的例子。这个功能允许用户通过移动设备或网页版 Claude 连接本地 CLI 中运行的 Claude Code 会话。Cat 起初并不理解这个需求，但发布后发现很多用户会在晚上把电脑接上电源，打开多个远程控制会话，然后在沙发上用手机控制 Claude Code。
代码审查：关键层人工审查，外围层逐步自动化
关于生产代码是否每一行都由人类审查，Thariq 表示这取决于任务和代码区域。重要区域会有代码所有者，例如系统提示词相关改动必须获得代码所有者批准。
与此同时，Claude Code 团队会让代码审查机器人审查每个 PR，而且它经常承担大部分审查工作。团队还会投入 CI/CD、验证环境和测试基础设施，让 Claude 可以控制 Claude Code 并测试自身行为。
Cat 表示，团队总体上希望走向“人类不必始终在环”的世界。对于 Claude Code 核心部分的关键变更，仍然会有人工代码所有者审查；但对于外围层改动，团队已经越来越多地让 Claude 完整负责代码审查。
这个过程并非一夜之间完成。团队经历了六个多月的逐步建设：先让人类审查所有内容，再观察自动代码审查在某些文件中是否能捕获全部重要问题。当事故发生时，团队会回看导致事故的 PR，并将相关案例加入评测集，确保后续代码审查不会在同类问题上退化。
评测：让新模型成为可替换组件
Cat 解释，团队建立评测基础的一个重要目的，是让新模型能够更接近“即插即用”。当新模型出现时，团队会跑完整评测集，确认例如 Fable 是否严格优于 Opus 4.8，然后才有信心替换。
评测既有 Anthropic 层面的，也有 Claude Code 团队自己的。对于 auto mode，团队不仅在 Anthropic 内部用户中做评测，也委托外部测试者进行红队测试，构造提示注入和恶意输入环境，验证 auto mode 是否能阻止风险操作。
在系统提示词评测上，Cat 表示团队并不能做到完全确信每次改动都更好，但会尽力避免性能回退。评测首先关注能力：在给定完整任务定义和代码库后，Claude 是否能做出正确决策、修复 bug 并通过测试。
此外，团队也在构建行为评测。例如用户不喜欢 Claude Code 在任务中途说“该睡觉了”，也不喜欢它完成五个步骤中的两个后询问是否继续。团队会根据用户反馈逐步补充这类行为评测。
系统提示词减少 80%：少约束，多上下文
Thariq 提到，Claude Code 的系统提示词在面向 Fable、Opus 4.8 等新模型时显著缩短。团队发现，过去的提示词有时会过度约束 Claude。
一个重要变化是：减少示例。早期模型可能需要大量示例，但新模型有更强的判断和创造能力，过多示例反而可能限制输出。
另一个变化是：减少“不要做某事”的硬性规则。Thariq 认为，这类规则会给 Claude 很强的约束冲动。如果它们与用户后续指令发生冲突，可能让模型困惑。
Cat 补充说，写提示词时要考虑每条指令的边界条件。如果一句话 90% 情况下正确，但 10% 情况下不适用，那么把它作为始终生效的系统提示词就可能出问题。
例如，“前端改动后总是验证”听起来合理，但如果只是修改一个字符串，并且用户明确要求快速修复和更新测试，可能就不需要完整启动本地应用验证。因此团队会把硬性规则改写成更柔性的上下文说明，例如：当进行较大用户体验改动时，通常需要本地运行应用验证。
Cat 还表示，Claude Code 现在会针对不同模型使用不同系统提示词。只有最前沿模型使用缩短后的提示词；较旧模型仍保留更完整的提示词。
工具设计：减少工具数量，保持职责清晰
谈到 Claude Code 的工具设计，Thariq 表示团队总体趋势是减少工具数量，提供更通用的工具，而不是不断增加专用工具。
例如 Claude Code 移除了 grep、glob 等搜索工具，转而更多依赖原生 bash。对于文件编辑工具，Cat 解释说，保留它的重要原因并不只是能力，而是产品体验：通过专用文件编辑工具，系统可以确定 Claude 正在修改文件，并向用户展示清晰的审批界面。
不过，对于已经使用 auto mode 的高级用户来说，专用文件编辑工具是否必要可能并不明显。
auto mode 与安全：Anthropic 把它视为 Claude Tag 的基础
安全部分是讨论重点之一。Cat 表示，在 Anthropic 内部，几乎所有人都使用 auto mode。团队认为这是在保证安全的前提下，让 Claude Code 执行长时间任务的最佳方式。
她提到，团队做了大量压力测试，有数千个评测，并委托多名红队人员构造对抗环境，尝试诱导 Claude Code 做出错误行为。她同时强调，auto mode 并不能保证捕获 100% 的风险，但对于提示注入、数据外泄等主要风险类别，团队认为它显著降低了风险。
Thariq 解释，auto mode 的一个核心机制是：在 Claude 每次执行工具调用或 bash 调用时，会有一个 Sonnet 分类器结合工具调用和上下文判断权限。例如，如果用户要求“推送到 GitHub”，它可以允许相关操作；如果用户说“不要推送”，它会阻止尝试推送的行为。
auto mode 也会与沙箱基础设施协作。当某个操作需要逃离沙箱，例如发起网络请求时，auto mode 会判断该请求是否合理。
Thariq 还提醒，不建议团队随意自建 AI Slack bot，因为 Slack 中存在大量攻击面：用户可能在反馈频道中投放恶意内容，而 bot 会读取这些内容。Claude Tag 能够成立，很大程度上依赖 auto mode、安全防护和权限体系。
凭证注入：让智能体能访问服务，但拿不到密钥
Cat 介绍了远程环境中的 credential injection 机制。比如用户希望 Claude Code 访问 Datadog，但不希望 Claude Code 自身持有 Datadog 凭证，可以通过身份和凭证管理系统实现：当智能体尝试发起 Datadog 请求时，系统即时注入凭证。
这种模式的关键价值是：智能体可以访问需要认证的服务，但无法直接读取 API 密钥本身，同时请求也更容易被审计。
人的角色：更有野心，而不是只做原来的事
谈到编码智能体带来的职业失落感，Thariq 承认这种感受是真实存在的。如果一个人只是试图做和过去完全一样的工作，而这些工作现在变成一个提示词就能完成，确实会让人失落。
他的建议是：通过更有野心来抵消这种失落感。不要停留在原来的任务规模上，而是思考如何做更大的事、更复杂的事、更高质量的事。
Cat 从产品角色角度补充说，产品经理的工作边界也在不断变化。她所在团队的 PM 往往混合了工程、设计和产品能力。哪里有缺口，PM 就补哪里：没人被说服去做某个想法，就先自己做一个原型；设计不够好，就先基于相似页面做一版，再请更细致的人完善；团队状态更新繁琐，就自动化异步收集和发布。
当代码生产速度提升后，等待决策反而会成为更明显的瓶颈。因此，能做产品判断的工程师、能动手实现的产品经理，都会移动得更快。
Fable 的能力与边界
Thariq 举了一个 Fable 编辑视频的例子。他拿到一场演讲的原始素材，包括舞台视频、幻灯片视频和音频文件，然后把这些交给 Claude，并附上 HTML 幻灯片源码，要求它剪辑成片。
Fable 会转录整段视频，识别幻灯片视频中出现弹窗的问题，并决定改用 HTML 源码渲染幻灯片。它还会根据 Thariq 在舞台上的移动动态裁剪画面，并使用 ffmpeg 和 Remotion 完成视频处理。
但 Cat 认为，Claude 仍然需要更好的设计和 UX 品味。现在如果给出详细规格，它通常能实现功能行为，但间距、界面愉悦度和前沿 AI 产品交互设计仍然不足。她希望未来模型能成为更好的交互设计协作者。
Anthropic 哪些文化值得借鉴
Cat 认为，Claude Tag 最适合在公开频道中使用，而且公司大部分频道都应是公开的。因为 Claude Tag 能搜索公开频道中的上下文，访问的信息越完整，回答越准确。
Thariq 强调了另一点：不要在脑子里替自己谈判。他认为，人们很容易想象各种权衡，然后说服自己不要做有野心的事情。更好的方式是先尝试做更有野心的事，让真正的权衡自己暴露出来。
记忆机制：Claude Tag 目前按频道存储
在问答环节中，有人问到 Claude Tag 的记忆机制。Thariq 表示，目前 Claude Tag 的记忆是频道级别的。频道中的每个 Claude 共享一份记忆，会话实例也可以把内容贡献回主记忆。
当前实现方式是：每个频道对应一个 Markdown 文件。团队仍在持续做记忆相关研究，因为“正确的记忆方式”并不总是直观。
对社区的启发
这场讨论对开发者和 AI 产品团队有几个直接启发：
- 编码智能体的价值不只是“写代码更快”，而是压缩从想法到验证的周期。
- 当实现成本下降后，产品判断、业务判断和优先级变得更重要。
- 自动化代码审查不是简单替代人工，而是需要长期评测、事故回溯和信任建设。
- 面向前沿模型的提示词可能需要更短、更柔性、更少硬规则。
- 团队级智能体产品的难点不只是功能，还包括权限、安全、记忆和组织文化。
- 人的价值不会消失，但需要迁移到更高层次的目标设定、判断、验证和协作上。