AI 辅助编程的正确姿势——我用了1年 Claude Code 的真实感受

适读人群：正在用或者考虑用 AI 辅助编程工具的工程师 | 阅读时长：约18分钟 | 核心价值：不是广告也不是恐吓，是我用了一年 Claude Code 之后，对 AI 辅助编程最真实的看法

---

我想先说一个让很多人不舒服的观点：大多数工程师对 AI 辅助编程的态度，要么过于乐观，要么过于悲观，两个极端都没看到真实情况。

过于乐观的说："AI 会帮我做所有事，我只需要写需求就行了，效率提升10倍。" 过于悲观的说："AI 写的代码一塌糊涂，到处是 Bug，根本不能用。"

我用了一年 Claude Code 之后，我的感受是：它是一个极其有价值的工具，但你需要学会正确使用它，就像你需要学会正确使用 IDE 一样。

我怎么用 Claude Code

我目前的使用模式大概是这样的：

高频场景（每天都在用）：

• 写样板代码（Boilerplate）：DTO、配置类、标准的 CRUD service，这类代码逻辑简单但写起来枯燥，交给 AI 写完我 review 一遍
• 单元测试：给定一个方法，让 AI 生成测试 case，通常能覆盖我自己想到的大多数情况，再补充一些边界 case
• SQL 写作：尤其是比较复杂的聚合查询和 JOIN，描述好需求，让 AI 起一个草稿，我再调整
• 文档初稿：方法注释、README 初稿、技术设计文档的框架

中频场景（每周用几次）：

• 代码解释：遇到不熟悉的代码，让 AI 帮我解释逻辑
• 重构建议："这段代码有什么可以改进的地方"，AI 通常能提出有价值的建议
• 调试辅助：把报错信息和相关代码贴进去，AI 能快速指出可能的原因

低频场景（偶尔用）：

• 算法实现：一些标准算法（排序、树遍历、图搜索），直接让 AI 实现，然后我理解确认
• 学习新技术：想快速了解某个框架的基本用法，让 AI 用代码示例解释

真实效果：有几件事出乎我意料

超出预期的地方：

AI 在理解上下文和生成"像样的"代码方面，比我预期强很多。给它一个业务需求描述，配合当前代码的上下文，它能生成出我需要再改一点就能用的代码，而不是"看起来像代码"但完全跑不通的东西。

这在一年前还不是这样。我在2023年初试用 ChatGPT 辅助编程的时候，生成的代码质量明显比现在低，经常会用不存在的 API，或者生成逻辑上有明显漏洞的代码。一年的时间，进步非常明显。

不如预期的地方：

复杂业务逻辑的处理能力，依然有明显局限。

当需求涉及多个系统的交互，或者需要深入理解业务规则（比如"退款要考虑会员等级折扣、优惠券的使用规则、是否在质保期内"这类复杂业务逻辑），AI 生成的代码框架是对的，但细节会有很多错误，需要大量修改。

换句话说：AI 擅长"形式"，弱于"业务语义"。它知道怎么写一个 Java Service，但它不知道你们公司退款规则的那些特殊情况。

我踩过的坑

坑1：过度信任，没有 review

有几次我让 AI 生成了一段代码，粗看了一下觉得对，就直接提交了。后来在测试阶段发现了 Bug，排查的时候才发现原来 AI 生成的代码有一个逻辑错误。

从那之后，我建立了一个原则：AI 生成的所有代码，都要经过我的仔细 review，就像 review 别人的代码一样。不能因为"是 AI 写的"就降低 review 的标准。

坑2：让 AI 做架构决策

有一次我问 AI："这个场景应该用 Redis 缓存还是本地缓存？"

AI 给了一个看起来很合理的分析，然后给出了推荐。我直接按推荐做了。

后来问题出现了：AI 没有考虑到我们的部署是多实例的，本地缓存在多实例环境下会有数据不一致的问题，而 Redis 在这个场景下才是正确选择。但 AI 给的推荐恰好是本地缓存。

AI 不了解你的具体部署环境和架构约束，它只知道你告诉它的信息。架构和设计决策，要用自己的判断来做，AI 的建议只是参考。

坑3：用 AI 的方式"假学习"

我发现自己有时候会这样：遇到一个不熟悉的技术点，让 AI 直接帮我实现，"反正能用就行"。

这样积累了几次之后，发现自己对某些技术点的理解依然是空白的，甚至有退步的迹象，因为连"自己摸索"的那点学习也省掉了。

