AirCoding/AirPlan/docs/开发阶段多模型交叉审计报告.md

AirCoding V1.0.0 Alpha — 开发阶段多模型交叉审计报告

报告类型: 多模型交叉审计综合（Meta-Audit） 生成日期: 2026-06-03 审计分支: GLM5-Achieve 代码规模: 7 包 / 146 源文件 (137 TS + 9 TSX) / 123 实现任务 (T-001..T-809) 参审模型: 4 个独立审计模型

模型	报告文件	评级	发现总数	阻断级	审计角度
DeepSeek	Deepseek开发阶段审计.md	B+	97	10	阶段级 + 问题计数
Opus 4.8	Opus开发阶段审计.md	C+	140+	18	逐字段对照规范
MiniMax-M3	MiniMaxM3开发阶段审计.md	C+	38+	18	可执行性 + 治理
Qwen3.7-Max	Qwen3.7开发阶段审计.md	骨架就位/语义偏差	84 (31C+22H+19M+12L)	31	需求覆盖 + 规范一致性%

---

0. 综合结论（四模型共识）

0.1 一致裁决

四个独立审计模型在以下核心判断上完全一致： AirCoding V1.0.0 Alpha 当前处于 「架构骨架与基础设施质量高，但核心运行时子系统语义大面积偏离冻结基线」 的状态。 不应在当前状态下发布；必须先关闭阻断级缺陷。

维度	四模型一致结论
基础设施层	✅ Monorepo / SQLite Schema / 事件注册表 / Enum 验证 / 依赖方向 — 质量高
契约层	⚠️ contracts 编码良好，但下游系统性重定义本地类型、不 import 契约（Opus + Qwen 明确，DeepSeek + M3 印证）
执行链路	❌ Scheduler / IPC / Security / Context / TUI / outbox — 语义偏离或链路断裂
安全	❌ 3 处命令注入 + 权限旁路 + 弱加密密钥（四模型均独立发现命令注入）
可发布性	❌ 四模型均判定不可发布

0.2 评级谱系

DeepSeek  B+  ████████░░  (乐观：文件齐全=骨架完整)
Opus 4.8  C+  █████░░░░░  (严格：逐字段不符规范)
MiniMax   C+  █████░░░░░  (务实：接口在但链路断)
Qwen3.7   D+  ████░░░░░░  (最严：规范一致性平均<45%)
─────────────────────────
综合评级  C   █████░░░░░  (骨架B级 / 执行链路D级)

评级分歧根源：DeepSeek 以"实现计划任务完成度"（123/123 文件创建）为主轴 → B+；其余三模型以"与冻结规范的语义一致性"为主轴 → C+/D+。Meta 裁决采纳后者：文件存在 ≠ 语义正确，综合评级 C（骨架 B / 执行 D）。

---

1. 阻断级缺陷交叉确认矩阵

下表汇总四模型发现的阻断级（P0/CRITICAL）缺陷。≥2 模型独立确认的缺陷置信度最高，列为「高置信阻断项」。

1.1 高置信阻断项（≥3 模型确认 — 必须立即修复）

