当OpenSpec 管好了「规范怎么写」，Superpower管好了「单点能力怎么强」，谁来管「整个研发过程怎么跑」？
MASE （M easures A I S oftware Engineering）是麦哲思科技结合自身在 VIBE 工程（Vibe-Driven AI Engineering）领域的一线实践经验，沉淀并开源的一套 AI 软件工程统一方法论与工具集。它在 OpenSpec 和 Superpower 等成熟框架的基础上，补齐了流程编排、质量门禁、复盘闭环等关键拼图，让碎片化的好工具协作成一套自洽、可进化的研发体系。
一、我们已经有 OpenSpec 和 Superpower 了，为什么还要 MASE ？
在 AI 辅助编程的探索中，我们先后构建了两层能力，各自解决了不同维度的问题：
第一层： OpenSpec --- 规范驱动开发
OpenSpec 解决的是「规范怎么写」的问题。它以 changeset 为单位，用 proposal → design → specs → tasks 的结构化流程，让每个功能变更都有清晰的 Why / What / How，并通过 Gherkin 风格的 spec.md 定义可验证的验收标准。它让 AI 不再「凭感觉写代码」，而是「对着规格写代码」。
第二层： Superpower / Skills --- 单点能力强化
Superpower 解决的是「具体任务怎么做」的问题。brainstorming 做需求澄清，bug-fixer 做智能修复，code-review 做合规检查，test-driven-development 做 TDD 微循环......每个 Skill 都是某个垂直领域的高度专业化 Agent。
两层的长处，也是两层的盲区：
OpenSpec 的强项是规范产出结构化 ------proposal 把 Why 讲清楚，specs 把验收标准定义死。但它的盲区同样明显：规范写好了，谁来执行？谁在执行前审查？执行后谁验证？验证发现的问题谁来追踪闭环？
Superpower 的强项是单点任务专业化 ------每个 Skill 在它擅长的领域表现极佳。但它的盲区正好相反：单点再强，拼不起来还是一盘散沙。 brainstorming 澄清了需求，需求如何流转到设计？code-review 发现了问题，问题如何确保被修复？bug-fixer 修了一个 BUG，类似 BUG 如何被系统性地预防？
MASE 的答案：取两者之所长，补两者之所短。
它不替代 OpenSpec------而是把 OpenSpec 的规范产出作为各阶段的输入和门禁依据。它不重写 Superpower/Skills------而是把每个 Skill 分配到正确的 Agent、正确的阶段，让它们在对的时间做对的事。同时，它补齐了两层都不覆盖的关键拼图：
- 质量门禁：每个阶段有明确的 Checklist + 人工确认，不合格不进入下一阶段；
- PDCA 闭环：复盘 → 分析模式 → 改进规则 → 下次不再犯同类错误；
- 项目结构规范：唯一性原则 + 镜像原则 + Capability 对齐，杜绝代码散落；
- 工程纪律：八条不可妥协的规则，编码进 Agent 行为约束。
这就是 MASE 的由来：站在 OpenSpec 和 Superpower 的肩膀上，把碎片化的好工具编排成一套自洽、可进化的软件工程方法论。
二、 MASE 是什么？
MASE （ Measures AI Software Engineering ） 是一套面向 AI 辅助软件开发的统一方法论与工具集 ，核心架构概括为九个字：四 Agent · 六阶段 · PDCA 闭环。
它不是 OpenSpec 或 Superpower 的替代品，而是它们的上层编排层：
|--------------------------------------------------------------------|
| MASE（编排层） 四 Agent 协作 · 六阶段流转 · PDCA 进化 |
| OpenSpec 层（规范层） proposal / design / specs / tasks |
| Superpower / Skills 层（能力层） brainstorming / TDD / code-review / ... |
- OpenSpec 的产出物（proposal、specs、tasks）被 MASE 各阶段直接消费；
- Superpower/Skills 被分配到 MASE 的四个 Agent 中，在正确的阶段被正确调度；
- MASE 额外补齐了门禁机制、复盘闭环、项目结构规范、八大工程规则------这些是前两层都不覆盖的。
三、 MASE 的核心架构
四 Agent --- 专业分工，各司其职
|-----------|--------|---------------------------------------|
| Agent | 角色 | 一句话职责 |
| A1 | 计划与统管 | 接收需求 → 分解任务 → 调度 A2/A3/A4 → 门禁把关 → 发布 |
| A2 | 需求 | 澄清需求 → 生成交互原型 → 编写操作流程 → 定义测试用例 |
| A3 | 开发 | 技术预研 + POC → 架构设计 → 详细设计 → TDD 构建 |
| A4 | 质量 | 设计评审 → 代码评审 + 安全扫描 → 端到端验证 + BUG 修复 |
A1 是「总指挥」，A2/A3/A4 是专业化执行单元。每个 Agent 只在它擅长的阶段工作，协作但不耦合。
六阶段 --- 从需求到发布，一步不落
Proposal ──→ Design ──→ Build ──→ Verify ──→ Retro ──→ Release
需求 设计 构建 验证 复盘 发布
(A2) (A3+A4) (A3+A4) (A4) (A4+A1) (A1)
每个阶段都有明确的输入、产出物、执行 Agent 和门禁条件：
|--------|---------------------------------------|----------------------------|
| 阶段 | 核心产出 | 门禁 |
| 需求 | 交互原型 + 操作流程 + 系统测试用例 | 原型走查演示 + Checklist 确认 |
| 设计 | 技术预研报告 + POC 脚本 + 架构图 + Gherkin Specs | 设计评审（架构合规 + 需求一致性）+ 人工确认 |
| 构建 | 可运行代码 + 自动化测试 | Capability 全量测试通过 + 代码评审通过 |
| 验证 | 全部 BUG 关闭 + 测试缺口补充 | 端到端测试无新 BUG |
| 复盘 | 复盘报告 + 改进措施 | 改进措施执行完毕 |
| 发布 | 最终合规审查 + 使用手册 + git commit | 全量 spec 合规检查通过 |
这个流程看起来「重」，但它的设计哲学是：宁可前面多花一小时确认方向，也不要在写了两天代码后发现做错了。 在 AI 编程时代，这条原则被进一步放大------AI 没有创造力瓶颈、没有流程抵触、没有倦怠疏漏，它天生适配 CMMI 式的刚性规范和标准化流程。人类怕约束所以爱敏捷，AI 守规则所以爱工程化。MASE 正是利用了这种天性互补：人负责定义与决策， AI 负责执行与守规。
四、八大工程原则
MASE 的原则体系背后有一条朴素的元规则------三次法则：同一问题、同一模式、同一类错误在第三次出现时，就是系统化改进的最佳时机。第三次修改同一模块 → 重构它；第三次出现相似代码 → 统一封装；第三次被同一类 BUG 绊倒 → 更新流程。这条元规则贯穿了八条原则的设计逻辑：不是等到出了问题再打补丁，而是在问题第二次、第三次出现时，就把它变成流程的一部分。
MASE 将工程纪律固化为八条不可妥协的原则，按研发生命周期排序------从需求到交付，贯穿始终：
|-------|----------------|--------------------------|------------------|
| # | 原则 | 含义 | 在哪个阶段落地 |
| 1 | 需求澄清确认 | 原型确认后才进入开发，不确认不设计 | Proposal |
| 2 | 设计预研，消除风险 | 技术预研 + POC 验证，不把风险带进编码 | Design |
| 3 | TDD 驱动 | 内外双循环：spec 驱动验收 + 测试驱动编码 | Build |
| 4 | 验证与确认检查 | 端到端验证 + 合规审查，不通过不发布 | Verify + Release |
| 5 | 根因分析 | 任何 Bug 必须找到根本原因，不只修表象 | Verify |
| 6 | 系统化解决 | 杜绝临时补丁，修一个 Bug 防一类 Bug | Verify + Retro |
| 7 | 固定节奏提交 | 每 20 次对话做一次提交，保持版本粒度 | Build |
| 8 | 及时备份 | 删除/回退代码前必做备份，不留不可逆操作 | 全阶段 |
这八条原则不是「建议」------它们被编码在门禁 Checklist 和 Agent 的行为约束中，执行过程自动触发检查。每一条都对应到 MASE 的特定阶段，确保原则不悬空、纪律能落地。
五、完整的交付物
MASE 不仅是一套方法论文档，它还包含可直接部署的工具集：
|------------------------|-------------------------------------------------------------------------------------------------------------------------------------------|
| 组件 | 内容 |
| 9 个 Skills | brainstorming、bug-fixer、code-review、test-driven-development、frontend-skill、frontend-design、webapp-testing、git-commit、TRAE-security-review |
| 完整模板体系 | proposal / tech-feasibility / architecture / detailed-design / specs / tasks 全套模板 |
| 项目结构规范 | 五层目录（src + tests + docs + openspec + config），唯一性原则、镜像原则、Capability 对齐原则 |
| 培训讲义 | 35 页 Vellum 风格 HTML 培训材料，可直接浏览器打开 |
| 使用手册 | 从创建项目到发布的全流程操作指南 |
| 一键安装 | ./install.sh 自动部署到 Trae IDE |
六、 MASE 的独特价值
有了原则和工具，MASE 究竟能带来什么不一样的效果？
1. 设计先行，原型确认 --- 杜绝「写着写着就偏了」
每个需求在写一行代码之前，必须先产出可交互 HTML 原型并由你确认。不是线框图，不是 Markdown 描述------是你能点、能走、能感知的可交互界面。确认了原型，再进入设计；确认了设计，再进入编码。每一步都有「人工确认」这个硬门禁。
这里有一条来自实践的铁律：1:10 定律。 前期花 1 分钟澄清需求、明确边界，可以节省后期 10 倍的返工时间。AI 编程时代这一定律被进一步放大------AI 猜错一次需求，不是写错一行代码，而是批量生成一个方向的错误代码。模糊性就是返工成本的最大来源，而原型确认就是把模糊性降到最低的性价比最高的手段。
2. TDD 内外双循环 --- 测试不只是「写完补的」
MASE 中的 TDD 是内外双循环：
- 外循环：spec 驱动开发。specs/{capability}/spec.md 中的每个 Scenario 就是验收标准，不通过 = 不能提交。
- 内循环：测试驱动编码。每个 Scenario 的编写顺序必须是：测试 → 实现 → 验证。
这和「写完代码再补测试」有本质区别------测试不是事后验证，而是事前约束。
3. 系统化 BUG 修复 --- 不止于修，还要追根溯源
MASE 的 bug-fixer 不是「改一行代码就完了」。每个 BUG 修复走五步：
- 根因分析 → 为什么出这个 BUG？
- A/B 双修 → 不止一个修复方案，选择系统性的那个
- 回归验证 → 确认修复有效
- 测试缺口复盘 → 为什么自动化测试没抓到？补充用例
- 横向扫描 → 同类代码有没有同样的问题？
修一个 BUG，防一类 BUG。这是 MASE 区别于「对话式修 BUG」的核心差异。
4. PDCA 复盘闭环 --- 每一次开发都在进化
MASE 最独特的一个阶段是「复盘」。如果你读过前文提到的「三次法则」，你会理解为什么这个阶段不是可有可无的收尾，而是 MASE 自我进化的引擎。
复盘不是写个总结就完了。MASE 的复盘遵循四层蒸馏模型：
第 1 层：变更归零 --- 记录每一次值得记录的变更（不仅是 Bug，还包括需求变更、设计变更、重构、性能优化）。技术归零回答「根因是什么」，管理归零回答「流程哪里漏了」。
第 2 层：四环节改进点 --- 从每次变更中，分别对需求、设计、编码、测试四个环节各提出一个具体的改进点。不同变更类型，改进的侧重不同：需求变更侧重需求捕获流程，设计变更侧重设计评审机制，缺陷修复侧重测试用例缺失，重构侧重设计原则违背。
第 3 层：模式提炼 --- 当积累了足够多的变更记录，让 AI 聚类分析。比如「数据库 Schema 变更每次都引起代码变更」→ 模式：Schema 与代码未同步版本化；「需求变更集中在第2周之后」→ 模式：前期需求锚定不足。
第 4 层：原则蒸馏 --- 从多个模式中蒸馏出普适的、可指导未来行动的原则。比如「任何对外契约（API/Schema/配置项）必须版本化，且支持快速回滚」。原则不能是「正确的废话」（如「要加强测试」），而必须有正反案例和触发条件。
最终的产出：
- 复盘报告（docs/lessons/YYYY-MM-DD-{project}-retro.md）
- 改进措施：更新 Skill 规则、补充代码规约、调整门禁 Checklist
这种复盘机制的本质，是 MASE 对「需求往前看，缺陷往后看」这一工程哲学的落地：往前走时，不忘回头看路；往后看时，不忘前方的目标。 Proposal 阶段做前瞻性探索（需求澄清 + 技术预研），Retro 阶段做反思性复盘（根因分析 + 模式蒸馏），两端一合，构成了 PDCA 的完整闭环。
上一次犯的错，下一次不会在同一个地方再犯------因为流程本身就是可以进化的。
七、 MASE vs. OpenSpec vs. Superpower --- 一张表说清楚
|---------|--------------------------|-----------------------|-------------------------|
| 维度 | OpenSpec | Superpower/Skills | MASE |
| 定位 | 规范层 | 能力层 | 编排层 |
| 解决什么问题 | 规范怎么写 | 具体任务怎么做 | 整个研发过程怎么跑 |
| 有流程吗？ | 有（proposal→design→specs） | 无（单点工具） | 有（六阶段 + 门禁 + 闭环） |
| 有质量门禁吗？ | 无 | 无 | 有（每阶段 Checklist + 人工确认） |
| 有复盘机制吗？ | 无 | 无 | 有（PDCA 闭环） |
| 能自我进化吗？ | 不能 | 不能 | 能（复盘 → 改进 → 更新规则） |
| 管项目结构吗？ | 管 openspec/ | 不管 | 管全部目录（唯一性 + 镜像 + 对齐） |
八、写在最后
在软件工程领域，有一类实践被反复讨论却极少被严格执行------文档与代码同步、需求追踪矩阵、设计先行、TDD、质量门禁。不是人们不想做，而是人性天然的短视、认知负荷的局限、繁琐带来的疲惫感，让这些「正确的事」变得难以坚持。这五件事有一个共同的内核：它们都是需要「延迟满足」的软件工程实践。人类大脑偏爱即时反馈------写代码、看效果、解决问题，而厌恶短期没有收益的严谨工作。
AI 恰好没有这些「人性弱点」。它不觉得枯燥，不需要自律，不厌倦重复。它擅长处理繁琐、保持一致性、严格守规矩。AI 编程更应工程化 ------因为 AI 放大了混乱的代价：AI 猜错需求会批量生成错误代码，AI 缺少约束会自由发挥到不可预测的方向。AI 编程更能工程化------因为 AI 具备人类没有的执行力：永不疲惫、永不妥协、永不抵触。
所以 MASE 不是给开发流程「加重量」，而是给 AI 编程「配缰绳」。这匹千里马需要方向、需要节奏、需要边界------这些恰好是 OpenSpec 的规范能力和 Superpower 的单点能力在各自孤立刻状态下无法提供的。
OpenSpec 让 AI 有了「规格意识」，Superpower 让 AI 有了「专业技能」，MASE 让这一切有了「流程纪律」。
如果用一个比喻：OpenSpec 是施工图纸，Superpower/Skills 是各工种师傅，那 MASE 就是项目经理 + 监理工程师 + PDCA 改进小组的合体。
它不是要取代前两者，而是站在它们的肩膀上，回答一个更根本的问题：当我们有了一堆好工具之后，怎么让它们协作出一套真正靠谱的软件？
MASE 的答案很朴素，只有六个字：分工、门禁、闭环。
该框架已经免费发布在github上：GitHub - DylanRenM/MASE: MASE - Measures AI Software Engineering: 一套会自我进化的 AI 软件工程方法论 · GitHub