MiniMax 把自家 coding agent 的工作手册开源了：17 个技能，先管住评审和上下文

10 月 28 日，MiniMax 在 GitHub 上公开了一个叫 mcode-stack 的仓库。里面没有 MiniMax Code 的源代码，装的是这家公司的 MiniMax Code 团队每天真正用的工作方法：17 个 SKILL.md 技能和 5 份清单，讲的都是 agent 干活时最容易翻车的地方——什么时候该拆子 agent、上下文贵在哪里、长会话怎么不越跑越糊、长命令怎么等、代码评审怎么做才不被作者带偏。仓库建在 10 月 28 日，协议是 MIT，发布第二天上午看过去已经有 360 个 star。这篇讲的不是“又一个提示词合集”，而是为什么一家做 coding agent 的团队会把自己的内部工作手册拿出来，以及普通开发者拿它能直接抄什么。

先说清这个仓库是什么、不是什么。它不是 MiniMax Code 本身——MiniMax Code 是另一个 MIT 开源的终端 coding agent，mcode-stack 里不含它的源代码。它也不是一堆通用提示词。仓库自己的话说得很直白：这不是提示词合集，也不是“最佳实践”清单，而是团队成员每天实际用的东西：怎么让 AI 写的代码保持高标准、一个任务该不该交给子 agent、一条长命令要等多久、长会话怎么不走样、每一轮到底往上下文里塞了什么。每一项都是一份 SKILL.md 技能或者清单，可以直接装进 agent 里跑，而不是放在文章里读完就忘。

里面到底有什么

仓库由两个 stack 组成。主 stack 叫 ronny，来自 MiniMax Code 的研发负责人 Ronny，是最完整的一套，一共 15 个技能；另一个 stack 叫 jiachen，补了 2 个技能，总数 17 个，另有 5 份清单和 5 篇配套文章（《MCode Engineering Notes》专栏）。文章讲道理，技能把道理变成可执行的检查步骤——这个“一篇文章配一个可运行技能”的 pairing，是整个仓库最值得学的地方。

Ronny 的 15 个技能按一天的工作节奏分组。计划和拆分有 3 个：subagent-split-check（决定工作是交给子 agent 还是留在主循环）、engineering-small-prs（把大功能、重构、迁移拆成可评审的小 PR）、engineering-change-descriptions（写清楚改了什么、为什么改的 PR 和提交描述）。上下文和工具有 2 个：tool-budget-audit（量工具在上下文里花了多少钱）、context-tax-audit（每一轮被塞进请求里的东西，以及它对提示缓存的影响）。长会话和长命令有 3 个：long-session-check（该丢弃、该摘要、该写文件，还是该压缩或重开；内存放多大范围）、handoff-doc（写一份交接文档，让新会话能接上旧工作）、long-command-check（针对长 shell 命令和后台任务的 10 项检查）。评审有 4 个：independent-review、engineering-code-review、engineering-review-comments、engineering-review-feedback。实验和热修复有 3 个：harness-experiment、trajectory-review、engineering-emergency-changes。

其中几个技能的思路很值得单独说。independent-review 要求评审员只拿 3 样东西：diff、需求、测试结果，并且故意不给作者的对话记录。理由很直接：评审员如果继承了作者的上下文，就会重复作者的盲点。这和我们平时“评审先看作者怎么说”的习惯正好反过来，但对 AI 生成的代码尤其有道理——因为作者（不管是人还是 agent）最容易在自己已经相信的前提上滑过去。

subagent-split-check 则给“要不要拆子 agent”立了一条硬规矩：只有当上下文是已经量出来的问题时才拆，按团队分工或者按问题类型拆都不算正当理由。这句话对现在动不动就“多开几个 agent 并行”的风气是个提醒：并行不是免费的，每多一个 agent 就多一份上下文账单和一份协调成本，没量过就别拆。