#	缺陷	位置	DeepSeek	Opus	M3	Qwen	置信度
B1	EventStore.project() 事务边界违反（_tx 不传仓库，域表写在事务外）	EventStore.ts	—	⚠️	—	✅ F-04	2/4 ⭐⭐⭐
B2	workspace 投影写非法枚举 'created'/'merging' → 首次创建即崩溃	EventStore.ts:900,909	—	✅#1	✅	✅ F-05	3/4 🔴
B3	项目级 DB（debug/learned-memory）表名/路径/列全面偏离 db-schema §20	DebugKnowledgeStore.ts, LearnedMemoryStore.ts	⚠️	✅#2	✅	✅ F-01/F-02	4/4 🔴🔴
B4	route_prefix 查询用 . 拼接但存储用 / → 前缀过滤永久失效	EventRepository.ts:185	—	✅#3	✅	✅ F-07	3/4 🔴
B5	TaskAttemptRepository 列映射 bug（检查 signature 却写 summary 列）	TaskAttemptRepository.ts:114	—	✅#4	✅	✅ F-06	3/4 🔴
B6	ToolRegistry 权限上下文硬编码 undefined → 权限模型被旁路	ToolRegistry.ts:262-263	—	✅#5	⚠️	✅ §5.4	3/4 🔴🔴
B7	ACTION_BRANCHES 内 this.* 调用 → read_only/sandbox 分支运行时崩溃	ToolRegistry.ts:62,72	—	✅#6	—	✅ §5.4	2/4 🔴
B8	命令注入 ×3（CMake/CppBuilder/Cppcheck execSync 字符串拼接）	CMakeConfigurator.ts:48, CppBuilder.ts:30, CppcheckRunner.ts:36	⚠️	✅#10-12	✅	✅ §14.2	4/4 🔴🔴
B9	C++ 工具绕过 PermissionEngine（违反 INV-3）	CppToolRegistrar.ts	—	✅#13	✅	✅ §14.1	3/4 🔴
B10	INV-2 outbox 完全未发事件（debug.record.created / memory.promoted）	wiring.ts:35-73	⚠️	✅#14	✅	—	3/4 🔴
B11	Scheduler 状态机缺 BLOCKED/CANCELLED（多 TERMINATED）	Scheduler.ts:18-29	—	✅#8	✅	✅ §7.1	3/4 🔴
B12	Scheduler 是空壳（不调 WorkspaceManager/WorkerManager/ContextAssembler/EventIngestor）	Scheduler.ts:74-204	—	⚠️	✅	✅ §7.3	3/4 🔴
B13	MainAgent 状态机缺 7/13 状态 + 正则分类非 LLM	MainAgent.ts:13	⚠️	✅#12	✅	✅ §9.1	4/4 🔴
B14	Worker IPC 握手顺序反转 + 信封缺 5 字段	WorkerManager.ts:45-91, WorkerProtocol.ts	—	⚠️	✅	✅ §8.2/8.3	3/4 🔴
B15	TUI 不依赖 OpenTUI（render 走 console.log）+ ProjectionClient↔Store 断连	TuiApp.tsx, ProjectionClient.ts	⚠️	✅#18	✅	✅ §13.2	4/4 🔴

1.2 中置信阻断项（2 模型确认）

#	缺陷	位置	确认模型
B16	ModelConfig.api_key 明文存储（应 auth_ref 间接引用）	ModelConfigLoader.ts:17	Opus#7 + Qwen §11.2
B17	DeveloperLogEncryptor 硬编码弱密钥 'dev-key'	DeveloperLogEncryptor.ts:22	Opus#15 + M3
B18	CapabilityTrustLevel 用错误枚举值（core/trusted vs 规范 5 级）	CapabilityManifestValidator.ts:19	Opus#16 + Qwen §6.1
B19	PermissionEngine 缺 block/refuse/announce_then_run 动作	PermissionEngine.ts:19-26	Opus#17 + Qwen §4.3
B20	WorkerProcess 退出码 4 错配（blocked vs 规范 parent-cancelled）	WorkerProcess.ts:17,30	Opus#9 + M3
B21	CLI init 直接写 FS 绕过 ToolRegistry（违反 INV-3）	cli/commands/init.ts	M3 + Qwen §15.2
B22	CommandRiskAnalyzer 'sudo_likely' in trimmed 永远 false	CommandRiskAnalyzer.ts	Qwen §4.2（单模型深挖，逻辑确凿）

1.3 单模型独有阻断项（需复核）

#	缺陷	来源	说明
B23	e2e 命令 hardcoded 全 ✅ 不跑测试（release gate 形同欺骗）	M3 独有	治理问题，价值归零
B24	project_id 用 Date.now() 而非 stable UUID	M3 独有	同秒重 init 撞 id
B25	16/28 MVP 工具缺失	Qwen §5.1 独有量化	DeepSeek/Opus 提及但未量化
B26	ContextAssembler L6-L9 四层缺失 + 非 canonical 输出	Qwen §12 + Opus 印证	上下文装配不完整

---

2. 不变量（INV）合规交叉裁决

综合四模型对运行时不变量的判定。任一模型判 FAIL 即标红，多模型一致 PASS 才判绿。

