老金开源“元”概念落地项目雏形，一套让你能做任意你想做的项目的架构！
众所周知，近期老金的文章发的很少，原因就是在憋这个项目。
在上周，我发了“元”的概念说明文章。
然后在假期期间，老金我终于把憋了两个月的项目推到 GitHub 了。
项目叫 Meta_Kim（元），beta 版，MIT 开源。
核心 skill meta-theory 在仓库里标到 v1.5.0（README 徽章可查）。
老金我不是在发布一个工具。
我是在说一件事：AI 编程缺的是治理纪律，Meta_Kim 是一包可落地的 beta 资产，不是银弹。
更准确地说，老金我真正想聊的，是一个叫 元 的概念。
今天不说花活，就说三件事：
元到底是什么，为什么 AI 编程需要它，以及 Meta_Kim 怎么落地。
经老金我实测，我拿国产模型，也拼出了很强的能力。学员评价如下：
图片加载中…
老规矩，项目地址在文末。
Readme上也写得更详细，但老金希望你能先看完本文，否则readme看着都会云里雾里。
先说痛点，你有没有这种经历
老金我每天用 Claude Code 写代码，用了大半年了。
一个文件改改还行。
一旦跨模块、跨文件，AI 就容易翻车。
最典型的场景：你让它重构认证模块，涉及 6 个文件。
它上来就改，改完 A 忘了 B 的依赖。
你让它修 B，它又把 C 搞坏。
来来回回，比你自己改还慢。
问题出在哪？
老金我想了很久，总结成一句话：AI 缺的不是写代码，是治理能力。
什么叫治理？
先搞清楚你到底要什么。
再决定谁来干。
干完要有人检查。
检查完要把经验沉淀下来。
听起来像项目管理对吧？
但多数 AI 编程产品的默认体验，仍是把你直接带进写代码。
追问、分工、审查、沉淀，很少被当成一等公民。
老金我不是说别人家零治理。
我是说，系统性地把协作 run 当对象来治理，仍然稀缺。
先把元说清楚
在介绍 Meta_Kim 之前，老金我得先把概念掰开讲透。
这个概念，是整篇文章的灵魂。
也是老金我认为 AI 编程领域一直缺的那块砖。
元是治理层的最小砖块
先别急着说这不就是模块化吗。
不是。
你要分清三样东西。
第一，Spec（规格说明）
Spec 管的是是什么。
偏静态说明，偏交付物描述。
第二，工程化
工程化管的是怎么批量、稳定地产出。
流水线、目录规范、CI、脚手架、代码风格，都在这一类。
第三，元
元管的是协作层：谁以什么边界参与、何时必须停、如何被审查、怎么进化。
什么该先做、什么该停、什么能对外说、错了怎么回滚。
三者可以并存。
但老金我只站第三块。
为什么？
前两块成熟方案很多。
唯独 AI 协作层的治理，目前几乎是空白。
AI 编程最容易出问题的，往往不是代码写得烂。
而是 边界不清：谁负责什么、谁不该碰什么、什么时候该停下来。
这些事不提前定好，后面一定会乱。
那什么算一个合格的元？
老金我按五条给你对齐。
1、可独立理解：不用读完整个系统，也能单独读懂它在管什么。
2、足够小：小到你能盯着它改，不会一动全身痛。
3、边界清晰：写清楚我管什么、我不管什么。
4、可替换：坏了能换一块，不至于整盘推翻。
5、可复用：换一条工作流还能拿出来用，不是一次性补丁。
五条凑齐，才算一个完整的元。
缺一条，就会碎、就会胀、就会用完就扔。
老金我的核心论点：
元这个概念，是 AI 编程从能写代码进化到能治理复杂任务的关键台阶。
没有它，你只能靠人的经验补治理缺失。
有了它，治理变成可操作、可沉淀、可进化的结构。
Meta_Kim，就是元这个概念的第一次系统性落地。
Meta_Kim 到底是什么
一句话：给 AI 编程助手加一层治理层，让复杂任务做对了再做。
它一套治理框架，跑在 Claude Code、Codex CLI（OpenAI 的编码 Agent）、OpenClaw（另一套 Agent 运行时）上。
注意老金我说的是运行时，不是平台。
Meta_Kim 的核心设计是：一套方法论，投影到三个运行时，不是三个独立项目。
这套方法论的核心叫 意图放大（Intent Amplification，把模糊话变可执行任务）。
用人话说：
把你一句模糊的话，变成边界清晰、职责明确、可执行可审查的任务。
老金我得强调：意图放大之前，先有可治理的结构，先要有元。
四个环节，缺一个就是残废
Meta_Kim 的方法论不是拍脑袋，它有一条完整方法链：
元 → 组织镜像 → 节奏编排 → 意图放大
元：怎么拆，把复杂系统拆成最小可治理单元。
组织镜像：怎么分工，每个单元职责边界写死。
节奏编排：怎么调度，谁先谁后、何时切换。
意图放大：怎么闭环，从模糊需求到完整交付。
图片加载中…
去掉任何一个环节，整套方法论就是残缺的。
这不是老金我在吹。
这条链对应的理论，老金我自己写了篇论文，Zenodo 自存档，DOI：10.5281/zenodo.18957649。
你觉得瞎说，可以点开 DOI 看全文。
论文地址：https://zenodo.org/records/18957649
图片加载中…
八个阶段，三个在想，一个在做，四个在验
这段默认说的是复杂任务：多文件、跨模块、要多种能力协作。
纯问答、或极简单 owner 的小改动，主源允许压缩脊柱或走分流（README 里有分流图，别被八阶段吓到）。
复杂任务要走八阶段流程，这是 Meta_Kim 的执行主干。
下面这张表，帮你把英文阶段翻成大白话。
图片加载中…
前三个阶段全是想，Execution 是唯一做，后四个阶段全是验。
你可能会说：这不就是正常软件开发流程吗？
没错。
但关键是：AI 自己不会主动走这个流程。
你不逼它，它就直接跳到 Execution 开始瞎写。
还有一点很多人不知道。
Thinking 阶段是 协议优先。
主源写死：Execution 开工前，至少要齐备 十个必需协议包，名字老金我念几个你感受下：runHeader、taskClassification、cardPlanPacket、dispatchBoard、workerTaskPacket（每 owner 一份）、workerResultPacket、reviewPacket、verificationPacket、summaryPacket、evolutionWritebackPacket。
复杂治理流（如 complex_dev、meta_analysis）还会要 intentPacket、intentGatePacket。
老金我不背全表。
记住一句：包不齐，就不该开干。
翻译成人话：
不是写完了再说。
而是怎么写、谁来写、怎么验、怎么交付，都得提前说清楚。
四条铁律 + 四条补充
老金我给这套系统定了四条铁律。
追问强于猜测（Critical > Guessing）
需求不清楚，先追问，不要猜。
AI 最大的毛病就是太自信。
搜索强于假设（Fetch > Assuming）
动手之前先找有没有现成的 Agent 或 Skill。
计划强于冲动（Thinking > Rushing）
拆任务、定责任人、理清依赖，要在写代码之前做完。
验证强于信任（Review > Trusting）
AI 写的每一行都要检查。
复杂系统里一个小错能引发连锁反应。
除了铁律，还有四条执行规则。
1、只有纯问答可以绕过 Agent：只要涉及改代码、产出交付物，必须有明确所有者。
2、每个可执行任务必须有 Owner：匿名执行禁止。
3、能并行就并行：独立子任务要声明依赖和并行组，别偷懒串行。
4、能力优先，不是名字优先：先描述需要什么能力，搜索谁拥有，再分派，别写死叫某某 Agent。
8 个元 Agent，你只需要认识一个
先分清一件事（README 里也写得很死）：
meta-theory 是 Skill，方法说明书，触发时加载纪律；
meta-warden 是 Agent，默认对外入口，管闸门和收口。
别混成一个人。
Meta_Kim 背后有 8 个专职 Agent。
用户只需要跟一个打交道：meta-warden（项目经理）。
图片加载中…
你只需要说：帮我重构这个认证模块。
默认入口是 meta-warden。
真正把你按纪律拽着走的，是 meta-theory skill 的规则。
复杂开发里主源要求 meta-theory 想、具名 agent 做：warden 协调收口，不是一个人包办执行。
用户不需要知道后厨有几个人。
就像你去餐厅点菜，不需要数厨师。
为什么越用越轻
这是老金我最想说的一个点。
很多人第一反应：8 个 Agent、8 个阶段，这不是更重了吗？
重，但只重在前面。
Meta_Kim 的设计逻辑是：把高成本的临时推理，逐步转化成可复用的能力资产。
刚开始更重：建 Agent、定义 Skill、写 Hook、配协议、补记忆策略。
越往后越轻：重复任务不必再从零发现能力、重新踩坑、重新定边界。
省下来的不是所有 token，而是重复性 token。
同类任务、已知任务、踩过坑的任务，平均成本会明显下降。
这不是画饼。
Evolution 阶段（第 8 阶段）的学习成果必须 写回磁盘，不是聊完就没了。
图片加载中…
主源还要求每轮 Evolution 给显式 writebackDecision：要么列写回目标，要么说明这轮为何没有结构性落盘。
避免聊完就算进化。
特别说一下 伤疤协议（Scar Protocol）。
什么是伤疤？
不是普通 bug，是 系统性的治理失败。
比如审查放过安全漏洞，一周后在生产爆了。
要记成伤疤，写进预防规则，供后续 Critical、治理 run 对照（是否自动扫描，取决于你怎么接记忆，别当成装好的 cron）。
伤疤不是失败标志，是系统学会自我保护。
跨三个运行时，一个源头
Claude Code、Codex CLI、OpenClaw，三家生态各不一样。
很多人同时用两三个工具。
问题是：你在 Claude Code 里配好的 Agent、Skill、Hook，换到 Codex 里往往要重来。
Meta_Kim 的解法：.claude/ 目录是唯一权威源。
改完跑一句 npm run sync:runtimes，同步到 Codex 和 OpenClaw。
具体来说，主源这几类最关键：
.claude/agents/*.md，8 个 Agent 定义。
.claude/skills/meta-theory/SKILL.md，核心技能定义。
contracts/workflow-contract.json，运行时治理契约。
Codex 侧的 .codex/、.agents/，OpenClaw 的 openclaw/workspaces/*，以及 shared-skills/，多是派生或参与校验的镜像层。
优先改主源，再同步。
工具链比早期全多了：validate、check:runtimes 对齐镜像，discover:global 扫全局能力，eval:agents 做轻量 smoke（CLI、钩子、脚手架）。
真要 prompt 级验收再用 eval:agents:live。
大改后还有 verify:all、verify:all:live。
另有 check:global:meta-theory、doctor:governance、validate:run 等。
npm scripts 二十多条，按同步、发现、校验、验收分块记就行，不必背全名。
Claude Code 主场上，.claude/settings.json 挂了 8 个 Hook：危险命令拦截、push 前提醒、格式化与类型检查、子代理上下文注入、会话结束审计等。
另有一个可选 Stop 完成度守门，默认关。
和契约、skill 一样，属于主源写好、同步后多运行时受益。
它不是一条流水线
看到八个阶段排成一排，你可能以为就是线性流水线。
不是。
表面上看，是一条链：
Critical → Fetch → Thinking → Execution → Review → Meta-Review → Verification → Evolution
还有第二层，别和上面揉成一个。
仓库里的部门运行合同是 十阶段：direction → planning → execution → review → meta_review → revision → verify → summary → feedback → evolve。
它管 run 怎么封装、交付怎么收口、对外展示什么口径。
不会改名，也不会顶替底下的八阶段脊柱。
心里记一句：脊柱管怎么执行，合同管怎么算交卷。
底层还有 6 层隐藏状态在控节奏（用户通常看不到）：
stageState，当前卡在哪一阶段。
controlState，正常、跳过、中断、静默还是迭代。
gateState，门禁，规划门开没开、验证门关没关。
surfaceState，产出是调试级、内部级还是可公开级。
capabilityState，能力覆盖全不全、有没有缺口、有没有升级。
agentInvocationState，Agent 是空闲、已发现、已匹配、已分派还是已返回。
它们让系统能处理跳过、中断、回滚、并行合并。
合同侧最近还加固了 没到点别喊完工：执行前要 taskClassification；要有可审计的 cardPlanPacket；审查要走 reviewPacket → 修订 → 验证 → 关闭；对外宣称前要 summaryPacket；进化写回要明确 writebackDecision。
老金我用人话说：有内容不等于能对外展示，闸门齐了才算。
说到 回滚，Meta_Kim 有四级机制。
图片加载中…
回滚不是失败，是系统知道什么时候该停。
说说真实的局限
beta 版，不完美的地方很多，老金我不藏着。
第一，学习成本不低
8 个 Agent、8 个阶段、4 条铁律、6 层隐藏状态。
概念够喝一壶。
你只改单文件，完全不需要这套。
第二，前期投入比较重
前几次配置 Agent、Skill、Hook，可能比直接写代码还慢。
好处在后面：重复任务越多，省得越明显。
第三，还在非常早期
开源不久，文档还在完善，bug 肯定有。
老金我自己每天都在修。
第四，不适合所有场景
单文件编辑、一次性小脚本、不需要跨模块协作，用它就是给自己添堵。
谁适合用
如果你经常处理跨文件、跨模块的复杂任务
Meta_Kim 能帮你减少 AI 瞎猜带来的返工。
如果你在用 Claude Code、Codex CLI、OpenClaw
一套配置同步三个运行时，省得维护三份。
如果你在管理多个 Agent 或 Skill
治理框架让边界更清晰，减少职责重叠。
如果你关心 AI 编程的可治理性
不是让 AI 写更多，是让 AI 写得更靠谱。
如果你只是改改单文件、写写小脚本
用不上。
别装了给自己添堵。
这是老金使用的一个案例，我的提问就一句话，“我怎么能传播我的个人博客 aiking.dev”
它就给我了完整的执行方案，以及 谁负责什么，要怎么做成。
图片加载中…
老金我的一点思考
做这个项目的过程中，老金我想明白了一件事。
AI 编程工具这两年发展太快。
模型越来越聪明，代码越来越像样。
但像样和靠谱之间，差的不是智商，是纪律。
聪明但没纪律的团队，小项目没问题。
大项目一定会乱。
AI 编程的下一步，不是让模型更聪明。
是让聪明的模型学会守规矩。
老金我想说更深一句：规矩不是靠人盯出来的，是靠结构长出来的。
元就是那个结构。
一个合格的元，自带边界、自带审查条件、自带进化接口。
你不必每次都喊别越界，设计本身限制越界。
你不必每次都问 Agent 干没干对，五条标准就是检查清单。
最重要的不是堆更多规则，而是找到最小治理单元，让纪律从结构里长出来。
这件事，老金我先干了。
Meta_Kim 是答案的第一版。
元这个概念，比 Meta_Kim 更大。
Meta_Kim 会迭代、会重构，甚至可能被更好的实现替代。
但元作为一种治理思想，最小可治理单元、边界先于执行、结构先于速度，老金我相信它会留下来。
正文资源：
GitHub：Meta_Kim（README 有中/英/日/韩入口，看图谱与维护命令会顺一点）
https://github.com/KimYx0207/Meta_Kim
Zenodo 论文全文 · DOI：10.5281/zenodo.18957649
https://zenodo.org/records/18957649
你可以 star，可以 fork，可以提 issue 骂我。
但老金我赌一件事：三年后回头看，元会成为 AI 编程治理的基本概念。