tool-budget-audit 把工具成本拆成两笔账：工具定义（告诉模型有哪些工具）和工具结果（工具跑完返回的东西）。工具搜索主要省的是第一笔，程序化调用工具主要省的是第二笔。很多人调 agent 成本时只盯着一笔，结果另一笔在悄悄漏水。context-tax-audit 补的是另一块：每一轮请求里被自动塞进去的东西——系统提示、技能描述、记忆、工具定义——都会收“税”，而且会影响提示缓存的命中。不知道税交在哪，就没法谈省 token。

long-command-check 的 10 项检查也很对症：一条命令挪到后台之后，进程会不会被重跑？没读完的结果在上下文压缩之后还活着吗？这些都是长任务跑着跑着就丢了、或者重复跑了两次的常见原因。harness-experiment 则要求做实验一次只改一个变量，记录哪些任务的结果翻转了、每个任务多少请求、多少 token、缓存命中率和耗时。没有这个纪律，所谓的“换了个模型效果更好”往往只是运气。

另外，6 个 engineering-* 技能改编自谷歌的工程实践材料，这部分仍保留 CC-BY 3.0 协议，不是 MIT——引用或者二次改编时要留意协议不同。Jiachen 的 2 个技能方向不太一样：lifting-loops 是找出那些你一直在替 agent 手动跑的环节、把你从循环里摘出来；making-content 是把笔记和素材转成小红书图文和短竖视频。后者跟写代码关系不大，照搬时要分清楚：这个 stack 里不是每样东西都冲着 coding 来的。

为什么一家 agent 厂商要开源自己的工作手册

表面上看，MiniMax 是在送东西；实际上它在划一条线。过去几个月，agent 技能（SKILL.md）正在变成各家争夺的格式：Anthropic 在 10 月 22 日把 Agent Skills 等项目捐给了 Linux 基金会旗下的组织，市面上也出现了各种技能包。在这个时间点开源自己的内部用法，MiniMax 争的不是某一个技能写得好不好，而是“我们这套工作方式”能不能成为别人默认抄的模板。格式是开放的，内容是自家的，生态一旦跟着你的模板走，你的 agent 就更容易被接纳。

对开发者来说，更实际的意义是：这套东西回答的不是“怎么写提示词”，而是“怎么管一个会自己干活的 agent”。写代码这件事，模型越强，瓶颈越不在“能不能写出来”，而在“写出来的东西谁来把关、上下文花了多少钱、长任务跑丢了怎么办、一次改动到底可不可信”。mcode-stack 里的技能，几乎全是冲着这第二层问题去的。这也是它和市面上很多技能包的区别：后者教你怎么让 agent 多干活，前者教你怎么让 agent 少闯祸。

还有一点值得注意：这个仓库的起点是“团队内部真的在用”，而不是“为了开源而写”。证据是它的组织方式——每个技能都对应一篇工程笔记，笔记讲为什么，技能讲怎么做；贡献规则也写明，现阶段只有协作者能直接提 PR，其他人先开 issue 讨论。这说明它目前还是一份“正在演进的工作手册”，而不是一份定稿的标准。拿来用可以，拿来当标准背诵就过头了。

对 vibe coding 开发者：先抄哪 4 个

如果你平时就是一个人加一个 agent 在做项目，不用 17 个全装，先从 4 个开始，顺序如下。

第一，装 independent-review，并且真的用它来审 AI 的改动。做法是：让 agent 写完代码、跑完测试之后，另开一个干净的评审视角，只给它 diff、需求原文和测试结果，不给之前的对话记录，然后让它按严重程度写评审意见。你会发现，很多“看着对”的问题是在这个干净视角下才冒出来的。等这条跑顺了，再把 engineering-review-comments 的写法接上：评审意见要带严重程度分级、讲清理由，而不是只说“这里不好”。

第二，装 subagent-split-check，治一治“并行上瘾”。下次想拆子 agent 之前，先让它回答一个问题：上下文是不是已经量出来的瓶颈？如果不是，就别拆。很多个人项目的问题根本不是“人手不够”，而是主循环里塞了太多东西——先做 tool-budget-audit，看看工具定义和工具结果各花了多少，再决定是剪工具、还是上工具搜索、还是改成程序化调用。