不变量	DeepSeek	Opus	M3	Qwen	Meta 裁决
INV-1 状态列仅经 EventStore.project	✅	⚠️	⚠️	❌(F-04)	❌ FAIL（事务边界 + Scheduler 旁路写 status）
INV-2 跨库 outbox 单写者	⚠️	❌	❌	✅*	❌ FAIL（完成事件从不发出）
INV-3 副作用经 ToolRegistry/PermissionEngine	⚠️	❌	❌	❌	❌ FAIL（CLI init / C++ / 权限旁路）
INV-4 导入方向单向	✅	✅	✅	⚠️(llm不引contracts)	⚠️ 部分（依赖图合规但 llm 本地定义类型）
INV-5 EventBus 仅传输	✅	✅	✅	✅	✅ PASS
INV-6 工件 temp-rename 原子写	—	—	—	✅	✅ PASS
INV-7 Workspace GC 策略	—	—	—	⚠️(SQL bug)	⚠️ 部分
INV-8 Agent heartbeat 持久化	—	—	—	❌(仅内存)	❌ FAIL
INV-9 ExperienceMiner 4 触发路径	—	—	⚠️	❌(0实现)	❌ FAIL
INV-10 read-before-edit 强制	⚠️	—	—	❌	❌ FAIL
INV-11 完成门禁强制	—	—	—	❌	❌ FAIL

INV 合规综合得分：PASS 2 / 部分 3 / FAIL 6。 关键裁决：四模型独立得出 INV-1/2/3 三大核心不变量均不达标——这是评级压到 C 的决定性依据。

---

3. 规范一致性百分比（Qwen 量化 + 三模型印证）

Qwen3.7 提供了唯一的逐文档一致性%量化，其余三模型的定性结论与之高度吻合。

基线文档	Qwen 一致性	其余模型印证	Meta 评估
event-registry-v1	95%	DeepSeek/Opus 均确认 54+7 事件齐全	✅ 高
error-taxonomy-v1	90%	Opus 确认 AirError 匹配	✅ 高
C4 code-view	90%	Opus 确认 contracts 忠实编码	✅ 高
db-schema-v1（会话表）	85%	四模型确认 17 表正确	✅ 高
artifact-naming-v1	80%	—	✅ 中高
cross-platform-matrix	80%	—	✅ 中高
interface-contracts-v1	65%	Opus 列 15 契约缺失	⚠️ 中
solution-architecture	55%	M3 确认链路断	⚠️ 中
prompt-layering-v1	50%	Opus 确认 L5-L9 缺	❌ 低
system-overview-design	50%	M3 确认子系统连接断	❌ 低
main-agent-state-machine	45%	四模型确认缺 7 状态	❌ 低
system-detailed-design	45%	Opus 确认方法签名偏差	❌ 低
tool-registry-v1	40%	Opus/M3 确认工具缺失	❌ 低
runtime-semantics-v1	40%	5/11 不变量违反	❌ 低
scheduler-state-machine	35%	四模型确认状态/方法缺	❌ 低
capability-trust-v1	30%	Opus 确认 trust level 错	❌ 很低
security-model-v1	20%	Opus/M3 确认全面偏差	❌ 很低
provider-capability-matrix	20%	Qwen 确认仅 20% 实现	❌ 很低
scope-escalation-v1	10%	未实现	❌ 极低

加权平均一致性 ≈ 52%。基础设施类文档（80-95%）拉高均值，但核心执行类文档（10-45%）是真实短板。

---

4. 各模型审计角度与独有贡献

4.1 DeepSeek — 阶段级问题计数

• 角度：以 P0-P8 阶段为主轴，逐文件审查 + 跨引用合约 + 不变量检查
• 独有贡献：完整的「合约合规矩阵」「DB 模式合规表」「测试覆盖率<5%」量化
• 盲区：评级偏乐观（B+），未深挖权限旁路、状态机终态等语义级缺陷
• 价值：建立了问题分类框架与技术债务清单（TODO.md）

4.2 Opus 4.8 — 逐字段对照规范

• 角度：4 个子代理并行，全部 16 合约文件逐字段对照
• 独有贡献：首次发现「契约系统性漂移」根因（下游重定义本地类型不 import 契约）；权限旁路（B6）；ACTION_BRANCHES this 崩溃（B7）
• 盲区：未量化规范一致性%；对治理/可执行性着墨少
• 价值：18 项阻断清单精确到文件:行，最具可操作性

