夜雨聆风2025 年夏天我开始密集用 AI 编程助手。起初跟所有人一样，问它怎么写个正则、怎么处理某个报错。用了一个月觉得"还行吧"，但说不上多惊艳。
转折发生在一次深夜赶工。我需要重写一个数据清洗模块，大概 400 行代码。与其逐行手敲，我把整个需求和数据结构丢给 AI，让它先出一版框架。它给了，粗糙但有骨架。我在这个基础上改，40 分钟跑通。
那天我意识到一件事：我之前用法是错的。把 AI 当搜索引擎用，你只能得到搜索引擎级别的回报。把它当搭档，产出完全不同。
大多数人卡在哪
我观察过身边十几个用 AI 编程工具的开发者，用法基本分三个层次：
第一层，把它当 Stack Overflow。遇到报错贴过去，要一段代码片段。这是 80% 的人停留的地方。AI 回答质量确实比搜索好，但本质上没改变工作方式。
第二层，让它写完整功能。描述需求，让它生成一个函数甚至一个文件。这一步很多人尝试过，但经常被质量劝退，生成的代码能跑，但不够好，改起来比自己写还慢。
第三层，把它当协作者。不是让它"代替你写"，而是让它"跟你一起想"。先一起搭骨架，再分头干活，它写模板代码，你做决策和打磨。
第三层才是甜区。但到这一层之前，大部分人被第二层的体验卡住了。
一个具体的方法
我后来固定了一套流程，写新模块时反复用。拿上周的例子说，要做一套 API 限流中间件。
第一步，扔上下文，不扔需求。
很多人上来就说"帮我写一个限流模块"。这等于让 AI 猜。我的做法是先把它"拉进项目":技术栈是什么，现有中间件怎么组织的，路由层长什么样，数据库用什么。这些信息我一次性贴过去。
它不需要猜了，给出的方案直接贴合现有架构，而不是凭空造一个。
第二步，要骨架，不要成品。
我明确说:"先给我接口定义和整体结构，不用实现具体逻辑。"AI 写完整实现时容易在一些边角细节上"发挥"，变量命名风格不统一、异常处理方式跟项目其他部分不一致。骨架阶段不会有这个问题，因为它写的只是结构。
拿到骨架后我看一眼:路由对了，中间件链位置合理，限流策略的选择留了扩展点。这时候我心里有数了，方向没问题。
第三步，分块实现，每块给约束。
逐个文件实现时，我每次都带上约束条件:"这个文件参照现有 auth 中间件的写法，错误返回格式跟 utils/errors 里一致，不要引入新依赖。"约束越具体，生成质量越高。
四块代码，每块两三轮对话。最后一跑，有个竞态问题，把报错贴回去，它定位到是 Redis 原子操作的问题，给了修复方案。整个模块从开干到测试通过，不到两小时。
几个容易踩的坑
别让它一次性写太多。超过 200 行的输出，质量会明显下降。分块来，每块聚焦一个职责。
别信任它给的依赖版本号。AI 经常推荐最新版本，但你的项目可能锁定在旧版本。依赖相关的建议，一定自己核实。
它写的测试，自己再测一遍。AI 写测试代码时有个倾向:围绕"快乐路径"写，边界条件覆盖不够。它写的测试能过，不代表你的代码真的对。我自己补测试时会专挑它没考虑到的输入。
注意上下文窗口的"健忘"。对话长了之后，前面给过的约束它会忘。我的习惯是每开一个新功能点，把关键约束再强调一次，不嫌啰嗦。
一些反直觉的经验
用得越久，我越觉得几件事跟直觉相反。
写得越细，反而越快。一开始我觉得"把需求说清楚"很花时间。后来发现，说清楚花 5 分钟，省下的是 30 分钟的来回纠偏。模糊的需求导致模糊的输出，模糊的输出导致反复修改，这个循环比写需求本身慢得多。
不会问问题的人，用不好工具。AI 编程助手的上限取决于你问问题的质量。"这段代码有 bug"和"这段代码在并发场景下偶发空指针，我怀疑是初始化顺序的问题"，后者的回答质量碾压前者。
它的价值不在写代码，在省决策。 我后来回顾，AI 帮我省掉的最多的时间不是"敲键盘"的时间，而是"发呆想方案"的时间。以前面对一个需求会先坐着想半小时该怎么做。现在把需求扔过去，它给三个方向，我花五分钟判断哪个靠谱。决策快了，执行自然快。
写在最后
工具是中性的，但用法有高下。同样一把刀，有人切菜有人雕花，区别不在刀，在持刀的人。
AI 编程助手也一样。它不会自动让你变成更好的工程师，但如果你愿意花时间找到跟它的协作节奏，回报是实实在在的。我至今没有让 AI 独立写过一个完整模块，但几乎每个模块都有它的参与。
这个边界自己拿捏:哪些交给它，哪些留给自己。拿捏清楚了，工具就真的变成了搭档。
这篇是个人使用经验总结，不涉及具体工具的推荐。各家 AI 编程助手的能力差异在缩小，但使用方法的差异一直在。
