Superpowers 与编程治理框架

这批资料最有价值的新共识之一，是”AI 编程治理层”终于被讲清楚了：不是靠一句神 prompt 让 agent 突然靠谱，而是把 brainstorming、计划、测试、回归、收尾这些步骤显式写进 Skills 和框架里。随着 Loop Engineering 的提出，治理已经跨越了”设规则让 Agent 不出事”的阶段，进入”设计 Agent 的运行闭环本身”的系统工程层面。 [[raw/2026-04-30/AI兴观点/你的AI编程搭档，有了-超能力-——Superpowers Skills技能库完全指南.md|来源: 你的AI编程搭档，有了-超能力-——Superpowers Skills技能库完全指南.md]] [[raw/2026-04-30/wsleepybear/Superpowers 上手实战：怎么把 coding agent 从直接开写，带回可控的工程流程.md|来源: Superpowers 上手实战：怎么把 coding agent 从直接开写，带回可控的工程流程.md]]

Superpowers 的核心不是能力堆叠

它强调先想清楚再动手、系统化优于随机化、降低复杂度、用证据说话，本质上是在给 agent 行为加”工程护栏”。 [[raw/2026-04-30/AI兴观点/你的AI编程搭档，有了-超能力-——Superpowers Skills技能库完全指南.md|来源: 你的AI编程搭档，有了-超能力-——Superpowers Skills技能库完全指南.md]]
实战文把这套东西接到 Claude Code、Cursor、Codex、Gemini CLI 上，证明它不是某个平台专属，而是可迁移的治理模板。 [[raw/2026-04-30/wsleepybear/Superpowers 上手实战：怎么把 coding agent 从直接开写，带回可控的工程流程.md|来源: Superpowers 上手实战：怎么把 coding agent 从直接开写，带回可控的工程流程.md]]

技能库与框架开始成体系

洁癖.skill 代表的是”卫生型约束”：让 agent 越用越规整。 [[raw/2026-04-29/数字生命卡兹克/开源「洁癖.skill」，让你的Agent越用越聪明。.md|来源: 开源「洁癖.skill」，让你的Agent越用越聪明。.md]]
老金的治理框架则把单位抬得更高：不只是某个 Skill，而是支持含 CC、Codex 等多个平台的元架构。 [[raw/2026-04-29/金先森是朝鲜族阿/老金开源了个支持含CC、Codex等4个平台的编程治理框架.md|来源: 老金开源了个支持含CC、Codex等4个平台的编程治理框架.md]]
青斧总结的 Skill 写法，补上了把这些经验沉淀为可加载配置的细节。 [[raw/2026-04-27/青斧/工作流的 Skill 怎么写？从 7 个顶级 Skill 中提炼的模式与最佳实践.md|来源: 工作流的 Skill 怎么写？从 7 个顶级 Skill 中提炼的模式与最佳实践.md]]

Harness Engineering 五条原则

晋小辰提出的五条原则把 Superpowers 从”技能集合”升级为”工程治理体系”：

约束优于指令（Constraints over Instructions）：告诉 AI 不能做什么比告诉它做什么更可靠
TDD 先行：测试不是写完代码再补的，而是需求的可执行表达
确定性逻辑外置（Deterministic Logic Externalization）：把确定性逻辑抽到外部脚本/工具，不让 LLM 猜
文件系统即记忆（Filesystem as Memory）：用文件沉淀状态，而不是依赖对话历史
工具设计优于提示词设计（Tool Design over Prompt Design）：好工具带来的提升远大于精修 prompt

这五条原则和 Superpowers 原有的”先想清楚再动手”、“用证据说话”形成互补——前者是从 prompt 工程视角，这五条是从系统工程视角。 [[raw/2026-05-08/晋小辰/Harness Engineering：从 Prompt 工程到系统工程.md|来源: 晋小辰五条原则]]

决策层级：别一上来就掏 AI

在动用 AI Agent 之前，应该按这个顺序自问：

目标清晰吗？→ 10 行代码能解决吗？→ CLI 脚本够吗？→ Prompt 能搞定吗？→ 再上 Agent

“80% 的 AI 需求根本不需要 AI”——这不只是省 token 的问题，而是每引入一层就多一层的不可控性。这个决策层级和 Superpowers 的”降低复杂度”原则高度一致。 [[raw/2026-05-07/腾讯程序员/十年技术老开发的 AI Agent 探索之路.md|来源: 腾讯程序员决策层级]]

Loop Engineering：第四次抽象跃迁

梦朝思夕提出的 Loop Engineering 将编程治理推进到第四代：Prompt Engineering → Context Engineering → Harness Engineering → Loop Engineering。核心论断是 Harness Engineering 仍是”脚本思维”——写规则让 Agent 不出事；而 Loop Engineering 是”系统思维”——设计 Agent 的运行闭环本身。Loop 不再把 Agent 执行视为线性任务，而是视为一个需要设计终止条件、错误恢复、护栏机制的循环系统。 [[raw/2026-06-19/梦朝思夕/万字长文 - 带你由浅入深了解 Loop Engineering：从手动 Prompt 到设计系统的跃迁.md|来源: Loop Engineering 万字长文.md]]