4.3 MiniMax-M3 — 可执行性 + 治理

• 角度：「代码即使符合规范，是否真能跑」
• 独有贡献：Scheduler 空壳（B12）；TUI 无 OpenTUI 依赖（B15）；e2e 假报绿（B23）；project_id Date.now（B24）；Worker 握手反转细节（B14）
• 盲区：发现总数较少（侧重关键链路）
• 价值：揭示「接口在但连接链路断」的系统性可执行性阻断

4.4 Qwen3.7-Max — 需求覆盖 + 一致性%

• 角度：FR/NFR 需求矩阵 + 逐文档一致性百分比
• 独有贡献：唯一的需求覆盖矩阵（FR-001..020）；唯一的逐文档一致性%量化；CommandRiskAnalyzer in 操作符 bug（B22）；16/28 工具缺失量化（B25）；ContextAssembler L6-L9（B26）
• 盲区：部分发现与其余模型重叠未交叉标注
• 价值：最全面的规范覆盖视图，发现总数最高（84 项）

---

5. 正面发现（四模型共识 — 已正确实现）

以下项目至少 2 个模型独立确认实现正确，构成可信赖的基础设施基座。

#	正面项	确认模型
1	Monorepo 结构（Bun workspace + Turborepo + 7 包分层）	四模型
2	SQLite Schema（17 表 / 38 索引 / PRAGMA / 5 schema_meta）	四模型
3	事件注册表（54 持久 + 7 临时事件全注册）	DeepSeek/Opus/Qwen
4	Enum 验证（18 闭枚举全覆盖）	Qwen
5	ArtifactStore 原子写（temp→sha256→rename→event）	Qwen + Opus
6	EventBus 错误隔离（handler 异常不中断订阅，INV-5）	四模型
7	临时事件合并（7 类型 / 5 秒窗口）	DeepSeek/Qwen
8	EventIngestor 持久/临时路径分离	Opus/Qwen
9	SecretRedactor（14 凭证模式）	Opus/Qwen
10	CLI 命令完整（11/11 入口）	四模型
11	依赖方向（dependency-cruiser 7 forbidden 规则零违规）	DeepSeek/Opus/M3
12	16 仓库 CRUD 完整	Qwen
13	TUI/Worker 模块导入方向干净（仅 contracts）	Opus/M3
14	ArchitectureDesigner 4 结果枚举正确	Opus/M3

---

6. 统一修复路线图（四模型优先级融合）

融合四模型的 P0/P1 建议，按「阻断级 → 链路连通 → 规范对齐 → 完整性」分层。

阶段 A — P0 安全与崩溃阻断（发布前红线，必须 100% 关闭）

任务	对应缺陷	确认模型数
A1. 消除 3 处命令注入（execSync → execFileSync + args 数组）	B8	4/4
A2. 修复 workspace 投影非法枚举	B2	3/4
A3. EventStore.project() 传递事务句柄给所有仓库	B1	2/4
A4. 修复 ToolRegistry 权限旁路（加载真实 task_scope/profile）	B6	3/4
A5. 修复 ACTION_BRANCHES this 绑定崩溃	B7	2/4
A6. 修复 TaskAttempt 列映射 + route_prefix 分隔符	B5,B4	3/4
A7. api_key 改 auth_ref + 移除硬编码 'dev-key'	B16,B17	2/4
A8. CommandRiskAnalyzer in 操作符 bug	B22	1/4(确凿)

阶段 B — 执行链路连通（让一个任务真正跑起来）

任务	对应缺陷	确认模型数
B1. Scheduler 接通 WorkspaceManager/WorkerManager/ContextAssembler/EventIngestor	B12	3/4
B2. Scheduler 补 BLOCKED/CANCELLED 状态 + 状态写入改走事件投影	B11	3/4
B3. Worker IPC 修握手顺序 + 补信封 5 字段 + 退出码 4 语义	B14,B20	3/4
B4. INV-2 outbox 真实发出 debug.record.created / memory.promoted	B10	3/4
B5. ProjectionClient↔ProjectionStore 建立推送 + 接入 OpenTUI	B15	4/4
B6. CLI init 改走 ToolRegistry（INV-3）	B21	2/4
B7. 替换 e2e 假报绿为真实测试套件	B23	1/4(治理)

