每个 AI 编程会话都结束于同一个尴尬的瞬间。代理宣布任务完成，测试全过，代码就绪。也许是真的。但说这话的代理，正是写下每一行代码、沿途做了一百个小判断、并且一个个把自己都说服了的那个。问它自己的活干得怎么样，多少有点像让学生批改自己的考卷。
2026 年 10 月 28 日，MiniMax 建了一个公开仓库 MCode Stack，第二天加上了 Claude Code 和 Codex 的安装入口。里面不是新模型，也不是提示词合集，而是开发 MiniMax Code 那个团队每天真实在用的工作习惯——技能、检查清单、工作流——以任何兼容代理都能直接加载的文件形式公开。其中最有意思的一件，正面回答了"自己批自己考卷"的问题。
干净上下文里的审查员
这个技能叫 independent-review，规则简单到近乎苛刻：审查员只看三样东西。代码改动（diff）。这次改动要满足的需求。以及真实的测试结果，包括失败的和跳过的。
就这些。审查员拿不到作者的对话记录、计划、中间推理和自我评价。技能文件里对为什么这样做的解释值得转述：继承了作者对话的审查员，容易顺着同样的推理走，漏掉同样的东西。所以审查员要回答的问题被刻意换了一个。不是"作者的逻辑成立吗"，而是"这个改动满足需求吗"。这是两个不同的问题，而只有不在写作现场的人，才能诚实地回答第二个。
这个技能的讲究不止于设置。它给审查员指了几类具体的坑：代码依赖但从未检查过的假设；diff 悄悄跳过的需求条目；通过了但并没有真正检验需求的测试——同一个代理写的测试，带着和作者一样的盲区；以及超出声明范围的行为变化。发现的每个问题都要按固定结构返回：位置、原因、外加 blocking、should-fix、nit 三档严重度；没有位置和原因的，按意见处理，不算缺陷。
然后是防止你反过来盲信审查员的最后一步：回到主会话后，不要整批照单全收。每一条先对着真实代码核实，最好用一个会失败的测试来确认，然后再改。被驳回的发现连同理由记下来，下次审查就不会再提一遍。
仓库里还有什么
仓库按团队成员的个人栈组织。主力是 MiniMax Code 研发负责人的 ronny 栈，按一天里的工作场景分组装了大约十五个技能。有判断一个任务到底该不该交给子代理的检查清单——independent-review 的配套文章标题就很直给："子代理不是越多越好"。有把工作拆成可审查的小 PR 的技能，有审计你的工具和注入上下文每次请求吃掉多少的技能，有防止长会话变迟钝的，有决定一条 shell 命令该等多久的，也有教你怎么不慌不忙处理热修复的。另一个栈里加了一条挺扎心的技能：找出那些你一直在给自己的代理当手动步骤的循环，把你从里面摘出来。
所有内容都是通用的 SKILL.md 格式，所以大部分能装进 MiniMax Code、Claude Code、Codex 或任何支持技能的代理。安装就是一两行插件命令——claude plugin install ronny --marketplace MiniMax-AI/mcode-stack——只想要单个技能的话，把对应文件夹拷进代理的 skills 目录就行。
它不是什么
在有人过度解读之前，先澄清三件事。这不是 MiniMax Code 本体开源，工具在另一个仓库，这个仓库只有工作流和技能。这不是新模型，也不附带任何免费算力——你的代理跑在哪个模型上，费用照算。另外仓库整体是 MIT 许可，但那几条工程评审技能改自 Google 的工程实践文档，按 CC-BY 3.0 保留署名要求，想转载再发布的话要注意。
再补一句实话：这些技能我们自己没有装过、跑过。一份公开的清单不能证明它能抓到更多 bug——它能证明的是，有一个正经团队每天就是这么干活的，而且觉得值得分享。
那为什么还值得看
AI 编程的讨论一直围着"生成"打转：更大的模型、更长的上下文、更多的并行代理。MCode Stack 押的是另一头：下一波提升来自代理周围那一层工程习惯——什么时候让它停下来检查自己的活、谁来审、审查员可以看什么。independent-review 这条技能尤其点破了一个大多数人都感觉到过、却很少被正式说出来的失败模式：所谓第二意见从来都不独立，因为它读过第一意见的日记。
AI 审 AI 算不算真正的审查，可以争论。但一个眼神干净、拿着固定清单、指着需求说话的审查员，总好过今天多数团队实际在跑的那个流程——作者批完自己的考卷，所有人管这个叫完成。