---
name: role-审核者-系统破坏
description: 系统破坏审核者（关卡B）。关键词：架构审核/安全审查/系统破坏/压力测试/关卡B/技术审核/漏洞/可演化性。在技术架构完成后、代码开始前触发。扮演黑客/极端用量测试者找出架构弱点。
---

# 审核者：系统破坏视角（关卡B）

> **触发时机**：技术架构.md 完成后，代码开始之前。
> **目的**：找出架构中的静默失败点、权限漏洞、可演化性死角。
> **通过条件**：没有致命漏洞，或漏洞已记录并有规避方案。

---

## 知识导航表（审核前必须按顺序读取）

| 层级 | 文档 | 用途 |
|---|---|---|
| **D0 认知根确认** | `_内部总控/认知结构/L1.5_底层原则层/底层原则库.md`（P1~Pn 全部已确认原则）| **先于一切**：以已确认 L1.5 原则为审核标准——此架构是否违反任一已确认原则？违反哪条原则是本次关卡B 的主要发现依据。带此问题进入审核 |
| ① 元项目顶层 | `_内部总控/元项目导航.md` | 了解元项目边界和顶层约束 |
| ② 被审核架构 | `项目群/[项目]/技术架构师/技术架构.md` | 审核对象（必须完整读完）|
| ③ 任务层文档 | `项目群/[项目]/产品经理/产品定义.md` | 了解产品需求背景 |
| ④ 总规范库 | `_内部总控/开发规范/AI调用服务器助手接口规范.md` | 接口安全规范 |
| ⑤ 角色专属 | `.cursor/skills/role-审核者-系统破坏/` | 历史审核案例（如有）|

## 元认知前置（每次激活后必须先回答）

执行审核前，必须回答以下三个问题（F-028）：
1. **有没有更好的方法？** 有没有比「走常规测试路径」更能发现破坏点的方式？
2. **是否考虑全面了？** 我是否覆盖了安全/性能/数据一致性/可演化性四个维度？
3. **是否需要先搜索？** 有没有同类架构的已知CVE或失败模式值得参考？

---

## ⚠️ 核心认知差异

**你不是技术架构师**，不要为架构方案辩护。

| 维度 | 技术架构师（创作者）| 系统破坏（审核者）|
|---|---|---|
| 思维模式 | 建构性——设计一个能工作的系统 | **破坏性**——找出系统在什么条件下会失败 |
| 视角 | 内部视角——"这个架构能实现什么" | **外部视角**——"这个架构有什么弱点" |
| 工作方式 | 正向推演——从需求到方案 | **逆向推演**——从失败场景反推漏洞 |
| 扮演角色 | 系统设计者 | **黑客 + 极端用量测试者 + 未来维护者** |

---

## 执行流程

```
Step 1  Read: 技术架构师/技术架构.md（已经 PM 确认过的版本）

Step 2  调用 /arch-destroyer 子智能体（前台，等待完成）
        传入：
        - 技术架构文档内容（文本形式）
        - 产品核心场景描述（从产品定义中提取的关键用户场景）

        【为什么用子智能体】
        系统破坏审核者必须与架构师上下文完全隔离。
        主 Agent 带有架构设计的全部推理过程，会无意中为方案辩护。
        子智能体从干净上下文启动，以黑客/极端用量视角独立审查，
        确保破坏性视角真正有效。

Step 3  子智能体返回审核报告，主 Agent 不修改审核结论，原样写入文件
        → 报告写入：技术架构师/关卡B审核报告_YYYYMMDD.md
        → 发现的技术漏洞同时写入 技术架构师/技术问题追踪台.md（调用 issue-tracker Skill）

Step 4  发现致命漏洞 → 回架构师修复
        发现可接受风险 → 记录并有规避方案 → 通过关卡B
        所有检查通过 → 允许开始写代码
```

---

## 必问清单（通用部分）

> 扮演"想找出系统弱点的攻击者/极端用量测试者/六个月后的维护者"来回答。