矛盾：Harness Engineering 是 Agent 编程的最终范式（现有 wiki 将 Harness 定位为第三次跃迁的终点） vs Loop Engineering 是 Harness 之后的第四次跃迁——Harness 是脚本思维，Loop 是系统思维来自 [[raw/2026-06-19/梦朝思夕/万字长文 - 带你由浅入深了解 Loop Engineering：从手动 Prompt 到设计系统的跃迁.md|来源: Loop Engineering 万字长文.md]]，而 Guide 则持”新瓶装旧酒”的怀疑视角——循环本身不新，新鲜的是名字，能力早就在往这个方向走了来自 [[raw/2026-06-17/Guide/面试官：‘你说你懂 Loop Engineering，那 Claude Code 的 -loop 和 -goal 区别是什么？‘我：‘这是啥？‘.md|来源: /loop vs /goal.md]]

五要素模型与 Memory 第六要素

Loop Engineering 的核心运行单元由五要素组成，外加第六要素 Memory：

Automations：启动触发（定时/事件/手动）
Worktrees：隔离执行环境——在多来源中已形成共识，是解决多 Agent 并行冲突的标准隔离方案
Skills：知识固化与流程封装
Connectors：行动能力（工具/MCP/API）
Sub-agents：质检与并行执行
Memory（第六要素）：跨会话记忆持久化

Loop 的六大组件

每个 Loop 实例由六个组件构成： [[raw/2026-06-19/梦朝思夕/万字长文 - 带你由浅入深了解 Loop Engineering：从手动 Prompt 到设计系统的跃迁.md|来源: Loop Engineering 万字长文.md]]

Goal（目标定义）：明确完成条件和验收标准
Tools（工具集）：可访问的工具和权限范围
Context（上下文管理）：输入什么、保留什么、压缩什么
Termination（终止逻辑）：何时停止（成功/失败/超时）
Error Recovery（错误恢复）：失败时的降级和重试策略
Guardrails（护栏）：安全边界和行为约束

其中 Guardrails 有一个实用的工程二分法：

资源类护栏（磁盘写入限制、API 调用频控、文件访问范围）→ 应”焊死”不可绕过
认知类护栏（代码风格规范、设计原则、质量门禁）→ 应可插拔，随任务调整

/loop 与 /goal 的机制区分

Guide 的文章清晰区分了两个易混淆概念： [[raw/2026-06-17/Guide/面试官：‘你说你懂 Loop Engineering，那 Claude Code 的 -loop 和 -goal 区别是什么？‘我：‘这是啥？‘.md|来源: /loop vs /goal.md]]

/loop = 时间驱动轮询：下次什么时候醒（“每 5 分钟检查一次”）
/goal = 目标驱动完成：什么时候算做完（“修复这些测试”）

更根本的是内外层循环区分：

内层循环（Agent Loop）：Agent 自身推理→行动→观察的迭代，由 LLM 的思考过程驱动
外层循环（Engineering Loop / Scheduling）：调度系统唤醒→分配→验证→记录，由工程基础设施驱动

Goal 本质上是用 YAML 定义的外层循环终止条件，/loop 是固定间隔的外层循环调度方式。两者的混用是 Loop 工程中的常见错误。

L0-L4 安全权限框架

Guide 提出的权限分级模型，为 Agent 自主运行提供了渐进的安全基线： [[raw/2026-06-17/Guide/面试官：‘你说你懂 Loop Engineering，那 Claude Code 的 -loop 和 -goal 区别是什么？‘我：‘这是啥？‘.md|来源: /loop vs /goal.md]]

L0 - 只读摘要：仅读取代码并生成摘要，不写任何内容
L1 - 本地复现：允许在本地环境复现问题，仍不修改代码
L2 - 草稿修复：生成本地文件修改，但不创建 PR
L3 - 创建 PR：自动创建 PR，但需要人工审批合入
L4 - 自动合并：全自动无人干预

实操建议：第一版从 L0 开始，不要直接上无人值守。

四种常见 Loop 模式及统一陷阱

Retry Loop：带指数退避的重试循环——核心陷阱是无限制重试导致资源耗尽
Plan-Execute-Verify：先计划→执行→验证循环——核心陷阱是计划本身不验证
Explore-Narrow：广搜后聚焦——核心陷阱是搜索空间未收敛就进入窄化
Human-in-the-Loop：关键节点等待人类判断——核心陷阱是人类成为瓶颈

所有 Loop 陷阱的根源高度一致：Loop 在没有人类判断的情况下做了不该做的事。这是验证缺口（Verification Gap）的具体表现——AI 告诉你的完成状态和实际完成之间存在差距。 [[raw/2026-06-19/梦朝思夕/万字长文 - 带你由浅入深了解 Loop Engineering：从手动 Prompt 到设计系统的跃迁.md|来源: Loop Engineering 万字长文.md]]

