AI写代码总胡乱优化？19条开发家规管住过度发挥

P.S. 目前国内还是很缺AI人才的，希望更多人能真正加入到AI行业，共同促进行业进步，增强我国的AI竞争力。想要系统学习AI知识的朋友可以看看我精心打磨的教程 http://blog.csdn.net/jiangjunshow，教程通俗易懂，高中生都能看懂，还有各种段子风趣幽默，从深度学习基础原理到各领域实战应用都有讲解，我22年的AI积累全在里面了。注意，教程仅限真正想入门AI的朋友，否则看看零散的博文就够了。

前言

最近用Codex写代码，我逐渐发现一个真相：AI不是不会写，它是太会写了。

你让它改一个接口字段，它开始写兼容逻辑，兼容到后面字段名都快能凑一副扑克牌。你让它修个按钮文案，它顺手重构了半个组件，还贴心地告诉你：“这样更具可维护性。”

这种感觉就像你请朋友来家里换个灯泡，他看了看天花板说：“你这个房子的采光系统有问题，我给你重新设计一下电路。”

谢谢，但我只是想让灯亮。

一、AI的热心事故：它比丈母娘还爱操心

AI开发里有个经典毛病：补过头。人类工程师写代码时，心里装着项目上下文、团队约定、业务边界，以及一点点来自线上事故的心理阴影。AI不一样，它擅长把"不确定"补成"看起来合理"。

1. 过度兼容：代码开始像在相亲

接口文档明明写的是title，AI觉得后端也许会返回name，历史数据也许会有label，保险一点再兼容displayName。

于是代码变成：

consttitle=item.title||item.name||item.label||item.displayName

看起来很稳，实际上很危险。因为它把一个明确的接口契约，变成了一场字段猜谜游戏。今天兼容四个字段，明天再来一个text，后天补一个caption，最后谁也不知道真实数据到底应该长什么样。

代码开始像在相亲：谁来都能接一下。

2. 过度重构：修个bug，顺便翻新半栋楼

你只想让它修一个bug，它觉得附近代码不够优雅。“这个函数可以抽一下。”“这个组件可以拆一下。”"这个命名可以统一一下。"如果是在学习项目里，这可能还挺开心。但在真实业务里，这种"顺手优化"经常变成范围失控。

一个小改动突然牵扯多个文件，原本只需要验证一个按钮，现在要确认半个页面有没有回归。AI倒是很积极，Code Review的人开始沉默，沉默到能听见键盘冒汗的声音。

3. 过度抽象：看到重复就想抽，最后没人敢动

AI看到重复代码，封装欲立刻拉满。两个地方都有状态判断？抽。两个组件class有点像？抽。两个类型字段差不多？合。但工程里的重复并不总是坏事。有些重复只是长得像，业务含义并不一样；有些代码现在重复，未来变化方向可能完全不同。

强行抽象之后，项目可能从"有一点重复"升级成"没人敢动"。就像你把家里所有钥匙都熔成一把万能钥匙，看起来很高效，直到有一天你想只开卧室门，结果整个房子的锁都跟着转。

4. 中文乱码：项目开始用另一种文明交流

中文项目还有个经典问题：编码。尤其在Windows环境里，如果读写文件时不确认UTF-8、GBK、ANSI，轻则中文变乱码，重则你打开文件那一刻，仿佛看见项目在用另一种文明和你交流。

还有些AI会把中文写成一串Unicode转义字符。这当然也许能运行，但人类读起来会很想下班，下班到想直接退休。

5. 缺少边界感：它不知道哪些东西不能碰

说到底，很多问题不是AI不懂代码，而是不知道边界。它不知道哪些文件不能动，哪些字段不能猜，哪些重复可以保留。它不知道这个项目现在需要的是"修复"，不是"翻新"。

于是我开始给Codex准备一套开发规则。目标不是让AI变笨，而是让AI在写代码之前先明白一件事：不是所有能写的代码，都应该写。

二、治AI的三种老办法，都像在哄孩子

要解决AI过度发挥，常见办法有几种，但每种都有种"在跟三岁小孩讲道理"的无力感。

