第一条军规 先读懂代码库再动手

模型写出烂代码, 最大原因是, 它根本没读你的代码库, 就开始动手。2026年1月, 开发者Chang在X上吐槽, AI写代码反复踩坑, 第二天, 他就把这四类问题提炼成65行文本的仓库, 三个月破10万星。可真正在用的内部版本, 第一条要求是，AI先去看要改的文件, 把已有模式照搬过来, 弄明白项目实际依赖什么, 而不是凭空去猜, 用axios, 当所有人都在用fetch。

他列举了一个极为精准的例子 , 那就是「添加认证」实际上是五件各不相同的事情 , 要把它们罗列出来 , 并且说明其中的取舍。要是真的弄不明白 , 那就停下来去询问 , 而并非用一段看上去好像有那么回事 , 但实际上一运行就会崩溃的代码去敷衍。这一步骤节省了团队每周至少10小时的返工时间 , 缘故是大部分错误都源自模型不了解项目上下文。

第二条军规 写最少的代码解决眼前问题

编写能使当下问题得以解决的最少数量代码, 而非能对所有未来版本予以解决的最少代码。测试的标准极为简单: 如果某一事务被抽象出来的仅有缘由便是“以防有意外情况”, 那么你便进行了过度构建。2026年3月, Code团队经统计发觉, 因过度工程化致使出现的数据膨胀, 在所有漏洞中占比达35%。

不让触碰的就别去触碰, 要与已有的代码风格相匹配, 不要随意顺手去重新排列格式。用一个格式化器运行一遍, 会将真正关键重要的三行改动掩埋在三百行没有关联的变更之中。进行判断的标准非常直接: 你能够为每一行改动找寻到和用户需求的直接联系关联吗。要是不能, 那么这行代码就不应该出现。

第三条军规 用测试锁定每次修复

你认为, 具备可运行能力的代码与切实可成功运行的代码之间, 存在着一道名为「测试」的巨大差距。在修复程序漏洞时, 不要一开始就着手修改代码。首先要将此漏洞「记录」下来, 编写一个能够使其稳定重现的测试用例。修复完毕后运行一次, 只有测试通过了, 才算是真正完成了修复, 而并非是自认为修好了便是修好的情况。

要是存在某样东西, 你无论如何也没有办法去加以测试, 那就千万别偷懒而选择跳过, 那并非是测试方面所存在的问题, 而是代码自身在设计的过程当中是存在着问题的。Code团队于内部进行统计的时候发现, 跳过测试部分直接去修改代码的那种修复操作, 会有百分之四十在两周之内引发崭新的bug。这样的一条规则把修复的准确率从百分之六十提升到了百分之九十二。

第四条军规 先说清楚做完了长什么样

开展写代码的操作之前, 要将「做完了」呈现出的样子精准表述清楚, 并且必须是能够进行验证的, 绝不是简单的一句「搞定就行」。比如说, 老板下达指令「加个验证」, 这样的话语太过模糊, AI听闻之后会自行随意发挥。你需要进行翻译, 具体为: 「用户邮箱处于未填写或者填写错误的状况, 要弹出清晰明确的报错提示, 而且这两种情形都得经过测试过才行。」。

要是活儿分成好几步, 那就先把计划给列出来, 别让AI闷头干上一小时, 等你回来一看方向却是不对的了。在2026年4月的一次内部测试当中, 显示出没有计划直接开工的任务, 返工率高达70%；而那种先写计划再去执行的任务, 一次通过率超过85%。

第五条军规 读完整报错再动手改

要先去读完整的报错以及堆栈跟踪, 接着复现问题之后再着手去改, 而且一次就只改一个所处位置。好多AI在看到报错第一行的时候就急忙着手改代码, 然而改了好长一段时间之后却发现根本就不是那方面的问题。Code团队经过统计得出发现, 百分之八十的无效修复均是源于没有彻底理解报错信息。

增添新依赖之前先询问, 标准库可不可以解决。添加之后就要讲明白所以然, 使得选择能够看见, 而并非偷偷放进package.json。对于不确定的情况要精准表述, 像是「我不清楚这个库是不是支持流式传输」称作良好的沟通。含混的表达会致使AI进行猜测, 而猜测通常就是bug的源头。

