code-yangzz 1.0.0

package/skills/meta-theory/references/intent-amplification.md

@@ -0,0 +1,190 @@
+# 意图放大 — 完整参考
+
+> 来源：meta.md 第八部分启发7（第882-896行）+ 第九部分总纲，老金直播口播提炼
+
+## 核心命题
+
+**高层意图被结构性展开后的结果。不是一个人把所有事做完，而是一个意图通过组织结构被逐层放大成系统级产出。**
+
+> **同一意图，不该只有一种表达方式。成熟系统应该按触点、角色、上下文，换壳不换核。**
+
+---
+
+## 意图核 + 交付壳模型
+
+### 意图核（不变）
+
+意图核是底层目标/信息/决策，不随交付形式改变。
+
+示例：
+- "用户认证系统需要Token刷新机制" — 这是意图核
+- "当前进度落后预期 20%" — 这是意图核
+- "Genesis 产出的 SOUL.md 缺少 Decision Rules" — 这是意图核
+
+### 交付壳（按场景换）
+
+交付壳是意图核在不同场景下的包装形式。同一个意图核，交付给不同受众时，壳不同。
+
+示例 — 同一意图核"Token刷新机制需要实现"：
+
+| 受众 | 交付壳 |
+|------|-------|
+| CEO | "认证模块还差一个安全关键功能，预计增加 2 天工期" |
+| 开发者 | "需要实现 `refreshToken()` 函数，JWT 过期前 5 分钟触发，详见 API 设计文档" |
+| 用户 | "登录状态将自动保持，无需重复登录" |
+
+---
+
+## 壳选择4维度
+
+### 维度矩阵
+
+| 维度 | 选项 | 影响 |
+|------|------|------|
+| **受众角色** | CEO / 开发者 / 用户 / 审查员 | 决定抽象层级和专业深度 |
+| **触点类型** | 文档 / 对话 / 通知 / 报告 | 决定格式和详细程度 |
+| **上下文密度** | 首次 / 复查 / 紧急 | 决定上下文铺垫量 |
+| **注意力预算** | 高 / 中 / 低 | 决定信息密度和长度 |
+
+### 壳选择决策表
+
+```
+selectDeliveryShell(card, audience, context):
+
+  IF audience = CEO:
+    → 高抽象、重结论、附决策建议
+    → 格式：摘要 + 关键数据 + 建议行动
+
+  IF audience = 开发者:
+    → 低抽象、重实现细节、附代码引用
+    → 格式：技术说明 + 文件路径 + 代码片段
+
+  IF audience = 审查员:
+    → 中等抽象、重证据链、附断言验证
+    → 格式：断言 + 证据 + 判定
+
+  THEN 叠加上下文密度调整:
+    IF 首次 → 补充背景说明
+    IF 复查 → 只给差异和变化
+    IF 紧急 → 只给结论和行动项
+
+  THEN 叠加注意力预算调整:
+    IF 高 → 完整详细输出
+    IF 中 → 核心内容 + 可展开链接
+    IF 低 → 一句话摘要
+```
+
+---
+
+## 出牌成本与壳的关系
+
+壳选择直接影响出牌成本：
+
+| 壳类型 | 注意力成本 | 适用场景 |
+|--------|-----------|---------|
+| 一句话摘要 | low | 低注意力预算、信息确认 |
+| 结构化报告 | mid | 中等预算、需要全面了解 |
+| 完整技术文档 | high | 高预算、首次深入理解 |
+| 差异增量 | low | 复查场景、只看变化 |
+| 决策建议 | mid | CEO场景、需要行动指引 |
+
+**与节奏编排的对接**：每张牌出牌时，Conductor 根据当前受众和上下文选择交付壳，控制注意力成本。
+
+---
+
+## 5维进化放大操作
+
+进化检测不是终点。检测结果必须转化为结构性的放大操作，让系统通过每次执行变得更强。
+
+### 维度1：模式复用 → 提取放大
+
+| 检测结果 | 放大操作 | 执行者 |
+|---------|---------|--------|
+| 发现可复用的代码模式 | 提取为 Skill → 注册到 Artisan 候选池 | Artisan |
+| 发现可复用的工作流模式 | 提取为编排模板 → 注册到 Conductor 模板库 | Conductor |
+| 发现可复用的审查模式 | 提取为断言模板 → 注册到 Prism 签名库 | Prism |
+
+### 维度2：agent边界 → 结构放大
+
+| 检测结果 | 放大操作 | 执行者 |
+|---------|---------|--------|
+| agent 职责膨胀（>2域） | 触发拆分 → 走类型B创建流水线 | Warden |
+| agent 过于碎片化 | 触发合并 → 重新分组 | Warden |
+| 5标准仍全部PASS | 维持现状，记录验证快照 | Prism |
+
+### 维度3：引导优化 → 交互放大
+
+| 检测结果 | 放大操作 | 执行者 |
+|---------|---------|--------|
+| 追问轮数 >2 | 优化引导牌触发条件 → 预设常见意图模板 | Conductor |
+| 用户需提供过多上下文 | 增强记忆策略 → 自动从历史补全 | Librarian |
+| 误解率 >0 | 更新 Decision Rules → 增加歧义消解规则 | Genesis |
+
+### 维度4：流程瓶颈 → 效率放大
+
+| 检测结果 | 放大操作 | 执行者 |
+|---------|---------|--------|
+| 某步骤耗时最长 | 分析原因 → 增加��行或预计算 | Conductor |
+| 某步骤失败率最高 | 增加前置检查 → 或降级为更简单的替代方案 | Sentinel |
+| 串行浪费 | 标记可并行步骤 → 更新牌组依赖关系 | Conductor |
+
+### 维度5：能力覆盖 → 规模放大
+
+| 检测结果 | 放大操作 | 执行者 |
+|---------|---------|--------|
+| 发现新能力缺口 | 创建新元/Skill → 或调用 Scout 搜索外部工具 | Scout/Genesis |
+| 工具/Skill缺失 | 触发 Scout 扫描 → ROI 评估 → 引入决策 | Scout |
+| 知识缺失 | 添加到记忆/references → 更新 Librarian 索引 | Librarian |
+
+---
+
+## Warden 的意图放大审查
+
+Warden 在综合报告环节需要检查意图放大质量：
+
+### CEO报告壳适配检查
+
+| 检查项 | 方法 | 不通过处理 |
+|--------|------|-----------|
+| 报告是否按受众调整了抽象层级？ | CEO报告不应包含代码片段或文件路径 | 要求重写，提高抽象层级 |
+| 关键结论是否前置？ | 第一段必须包含核心结论 | 调整结构，结论前置 |
+| 是否附带决策建议？ | CEO需要可行动的建议，不只是信息 | 补充"建议行动"段 |
+| 信息密度是否匹配注意力预算？ | CEO预算通常为"中" | 删减细节，保留核心 |
+
+### 跨受众一致性检查
+
+同一意图核交付给不同受众���：
+- 核心信息必须一致（不能给CEO说进度正常，给开发者说进度延迟）
+- 只有壳的形式不同，不是内容矛盾
+- 如果发现矛盾 → 回溯意图核，确认事实后统一
+
+---
+
+## 意图放大与其他主线的关系
+
+```
+元(拆)
+  ↓ 提供：可独立交付的最小单位
+组织镜像(组)
+  ↓ 提供：分层的受众结构（CEO/中层/执行层）
+节奏编排(发)
+  ↓ 提供：出牌时机和注意力预算
+意图放大(成) ← 本层
+  ↓ 产出：按受众、触点、上下文适配的结构化交付
+```
+
+意图放大是四条主线的终点——前三层的所有工作，最终都要通过意图放大转化为有效的系统级产出。
+
+---
+
+## 场景示例
+
+### 场景：安全漏洞修复完成
+
+**意图核**：XSS 漏洞已修复，影响范围 3 个页��，需要验证。
+
+| 受众 | 交付壳 |
+|------|-------|
+| CEO | "安全关键修复完成，3个面向用户的页面已加固。建议行动：安排一次安全审查确认。" |
+| 开发者 | "修复了 `pages/profile.tsx:42`、`pages/settings.tsx:88`、`pages/dashboard.tsx:156` 的 XSS 漏洞。使用 DOMPurify sanitize 用户输入。需要 code review + 回归测试。" |
+| 审查员 | "断言：所有用户输入路径已做 sanitize。证据：3 处 innerHTML 替换为 DOMPurify.sanitize()。验证方法：注入 `<script>alert(1)</script>` 测试。" |

