「吃自己的狗粮（dogfooding）」在软件行业是个常见说法，但真正做到的不多。更少见的是：用一个工具来开发这个工具本身，并且把过程中的数据公开出来。
这就是 Manon 自举验证的意义。从 v1.0 到 v1.2.4，Manon 的所有迭代都经过自己的开发技能体系：/idea 定需求、图谱工具写代码、/dao 清理、/tc 补测试、/exp 验证上线。
以下是关键数据节点的真实记录。
/dao：代码健康度从 88 提升到 97
在 v1.1.2 版本，我们把 /dao 应用于 Manon 自身的代码库（93 个文件，800+ 实体）。
/dao 的工作流程是：扫描代码健康度 → 将问题分为三层（架构/模块/代码）→ 架构层和模块层展示面板让人工决策 → 代码层全部自动修复，每一步都通过图谱验证（比如删除死代码前先确认零调用者）。
| 指标 | 之前 | 之后 | 变化 |
|---|---|---|---|
| 代码健康度评分 | 88/100 | 97/100 | +9 |
| 死代码实体数量 | 47 | 29 | -38% |
| 测试覆盖率 | 32% | 61% | +29pp |
| 跨模块关系 | 0 | 48 | 从零修复（图谱 bug） |
具体识别并修复的问题：
- 死函数：17 个从未被调用的函数被移除
- 过度碎片化：4 个单函数模块被合并
- 桶式重导出：多层
__init__.py间接层被简化 - 循环依赖：2 个循环依赖被切断
38% 的死代码减少意味着：以后每次阅读代码库，需要在脑子里排除的干扰项少了 38%。这个收益随时间复利累积。
/exp：上线前发现 4 个真实 Bug
在 v1.2.4 发布前，我们用 /exp 测试 /idea 技能。/exp 让 AI Agent 像真实用户一样通过 Playwright 操作产品，最多 3 轮自动修复。
| 轮次 | 通过率 | 发现的 Bug | 修复 |
|---|---|---|---|
| 第 1 轮 | 4/5 通过 | 图谱 API 响应解析错误；Windows GBK 编码崩溃 | 修复关系匹配逻辑 + 强制 UTF-8 输出 |
| 第 2 轮 | 0/1 通过 | 符号过滤器过严导致中文查询崩溃 | 放宽过滤条件 + 编码修复 |
| 第 3 轮 | 1/1 通过 | — | 全部场景通过 |
3 轮测试，发现 4 个真实 Bug。没有 /exp，这 4 个 Bug 会直接发布给用户。
值得注意的是：这些 Bug 全部是在真实操作场景下被发现的，而不是单元测试覆盖的。Windows GBK 编码崩溃这类问题，只有真实跨平台运行才能暴露。/exp 模拟的是用户行为，不是代码路径。
/idea：需求精化流程的完整测试
我们用 /idea 来规划「批量仓库导入」功能。完整流程：
- Phase 1（上下文）：一次脚本调用获取 15 个相关模块 + 3 个图谱条目 + 当前健康评分
- Phase 2（苏格拉底式追问）：生成 5 个问题，全部基于图谱事实——「
repos_create的扇入是 7，批量导入放在同一接口还是新建路由？」 - Phase 3（方案）：3 个技术方案，每个带影响分析和健康度预测
- Phase 4（开发文档）：生成完整的开发文档，通过 5 维度自动审查（需求完整性、风险覆盖、测试策略、接口设计、向后兼容）
传统做法：需求文档由人撰写，可能花一天，问题基于经验和假设。
/idea 做法：问题基于代码事实（fan-in、模块边界），追问有明确的结构依据。
自增强循环的意义
自举验证不只是一个数字游戏，它证明了一件事：这套工作流在真实复杂度的项目上是可行的，而且是自我改进的。
每次 /dao 提高健康度，下次 manon_graph 的结果就更准确；每次 /tc 提高覆盖率，/exp 发现的 Bug 就越少来自已知路径；每次 /idea 追问到了更清晰的需求，写出的代码就越少需要后期重构。
技能之间的协同是设计意图，不是偶然。
版本历史中的健康度轨迹
- v1.0.0（2026-03-16）：架构简化，完整测试套件建立
- v1.1.2（2026-03-19）：
/dao大规模清理，测试覆盖率 32%→61% - v1.2.1（2026-03-20）：知识图谱质量升级，跨模块边恢复，关系数量 +74%，健康度 97/100
- v1.2.4（2026-03-22）：
/idea+/exp技能上线，HANDLES 边类型，完整技能生态
从 v1.0 到 v1.2.4 共 6 天，4 个主要版本——每个版本都通过完整的 /idea → 开发 → /dao → /tc → /exp 循环交付。