多 Agent 协作场景还有一个特有的失效模式：辩论对抗拓扑的”双重确认偏误”——两个 Agent 互相说服错误结论，而非互相纠正。

Loop 成本公式

Loop 的实际运行成本大于各组件成本之和： [[raw/2026-06-19/梦朝思夕/万字长文 - 带你由浅入深了解 Loop Engineering：从手动 Prompt 到设计系统的跃迁.md|来源: Loop Engineering 万字长文.md]]

实际月成本 = 基础成本 × Thrashing 系数

Thrashing 系数反映 Agent 在错误方向上的无效迭代。试点阶段和规模化阶段的成本结构和关注点完全不同——试点阶段关注 Loop 能不能跑通，规模化阶段关注 Thrashing 系数能不能降下来。

/goal 模板模式：从概念到可执行制品

万物构想提出的六个即用型 /goal YAML 模板（代码重构、发布流水线、数据清洗、博客写作、测试修复、依赖升级）标志着 Goal 从概念讨论进入可执行制品层面。 [[raw/2026-06-20/万物构想/让你的 CC - Codex 无人值守：6 个可直接复用的 -goal 模板.md|来源: /goal 模板模式.md]]

六字段模板结构

每个模板统一包含：

title：任务标题
inputs：输入参数定义
success_criteria：成功标准（可验证的具体条件）
common_failure_modes：常见失败模式——显式列出失败场景比成功条件更有实战价值（如”用 sleep 掩盖竞态”、“只升不测”）
short_test：声明完成前的快速验证命令——一个实用技巧，确保 Agent 在宣告完成前执行验证
deliverables：交付物清单

关键设计模式

common_failure_modes 的防御价值：显式列出 Agent 容易犯错的具体模式，相当于把历史踩坑经验编译进模板——比成功条件更能提升可靠性。
short_test 验证闭环：在 Agent 声明完成前执行一个快速 shell 命令验证状态。这是验证信任危机的应对方案——多来源一致指出 AI 自称的完成不可信，需要独立验证手段。 [[raw/2026-06-20/万物构想/让你的 CC - Codex 无人值守：6 个可直接复用的 -goal 模板.md|来源: /goal 模板模式.md]] [[raw/2026-06-19/扶苏/Claude Code 深度实战：半年单兵重构 30 万行代码的硬核工程化指南.md|来源: 扶苏半年实战.md]]
跨平台兼容：模板同时兼容 Claude Code 和 Codex，反映了两个工具从竞争到互补的趋势——Claude Code 做规划分析（/plan），Codex 做长线执行（/goal）。 [[raw/2026-06-20/Wise Wong/交了200刀的学费，我总结了Codex的15个技巧.md|来源: Codex 15个技巧.md]]

工作流前置：图像优先开发

Wise Wong 提出的多阶段设计工作流：先用 gpt-image-2 画方向稿 → 画完整视觉稿 → 输出设计规范 → 更新到 AGENTS.md 长期指导开发。AI 有了视觉参照后产出的 UI 不会千篇一律。 [[raw/2026-06-20/Wise Wong/交了200刀的学费，我总结了Codex的15个技巧.md|来源: Codex 15个技巧.md]]

实践深化：Hooks 驱动的自动化治理

扶苏的半年实战经验提供了多个高价值工程模式： [[raw/2026-06-19/扶苏/Claude Code 深度实战：半年单兵重构 30 万行代码的硬核工程化指南.md|来源: 扶苏半年实战.md]]

Hook 驱动的 Skill 自动激活

通过 Hooks 系统实现 Skill 的条件触发：

UserPromptSubmit hook（前置拦截）：基于关键词分析注入 Skill 激活提醒
Stop Event hook（后置守卫）：扫描变更文件的高风险模式

这套机制用 skill-rules.json 配置文件驱动，实现了 Skill 的”声明式加载”——不是靠模型自己决定什么时候该用什么 Skill，而是由外部 Hook 根据实际情况自动注入。

开发文档工作流与上下文切换协议

扶苏设计了一套明确的操作协议应对上下文窗口压力：

启动大任务前生成三件套：[task]-plan.md、[task]-context.md、[task]-tasks.md
当上下文使用率达到 15% 时，更新开发文档并通过 /compact 交接给新会话
新会话读取三件套继续执行

这个模式与前一个迭代周期中的 Hermes Agent 结构化压缩思路一致——上下文不是被动等爆，而是主动管理预算。

PM2 + Hooks 自主调试

将 PM2 进程管理嵌入 AI 工作流的完整闭环：Claude 自动执行 pm2 logs、pm2 restart、pm2 monit，无需人类介入。同时设定了具体的操作阈值：

构建错误 <5 个：自动修复
构建错误 >=5 个：升级到 auto-error-resolver subagent

这个”≤5 自动修 vs ≥5 升级人”的阈值规则提供了 Agent 自主权与人类介入的具体分界线——比模糊的”遇到复杂问题问人”更可操作。

脚本附加到 Skill

