Appearance
04 · 如何让想法真正落地
从一份退款 SOP 出发，经过 2 次 spike、1 份 canonical plan（11 条 ADR）、4 轮 Darwin 优化、1 次架构补全，最终在 GitHub 发布一个 88 文件、12 道自检关、跨平台可用的元技能。本文不是教怎么写代码——是教 怎么把脑子里一个想法，变成可靠的、可交付的、别人能用的东西。
💡 核心方法论：「落地 5 步法」
从想法到交付，不是一股脑冲，而是五步闭环：
| 步骤 | 做什么 | 关键动作 | 时长 |
|---|---|---|---|
| ① 识别 | 搞清楚这是什么性质的问题 | 本体差异分析，判断是新项目还是变种 | 5 分钟 |
| ② 验证 | 用最小代价确认核心假设没塌 | 跑 spike（1 小时实验） | 1-2 小时 |
| ③ 规划 | 建立唯一真理源 | 写 canonical plan，写 ADR | 2-3 小时 |
| ④ 执行 | Phase 化推进，近细远粗 | 每次只做一个 Phase | 2-4 周 |
| ⑤ 审查 | 完成后必做的两道关 | 独立审查 + Darwin 评分 | 2-3 小时 |
协作质量 = 你的提问质量 × agent 的执行质量——两个变量相乘，任何一个低了结果都不会好。
① 识别：搞清楚这是什么问题 [5 分钟]
手上有一份《SP007-系统课退课退款流程》的 SOP 文档，约 200 行 Markdown。同时已有一个跑通的「产品介绍元技能」。
第一个问题：业务流程文档化，是产品元技能的延伸，还是新东西？
让 agent 做了本体差异分析：
| 维度 | 产品 | 业务流程 |
|---|---|---|
| 主体 | 静态对象 | 动态序列 |
| 时间性 | 弱 | 强（顺序 + SLA 是一等公民） |
| 角色 | 2-3 类外部受众 | 5-7 类内部角色 |
| 输出 | 介绍材料 | 执行 + 审计 + 学习 |
| 失败处理 | 弱 | 强（每步需异常路径） |
判断：5 处都是本体级别的不同，不是参数差异。这是姊妹元技能，不是扩展。
💡 心法
每个项目开始前，先问「新东西还是变种？」 变种 → 改现有的，省一半工作量。新东西 → 单独建。判断方法：列出至少 5 个维度的对比，看是参数差异还是本体差异。
② 验证：用最小代价确认核心假设 [1-2 小时]
确定新建后，不直接 build。先跑 spike——为消除关键不确定性而做的小代价实验。
核心假设：「L0-L6 七层架构真的能装下真实业务流程吗？」
怎么跑
用 SP007 那份 SOP，时间盒 60 分钟，只填 L0 和 L1。每个字段标摩擦等级：
🟢 顺利填入 🟡 放哪不够明确 🟠 两处都能放
🔴 素材缺信息 🟣 schema 完全没考虑为什么跑两次
- spike-01 用完整 SOP → 验证理想素材下架构是否成立
- spike-02 用流程图 + 稀疏文档 → 验证现实素材下是否成立
spike-02 的关键发现：架构不只要「装信息」，还要「识别缺失」。只跑一次就 build，元技能会在面对稀疏素材时持续撒谎。
💡 心法
任何超过 1 周工作量的项目，开始前花 1 小时跑 spike。 spike 的本质是证明核心假设没塌。如果你不知道核心假设是什么，那你还没准备好 build。
③ 规划：建立唯一真理源 [2-3 小时]
翻车时刻
跑完 spike 打算「把学到的合并进 blueprint 然后 build」。被打断：
「你应该先有一份针对整个 skill 的全局规划文档，在规划中解决前面遇到的问题。」
之前在做的是 bottom-up 修补流：每发现新问题就回头打补丁，blueprint 越来越碎片。
正确做法：plan 是唯一真理源。spike → plan → 实现 → 反馈 → 改 plan → 再实现。任何实现必须能追溯到 plan 的某一节。
plan.md 的具体结构
20 章 + 11 条 ADR（架构决策记录）。每条 ADR 5 字段：
Context → 为什么遇到这个问题
Decision → 决定怎么做
Consequences → 后果是什么
Alternatives → 考虑过的其他方案，为什么否决
Spike Reference → 证据来自哪个 spike 的哪一项💡 心法
绝不在没有 plan 的情况下让 agent 开始 build。 Plan 不需要完美，但必须是唯一真理源。违反代价极高——文档与代码漂移、决策上下文丢失、相同错误反复犯。
④ 执行：Phase 化推进，近细远粗 [2-4 周]
不要让 agent 一口气 build 完。切 4 个 Phase：
| Phase | 范围 | 估时 |
|---|---|---|
| 1 | 核心架构 + 6 个高频产物 | 1.5-2 周 |
| 2 | 多模输入采集 + 全 14 产物 | 2 周 |
| 3 | 生命周期 + 网络层 | 1.5 周 |
| 4 | 发布准备 | 3-5 天 |
每个 Phase 写独立 build-guide，Phase 2 开头设 5 道自检题根据状态分流。Phase 3-4 只写轻量 outline——先跑完 Phase 1-2 拿到真实信号再补细节。
💡 心法
N+1 写细，N+2 写粗，N+3 只列目标。 远阶段不要早规划——现在写细节就是基于假设的过度设计。
⑤ 审查：完成后的两道必过关
第一道：独立审查（vs self-validation）
Phase 1-4 跑完，agent 汇报「Self-Validation 7 维度全过，可以发布」。
不能信。 需要用独立审查来对照原始目标检查。发现了 4 个问题：
| 优先级 | 问题 | self-validation 漏掉的原因 |
|---|---|---|
| 🔴 P0 | 版本号在 5 个文件不一致 | 检查项里没覆盖跨文件版本一致性 |
| 🟡 P1 | git init 了但 0 commits | "已发布"是 agent 自己的定义 |
| 🟡 P1 | example 只有占位符 | agent 认为「占位符也算有」 |
| 🟢 P2 | plan.md 没反向 sync | plan 和实现脱节 |
Self-validation 7 维度全过，独立审查发现 4 个问题。
第二道：Darwin 评分 + 单维优化
Darwin 是另一个独立评估 Skill 质量的元工具，8 维度 100 分制。基线 91.3 分。
四轮优化，每轮只动一个维度：
| 轮次 | 改了什么 | 分数 |
|---|---|---|
| R1 | 实测表现：2 角色流程覆盖规则从固定 ≥3 改为动态 | 91.3 → 93.3 |
| R2 | 检查点设计：L1 生成完后插入 4 项确认检查点 | → 94.9 |
| R3 | 指令具体性：14 recipes 清单内联到 Step 6 | → 95.7 |
| R4 | Frontmatter：加排除声明 + 补齐 6 项能力 | → 96.0 |
架构补全：版本追踪 + 时间有效性
一个更深的问题：「修改元技能时，对已生成的流程有影响吗？」→ 诚实答案是没有形式化考虑。
修复：生成 Skill 时自动写入 generated_by_meta_skill_version。同时加了时间有效性 4 字段（生效日期、失效日期、生命周期阶段、试运行截止日），定义了 draft → trial → active → superseded → retired 状态机。→ 98.0。
同类错误第二次发生，立刻机器化
P0 版本号不一致在 v1.1.1 修复后，3 次 bump 之后又复发了。原因是检查靠人记。
修复：「把检查写成 CLI 命令 → 放进 INITIAL_COMMIT.sh → commit 前必须跑通。」版本号不一致再也无法 commit。
💡 心法
第 1 次出错 → 修。第 2 次出错 → 加 CLI 检查命令。第 3 次 → commit pre-gate。 你的大脑不应该被用来记忆「该检查 X」。
警惕 agent 的「看似有价值」提议
agent 提议了 5 项「v2.0 铺路」工作。用杀手锏问题检验：「如果未来不做 v2.0，这些对当前有价值吗？」——5 项全部对单流程零价值，只是在为假想未来铺路。
💡 心法
当 agent 提一组任务时，问：「这些不解决会怎样？如果某未来场景不发生，它们还有价值吗？」 agent 容易输出看似有用的工作，实际是死代码。
📋 30 秒扫读版
| 步骤 | 核心动作 | 一句话 |
|---|---|---|
| ① 识别 | 本体差异分析 | 列 5 个维度对比，判断新项目还是变种 |
| ② 验证 | 跑 spike | 1 小时验证核心假设，必须跑两次（理想+现实素材） |
| ③ 规划 | 写 canonical plan | 唯一真理源 + ADR 5 字段，完成前不 build |
| ④ 执行 | Phase 化 | N+1 细 N+2 粗，每个 milestone 独立 build-guide |
| ⑤ 审查 | 两道必过关 | 独立审查 + Darwin 单维优化，self-validation 不可信 |
5 个起步动作（如果完全没做过）
动作 1：识别素材。 打开身边一份业务文档，问自己——它能让新人独立执行吗？
动作 2：写 30 秒项目描述。 要解决的问题 + 当前状态 + 理想交付物。
动作 3：要求 agent 跑 spike。 「只做最小可行验证，输出 diagnosis 文档，不要直接 build。」
动作 4：要求 agent 写 plan.md。 含 ADR + CHANGELOG + 声明唯一真理源。
动作 5：milestone 完成后做独立审查。 「对照原始目标，列出 P0/P1/P2 三类问题，包括 self-validation 盲区。」
完成这 5 个动作 = 已经掌握 80% 的 agent 协作能力。
结语
这个项目从一份退款 SOP 开始，经历了 2 次 spike、5 份 Phase 文档、1 份 canonical plan（11 条 ADR）、1 次 Darwin 评估 + 4 轮优化（91.3 → 96.0）、1 次架构补全（→ 98.0）、5 个 GitHub tag。核心架构没改过一次——所有变化都在它能装下的边界内。
这就是 plan-first 工作法的回报：前期多想 1 小时，后期少返工 1 周。
如果只能记住一句：Agent 不是替你思考的工具，是放大你思考的工具。协作质量 = 你的提问质量 × agent 的执行质量。
本案例由 桔子 通过 WorkBuddy 与 Claude 双平台协作完成。2026 年 5 月。