| # | 问题 | 检测目的 |
|---|---|---|
| B-01 | 有没有任何 DB 写入函数使用了 `:param::jsonb` 语法？ | JSONB 参数静默丢失（真实踩坑） |
| B-02 | 所有需要登录的路由，覆盖了"用户从未登录"和"token 过期"两种状态吗？ | 认证边界完整性 |
| B-03 | JWT payload 里的用户 ID 字段叫什么？`sub`？`id`？`user_id`？业务代码统一了吗？ | 字段约定一致性（真实踩坑）|
| B-04 | 有没有任何函数/变量名称承诺了某种实现（如 `_with_llm`），但实际是简化版本？ | 命名诚实性（真实踩坑）|
| B-05 | 多用户场景：用户A的数据能出现在用户B的查询结果里吗？所有查询都有 `WHERE user_id = :id` 过滤吗？ | 数据隔离 |
| B-06 | SSE 流式输出：如果中间某个步骤抛出异常（DB 失败、LLM 超时），前端会收到错误提示，还是静默关闭（永远转圈）？ | 错误可见性（真实踩坑）|
| B-07 | 如果 LLM API 挂了，系统如何降级？降级后用户看到什么？ | 容错性 |
| B-08 | 前端 vite 代理端口与后端 BACKEND_PORT 是否完全对齐？ | 配置一致性（真实踩坑）|
| B-09 | schema.sql 中的跨 schema 引用（如 `topiclab.users`），在目标数据库里实际存在吗？ | Schema 引用正确性（真实踩坑）|
| B-10 | 技术架构图中定义的模块和目录结构，在实际代码里都有对应实现吗？缺少的模块影响哪些功能？ | 架构-实现对齐（真实踩坑）|
| B-11 | 6个月后，如果要新增一个功能，数据模型需要怎么改？会影响多少现有代码？ | 可演化性 |
| B-12 | 所有环境变量，如果缺少某一个，系统在启动时会立即报错，还是在运行时静默失败？ | 环境变量验证 |
| **B-13** | **本次架构的核心设计决策（数据模型/模块划分/状态管理方式），是否违反了 L1.5 已确认的任何原则（如 P11 DRY、P12 最小必要限制、P17 API消费者约束）？** | **L1.5 原则合规性（新增）** |

---

## 扮演三类破坏者

### 黑客视角
```
尝试越权访问：用户A的 token 能访问用户B的资源吗？
尝试绕过认证：有没有忘记加 Depends(get_current_user) 的路由？
尝试注入攻击：SQL 参数都是参数化的，没有字符串拼接吗？
尝试资源滥用：能不能通过循环调用消耗所有 LLM 配额？
```

### 极端用量视角
```
100个并发用户同时请求，数据库连接池够用吗？
用户发送 10000 字的消息，系统能处理还是超时？
AI 推理时间超过 2 分钟，SSE 连接会超时断开吗？
磁盘满了或内存不足时，系统优雅降级还是崩溃？
```

### 六个月后的维护者视角
```
新人接手这个代码库，能在1天内理解架构吗？
新增一个功能，需要修改几个文件？是否有合理的模块边界？
数据模型有没有预留扩展空间？
有没有循环依赖或者难以测试的全局状态？
```

---

## 关键技术踩坑检查（来自真实案例）

### JSONB 参数绑定检查（B-01）

```python
# 架构审核时，检查数据层代码中是否有以下危险模式：

# ❌ 危险：参数静默丢失
text("INSERT INTO t (state) VALUES (:state::jsonb)")
# ✅ 安全：使用 CAST
text("INSERT INTO t (state) VALUES (CAST(:state AS jsonb))")
```

### 认证边界完整性（B-02, B-03）

```python
# 检查：所有路由是否都有认证依赖
# 检查：JWT payload 字段是否统一规范化

# 必须有 _normalize_user 处理 sub/id 不一致问题
def _normalize_user(payload):
    if "id" not in payload and "sub" in payload:
        payload["id"] = int(payload["sub"])
    return payload
```

### SSE 错误处理（B-06）

```python
# 检查：SSE generator 是否有全局 try/except
def generate():
    try:
        for event in run_agent():
            yield f"data: {json.dumps(event)}\n\n"
    except Exception as e:
        yield f"data: {json.dumps({'type': 'error', 'content': str(e)})}\n\n"
    finally:
        yield "data: [DONE]\n\n"
```

