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

Vincent Quigley - 2025.09.02

作者从亲身实践出发，回顾了过去十八个月的工作方式转变。早期所有代码均需逐一输入，如今超过八成的初始实现代码由AI完成，作者的核心精力已转向架构设计、代码审查以及多线程开发管理。

需要明确的是，这篇内容并非空洞的“AI改变一切”预言，而是一份真实的实战报告。作者希望探讨将AI深度融入生产级开发流程后，所面临的实际挑战与收获。哪些方法行之有效，哪些方式纯粹浪费时间，以及为何作者将AI视为“永远学不会东西的初级开发者”——这个思维模型，恰恰是高效使用AI的核心。

这一思考的起点，源于作者在Sanity公司的一次工程研讨会。公司每月都会组织此类活动，由一位同事分享近期尝试的新技术。当轮值到作者时，展示的主题正是Claude Code。

AI辅助编程：编程方式的四次关键转变

回顾整个历程，作者解决编程问题的方式经历了四次清晰的演进：

最初的五年，主要依赖书本与SDK文档。接下来的十二年，则以谷歌搜索与社区答案为主。随后是十八个月的Cursor，属于AI辅助编程阶段。直到最近六周，作者切换至Claude Code，才算真正实现了完全的AI编程委托。

每一次转变的速度都明显加快。而切换到Claude Code后，从上手到高效产出仅花费了几个小时。

AI辅助开发：真实工作流与实战经验分享

抛开各种宣传话术，作者当前的实际工作流相当务实。作者将AI视为“辅助思考”的伙伴，协作完成最终要投入生产环境的代码。

三次尝试，是必经之路

别指望AI能一次生成完美无缺的代码。作为工程师，职责是为问题找到最优解，而非单纯堆积代码。

第一次尝试：九成五是废代码

• AI开始建立对系统的基本认知。
• 您反而在此过程中识别出真正的挑战所在。
• 生成的代码大概率完全无法使用。

之后，带着从这次失败中学到的信息，再次反馈给AI。

第二次尝试：一半是废代码

• AI总算理解了其中的细微差别。
• 您也已经构思好了具体的实现方法。
• 但仍有一半的代码无法直接使用。

第三次尝试：终于产出可用代码

• AI实现了一个可作为基础版本的方案，供后续迭代与优化。
• 整个过程中，您需要持续审查并修正方向。
• 这只是一个起点，远非终点。

这绝非失败，而是必经之路。期待首次尝试就获得完美结果，如同期待一位新入职的初级开发者在毫无背景信息的情况下独立完成复杂功能一样不切实际。

上下文管理：关键挑战与解决方案

最大的挑战在于，AI无法在两次对话之间保留已学到的信息，除非您手动为其建立“记忆”。每次对话几乎都是从零开始。

作者采用的解决办法如下：

Claude.md 文件：项目专属上下文库

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

• 架构决策记录
• 代码库中的常见模式
• 各类注意事项与变通方法
• 相关文档的链接

工具集成：打通信息孤岛

借助MCP集成，作者将AI连接到多个系统：

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

缺乏这些上下文时，您需要反复解释同样的限制条件。而具备此条件后，工作起始点相当于直接从第二次尝试开始，而非从零起步。

管理多个AI“开发者”

作者目前会并行运行多个Claude实例，感觉如同带领一个小型开发团队，唯一的区别是团队成员每天早晨都会重置记忆。

几个关键策略：

• 避免在同一个问题空间上并行处理多个任务，以免自身混淆。
• 利用Linear或其他项目管理工具追踪所有事项。
• 明确标记人类编辑过的代码，因为AI经常混淆自身编写与用户修改的部分。

三步代码审查流程

编写代码只是工作的一部分，代码审查同样重要。引入AI后，作者的审查流程也自然发生了改变。

第一步：由Claude进行初审

• 捕捉缺失的测试用例。
• 发现明显的错误。
• 提出优化建议。

这一步为作者和团队成员节省了不少重复审查的时间。

第二步：作者审查关键部分

在Sanity公司，有一项原则：工程师必须对自己提交的代码负责，即使代码由AI生成。作者需要确保最终提交的代码符合以下要求：

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

第三步：团队进行常规审查

• 团队成员通常并不清楚哪些代码是AI生成的。
• 质量标准与以往完全相同。

关键在于，作者现在对自己“写”的代码反而更加挑剔，因为其中许多并非逐字输入。由于失去了那种情感依恋，审查质量反而得到了提升。

后台任务袋里的早期实验

作者所在的团队正在测试一种方式：利用Cursor通过Slack触发一些简单的后台任务袋里程序。截至目前：

• 有两次成功修复了业务逻辑问题。
• 有一次在处理CSS布局时失败。

当前的局限性也比较明显：

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

但其中蕴含的潜力值得期待。例如，在您休息期间，袋里程序可以自动处理待办事项列表中的小型任务。Sanity团队正在积极探索此方向，并在团队间分享经验，识别真正有效的做法。

真实成本：投入与产出的数据

谈及成本问题，作者坦承，每月使用Claude Code的费用，已占据公司支付月薪的相当一部分比例。

然而，作为交换，作者获得的是：

• 功能交付速度提升2至3倍。
• 同时管理多个开发线程的能力。
• 不再将时间浪费在样板代码与重复性工作上。

投资回报率显而易见。不过，如果想全面投入，有一个实际数字可供参考：全身心使用AI的资深工程师，每月大约需要准备1000至1500美元预算。当然，随着对AI使用愈发熟练，开销效率会逐步提升，但这需要时间。

实际出问题的情况

AI辅助开发并非一帆风顺。以下是作者经常遭遇的几个持续性挑战：

学习问题：AI不会从错误中学习。您需要一遍又一遍地纠正它相同的误解。解决办法是提供更完善的文档和更明确的指令。

自信问题：AI会极其自信地写出有问题的代码，并声称效果出色。因此，务必亲自验证，尤其是在以下方面：

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

上下文限制问题：大型代码库很容易超出AI的上下文窗口大小。需要将问题拆解成更小的部分，并提供集中的上下文信息。

从关注代码到关注问题的情感转变

最难克服的部分是什么？放下对代码的“所有权”感。如今作者已不再纠结这是不是“我的代码”，它只是一个需要审查与优化的输出结果。

坦率而言，这种抽离感反而是一种解放。

• 能够更快地删除糟糕的解决方案。
• 可以更客观地进行代码审查。
• 重构时不再受个人情感因素影响。

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

给技术主管的建议：AI团队落地要点

从工程师角度出发，作者向技术领导者提出以下建议，供在考虑引入AI时参考：

1. 鼓励工程师主动采用并测试不同的AI解决方案，AI辅助编程是一项需要通过实践来掌握的技能。
2. 从最重复性的任务开始，这是AI能够立竿见影发挥作用的领域。
3. 为实验阶段准备预算，第一个月很可能比较混乱。
4. 调整审查流程，AI生成的代码需要用不同视角审视。
5. 记录一切，优质的上下文是提升效率的倍增器。

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

给开发者的下一步行动

挑选一个较小、定义清晰的功能。让AI尝试实现它三次。像指导一位初级开发者一样，审查它的输出结果。

就是这样。不需要巨大的变革，也不需要彻底改造流程。只需一个功能，三次尝试，以及一次坦诚的审查。

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