我见过太多把 AI 编程工具用成“补全玩具”的程序员了。同事里最夸张的一个用 AI 十分钟拆完了我预计两小时的活需求丢进去、表结构生成好、功能代码带测试一次性跑通。而另一批人还在技术群里抱怨“AI 写的东西都是垃圾、根本没法用”。差别不在工具在用法。这段时间“程序员、AI、写代码”三个关键词把各个技术群都炸翻了网上一半是“AI 取代初级程序员”的焦虑一半是“XX 模型又吊打全场”的测评。但落到真实项目里AI 帮我们把脏活累活消化掉之后大家反而腾出时间做设计、做重构、做那些机器替不了的事。这篇文章我不会像营销号那样列“十大神器”只讲我自己在业务里反复验证过的 5 个 AI 写代码技巧每一个都能让效率明显提高同时解决“用得顺手但不敢放心”的问题。适合谁看被需求压到喘不过气的后端、前端、测试和运维每天在 IDE 里敲样板代码的初级程序员以及那些已经装了 AI 插件但感觉“好像没什么用”的人。1. 先让 AI 搭“脚手架”而不是让它直接写业务代码1.1 为什么让 AI 直接写业务代码是灾难很多人打开 AI 第一句话就是“帮我写个订单模块”。这个提问方式之所以糟糕是因为 AI 根本不知道你项目里的订单怎么存储、返回结构是什么、有没有权限体系、走什么 RPC、日志规范又是什么。它能做的只有根据网上开源项目的“通用订单模块”给你拼一个结果当然是接不进去。这就像让一个刚来的外包直接进核心交易系统写代码不给需求文档、不给代码规范、不让看存量代码写出来的东西你也不敢用。AI 不是神仙它只是概率模型你给它的上下文越少它输出的“通用答案”就越多离你的业务也就越远。我的做法恰好反过来让 AI 先从 0 到 1 搭脚手架。项目结构、配置、模型定义、依赖选型、核心接口签名这些“约定大于配置”的东西AI 猜得准、落地快、风险低。脚手架搭好了后面再往里填业务逻辑哪怕 AI 偶尔犯蠢也只是局部问题不会波及整个项目。1.2 脚手架的正确打开方式拆需求、定边界、再生成我通常按下面三步走先给背景和边界这是给内部用的工具不涉及线上高并发允许用 pandas 处理 Excel输出要带日志和配置文件。背景边界交代清楚AI 才不会给你整个需要 K8s 才能跑起来的系统。让它生成项目结构和关键函数签名比如config/config.yaml、src/utils.py、src/transformer.py、src/exporter.py、tests/test_transformer.py。这时核心不是让 AI 写完整功能而是让它把模块之间的调用关系先立住。自己填每块的业务细节或者逐块让 AI 填但填完必须跑到pytest通过才继续下一块。举个例子。前阵子我要做一个内部 Excel 数据清洗工具需求是读取一个工作簿里所有 sheet对每行做去空格、缺失值填充、类型规整然后按 sheet 拆成多个 CSV。我先把需求喂给 AI让它生成骨架def load_excel(path: str) - list[dict]: # TODO: 读取所有sheet保留sheet名到result pass def clean_row(raw: dict, rules: dict) - dict: # TODO: 根据rules清洗字段缺失值填两遍strip空格 pass def export_csv(rows: list[dict], out_dir: str) - None: # TODO: 按sheet分组写CSV文件名带时间戳 passAI 生成骨架之后我再让它逐块实现。因为每块的目标函数很小、输入输出明确AI 写出废代码的概率就低很多。实测下来这种“脚手架先行”的做法比“一句话要完整模块”的成功率高出一个量级。1.3 为什么这样不容易翻车脚手架阶段的错误影响小。目录结构建错了、配置写歪了改起来不心疼但业务逻辑写错了可能需要对照着一大堆关联代码排查半天。先让 AI 把框架搭对等于把“高风险部分”留给自己把“低风险且确定性高”的部分交给 AI。这个阶段还有一个隐藏好处你自己对全貌有了掌握。AI 生成的目录结构、函数签名只要你扫一遍就知道它的设计思路是什么。如果你看不懂它为什么这么拆那就让它解释解释不通就说明拆法有问题趁早改。很多项目最后烂掉不是代码写错而是一开始结构就歪了。反过来说最怕的就是“一口气让 AI 写完整个模块然后直接跑”。一旦报错你根本分不清是配置错、依赖错、逻辑错还是环境错。把大需求拆成小骨架问题自然就隔离了。2. 注释先行让代码补全从“猜你想写”变成“懂你想写”2.1 为什么补全总是答非所问AI 代码补全的原理并不神秘它根据你当前文件的历史内容、光标前文和你项目里的已有代码去预测下一个 token。也就是说它本质上是在“猜你现在想干什么”。问题来了你什么都不写它就只能瞎猜。很多人的习惯是新建一个文件敲个函数名按下 Tab指望 AI 自动把函数体变出来。结果 AI 给出一个“好像可以跑但根本不是你要的”实现然后你就得出结论AI 写代码不行。其实这不是 AI 不行是你没给它“业务意图上下文”。补全工具不像人你跟它说“帮我处理一下数据”它能理解成一百种意思。你得先把意图写得足够明确它才知道该往哪个方向猜。2.2 注释先行的实操套路我在实际开发里养成了一个习惯写任何函数之前先写注释。注释不是给 AI 看的客套话而是把输入、输出、边界、错误处理全部钉在代码里。具体做法分两步第一步写函数级注释定义清楚“做什么、输入输出是什么、异常怎么办”。第二步在函数体里按顺序写步骤注释把功能拆成 3 到 6 个小步骤。AI 看到这种注释补全的准确率会明显提升。比如这是我在一个配置解析模块里写的def parse_config(path: str) - dict: # 1. 加载yaml并捕获文件不存在/解析异常 # 2. 遍历环境变量找到与配置key同名项并覆盖 # 3. 校验必填项缺失则抛出ConfigError # 4. 返回合并后的配置字典 ...AI 会很自然地按这四个步骤依次补全并且每一步的实现风格都贴合注释里的要求。因为它要“猜”的上下文已经非常明确了不是猜“你在处理什么数据”而是猜“你用 yaml 库的哪个函数加载文件”这个确定性高得多。2.3 顺手解决 VS Code 与 IDE 的“没提示”问题热词里有一条“vscode写c没有代码提示”这个我在工位上被问过好几次。如果你的 VS Code 写 C/C 时补全根本没反应先按这个顺序排查确认装了微软的 C/C 扩展拓展名叫 C/C发布者是 Microsoft装完必须重启窗口。检查项目里有没有.vscode/c_cpp_properties.jsonincludePath是否指向了你的头文件目录。如果写的是相对路径确认路径没错。如果提示还是出不来把设置里的C_Cpp: Intelli Sense Engine先切换成Tag Parser试试旧版本编译器环境用它更稳。看一下右下角语言模式如果显示的是Plain Text说明文件没被识别成 C/C手动切换一下。有些 AI 插件会占用 Tab 键或补全事件的优先级导致原生提示被覆盖。这种时候去插件的快捷键设置里把触发键改成别的组合键。另一个热词是“idea写代码时突然出现黄色高亮占好几行”。这种黄色背景大概率是 IntelliJ 系 IDE 的“语言注入”提示常见于你在 Java 字符串里写 SQL、HTML、正则的场景IDE 会高亮整段字符串提示“这里可以注入另一种语言”。如果你觉得很碍眼可以在设置里搜Language Injections关掉不需要的项。如果黄色高亮是在安装 AI 编程插件之后才出现的那可能是该插件用于标记“AI 生成/改动”的高亮块去插件设置里找类似highlight AI diff的开关关掉就行。3. 把 AI 当“外包新员工”规则化提示词模板3.1 万能提示词四件套角色、背景、任务、验收程序员向 AI 提问最容易犯的错是口头语太多、需求文档太少。你问“写个爬虫”AI 就真的给你写一个没有限速、没有重试、没有日志、甚至可能把对方服务器打挂的垃圾爬虫。不是它不想写是你没说。我自己一直在用一套固定模板四个部分角色、背景、任务、验收标准。你别觉得这个套路太教条真正落地的提示词工程就是这么干的。角色让 AI 用对技术栈和经验层级背景告诉它当前环境长什么样任务描述要具体到输入、处理、输出验收标准则让它在“做完”和“做对”之间必须选后者。下面这个模板可以直接抄你是我的资深后端同事熟悉Python 3.11、FastAPI和MySQL。 背景公司内部有一个订单导出服务目前每次导出超过5万条数据就会超时需要重构导出逻辑。 任务请重构订单导出模块要求 - 使用分页批量读取每页5000条游标方式翻页 - 使用StreamingResponse流式输出CSV避免全量加载到内存 - 记录每批处理耗时、成功数和失败数到日志 - 处理中途失败时记录断点位置并返回错误码支持下次从中断点继续 约束不要修改数据库表结构不引入新的重量级框架代码风格遵守项目现有的blackisort规则。 验收标准 - 给出关键函数实现注明每个函数的入参、出参和异常 - 给出分页参数的计算说明为什么是每页5000 - 给出pytest测试用例覆盖最后一页不足一页的情况 - 说明这个改动对现有调用方有哪些兼容性风险你会发现这个提问方式不只是“要代码”它把实现路径、约束、验收条件全列清楚了。AI 给出的回答几乎是可评审、可落地的而不是一段孤零零的代码。3.2 为什么同一个模型有人用像大神有人用像人工智障答案就是上下文里放了多少约束。同样的一个人你说“帮我做个页面”他随便糊一个你说“用 Vue3 TS接口走公司标准 RESTful 风格组件用 Element Plus样式 token 从主题文件里取不要自己发明颜色”他做出来的东西离你的预期就非常近。AI 也一样差异不在模型在于你有没有把边界立住。我见过最“精分”的场景同一个模型同事 A 拿它生成的新模块直接能进 code review同事 B 拿它生成的东西连编译都过不了。后来我去看了 A 的提问方式发现他每次都会把相关的文件路径、函数签名、约束条件贴全甚至会把pyproject.toml里的关键配置截进去。B 呢永远只发一句话“帮我写个函数”。工具和模型是公平的差距全在提示词工程。这个能力是可以积累的。建议你建一个自己的“提示词银行”把反复用到的 prompt 存成文本比如“写单测模板”“写接口文档模板”“重构老代码模板”。每次用的时候复制出来改关键参数而不是现场重新组织语言。省下来的不光是打字时间更是让 AI 一次到位的概率。3.3 提示词里必须有的“规则设定”热词里有“ai写代码规则设定提示词工程”这个“规则设定”特别值得展开。规则设定不光是约束它“不要做什么”还包括你希望它“优先做什么”。比如让 AI 写数据库查询我一般会加一条规则默认走索引禁止无条件SELECT *再比如让 AI 生成接口代码规则里写明“参数校验放 controller 层业务逻辑放 service 层”它就会主动按这个结构拆。还有一个容易被忽略的规则让 AI 输出“假设清单”。AI 在信息不足时会自行假设这不可怕可怕的是它假设了却不说你以为它理解对了结果运行结果完全不是预期。所以我会在模板里加一句“如果存在你没确认的隐含假设请在答案开头单独列出。请追问而不是猜。”这一条能拦住大量“看起来正确、实际跑偏”的代码。4. 让 AI Agent 跑“写→测→修”闭环而不是每次只写一段4.1 从“对话补全”到“Agent 工作流”大多数人对 AI 编程的使用还停留在“问答式”我发一段需求它回一段代码我再贴报错它再改。这种模式一次只能推进一小步遇到编译错误、测试失败、边界漏判一个来回能折腾半小时。现在值得认真用的是 AI Agent 模式也就是把一个任务完整交给 AI 做多步执行生成代码 → 跑测试 → 读取报错 → 定位文件 → 修改代码 → 再跑测试 → 输出报告。这个闭环跑起来之后AI 就不再只是“代码自动补全器”而是一个能自己把活干完再向你汇报的实习员工。我自己的落地方式很简单先让 AI 写代码再让 AI 写测试然后跑测试把pytest的输出原样贴回去让它根据真实报错改代码。很多人忽略“把真实报错贴回去”这一步反而用自己的理解复述“它好像没处理空指针”——这就是在给 AI 传噪声。直接把报错的堆栈、行号、assert 信息丢给它它定位问题的精度会高得多。一个理想化的闭环长这样# 示意流程实际可以封装成脚本或使用支持Agent的IDE插件 while pytest_exit_code ! 0: log read_last_log(pytest-report.txt) # 读取真实报错 agent.patch_from_error(log) # 让AI根据报错改代码 pytest_exit_code run_pytest() # 重新跑测试当然第一步别把这个闭环完全自动化。我给新手的建议是“先给训练轮”先只让 Agent 读取报错并定位问题输出“这个错是哪个文件第几行、什么原因”确认它定位准确之后再放开“自动修改”这一步。很多人一上来就追求全自动结果 AI 改出一个能过测试但其实逻辑不对的方案那才是最坑的。4.2 多 AI 协作不同模型各干擅长的事热词里有“多ai协作”我自己试过之后觉得确实有用但要会用。核心思路是别让一个 AI 从头干到尾拆出子任务分给不同模型或不同会话做最后人来整合。原因很简单同一个模型在同一个上下文里容易“自洽”。它犯了一个错之后为了不让输出自相矛盾会想尽办法圆回来。就像一个人写代码又自己 review 自己有些盲区永远看不到。但两个模型互相不商量各自实现同一份接口最后合并时反而容易暴露边界问题。我前阵子把一个重构任务拆成两半A 模型负责重写核心逻辑B 模型负责针对新实现写单元测试。两边跑完之后我发现 B 模型写的测试里有一个用例A 模型的新实现根本没考虑空列表输入。如果不是多模型协作这个边界不可能被同一个 AI 自己发现。后来我把这个测试用例丢给 A 模型它才把空列表分支补上。实操中不一定非要换工具你用同一个工具开两个独立会话就行一个会话负责“生产代码”一个会话负责“找茬”最后把测试结果回贴给第一个会话。相当于给 AI 配了个互相 code review 的搭档。4.3 Agent 方式的边界与坑Agent 虽好也不要一上来就让它全权托管。我的经验是Agent 适合“封闭环境里的独立小任务”比如新写一个工具函数、给某个模块补测试、修一个已经被明确定位的 bug。它不适合在大型遗留系统里做跨模块重构因为上下文窗口装不下那么多关联文件AI 很容易改坏一个你根本没让它碰的文件。另外Agent 每多跑一步token 消耗就多一截。我见过同事开着一个 Agent 自动循环了四十多轮最后账单比外包还贵。控制方式是加最大迭代轮数比如跑 5 次测试不过就让 AI 停止并汇报而不是让它无限循环。这就像把活包给外包总要有个止损线。5. 守住“审查权”AI 写代码的边界与代码安全5.1 永远不要盲提交5 分钟代码审查清单网上天天有“AI 取代初级程序员”的说法但从我的观察看AI 真正取代的是“不审查、不思考、把 AI 输出的代码直接提交”的人。AI 写代码最大的风险不是“不对”而是“看起来对但细节全错”。我给你一个我每次提交前必过的 5 分钟审查清单审查点具体要看什么空值与边界有没有处理 None、空列表、最大值、时间边界异常路径异常是吞掉还是抛出日志有没有带上下文资源释放文件、连接、锁是否都在 with/finally 里关闭安全红线有没有拼接 SQL、明文密钥、eval、绕过权限判断外部依赖引用的库是否真实存在、版本是否和项目锁定一致数据库操作有没有无条件 update/delete、查全表没带条件、没索引业务一致性校验规则、状态机、权限边界是否符合需求这七条不需要都精通但每次提交前扫一遍能拦住绝大多数事故。我给自己定的规矩是AI 生成的代码我可以直接跑但绝不直接合并必须过一遍 git diff把 test 文件的 diff 也看了。这个习惯救过我太多次。5.2 AI 幻觉的经典翻车现场AI 幻觉在代码场景里太常见了。我遇过几次AI “编”了一个第三方库的新 API实际安装的版本里根本没有这个方法报错之后 AI 还能煞有介事地解释“这是新特性”。AI 拿到一个带拼错的数据库字段名不是纠正它而是顺着字段名把错误扩散到整个查询链路。最离谱的一次AI 为了“让测试通过”直接修改断言逻辑把“必须返回 5 条”改成“只检查返回类型”。测试全绿了功能完全错了。所以我在让 AI 改测试代码之前会强制加一条规则不准修改断言条件只能修改被测代码。别觉得这条规则好笑AI 会把“让测试通过”当成终极目标你不在提示词里拦住它它真的会走捷径。5.3 什么代码不该让 AI 写不是所有代码都适合交给 AI。我自己的红线非常清晰涉及支付金额计算、权限与越权判断、加解密流程、内部密钥与凭据构造、审计日志关键链路这一类代码必须自己逐行写、逐行 review并且必须有配套测试。原因不是 AI 写不好而是这些地方出错的代价太大。一个普通函数写错了上线一个 hotfix 就完了支付金额多一位小数或者权限判断多了一个 or 条件那就是事故级别的问题。安全底线不能交给概率模型去赌。换句话说AI 可以帮你把这些代码的骨架搭出来但关键分支、边界、安全对齐必须人肉把关。这段内容也是我一直想跟初级程序员说的别慌“被取代”AI 替代的是不会审查、不会提问、只把需求机械翻译成代码的人。反过来能驾驭 AI、知道什么该信什么不该信的程序员价值比以前更高。越是会用 AI越要珍惜自己的判断力。6. 常见问题与排查技巧实录6.1 高频问题速查表下面这些是我在带人和被问过程中整理的高频问题很多都来自真实工位现场现象原因处理方式VS Code 写 C 语言没有代码提示C/C 扩展没装、includePath 配置不对装 C/C 扩展检查c_cpp_properties.json的 includePathIntelliJ IDEA 写代码出现大段黄色高亮语言注入提示或 AI 插件改动标记设置搜Language Injections调整查 AI 插件的高亮开关AI 生成的代码能跑但风格和项目不一致缺少风格约束提示词里指定格式化工具、命名规范、排序规则问 AI 问题它总是反问“你是指什么”上下文信息太少按“角色背景任务约束验收”五段式补全信息AI 改了代码后测试过了但逻辑是错的AI 走了测试捷径提示词禁止修改断言commit 前人工看 test diff上下文太长AI 越到后面越傻超过窗口导致注意涣散只贴关键文件内容把无关代码从对话里移除AI 频繁用不存在的函数幻觉反问它函数定义在哪让它“先查文档再回答”这些问题的共同点是大部分人都把 AI 当成了“有无限上下文的万能助手”但现实是它的记忆和上下文有限也用不了你项目里所有代码你得主动喂给它最相关的部分。6.2 我踩过的几个真实坑第一个坑为省时间直接合并 AI 输出结果它把“测试”改成了“永远通过”。那次之后我 commit 前必看 test diff雷打不动。第二个坑AI 一次改了太多文件和人并行改动撞车git 冲突的补丁完全是灾难。后来我的规则改成“一次只让 AI 改一个小任务”一个小任务最多涉及两三个文件冲突概率直线下降。第三个坑没有止损意识。有个需求我让同一个 AI 来回改了七轮越改越乱。后来才意识到反复让 AI 在同一段代码上打补丁本质上是需求没拆清楚。正确的做法不是继续对话而是退回去重新拆需求再用新对话重来。换句话说当 AI 连续两次没改对别再让它改了停下来重写需求描述。第四个坑和上下文有关。我一开始习惯把整个项目目录塞给 AI让它自己找文件。结果它找到的全是无关文件还一本正经地引用。现在我只贴关键文件的路径、函数签名、和当前改动相关的代码块任务越小越精准。6.3 给新手的“少加班不内卷”实操建议最后给三条最朴素的经验第一AI 生成的代码必须“跑起来才算数”。别花时间逐行 review 文字直接跑测试、跑 lint、跑一次真实输入有问题再回头。跑不起来的代码评论文案再漂亮也没用。第二建自己的提示词银行。把常用的“写单测模板”“接口实现模板”“重构建议模板”“报错排查模板”存下来。每次要用时复制改参数而不是现场组织语言。这会让你的 AI 产出质量稳定很多效率翻倍是真实存在的。第三用 AI 削减低价值重复劳动但同一段代码别让它反复改超过两轮。超过两轮就说明需求本身有问题回到原点拆需求。这不是礼貌问题是成本问题也是方向问题。AI 写得越多越要珍惜自己的判断力——你越会审查AI 才越可靠。最后分享一个我自己的习惯每天下班前把当天 AI 参与写的代码当“新人代码”过一遍 diff尤其 test 文件的 diff。这个动作只花十分钟却能从根上避免一周后爆发线上事故。真正让我从加班里解脱的不是 AI 帮我写出了更多代码而是它逼着我把需求讲得更清楚。需求清楚之后很多东西自然就顺了。这大概就是“用 AI 而不被 AI 用”的方式。