package/skills/meta-theory/references/meta-theory.md

@@ -0,0 +1,346 @@
+# 元理论方法论 — 完整参考
+
+## 四条主线（核心框架）
+
+整个元方法论的终极框架：
+
+```
+元(拆) → 组织镜像(组) → 节奏编排(发) → 意图放大(成)
+```
+
+| 层 | 解决什么 | 核心问题 |
+|----|---------|---------|
+| **元** | 怎么拆 | 系统该拆到什么粒度，才能既做事又治理？ |
+| **组织镜像** | 怎么组 | 拆出来的元怎么形成有结构的组织？ |
+| **节奏编排** | 怎么发 | 组织怎么优雅地出牌，而不是一股脑倾泻？ |
+| **意图放大** | 怎么成 | 高层意图怎么被结构性展开成系统级结果？ |
+
+> 前两层解决"系统怎么成立"，后两层解决"系统怎么优雅地运行"。
+
+### 四条主线的依赖关系
+
+```
+元(拆)      ← 基础层：没有元，后面全是空中楼阁
+  ↓
+组织镜像(组) ← 结构层：元必须被组织才能协作
+  ↓
+节奏编排(发) ← 运行层：组织必须有节奏才不会过载
+  ↓
+意图放大(成) ← 产出层：节奏控制下的结构化产出
+```
+
+**深入参考**：
+- 节奏编排详见 → `references/rhythm-orchestration.md`
+- 意图放大详见 → `references/intent-amplification.md`
+- 十步治理详见 → `references/ten-step-governance.md`
+
+---
+
+## 元 = 最小可治理单元
+
+### 5标准
+
+**元 = 最小可治理单元**，必须满足5标准：
+1. **独立** — 可单独理解、调用、产出
+2. **足够小** — 再拆无意义或成本反噬
+3. **边界清晰** — 明确"只管"和"不碰"
+4. **可替换** — 换掉不塌，能升级/重组
+5. **可复用** — 跨场景有用，非一次性
+
+### 四种死法
+
+| 死法 | 症状 | 诊断 |
+|------|------|------|
+| **一锅炖** | 一个agent什么都能干 | >2不相关域？SOUL.md>300行？ |
+| **碎成渣** | agent太多太碎 | 需要其他agent输出才能产出？ |
+| **只有执行没有治理** | 只有方向→规划→执行，没有评审→验证→进化 | 谁评审？谁评审评审者？修完谁验证？经验怎么沉淀？ |
+| **只追结果不做结构** | 一次跑通就当圣经 | 明天还能跑通吗？别人接手能跑通吗？模型一换能适配吗？ |
+
+> 死法一二是拆分层面的极端；死法三四是治理层面的缺失。
+> 前两种让系统"站不住"，后两种让系统"长不大"。
+
+### 拆分的黄金区间
+
+**既足够小，又足够完整；既能独立存在，又能进入协作；既能承担职责，又不会把整个系统拖死。**
+
+判定方法：
+- 再往下拆，治理成本开始反噬 → 到了下界
+- 再往上合，职责开始串味 → 到了上界
+- 两者之间就是黄金区间
+
+### 三层架构
+
+| 层级 | 职责 | 示例 |
+|------|------|------|
+| 执行元 | 直接干业务，职责要纯 | Frontend, Backend, Quality |
+| 编排元 | 调度作战，决定谁先谁后 | Commander, meta-conductor |
+| 基础设施元 | 修路搭桥，造能力而非做事 | 记忆/技能/工具/规则/权限/安全 |
+
+> **有些元，不是做事的元，而是造能力的元。**
+
+执行元在前线打仗。编排元在调度作战。基础设施元在修机场、修道路、送弹药、定规则。
+
+---
+
+## 入口元（Entry Agent）
+
+### 定义
+
+**每个项目必须有且只有一个入口元。**
+
+入口元 = 用户第一个见到的 agent = 把用户意图转译成可执行任务包的那个人。
+
+入口元不是"先后创建顺序"问题，而是"入口集中"问题——用户只和一个人说话，不是一堆 agent 轮番轰炸。
+
+### 入口元 vs 其他元
+
+| 维度 | 入口元 | 其他元 |
+|------|--------|---------|
+| **入口** | 用户直接对话 | 由入口元 spawn/路由 |
+| **职责** | 意图转译 + 任务路由 + 节奏控制 | 直接执行具体任务 |
+| **边界** | "只管"用户可见层 | "只管"内部执行层 |
+| **数量** | 每个项目仅 1 个 | 每个项目 N 个 |
+
+### 入口元的职责
+
+入口元承担以下职责，其他 agent 不碰：
+
+| 职责 | 说明 |
+|------|------|
+| **意图转译** | 把模糊需求追问成具体任务 |
+| **任务路由** | 判断任务该路由给哪个执行元 |
+| **节奏控制** | 决定什么时候给什么、什么时候沉默 |
+| **守门把关** | 阻断越界（Frontend 改了 API？立即打回） |
+| **统一汇总** | 汇总只从入口元出，执行元不直接对用户 |
+
+### 入口元的产出
+
+入口元的产出物 = 其他人看到的唯一声音：
+
+```
+[结构化需求文档]
+  ↓
+[任务拆解 + agent 路由]
+  ↓
+[自治执行 + 自动评审]
+  ↓
+[统一变更汇总]  ← 用户只看这一层
+```
+
+### 项目规模 vs 入口元名字
+
+| 项目规模 | 入口元名字 | 层级 | 特征 |
+|---------|-----------|------|------|
+| **单项目** | Commander | 项目执行层 | 需求引导 + 任务分解 + agent 调度 |
+| **多部门协作系统** | Warden | 元架构层 | 协调 + 仲裁 + 最终合成 |
+| **通用模板** | Manager | 通用入口 | 意图理解 + 任务规划 + 结果交付 |
+
+### 入口元的核心原则
+
+1. **用户只看到一个声音** — 所有输出统一从入口元出，执行元不抢话
+2. **入口元不写代码** — 编排元的产出是计划和调度，不是代码
+3. **入口元是守门员** — 任何越界变更必须被阻断
+4. **入口元决定节奏** — 什么时候推进、什么时候留白、什么时候打断用户
+
+> **没有入口元的系统 = 用户面对一群七嘴八舌的 agent = 认知过载**
+
+### 入口元在组织镜像中的位置
+
+入口元是组织镜像的"用户接口层"：
+
+```
+用户 ──→ 入口元 ──→ 执行元(们) ──→ 治理元 ──→ 用户
+            ↑
+         意图转译
+         任务路由
+         节奏控制
+         守门把关
+```
+
+---
+
+## 组织镜像
+
+### 定义
+
+组织镜像不是修辞，是架构方法——把真实组织的机制映射到多智能体系统：
+
+| 机制 | 组织中 | AI系统中 |
+|------|--------|---------|
+| 层级委派 | 高层→中层→执行层 | CEO→Warden→执行agent |
+| 职责分工 | 岗位职责说明书 | SOUL.md + "只管/不碰"边界 |
+| 独立工作空间 | 各部门独立办公 | 每个agent独立上下文 |
+| 评审反馈 | 质检+绩效考核 | Review + Meta-Review |
+| 持续进化 | 复盘+培训+升级 | Evolution + 记忆沉淀 |
+
+### 三个老问题（不用组织镜像会踩的坑）
+
+| 问题 | 症状 | 根因 |
+|------|------|------|
+| **串味** | A领域的东西跑进B领域 | 元之间共享上下文，没有隔离 |
+| **协调爆炸** | 角色一多，链路打结 | 平铺互发消息，没有层级结构 |
+| **认知成本高** | 设计者要手搓每个交互 | 没有现实映射的抽象，人在伺候系统 |
+
+> **协同可以扁平，治理不能缺位。平等不等于无序。**
+
+---
+
+## 节奏编排（概要）
+
+### 定义
+
+编排不只是流程编排（谁先谁后），还包括节奏编排（什么时候给什么、什么时候不给）。
+
+### 核心原则
+
+> **告诉用户某件事���是有成本的。**
+
+- 给用户一条建议，有成本
+- 给系统加一个待办，有成本
+- 给Agent多塞一个目标，有成本
+- 给用户多推一个任务，有成本
+
+每多说一件事，它就和前面那些事形成竞争。用户/组织/系统的注意力、带宽、吞吐都是有限的。
+
+> **成熟系统不是知道的都说，而是知道什么时候说最值钱。**
+
+### 事件牌组
+
+事件牌组是节奏编排的具体实现机制。表面给自由，底层保留理想顺序。
+
+| 牌 | 触发条件 | 动作 | 设计哲学 |
+|----|---------|------|---------|
+| **澄清牌** | 需求模糊 | 追问2轮，明确要改什么 | 信息不足时先收集再行动 |
+| **范围收缩牌** | 仓库太大/文件太多/同名冲突 | 先把边界缩小到可处理范围 | 环境复杂度变高时继续冲会误改 |
+| **方案牌** | 需求清晰但有多条路径 | 把路线摆出来，好处/代价/该选哪条 | 复杂问题不能一口吞，先给路线再动手 |
+| **执行牌** | 规划完成，风险可控 | 分配到具体元，真正动代码 | 有计划才执行 |
+| **校验牌** | 执行完成 | 编译/类型/依赖/需求对齐 | 第一次做出来不等于做对 |
+| **修复牌** | 校验不通过 | 重新修正，不要装作已完成 | 修到过为止，设上限防死循环 |
+| **回滚牌** | 风险超预期或影响范围扩大 | 退回到上一个稳定状态 | 不要硬顶，能退回来才是成熟系统 |
+| **风险牌** | 牵扯公共组件/鉴权/全局逻辑/多人协作 | 把风险抬到台面上，必要时插队 | 关键状态落后于预期，安全/权限/全局影响优先 |
+| **建议牌** | 系统发现用户卡住但不需要太重打断 | 给一个更低成本的下一步推进动作 | 非紧急，但值得给一个方向 |
+| **留白牌** | 连续完成/需消化/≥3连续高成本牌 | 暂停推送，给简短状态总结 | 空白本身也是被设计的体验，什么都不做可能是最优动作 |
+
+### 三个内部机制
+
+这三个机制是 Conductor 的内部能力，不是独立 agent（不满足元的5标准）：
+
+| 机制 | 触发条件 | 行为 |
+|------|---------|------|
+| **留白机制** | 连续 ≥3 轮高成本牌 | 暂停推送，给简短状态总结 |
+| **回滚机制** | 风险超预期或影响范围扩大 | 退回到上一个稳定状态，重新评估范围 |
+| **紧急治理机制** | Sentinel 安全警报 / Prism 严重质量漂移 | 暂停当前牌组，风险牌提升到队首 |
+| **发牌接口** | 每张牌出牌时 | 选择最优交付通道（直接回复/写入文件/spawn子代理/等待用户操作） |
+
+> 详见 `references/rhythm-orchestration.md`
+
+---
+
+## 意图放大（概要）
+
+### 定义
+
+高层意图被结构性展开后的结果。不是一个人把所有事做完，而是一个意图通过组织结构被逐层放大成系统级产出。
+
+### 意图核 + 交付壳模型
+
+> **同一意图，不该只有一种表达方式。成熟系统应该按触点、角色、上下文，换壳不换核。**
+
+- **意图核**（不变）：底层目标/信息/决策
+- **交付壳**（按场景换）：不同角色、不同触点、不同界面、不同形式的交付包装
+
+壳选择4维度：
+1. **受众角色** — CEO / 开发者 / 用户
+2. **触点类型** — 文档 / 对话 / 通知
+3. **上下文密度** — 首次 / 复查 / 紧急
+4. **注意力预算** — 高 / 中 / 低
+
+> 详见 `references/intent-amplification.md`
+
+### 5维度进化检测
+
+| 维度 | 检测什么 | 通过标准 |
+|------|---------|---------|
+| **模式复用** | 这次的解法能不能抽象成可复用模式？ | 有明确的可复用组件/模板/规则 |
+| **agent边界** | 现有agent边界还合理吗？需要拆/合？ | 5标准仍全部PASS |
+| **引导优化** | 用户交互路径能不能更短更顺？ | 减少追问轮数或简化输入 |
+| **流程瓶颈** | 哪一步最慢/最容易出错？ | 识别并有改进方案 |
+| **能力覆盖** | 有没有发现新的能力缺口？ | 缺口已记录或已触发创建流水线 |
+
+### 5维进化放大操作
+
+检测不是终点，检测结果必须转化为结构性操作：
+
+| 维度 | 检测结果 | 放大操作 |
+|------|---------|---------|
+| 模式复用 | 发现可复用模式 | → 提取为 Skill/模板 → 注册到 Artisan 候选池 |
+| agent边界 | 发现边界不合理 | → 触发拆分/合并 → 走类型B创建流水线 |
+| 引导优化 | 发现交互路径冗余 | → 更新引导牌触发条件 → 优化追问策略 |
+| 流程瓶颈 | 发现瓶颈环节 | → 调整牌组优先级 → 增加并行或跳过条件 |
+| 能力覆盖 | 发现能力缺口 | → 创建新元/Skill → 或调用 Scout 搜索外部工具 |
+
+> 详见 `references/intent-amplification.md`
+
+---
+
+## 十步治理（概要）
+
+| 步骤 | 说明 | 执行者 | 关键问题 |
+|------|------|--------|---------|
+| 1. 方向 | 需求分析 | Warden/用户 | 意图是什么？ |
+| 2. 规划 | 任务拆解 | Conductor | 元怎么拆？ |
+| 3. 执行 | 搜索 + 执行 | 执行元 | 谁��干？ |
+| 4. 评审 | 质量评审 | Prism | 做对了吗？ |
+| 5. 元评审 | 越界检测 | Warden审Prism | 评审者看偏了吗？ |
+| 6. 修订 | 修复问题 | 执行元 | 怎么改？ |
+| 7. 验证 | 重新评审 | Prism | 改好了吗？不是自我感动？ |
+| 8. 汇总 | 总结产出 | Warden | 学到了什么？ |
+| 9. 反馈 | 用户确认 | 用户/CEO | 用户满意吗？ |
+| 10. 进化 | 5维度检测 | 全员 | 下次怎么更强？ |
+
+> 前三步是"会动"，后七步是"成熟"。
+> 没有评审，只会冲。没有验证，只会演。没有进化，只会重复犯错。
+
+### 复杂度路由
+
+| 复杂度 | 判定 | 执行步骤 |
+|--------|------|---------|
+| 简单 | <2 文件 | 1→3→4→7→9（跳过元评审） |
+| 中等 | 2-5 文件 | 1→2→3→4→5→6→7→9 |
+| 复杂 | >5 文件/多模块 | 全部10步 |
+
+> 详见 `references/ten-step-governance.md`
+
+---
+
+## 8模块SOUL设计
+
+| # | 模块 | 作用 | 质量标准 |
+|---|------|------|---------|
+| 1 | Core Truths | 行为锚点，定义agent的核心信念 | ≥3条，具体到该领域 |
+| 2 | Role + Core Work | 角色定义和核心职责 | 有明确的"只管/不碰"边界 |
+| 3 | Decision Rules | 决策规则，遇到选择怎么办 | ≥3条if/then规则 |
+| 4 | Thinking Framework | 思维框架，怎么思考问题 | 有领域特定的分析步骤 |
+| 5 | Anti-AI-Slop | 反AI套话规则 | 有该领域的具体套话检测信号 |
+| 6 | Output Quality | 输出质量标准 | 有可验证的质量门槛 |
+| 7 | Deliverable Flow | 交付流程 | 有清晰的input→process→output |
+| 8 | Meta-Skills | 元能力，自我提升方向 | ≥2个学习/改进方向 |
+
+## 质量评级
+
+| 级别 | 标准 | 处置 |
+|------|------|------|
+| **S** | 独特洞察、硬数据、可直接执行、不可替换 | → 通过 |
+| **A** | 覆盖完整、有具体数据、中等洞察深度 | → 通过 |
+| **B** | 结构完整但缺具体案例/数据引用 | → 修订 |
+| **C** | 套话多、高可替换性、无具体计划 | → 修订 |
+| **D** | AI模板输出、零思考证据 | → 重做 |
+
+## AI-Slop检测
+
+| 信号 | 检测方法 | 判定 |
+|------|---------|------|
+| 套话密度 | 计数"综上所述/值得注意/总而言之" | >0即扣分 |
+| 具体性缺失 | 检查是否引用了具体文件/函数/数据 | 无具体引用 = 不及格 |
+| 可替换性 | 把Agent名换成竞品 | 仍成立 = 无深度 |
+| 并列堆砌 | 5+条建议每条不到2句 | 检出 = 肤浅 |