2026 年 8 月初，dev.to 上有篇文章在圈内小范围传开。作者 Ashley Childress，标题大意是“我用 AI 重构了管理，九件我做得不一样的事”。文章本身是 AI 代笔的——她在文末自己承认，研究和策划是她做的，成文交给模型。这个坦白不是重点，重点是文章里一个数字：134。
134 条常设规则。这是她给 AI 累积下来的行为边界，其中一次快照里有 119 条包含明确的禁止词。她管这套东西叫权限模型，默认黑名单式——默认允许，按禁令排除，而不是白名单式逐项审批。
我想挖的不是“她用 AI 用得多溜”，是这 134 条规则怎么来的。因为顺着她的时间线看，这些规则没有一条是预先设计出来的，全部是事故的化石。
先说最典型的：git push
她的核心规则之一：除非用户在当前消息里明确要求，AI 不得执行 git push；一次 push 请求只授权一次推送，权限不永久持续。动机具体到近乎抠门——避免不必要的 GitHub Actions 流水线运行和费用。
这条规则的结构值得停下来多看一眼。它不是“AI 不该 push”，是“push 这个动词在对话里出现一次，只兑换一次执行权”。同一个人，同一个会话，下一分钟再要 push，得重新开口。类似的还有 commit：一次请求只允许执行一次带签名的提交，“commit”这个词不被当成持续授权。
这说明什么？说明她踩过坑。你不会凭空设计出“一次请求兑换一次执行”这种粒度的规则，只有被“我以为它懂了‘就提交这一次’结果它把后面三次也顺手提了”教育过的人，才会把授权粒度切到这个精度。规则是事故的负片。
再往下挖一层，这个粒度恰好是人和人之间管理授权的老问题。你跟一个新下属说“这个分支你来推”，没人会理解成“以后所有分支你随便推”。但跟模型说，它就这么理解了——因为对话里的授权语义，模型是靠模式匹配补全的，不是靠职场常识。所以她实际上是在给一个不懂潜规则的员工，把所有潜规则显式化成条文。这就是她说的“重新创造了管理”：她让五个系统——Codex、ChatGPT、Claude Code、Cowork、Gemini——分别跑同一个提示，问它们对她工作方式的观察，其中一个总结出来：她在用 AI 写代码、审查 AI 生成的代码、对照实时分支复核、测试修正、记录规则。这个循环里“记录规则”是闭环的那一环，也是最像管理的那一环。
管理者不审代码，审代码的是两个互相看不顺眼的 AI
她不再亲自审查大部分代码变更了。理由说得很难听：人工代码审查是浪费资源。替代方案是两个独立的强对抗 AI 审查——注意是两个，不是一个，而且是刻意的强对抗。
为什么是两个？她的解释是不同工具往往发现不同问题。Carbon Trace 项目里——就是那个拿了 WeCoded 2026 前端艺术挑战奖的项目——Codex 和 Claude 曾经为 frame 0 的初始化时序吵起来，最后 Codex 是对的，修复提交同时过了单元、浏览器、lint 和性能检查。
这一步是分水岭。单个 AI 审查的问题是它和写代码的 AI 共享同一套盲区——测试全绿也可能测错了层。她举的例子很扎心：复制截图功能在“dev 环境”失效，AI 先去修了剪贴板，因为她和 AI 都默认“dev”指本地开发服务器——实际上指 dev.to 站点。真正的修复在服务端，把 SVG 光栅化成 PNG。全绿的测试没撒谎，它只是基于和实现相同的错误假设。所以她要求 AI 提供超越“测试通过”的证明：查 fixtures、真实记录、契约、运行时输出、畸形输入。两个不同家族的模型互相挑刺，等于用异构性对冲同构的盲区——这个思路不新，航空软件的双通道异构冗余几十年前就在用，只是那时候两条通道是人写出来的两套独立实现，现在一条通道是模型 A，另一条是模型 B。
我承认我对“人彻底退出代码审查”这件事存疑。两个强对抗 AI 能抓住的错，和两个互相较劲的高级工程师能抓住的错，未必是同一种。但她的立场至少自洽：她退出的只是审查这一环，系统设计和最终结果验证还攥在手里。这和 4GL 时代“业务人员自己写应用”的剧本结构上不同——4GL 想砍掉的是“想清楚”那一步，她砍掉的只是“逐行看”那一步。上一篇我讲 4GL 那条路怎么死的时候说过，死因从来不是工具不行，是它承诺连想都省了。她没省。
重启而不是修复
她的另一条策略更狠：同一个问题跟模型说了三次还不对，就假定对话已被污染，直接开新聊天。扔掉一个两天前写的前端方案，比继续修补更快。
她的依据是模型换了代——GPT-5.6 和 Claude 5 时代，AI 不再需要 GPT-4 那种手把手的照料。这个判断我不完全同意，“三代模型”这种划法太整齐了，整齐得可疑。但“对话污染”这个观察本身是真金。上下文窗口里的错误假设不会自己消失，它会像滚雪球一样让后面每一次修正都背着前面的包袱。人在带新人的时候其实也懂这个道理——一个新人钻进牛角尖，最好的办法往往是给他换个任务，让他忘了那条歧路——只是人不好意思承认，因为“重启”听起来像放弃，而工程师文化里放弃是脏话。
她把它变成了纪律。这是把管理直觉翻译成操作规程的又一个例子。
没说出口的话，都不是一次性的
整个体系里我觉得最有意思的，是她让 AI 分析自己的聊天历史，从中挖出从未被记录的实践和失败模式。挖出来的东西很具体：某个技能文件曾因认证令牌过期而静默失败；AI 曾经擅自补了用户指定之外的标签。这些都不是她写规则时想到的，是回头翻记录翻出来的。她的原话大意是：她对 AI 说过的任何内容，都不是一次性的。
这句话有两种读法。乐观的读法：每句话都沉淀成了资产。悲观的读法：每句话都成了永久记录，而且她还需要让 AI 定期自我审计记忆文件，清除失效或矛盾的规则——因为规则会腐烂，134 条里必然有互相打架的，不清就会越积越死。
这就是我标题想说的那个点。管理理论里有一整套关于授权、关于规则何时显式化何时留白、关于制度成本的讨论，这些讨论她大概率没系统读过——她不是从理论出发的，她是一年多前开始认真用 AI、做了大量实验，然后被一个个具体事故逼着，把管理经验从零重新发明了一遍。134 条规则就是她重新发明管理学的过程记录。据传她最初的动力只是想证明 AI 比常见用法强大得多，管理是副产品。
副产品长成了主体。这条路在历史上出现过：Unix 那批人最初只是想要个好用的开发环境，操作系统是副产品；Git 最初只是 Torvalds 不想再用 BitKeeper，版本控制是副产品。区别在于 Unix 和 Git 的副产品有文档、有传抄、有一代人在上面继续垒，而她这 134 条规则目前只活在一个人的记忆文件里。
回到当下
所以回到今天大家吵的“AI 时代管理者该干什么”。她这份实践给了一个比大多数预测都具体的答案：管理者的核心产出在迁移——从“审别人的产出”迁移到“维护一套不断腐烂又不断生长的规则库”。审查可以外包给两个互相较劲的模型，但判断哪条规则过期了、哪次事故值得固化成禁令、什么时候该重启而不是修补，这些还是人在做。她的 AI 甚至会反过来告诉她“什么时候不行动”——这条消息已经说过一遍了，别发；这个仓库名会被误读，换一个——而她采纳了。反向管理出现了，但采纳与否的那一票，还在人手里。
这套东西能不能规模化，我不知道。134 条规则维护一个人的 AI 员工，十个人的团队是不是要一千三百条，规则之间的冲突会不会指数级爆炸——这是她那篇文章没回答的，也是我最想看下一篇文章回答的问题。但至少有一点可以下判断：她不是在“使用 AI 工具”，她真的在管理一个员工，付的是管理的全套成本——写规则、审绩效、处理越权、定期清理制度垃圾。工具没有这些成本，员工有。
她那篇文章是 AI 写的。她自己只做了研究和策划，还专门写了一组规则保护个人文风——禁止为了“可读性”把长句切碎，禁止创业公司落地页式的套话。你看，连“让 AI 替我写”这件事本身，最后也落到了一条条规则上。这个循环闭得很彻底，我一时说不好该佩服还是该后背发凉。