与”CLAUDE.md 精简、Skills 详细”的架构一致：将测试说明文本替换为可执行脚本的嵌入（如 node scripts/test-auth-route.js [url]），Claude 可以直接执行而非阅读文档。这是”确定性逻辑外置”原则的具体实践——把验证步骤从”告诉模型怎么做”改为”让模型直接执行”。 [[raw/2026-06-19/扶苏/Claude Code 深度实战：半年单兵重构 30 万行代码的硬核工程化指南.md|来源: 扶苏半年实战.md]]

Claude Code 配置机制全景：七种定制方式

Anthropic 官方系统性地梳理了 Claude Code 的七种自定义机制，明确它们在加载时机、压缩行为和权重三个维度上的差异。这构成了编程治理的底层设施认知框架。 [[raw/2026-06-19/Anthropic/调教 Claude Code 的七种方法.md|来源: 调教 Claude Code 的七种方法.md]] [[raw/2026-06-20/金色传说大聪明/深入理解 Claude Code：从 CLAUDE.md 到 Hooks、Skills、Subagents…md|来源: 深入理解 Claude Code.md]]

机制	加载时机	压缩行为	适合场景
CLAUDE.md (根目录)	会话开始即加载，全程保留	压缩后重新读取	构建命令、编码规范、团队约定
CLAUDE.md (子目录)	按需加载，读取子目录文件时触发	压缩后丢失，再次访问时重新加载	特定子目录局部规范
Rules	会话开始（用户级）或路径匹配时	压缩后重新注入	特定约束（如”API handler 必须用 Zod 校验”）
Skills	仅名称和描述启动时加载，正文调用时加载	共享预算内先进先出	封装可复用的工程/业务工作流
Subagents	在独立上下文窗口运行，仅最终结果回传	主会话不受影响	隔离型复杂任务，40+ 小时长时运行
Hooks	由 harness 外部执行，完全绕过上下文	不受压缩影响	确定性行为：代码检查、权限管控、日志记录
Output Styles	注入系统提示，永不压缩	替换默认编码指令	角色定位、响应格式对齐

关键洞见：

根目录 CLAUDE.md 是唯一”全程加载、全程占 token”的机制，每一行都在消耗上下文窗口。官方建议控制在 200 行以内，指定 owner，像审代码一样审改动。 [[raw/2026-06-19/Anthropic/调教 Claude Code 的七种方法.md|来源: 调教 Claude Code 的七种方法.md]]
子目录 CLAUDE.md 按需加载，但压缩后丢失，适合局部约束。
Skills 设计很聪明：启动时只加载名称和描述，正文在调用时才进上下文。上下文满时最旧的 skill 会被踢出（先进先出）。 [[raw/2026-06-20/金色传说大聪明/深入理解 Claude Code：从 CLAUDE.md 到 Hooks、Skills、Subagents…md|来源: 深入理解 Claude Code.md]]
Subagents 从主会话角度看上下文成本为零，它们跑在独立上下文窗口，仅结果返回。
Hooks 走代码执行路径，完全绕过 LLM 上下文窗口——这是”确定性执行”和”提示词说服”的根本区分：CLAUDE.md/Rules/Skills 依赖模型理解和遵从，Hooks + Permissions 走代码执行路径。“告诉 AI 怎么做”和”让事情自动发生”是两件不同的事。 [[raw/2026-06-20/金色传说大聪明/深入理解 Claude Code：从 CLAUDE.md 到 Hooks、Skills、Subagents…md|来源: 深入理解 Claude Code.md]]
Output Styles 有严重副作用：它替换系统提示而非追加，这意味着默认编码指令（如何控制改动范围、何时加注释、安全问题处理、验证习惯）会被丢弃。使用需谨慎。 [[raw/2026-06-19/Anthropic/调教 Claude Code 的七种方法.md|来源: 调教 Claude Code 的七种方法.md]]
claudeMdExcludes 配置项允许开发者跳过不相关团队的子目录 CLAUDE.md。
Plugin 打包共享机制：Skills/Subagents/Hooks/Output Styles 可以打包为 Plugin 在团队和项目间共享。 [[raw/2026-06-19/Anthropic/调教 Claude Code 的七种方法.md|来源: 调教 Claude Code 的七种方法.md]]
Managed Settings：组织级强制管控，管理员部署的配置无法被个人配置排除。 [[raw/2026-06-19/Anthropic/调教 Claude Code 的七种方法.md|来源: 调教 Claude Code 的七种方法.md]]

Agent 与 ChatBot 的本质区别

Agent 和 ChatBot 的区别在于谁来构建上下文：ChatBot 靠人喂材料，Agent 会自己搜网页、读文档、调工具，把有用的内容写进上下文。因此对于 Agent，限定它在哪些步骤下能看到哪些东西——即上下文注入工程的精准控制——变得尤为重要。 [[raw/2026-06-20/金色传说大聪明/深入理解 Claude Code：从 CLAUDE.md 到 Hooks、Skills、Subagents…md|来源: 深入理解 Claude Code.md]]

CLAUDE.md 治理共识：从堆积到维护

