Mycelium 实战教程：让 AI 编码 Agent 在写代码前先想清楚，告别做白工
痛点：Agent 太快了，快到你来不及后悔
用 Claude Code、Cursor 这类 AI 编码 Agent 时，你是不是有过这样的体验：你给了一个想法，Agent 飞速地建仓库、写代码、开 PR —— 整个过程行云流水，但发布的却是一个「没人需要的东西」。
这不是 Agent 的错，这是工作流的缺陷。AI 让「动手构建」变得极其廉价，但「决定该不该构建」的环节却完全被跳过了。Agent 从「有个想法」直接跳到「写代码」，中间缺失的需求验证、受众分析、风险假设检查才是决定产品成败的关键。
Mycelium 正是在这个缺口上补了一刀 —— 它不是帮你写更多代码的 Agent 插件，而是让 Agent 在动键盘之前先动脑子的工具。
Mycelium 是什么
Mycelium 是一个 Claude Code 插件（MIT 开源，Python），核心一句话：让 AI Agent 在写代码之前，先通过证据检查（Gate）来证明它应该写这段代码。
它不替代你的判断，而是给 Agent 套上一套「发现 → 验证 → 决策」的流程框架，让 Agent 在接想法到产出 PR 的管道中，不会无声无息地跳过那些你真正在意的问题。
快速安装
在 Claude Code 终端中执行：
/plugin marketplace add haabe/mycelium /plugin install mycelium@haabe-mycelium
安装完成后，运行首次命令启动发现流程：
/mycelium:start
一条命令完成两件事：项目初始化（创建 .claude/ 下的状态目录）和首次 10 分钟的需求发现访谈（Interview）。两个子命令也可独立调用：
/mycelium:setup # 仅初始化项目目录 /mycelium:interview # 仅运行需求发现访谈
插件安装是无侵入的（brownfield-safe），不会修改你的 CLAUDE.md、README、LICENSE 等根文件。所有技能以 /mycelium: 命名空间注册，不会与你自己定义的 slash 命令冲突。
核心概念：Scales × Diamonds × Gates
Mycelium 的架构围绕三个核心概念展开，理解它们就能理解整个工具的设计哲学。
Scales（尺度）：决策的 6 个层级
不是每个项目都需要完整的流程。Mycelium 把「该不该做」的决策分成 6 个尺度：
| 尺度 | 含义 | 适用场景 |
|---|---|---|
| L0: Purpose | 为什么要做这个 | 新项目立项 |
| L1: Strategy | 整体策略方向 | 季度/年度规划 |
| L2: Opportunity | 具体机会验证 | 产品功能评估 |
| L3: Solution | 解决方案设计 | 技术方案决策 |
| L4: Delivery | 交付执行 | 迭代规划 |
| L5: Market | 市场反馈 | 上线后验证 |
周末 Hackathon 项目可能只需要 L3 以下的验证，而团队产品则需要完整的 L0-L5 流程。Mycelium 会通过 start 命令自动检测你的项目规模，只执行必要的尺度。
Diamonds（钻石）：四段式验证循环
每个尺度内部都遵循同一个四段循环模式：
Discover（发现）→ Define（定义）→ Develop（开发）→ Deliver（交付）
这个循环来自设计思维（Design Thinking），Mycelium 将其形式化为 Agent 可执行的结构化流程。每个阶段结束时，Agent 必须通过一个 Gate（门） 才能进入下一阶段。
Gates（门）：让 Agent 停下来
Gate 是 Mycelium 最重要的机制。它不是一份 Checklist 让 Agent 勾选了事，而是强制 Agent 停下来，向你呈现已收集的证据，确认该证据支持继续前进后才放行。
一个典型的 Gate 会问四个问题：
- 问题是什么？（我们解决了什么）
- 谁有这个问题？（目标受众是谁）
- 你在这个问题上最冒险的假设是什么？（什么可能让你全盘皆输）
- 验证这个假设的最小步骤是什么？（最小的验证动作是什么）
10 分钟后，你手上就有一份结构化的需求文档，Agent 指向那个最冒险的假设，问你要不要验证它再继续。
实战：从一个想法到值得构建的 PR
下面用一个真实的场景演示 Mycelium 的工作流。假设你想用 AI 做一个「个人播客剪辑助手」。
第一步：启动发现
/mycelium:start
Agent 不会打开编辑器，而是开始提问。它会问：
- 「这个播客剪辑助手是给谁用的？自己还是外包团队？」
- 「你假设的最冒险的事情是什么？——用户是否愿意把原始音频上传到第三方？」
- 「如果不做这个产品，最直接的替代方案是什么？」
第二步：Interview 阶段的输出
10 分钟后，Mycelium 在项目目录下生成一份 YAML 格式的决策文档。内容类似这样：
purpose:
statement: "帮助独立播客制作者快速剪辑多轨录音"
evidence: "访谈了 5 位独立播客主，100% 提到剪辑耗时是最大痛点"
assumptions:
- risk: "用户愿意上传原始音频到云端处理"
test: "做一个带隐私声明的落地页，看注册转化率"
minimum_viable: "本地处理 + 可选云端加速"
decision: "进入 Solution 阶段，MVP 定位本地优先"
这就是「证据」——不是感觉，不是信念，而是真正放到项目里的结构化数据。
第三步：Gate 放行，进入构建
你同意验证那个最冒险的假设后，Agent 才开始写代码。如果验证失败（比如用户确实不愿意上传音频），Agent 会回到 Discovery 阶段，用新学到的信息重新定义方案。
这意味着什么？——如果方向错了，你在 30 分钟内就知道，而不是 3 周后才知道。
回到已启动的项目
如果你想回到之前做了一半的项目，用这个命令恢复上下文：
/mycelium:diamond-assess
它会读取项目中的决策 YAML，告诉你当前处于哪个尺度/阶段的哪个门，然后推荐下一步操作。
与其他工具的区别
Mycelium 在这个赛道上并不是孤例，但它的定位很独特：
| 工具 | 定位 | 区别 |
|---|---|---|
| Mycelium | 发现驱动的开发框架 | 强制 Agent 在写代码前收集证据 |
| Agent Skills（addyosmani） | 执行速度优化 | 适合已知范围的纯执行加速，可与 Mycelium 组合 |
| Boring Agents（Paddo） | 流程自动化 | Triage 类工作（扫陈旧 Ticket、固定模板生成） |
| 传统需求文档 | 人工撰写 | 不集成到 Agent 工作流中 |
Mycelium 适合的场景是「决定做什么比怎么做更难」的项目。如果你的项目方向明确、需求清晰，纯执行加速工具（如 agent-skills）更合适。
成本考量
Mycelium 本身在 API 开销上较为克制：
- 框架开销约 6,000 tokens/会话（hooks、gates、pre-task 上下文）
- 主要成本在 15-30 分钟的 Interview 阶段——这是无框架 Agent 会直接跳过但实际最有价值的环节
- 根据外部用户 2026 年 4 月的估算数据，Claude Code 日均约 $13 API 费用，Mycelium 的额外开销远低于 10%
最佳实践
不要对所有项目都跑完整流程：Mycelium 的 Gate 根据项目规模自动调整严格度。周末小项目可以跳过 Strategy 层，让你的 Agent 知道这个项目的「风险等级」。
Gate 失败不是坏事：如果证据检查没通过，说明你规避了一个损失。重新进入 Discovery 循环比上线后才发现方向错了要好一万倍。
与执行工具组合使用：Mycelium 解决了「该不该做」的问题，但「怎么做更快」的问题可以用 Addy Osmani 的 agent-skills 或 Cursor 的原生功能来解决。两者组合使用效果最佳。
定期运行 diamond-assess：项目进行中，最初的假设可能已经过时。每周或每个迭代结束时运行 /mycelium:diamond-assess，检查哪些假设仍然成立。
总结
Mycelium 解决的不是「写得快不快」的问题，而是「写得对不对」的问题。在 AI Agent 越来越快的今天，知道什么时候不要写代码、写什么代码、为什么写这些代码，反而成了更稀缺的能力。
如果你已经在用 Claude Code 做产品开发，并且厌倦了 Agent 做了一大堆然后发现方向错了，Mycelium 可能是你需要的那个刹车片——它不是踩死油门，而是让你在加速之前先看清路。
相关链接