阶段 C — 规范对齐（与冻结基线重新同步）

任务	对应缺陷	确认模型数
C1. 项目级 DB schema 对齐 db-schema §20	B3	4/4
C2. MainAgent 补 7 状态 + LLM 分类	B13	4/4
C3. 补 15 缺失契约接口 + 下游 import 契约（消除本地漂移）	(Opus/Qwen)	2/4
C4. PermissionEngine 补 block/refuse/announce_then_run + grant_scope	B19	2/4
C5. CapabilityTrustLevel 改 5 级 + manifest schema 对齐	B18	2/4
C6. PathClassifier 补 credential_store/project_air_*/unknown	(Opus/Qwen)	2/4
C7. 注册 16 缺失 MVP 工具（cpp./debug./gui./network.）	B25	1/4(量化)

阶段 D — 完整性（功能补全）

任务	对应缺陷
D1. ContextAssembler L6-L9 + canonical 输出	B26
D2. Provider 能力矩阵补全 ~80% 字段
D3. Worker 结果统一 WorkerResult 信封
D4. Recovery 实现孤儿扫描 + PID 存活检查
D5. EvidenceStore 持久化（弃内存 Map）
D6. project_id 改 stable UUID

---

7. Meta-Audit 方法论说明

7.1 交叉验证原则

• 置信度分级：≥3 模型确认 = 高置信🔴；2 模型 = 中置信；1 模型 = 需复核
• 冲突解决：评级分歧时，采纳「语义一致性」视角（3 模型）而非「文件完成度」视角（1 模型）
• 独有发现保留：单模型独有项不丢弃，标注「需复核」纳入路线图

7.2 四模型互补性

DeepSeek (广度·计数) ──┐
Opus     (深度·字段) ──┤
                       ├──→ Meta-Audit (交叉确认 + 优先级融合)
MiniMax  (链路·治理) ──┤
Qwen     (覆盖·百分比)─┘

• 四模型从完全不同的角度独立审查，关键缺陷（命令注入 B8、DB schema B3、MainAgent B13、TUI B15）获4/4 满票确认，置信度极高
• 评级从 B+ 到 D+ 的分布反映了「完成度 vs 一致性」的根本张力，Meta 裁决取 C（骨架 B / 执行 D）

7.3 综合数据

指标	数值
四模型发现总数（去重前）	97 + 140 + 38 + 84 ≈ 359
高置信阻断项（≥3模型）	15 项
中置信阻断项（2模型）	7 项
INV 合规	PASS 2 / 部分 3 / FAIL 6
加权规范一致性	≈ 52%
正面共识项	14 项

---

8. 最终裁决

综合评级：C（骨架 B 级 · 执行链路 D 级）

可发布性：否。四个独立审计模型一致判定 V1.0.0 Alpha 不应在当前状态发布。

核心判断：

1. 基础设施扎实——Monorepo、SQLite Schema、事件注册表、依赖方向四模型满票通过，这是真实的工程资产。
2. 契约系统性漂移——contracts 忠实编码规范，但 runtime/llm/workers/tui/toolchain-cpp 系统性重定义本地冲突类型、几乎不 import 契约（Opus 揭示根因，Qwen 量化为 15 契约缺失）。
3. 核心链路断裂——Scheduler 空壳、TUI 无渲染、IPC 握手反转、outbox 不发事件，使「一个任务从派发到完成」的主路径无法真正贯通（M3 揭示）。
4. 三大不变量失守——INV-1/2/3 四模型独立判 FAIL，是评级压到 C 的决定性依据。
5. 安全红线——3 处命令注入（4/4 满票）+ 权限旁路 + 弱密钥，任一项都是 GA 阻断。

建议：冻结新特性，按统一路线图阶段 A（安全红线）→ B（链路连通）→ C（规范对齐）→ D（完整性）顺序整改。阶段 A 必须 100% 关闭方可考虑下一里程碑。

---

本报告由 Opus 4.8 (1M context) 综合 DeepSeek、Opus 4.8、MiniMax-M3、Qwen3.7-Max 四份独立审计报告交叉生成。所有阻断项均标注确认模型数以供溯源复核。

🤖 Generated with Claude Code