主题
规则 ROI 审计报告
审计范围：
core/rules/（3 个文件，303 行）+core/agents/（7 个文件，~800 行 marker 上方内容）审计时间：2026-04-23 审计版本：v2.0.0-20260422
分类标准：
- 天然行为：AI 没有这条规则也会这样做 → 删除或精简，节省 token
- 有效约束：有规则时 AI 行为明显不同 → 保留，核心价值
- 愿望性指导：写了但 AI 无法可靠执行 → 改写为具体动作或删除
- 死规则：从未被实际场景触发，或仅特定项目场景触发 → 移除、归档或下沉到 Skill
一、审计总览
统计数据
| 文件 | 行数 | 天然行为 | 有效约束 | 愿望性指导 | 死规则 |
|---|---|---|---|---|---|
| project_rule.md | 187 | 5 | 19 | 3 | 1 |
| merge_checklist.md | 25 | 1 | 5 | 0 | 0 |
| framework_protection.md | 91 | 3 | 7 | 0 | 0 |
| pm-agent.md | 145 | 2 | 8 | 3 | 0 |
| arch-agent.md | 226 | 0 | 12 | 3 | 0 |
| dev-agent.md | 112 | 0 | 10 | 3 | 0 |
| fe-agent.md | 125 | 0 | 10 | 3 | 0 |
| qa-agent.md | 132 | 0 | 11 | 3 | 0 |
| prototype-agent.md | 95 | 1 | 5 | 1 | 0 |
| e2e-runner.md | 191 | 0 | 6 | 0 | 5 |
| 合计 | ~1330 | 12 (9%) | 93 (70%) | 16 (12%) | 6 (5%) |
说明：分类是逐条判断而非逐行，一条规则可能跨多行。百分比四舍五入。
关键发现
- 冗余是最大的 token 浪费源：同一规则在 project_rule.md 和多个 Agent 中重复出现，估计 15-20% 的 token 用于重复内容
- "路径校验"出现在 5/7 个 Agent 中，且措辞几乎相同（逐字复制），是最显著的单一冗余项
- 愿望性指导虽只占 12%，但它们的存在"稀释"了有效约束的注意力权重
- E2E Runner 的 ~60% 内容绑定特定技术栈（qiankun + Element UI + AES + OCR），不适合留在 core/
二、逐文件审计
2.1 project_rule.md（187 行）
| # | 规则（摘要） | 分类 | 建议 | 理由 |
|---|---|---|---|---|
| 1 | §1 触发条件：涉及新增/修改/删除功能时 | 有效约束 | 保留 | 无此规则时 AI 会对所有输入启动工作流 |
| 2 | §1 第一句话必须是 Intake 三问，禁止先读/写代码 | 有效约束 | 保留 | 最高价值规则。无此规则 AI 直接跳到代码 |
| 3 | §1 Intake 三问内容（目标/边界/验收） | 有效约束 | 保留 | 结构化提问模板，保证覆盖面 |
| 4 | §1 例外：纯解释/查询类、明确 bug 定位 | 天然行为 | 保留 | AI 天然区分这些场景，但明确列出可避免误判 |
| 5 | §1.1 Intake 后不得立即路由，需呈现摘要 | 有效约束 | 保留 | 强制确认步骤，纠偏效果好 |
| 6 | §1.1 用户明确同意后才可路由 | 有效约束 | 保留 | 审批门控的核心 |
| 7 | §1.1 路由自检 checkpoint | 有效约束 | 保留 | P0 新增，迫使 AI 输出推理过程 |
| 8 | §2 分类决策树（Q0→Q1→Q2→Q3） | 有效约束 | 保留 | 路由准确性的核心保证 |
| 9 | §2 Q0 轻量判定标准（"不超过 3 个文件"） | 愿望性指导 | 改写 | "不超过 3 个文件"在需求初期无法准确判断。改为更客观的标准，如"不需要新建文件，只修改现有代码" |
| 10 | §2 路由信号速查表 | 有效约束 | 保留但考虑合并 | 与决策树有信息重叠，但作为速查有独立价值 |
| 11 | §3 Spec 产出物定义表 | 有效约束 | 保留 | 核心参考表 |
| 12 | §4 工作流 A 定义 | 有效约束 | 保留 | 核心流程 |
| 13 | §4 工作流 B 定义 | 有效约束 | 保留 | 核心流程 |
| 14 | §4 工作流 C 定义 + 并行细节 | 有效约束 | 保留 | 核心流程 + 必要的操作细节 |
| 15 | §5 "无 Spec 直接开改代码" | 有效约束 | 合并 | 与 §1 和各 Agent 定义重复，保留一处即可 |
| 16 | §5 "PM/Arch 产出未经审批就进入下一环节" | 有效约束 | 合并 | 与 §1.1 重复 |
| 17 | §5 "Dev/FE 自行变通不上报" | 有效约束 | 保留 | 常见违规行为，单独列出有价值 |
| 18 | §5 "跳过 Intake 直接转发子 Agent" | 有效约束 | 合并 | 与 §1 重复 |
| 19 | §5 "主对话不输出大段代码" | 愿望性指导 | 改写或删除 | AI 经常违反此规则，无法可靠执行。如果保留，改为具体的行数限制 |
| 20 | §5 "前端任务不加载后端规则，反之亦然" | 有效约束 | 保留 | 防止上下文污染 |
| 21 | §6 主会话职责（7 项） | 混合 | 精简 | 5 项与 §1-5 内容重叠，仅"派发约束"和"异常处理"有独立价值 |
| 22 | §7 运行验证表 | 有效约束 | 保留 | 定义验证方式和证据 |
| 23 | §7 E2E 测试（可选） | 有效约束 | 保留 | 低频但必要 |
| 24 | §7 Deploy（可选、非阻塞） | 死规则 | 评估 | 无实际触发记录。如果有项目使用则保留，否则移除 |
| 25 | §8 Jira 集成 | 有效约束 | 保留 | 设计良好的非阻塞可选规则 |
project_rule.md 精简建议：
- §5 绝对禁止事项：从 6 条合并为 3 条（去重后：① No Spec No Code ② 不上报自行变通 ③ 不交叉加载规则）
- §6 主会话职责：从 7 条精简为 3 条（只保留与前面不重叠的：派发约束、异常处理、不重复建分支）
- §7 Deploy 规则：确认使用情况后决定去留
- 预计可精简约 20-30 行（-11%~-16%）
2.2 merge_checklist.md（25 行）
| # | 规则 | 分类 | 建议 |
|---|---|---|---|
| 26 | "只有用户明确同意后才可合并" | 有效约束 | 保留 — 安全红线 |
| 27 | "执行主体为主会话，不是 QA" | 有效约束 | 保留 — 防止 QA 越权 |
| 28 | 7 步合并 SOP | 有效约束 | 保留 — 具体可执行 |
| 29 | "冲突时立即中断" | 有效约束 | 保留 — 安全规则 |
| 30 | "参考 CLAUDE.md 分支策略" | 天然行为 | 保留 — 提醒作用 |
merge_checklist.md 评价：精炼高效，无冗余，无需改动。
2.3 framework_protection.md（91 行）
| # | 规则 | 分类 | 建议 |
|---|---|---|---|
| 31 | 框架是什么（解释性） | 天然行为 | 保留 — 给新 AI 会话的上下文 |
| 32 | Marker 机制说明 | 有效约束 | 保留 — 核心机制说明 |
| 33 | 双向同步说明 | 有效约束 | 保留 |
| 34 | upgrade.sh 参数表 | 有效约束 | 保留 — 实用参考 |
| 35 | 框架级 vs 项目级分类标准 | 有效约束 | 保留 — 核心判断依据 |
| 36 | 不确定时告知用户 | 天然行为 | 可精简 — AI 天然会做，但明确说出也没坏处 |
| 37 | 如何添加 marker | 有效约束 | 保留 — 操作步骤 |
| 38 | 告知用户联系基础设施组 | 天然行为 | 保留 — 社交流程需要明确说 |
framework_protection.md 评价：以说明性内容为主，不是行为约束。设计合理，无需改动。
2.4 PM Agent（145 行）
| # | 规则 | 分类 | 建议 | 理由 |
|---|---|---|---|---|
| 39 | "No Spec No Code" | 有效约束 | 删除 | 与 project_rule.md §5 重复 |
| 40 | "禁止写代码" | 有效约束 | 保留 | PM 有 Write/Edit 工具（写 .md），需明确边界 |
| 41 | "保持沟通：遇到模糊地带主动提问" | 愿望性指导 | 改写 | "模糊"无法定义。改为具体场景："如果用户未说明字段是必填还是选填，必须提问" |
| 42 | "需求精度决定下游质量" | 愿望性指导 | 删除 | 设计理念，不是可执行指令 |
| 43 | "路径校验" | 有效约束 | 提取为通用规则 | 5/7 Agent 有相同规则，应只出现一次 |
| 44 | 绝对禁止事项（4 条） | 混合 | 精简 | "禁止执行 Bash"是天然行为（PM 无 Bash 工具）；"禁止产出技术设计"与 project_rule.md 重复 |
| 45 | 三种模式（后端/前端/全栈） | 有效约束 | 保留 | 定义清晰的产出物差异 |
| 46 | 工作流程（5 步） | 有效约束 | 保留 | 具体可执行 |
| 47 | 产出自检 | 有效约束 | 保留 | P0 新增，有结构化格式 |
2.5 Arch Agent（226 行）
| # | 规则 | 分类 | 建议 | 理由 |
|---|---|---|---|---|
| 48 | "No Unreviewed Code：必须深入阅读现有代码" | 愿望性指导 | 改写 | "深入"无法衡量。改为具体动作："必须列出所有相关的 Controller/Service/Mapper 文件路径" |
| 49 | "禁止直接开发" | 有效约束 | 保留 | Arch 有 Write/Edit 工具，需明确边界 |
| 50 | "全栈视图：必须同时调研两侧" | 愿望性指导 | 改写 | 改为具体动作："全栈模式下，后端和前端的研究清单都必须完成" |
| 51 | "DB 现状查询：通过 MCP 执行 SELECT/SHOW/DESCRIBE" | 有效约束 | 保留 | 具体可执行 |
| 52 | "Codemap 维护" | 愿望性指导 | 改写 | "复杂场景"未定义。改为可判断的条件："涉及 2+ package 或调用链超 3 层时必须产出 codemap" |
| 53 | "设计即契约：Dev/FE 直接按此执行" | 有效约束 | 保留 | 质量标准 |
| 54 | "路径校验" | 有效约束 | 提取为通用规则 | 冗余 |
| 55 | 研究清单（后端 5 项 / 前端 5 项） | 有效约束 | 保留 | 具体可执行 |
| 56 | Part A/B/C/D/E 产出格式 | 有效约束 | 保留 | 详细模板，核心价值 |
| 57 | 绝对禁止事项（4 条） | 混合 | 精简 | "禁止修改代码"与规则 #49 重复 |
| 58 | 设计自检（5 项） | 有效约束 | 保留 | P0 新增 |
| 59 | Part E 模板参考（40+ 行） | 有效约束 | 考虑提取为 Skill | 模板内容较长，可引用 spec-templates Skill 而非内联 |
2.6 Dev Agent（112 行）
| # | 规则 | 分类 | 建议 | 理由 |
|---|---|---|---|---|
| 60 | "Spec is Truth, Design is Guide" | 有效约束 | 精简为引用 | 与 project_rule.md 哲学重复，保留口诀但不需要展开解释 |
| 61 | "发现问题立即停止" | 有效约束 | 保留 | 常见违规行为，反复强调有价值 |
| 62 | "YAGNI/KISS" | 愿望性指导 | 保留具体条款 | "严禁过度设计"是愿望性的，但"简单CRUD禁止创建无业务逻辑的Service"是具体可执行的。保留后者，删除前者 |
| 63 | "证据落盘" | 有效约束 | 保留 | 具体可验证 |
| 64 | "合并流程" | 有效约束 | 删除 | 与 merge_checklist.md 重复，改为引用 |
| 65 | "路径校验" | 有效约束 | 提取为通用规则 | 冗余 |
| 66 | Research 步骤 | 有效约束 | 保留 | 具体可执行 |
| 67 | TDD 循环（RED/GREEN/REFACTOR） | 愿望性指导 | 保留但降低期望 | AI 不会可靠遵循 TDD，但循环结构本身有助于代码质量。作为推荐流程保留，不作为硬约束 |
| 68 | 两阶段自查（Compliance + Quality） | 有效约束 | 保留 | 核心质量保证机制 |
| 69 | 04_test_plan 产出 | 有效约束 | 保留 | 具体可验证 |
| 70 | 异常处理（3 种情况） | 有效约束 | 保留 | 具体可执行 |
2.7 FE Agent（125 行）
与 Dev Agent 结构高度对称，分析结论一致：
| # | 独有差异 | 建议 |
|---|---|---|
| 71 | "强制规范对齐：严格遵循前端编码规则" | 愿望性指导 → 改为"必须通过 npm run lint 验证" |
| 72 | Quality 检查中的前端特定项（scoped、Dialog 重置等） | 有效约束 → 保留，这些是前端常见遗漏 |
| 73 | 04 Part B 为"人工验证清单"（非 curl） | 有效约束 → 保留，前后端差异合理 |
2.8 QA Agent（132 行）
| # | 规则 | 分类 | 建议 | 理由 |
|---|---|---|---|---|
| 74 | "绝对独立性" | 愿望性指导 | 保留 | 虽然无法强制，但反复强调有心理暗示效果 |
| 75 | "严格只读" | 有效约束 | 保留 | QA 有 Write/Edit 工具（写审查报告），需明确"只读"是指不修改业务代码 |
| 76 | "01+02 是审查标准" | 有效约束 | 保留 | 明确审查依据 |
| 77 | "极速审查" | 愿望性指导 | 改写 | "无复杂业务逻辑的微小变更"未定义。改为可判断的条件："变更文件数 ≤ 3 且无新增 API 端点时，可跳过构建验证" |
| 78 | "路径校验" | 有效约束 | 提取为通用规则 | 冗余 |
| 79 | 四轴/五轴审查框架 | 有效约束 | 保留 | 框架核心价值 |
| 80 | 测试审计（6 项） | 有效约束 | 保留 | 具体可执行 |
| 81 | 审查自检（5 项） | 有效约束 | 保留 | P0 新增 |
| 82 | API 契约一致性（第五轴）的具体规则 | 有效约束 | 保留 | 针对实际踩坑经验的约束 |
2.9 Prototype Agent（95 行）
| # | 规则 | 分类 | 建议 | 理由 |
|---|---|---|---|---|
| 83 | "Spec is Source" | 有效约束 | 保留 | 明确输入来源 |
| 84 | "直接实现" | 天然行为 | 删除 | AI 天然会直接做，不需要告诉它"直接做" |
| 85 | "只写原型文件" | 有效约束 | 保留 | 范围约束 |
| 86 | "风格一致：必须使用项目已有的公共组件" | 愿望性指导 | 改写 | "风格一致"无法验证。后面的组件替代表是有效约束，保留表、删口号 |
| 87 | "路径校验" | 有效约束 | 提取为通用规则 | 冗余 |
| 88 | 组件替代表 | 有效约束 | 保留 | 具体实用 |
| 89 | 可直接使用的组件列表 | 有效约束 | 保留 | 具体实用 |
2.10 E2E Runner（191 行）
| # | 规则 | 分类 | 建议 | 理由 |
|---|---|---|---|---|
| 90 | "只读 Spec，不改代码" | 有效约束 | 保留 | 范围约束 |
| 91 | "POM 优先"、"data-testid 优先" | 有效约束 | 保留 | 具体可执行 |
| 92 | 故障分类 A/B | 有效约束 | 保留 | 最有价值的设计——精确区分"测试代码问题"和"业务代码问题" |
| 93 | 认证 Setup（sessionStorage + AES 加密 + OCR） | 死规则/有效约束 | 下沉到 Skill | 高度项目特定，不属于 core/ |
| 94 | qiankun 微前端等待策略 | 死规则 | 下沉到 Skill | 非 qiankun 项目无用 |
| 95 | Element UI 特定选择器知识 | 死规则 | 下沉到 Skill | 非 Element UI 项目无用 |
| 96 | 截图命名规范 | 有效约束 | 保留 | 通用可执行 |
E2E Runner 核心问题：191 行中约 110 行（~60%）是特定技术栈（qiankun + Element UI + AES + OCR）的实现细节。这些内容应下沉到 e2e-testing Skill，Agent 定义中只保留通用的流程和故障分类框架。
三、冗余热力图
以下规则在多个文件中重复出现：
| 规则 | 出现位置 | 重复次数 | 建议 |
|---|---|---|---|
| "路径校验" | PM/Arch/Dev/FE/QA/Prototype (6处) | 6 | 提取到 project_rule.md §6 作为通用规则 |
| "No Spec No Code" | project_rule + PM | 2 | 只保留 project_rule |
| "禁止写/修改代码" | PM/Arch/Prototype 各自的禁止事项 | 3 | 保留各 Agent 独立声明（Agent 可能单独加载） |
| "合并流程" | Dev/FE Agent + merge_checklist | 3 | Agent 中改为引用 merge_checklist |
| "发现问题立即停止" | Dev/FE 的行为准则 + 异常处理 | 2+2 | 保留 Agent 中的详细版本，删除概要版 |
注意：Agent 文件在运行时可能独立加载（而非与 project_rule.md 一起），因此部分重复是有意的（确保 Agent 单独运行时也有完整上下文）。关键区分：
- Agent 独立加载时的必要重复 → 保留（如"禁止写代码"、"发现问题停止"）
- 始终一起加载时的无意义重复 → 合并（如"路径校验"在所有 Agent 中逐字重复）
四、精简行动清单
立即可做（预计节省 ~200 行，-15%）
| # | 行动 | 影响文件 | 节省估计 |
|---|---|---|---|
| A1 | "路径校验"提取为通用规则：从 6 个 Agent 中移除，在 project_rule.md §6 加一条"所有 Agent 写入文件前必须校验路径" | project_rule + 6 Agents | ~30 行 |
| A2 | PM 删除"No Spec No Code"：与 project_rule 重复 | pm-agent.md | ~1 行 |
| A3 | PM 删除"需求精度决定下游质量"：愿望性指导 | pm-agent.md | ~1 行 |
| A4 | Dev/FE 删除"合并流程"引用：改为"按 merge_checklist.md 执行" | dev/fe-agent.md | ~4 行 |
| A5 | project_rule §5 合并重复禁止事项：从 6 条减为 3 条 | project_rule.md | ~6 行 |
| A6 | project_rule §6 精简主会话职责：移除与前面重叠的 4 条 | project_rule.md | ~8 行 |
| A7 | E2E Runner 项目特定内容下沉到 Skill：认证、qiankun、Element UI 选择器 → e2e-testing Skill | e2e-runner.md + e2e-testing Skill | ~110 行（Agent 减少，Skill 增加） |
| A8 | Arch Part E 模板提取为 Skill 引用：40+ 行模板内联改为引用 spec-templates | arch-agent.md | ~35 行 |
| A9 | Prototype 删除"直接实现"：天然行为 | prototype-agent.md | ~1 行 |
需验证后做（基于遵从度实测数据）
| # | 行动 | 前置条件 |
|---|---|---|
| B1 | 评估"路由自检 checkpoint"有效性 | 实测路由准确率 |
| B2 | 评估"产出自检"有效性 | 对比有/无自检的 Spec 质量 |
| B3 | 评估愿望性指导改写后的效果 | 将 3-5 条改写为具体动作，实测对比 |
| B4 | 决定 Deploy 规则去留 | 收集使用数据 |
不建议做
| # | 行动 | 原因 |
|---|---|---|
| C1 | 删除 Agent 中的"禁止写代码" | Agent 可能独立加载，需要完整上下文 |
| C2 | 删除 merge_checklist.md | 精炼高效，无冗余 |
| C3 | 删除 framework_protection.md | 说明性内容，对 AI 理解框架机制有价值 |
| C4 | 大幅精简 Arch 的 Part E 模板 | 模板虽长但具体可执行，精简风险大于收益 |
五、结论
核心判断
- 框架的 70% 规则是有效约束，核心价值扎实
- 最大的优化空间不是"删规则"而是"去冗余"：同一规则在多文件中重复出现是 token 浪费的主因
- 愿望性指导占比不高（12%），但需要改写而非直接删除——它们识别了真实问题（"深入调研"、"严格遵循"），只是表述不够具体
- E2E Runner 的技术栈绑定是最突出的架构问题，应优先处理
下一步
- 执行 A1-A9 精简行动 → 预计节省 ~200 行
- 执行遵从度实测（compliance-tests.md 16 个用例）→ 建立基线
- 基于实测数据做 B1-B4 验证后精简 → 数据驱动