我做了快十年后端这两年用AI写代码的时间比手写多。但有个事始终让我头疼这玩意儿太爱“自作聪明”。你让它改一个变量名它顺带把你整个函数重写了你问它一个bug可能出在哪它直接给你开新分支改完代码还觉得自己干得漂亮。GitHub上的issue里全是这种吐槽有人说“AI写代码就像刚入职的程序员——热情洋溢但总在事后让你收拾烂摊子。”这篇文章想聊的就是我摸索了小半年、结合团队实践整理出来的一套“治AI”方法论。核心是三件事规则设定、提示词工程、工作流约束。适合被AI“坑”过的开发者也适合刚接触AI编程、不想让它一开始就“放飞自我”的新手。读完你会知道大部分“自作聪明”其实是可被提前扼杀的而你要做的不是换工具而是换用法。1. “自作聪明”到底是怎么发生的1.1 一次让我血压升高的“优化”先说我真实的翻车现场。那段代码是个运营后台的订单导出接口逻辑不复杂无非是拉数据、填表、处理一下边界值。我让AI“优化一下导出性能”它给的结果是把同步导出改成了异步任务、引入了消息队列的封装、增加了一层缓存抽象、还主动加了个“重试机制”。听着是不是很“专业”但我们的业务根本没队列基础设施那套代码落不了地等于白写。这还不是最气的。后来我在Code Review里看到同事的AI生成代码明明只让修一个空指针异常AI把整个类的构造函数都改了连带着把另一个模块的依赖关系全打乱了。这种“超额完成”在AI编程里太普遍了普遍到大家已经默认“AI嘛给个方向就行细节别太指望。”但我后来想通了——问题的根子不在AI身上在我自己身上。因为我给的指令是“优化一下”这种指令在计算机眼里就是“你可以自由发挥”。它当然会按训练时数据里那种“最优解模板”来干活而这个模板往往就是过度设计。简而言之你不画边界它就默认没有边界。1.2 根因拆解不是AI坏是约束不够要治“自作聪明”先得理解它的决策机制。AI编程工具本质是一个基于大语言模型LLM的代码补全器它的输出是“基于你给的上文预测最可能的后续代码”。它的目标是高概率匹配训练数据里的常见模式而不是精确执行你的意图。这就造成几个典型问题它见过的代码质量差异巨大。训练数据里有大量“被人诟病”的过度设计代码在“优化”类提示下它会把那些“看起来更高级”的模式当作优选。它的理解偏向“最大化满意度”。你用模糊词“优化”“改进”“更好”时它会倾向于做更多事来增加“帮助感”。它缺少对项目上下文的判断力。在不清楚业务规模时引入消息队列、缓存、设计模式是它在“无信息环境”下的默认选择。我打个比方你雇了一个能力很强的实习生你跟他说“帮我把办公室收拾一下”他给你把办公桌布局都改了、文件重新归类了看起来更整洁了但你要找的东西找不到了。问题不是实习生笨是你给的指令边界太宽。AI写代码就是这样——你不说“只允许做X不允许做Y”它就把X、Y、Z全做了。1.3 “靠人品”不如“靠规则”很多人对付AI“自作聪明”的办法是碰运气“这次说得清楚一点应该就行吧。”但实测下来单次沟通的约束力很差因为AI会随着对话增长逐渐“遗忘”你前面的要求尤其是当上下文超过它的注意力窗口时最早的限制条件会被淡忘。所以真正有效的思路是把“规则”从对话里抽出来变成常驻的、每次对话开始时AI都会先加载的东西。这就是“规则设定”在做的事。它解决的问题是不是每次对话都存在一次性的提醒而是让AI在“进入项目的那一刻”就知道——这个项目的代码风格是什么、哪些事绝对不能干、完成任务的验收标准是什么。我团队里现在所有AI辅助编程的仓库都强制带一个规则文件没有这个文件AI一律只做“只读问答”不做任何修改。这不是矫枉过正这是从血泪教训里总结出来的制度。2. 用规则文件给AI立“职业底线”2.1 选对规则载体AGENTS.md、CLAUDE.md还是项目配置市面上主流AI编程工具的规则承载方式各不一样但万变不离其宗。现在最常见的几个载体AGENTS.md越来越多工具默认读取的通用规则文件放在项目根目录CLAUDE.mdClaude相关工具的专用规则文件.cursorrulesCursor早前版本的方式现在部分迁移到.cursor/rules/目录copilot-instructions.mdGitHub Copilot目前支持的仓库级指令文件需在.github目录下不要纠结选哪个你项目用哪个工具为主就配哪个。如果团队里工具混用最省事的方法是把同一份规则内容同时写到AGENTS.md和CLAUDE.md二者不冲突。现在的AI工具兼容性比前两年好识别到哪个文件就加载哪个规则。有个细节值得注意规则文件放根目录还是子目录影响的是AI的“作用范围”。根目录的规则对所有文件都生效子目录的规则只在相关路径下生效。我个人建议核心团队规范放根目录模块级特殊约束放子目录避免根目录规则过于臃肿。2.2 规则文件内容怎么组织拿来即用的模板规则文件不是越长越好太长了AI反而会抓不住重点。我实践下来最有效的结构是“三段式”角色定位、行为准绳、验收标准。下面是一份我目前实测效果很好的模板你可以直接复制修改# 项目开发规则 ## 角色与定位 你是一名严格服从的资深工程师首要目标是按用户指令最小化变更 而不是追求“更优设计”。用户没有要求的改动一律视为多余改动。 ## 行为准则按优先级从高到低 1. 只做被明确要求的修改不做额外优化、重构、格式化。 2. 不改变函数签名、类结构、依赖关系除非用户明确要求。 3. 不新增依赖库不引入新设计模式不改动无关代码。 4. 不添加未经要求的注释、日志、文档字符串。 5. 代码风格严格遵循项目现有风格不引入个人偏好。 ## 任务执行流程 - 动手修改前先用2-3句话复述你的修改计划。 - 若任务涉及的业务逻辑不明确向用户确认后再动手不要自行脑补。 - 修改完成后列出你改了哪些文件、每处改动的理由。这套模板的核心逻辑是“防飘”角色定位防“好为人师”行为准绳防“超额完成”任务流程防“不懂装懂”。我最初写的规则文件很长有几十条结果AI在长对话里经常“捡了芝麻丢西瓜”。后来精简到这不到二十行反而效果好了很多。原因是AI对“短而强的禁令”记忆更深刻对“冗长的条款”容易在后半程失焦。2.3 规则书写的三个关键质量指标规则文件写了不等于能执行质量差的话写了跟没写差不多。我总结出三个判断标准第一规则要具体不要抽象。比如“遵循良好代码风格”是废话“函数长度不超过50行”“变量命名用英文名词短语”才有效。AI对具体数字和操作的理解远好于对形容词的理解。第二规则要可验证。每条规则都应该能在代码评审时被“对或错”地检查。比如“不新增依赖”是可验证的看package.json有没有变化“提高代码质量”是不可验证的无从检查。第三规则要有优先级。AI面对多条规则冲突时的处理逻辑是选权重最高的执行。所以那些你绝对不想被违反的比如“不改变函数签名”必须排前面而那些“期望项”比如“风格统一”可以排后面让AI在取舍时不至于因小失大。我见过最典型的反例是有人把“注释要清晰”写在了“不添加多余注释”前面结果AI开始给每一行代码都加注释活脱脱一场灾难。3. 提示词工程让每一次对话都“老实”3.1 结构化指令的“四件套”规则文件是“常设法律”但每次对话的提示词才是“个案执法”。两者缺一不可。规则文件管住了边界提示词管住了本次任务的具体目标。一个能有效防止“自作聪明”的提示词模板我称之为“四件套”【任务】只做哪一件事越具体越好 【范围】涉及哪些文件/函数/模块明确修改边界 【禁止】列出绝对不能做的事不要重构、不要加依赖、不要改签名 【验收】如何判断做对了测试通过、输出格式、原有行为不变举个例子。你让AI“帮我修个bug”它最容易飘。改成这样【任务】修复用户登录接口在密码错误时返回500的问题 【范围】只修改 auth/login.py 中的 verify_password 函数 【禁止】不得修改数据库模型、不得改动其余接口、不得添加新的异常捕获层 【验收】密码错误时返回401且不打印异常堆栈原有正确密码登录逻辑不受影响这个模板的精髓是把“目标”和“边界”同时交给AI让它既知道往哪走又知道哪里不能去。实测下来这种结构化指令比“帮我修一下登录报错”的成功率至少提高了一倍——不是说一次就能改对而是改出来的东西不会再额外毁掉一片。还有个容易被忽略的点一次对话只给一个任务。很多人习惯在一条消息里交代三件事“顺手把日志加上、再优化下查询”AI执行时往往会自行排序和加权最后哪件都没做对。宁可多发几次指令也不要让它自己排优先级。3.2 关键词和权威指令的实际效果对比“请”“麻烦”“我希望你”这类客气话在AI编程里一点用没有。真正有用的是“命令式边界式”的组合。我做了个简单对比列出来给你直观感受下模糊表达精确表达效果差异“优化一下这段代码”“仅优化时间复杂度不改变函数签名和返回结构”前者可能重写整个函数后者只动核心循环“帮我看看这个接口为什么慢”“定位本接口的慢查询只给出分析和最小修复方案不要改代码”前者直接动代码后者先解释清楚再等你拍板“加个缓存”“在get_detail函数内加一级本地缓存禁止引入Redis等外部依赖”前者可能给你整出个缓存框架后者一个dict就能解决“让代码更规范”“遵循项目现有PEP8风格不做结构性重构”前者可能改变缩进、注释、变量名后者只做格式层面微调我有个习惯在第一次下指令时直接声明“本次任务禁止做任何额外变更”。这句话的威力很大相当于给AI的“自由发挥”上了一道保险。等确认它理解了核心任务后再按需放开权限比如“现在可以帮我优化这块逻辑了但仅限于这个函数内部”。3.3 实操现场把“优化代码”改成有效指令光说模板容易显得空我拿一段真实代码改给你看。假设有这样一个函数def get_user_orders(user_id): orders db.query(SELECT * FROM orders WHERE user_id %s, user_id) result [] for order in orders: items db.query(SELECT * FROM order_items WHERE order_id %s, order.id) result.append({order: order, items: items}) return result老手一眼就看出这里有个N1查询问题。如果直接说“优化一下”AI很可能把整个函数改成JOIN查询再顺手加个数据模型类、改掉返回值格式。然后你下游所有调用方都要跟着改。我用“四件套”写一下【任务】消除get_user_orders的N1查询改为单次JOIN查询获取订单商品明细 【范围】仅修改该函数其他调用方接口无需变更 【禁止】不改变返回结构仍返回[{order, items}]不新增数据库模型类不修改order_items表结构 【验收】保持返回结构不变输出orders查询次数从N1变为1这样AI才会老老实实在同一个函数里做局部优化而不是借机把架构升级一遍。“最小变更”这四个字才是治“自作聪明”的灵丹妙药。4. 一套能落地的“治AI”工作流4.1 我在项目里实际用的“四阶段”流程规则文件和提示词都是基础能力但要让团队稳定复现“AI不飘”的效果还需要一套全流程的约束机制。我目前跑通了一套“四阶段”流程分享出来供你参考阶段一规则注入。每次开始AI辅助开发前确认规则文件已经放到项目根目录。如果仓库是新建的第一步就创建AGENTS.md而不是先写业务代码。阶段二任务拆解。把一个大需求拆成多个可独立验证的小任务分别发给AI。比如“先写数据库迁移脚本”“再写查询逻辑”“最后写路由”一次只让它做一个环节。拆得越细AI的“自由裁量权”越小产出越可控。阶段三最小变更评审。每次AI返回代码先不要急着测试先对照它改了哪些文件、哪些行。凡是超出任务范围的改动一律revert不让它“顺手”处理任何无关项。这一步是纪律问题不是技术问题。阶段四回归验证。所有AI生成代码必须跑完整的测试套件不只是“能跑通”还要确认原有功能行为没变。我见过太多“改了A坏了B”的情况——AI自己不会觉得有责任因为它只看到你让它改的那一小块。这套流程看着繁琐但实际跑起来比“让AI自由发挥再加班debug”要快得多。你省的不是写代码时间而是“踩坑改错返工”的时间。我团队里有个新人一开始嫌流程麻烦非要“让AI一步到位”结果一个功能写了三天其中两天在处理AI产生的副作用。后来老老实实按流程走半天就搞定了而且代码Review一次通过。4.2 免费AI工具的场景差异热门词里提到“免费的AI编程写代码”我也试过不少。免费工具和付费工具的能力差距主要体现在上下文长度和复杂任务处理上但“自作聪明”这个毛病是共通的。免费AI因为模型参数规模较小理解复杂指令的能力会弱一些更容易出现“只看到关键词就自行发挥”的情况。针对免费工具我有三个实用技巧第一提示词要更短、更明确。免费模型对复杂长句的理解更吃力所以把“四件套”压缩成“任务一句话禁止一句话”更有效。比如“改这个函数的返回字段为created_at不要动其他逻辑”。第二分步交流更可靠。付费工具能一次性处理大块上下文免费工具更适合“一问一答式”。让它先读代码、再给方案、确认后再改代码每一步都先确认再继续能大幅降低出错率。第三不要让它写“完全陌生领域”的代码。免费AI在你熟悉的框架里表现尚可一旦涉及生僻库、内部SDK它就开始瞎编API。这种情况下必须要它“先在代码库里找到相关用法再仿写”同时明确禁止编造不存在的接口。免费不等于不行但它更需要你用强约束去“圈养”。4.3 规则从哪来、怎么迭代规则文件不是一次性写完就一劳永逸的。它的内容来源主要有三个渠道一是踩坑沉淀。每次AI“自作聪明”闯了祸把这个场景归纳成一条规则写进规则文件。比如“不要在controller层做业务逻辑处理”可能就是某次AI把service层逻辑塞进controller后你总结出的防再犯条款。二是Code Review反馈。团队Review时反复出现的AI改动类型比如“爱改命名风格”“爱抽公共函数”直接固化成规则。规则的价值不在于一遍遍口头教育AI而在于让它从源头不产出此类行为。三是工具更新跟踪。AI编程工具迭代很快规则文件的加载机制、优先级处理逻辑都可能变。建议每季度检查一下规则文件是否还生效、有没有被新版机制忽略。规则文件也会“劣化”条文太多会让AI无所适从条文太少又管不住。我的建议是控制在10-20条核心规则每条都是被实际事件验证过的而不是拍脑袋写出来的。5. 常见问题与排查技巧实录5.1 典型问题速查表我把这半年多来遇到的高频问题整理成一张表方便你照着排查现象根因对策规则文件写了AI还是乱来规则太长/太抽象AI抓不住重点精简到15条以内每条用“禁止/必须”式句式AI在对话中途“忘了”你的限制上下文太长初始约束被稀释在关键节点重新重申约束用“你仍然要遵守X限制”句式让AI分析代码它直接动手改提示词里没写“只分析不改”显式声明“当前任务仅分析和回答禁止修改任何代码”AI引入了项目里不存在的依赖训练数据里的“常见模式”自带依赖规则里写明“禁止新增依赖”并在提示词中列出已有依赖清单AI改了不相关文件的代码没有划定文件作用域提示词里写“只允许修改以下文件xxx其他文件一律不动”AI生成代码和项目风格不一致规则文件没要求“模仿现有代码风格”规则里加一条先阅读同目录文件的风格再动手这些问题的共性都是“约束不足”。你每一次“随口说说”的指令在AI那里都会被放大成“尽可能多做”。5.2 我的独家避坑笔记按我的习惯最后再分享几条实际踩坑后悟出来的原则不一定在所有场景都对但至少在我接触的项目里是有效的。第一条永远不要对AI说“这段代码很烂帮我改好”。这种带情绪的表达会让AI觉得你有较高容忍度于是大胆发挥。换成“列出这段代码的具体缺陷和修改范围不要动手改”它反而会老老实实给你列要点。第二条如果你的项目工期很紧不要用AI改核心逻辑。不是AI能力不行而是它一旦产生“不能自测的改动”你根本没时间在deadline前排查。让它干点“脏活累活”——生成测试数据、写配置文件、做批量替换——这些场景即使出错也好发现好修正。第三条关键代码必须“人肉Review”。AI生成的代码不是不能改而是要把它当成“外包临时工的产出”看待可以复用架子、快速参考思路但涉及资金、安全、核心业务链路的部分必须人工逐行确认。这不是不信任AI这是工程责任感。第四条不要和AI争论。某些情况下你指出它改错了它会立刻道歉然后反向修改但可能把本来就对的也改错了。与其来回拉扯不如直接revert重新用更精确的指令再来一轮。AI没有“记忆教训”的能力反复拉锯纯属浪费你的时间。我个人的体会是AI写代码的“自作聪明”和人的“初生牛犊不怕虎”其实很像——它本质上是能力与约束不匹配时的自然产物。你不可能靠“求它听话”解决问题唯一有效的方式是把边界和规则焊死在每一个环节里。工具会继续变聪明但如果你不建立管理它的方法论AI越聪明你收拾的烂摊子就越多。如果你目前也困在“AI写代码一时爽改bug火葬场”的循环里建议你从今天开始做两件事给项目写一份AGENTS.md规则文件坚持用“四件套”结构下发指令。坚持一个礼拜你大概率能体会到什么叫“省心”。后续如果你想深入玩转规则文件和提示词我可以再拆几个具体项目的实战案例包括Web后端、数据处理脚本和前端页面的不同约束策略。
用规则设定与提示词工程治住AI写代码的“自作聪明”
我做了快十年后端这两年用AI写代码的时间比手写多。但有个事始终让我头疼这玩意儿太爱“自作聪明”。你让它改一个变量名它顺带把你整个函数重写了你问它一个bug可能出在哪它直接给你开新分支改完代码还觉得自己干得漂亮。GitHub上的issue里全是这种吐槽有人说“AI写代码就像刚入职的程序员——热情洋溢但总在事后让你收拾烂摊子。”这篇文章想聊的就是我摸索了小半年、结合团队实践整理出来的一套“治AI”方法论。核心是三件事规则设定、提示词工程、工作流约束。适合被AI“坑”过的开发者也适合刚接触AI编程、不想让它一开始就“放飞自我”的新手。读完你会知道大部分“自作聪明”其实是可被提前扼杀的而你要做的不是换工具而是换用法。1. “自作聪明”到底是怎么发生的1.1 一次让我血压升高的“优化”先说我真实的翻车现场。那段代码是个运营后台的订单导出接口逻辑不复杂无非是拉数据、填表、处理一下边界值。我让AI“优化一下导出性能”它给的结果是把同步导出改成了异步任务、引入了消息队列的封装、增加了一层缓存抽象、还主动加了个“重试机制”。听着是不是很“专业”但我们的业务根本没队列基础设施那套代码落不了地等于白写。这还不是最气的。后来我在Code Review里看到同事的AI生成代码明明只让修一个空指针异常AI把整个类的构造函数都改了连带着把另一个模块的依赖关系全打乱了。这种“超额完成”在AI编程里太普遍了普遍到大家已经默认“AI嘛给个方向就行细节别太指望。”但我后来想通了——问题的根子不在AI身上在我自己身上。因为我给的指令是“优化一下”这种指令在计算机眼里就是“你可以自由发挥”。它当然会按训练时数据里那种“最优解模板”来干活而这个模板往往就是过度设计。简而言之你不画边界它就默认没有边界。1.2 根因拆解不是AI坏是约束不够要治“自作聪明”先得理解它的决策机制。AI编程工具本质是一个基于大语言模型LLM的代码补全器它的输出是“基于你给的上文预测最可能的后续代码”。它的目标是高概率匹配训练数据里的常见模式而不是精确执行你的意图。这就造成几个典型问题它见过的代码质量差异巨大。训练数据里有大量“被人诟病”的过度设计代码在“优化”类提示下它会把那些“看起来更高级”的模式当作优选。它的理解偏向“最大化满意度”。你用模糊词“优化”“改进”“更好”时它会倾向于做更多事来增加“帮助感”。它缺少对项目上下文的判断力。在不清楚业务规模时引入消息队列、缓存、设计模式是它在“无信息环境”下的默认选择。我打个比方你雇了一个能力很强的实习生你跟他说“帮我把办公室收拾一下”他给你把办公桌布局都改了、文件重新归类了看起来更整洁了但你要找的东西找不到了。问题不是实习生笨是你给的指令边界太宽。AI写代码就是这样——你不说“只允许做X不允许做Y”它就把X、Y、Z全做了。1.3 “靠人品”不如“靠规则”很多人对付AI“自作聪明”的办法是碰运气“这次说得清楚一点应该就行吧。”但实测下来单次沟通的约束力很差因为AI会随着对话增长逐渐“遗忘”你前面的要求尤其是当上下文超过它的注意力窗口时最早的限制条件会被淡忘。所以真正有效的思路是把“规则”从对话里抽出来变成常驻的、每次对话开始时AI都会先加载的东西。这就是“规则设定”在做的事。它解决的问题是不是每次对话都存在一次性的提醒而是让AI在“进入项目的那一刻”就知道——这个项目的代码风格是什么、哪些事绝对不能干、完成任务的验收标准是什么。我团队里现在所有AI辅助编程的仓库都强制带一个规则文件没有这个文件AI一律只做“只读问答”不做任何修改。这不是矫枉过正这是从血泪教训里总结出来的制度。2. 用规则文件给AI立“职业底线”2.1 选对规则载体AGENTS.md、CLAUDE.md还是项目配置市面上主流AI编程工具的规则承载方式各不一样但万变不离其宗。现在最常见的几个载体AGENTS.md越来越多工具默认读取的通用规则文件放在项目根目录CLAUDE.mdClaude相关工具的专用规则文件.cursorrulesCursor早前版本的方式现在部分迁移到.cursor/rules/目录copilot-instructions.mdGitHub Copilot目前支持的仓库级指令文件需在.github目录下不要纠结选哪个你项目用哪个工具为主就配哪个。如果团队里工具混用最省事的方法是把同一份规则内容同时写到AGENTS.md和CLAUDE.md二者不冲突。现在的AI工具兼容性比前两年好识别到哪个文件就加载哪个规则。有个细节值得注意规则文件放根目录还是子目录影响的是AI的“作用范围”。根目录的规则对所有文件都生效子目录的规则只在相关路径下生效。我个人建议核心团队规范放根目录模块级特殊约束放子目录避免根目录规则过于臃肿。2.2 规则文件内容怎么组织拿来即用的模板规则文件不是越长越好太长了AI反而会抓不住重点。我实践下来最有效的结构是“三段式”角色定位、行为准绳、验收标准。下面是一份我目前实测效果很好的模板你可以直接复制修改# 项目开发规则 ## 角色与定位 你是一名严格服从的资深工程师首要目标是按用户指令最小化变更 而不是追求“更优设计”。用户没有要求的改动一律视为多余改动。 ## 行为准则按优先级从高到低 1. 只做被明确要求的修改不做额外优化、重构、格式化。 2. 不改变函数签名、类结构、依赖关系除非用户明确要求。 3. 不新增依赖库不引入新设计模式不改动无关代码。 4. 不添加未经要求的注释、日志、文档字符串。 5. 代码风格严格遵循项目现有风格不引入个人偏好。 ## 任务执行流程 - 动手修改前先用2-3句话复述你的修改计划。 - 若任务涉及的业务逻辑不明确向用户确认后再动手不要自行脑补。 - 修改完成后列出你改了哪些文件、每处改动的理由。这套模板的核心逻辑是“防飘”角色定位防“好为人师”行为准绳防“超额完成”任务流程防“不懂装懂”。我最初写的规则文件很长有几十条结果AI在长对话里经常“捡了芝麻丢西瓜”。后来精简到这不到二十行反而效果好了很多。原因是AI对“短而强的禁令”记忆更深刻对“冗长的条款”容易在后半程失焦。2.3 规则书写的三个关键质量指标规则文件写了不等于能执行质量差的话写了跟没写差不多。我总结出三个判断标准第一规则要具体不要抽象。比如“遵循良好代码风格”是废话“函数长度不超过50行”“变量命名用英文名词短语”才有效。AI对具体数字和操作的理解远好于对形容词的理解。第二规则要可验证。每条规则都应该能在代码评审时被“对或错”地检查。比如“不新增依赖”是可验证的看package.json有没有变化“提高代码质量”是不可验证的无从检查。第三规则要有优先级。AI面对多条规则冲突时的处理逻辑是选权重最高的执行。所以那些你绝对不想被违反的比如“不改变函数签名”必须排前面而那些“期望项”比如“风格统一”可以排后面让AI在取舍时不至于因小失大。我见过最典型的反例是有人把“注释要清晰”写在了“不添加多余注释”前面结果AI开始给每一行代码都加注释活脱脱一场灾难。3. 提示词工程让每一次对话都“老实”3.1 结构化指令的“四件套”规则文件是“常设法律”但每次对话的提示词才是“个案执法”。两者缺一不可。规则文件管住了边界提示词管住了本次任务的具体目标。一个能有效防止“自作聪明”的提示词模板我称之为“四件套”【任务】只做哪一件事越具体越好 【范围】涉及哪些文件/函数/模块明确修改边界 【禁止】列出绝对不能做的事不要重构、不要加依赖、不要改签名 【验收】如何判断做对了测试通过、输出格式、原有行为不变举个例子。你让AI“帮我修个bug”它最容易飘。改成这样【任务】修复用户登录接口在密码错误时返回500的问题 【范围】只修改 auth/login.py 中的 verify_password 函数 【禁止】不得修改数据库模型、不得改动其余接口、不得添加新的异常捕获层 【验收】密码错误时返回401且不打印异常堆栈原有正确密码登录逻辑不受影响这个模板的精髓是把“目标”和“边界”同时交给AI让它既知道往哪走又知道哪里不能去。实测下来这种结构化指令比“帮我修一下登录报错”的成功率至少提高了一倍——不是说一次就能改对而是改出来的东西不会再额外毁掉一片。还有个容易被忽略的点一次对话只给一个任务。很多人习惯在一条消息里交代三件事“顺手把日志加上、再优化下查询”AI执行时往往会自行排序和加权最后哪件都没做对。宁可多发几次指令也不要让它自己排优先级。3.2 关键词和权威指令的实际效果对比“请”“麻烦”“我希望你”这类客气话在AI编程里一点用没有。真正有用的是“命令式边界式”的组合。我做了个简单对比列出来给你直观感受下模糊表达精确表达效果差异“优化一下这段代码”“仅优化时间复杂度不改变函数签名和返回结构”前者可能重写整个函数后者只动核心循环“帮我看看这个接口为什么慢”“定位本接口的慢查询只给出分析和最小修复方案不要改代码”前者直接动代码后者先解释清楚再等你拍板“加个缓存”“在get_detail函数内加一级本地缓存禁止引入Redis等外部依赖”前者可能给你整出个缓存框架后者一个dict就能解决“让代码更规范”“遵循项目现有PEP8风格不做结构性重构”前者可能改变缩进、注释、变量名后者只做格式层面微调我有个习惯在第一次下指令时直接声明“本次任务禁止做任何额外变更”。这句话的威力很大相当于给AI的“自由发挥”上了一道保险。等确认它理解了核心任务后再按需放开权限比如“现在可以帮我优化这块逻辑了但仅限于这个函数内部”。3.3 实操现场把“优化代码”改成有效指令光说模板容易显得空我拿一段真实代码改给你看。假设有这样一个函数def get_user_orders(user_id): orders db.query(SELECT * FROM orders WHERE user_id %s, user_id) result [] for order in orders: items db.query(SELECT * FROM order_items WHERE order_id %s, order.id) result.append({order: order, items: items}) return result老手一眼就看出这里有个N1查询问题。如果直接说“优化一下”AI很可能把整个函数改成JOIN查询再顺手加个数据模型类、改掉返回值格式。然后你下游所有调用方都要跟着改。我用“四件套”写一下【任务】消除get_user_orders的N1查询改为单次JOIN查询获取订单商品明细 【范围】仅修改该函数其他调用方接口无需变更 【禁止】不改变返回结构仍返回[{order, items}]不新增数据库模型类不修改order_items表结构 【验收】保持返回结构不变输出orders查询次数从N1变为1这样AI才会老老实实在同一个函数里做局部优化而不是借机把架构升级一遍。“最小变更”这四个字才是治“自作聪明”的灵丹妙药。4. 一套能落地的“治AI”工作流4.1 我在项目里实际用的“四阶段”流程规则文件和提示词都是基础能力但要让团队稳定复现“AI不飘”的效果还需要一套全流程的约束机制。我目前跑通了一套“四阶段”流程分享出来供你参考阶段一规则注入。每次开始AI辅助开发前确认规则文件已经放到项目根目录。如果仓库是新建的第一步就创建AGENTS.md而不是先写业务代码。阶段二任务拆解。把一个大需求拆成多个可独立验证的小任务分别发给AI。比如“先写数据库迁移脚本”“再写查询逻辑”“最后写路由”一次只让它做一个环节。拆得越细AI的“自由裁量权”越小产出越可控。阶段三最小变更评审。每次AI返回代码先不要急着测试先对照它改了哪些文件、哪些行。凡是超出任务范围的改动一律revert不让它“顺手”处理任何无关项。这一步是纪律问题不是技术问题。阶段四回归验证。所有AI生成代码必须跑完整的测试套件不只是“能跑通”还要确认原有功能行为没变。我见过太多“改了A坏了B”的情况——AI自己不会觉得有责任因为它只看到你让它改的那一小块。这套流程看着繁琐但实际跑起来比“让AI自由发挥再加班debug”要快得多。你省的不是写代码时间而是“踩坑改错返工”的时间。我团队里有个新人一开始嫌流程麻烦非要“让AI一步到位”结果一个功能写了三天其中两天在处理AI产生的副作用。后来老老实实按流程走半天就搞定了而且代码Review一次通过。4.2 免费AI工具的场景差异热门词里提到“免费的AI编程写代码”我也试过不少。免费工具和付费工具的能力差距主要体现在上下文长度和复杂任务处理上但“自作聪明”这个毛病是共通的。免费AI因为模型参数规模较小理解复杂指令的能力会弱一些更容易出现“只看到关键词就自行发挥”的情况。针对免费工具我有三个实用技巧第一提示词要更短、更明确。免费模型对复杂长句的理解更吃力所以把“四件套”压缩成“任务一句话禁止一句话”更有效。比如“改这个函数的返回字段为created_at不要动其他逻辑”。第二分步交流更可靠。付费工具能一次性处理大块上下文免费工具更适合“一问一答式”。让它先读代码、再给方案、确认后再改代码每一步都先确认再继续能大幅降低出错率。第三不要让它写“完全陌生领域”的代码。免费AI在你熟悉的框架里表现尚可一旦涉及生僻库、内部SDK它就开始瞎编API。这种情况下必须要它“先在代码库里找到相关用法再仿写”同时明确禁止编造不存在的接口。免费不等于不行但它更需要你用强约束去“圈养”。4.3 规则从哪来、怎么迭代规则文件不是一次性写完就一劳永逸的。它的内容来源主要有三个渠道一是踩坑沉淀。每次AI“自作聪明”闯了祸把这个场景归纳成一条规则写进规则文件。比如“不要在controller层做业务逻辑处理”可能就是某次AI把service层逻辑塞进controller后你总结出的防再犯条款。二是Code Review反馈。团队Review时反复出现的AI改动类型比如“爱改命名风格”“爱抽公共函数”直接固化成规则。规则的价值不在于一遍遍口头教育AI而在于让它从源头不产出此类行为。三是工具更新跟踪。AI编程工具迭代很快规则文件的加载机制、优先级处理逻辑都可能变。建议每季度检查一下规则文件是否还生效、有没有被新版机制忽略。规则文件也会“劣化”条文太多会让AI无所适从条文太少又管不住。我的建议是控制在10-20条核心规则每条都是被实际事件验证过的而不是拍脑袋写出来的。5. 常见问题与排查技巧实录5.1 典型问题速查表我把这半年多来遇到的高频问题整理成一张表方便你照着排查现象根因对策规则文件写了AI还是乱来规则太长/太抽象AI抓不住重点精简到15条以内每条用“禁止/必须”式句式AI在对话中途“忘了”你的限制上下文太长初始约束被稀释在关键节点重新重申约束用“你仍然要遵守X限制”句式让AI分析代码它直接动手改提示词里没写“只分析不改”显式声明“当前任务仅分析和回答禁止修改任何代码”AI引入了项目里不存在的依赖训练数据里的“常见模式”自带依赖规则里写明“禁止新增依赖”并在提示词中列出已有依赖清单AI改了不相关文件的代码没有划定文件作用域提示词里写“只允许修改以下文件xxx其他文件一律不动”AI生成代码和项目风格不一致规则文件没要求“模仿现有代码风格”规则里加一条先阅读同目录文件的风格再动手这些问题的共性都是“约束不足”。你每一次“随口说说”的指令在AI那里都会被放大成“尽可能多做”。5.2 我的独家避坑笔记按我的习惯最后再分享几条实际踩坑后悟出来的原则不一定在所有场景都对但至少在我接触的项目里是有效的。第一条永远不要对AI说“这段代码很烂帮我改好”。这种带情绪的表达会让AI觉得你有较高容忍度于是大胆发挥。换成“列出这段代码的具体缺陷和修改范围不要动手改”它反而会老老实实给你列要点。第二条如果你的项目工期很紧不要用AI改核心逻辑。不是AI能力不行而是它一旦产生“不能自测的改动”你根本没时间在deadline前排查。让它干点“脏活累活”——生成测试数据、写配置文件、做批量替换——这些场景即使出错也好发现好修正。第三条关键代码必须“人肉Review”。AI生成的代码不是不能改而是要把它当成“外包临时工的产出”看待可以复用架子、快速参考思路但涉及资金、安全、核心业务链路的部分必须人工逐行确认。这不是不信任AI这是工程责任感。第四条不要和AI争论。某些情况下你指出它改错了它会立刻道歉然后反向修改但可能把本来就对的也改错了。与其来回拉扯不如直接revert重新用更精确的指令再来一轮。AI没有“记忆教训”的能力反复拉锯纯属浪费你的时间。我个人的体会是AI写代码的“自作聪明”和人的“初生牛犊不怕虎”其实很像——它本质上是能力与约束不匹配时的自然产物。你不可能靠“求它听话”解决问题唯一有效的方式是把边界和规则焊死在每一个环节里。工具会继续变聪明但如果你不建立管理它的方法论AI越聪明你收拾的烂摊子就越多。如果你目前也困在“AI写代码一时爽改bug火葬场”的循环里建议你从今天开始做两件事给项目写一份AGENTS.md规则文件坚持用“四件套”结构下发指令。坚持一个礼拜你大概率能体会到什么叫“省心”。后续如果你想深入玩转规则文件和提示词我可以再拆几个具体项目的实战案例包括Web后端、数据处理脚本和前端页面的不同约束策略。