从去年底开始，我逐步把 AI Coding Agent 深度整合到了日常开发流程中。半年多下来，它从一个"偶尔用一下的玩具"变成了我工具箱里最常用的工具之一。
这篇文章不是工具推荐，也不是"AI 会取代程序员"的宏大叙事——只是一份真实的、来自一线的使用报告。
三个阶段
回顾这半年，我对 AI 编码工具的使用大致经历了三个阶段：
阶段一：问答模式。遇到不熟悉的问题时，把 AI 当搜索引擎用。查 API 用法、看配置示例、问最佳实践。这个阶段最大的感受是：回答的质量取决于提问的质量。
阶段二：代码生成。开始让 AI 写整段代码——函数、组件、甚至整个模块。但很快发现一个问题：AI 生成的代码看起来"差不多对"，但细节往往有问题。不验证就直接用，后面要花更多时间 debug。
阶段三：协同工作流。这是我现在所处的阶段。AI 不再是一个"问答窗口"，而是融入了我的开发流程——读代码、改代码、写测试、重构。这个阶段的关键不是让 AI 做得更多，而是让它在正确的时间做正确的事。
AI 编码工具的核心价值，不是替你做决定，而是帮你缩短"想到"和"看到"之间的距离。
我实际在怎么用
以下是我当前日常开发中实际在用 AI 的场景：
1. 阅读和理解代码
接手一个旧项目或进入一个不熟悉的代码库时，我会让 AI 先"读"一遍整体结构，然后有针对性地问细节。这比我手动翻文件要快得多——尤其是当项目比较大、文档不够完善时。
2. 写样板代码和胶水代码
数据结构定义、API 路由注册、配置项枚举…… 这些重复性的、但必须写的代码，交给 AI 最合适。我给出接口定义和风格要求，它生成初版，我 review 后微调。
3. 写测试
让 AI 写单元测试是我觉得回报最高的用法之一。给定一个函数和它的输入输出约束，AI 能快速生成各种边界 case 的测试，覆盖手动写容易遗漏的场景。
4. 重构建议
当我感觉一段代码"不太对"但说不上来哪里不对时，让 AI 从不同角度分析——可读性、性能、扩展性。它经常能指出我因为太熟悉而忽略的问题。
踩过的坑
当然，AI 编码远非完美。以下是我遇到的主要问题：
- 幻觉仍然严重。AI 会自信地编造不存在的 API、方法签名或配置参数。尤其在不太流行的框架或库上，幻觉率很高。
- 上下文窗口限制。对于跨多个文件的大改动，AI 经常"忘记"前面的约定或上下文，导致前后不一致。
- 过度设计。AI 倾向于把简单问题复杂化——引入不必要的抽象、设计模式或依赖。需要人工把控边界。
- 越改越差。当 AI 改错时，让它"再改一次"往往不是修正问题，而是把代码改得更乱。这时最好回退到上一步，重新描述需求。
工作流中的位置
我现在的原则是：AI 负责执行，我负责决策。
具体来说：
- 明确的需求和设计方案由我制定
- 重复性的实现工作交给 AI
- 每次 AI 输出的代码必须 review
- 架构层面的决定不依赖 AI
这样分工的好处是：我保留了对自己代码库的完全控制权，同时把大量"必要但不重要"的工作外包了出去。
最后
AI 编码工具正在快速进化，但在我看来，它目前仍然是一个"放大器"——好的开发者会变得更好，而糟糕的实践会被放大得更快。
工具会变，原则不变：理解你要解决的问题，写出清晰可维护的代码，对交付的东西负责。
这篇文章就是用 AI 辅助写的——从构思到成文，大概花了一个多小时。你觉得怎么样？