---

## L1.5 原则合规性检查（新增，认知根原则落地）

> 技术架构不仅要通过技术安全审查，还要与认知结构中已确认的底层原则保持一致。
> 读取 L1.5 底层原则库后，逐条检查架构设计是否违反已确认原则。

| 原则 | 架构中的表现 | 合规 | 备注 |
|---|---|---|---|
| P11 DRY（复用优先） | 有没有重复实现已有公共模块？ | ✅/❌ | |
| P12 最小必要限制 | 权限设计是否遵循「消费者不需要的权限不给」？ | ✅/❌ | |
| P17 API消费者约束（若已确认）| 接口设计是否从消费者视角出发？ | ✅/❌/N/A | |
| 其他已确认原则 | 根据 D0 步骤读取的原则库，逐条检查 | — | |

**说明**：
- 违反原则 → 在审核报告「致命漏洞」或「已记录风险」中注明，附原则编号
- 原则库中没有直接覆盖的技术决策 → 正常审查其他维度，不强行归因

---

## 审核报告格式

> **报告必须写入文件**：`技术架构师/关卡B审核报告_YYYYMMDD.md`
> 发现的致命漏洞和可接受风险同时通过 issue-tracker Skill 写入 `技术架构师/技术问题追踪台.md`。
> 不允许只在对话中输出，不写文件。

```markdown
## 关卡B 审核报告 · [产品名] · YYYY-MM-DD

**审核视角**：系统破坏（黑客 + 极端用量 + 六个月后维护者）
**覆盖范围**：[本次审核覆盖的架构范围]

### 致命漏洞（必须修复才能开始写代码）

| # | 漏洞描述 | 检查项 | 修复建议 | 已写入追踪台 |
|---|---|---|---|---|
| 1 | [描述] | B-XX | [修复方向] | ✅/❌ |

### 已记录风险（有规避方案，可接受）

| # | 风险描述 | 严重程度 | 规避方案 | 已写入追踪台 |
|---|---|---|---|---|
| 1 | [描述] | 高/中/低 | [方案] | ✅/❌ |

### 通过的检查项

- [B-01] ✅ JSONB 语法：已使用 CAST 语法
- [B-02] ✅ 认证边界：所有路由均有认证依赖
- [B-05] ✅ 数据隔离：所有查询均有 user_id 过滤
- ...

### 结论

**通过** ✅：没有致命漏洞，允许进入代码阶段
**不通过** ❌：以下致命漏洞需要修复：
- [漏洞列表]
```

---

## 关键强制规则

> **技术架构草稿必须先回 PM 确认，再进行系统破坏审核，最后才能下发给开发。**

流程：
```
架构师完成草稿 → PM 确认（防技术偏离产品意图）→ 关卡B（系统破坏审核）→ 下发开发
```

如果技术架构跳过了 PM 确认直接下发开发，是严重的流程违规。

---

## 变更记录

### 2026-03-22 — v1.2 → v1.3 — D0 认知根 + B-13 L1.5原则合规检查 + 原则合规表

**根因**：Skill体系设计原则_v1.0.md §4.3.5（认知根原则）要求关卡B在审核架构时，除检查技术安全性外，还应检查「架构是否违反已确认的 L1.5 原则」。当前关卡B只做技术层审查，不检查原则合规性。

**修改内容**：
- 新增：知识导航表 D0 行——先读 L1.5 底层原则库 + L1 架构原则文档，带原则合规问题进入审核
- 新增：必问清单 B-13——架构核心决策是否违反 L1.5 已确认原则
- 新增：「L1.5 原则合规性检查」独立表格

**验证结果**：
- 正向验证：关卡B 审核报告包含 B-13 和原则合规性表（待验证）
- 负向验证：技术安全类检查（B-01~B-12）不变

**备份路径**：`history/SKILL_v1.2_20260322.md`

---

### 2026-03-19 02:10 — 断点1修复：审核报告写入固定路径 + 问题写入追踪台

**根因**：同关卡A，报告只活在对话里，漏洞无法持久化追踪。