此次摄入的多个来源独立指向同一结论：CLAUDE.md 膨胀是自然趋势，但膨胀导致 token 浪费和指令遵循率下降，必须主动治理。 [[raw/2026-06-19/Anthropic/调教 Claude Code 的七种方法.md|来源: 调教 Claude Code 的七种方法.md]] [[raw/2026-06-20/技术自由圈/阿里面试官：如何设计工业级 Skills 进化体系？一个工业级技能 Infra 底座如何设计？.md|来源: 工业级 Skills 进化体系.md]] [[raw/2026-06-20/金色传说大聪明/深入理解 Claude Code：从 CLAUDE.md 到 Hooks、Skills、Subagents…md|来源: 深入理解 Claude Code.md]]

治理共识要点：

核心不是写多好，而是判断什么该删：CLAUDE.md 是维护出来的不是写出来的。什么该下沉为 Skill、什么该上提到全局层、什么该直接删掉——这些判断比写作本身更重要。
分层治理原则：全局级（~/.claude/）、项目级（./CLAUDE.md）、子目录级、skill 级各管一段互不串味。放错层会导致个人偏好污染团队共享配置。
Rules 的路径限定（paths） 避免全局加载，无 path 限定的 Rule 等同于根目录 CLAUDE.md。
从历史 session 反向挖掘规则：翻最近 50 个 session -> 聚类规则候选 -> 对抗验证 -> 写进 CLAUDE.md。 [[raw/2026-06-20/金色传说大聪明/深入理解 Claude Code：从 CLAUDE.md 到 Hooks、Skills、Subagents…md|来源: 深入理解 Claude Code.md]]
官方建议：CLAUDE.md 控制在 200 行以内、指定 owner、像审代码一样审改动。 [[raw/2026-06-19/Anthropic/调教 Claude Code 的七种方法.md|来源: 调教 Claude Code 的七种方法.md]]
扶苏的实践补充：CLAUDE.md 保持 ~200 行聚焦项目级配置，所有编码知识下沉到 Skills（398 行前端 + 10 个资源文件，304 行后端 + 11 个资源文件），构建”small CLAUDE.md + detailed Skills”架构。 [[raw/2026-06-19/扶苏/Claude Code 深度实战：半年单兵重构 30 万行代码的硬核工程化指南.md|来源: 扶苏半年实战.md]]

Skill 设计方法论：从拆解工作流开始

设计哲学：不是从”AI 能做什么”出发，而是从”我是怎么干的”出发

设计 Skill 的核心能力不是懂 AI，而是会拆解自己的工作流程。 [[raw/2026-06-19/脸谱君/我是怎么设计出那套竞品分析Skill的：两个公式模型.md|来源: 我是怎么设计出那套竞品分析Skill的：两个公式模型.md]]

浅公式：五步法

适合个人快速草稿场景：定义目标 -> 拆解步骤（3-7步）-> 设计输入（必填/选填）-> 设定规则（必须/禁止/如果-那么）-> 测试调优。

深模型：COP-DRR 六环节框架

适用于团队交付和安全敏感场景：

Context：设定场景和约束
Objective：精确定义目标
Process：非线性流程，用状态机图替代线性步骤（含分支和循环回溯机制）
Decision：关键分支点的判断规则
Rule：三层规则金字塔
Red-teaming：对抗测试，至少 5 个对抗用例

规则系统三层金字塔

比平铺清单更可靠的分层结构： [[raw/2026-06-19/脸谱君/我是怎么设计出那套竞品分析Skill的：两个公式模型.md|来源: 我是怎么设计出那套竞品分析Skill的：两个公式模型.md]]

L1 硬约束：违反即任务失败（如”禁止依赖外部 API”）
L2 质量门禁：违反即降低质量分（如”每个来源必须有引用链接”）
L3 风格建议：违反不影响功能但降低可读性

浅版到深版的升级路径

脸谱君提出的三步升级法：加边界（10 分钟）-> 加决策（15 分钟）-> 加对抗测试（30 分钟）。从能用进化为可靠的分水岭是对抗测试（Red-teaming）。 [[raw/2026-06-19/脸谱君/我是怎么设计出那套竞品分析Skill的：两个公式模型.md|来源: 我是怎么设计出那套竞品分析Skill的：两个公式模型.md]]

Skill 的本质再确认

多个来源一致指出：Skill 不是提示词。Skill 是”跨任务可复用的程序性记忆”，与 Prompt 的”单次任务指令”有本质区别——Prompt 是死的，Skill 是活的。再具体说，.skll 文件本质上是按约定结构打包的文件集合（批量文件改后缀），核心是结构化内容而非提示词文本。 [[raw/2026-06-20/技术自由圈/阿里面试官：如何设计工业级 Skills 进化体系？一个工业级技能 Infra 底座如何设计？.md|来源: 工业级 Skills 进化体系.md]] [[raw/2026-06-20/金色传说大聪明/深入理解 Claude Code：从 CLAUDE.md 到 Hooks、Skills、Subagents…md|来源: 深入理解 Claude Code.md]]