第三，装 long-command-check 和 long-session-check，管住长任务。凡是超过几分钟的命令、后台任务、跨会话的长活，先走一遍 10 项检查：会不会重跑、结果会不会在压缩后丢失、中途断了怎么续。长会话跑到一半开始“变糊”时，别硬撑着继续对话，按 long-session-check 的路子：该摘要的摘要、该写文件的写文件、该重开的重开，再配一份 handoff-doc 让新会话接得上。这比在糊掉的会话里反复纠正要省得多。

第四，装 harness-experiment，给自己的“调参”立规矩。以后每次想换模型、换技能、改流程，都只改一个变量，跑重复实验，记下哪些任务结果翻转了、token 和耗时怎么变。没有这个记录，你对“新版更好”的感觉基本不可信——运气和真实改进是分不出来的。

安装本身不复杂，仓库 README 给了三条路。最省事的是在 Claude Code 里装整个 stack：一条 marketplace 命令装 ronny 或者 jiachen；Codex 也有对应的 marketplace 命令；只想拿某一个技能时，把它的文件夹拷到 ~/.agents/skills/ 就行，MiniMax Code、Claude Code 和 Codex 都会读这个目录。MiniMax Code 桌面版的 marketplace 添加功能还在逐步放开，你的版本如果没有这个入口，就先用拷文件夹的办法。装完之后在新会话里用 /skills 看一眼，确认技能真的被加载了，再开始用——装了但没加载，等于没装。

风险与还没定下来的地方

有几盆冷水要先泼。第一，这个仓库 10 月 28 日才公开，发布时只有 10 次提交，star 数一天之内还在快速变，内容随时可能大改。现在抄进去的技能，要当作“会演进的工作手册”来对待，定期去看更新，而不是装一次就当作定论。

第二，仓库没有附任何评测数据。README 里没有“用了这套技能之后，返工率降了多少、token 省了多少”这样的数字，第三方报道也明确说了这一点。所以它目前只能算一份经验沉淀的 playbook，不能算被证明有效的方法论。你自己的项目就是评测场：按 harness-experiment 的规矩，拿自己的任务量一量，再决定留哪些、扔哪些。

第三，不是每个技能都适合个人项目。engineering-* 那组来自大公司的工程实践，讲的是多人协作下的 PR 拆分、评审流程和紧急变更纪律；一个人做副业项目时，照搬全套反而会拖慢节奏。建议的取舍是：评审和上下文那几条照单全收，流程纪律那几条按需取用，别为了“像大厂一样”而给自己加流程。

第四，技能格式本身还在演进。SKILL.md 现在是各家都支持的通用格式，但不同 agent 对技能的加载、触发和权限处理并不完全一致。同一个技能在 MiniMax Code 里跑得顺，在别的 agent 里可能触发时机不同、或者根本不触发。换 agent 时，别默认技能行为也跟着搬过去，要重新验证一遍。

把技能表摊开：每一组到底在防什么

如果把 17 个技能按“防什么”重新归类，会发现它们其实只防四类事。第一类是“评审被带偏”，对应 independent-review 和整组评审技能。AI 写代码时，作者视角和评审视角很容易合谋：写代码的 agent 相信自己的思路，评审的 agent 如果读了同一份对话记录，也会沿着同一条思路往下走，最后两边一起把一个前提错误当成了共识。independent-review 的办法很粗暴，也很有效：把评审员放到干净的上下文里，只给 diff、需求和测试结果，让它自己重新推一遍。这个办法对人也适用——很多团队做代码评审时，先看作者的解释再看代码，顺序反了，评审质量就打折。

