从一个 Command 到十五个：系统是怎么长出来的

不要试图一步到位。让真实的痛点驱动每一次演化。

起点

2026 年 1 月底，系统上线时只有 6 个命令。此后的两个月里，经历了 17 次实施计划和 40+ 个版本发布，长成了 15 个命令、3 个 Agent、几十个 Skill 的系统。

转折点 1：元管理能力的剥离

问题：一个 Agent 同时负责 QA 业务 + 元管理，system prompt 越来越臃肿。

决策：拆成两个独立插件：plugin-qa（纯业务）+ plugin-manager（通用管理）

教训：如果一个组件里有两种不同频率变化的东西——尽早拆分。

转折点 2：安装方式的破坏性迁移

问题：shell 脚本会展平目录层级，导致路径引用失效。

决策：迁移到 AI 工具的原生插件安装系统

教训：不要自己造轮子管理文件分发。用原生机制。

转折点 3：一个命令被拆成四个

问题：一个巨型命令 `generate_automation_cases` 承担了五件事，暴露了 9 个问题。

决策：拆成四个专注命令：

• explore_pages：页面探索
• generate_automation：用例生成
• run_automation：执行 + 失败分类
• merge_knowledge：知识库合并

教训：一个命令只应该有一个"主循环"。

转折点 4：人类审查体验的重构

问题：分析文档 300+ 行，没有人逐行审查，导致下游返工。

决策：三件套产出模式 + Revision 模式

• 完整文档（机器消费）
• 评审摘要（人类审查，<= 2 页）
• 反馈模板（勾选反馈）

核心洞察：AI 擅长穷举，人类擅长判断。

转折点 5：修复闭环的自动化

问题：自动化测试失败后，手动分类 + 修复 + 重跑需要 3-5 轮。

决策：创建 `run_fix_loop` 命令——状态机自动编排器

教训：可以形式化的判断→执行循环，就可以让 AI 驱动。

转折点 6：从 Diff 分析到跨仓库取证

演化路径：

• v1.0：分析单个 PR 的 diff
• v1.2：支持多 URL 输入
• v1.4：增量分析模式
• v1.5：技术栈自动路由
• v1.6：共享写入方法兼容性检查

核心观点：把每一次线上事故转化为系统的永久能力。

转折点 7：外部系统集成的分层策略

问题：外部系统 API 返回 194K 字符，超过调用限制。

决策：本地字段注册表（已知项目直接用，未知项目动态获取）

教训：对频繁调用的外部接口，本地缓存是必需的。

增长的规律

规律 1：每个 Command 都是从一个 Pain Point 长出来的

命令	触发事件
deep_investigation	3 轮浅层调查不够用
run_fix_loop	手动跑 5 轮修复循环太痛苦
explore_pages	不知道怎么导航到目标页面
bug_stats	手动统计 Bug 分布花了一下午

规律 2：拆分总是对的方向

• 1 个大插件 → 2 个独立插件
• 1 个大命令 → 4 个专注命令
• 1 个大循环 → N 个独立调查

规律 3：17 个计划文档 = 17 次学习

每个实施计划记录：问题 → 根因 → 方案选择 → 验证结果。比代码本身更有价值。

给正在从 0 到 1 构建的人

1. 从一个端到端的命令开始，而不是从完美的架构开始
2. 在真实场景中跑，而不是用假数据测试
3. 记录每一个失败——它就是下一次迭代的需求文档
4. 当一个命令的代码超过 500 行时，开始考虑拆分
5. 当一个问题第二次出现时，把解决方案编码为系统能力
6. 不要害怕 breaking change——越早拆分，迁移成本越低

---

这是"当 AI 接管测试流水线"系列的第四篇。最后一篇将讨论不确定性的传播管理。