办法一：人工Code Review

这是最传统也最可靠的方式。问题是，AI写得太快了。它一分钟可以生成一大片代码，而人类要逐行确认：这个兼容有没有必要、这个抽象有没有收益、这个字段是不是瞎猜。久而久之，Code Review从"质量保障"变成"AI善后现场"，审代码审出了一种保洁阿姨的气质。

办法二：Prompt反复提醒

每次都说："只做最小改动。不要重构。不要猜接口字段。“这当然有用。但问题是，每次都要说。你忘说一次，AI立刻恢复出厂设置，重新变成那个看到代码就想顺手优化的热心同事。这就像你每天早上都要提醒室友"记得冲厕所”，有一天忘了，后果自负。

办法三：项目级规则文件

比如AGENTS.md、CLAUDE.md或者Codex skill。这种方式把团队约定固化下来，不是每次靠人提醒，而是让AI在工作时就能读到项目边界。它相当于给AI配了一份"入职手册"。
只不过这份手册的重点不是"欢迎加入团队"，而是：欢迎加入团队，先别乱动。

三、19条家规：让AI从戏精变员工

我把这套规则叫codex-dev-norms，核心就一条：把AI常见的失控点拆成明确边界。它不是"代码洁癖清单"，更像"防止AI过度热心说明书"。下面挑几条最扎心的说说。

家规1：你是来修bug的，不是来给项目重新投胎的

这条叫code-change-boundary，强调最小改动原则。AI很容易把"解决问题"理解成"顺便把附近看不顺眼的地方都整理一下"。但真实项目里，很多时候我们需要的是可控的小变更，而不是一次兴致勃勃的局部装修。
提醒Codex：你是来修这个bug的，不是来给项目重新投胎的。

家规2：别猜接口，按定义来

API字段必须严格来自真实定义。不要猜字段名，不要猜响应结构，不要加别名字段，不要写a || b || c这种自动兼容。如果字段不清楚，就去确认接口定义。
这正好命中AI的常见毛病：太喜欢替后端"考虑周全"。但业务代码里，接口契约不是开放式作文。后端返回什么，前端就按什么接。否则所谓兼容会慢慢变成技术债，最后谁也不知道哪个字段才是真的。

家规3：中文别乱码，项目不是考古现场

读写文件前确认编码，不要默认使用可能出问题的读取方式；中文要直接写中文，不要写Unicode escape。如果发现乱码或混合编码，要先处理编码问题。
毕竟中文乱码不是普通bug，它更像一种仪式。一旦触发，项目里所有汉字都会开始怀疑自己到底来自哪里。

家规4：业务逻辑不是贴纸，不能哪里空贴哪里

业务规则应该待在真正属于它的位置，不要散落在controller、service、job、mapper各处。AI容易哪里需要判断就在哪里补一段，哪里缺个转换就加一个helper。短期看问题解决了，长期看业务规则开始到处流浪。
以后要改一个状态判断，可能要在五个地方找它的分身。这就像你家的遥控器，客厅一个、卧室一个、厨房一个，最后想关电视得先打一圈电话确认位置。

家规5：小组件别写成小宇宙

可读性优先，不要为了优化引入复杂度。是否抽hook、utils，要看真实复杂度，而不是主观觉得"这样更优雅"。AI很擅长把简单事情做得很完整，一个本来只在当前组件里用一次的逻辑，它可能会抽成hook；一个简单formatter，它可能会塞进utils。
看起来很专业，但专业不等于复杂。尤其前端代码，很多时候"放在这里一眼看懂"，比"抽出去但你要点进去看"更好。就像你把牙膏挤到牙刷上，AI非要给你设计一个自动挤牙膏机械臂，还附赠使用说明书。

家规6：状态不是越全局越高级，放对地方才高级

区分组件状态、hook状态、store状态、URL query状态和server state。AI喜欢把状态放到"看起来更通用"的地方，本来只属于一个组件的展开状态被放进store，本来应该体现在URL上的筛选条件被藏在内部state。
最后状态之间互相看不顺眼，页面刷新、返回、切tab都可能出现奇怪行为。这就像你把内衣放进客厅展示柜，把奖杯塞进衣柜深处——不是不能放，是地方不对。