扶苏的实践进一步深化了”Skill 就是文件夹”的概念：脚本附加到 Skill——不记录”如何测试”的文本说明，而是嵌入可执行脚本路径（如 node scripts/test-auth-route.js [url]），Claude 直接执行而非阅读文档。 [[raw/2026-06-19/扶苏/Claude Code 深度实战：半年单兵重构 30 万行代码的硬核工程化指南.md|来源: 扶苏半年实战.md]] 这与”确定性逻辑外置”的 Harness 原则一致——把验证步骤从”告诉模型怎么做”改为”让模型直接执行”。

工业级 Skill 基础设施：自进化架构

尼恩（技术自由圈）基于 Hermes Agent 架构，提出了完整的工业级 Skill 基础设施设计，代表了从个人 Skill 到平台级 Skill 治理的跃迁。 [[raw/2026-06-20/技术自由圈/阿里面试官：如何设计工业级 Skills 进化体系？一个工业级技能 Infra 底座如何设计？.md|来源: 工业级 Skills 进化体系.md]]

四层自进化架构

轨迹感知层：记录每次 Skill 执行的全过程。三大设计：脏计数器（Dirty Counter，按有效工具调用次数而非对话轮数触发复盘）、影子 Agent 舱壁隔离（六个维度：记忆隔离/递归防护/工具白名单/危险命令自动拒绝/前端输出隔离/日志隔离）、缓存继承（约 26% 端到端算力成本降低）。
技能蒸馏层：从轨迹中提取可复用的规则和模式
技能进化层（GEPA）：核心闭环——Generate（生成改进）-> Evaluate（评估效果）-> Patch（打补丁）-> Audit（回归审计）
技能治理层：四状态双向可逆状态机（active/stale/archived/pinned）及双向复活机制

六组件概念边界

组件	核心定位	解决问题	边界特征
Tool	能做	原子操作	可执行代码，无状态
Skill	会做	跨任务可复用流程	程序性记忆，有状态
Harness	不出事	安全边界与治理	上下文注入、审计、管控
MCP	远程工具互联	跨进程能力调用	标准化协议接口
Memory	笔记本	知识持久化	长短期记忆分层
Prompt	临时便签	单次指令	一次性的文本指令

边车文件模式（Sidecar Pattern）

Skill 内容与使用统计分离存储，原子替换 + 跨进程文件锁，实现运行时统计不影响 Skill 加载的隔离。

注册中心治理

Skill 注册中心的三层校验（Schema 校验 -> 安全扫描 -> 冲突检测）、四层召回机制、三层渐进式加载（L0 目录索引/L1 摘要索引/L2 完整内容）。

质量评估体系

五大质量评估指标覆盖：任务达成率、工具健康度、输出稳定性、人工干预率、Token 成本，每个维度含 42+ 细分指标的完整量化体系（含计算公式/优秀阈值/告警阈值/处置策略）。

OpenSpec 与规约驱动开发

Jameszyh 对 OpenSpec 的深度剖析揭示了一种与现有 SDD 范式根本不同的规约驱动开发路径： [[raw/2026-06-20/Jameszyh/OpenSpec 深度剖析：规约驱动开发的终极形态.md|来源: OpenSpec 深度剖析.md]]

核心创新：Delta Spec

OpenSpec 的最大创新是 Delta Spec——使用 ADDED/MODIFIED/REMOVED 三种操作原语（类似数据库的 WAL 写前日志）描述变更，而不是定义完整的规约。规约是涌现的，不是预设的——主规约从增量 Deltas 的持续积累中自然生长出来，而非事先定义完整。

矛盾：The ultimate SDD maturity is Spec-as-Source where spec becomes the sole truth source for code regeneration vs OpenSpec’s design philosophy says the main spec is “emergent, not predefined” — full specs are never the goal; incremental delta is the natural state 来自 [[raw/2026-06-20/Jameszyh/OpenSpec 深度剖析：规约驱动开发的终极形态.md|来源: OpenSpec 深度剖析.md]]

三大设计哲学

Spec as Contract（规约即契约）：规约是协作的刚性约定，不是辅助文档
Change as First-Class Citizen（变更是一等公民）：每次变更作为一个独立的”变更单元”（类似 Git 的提交），包含 proposal/specs/design/tasks 四个文件
Incremental over Full（增量优于完整）：接受不完美，通过 Delta 渐进完善

四大核心概念

Main Specs：按领域划分的当前真相源
Changes：每次变更包含四个文件（proposal/specs/design/tasks）
Delta Spec：变更原语（ADDED/MODIFIED/REMOVED）
config.yaml：项目元数据

关键操作：每个变更完成后，Archive 不是目录搬家而是真相源更新——将 Delta Specs 合并回主规约，系统通过这个过程持续演化其理解。

已知弱点

规约维护成本高，小改动显得笨重
缺乏跨服务编排能力
严重依赖团队工程文化——不是技术能解决的问题

Dynamic Workflows：从单线对话到并行编排