第六条军规 学会识别翻车信号及时停手

当发觉自身正处于犯下这类错误之际, 恰当的举措是即刻收手, 而非不顾后果地一味坚持到底。这听闻起来较为简易, 然而却是内部版本最为关键的差别所在。以社区版本而言, 仅仅告知人工智能怎样精心编写代码, 而内部版本除此之外, 还会告知它怎么去辨别自身正在编写质量欠佳的代码。

用5周的内部实战, 将此前社区版最大的空白给补全了。他不但告知AI怎样去写代码, 还告知它怎样去检查自身, 怎样去调试, 怎样去沟通, 怎样去识别自身正处于翻车状态。这才是内部版真正令人觉得可怕的地方: 它把AI从一个“听话然而莽撞的码农”, 转变成了一个“具备自检能力的工程搭档”。

第七条军规 用循环工程替代单次对话

Code的创建者Boris, 于2026年6月讲了一句令全网寂静的话语: 「我不会再给AI撰写提示词了。」这套全新玩法拥有了正规名称——循环工程。在提示词工程、上下文工程之后, AI领域的第三次范式转变就这样悄然开启了。它是一个小型系统, 为你一次又一次地给AI安排任务、进行验收、纠正错误, 直至一件事情完全完成。

没给自己打分的是写代码的, 专门负责检查「是否达成目标」的是另一个模型。Code已将此能力做成两条命令: /goal是「持续做到完成」, /loop是「依节奏定期检查」。Boris自身更极端, 他使好几个Agent在后台一直运转，一个找寻架构能优化之处, 一个找寻可合并的重复代码。

第八条军规 把教训写进配置让修正传播

犯了那种重复出现的错误之后, 他要求自己把从中得到的教训写进.md里, 如此一来, 相应的修正就能传播到未来的每次运行当中。而那一份十条军规, 从本质上来说, 就是给循环工程提供“自检标准”的。要是没有这份纪律文件, 即便Loop运行得再快, 那也仅仅只是一台会快速生产bug的机器罢了。

在2026年5月的时候, Code团队于内部所做的统计表明, 每当把教训写入配置完成之后, 同类错误的复发概率下降了80%。这个文件好似针对AI的“学习日志”, 犯下一次错误，便增添一条规则, 致使整个系统不断地进化。从4条增长到10条, 并非单纯地增添规则, 而是把纪律由外部的约束转变成为了内生的能力。

第九条军规 纪律和自动化是同一枚硬币

同一个方向被三次跃迁所指向: 人类正从作为一句一句跟AI对话的“操作员”, 转变为定好目标、搭好系统且放手让AI自行运作的“设计者”。泄露的那份内部.md以及Boris口中的循环工程, 看似是两件不同之事, 实则是同一枚硬币的两面: 一面刻画着纪律, 一面刻画着自动化。

纪律告知AI怎样去检查自身, 自动化促使这套检查持续不断地运行起来。2026年6月, Boris于一次内部会议讲道: 「未来的开发者并非撰写代码之人, 而是撰写规则之人。」这份文本引发全网轰动的真正缘由就在于此——它并非仅是一份配置文件, 它乃是一个信号。

第十条军规 定义约束比使用AI更重要

若是AI聪明到了一定程度, 那么掌控它所用的办法, 相较于运用它的法子更为关键。而那个能够规定约束内容、架构系统、于更高层面操控AI的人, 才是下一个时代真正极为稀缺的资源。从提示词工程转变到上下文工程, 再到循环工程, 每一回进阶都使得人类距离「操作员」角色愈发遥远, 距离「设计者」角色愈发接近。

2026年6月29日, 这份内部配置被泄露, 此泄露致使整个开发者社区有所察觉, 即AI并非是需要更多指令的那种情况, 而是需要更好的纪律。你是否已然准备好, 从给AI撰写提示词这个行为, 升级转变到给AI设计自检系统呢? 要是你感觉到了其有用性, 那就点个赞并分享出去, 以此使得更多人能够看到这份改变游戏规则的十条军规。