第二类是“上下文花冤枉钱”，对应 tool-budget-audit 和 context-tax-audit。很多人第一次看到 agent 账单时都会吓一跳：明明没让它干多少活，token 却哗哗地走。原因往往不在你发的那几句话，而在每一轮自动塞进去的东西：系统提示词、技能描述、工具定义、记忆片段、历史对话。这些东西每一轮都要重新算一遍，还会影响缓存命中。tool-budget-audit 的价值在于把账拆开：先分清是工具定义贵还是工具结果贵，再决定是剪工具、做工具搜索，还是改成程序化调用。没有这张拆开的账单，所有的省 token 动作都是凭感觉。

第三类是“长任务中途掉链子”，对应 long-session-check、handoff-doc 和 long-command-check。长任务有三种死法：会话跑糊了、命令跑丢了、交接断了。会话跑糊是最常见的：对话越长，agent 越容易前后不一致，开始重复问已经定下来的事，或者悄悄改掉早期的决定。long-session-check 给的办法是主动管理——该摘要就摘要，该写文件就写文件，该重开就重开，别等到糊得没法救了才处理。handoff-doc 则是给重开准备的：把“做到哪了、下一步是什么、哪些决定已经定了”写下来，新会话照着接，而不是从头再问一遍。

第四类是“凭感觉下结论”，对应 harness-experiment 和 trajectory-review。换模型、换技能、改流程之后，效果变好变坏，人的感觉是最不可靠的证据：跑一次顺了就觉得新版好，跑一次卡了就觉得新版差。harness-experiment 要求一次只改一个变量、重复跑、记录哪些任务的结果翻转了；trajectory-review 则要求不只看结果对不对，还要看 agent 是怎么走到结果的——是推理对了，还是蒙对了。这两条加起来，才是“改进”这个词成立的前提。

这样归类之后，取舍就清楚了：评审和上下文这两类，是所有用 agent 写代码的人都会撞上的问题，优先级最高；长任务那类，取决于你的任务是不是真的长——如果每次会话都在一小时内结束，它的价值就没那么大；实验纪律那类，取决于你调参调得多频繁——如果你基本不换模型、不改流程，它可以先放一放。不是 17 个技能都要装，而是先装你正在疼的那几类。

从这份仓库学到的工作方法

除了技能本身，这份仓库的工作方法也值得抄。第一条是“文章配技能”：每篇工程笔记讲一个道理，每个技能把道理变成可执行的检查步骤。很多团队内部也有经验总结，但都躺在文档里，读完就忘；变成技能之后，agent 会在合适的时机自己把它加载出来用。换句话说，经验从“人记得”变成了“系统记得”。个人开发者也可以照着做：把你踩过的坑写成一份 SKILL.md，下次 agent 再遇到同类任务，它就能先过一遍你的检查表。

第二条是“按一天的工作节奏分组”。Ronny 的技能不是按技术领域分的，而是按“计划、上下文、长会话、评审、实验”这些一天里真实出现的时刻分的。这种分法的好处是，agent 在某个时刻需要什么，就能找到对应的技能，而不是对着一堆按技术名词排列的清单发呆。你自己整理技能时，也可以照这个思路：别按“提示词技巧、模型参数”这种教科书分类，按“我的一天里什么时候会用到它”来分。

第三条是“先开 issue 再提 PR”的贡献规则。现阶段只有协作者能直接提 PR，其他人先开 issue 讨论。这条规则看起来是门槛，实际上是质量保证：技能这种东西，写得不对反而会误导 agent，比没有技能更糟。先讨论再合并，能挡住很多“看起来有道理、实际没验证”的内容。个人项目里也可以借鉴：新技能先在自己的任务上跑几遍、确认真的有用，再把它固定下来，别一拍脑袋就写进常用技能库。

最后说一句判断：mcode-stack 的价值不在 17 这个数字，而在它把“怎么管 agent”这件事从玄学变成了清单。Vibe coding 走到今天，缺的从来不是让 agent 多写几行代码的办法，缺的是写完之后谁来把关、上下文花在哪、长任务怎么不断线。这些问题不解决，代码写得越快，返工和账单也涨得越快。这份开源手册给不了一个标准答案，但它给了 17 张现成的检查表——先抄评审和上下文那几张，是最划算的起点。