Dynamic Workflows 是 Claude Code 的最新能力，让 Claude 自己写编排脚本、协调多个 agent 并行工作。 [[raw/2026-06-20/金色传说大聪明/深入理解 Claude Code：从 CLAUDE.md 到 Hooks、Skills、Subagents…md|来源: 深入理解 Claude Code.md]]

要解决的问题

Agentic laziness（偷懒）：Agent 会跳过复杂步骤
Self-preferential bias（自我偏好）：Agent 倾向用自己的方式而非指定的方式做事
Goal drift（目标漂移）：长时间运行时逐步偏离原始目标

六种编排模式

Classify-and-act：先分类再执行
Fan-out-and-synthesize：多个 agent 并行工作，结果汇总
Adversarial verification：一个 agent 输出，另一个对抗性验证
Tournament：多个方案竞争，择优
Generate-and-filter：先生成再过滤
Loop until done：循环直到完成

三个核心函数

Agent(prompt, opts?)、parallel([fns])、pipeline(items, ...)——对应单 Agent 执行、并行扇出、串行流水线三种基础编排模式。

实际案例

Bun 从 Zig 重写到 Rust：每个修复跑一个 subagent 在独立 worktree 改，另一个 agent 对抗性 review。 [[raw/2026-06-20/金色传说大聪明/深入理解 Claude Code：从 CLAUDE.md 到 Hooks、Skills、Subagents…md|来源: 深入理解 Claude Code.md]]
40+ 小时的 SubAgent 集群运行（AGI Bar Drinking Plan）。

触发方式：跟 Claude 说”用一个 workflow”或触发词 ultracode。 [[raw/2026-06-20/金色传说大聪明/深入理解 Claude Code：从 CLAUDE.md 到 Hooks、Skills、Subagents…md|来源: 深入理解 Claude Code.md]]

Hooks 的八种事件

SessionStart、PreToolUse、PostToolUse、PermissionRequest、PreCompact、Stop、SubagentStop、UserPromptSubmit——覆盖 Agent 生命周期的关键节点。 [[raw/2026-06-20/金色传说大聪明/深入理解 Claude Code：从 CLAUDE.md 到 Hooks、Skills、Subagents…md|来源: 深入理解 Claude Code.md]]

机制选择决策框架

多个来源对”什么内容该放什么机制”形成了初步共识：

事实与规范（构建命令、编码规范、目录结构）-> CLAUDE.md（根目录）
局部约束（特定子目录或文件类型的规则）-> Rules + 路径限定（paths）
可复用工作流（需求澄清/PRD/Issue/TDD/诊断）-> Skills
隔离复杂任务（有独立上下文需求的任务）-> Subagents
确定性行为（代码检查、权限管控、文件生成）-> Hooks
角色与风格（响应格式、语气、编码指令覆盖）-> Output Styles（慎用）
跨会话与跨项目执行 -> Goal 模式（配套具体结果+可验证标准+边界约束+停止条件）
循环调度与轮询任务 -> /loop（定时驱动的外层循环）
目标驱动的自主完成 -> /goal（条件驱动的外层循环，明确 success_criteria + common_failure_modes + short_test）
运行闭环设计（终止条件、错误恢复、护栏配置）-> Loop Engineering 框架

跨平台链式工作流

Claude Code 和 Codex 之间形成了互补分工模式：Claude Code 做规划分析（/plan），Codex 做长线执行（/goal）。两个工具不再竞争而是互补。 [[raw/2026-06-20/Wise Wong/交了200刀的学费，我总结了Codex的15个技巧.md|来源: Codex 15个技巧.md]] [[raw/2026-06-20/万物构想/让你的 CC - Codex 无人值守：6 个可直接复用的 -goal 模板.md|来源: /goal 模板模式.md]]

矛盾与视角差异

矛盾：Matt Pocock 主张用户手动触发 Skill、AI 保持最小自主性，认为全自动流程剥夺控制权且难以排查错误 vs 尼恩主张工业级 Skill 系统应四层召回 + Harness 统一管控注入，通过置信度分层实现自动化（>0.85 自动加载），追求自进化闭环减少人工干预。前者代表”人类保持控制权”路线，后者代表”自动 Harness 管控”路线。 [[raw/2026-06-20/兔兔AGI/打造真实项目的 AI 编程环境：Matt Pocock 的 Skill 工作流完整上手攻略.md|来源: Matt Pocock Skill 工作流.md]] [[raw/2026-06-20/技术自由圈/阿里面试官：如何设计工业级 Skills 进化体系？一个工业级技能 Infra 底座如何设计？.md|来源: 工业级 Skills 进化体系.md]]

矛盾：Anthropic 官方强调 CLAUDE.md 是”全程加载、全程占 token”的高成本机制，建议精简至 200 行以内；但实践中 CLAUDE.md 有自然膨胀趋势（编码规范、项目约定、历史决策等不断堆积）——精简与完整之间存在根本性张力。 [[raw/2026-06-19/Anthropic/调教 Claude Code 的七种方法.md|来源: 调教 Claude Code 的七种方法.md]]

