工程师Claude Code六周心得：95%代码是垃圾

Vincent Quigley - 2025.09.02

分享一段亲身经历：18个月前，我还是逐行手写所有代码。如今，AI完成了大约80%的初始实现代码，我的精力则转向了架构设计、代码审查以及并行推进多个开发线程。

坦诚而言，这并非又一篇空洞的“AI改变一切”宣言。它更像一份实战报告——聚焦于将AI真正嵌入生产级开发流程时遇到的实际挑战与收获。哪些策略真正有效？哪些纯属浪费时间？以及为何我将AI视为“一个永远学不会的初级开发者”——这个认知模型正是我高效利用它的核心。

此思考源于我在Sanity公司的一次工程研讨会。我们每月举办这类活动，由一位同事分享近期尝试的新方向。上次轮到我的时候，展示的主题便是Claude Code。

编程方式的四次转变

回顾我的编程历程，解决问题的方法经历了四次显著的演变：

最初5年，依赖阅读书籍和SDK文档。接下来的12年，靠的是谷歌搜索与社区问答。再之后18个月使用Cursor，进行AI辅助编程。直到近6周，我转向了Claude Code，才真正实现了完全的AI编程委托。

每一次转变的加速都比前一次更明显。至于Claude Code的上手速度？从开始到高效产出，我只用了几个小时。

AI辅助开发的真实工作流（对我而言）

抛开各种夸张的宣传，我目前的工作流程相当务实。我主要将AI视为一个“思考伙伴”，与它协作生成最终投入生产环境的代码。

通常需要三次尝试

别指望AI一次就能产出完美代码。作为工程师，我们的职责是找到问题的最优解，而不仅仅是堆砌代码。

第一次尝试（95%的代码不可用）

• Claude开始初步理解你的系统架构。
• 你则在此过程中识别出真正的挑战所在。
• 生成的代码——基本无法直接使用。

然后，你带着从这次失败中学到的东西，再次反馈给它。

第二次尝试（50%的代码仍不可用）

• Claude总算理解了其中的微妙差异。
• 你也已经明确了具体的实现方案。
• 不过，仍有大约一半的代码需要修改。

第三次尝试（最终产出可用的代码）

• Claude实现了一个可作为基础版本、供我们后续迭代优化的成果。
• 整个过程中，你需要持续审查并调整方向。
• 这是一个起点，而非终点。

这并非失败，而是必经阶段！期望第一次尝试就完美无缺，就像期望一位刚入职的初级开发者在毫无背景信息下独立完成复杂功能一样——完全不现实。

上下文问题（及其解决方案）

最大的挑战是什么？AI无法在对话之间保留所学内容——除非你花时间手动为其注入“记忆”。因此，每次对话几乎都要从零开始。

我的解决方案如下：

Claude.md 文件

为每个项目创建一个专用的上下文文件，内容包含：

• 架构设计决策
• 代码库常见模式
• 注意事项与变通方法
• 相关文档链接

工具集成

借助MCP集成，我目前可将AI连接到：

• Linear（项目管理工具），获取任务上下文
• Notion或Canvas，获取文档
• 非生产环境的数据库（只读权限，这点很关键），获取数据和数据结构
• 你的实际代码库（这是理所当然的）
• Github，从旧的Pull Request中获取有用的上下文

缺乏这些上下文时，你只能反复解释相同的限制条件。有了它们，你的起始点便相当于直接从第二次尝试开始，而非从零起步。

管理多个AI“开发者”

我现在并行运行多个Claude实例，感觉就像在管理一个小型开发团队——只不过团队成员每天清晨都会清空记忆。

几个关键策略：

• 切勿在同一个问题域中并行处理多个任务，否则容易混乱。
• 使用Linear（或你偏好的项目管理工具）追踪所有事项。
• 明确标记人类编辑过的代码——AI经常混淆它自己编写的与你修改的部分。

三步代码审查流程

编写代码只是工作的一环，代码审查同样关键。引入AI后，我的审查流程也随之调整。

首先由Claude审查

• 发现遗漏的测试用例。
• 识别明显的缺陷。
• 提出优化建议。

