同一个大模型有人用它一天干完一周的活有人用它一分钟改出三天的bug。这不是模型能力的差别而是人和AI互动方式的差别。我见过太多开发者的AI用法停留在“把需求丢进去、把代码复制出来”的阶段结果就是AI写的代码不敢用、不会改、出了问题也不知道该怎么问。这篇东西不聊那些虚的我直接把这两年用AI辅助编程踩过的坑、总结出来的提示词打法、人和AI之间的上下文管理技巧以及AI Agent和多模型协作的实操思路都摊开讲。适合正在用AI写代码但总觉得“差点意思”的开发者也适合刚入门、想避开那些显而易见弯路的新手。1. 先从认知上把“AI辅助编程”这件事想清楚很多人用不好AI编程第一道坎不是技术是认知。他们默认AI就是一个“高级搜索引擎”或者“自动代码生成器”搜到答案就完事生成代码就复制。其实真正有效的AI辅助编程核心是两件事任务拆解和验证闭环。任务拆解是指你把一个大的需求拆成一个个小到可以让AI单次处理的单元。验证闭环则是指AI每产出一段结果你都有办法快速判断它到底对不对。这两件事没想明白后面再花哨的提示词技巧都是空中楼阁。1.1 AI到底适合干什么、不适合干什么先把我实测下来的结论摆出来。AI在编程上真正擅长的是这些样板代码和胶水代码。比如写一个REST接口、配置解析、DTO转换、初始化脚本这类重复度高、模式固定的东西AI生成速度快、质量也稳。已有代码的解释和梳理。扔给它一段你看不懂的历史代码让它按模块讲清楚逻辑效率远高于自己一行行啃。测试用例生成。喂一个函数签名和业务规则让它把边界情况、异常分支、正常路径都列一遍覆盖面往往比人想的全。跨语言翻译和框架迁移。比如把Python的脚本改写成Go把JQuery的老代码迁移到Vue3AI做这类“已知等价转换”很强。正则表达式、复杂查询语句、文档注释这类“短而精”的产出。手写正则容易漏边界AI反而稳。不适合干的事也要心里有数凭空做架构决策。比如“我这个项目应该用微服务还是单体”——这类问题AI给的答案看似有理实际它并不了解你的团队、流量、部署条件只能给你通用话术。安全敏感模块的最终拍板。涉及支付、权限、加密、鉴权的代码AI能给出初稿但最终必须由人来审计。需求本身就模糊不清的“帮我做个东西”。你越说不清楚它越给你一堆华丽但不切实际的代码。记住一句话AI是你手里的“高级外包工程师”不是“产品经理”。它需要你给出足够清楚的任务边界才能干出靠谱的活。1.2 大脑里的“任务拆分”比提示词更重要提示词技巧当然重要但它建立在一个前提上——你自己先想清楚要把任务拆成什么样。我用AI写一个用户注册接口时不会直接说“帮我写一个用户注册接口”而是拆成四步生成用户表结构设计字段、类型、约束、索引生成注册接口的输入校验逻辑生成密码加密存储的数据访问层代码生成邮箱重复注册时的异常处理每一步我都能明确判断“它给出的东西是否符合预期”这就是验证闭环。如果一股脑丢给它它生成的代码又长又杂任何一个地方出问题你都很难定位是哪一段逻辑的问题。拆任务的标准也很简单一次只改变一个“输入输出契约”。所谓契约就是输入是什么、输出是什么、出错怎么办。一次对话里只让AI完成一个契约不要混合。这样不管是审查还是修改你都有一条清晰的边界。2. 写代码场景下的提问与提示词打法认知理顺之后我们再聊具体的提示词打法。很多人以为提示词就是“讲人话”其实编程场景下的提示词有它专门的套路。我把实际使用中最常用的四种任务格式列出来生成、修改、解释、调试。每种格式的构造方式都不一样。2.1 四种任务格式直接生成、改错、重构、解释直接生成。关键信息要包括编程语言、框架、函数签名、输入输出约束、不允许用的库。一个我实际用过的模板是用Python写一个函数输入是一个列表元素为dict每个dict包含name和score字段。 输出是排序后的新列表按score从高到低排序score相同则按name字典序升序。 只能用标准库不要用第三方库。 请返回完整函数代码附一个使用示例。修改现有代码。必须把目标代码片段和你期望的改动一起贴进去。比如下面是现有代码。我要把超时时间从固定5秒改成可配置参数timeout默认值还是5。 请直接输出修改后的完整函数不要把无关代码也列出来。这里有个容易踩的坑你只贴一个函数但函数依赖类内部的其他方法AI改的时候可能会基于自己的想象改造依赖关系。正确的做法是把依赖的上下文也贴进去哪怕字多一点也比它编一个假依赖强。重构。除了贴代码还必须定义“重构后什么样才算好”。比如下面这段代码实现的是订单状态机的状态流转。 请在不改变外部调用接口的前提下用策略模式重构消除if-else。 输出时请说明每个类的职责。注意我加了“不改变外部调用接口”这就是约束。没有约束的重构AI经常给你把函数签名都改了下游全崩。调试。这是最看上下文功底的一种。需要三个要素预期行为、实际行为、报错信息或日志。示例下面这段Python代码预期是每秒打印一次当前时间但实际程序在运行时偶尔会跳过一次输出。 这是代码…… 这是日志片段…… 可能是什么原因请列出三个排查方向并给出每个方向对应的验证方法。注意我让AI给出“排查方向”而不是直接改代码。因为在调式阶段盲改代码容易引入新问题先让AI列方向你来判断优先级才是稳的。2.2 给AI“上下文”的3个具体方法方法一按“最小完整片段”贴代码。不要只贴报错那一行要贴整个函数或类。也不要把整个项目贴进去贴太多反而稀释了重点。一般贴函数体加上它调用的几个关键依赖就够用了。方法二把数据结构说清楚。如果你贴的代码里有自定义对象告诉AI这些对象的字段含义。AI理解字段名的能力比理解真实业务含义强得多你不解释它就只能猜。方法三明确“不能用什么”。不少需求是“不要用A库、不要用B写法、不要动C模块”这些负面清单越具体AI就越不容易自由发挥。比如不要使用requests库用urllib。 不要修改database.py里的任何内容。 不要用eval。负面清单其实就是给生成结果划了一条安全线AI在边界内的发挥才是有价值的。2.3 提示词里的“角色、约束、边界”三板斧进阶写法是在提示词里同时注入角色、约束、边界。我称之为三板斧。第一板斧是角色。不一定要花哨但要有领域针对性。比如“你是一名有十年经验的后端工程师熟悉Flask和PostgreSQL”这比“你是一个AI助手”管用得多。角色越贴近当前任务的领域它给出的代码风格和词法习惯就越对路。第二板斧是约束。包括性能约束并发量、响应时间、依赖约束只准用某个库、风格约束遵循PEP8、不允许超过80行。约束是让AI输出可控的关键。第三板斧是边界。也就是写清楚“这个函数的输入输出范围”。比如输入的用户对象保证非空无需做null检查。 函数只负责处理业务逻辑不负责调用持久层。 出错时统一抛出BusinessException。边界写清楚了AI就不会自己加塞一堆“你没想到但自以为很贴心”的逻辑。这三板斧用全生成质量会有肉眼可见的提升。我实测下来不加这些的生成结果平均要改两三轮加全之后不少代码基本能用只需要小修。3. 让AI替你测试和审查代码AI测试开发实战很多人把AI当“写代码的”但在我看来AI在测试和代码审查上的价值甚至比生成代码更高。写代码是从0到1AI常常会加戏审查代码是找茬AI反而能冷静地找出人类容易忽略的地方。这个章节我重点讲怎么用AI做测试和审查。3.1 从需求描述直接生成测试用例的思路测试用例生成的核心是把“需求描述”翻译成“验证条件”。我常让AI做的事是“给我列出测试用例清单”而不是直接生成测试代码。清单阶段可以很容易判断覆盖范围比直接生成代码更高效。提示词示例下面是一个函数的规格说明 - 输入两个整数a和b - 输出a除以b的商 - 异常b为0时抛ValueError 请列出所有需要覆盖的测试用例包括正常路径、边界路径、异常路径。 每个用例给我输入、预期输出、用例意图。这种方式的妙处在于AI列用例时遵循的往往是一套通用测试方法论等价类划分、边界值分析、异常路径比很多开发随手写的用例全得多。3.2 边界条件、异常分支、空值检查让我举一个实际的AI测试用例清单输出。比如输入是一个包含姓名和年龄的字典函数返回是否成年。AI会覆盖这些用例类型输入预期意图正常路径{name: 张三, age: 20}True大于等于18边界值{name: 李四, age: 18}True临界值边界值{name: 王五, age: 17}False临界值减1异常路径{name: 赵六, age: -1}抛异常年龄为负异常路径{name: 钱七}抛异常缺少age字段异常路径{name: 孙八, age: 20}抛异常类型错误空值检查{None}抛异常输入为空dict或None可以看到AI列的清单里既有边界值又有类型错误很多开发第一次写这个函数的用例时未必能一次覆盖这么全。清单确认后你再让它“根据上面的用例清单用pytest生成测试代码”它产出的代码就更好用。3.3 Code Review让AI帮查逻辑漏洞和安全隐患代码审查是我现在最依赖AI的场景。具体做法是把一段刚写完的代码贴过去然后按四个维度让AI给你挑刺性能、安全、可读性、边界情况。提示词模板下面是一段Python代码实现用户上传文件的大小校验和类型白名单过滤。 请从四个维度审查安全漏洞、性能问题、边界情况、可读性问题。 对每个问题标注严重程度高/中/低并给出修改建议。 不要直接重写代码先列问题。我先让它列问题这比让它直接改更安全。因为AI直接改代码时常常会改动超出预期但它列问题的时候你可以对照自己的代码逐个确认再决定要不要采纳。实践中AI在以下这几类问题上尤其敏锐竞态条件。比如检查文件和上传文件之间缺少原子性。资源没有释放。文件句柄、数据库连接没关闭。不安全的反序列化。pickle.loads这种高危操作。错误信息泄漏内部细节。比如直接把堆栈甩给用户。空指针/空值风险。它比人更擅长注意到“这个字段可能为None”。有一类问题是AI审查不出来的业务语义错误。比如一个折扣规则本来应该“满100减20”你代码写成了“满200减20”AI不会发现因为它不知道你的业务规则。所以审查的半成品还是得有业务经验的人去兜底。4. AI Agent与多模型协作把单次问答变成流水线如果你的AI用法还停留在“一问一答”那你只挖掘了这个时代一半的潜力。过去半年我最大的进步是从“单次问答”转向“流水线式的Agent协作”。说人话就是让AI自己扮演多个角色分阶段地把一个任务往下推。4.1 当好一个“AI Agent”的前提条件AI Agent在编程场景里表现为它不只是回答你的问题而是能自主完成任务链。比如你给它一个需求它能自己读项目代码、运行测试、看到失败结果、再改代码、再跑测试直到通过。对我们大多数普通开发者而言不需要去研究复杂的Agent框架只需要做两件朴素的事第一把人工流程写下来。比如“先让AI生成接口代码 - 再让AI生成测试用例 - 再让AI根据测试结果修复代码”这是一个最简流水线。第二把流水线的每一段设计成能从前一段的输出自动获得输入。比如第一段产出的是“接口代码”第二段就把这段代码和需求一起作为上下文。第三段把报错信息作为上下文。这样每段之间就形成了接力。这里的关键是你人站在这条流水线外面做“质量闸门”每一段的输出都要经过你的判断才进入下一段而不是傻傻地让它一路自动跑到底。4.2 多AI协作不同模型干不同活不同大模型的脾气差异很大这个我实测体会很深。有的模型生成代码的大纲和结构特别漂亮但细节容易错有的模型在数学和逻辑推理上更稳适合做审查和纠错有的模型中文表达好适合解释文档和技术方案。所以我目前的做法是“多AI协作”让擅长不同的模型干不同的活结构生成让A模型先用文字描述实现方案、模块划分。代码初稿基于A模型确定的方案让B模型写具体代码。代码审查把B模型的代码给C模型审重点找bug和安全隐患。文档撰文让D模型把整个过程整理成技术文档。这个协作过程中各模型的输出相互制衡。B模型写了一段可能过度的逻辑C模型会指出来A模型给了不合理的方案B在写代码时会暴露出问题。多模型交叉验证比同一个模型“既写又审”有效得多——同一个模型的固定偏好自己很难纠正自己。如果你只有一个模型可用也可以用“角色切换”模拟多模型协作让它先扮演架构师出方案再扮演资深工程师写代码再扮演QA挑刺。虽然不如真多模型交叉但也比一次生成到底强。4.3 自己搭一个最小的Agent工作流我分享一个最简可落地的工作流不需要任何额外框架就是纯靠提示词和文件组织。步骤需求描述文件。把需求写成markdown文件包含输入、输出、约束、验收标准。方案生成。让AI基于需求文件输出技术方案保存为plan.md。代码生成。把需求方案一起给AI让它按模块生成代码文件每人一个函数/一个类。自动测试。让AI根据需求中的验收标准生成测试代码然后人来运行。失败反馈。把报错信息原样复制给AI让它定位并修复。审查合并。代码通过测试后让AI从安全、性能角度做最终审查。这里不需要什么花哨的框架只要每个步骤的输入输出是明确的文本文件或代码文件你就是在和一个“人肉Agent”协作。更妙的是每一步的产物都可追溯出了问题时你能知道是方案错了还是代码错了而不是黑盒里一团乱麻。5. 对话式互动的上下文管理你与AI的“工作记忆”标题里“互动”这个词我理解为人跟AI之间持续的对话协作。很多人在这个环节上踩大坑因为对话里的上下文就是AI的“工作记忆”而这份记忆是有限的也是会遗忘的。5.1 上下文是什么为什么会丢大模型一次能“记住”的对话内容是有上限的专业术语叫上下文窗口。你可以把它理解成一个工作台工作台上能同时摆下的文件数量有限。你平时跟AI聊得越久、贴的代码越多工作台就越满最早的对话细节就会被挤掉。我在实际使用中经常遇到的情况是聊了半小时中间贴了好几段代码突然发现AI回答问题时已经忘了最开始指定的变量命名规则又自顾自用了一种新风格。这不是它笨是经验超过了上下文限制。解决办法有三个把长对话拆成短对话。一个任务开一个新对话不要指望一个对话串起所有工作。关键约定在每次提问时重复一遍。比如“变量命名仍按baseline_开头”哪怕AI记得你强调一遍也没什么成本。保存中间产物。把重要结论比如方案文档、代码规范单独存成文件在每个新对话里贴进去。5.2 让AI总结当前状态再接续当对话已经进行到一定长度直接往下问新问题时AI容易混淆。我的习惯是先让它“倒带”总结再继续。典型提示词先不要做任何新内容。 请把我们从开始到现在已完成的事项总结为三点 1. 已经确定的技术方案 2. 已经写完的代码文件 3. 还剩下没处理的问题 总结完再等我的下一步指令。这一步本质上是在刷新工作记忆也让你自己看一眼进度。它把AI的隐性记忆变成显性清单双方在同一个页面上工作。我在项目进行到中期、对话超过20轮之后几乎必用这一招。5.3 常见互动误区一句话反复追问、情绪化表达误区一不补直接追问。比如之前让AI生成过一个函数你想让它改其中的错误直接说“那个函数还是不对再改改”。问题在于“那个函数”在很长对话里出现过好多次AI分不清你指的哪一个。正确做法是在追问时把要修改的函数代码原样贴一遍再说明具体错误。误区二对AI情绪化发泄。“你怎么又错了”“你到底行不行”这类话对模型没有任何正面作用反而会挤占上下文空间。AI不会受情绪影响它只会根据文字内容做出反应。如果你真的不满就把不满足的细节说清楚哪里错了、预期是什么、实际是什么。误区三全盘接受AI的第一个答案。AI在对话里有一种“迎合倾向”它会倾向于给你一个看起来合理的答案而不一定会纠正你描述中不严谨的地方。你要做的是追问它“这个方案的缺陷是什么有什么情况下会不适用”我几乎每个方案都会让它自辩一轮再拍板。6. 我踩过的坑和现在的工作流这一章全是实在话。我从依靠AI写代码效率翻倍也因为它翻过车。把这些坑讲出来是想让你少走我走过的弯路。6.1 AI生成的代码最容易在哪几个地方埋雷依赖版本幻觉是我踩过的最大的坑。AI会为你写出一个库的用法但这个API可能在它训练数据里存在而你实际安装的版本根本不一样。尤其是一些较新的第三方库API变动频繁AI很容易按旧版本生成。解决方式是每次AI提到一个不熟悉的依赖先让它给出“你确定的版本号”并说明依据再自己去官方文档确认一遍。虚拟API命名也是高发问题。AI有时会编造一个不存在的模块或函数。这种现象在比较冷门的库中尤其严重因为训练数据少它只能编。我现在的对策是关键词检索。AI如果用了某个库的API我会先在本地执行一次大多数情况下报错会在第一时间暴露。还有一类问题是重复代码和过度设计。AI生成代码时倾向于把同一段逻辑复制到多处尤其是在生成多个相似功能时。代码一多维护就是噩梦。所以我在让AI生成多个文件之前会明确要求“公共逻辑提取成独立函数不要复制粘贴”。6.2 我的实际工作流长这样现在我最舒服的状态是这样的需求拆解用纸笔代码生成交给AI审查分两层人类卡最后一道。早上到公司我先把今天要开发的三个需求各写一段“一句话说明”和“验收标准”。然后直接把第一个需求丢给AI让它生成方案文档。我看一遍方案觉得合理再让它生成代码。代码回到我手上我快速扫一遍结构和命名然后让AI自己写测试用例我负责跑。跑挂的用例原样贴给它修。最后合代码之前它再以审查者视角找一轮安全问题。整个流程下来我坐在电脑前的时间不变但产出的质量比以前高因为AI把低价值的体力活全包了我只需要做判断。判断这件事恰恰是AI替代不了、也不应该替代的。6.3 一点个人体会AI编程是“素养放大器”说句掏心窝的话我发现AI编程在拉大而不是缩小开发者之间的差距。基础扎实、理解系统的人用AI能把一个小时的任务压缩到十分钟基础薄弱、逻辑混乱的人用AI可能会把十分钟就能写完的代码改成三个小时都调不通的烂摊子。根本原因在于AI是把你的意图放大成代码的“放大器”。如果你的意图本身是模糊的、错误的、边界不清的放大出来的代码就是模糊的、错误的、更难维护的。所以我最后的建议很朴素别把AI当神仙把它当一面镜子。你输入的信息质量怎么样输出的结果就怎么样。认真拆解需求、认真写清楚上下文、认真审查每一段AI生成的代码这才是“更好用AI辅助编程”的本质。我现在每天跟AI互动的习惯总结起来就一句话给它一个清晰的任务边界让它干活然后亲手验收。既不神化它也不轻视它。这就是我目前认为最健康的“人机互动”状态。