# 审查闸门使用指南

适用范围：`D:\AI Code\3danzhuang` 全仓库。  
目标：保留“规范审查员”这条硬规则，并把它稳定落成当前默认流程中的强制闸门。

---

## 1. 为什么改成现在这样

之前的问题不在“有没有规则”，而在“把动态运行时工具硬套成固定编制组织架构”。

实际痛点有两个：
- 任务派不出去：运行时 ID 会变，跨会话复用不稳定
- Agent 越开越多：规则文档能提醒，但不能代替底层调度器

因此现在收敛成：
- 默认按当前会话直接开发
- 规范审查为强制闸门
- 安全 / 性能 / QA 按任务风险追加

---

## 2. 当前默认流程

### 第一步：开始前先说清楚

至少明确 4 件事：
1. 目标是什么
2. 验收标准是什么
3. 这次要遵守哪些标准文件
4. 根因大概率在哪条链路上

### 第二步：开发

要求：
- 优先复用现有实现
- 优先根因修复
- 不顺手修一堆无关问题
- 不做只压报错的临时补丁

### 第三步：最小验证

先做和本次改动直接相关的验证，再决定要不要扩大到更大范围。

### 第四步：规范审查

交付前必须单独做一次“规范审查”，固定检查：
- 企业级架构标准
- 统一视觉标准
- 是否为根因修复

没有这一步，就不能宣告完成。

### 第五步：按风险追加其他审查

以下情况要补充：
- 安全风险链路 → 安全审查
- 性能敏感链路 → 性能审查
- 关键用户操作 / 回归风险 → QA 验证

---

## 3. “规范审查员”现在是什么意思

“规范审查员”现在是一个**流程角色**。

也就是说：
- 它必须存在
- 但不要求永远是某个固定 Agent
- 默认可以直接进入“规范审查阶段”执行
- 如果用户明确要求独立复审，且当前环境支持，再临时拉起独立审查 Agent

这样可以把你最在意的硬规则稳定落到每次交付的固定步骤里。

---

## 4. 什么时候算通过

规范审查结论只能是：
- `passed`
- `passed with warnings`
- `rejected`

其中只要出现下面任意一种情况，就必须 `rejected`：
- 架构分层被破坏
- 统一视觉标准跑偏
- 明显是补丁式修复，没有修根因

---

## 5. 推荐查看顺序

1. `docs/workflow/最简执行卡片.md`
2. `docs/workflow/规范审查清单.md`
3. `furniture-3d-system/.cursor/rules/*.mdc`
4. `furniture-3d-system/docs/设计规范/苹果风格视觉标准.md`