这一步为我和同事省去了许多重复的审查轮次。

我审查关键部分

在Sanity公司，我们遵循一条原则：工程师需对提交的代码负责，即使是AI生成的。我需要确保最终提交的代码满足以下标准：

• 可维护的代码库。
• 合理的架构决策。
• 正确的业务逻辑。
• 良好的集成点。

团队进行常规审查

• 他们通常不知道哪些代码由AI生成。
• 质量标准与以往完全相同。

关键在于：我现在对自己“编写”的代码反而更加严苛，因为其中许多并非逐字敲出。没有了情感依恋，审查质量反而提升。

后台任务袋里的早期实验

我们正在测试一种模式：通过Slack使用Cursor触发一些简单的后台任务袋程序。到目前为止：

• 有2次成功修复了业务逻辑错误。
• 有1次在处理CSS布局时失败。

当前的局限性也很明显：

• 无法访问私有的NPM包。
• 它提交的是未签名的commit。
• 绕过了常规的追踪流程。

但其蕴含的潜力令人期待——例如，你在休息时，后台程序正处理你待办列表中的小任务。我们Sanity团队正积极探索此方向，并在团队间共享经验，以寻找真正有效的方法。

真实成本（附上数据）

现在来谈费用问题。坦诚地说，我每月使用Claude Code的开销，已占公司支付我月薪的相当比例。

但作为交换，我换来的是：

• 功能交付速度提升2-3倍。
• 能同时管理多个开发工作流。
• 不再将时间耗费在样板代码和重复性任务上。

投资回报率显而易见。不过如果你想全面投入，这里提供一个实际数据：一位深度使用AI的资深工程师，每月大约需要1000-1500美元的预算。当然，随着工程师对AI运用日益熟练，其成本效率也会逐步提升——但这需要时间积累。

实际会出什么问题

AI辅助开发并非总是一帆风顺。以下是我反复遇到的几个常见挑战：

学习问题——AI不会从错误中汲取教训。你需要反复纠正它相同的误解。相应的解决方法是：提供更完善的文档和更清晰的指令。

自信问题——AI会极其自信地写出有问题的代码，并声称它很棒。所以，务必亲自验证，尤其是在以下几个方面：

• 复杂的状态管理
• 性能关键部分
• 安全敏感代码

上下文窗口限制——大型代码库很容易超出AI的上下文容量。需要将问题拆解为更小的部分，并提供聚焦的上下文。

从关注代码到关注问题的心理转变

最困难的部分是什么？放下对代码的“占有欲”。但现在我已经不再纠结于“我的代码”——它只是需要审查和优化的输出产物。

坦率地说，这种抽离感反而是一种解脱。

• 更快地删除糟糕的解决方案。
• 更客观地进行代码审查。
• 重构时毫无个人情感因素。

如果明天出现一个更好的AI工具，我会毫不犹豫切换过去。代码本身并不宝贵，我们解决的问题才是。

这对你的团队意味着什么（作为技术主管）

如果以工程师的身份给技术领导者提供建议，在考虑引入AI时，可以关注以下几点：

1. 让你的工程师去采用和测试不同的AI解决方案——AI辅助编程是一项需要通过实践来学习的技能。
2. 从最重复性的任务开始——这是AI能立竿见影发挥作用的地方。
3. 为实验准备预算——第一个月肯定会比较混乱。
4. 调整你的审查流程——AI生成的代码需要用不同的方式来审视。
5. 记录一切——优质的上下文是你提升效率的倍增器。

那些适应了新型AI工作流的工程师会发现，他们的工具箱里多了一把锋利的尖刀——他们正从单纯的代码编写者，转变为能够驾驭多个AI袋里的协调者，同时专注于架构设计、代码审查和复杂问题解决。

你的下一步（作为开发者）

选择一个微小的、定义明确的功能。让AI尝试实现它三次。像指导一位初级开发者那样审查它的输出。

就这么简单。不需要大规模变革，也不需要彻底重构流程。只需要一个功能、三次尝试和一次坦诚的审查。

未来的方向并非AI取代开发者，而是开发者借助最先进的工具，以更快的速度创造更优质的解决方案。