**修改内容**：
- 修改：执行流程 Step 4 → 报告必须写入 技术架构师/关卡B审核报告_YYYYMMDD.md，同时调用 issue-tracker 写入追踪台
- 修改：审核报告格式 → 加入「必须写入文件」说明，表格新增「已写入追踪台」列

**验证结果**：
- 正向验证：执行关卡B后，技术架构师/ 目录下应有审核报告，追踪台应有对应条目


---

## 经验感知钩子

> 本节由 uto-experience-hook Rule 驱动，此处为提示性说明。

执行本 Skill 过程中，若触发以下任一信号，立即追加一行到暂存区（不中断主任务）：
- **踩坑**：遇到错误且踩坑速查中找不到解决方案，最终找到了正确做法
- **新发现**：完成了某个当前 Skill 流程未覆盖的步骤，且未来会重复用到
- **步骤偏差**：Skill 描述的步骤顺序/内容与实际执行不符
- **缺失 Skill**：遇到某类任务没有对应 Skill，只能凭经验执行

暂存格式（追加到 .cursor/skills/skill-index/PENDING-EXPERIENCES.md）：
`
| [今日日期] | [本Skill目录名] | [信号类型] | [一句话描述经验内容] | 🔲 待处理 |
`

**所有执行步骤完成后**，检查暂存区是否有新增条目。若有，在收尾时告知用户：
「本次执行感知到 N 条经验（已暂存），任务确认跑通后可说「做一次项目复盘」处理。」

**⚠️ 强制收尾——写入任务日志（不可省略，不可等用户提示）**：

执行顺序铁律：先工具调用 → 确认成功 → 告知用户。**禁止声称「已写入」而未实际调用工具。**

```
1. [工具调用-读取] grep 今日 TASK-YYYYMMDD 全部条目，取最大序号 NN → 新序号 = NN+1
2. [工具调用-写入] StrReplace 追加到 `_内部总控/任务日志.md`：
   本次 Skill 执行的核心操作 + 创建/修改的文件 + 用户原始需求 + 遗留事项
3. 工具调用成功 → 输出「📝 任务日志已写入 [TASK-YYYYMMDD-NN]」
   工具调用报错 → 输出「⚠️ 任务日志写入失败，请手动检查任务日志.md」
```

---

## 变更记录（续）

### 2026-03-19 — v1.1 → v1.2 — 关卡B 改为调用 arch-destroyer 子智能体

**根因**：同关卡A，产品文档要求创作型与审核型必须视角隔离。arch-destroyer 子智能体已存在，本次将关卡B流程改为调用它，确保破坏者视角不被架构设计上下文污染。

**修改内容**：
- 修改：执行流程 Step 2 → 从「主 Agent 扮演三类破坏者」改为「调用 /arch-destroyer 子智能体（前台）」
- 修改：Step 3 → 接收子智能体结果，原样写入报告文件

**验证结果**：
- 正向验证：触发关卡B，AI 应启动 arch-destroyer 子智能体（待真实场景验证）
- 负向验证：关卡B 的报告格式、写入路径、issue-tracker 调用逻辑不变

**验证状态**：✅ 已验证（2026-03-19 arch-destroyer 子智能体执行 tashan-openbrain 关卡B：发现致命漏洞×5/重要缺陷×7，安全审查有效）

### 2026-03-22 — v1.2 → v1.3 — 双D0 → 单D0（角色认知根系统性审计修复）

**根因**：审计发现关卡B D0 同时列了两个文档（底层原则库 + Skill体系设计原则），违反单D0原则。关卡B 的本质是「以已确认 L1.5 原则为标准审核架构」，认知根应唯一指向 `底层原则库.md`（L1.5）。`Skill体系设计原则` 是 Skill 设计的，无需在关卡B D0 中出现。

**修改内容**：
- 修改：D0 行 → 移除 `Skill体系设计原则_v1.0.md`，保留唯一文档 `底层原则库.md`，并明确审核逻辑：以 L1.5 原则为标准，架构是否违反任一原则是主要发现依据

**备份路径**：`history/SKILL_v1.3_20260322_before_d0fix.md`

**验证状态**：🔵 待验证（关卡B 激活时 D0 应唯一指向底层原则库，不再包含 Skill 设计原则）