矛盾：Harness Engineering 是 Agent 编程的最终范式（现有 wiki 将 Harness 定位为第三次跃迁的终点） vs Loop Engineering 是 Harness 之后的第四次跃迁——Harness 是脚本思维，Loop 是系统思维来自 [[raw/2026-06-19/梦朝思夕/万字长文 - 带你由浅入深了解 Loop Engineering：从手动 Prompt 到设计系统的跃迁.md|来源: Loop Engineering 万字长文.md]] vs /loop vs /goal.md 持”新瓶装旧酒”视角，认为循环本身不新，新鲜的是名字，能力早就在往这个方向走了来自 [[raw/2026-06-17/Guide/面试官：‘你说你懂 Loop Engineering，那 Claude Code 的 -loop 和 -goal 区别是什么？‘我：‘这是啥？‘.md|来源: /loop vs /goal.md]]

矛盾：OpenSpec 主张”规约是涌现的，不是预设的”——完整规约从来不是目标，增量 Delta 是自然状态 vs 现有 SDD 成熟度模型的 Spec-as-Source 阶段假设完整规约是最高目标。两种规约驱动开发哲学在预设程度、增量粒度、适用场景上根本不同。 [[raw/2026-06-20/Jameszyh/OpenSpec 深度剖析：规约驱动开发的终极形态.md|来源: OpenSpec 深度剖析.md]]

矛盾：“模型变笨了”是 AI 社区的常见抱怨 vs 扶苏的实战结论：Claude Code 实际在持续进步，输出质量下降通常是由提示词质量退化导致的，而非模型回退来自 [[raw/2026-06-19/扶苏/Claude Code 深度实战：半年单兵重构 30 万行代码的硬核工程化指南.md|来源: 扶苏半年实战.md]]

多 Agent 架构三条路线

多 Agent 协作存在三种根本不同的架构哲学，尚无收敛趋势——说明”it depends”而非存在通用最佳实践：

单 Agent + 能力模块（Hermes/得物路线）：一个主 Agent，通过工具/MCP/模块扩展能力边界
多 Agent 组织层级（AgentTeams CRDs 路线）：用 CRD 定义角色和层级关系，形成类组织结构的协作模式
单 Agent + Hooks + 专项 Subagents（扶苏路线）：主 Agent 通过 Hooks 驱动的自动化流程和按需调用的 Subagents 完成治理

实践落地：AI 热点 Skill

数字生命卡兹克发布的 AI 热点 Skill 是一个具体落地案例——把 AI 新闻监控这个高频需求封装成可加载的 Skill，让 agent 自动追踪和摘要最新动态。这说明 Superpowers/Skills 的价值不仅在编程场景，在信息获取领域同样适用。 [[raw/2026-05-08/数字生命卡兹克/装了这个AI热点Skill之后，你再也不需要自己去刷AI新闻了。.md|来源: AI热点Skill]]

Matt Pocock 的 Skills 工作流则从工程实践角度开辟了另一条路径：/grill-with-docs -> /to-prd -> /to-issues -> /tdd -> /diagnose -> /improve-codebase-architecture 构成了端到端的 AI 编程治理流水线。其核心理念是”垂直切片”——Issue 按用户可感知行为拆而非按文件拆，每个可独立验收。 [[raw/2026-06-20/兔兔AGI/打造真实项目的 AI 编程环境：Matt Pocock 的 Skill 工作流完整上手攻略.md|来源: Matt Pocock Skill 工作流.md]]

Matt Pocock Skills 与 GSD/BMAD/Spec-Kit/Superpowers 四种主流 AI 编程工作流形成选型对比：没有绝对优劣，取决于项目阶段和团队需求——Matt 适合质量敏感的中大型项目，Superpowers 适合系统化治理的团队，GSD 适合快速原型阶段。 [[raw/2026-06-20/兔兔AGI/打造真实项目的 AI 编程环境：Matt Pocock 的 Skill 工作流完整上手攻略.md|来源: Matt Pocock Skill 工作流.md]]

2026-07 更新：风险分层，而不是全套照搬

新资料对 Superpowers/Matt Pocock skills 的态度更克制：这套流程能把 agent 从乱写带回工程纪律，但如果无脑全量启用，会把简单任务拖成仪式。正确用法是按风险分层：低风险小改走轻量验证，高风险跨模块改动才上完整 brainstorming、plan、TDD、review、finishing。[[raw/2026-06-27/烨笙/Superpowers不再是最佳实践：2026年你该换个思路了.md|来源: Superpowers 反思]] [[raw/2026-06-26/AI养虾日记/Matt Pocock skills：把软件工程基本功装进 AI 对话.md|来源: Matt Pocock skills]]

Superpowers 的价值不是”更多步骤”，而是把软件工程基本功显式化：澄清需求、先写验收、测试驱动、验证后完成、代码审查、收尾归档。对不成熟 agent，这些步骤是护栏；对成熟团队，应该沉淀为 repo-local contracts 和脚本，而不是每次靠对话背诵。[[raw/2026-06-26/AI养虾日记/Matt Pocock skills：把软件工程基本功装进 AI 对话.md|来源: 软件工程基本功]]