第 2 篇｜方法论运行时 — 为什么把纪律写进文件

这是 全栈 系列的开篇。它回答一个根本问题:当你想让 AI 反复、可靠地按某套规矩做事,你该把规矩放在哪里?答案决定了整个插件的形态。

一、问题的起点:提示词会蒸发

你和 AI 聊天时定下的规矩——"先复现再修 bug"、"没有验证不声称完成"、"ALTER 必须先于主任务发布"——默认活在三处:

1. 1. 当前对话的上下文里;
2. 2. 你脑子里的经验里;
3. 3. 某条偶尔被粘贴的提示词里。

这三处都不可靠:对话一压缩就蒸发;换个人就丢失;提示词一次性的。全栈 的第一性出发点就是:

纪律必须落到文件,随项目分发,被运行时反复加载——否则它只对你有效一次。

二、区分两个概念:提示词 vs 方法论运行时

大多数人把"写一个好 prompt"等同于"让 AI 听话"。全栈 不这么看。

全栈 要建的是后者:一个方法论运行时。它把"该怎么做事"编码成文件,再让一套事件驱动机制(hooks)在恰当的时机强制加载、检查、阻断。

Skill 也就是一段被文件系统承载、被事件系统驱动的方法论,而非一段更好的提示词。

三、运行时的物理形态:插件文件系统布局

复现这个插件,第一步是把目录骨架搭起来。所有目录都围绕"谁承载纪律、谁触发纪律、谁记录状态"分工:

关键认知:

• • SKILL.md 是纪律的容器,不是代码文件。它写给 AI 读,编码"应该怎么做"。
• • hooks 是纪律的牙齿。SKILL.md 说"不该跳过验证",hook 来阻断跳过验证的操作。
• • schemas 是纪律的形状。它规定"一个合格的交付长什么样",让产出可被机器校验。
• • scripts 是确定性的兜底。凡能用正则/计数/脚本判定的,绝不交给 agent 主观判断。

四、四条奠基规则

这一篇只立四条规矩,后续 20 篇都是它们的展开:

R2.1 纪律入文件,随项目分发。任何想被反复遵守的规矩,必须写进 skills/agents/hooks/schemas 的某个文件,而不能活在对话里。评判标准:换一个人、开一个新会话,这条规矩还在不在?

R2.2 脚本先行,agent 后判。能被正则/计数/脚本确定性判定的(语法、命名、字段存在性),由脚本先拦截;只有需要语义理解的,才交给 agent。原因:agent 会幻觉、会误唤起、会输出自由文本被误判为阻断。确定性优先于智能。

R2.3 事件驱动,而非人工触发。守卫不该等用户想起来才跑。写文件、调 MCP、对话压缩、AI 退出——这些事件由 hook 自动拦截/记录/恢复。用户只管干活,守卫在背后跑。

R2.4 运行时状态落盘,内存不可信。AI 的上下文会被压缩、会丢失。任何关键状态(当前阶段、产出进度、Git 分支、测试结果)必须写到 .omniverse/ 下,压缩后能自动读回。这直接催生第 11 篇的三层持久化。

五、为什么这样设计(第一性)

把"AI 帮你做事"拆到最底层,只有三个动作:决定干什么 → 干 → 检查干得对不对。

• • "决定干什么" → 由 commands(入口) + routing(路由)解决,这是第 3 篇。
• • "干" → 由 skills(方法论) + agents(角色)解决,这是第 6~7 篇。
• • "检查干得对不对" → 由 hooks(守卫) + schemas(契约) + schemas 校验 + 基线/冒烟(回归)解决,这是第 13~19 篇。

而贯穿三者的,是"状态不丢"和"越用越好"两条横切——持久化(第 1112 篇)与自进化(第 1618 篇)。

R2.2(脚本先行)和 R2.4(状态落盘)合在一起,就是整个插件所有设计决策的母规则:它不信任内存,也不信任模型,它只信任文件和脚本。

六、常见合理化借口

七、本篇产出的"形状"

这一篇产出的是心智模型。主要回答:

1. 1. 插件有哪些目录,各承载什么纪律?
2. 2. 为什么纪律要落文件而不是写对话?
3. 3. 为什么确定性脚本优先于 agent 判断?
4. 4. 为什么状态必须落盘?

带着这四条奠基规则,下一篇我们将进入第一个具体机制:怎么让 AI 知道该走哪条路——两步式路由。