家规7：不是所有副作用都能靠缘分收场

事件监听、订阅、定时器、watcher等副作用，注册要清楚，清理要明确。AI写副作用代码时，很容易只关心"让它生效"，忘了"让它结束"。加了resize listener但没有清理，开了timer但卸载时不处理。
这种问题短期不一定明显，但跑久了就会变成难查的行为异常。就像你请了钟点工但忘了告诉她什么时候走，三个月后她还在你家厨房擦盘子，你也不敢问。

家规8：有业务含义的值，别让它在项目里自由奔跑

业务状态、事件名、缓存key、storage key、路由、API path等，如果代表共享业务含义，就应该有稳定来源。AI有时会随手写字符串：status === 'success'。
但如果项目里到处都是'success'、'SUCCESS'、'done'、'finished'，以后改业务状态时就会很热闹。热闹到像在开联合国大会，每个字段都说自己的语言。

家规9：类型相同不代表概念相同，别搞连坐制度

如果多个类型字段相同，并且业务含义、生命周期也相同，可以考虑统一；但如果只是结构长得像，不要强行合并。AI很容易看到两个interface字段一样，就觉得可以抽一个公共类型。
但前端表单类型、接口响应类型、数据库实体类型，可能字段一模一样，语义却完全不同。强行合并之后，一个地方变动，另一个地方被迫跟着变，最后类型系统从保护伞变成连坐制度。这就像因为你和你邻居都穿白T恤，就把你们户口合并成一个家庭。

家规10：允许合理的局部重复，抽象不是奖励机制

如果逻辑只出现一次，或者业务含义不同，或者未来变化方向不同，或者抽象会让代码更难懂，那就不该为了"消灭重复"而抽象。AI看到重复就想收敛，看到相似就想封装。
但抽象不是奖励机制，不是写得越多越高级。好的抽象应该降低理解成本，而不是把简单代码变成参数迷宫。就像看到两棵树长得像，非要把它们嫁接成一棵，最后结出的果子可能既不能当苹果也不能当梨。

家规11：UI别硬统一，不是每个长得像的东西都要认亲

相同按钮、输入框、卡片样式可以收敛到基础组件，但不是鼓励AI看到class重复就马上抽组件。UI里有些重复来自设计系统，有些重复来自局部业务场景。前者值得收敛，后者未必。
别让每个长得像的东西都拉去认亲。就像你看到你同事和你穿同款衬衫，你不会立刻去查DNA鉴定是不是失散兄弟。

家规12：能写三行解决的问题，不要召唤整个npm

不要为了简单功能引入新依赖，不要引入职责重复的第二个库，不要在窄任务里升级无关依赖。AI有时会很喜欢推荐库：格式化时间？加个库。深拷贝？加个库。简单校验？加个库。
但依赖不是免费的。它带来体积、维护、安全、升级和团队认知成本。这就像你家里缺个开瓶器，AI非要给你装一个智能厨房系统，还附带年度订阅费。

家规13：注释解释为什么，不是把代码朗读一遍

鼓励解释业务目的、分支原因、边界场景、状态流转。但反对显而易见的注释，也反对没有owner或移除条件的TODO。AI特别容易写这种注释：// 设置标题然后下一行是setTitle(title)。
这不是注释，这是把代码又朗读了一遍。好的注释应该告诉人类：为什么这里要这么做，而不是告诉人类：这行代码长什么样。否则注释就像电影旁白，把画面里正在发生的事又说了一遍。

家规14：不要测试mock本身，别自我感动

不要给薄包装写无意义测试，不要重复相同输入输出的测试，不要测试mock本身，不要为了覆盖率数字写测试。有价值的测试应该覆盖正常路径、边界值、空值、非法值、权限、状态转换、错误处理、回归场景等。
AI可以很快写出一堆测试，但数量不代表质量。如果测试只是证明mock会返回mock，那它更像是在给自己鼓掌。就像你对着镜子说"你真帅"，然后把这个过程录下来当成获奖感言。

