菜单
积木式能力验证方法论——判断「直接做 vs 先验证」、将不确定性分层隔离、沉淀可复用能力资产。触发场景：(1) 讨论技术可行性或方案选型，(2) 评估某个实现的不确定性，(3) 决定直接集成 vs 先做 Demo 验证，(4) 分析能力复用或知识沉淀策略，(5) 用户说"积木"、"Demo"、"能力验证"、"不确定性"
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
| name | ddemo |
| description | 积木式能力验证方法论——判断「直接做 vs 先验证」、将不确定性分层隔离、沉淀可复用能力资产。触发场景：(1) 讨论技术可行性或方案选型，(2) 评估某个实现的不确定性，(3) 决定直接集成 vs 先做 Demo 验证，(4) 分析能力复用或知识沉淀策略，(5) 用户说"积木"、"Demo"、"能力验证"、"不确定性" |
| argument-hint | [Demo名称] [不确定性类型] [Layer1功能] |
| context | fork |
| agent | general-purpose |
| allowed-tools | ["Read","Bash","Write","Edit","WebSearch","Grep","Glob"] |
积木式能力验证方法论：最小成本验证，最高效率复用。
所有产品开发可归为两类，构建策略截然不同：
| 类型 | 特征 | 核心工作 | 不确定性来源 | 示例 |
|---|---|---|---|---|
| 业务编排型 | 80% 是拼接已有能力 | 流程设计、数据建模、UI 组装 | 需求理解（做什么） | CRM、ERP、电商后台 |
| 能力构建型 | 核心能力需从零验证 | 能力验证、效果调优、边界探索 | 技术可行性（能不能做、效果稳不稳） | AI 产品、算法驱动产品 |
判断方法：项目中是否存在"做了才知道行不行"的部分？
混合型产品（常见）：整体是业务编排，但某些模块属于能力构建。只对不可预期的部分做能力验证，其余直接实现。
比例参考：通常产品中不确定性工作占 20-40%（因产品而异）。Demo 覆盖的是产品中最关键、最有风险的少数部分，而非全部工作。
将能力验证组织为三层递进结构，每层解决不同粒度的不确定性：
产品积木（完整功能模块）
├── 组合积木（多能力集成）
│ ├── 原子积木 A（单一能力 Demo）
│ └── 原子积木 B（单一能力 Demo）
└── 组合积木（多能力集成）
├── 原子积木 C
└── 原子积木 D
最小粒度的能力验证单元。一个原子积木 = 一个隔离的 Demo，验证单一不确定性。
核心特征：一句话说清、换产品能用、独立可运行。
正例：prompt-citation-stability（Prompt 能否稳定输出引用标记格式）
反例：hera-meeting-citation（绑定了产品名，换项目不可用）
多个原子积木的集成验证。解决"各自能跑但组合起来未测过"的集成风险。
触发条件：两个以上已验证通过的原子积木需要协同工作时。 验证重点：数据流衔接、接口适配、性能叠加效应。
从能力到功能的最后一公里。将已验证的组合积木包装为用户可用的完整功能模块。
此时不确定性已消除，工作重心转向产品化：UI 设计、错误处理、配置管理。
识别不确定性的类型，决定验证策略：
| 类型 | 判断依据 | 验证重点 | 示例 |
|---|---|---|---|
| 能力缺口 | 团队从没做过这件事 | 能否跑通基本流程 | 第一次接入 TTS API |
| 结果不可预期 | 做了但不知道效果如何 | 输出的稳定性和质量 | Prompt 能否稳定输出指定格式 |
| 方法未验证 | 知道目标但路径不确定 | 方法是否可行且可重复 | 运营 SOP 能否跑通 |
| 集成风险 | 各自能跑但组合未测过 | 组合后的数据流和性能 | 三个模块集成后的端到端表现 |
应用方式：确定类型后，验证资产的设计才有方向——能力缺口需要最小可运行示例，结果不可预期需要多组测试 case，集成风险需要端到端数据流测试。
在投入验证之前，先确认验证的是"能力"而非"功能"：
判断问题：换一个产品，这个验证还能用吗？
| 能力（继续验证） | 功能（重新定义） | |
|---|---|---|
| 定义 | 可跨产品复用的技术能力 | 绑定特定产品的业务逻辑 |
| 示例 | SSE 流式推送、Prompt 稳定输出格式 | Hera 的聊天页面、订单详情展示 |
| 价值 | 验证一次，多处复用 | 只在当前产品有意义 |
剥离方法：把产品特定部分去掉，找到底层能力。
能力验证的产出不只是代码。四类资产各有沉淀价值：
| 资产类型 | 内容 | 复用方式 | 示例 |
|---|---|---|---|
| 代码资产 | 可运行的代码片段、SDK 封装、工具函数 | 直接引用或 fork | SSE 客户端实现、音频格式转换函数 |
| Prompt 资产 | 经过验证的 Prompt 模板及其测试 case | 复制 + 微调 | 引用标记提取 Prompt v3（准确率 95%） |
| 方案资产 | 技术选型结论、架构决策、对比分析 | 参考决策依据 | "WebSocket vs SSE"对比及选型理由 |
| 方法论资产 | 可复用的工作方法、SOP、评估框架 | 套用到新场景 | LLM 输出质量评估的 5 步流程 |
沉淀原则：每次验证结束后，至少产出一类资产。代码类验证产出代码 + 方案资产；Prompt 类验证产出 Prompt + 方法论资产。
每个 Demo 的 README.md 包含七个标准章节，确保知识完整沉淀：
| # | 章节 | 内容 | 何时填写 |
|---|---|---|---|
| 1 | 解决什么问题 | 从能力定义直接取 | 创建时 |
| 2 | 核心方案 | 最终采用的技术方案 | 验证后 |
| 3 | 验证结果 | 量化数据（对照通过标准） | 验证后 |
| 4 | 已知限制 | 能力边界、未覆盖场景 | 验证后 |
| 5 | 集成注意事项 | 依赖版本、配置差异、接口适配 | 创建时（从规格文档复制） |
| 6 | 怎么复用 | 复用路径、需要调整的部分 | 验证后 |
| 7 | 踩过的坑 | 踩坑记录、解决方法 | 验证后 |
Demo 不仅验证自有想法，还是吸收外部知识的标准化入口。
| 来源 | 吸收方式 | 产出 |
|---|---|---|
| 开源项目 | 提取核心能力，剥离项目特定部分，封装为原子积木 | 代码资产 + 方案资产 |
| 论文/技术博客 | 将理论方法转化为可执行的验证 case | 方法论资产 + 代码资产 |
| 竞品分析 | 逆向推断能力实现路径，验证可复现性 | 方案资产 |
| 团队经验 | 将隐性知识显性化为可验证的标准 | 方法论资产 |
关键区分：吸收不是照搬。目标是将外部知识转化为团队标准化的、可复用的能力单元。
验证 → 沉淀 → 复用 → 加速
↑ ↓
└──────────────────────┘
| 阶段 | 动作 | 产出 |
|---|---|---|
| 验证 | 隔离运行 Demo，验证不确定性 | 验证结论（通过/失败 + 量化数据） |
| 沉淀 | 将验证过程和结论标准化为四类资产 | 可检索的能力库条目 |
| 复用 | 新项目/新功能遇到类似需求时，先查能力库 | 跳过验证直接集成，或基于已有 Demo 微调 |
| 加速 | 能力库越丰富 → 需要从零验证的越少 → 开发速度越快 | 团队能力的复利效应 |
做得越多，积木越多，新版本越像「搭积木」而不是「造积木」：
| 版本 | 需要新 Demo | 直接复用 | 说明 |
|---|---|---|---|
| v1.0 | ~90% | ~10% | 从零开始，几乎每个能力都要验证 |
| v1.5 | ~30% | ~70% | 能力库充足，大部分直接用 |
| v2.0 | ~50% | ~50% | 架构升级，又有新的不确定性 |
| v3.0 | ~20% | ~80% | 积累更厚，新版本大部分是组装 |
遇到新的不确定性时，先查再做：
面对任何实现任务时的快速判断：
| 判断问题 | 可预期（直接做） | 不可预期（先验证） |
|---|---|---|
| 团队做过类似的事吗？ | 做过 | 没做过 |
| 结果有超过 90% 的把握吗？ | 有 | 没有 |
| 外部依赖（LLM、第三方 API）可控吗？ | 可控 | 不可控 |
| 多模块集成测试过吗？ | 测过 | 没测过 |
决策规则：
能力验证不只是"跑通代码"，还要编码约束——让违反约束的实现不可能被写出。基于产品特性，在设计阶段识别五个维度的约束：
| 维度 | 判断问题 | 例子 |
|---|---|---|
| 业务约束 | 100 年后还成立吗？ | 「原始录音不可变，摘要可重新生成」 |
| 时序约束 | 有没有执行路径可以绕过这个规则？ | 「停止录音后同一 session 不可恢复」 |
| 跨端约束 | 如果两个端定义不同，这是 bug 吗？ | 「CardType 在所有端完全一致」 |
| 并发约束 | 两个线程同时做这件事会出问题吗？ | 「状态机事件串行处理」 |
| 感知约束 | 超过这个阈值，用户会注意到吗？ | 「音频源切换 < 100ms」 |
新增功能模块时，逐行过上表，把命中的约束写入 Demo 的 README 或设计文档。
约束编码示例：
业务约束编码：「原始录音不可变，摘要可重新生成」
时序约束编码：「停止录音后同一 session 不可恢复」
并发约束编码：「状态机事件串行处理」
| 反模式 | 症状 | 正确做法 |
|---|---|---|
| 功能伪装成能力 | Demo 名含产品名，换项目不可用 | 剥离产品特定部分，找底层能力 |
| 跳过验证直接集成 | "应该没问题"→ 集成后才发现不稳定 | 对不可预期部分先隔离验证 |
| 验证但不沉淀 | 做了 Demo 但只在聊天记录里 | 至少产出一类资产，写入能力库 |
| 过度验证 | 对标准 CRUD 也做 Demo | 只对不可预期部分验证 |
| 原子太大 | 一个 Demo 验证三个不确定性 | 拆到一句话能说清 |
| 不查库就新建 | 团队已验证过类似能力但重新做 | 先查能力库，有则复用或扩展 |
归档管理——Task 归档与 Recording 物理归档的双轨机制、触发条件、手动步骤、验证清单。触发场景：(1) 终态任务数超阈值，(2) session 文件数超阈值，(3) 用户说"归档"、"archive"、"清理"
纠偏与误判排查方法论——退化信号检测、四行重写模板、止损序列、六类泛化误判排查表、与 BLOCKED 的边界判定。触发场景：(1) 出现退化信号（反复纠偏/目标漂移/证据缺失等），(2) 需要纠偏恢复，(3) 排查误判，(4) 判断是 correction 还是 BLOCKED，(5) 用户说"纠偏"、"偏了"、"不对"、"重写"、"止损"、"误判"
产品文档工具——正向（需求→文档）或逆向（代码→文档）两种模式。触发场景：(1) 为已有产品还原/补全文档，(2) 为新功能/模块编写产品文档，(3) 用户说"写文档"、"还原文档"、"doc"、"产品文档"
阶段边界决策锚点——四段式判断（启动/实施/验收/纠偏），含正例/反例/边界例。覆盖：基线失败处理、不确定性决策、入口门控、大幅度判定、执行偏差分级、并行串行选择、超前实施、Done 人工确认、blocked_by 判定、循环依赖、continuous_mode 续跑、recording 写入时机、decisions.md 写入时机。触发场景：(1) 需要做阶段边界决策，(2) 判断幅度大小，(3) 选择并行还是串行，(4) 判断是否需人工确认，(5) 用户说"判断"、"决策"、"幅度"、"并行"、"确认"
产品需求分析方法论——竞品分析、用户画像、需求优先级排序、迭代层次设计、方案对比、非功能性需求分类。触发场景：(1) 讨论产品规划或功能设计，(2) 进行需求分析或竞品调研，(3) 设计迭代路径或优先级排序，(4) 用户说"PRD"、"需求文档"、"竞品分析"、"产品规划"、"需求优先级"、"迭代规划"、"方案对比"
Session 记录写入方法论——文件格式模板、踩坑经验四段式记录、时间戳获取规则、最低合法答案、归档聚合指引、Stop hook 检测正则。触发场景：(1) 写 session 记录，(2) 记录踩坑经验，(3) Session 结束前整理，(4) 用户说"记录"、"recording"、"踩坑"。铁律：必须 date 命令获取时间戳。