jiechenjiechen

The world is quiet here.

© jiechen

Rebuild in 2023   |   Start in 2021
Total View 0 Site Visitors 0

Claude Code 背后的设计思考

2025年8月4日ai

观视频有感:《Anthropic 的工程师们如何适应 AI 编程工具》

How Anthropic Engineers Are Adapting to AI Coding Agents

产品哲学与设计巧思

“改变实现方式,而非工具本身”:Jacqueline 提出的这个观点非常深刻。在推广新工具时,最好的策略不是让开发者抛弃他们熟悉的命令行或 IDE,而是在他们已有的工具链中,以一种无缝、无打扰的方式增加新功能。这极大地降低了心理排斥感。

终端是“最大公约数”:他们选择终端作为主战场,是因为这是唯一一个几乎所有后端和基础设施工程师都会高频使用的界面。这个选择本身就是“在用户所在之处满足他们”哲学的最佳体现。

为“可折腾性”而生 (Designed for Tinkerability):Claude Code 被设计成高度可扩展和定制的。这不仅仅是一个功能,更是一种邀请,鼓励用户把它接入自己独特的环境,喂给它独特的上下文,让它从一个“通用实习生”变成一个“资深项目成员”。

Anthropic 内部工作流

Claude Code 的诞生故事:它不是一个自上而下规划的产品,而是工程师 Boris 为了熟悉自家 API 发起的一个个人项目。因为太好用了,所以像涟漪一样从个人、到团队、到实验室、再到整个公司,最终在对外发布时,内部大部分技术人员已经是它的日活用户了。这种有机的、自下而上的生长路径本身就证明了它的价值。

AI 时代的 Code Review 新范式:当 AI 大量生成代码时,审查责任如何分配?Anthropic 的答案是:责任在于 PR 的作者,而非审查者。 Claude Code 通过支持“测试驱动开发”(TDD)等方式,帮助作者在提交前就建立信心。作者可以用它生成测试,或者让它截图验证前端修改,确保提交的代码质量。

鼓励“广谱实验”:内部工程师可以自由使用 Claude Code、GitHub Copilot 甚至其他创业公司的 AI 工具。他们鼓励大家用 AI 去挑战非常困难的任务,因为只有在 pushing the boundary 的时候,你才能真正发现 AI 的惊人能力,比如给它一个晦涩的 GCP 堆栈跟踪,它能立刻看懂并修复,直接节省4小时。

Jacqueline 的黑客马拉松亲身经历:她在一个自己完全不熟悉的语言和代码库上,仅用了一天时间,就借助 Claude 做出了一个可以工作的演示。这是“从文档到演示”理念最有说服力的真人案例。

研究员与工程师的“统一战线”:在 Anthropic,研究员和工程师为同一个代码库(monorepo)贡献代码,使用相同的开发环境和工具集。这意味着对工具(比如 CLAUDE md)的任何投资和优化,都能让所有人受益,实现了规模效应。

高阶玩法与最佳实践

“多 Claude”详解:

目的:并行处理多个独立任务。
最佳实践:最好在不重叠的仓库中实例化多个 Claude,或者使用 GitHub worktrees、直接 git clone 多份等方式,避免多个代理修改同一份文件造成冲突和混乱。
认知极限:Ben 和 Cat 提到,3个claude进程是普通人的“甜点位”,有人能同时驾驭 6 个,甚至有人跑 12 个(可能是异步运行)。

“多 Claude” vs “子代理”:

多 Claude:用于处理多个不同的独立任务。
子代理:用于加速同一个核心任务,通过并行处理或引入不同视角(安全、产品等)来提升效率和质量。

如何让 Claude 更懂你的代码库:

通用原则:如果一个人类新员工能轻松看懂你的代码库(文档齐全、命名清晰、抽象合理),那 Claude 就能做得很好。反之,如果代码库里到处都是需要“祖传知识”才能理解的坑,Claude 也会一样懵。
处理多仓库依赖:可以在包含所有相关仓库的上级目录实例化 Claude,或者使用新推出的 add dir 功能,把其他仓库的访问权限授予当前会话。

迭代式地处理复杂任务:当面对大型重构或提升测试覆盖率这类复杂任务时,不要指望一步到位。最佳策略是:先从一两个文件开始,观察 Claude 在哪里会失败,然后迭代优化你给它的指令,最后再逐步扩大规模。

安全 & 局限

精细化的权限系统:他们的权限系统不只是简单的“是/否”,而是拆分成了读取文件、编辑文件、搜索、执行 bash 命令等多个维度,让用户可以进行更细粒度的授权。

内置的提示注入防护:当使用网页搜索等功能时,获取到的外部内容会先经过一个分类器模型进行“安检”,判断是否存在提示注入风险,然后再交给主代理。

公开承认的失败与教训:

  • 他们曾尝试让 Claude Code 自动创建大量 PR,结果造成了内部的“信息垃圾 (spam)”,后来不得不调整限制。
  • 有一长串功能已经构建出来了,但因为觉得模型成功率还不够高,最终没有发布。他们对开发者的“垃圾信息敏感度”有清醒的认识。

对“代码品味”的思考:Kyle 问 AI 何时能达到 100% 自动编程,Cat 认为很多不是原始“智能”的问题,而是**产品和“代码品味”**的问题。模型需要看到更多元、更优秀的代码库来学习,而不是简单地增加上下文窗口长度。

异步运行的取舍:Jacqueline 提到她会通过 Slack 异步触发一些 Claude Code 任务,让它们在后台无人监督地运行。这样做的好处是能并行处理更多任务,但代价是结果的方差会更大,不一定能成功。这是一个典型的效率与可控性之间的权衡。

未来规划

迈向“主动式”代理:未来的 Claude Code 不仅是被动地等你下命令,更希望能变得主动 (proactive)。它能读取你和你队友所有的历史会话,从中提取见解,甚至能主动维护一个 CLAUDE md 文件,成为团队知识的沉淀者和管理者。

成为开发者的“信息中枢”:未来的方向是让 Claude Code 能访问开发者能接触到的一切信息——Slack, Jira, PRD, 工程规范, 客户支持工单等等。上下文越完整,代理的能力就越强。

赋能开发者构建自己的代理:他们会大力投入 SDK 的建设,确保其功能与 CLI 体验对齐,最终目标是让所有开发者都能灵活、强大地构建出满足自己需求的、千奇百怪的 AI 代理。