如何正确使用 AI 编程助手：一个开发者的真实体会
从一段对话说起
前几天，我用 Claude Code 部署这个博客的时候，遇到一个问题：CSS 样式部署到服务器后全部丢失了。我在聊天框里打了一句话：
"CSS 显示不出来，帮我修一下。"
AI 回了一段代码，大概意思是"把 .next/static 目录复制到 standalone 里"。我复制粘贴，确实修好了。但同时它也"顺手"把 dev.db 文件、本地的 PDF 文档、临时 HTML 文件一并 git add -A 提交到了公开仓库。
这就是 AI 工具的一个典型问题——它只做你说的事，但不一定考虑你没说的后果。
AI 能做什么，不能做什么
经过这几个月在多个项目中使用 AI 编程助手的经验，我总结了一下 AI 当前的能力边界：
关于幻觉问题
AI 工具目前最难克服的问题之一就是幻觉（Hallucination）——当它面对自己不知道的事时，不会说"我不知道"，而是"编"一段看起来很合理的答案。
这类问题在编程场景中常见的表现是：AI 调用了不存在的 API，引用了某库的"最新版本"但实际该版本的 API 已经改变了，给出了看起来很完美但根本跑不通的代码。
这和人类的"不懂装懂"很像：但人类在面试或工作中编造答案，往往是意识到自己不知道但选择掩盖；而大语言模型没有"意识"，它只是在概率上觉得这段文本"应该长这样"——它根本不知道自己在编造。
幻觉问题的根本原因是当前大语言模型的运作方式：它们本质上是一个"下一个词预测器"，根据训练数据中学到的模式来生成最可能的回答。当遇到训练数据中没有覆盖、或覆盖不足的问题时，模型不会"承认无知"——因为它在训练中没有学会说"我不知道"能带来更高的奖励。
这意味着什么呢？意味着你永远不能把 AI 的输出当作最终答案。你需要自己去验证——跑一下代码能不能工作、查一下文档看 API 是否真的存在、思考一下逻辑是否自洽。
把 AI 当助手，而不是当老板
有个比喻我觉得特别贴切：AI 就像一个非常博学但偶尔会胡说的实习生。
你给实习生的任务越具体越好——"帮我写一个处理登录请求的 handler，要求：验证用户名密码、返回 JWT token、处理三种异常情况"和"帮我做登录功能"这两个 prompt 的质量天差地别。同时你不能完全信任实习生的输出——代码要 review，方案要讨论，重要的决策要自己拍板。而且你要为最终结果负责——出了问题，背锅的不是实习生，是你。
什么情况下 AI 真正好用
在我这几个月使用 AI 编程助手的经历中，以下几种场景是 AI 真正帮我提效的：
第一，理解和梳理代码。面对一个新的开源项目或者同事留下的旧代码，让 AI 帮你解释这段代码在做什么、数据流是怎么走的，比你自己一行一行读快多了。
第二，生成重复性代码。写第三个 CRUD 接口的时候，你已经不需要动脑子了——把前两个接口的模式告诉 AI，让它帮你生成第三个。这类机械劳动 AI 做得很靠谱。
第三，作为交互式文档。以前查 API 用法要打开 Stack Overflow 或者翻官方文档，现在直接在编辑器里问"Prisma 7 怎么配置 MySQL 连接"，得到的答案通常是可以直接用的。
第四，快速排查简单 Bug。把报错信息贴给 AI，它能帮你缩小排查范围，甚至直接给出修复方案。虽然不是 100% 准确，但比你自己从零开始排查快很多。
什么情况下 AI 反而拖累效率
另外一些场景，过于依赖 AI 不仅没提效，反而浪费了时间：
第一，架构设计决策。选什么技术栈、怎么组织模块、数据库怎么建模——这些需要理解全局上下文和权衡各种约束的决策，AI 给的建议往往过于"模板化"，缺乏对具体场景的洞察。
第二，涉及生产环境的安全操作。部署、数据库迁移、权限修改——这些操作一旦出错后果严重，AI 做这些事需要非常详细的确认和监督，不如自己动手来得安全。
第三，复杂的关联 Bug。那种需要追踪七八个文件、理解整个调用链路才能找到根因的 Bug，AI 往往只能分析表面的调用关系，追不到跨多层、跨多个模块的深层根因——因为它的上下文窗口装不下所有相关代码。
正确使用 AI 的几个原则
基于以上的实际经验，我总结了几个使用 AI 编程工具的黄金法则：
从具体问题出发，而不是大而化之的要求。告诉 AI 你要解决什么问题、当前的上下文是什么（哪些文件、什么框架）、你希望的输出是什么。"帮我写一个完整的电商系统"不是一个好的 prompt，"帮我写一个 Express 中间件，用于验证请求中的 JWT token，token 在 Authorization header 的 Bearer 字段中"才是。
始终验证，保持怀疑。AI 给你的代码，至少要在本地跑一下。AI 给你的解释，至少要和官方文档对一下。不要因为 AI 说得"很自信"就相信它——语言模型的设计目标就是"说出像人类写的话"，而不是"说出正确的话"。
你负责策略，AI 负责执行。架构怎么设计、模块怎么拆分、数据库怎么建模——这些需要全局视角的决策，自己来。具体的实现细节、模板代码、测试用例——这些机械劳动，交给 AI。
不要跳过学习过程。用 AI 帮你理解一个概念是好的，但如果你完全依赖 AI 写代码，时间一长你会发现：
- 你不理解自己项目的架构
- 你改不动 AI 写的代码
- 你会越来越频繁地让 AI 解决自己产生的问题 这是个危险的循环。AI 加速了编码，但不能替代学习。
这四条原则，一张图总结：
写在最后
AI 工具正在飞速演进，上面说的这些"AI 不擅长"的事情，可能一两年后就不再是问题。但在当下（2026 年），最有效的使用方式仍然是人机协作——你做好架构和分工，AI 在具体任务上帮你加速。
记住一个简单的原则：如果一个问题你自己都不知道答案，就不要期望 AI 能给你正确答案——它大概率会给你一个"看起来是对的"答案，而你没法判断。只有当你自己对问题有一定理解，才能发挥 AI 的真正价值：让它做那些你会做、但懒得做的事。
AI 是很好的工具，但它不是魔法。把期望放低一点，把 prompt 写具体一点，把验证做得认真一点——你的效率提升会非常真实。