家规15：错误不要被悄悄吞掉，人类至少要知道问题在哪

不要无声吞错，能明确失败就不要隐藏错误状态。处理错误要在真正能恢复的边界，转换或重新抛出错误时要保留有用上下文。日志要记录能帮助诊断真实问题的信息，不要给正常流程加一堆噪音。
出问题时，人类至少要知道问题在哪里，而不是只能看着控制台思考人生。思考人生是哲学家的事，程序员只想知道第几行报错。

家规16：命名稳定点，别随手起"helper"这种模糊名字

一个概念应该有一个稳定名字，不同名字应该意味着不同含义；优先使用领域术语，不要随手起helper、manager、common、base、util这种模糊名字。
也不要为了文件变小就拆文件，不要为了方便把无关职责塞进一个文件。AI很容易"整理结构"，但结构整理本身就是改动。这就像你为了衣柜整洁，把袜子塞进冰箱，把鸡蛋放进鞋柜——看起来分类了，实际上更乱了。

家规17：Review先找风险，不先夸优雅

Code Review优先关注错误行为、回归、边界条件、契约不匹配、缺失验证、不安全副作用、测试缺失等。避免AI review变成空泛评价：“整体结构清晰。”“代码可读性较好。”“建议进一步优化。”
这些话不是完全没用，但如果没有指出真实风险，就像开会时说"我们要持续改进"一样，听起来正确，落地困难。好的review应该先把可能出事故的地方指出来，而不是先给AI发一面"积极参与奖"。

家规18：交付时说人话，不要写过程汇报

完成任务后说清楚：改了什么，验证了什么，还有什么不确定，下一步是什么。AI很容易把最终回复写成过程汇报：“我首先分析了项目结构，然后检查了相关文件，接着进行了修改……”
用户真正关心的是结果。所以要求它开门见山：事情是否完成，完成到什么程度，有没有验证，哪里还需要注意。就像你去餐厅吃饭，服务员上来先说"我首先去厨房确认了食材，然后洗了手，接着打开了火"，你只想说：菜呢？

四、真正解决的不是代码问题，是边界问题

看完这些家规，你会发现codex-dev-norms真正解决的不是某一种具体bug。它解决的是AI开发里的边界问题。

AI很强，但它不知道你的项目里哪些东西不能碰。它不知道这个接口字段必须严格按定义来，它不知道这个重复现在不该抽象，它不知道这个状态只属于当前组件，它也不知道你今天只是想修一个按钮，而不是顺便参加一次架构改造。

所以这套skill的意义，就是把这些隐含经验变成显式规则。让Codex从"能写代码"，变成"能按项目边界写代码"。

五、让AI少一点自我发挥，多一点工程克制

AI写代码越来越强，这是事实。但在真实项目里，强不等于可以随便发挥。很多时候，我们需要的不是一个永远有新想法的AI，而是一个知道什么时候该停手的AI。

codex-dev-norms这类skill，就是给Codex准备的一套开发家规。它不会让AI失去能力，恰恰相反，它让AI的能力更可控、更稳定、更适合进入真实工程协作。

以前Codex像一个精力旺盛的搭子：你说一句，它能写一屏。现在有了这套规则，它还是能写一屏。但终于知道，哪半屏不该写。

这大概就是22年AI老兵能给新手的最好建议：不是让AI变聪明，而是让它学会克制。毕竟在这个行业里，知道什么不该做，比知道什么能做，要难得多。

P.S. 目前国内还是很缺AI人才的，希望更多人能真正加入到AI行业，共同促进行业进步，增强我国的AI竞争力。想要系统学习AI知识的朋友可以看看我精心打磨的教程 http://blog.csdn.net/jiangjunshow，教程通俗易懂，高中生都能看懂，还有各种段子风趣幽默，从深度学习基础原理到各领域实战应用都有讲解，我22年的AI积累全在里面了。注意，教程仅限真正想入门AI的朋友，否则看看零散的博文就够了。