AI 可以加速执行，但不能替代学习。如果你用 AI 绕开了学习，你失去的是比时间更宝贵的东西。

工程师会被 AI 替代吗

我知道你想问这个问题。

我的答案是：一部分工程师，做的一部分工作，会被 AI 取代或者大幅缩减。这是真实的，不是危言耸听。

哪部分工作最容易被取代：

• 大量重复性的样板代码
• 标准算法和数据结构的实现
• 基础的 CRUD 功能
• 简单的 Bug 修复（对于能被清晰描述的 Bug）

哪部分工作不容易被取代（至少在可见的未来）：

• 理解复杂的业务领域，把模糊需求转化为清晰的技术方案
• 在约束条件下做架构权衡
• 处理分布式系统的复杂性（并发、一致性、容错）
• 跨团队的技术协作和沟通
• 对系统整体的持续演进和维护

我观察到的趋势是：AI 工具的引入，确实让一些简单重复的工作减少了，但同时也让对"高阶能力"（架构、系统设计、业务理解）的需求变得更突出了，因为 AI 处理了低层级工作之后，工程师的时间和精力会被期望更多地投入在高层级工作上。

所以，正确的应对策略不是"拒绝 AI"，也不是"完全依赖 AI"，而是：把 AI 变成自己的乘数，同时持续提升 AI 暂时替代不了的能力。

怎么开始用好 AI 辅助编程

如果你还没有系统使用过 AI 辅助编程工具，这是我建议的入门路径：

第一周：选一类适合的任务

从单元测试生成开始。拿一个已有的方法，让 AI 帮你写测试，然后认真 review AI 写的测试，看它覆盖了哪些 case，漏了哪些，为什么漏了。这个过程会快速建立你对 AI 能力边界的认知。

第二周：尝试让 AI 解释代码

找一段你看不太懂的遗留代码，让 AI 解释，然后去验证 AI 的解释是否正确。这会锻炼你的 review 能力，也会让你了解 AI 在代码理解上的水平。

第三周起：系统性地把 AI 融入工作流

确定哪些任务适合交给 AI 加速，哪些任务仍然需要自己主导，建立自己的使用模式。

记住一条原则：AI 是工具，你是工程师。工具服务于你，而不是反过来。

AI 辅助编程改变了什么，没有改变什么

总结一下我观察到的，AI 辅助编程真正改变了什么，以及什么是没有改变的。

改变了的：

• 样板代码的编写速度：显著提升，以前需要30分钟写的标准 CRUD Service，现在可能10分钟。
• 单元测试生成：从"经常被跳过的步骤"变成了"不得不做也不太痛苦的步骤"。
• 陌生代码/框架的上手速度：遇到不熟悉的 API 或者框架，可以快速得到可用的示例，减少了翻文档的时间。
• 简单 Bug 的定位速度：把报错信息和相关代码一起发给 AI，很多时候能快速给出方向。

没有改变的：

• 理解复杂业务逻辑的时间：AI 不了解你的业务，它生成的代码框架是对的，但业务语义要你自己填充，这个需要的时间没有减少。
• 系统设计的思考深度：架构决策依然需要你对系统的整体理解，AI 给的建议要结合你的实际约束来判断。
• 调试分布式系统问题：多服务、多节点的复杂问题，AI 能提供思路，但追踪和定位依然需要大量人工投入。
• 和业务方沟通、澄清需求：这个 AI 完全帮不上忙。

理解这两个清单，能帮助你在实际工作中做出更好的"什么时候用 AI"的判断。

我对未来一两年的预测

不做那种"AI 五年后会怎样"的宏大预测，只说我认为未来一两年最可能发生的变化：

AI 写代码的质量会继续提升，特别是在"有明确规范"的代码领域（如按标准写一个 Spring Controller），会越来越接近"直接可用"的水平。

但在"需要理解复杂约束和历史上下文"的代码领域（改一个10年老系统的核心逻辑），短期内不会有显著突破，因为这需要的不只是写代码能力，而是理解一个系统的全部历史和约束的能力。

结论：如果你在做的工作有很多"标准、重复、规范"的成分，AI 对你这部分工作的影响会比较大。如果你在做的工作需要深度的上下文理解和复杂的系统思维，影响相对有限。

两种工程师都需要拥抱 AI，但拥抱的方式和应该强化的核心能力是不同的。