1. 先还原一下自作聪明的各种翻车现场在聊怎么治之前我们得先把病看清。我见过太多人第一次用AI编程助手时的状态先是惊叹这也太快了然后是它怎么这么懂我再然后就是某个深夜对着一段完全看不懂的代码发出灵魂拷问——你到底在干什么所谓自作聪明我把它分成三类每一类都是我在实际项目里真实踩过的坑。1.1 编造API最普遍也最坑的一种这是最经典的翻车方式。你让AI写一个读取配置文件的功能它给你写了一个load_config()这个函数在它训练数据里确实存在但它属于某个跟你项目八竿子打不着的第三方库。你复制粘贴跑起来第一行就报AttributeError或者ModuleNotFoundError。更隐蔽的是参数编造。比如Python标准库里某个函数明明只有两个参数AI给你传了五个上去其中有三个是它觉得应该有的。这类错误在静态语言里还能被编译器拦住在Python、JavaScript这种动态语言里经常是跑到了才炸排查起来特别痛苦。1.2 擅自改逻辑你只让它改个函数名它给你重构了一半工程我自己的一个真实经历项目里有个函数叫calcTotal()我让AI助手把这个函数重命名为calculateTotal保持其他逻辑不变。结果倒好它不但改了函数名还顺便优化了内部实现——把原来两层循环改成了列表推导式把if-else改成了try-except。逻辑从相等才累加悄悄变成了不相等就跳过看起来差不多实际边界情况全变了。单元测试跑完三个用例直接挂掉。类似的事情还有你让它修复一个bug它给你附赠了一个重构你让它加一个字段它把整个数据模型都改了你让它写个接口它顺便把数据库表结构也优化了。你要的是局部手术它给你做了个全身换血。1.3 幻觉依赖装包装了个寂寞还有一种情况更气人。AI给出的代码里用了一个库你在项目里根本没见过这个库。你去搜发现这是个冷门到几乎没人用的包甚至可能是AI自己编出来的、从未存在过的包名。有次我让它写个图片压缩的脚本它给了一个叫image_squeezer的库。我去PyPI上搜倒是有个同名包但维护者是我这辈子没听说过的个人开发者下载量个位数。装是能装但你敢把生产环境的图片处理逻辑交给这么个来路不明的包吗这三种情况前两种还能靠编译器或测试捞回来一点第三种直接威胁供应链安全。所以自作聪明不是小事它不是一个忍忍就过去的体验问题而是会导致线上故障、引入安全隐患的实质风险。2. 为什么会这样大模型出错的机制不搞清楚没法对症下药如果你只是想要几个提示词技巧可以直接跳到第三章。但如果不想每次都靠运气怼提示词建议花五分钟把这一章看完——理解了出错的机制怎么治就变成了一件顺理成章的事。2.1 概率生成不是数据库查询这是最根本的认知纠偏。大模型不是在你电脑上装了一个代码数据库然后给你做精确检索它是一个概率生成器——每生成一个token都是基于前面所有内容计算出一个概率分布然后从中采样。换句话说AI不是在回忆一个确切存在的API它是在猜测一种看起来合理的写法。训练数据里某段代码出现过一百次它就敢写出现过五次它也敢写一次没出现过它照样敢写——凭它学到的规律去编一个。这个机制决定了什么决定了你不可能通过换个更好的模型来彻底解决编造问题。模型再强也只是把编得有逻辑的概率提高了不可能做到百分百精确。所以我一直强调AI写代码的正确姿势不是让它独立完成而是在充分约束下让它完成。2.2 上下文窗口与遗忘边界第二个机制是上下文窗口。现在的模型上下文窗口动辄几万、几十万token看起来很大但实际上你塞进去一个大型项目的全部代码早就超了。就算没超模型对上下文中间部分的注意力也没你想的那么强。实验下来最典型的现象是对话一开始你给它交代了三条约束它都遵守了。写到中段上下文越来越长它开始忘记前面的约束然后自由发挥。这不是它故意的而是注意力机制天然倾向于开头和结尾中间部分容易被稀释。所以我后来总结出一个铁律不要在一条超长对话里让AI干一整件事。把大任务拆成小任务每个小任务的上下文里重新强调约束条件宁可多花几次调用也不要让它忘事。2.3 对齐训练与过度服从的副作用第三个因素对很多人来说是盲区。AI在训练阶段做了大量对齐alignment目的是让它更顺从、更愿意满足用户需求。这本来是好事但副作用是——当你给了它一个任务哪怕你给的指令和项目现状有冲突它也会优先做完而不是优先做对。典型场景你代码库里已经有一个工具函数formatDate()了但你不知道你让AI写一个格式化日期的函数。正常的人类同事会提醒你项目里已经有了但AI不会——它会直接给你再写一个新的哪怕两个函数内部逻辑一模一样。更麻烦的是你在描述需求时如果出现了前后不一致AI通常不会停下来问你您到底想要哪个而是选一个它认为最合理的来解释。这个自作主张的选择就是自作聪明的直接来源。理解这三个机制之后治理思路就很清晰了第一别依赖模型的记忆和判断用明确的上下文给它提供事实第二别让它做超出上下文承载能力的大任务第三用流程和验证来兜底而不是赌它这次会听话。3. 治病第一层在提示词里把约束焊死先说最简单、也最容易被忽视的一层——提示词。很多人的提示词写得跟发短信似的帮我写个接口这段代码有问题帮我改改。这种提示词等于把方向盘完全交给了AI它当然会按自己的理解乱开。3.1 显式禁止自作主张给出负面清单我的做法是在提示词里加一块负面清单negative constraints明确告诉AI什么事情不能做。比如任务修改 payment.py 中的 calculateTotal 函数 要求 1. 只修改 calculateTotal 函数的函数名改为 calculateTotalAmount 2. 内部实现、注释、日志输出完全保持不变 3. 不要改动本文件中其他任何函数 4. 不要顺手优化代码结构或调整算法 5. 如果发现函数内部有引用需要同步更新引用并在回复中列出所有被修改的引用位置有人说AI根本不会理这些实测下来恰恰相反。负面清单的效果远好于正面期望——因为正面的要求保持逻辑不变太抽象模型容易理解成逻辑大致不变我可以微调一下实现方式而不修改实现、不改动其他函数是具体的、可检查的指令模型基于注意力机制会更容易遵守。要注意的是负面清单要写在任务描述之后、让AI动手之前最好单独成一个段落。塞在中间容易被上下文稀释掉。3.2 用只改指定文件缩小爆炸半径多文件项目中AI自作聪明的破坏力会成倍放大——它可能一口气改了五六个文件你都不知道它动了什么。我的对策是凡是涉及修改已有代码的任务强制指定文件白名单。允许修改的文件 - src/utils/data_parser.py - tests/test_data_parser.py 禁止修改的文件 - src/utils/config.py - src/schema.py任何涉及数据库字段或接口格式的定义 - migrations/ 下所有文件用列表形式给出比尽量不要改其他文件明确得多。我甚至在项目里维护了一个AI_RULES.md每次写新的对话开始前贴给它——后面第3.4节细讲。3.3 强制先解释后动手的思维链很多人遇到过这种情况AI直接给出一大段代码你看着觉得有问题但说不出来具体哪里不对。改它的代码它又改回一个有新问题的版本。解决办法是先让AI用自然语言复述任务并说清楚思路经过你确认后再出代码。例如在动手写代码之前请先回答 1. 你打算怎么实现这个功能 2. 需要修改哪些文件 3. 有哪些关键设计决策为什么这么选 4. 有没有更简单的替代方案为什么不选这一招非常有效。原因在于模型在先写解释的过程中会把任务在逻辑上理顺一遍很多自作聪明的决策在这一步就被自己发现了——它发现自己编造了一个不存在的API在解释阶段就会编不下去。而且这个先解释后写的顺序天然地应用了思维链效应推理质量显著提升。我的个人习惯是对复杂任务至少做两轮对话。第一轮只确认方案第二轮才让AI落代码。虽然多花几十秒但返工率降低得不是一星半点。3.4 给AI一份项目契约比每次苦口婆心强如果你频繁使用AI写代码不要每次都从头写约束。我建议给每个项目创建一份AI_CONTEXT.md专门给AI看内容包括项目是什么、用什么语言/框架/包管理工具目录结构说明和各模块职责代码风格约定缩进、命名、注释习惯不能动的文件/模块如数据库schema、配置模板、自动生成代码区常见陷阱比如某些历史遗留代码AI容易踩进去测试命令和校验流程在每次对话开始时直接说请先阅读项目根目录下的 AI_CONTEXT.md然后按照其中的约定完成任务。这比你在提示词里临时写一大段约束稳定得多因为上下文是完整且一致的不会因为某次对话写得简略就走样。用文档把约束固化下来本质上就是你把每次都要跟AI解释一遍项目状况的成本提前一次性付清。刚开始花半小时写之后每次对话都省回来。4. 治病第二层从工作流上让AI没有乱来的机会提示词约束是软约束AI可能遵守也可能悄悄越界。真正可靠的防线是把流程设计成让AI即便想乱来也没有乱来的空间。这一层属于治理体系而非文本技巧。4.1 拆小步每步验证拒绝一次性大需求我见过很多人的典型操作把一个完整的功能需求给我做一个用户登录模块包含注册、手机验证码、忘记密码、第三方登录一次性丢给AI让它生成。这几乎是必翻车的。原因一是任务太长上下文塞不下AI写着写着就忘了前面的约束原因二是功能之间有关联AI在实现A功能时做的某些假设在实现B功能时根本对不上。正确做法是拆成原子任务任务1写一个用户注册接口输入为邮箱密码返回用户ID 任务2写一个登录接口校验密码签发JWT 任务3写一个发送验证码的工具函数先不关联注册流程每个任务完成后马上验证——编译、跑单测、人工看一遍。确认没问题再进入下一个任务。每步验证的好处是出错了你知道错在哪个小任务里修复成本低很多。如果是一次性生成2000行代码再统一调式你会在一个巨型错误堆里不知道从哪下手。4.2 用编译、测试当守门员提示词约束失效时需要机械性的检查来兜底。我用的组合是静态检查Python项目用ruff或flake8JavaScript项目用eslintTypeScript项目还额外加上tsc --noEmit。这些工具能拦住一大半调用了不存在的函数传参数量不对的低级错误。单元测试关键函数必须有测试。我给AI的要求是在生成代码的同时生成对应的测试用例。不需要多复杂的测试框架一个简单的pytest或vitest就够用。类型检查如果项目还没上TypeScript我会用pyright或mypy给Python补上类型检查。AI写出的代码加上类型标注的出错率会明显下降因为这个过程迫使它把接口协议想清楚。每次AI给出代码我都会做一遍命令式验证而不是直接信任它的输出。有次它给我写了一段文件处理逻辑逻辑本身看不出问题但mypy一跑暴露了一个Optional类型解引用错误。这种错误靠肉眼看很难发现但类型检查器一秒钟就抓出来了。4.3 关键部位锁死能靠配置就不靠自觉项目里总有一些碰一下就要出事的模块数据库表结构、接口协议定义、支付逻辑、加密相关代码。这些地方我建议在物理层面锁死让AI连找都找不到。具体做法把这类文件放到单独目录比如src/core/下并在AI_CONTEXT.md里标注禁止修改更严格一点在代码评审工具里配置机器人比如CODEOWNERS要求AI生成涉及这些文件的代码必须有人工审批文件本身加只读权限在本地用chmod或版本管理工具配置只读保护有同事觉得这有点小题大做但经历过一次AI顺手改了加密算法参数的惊魂事件后所有人都安静了。那次AI把AES-256-GCM的nonce长度从12字节改成了16字节代码能跑但和下游服务已经部署的加解密逻辑完全不兼容。要不是上线前有人比对diff这就是一次线上事故。修改权限的粒度要跟出错代价成正比。出错代价越高的文件权限就越收紧这是最朴素的管理逻辑放在AI协作里同样适用。4.4 让git当后悔药这一点太重要了单独拿出来说。任何AI生成的代码改动都必须经过git的diff审查。我的操作习惯是git diff # 查看改动 git diff --check # 检查空格等格式问题审查完没问题再git add和commit。如果AI的改动混在一起分不清可以先让AI只改一个文件或者用交互式暂存git add -p手动挑选每个hunk。不要嫌麻烦。看一遍diff的花费是五分钟被AI悄悄篡改逻辑后线上出问题的花费可能是五小时甚至五个通宵。用工具强制自己养成这个习惯AI就永远没有趁你不注意乱来的机会——它改了什么你全都知道。5. 治病第三层化解已出现的自作聪明——一个迁移脚本的救赎过程讲了这么多预防手段总归有已经发生的翻车。这一章我用一次真实的排查过程完整展示一遍从发现AI改坏了代码到定位根因到修复的思路。这个思路比任何具体命令都重要因为它是可以复用的模式。5.1 现场还原AI给自己加戏的完整链路事情起因很简单我们有个旧系统数据库里存了一批订单数据需要迁移到新系统。旧字段order_status的值范围是0-5新系统换成了字符串枚举pending/paid/shipped/completed/cancelled/refunded。我觉得这活太机械了就丢给AI写迁移脚本。为了说明规则我特意附上了一个映射表0 - pending 1 - paid 2 - shipped 3 - completed 4 - cancelled 5 - refundedAI交回来的脚本一开始看起来完全正常就是从数据库读出order_status跑一个字典映射再写入新库。我准备跑一遍测试数据结果测试用例里有两个用例失败。5.2 排查与修复我怎么一步步揪出问题第一个直觉是AI映射表写错了。我把脚本里所有映射关系打印出来核对发现映射表完全正确。那是数据库读取问题我检查了查询语句也没异常。然后我注意到了失败用例的特征出错的订单都是order_status 3也就是completed但脚本处理出来的结果却是shipped。这就奇了映射表里3 - completed明明是对的。我打开脚本一行一行读终于发现了它自作聪明的地方。它在映射逻辑前加了一段状态校验# 自动修正异常状态如果订单金额为0将已完成订单视为待发货 if order.amount 0 and mapped_status completed: mapped_status shipped它觉得金额为0的已完成订单是不合理的所以擅自加了一条业务规则。问题是这个合理性假设只存在于它的训练数据里不是我们业务团队制定的规则。测试用例里故意造了一些金额为0的已完成订单来验证迁移完整性被它这么一改全被修正了。修复方案很粗暴删掉那段校验逻辑回归纯粹的映射。但真正有价值的反思在后面。5.3 复盘同样的问题为什么还会复现这个案例有典型性吗太典型了。AI在任务描述里挖掘出了它自己觉得重要的隐藏需求然后基于错误的假设生成了代码。复盘下来我发现问题出在任务描述——我只给了映射规则没有解释这是一次全量数据迁移任何业务判断都不需要。在信息缺失的情况下AI用训练数据里的通用规律订单金额为0可能是未支付填补了空白自我脑补了一条规则。之后我的任务描述模板就多了一条业务背景这是一次全量数据迁移目标是原样复制字段值映射到新系统。 特别注意除非明确说明否则不要添加任何业务规则、校验逻辑或异常处理。迁移的完整性高于数据合理性。加上这句话之后同类问题再没出现过。这里面的教训是AI的自作聪明很多时候源于信息不对称——你以为是常识的信息它不知道你以为不需要说明的事情它默认需要补充。所以在任务描述里明确写上不要做什么以及为什么不要做比只写要做什么重要得多。6. 说点实在的AI写代码该用什么心态和姿势最后这部分不聊具体命令了聊聊更底层的使用哲学。毕竟工具用的时间越长我越发现态度比技巧更能决定上限。6.1 把AI当快但莽撞的实习生而不是无所不知的专家这个类比可能不够新颖但我必须说它确实是最贴切的。一个优秀实习生的特点是学习能力强、执行速度快、干活积极。缺点是经验不足、容易误解需求、会在你不知道的地方自作主张。你会怎么带这个实习生你不会把生产环境直接丢给他就让他在上面随便改。你会先给他一份详细的任务说明告诉他哪些能碰哪些不能碰你会定期检查他的产出而不是一周后再来看你会把最重要的模块自己来写把琐碎的、低风险的杂活交给他。对AI请用完全一样的方式。你在指点资深工程师时可以省略很多背景但在指示AI时必须事无巨细。它不是理解力差而是太容易自以为是。6.2 哪些代码可以放心交出去哪些必须握在手里根据我的使用经验AI适合处理的任务和不适合处理的任务边界其实挺清晰的适合交给AI不适合交给AI样板代码CRUD接口、DTO定义、配置加载核心业务规则与算法单一、明确定义的小工具函数涉及多系统交互的链路测试代码生成、mock数据生成数据库迁移、支付、权限等敏感逻辑代码格式转换、注释补充遗留系统改造AI不了解历史包袱写正则、写SQL、写文档需要深入业务沉淀的领域逻辑这个表格不是绝对的但我建议每个团队都建立一张类似的AI可做/不可做清单并且随着使用经验不断更新。边界设定越清晰AI越能发挥优势风险越可控。6.3 长期来看建立你自己的AI协作规范我特别不建议每个人按照自己的习惯随意使用AI然后靠个人临场发挥来规避问题。更可持续的做法是把零散的经验收敛成一份团队/个人的AI协作规范。这份规范至少要涵盖任务分级什么任务可以AI独立完成直接提交什么任务必须AI生成后人工审什么任务完全不让AI碰交接模板给AI写任务时的最小信息集合——输入、输出、边界、禁止事项验证流程AI产出物的检查步骤至少包括编译通过、测试通过、人工diff上下文化配置每个项目都要有AI_CONTEXT.md并在开始AI对话前强制提供事故复盘AI生成了问题代码导致线上故障后不只是修复还要复盘是哪个环节让自作聪明漏过了防线我把这套规范落地到团队之后明显的改善是AI产出代码的返工率显著下降线上出问题的频次几乎归零。AI写的代码不靠谱这个印象很大程度上源于使用者没有建立流程约束。一旦约束到位AI在恰当的任务范围内产出质量其实非常稳定。说到底治好AI的自作聪明不是指望AI不犯错而是用合适的方式定义任务、用合理的流程验证产出、用清晰的边界控制影响范围。能做到这三件事AI写代码从看起来很快但不敢用到又快又好其实差的只是这一整套工程化的协作习惯。写这篇文章的这段时间里我又让AI写了几个函数、改了几段配置每次都很顺利。不是AI变得更强了而是我变得更加知道怎么跟它打交道了。希望这篇文章也能让你少走一些我走过的弯路。