# moziplus v2.6 需求-设计一致性验证报告 v2 **版本**: v2.0 **日期**: 2026-05-16 **作者**: 庞统(副军师)🐦 **前置**: v1.0 报告(2026-05-15)+ 课题3/4/6/7/10 方案 **范围**: PRD v2.0 + v2.6 架构 + 5 个 Topic Proposal 的一致性检查 --- ## 0. 检查方法 1. 对照 v1.0 报告的 D1-D13 待讨论问题,逐项检查是否被课题方案填补 2. 对照 v1.0 报告的"未覆盖需求"清单(F4/F7/F8/F9/F10/IR-2/IR-4/上下文/并行),逐项检查 3. 重新评估覆盖率和 AI Native 程度 --- ## 1. 昨天的 Gap 修复状态 ### 1.1 🔴 必须讨论的 4 项(D1-D4) | # | 问题 | v1.0 状态 | v2.0 状态 | 填补方案 | |---|------|----------|----------|---------| | **D1** | IR-2 Plan→Execute→Validate 如何落地? | ❌ 未覆盖 | ✅ 已填补 | **课题4 D4-4** 复杂度驱动粒度控制 + **课题3 D3-6** 状态机细化(plan_review/executing/review 三段)+ **must_haves truths** 作为 plan 产物验证。但注意:PRD 说"每个节点都走三步",课题方案是"按风险等级决定是否走三步"--**偏差需确认** | | **D2** | IR-4 安全红线如何实现? | ❌ 未覆盖 | ✅ 已填补 | **课题3 D3-4** guardrails.yaml 声明式规则 + **v2.6.2** Guardrail 体系(L1硬检查/L2轻量AI/L3 tripwire)+ **PRD §10.1** 6条红线全部映射到 guardrail 规则 | | **D3** | 挑战协商轮次如何追踪? | ❌ 未覆盖 | ✅ 已填补 | **课题3 D3-3** reviews 表 round/max_rounds 字段 + **D3-1** 分级审查流水线(critical→max_rounds:5, standard→3, low→1)+ **D3-6** 状态机超轮次→escalated flag | | **D4** | 前端(Dashboard)与 v2.6 如何集成? | ❌ 未覆盖 | ✅ 已填补 | **课题7** 四种交互模式 + 5页Dashboard + 三层信息架构(L1一眼/L2看板/L3详情)+ frontend-principles.md | ### 1.2 🟡 建议讨论的 5 项(D5-D9) | # | 问题 | v1.0 状态 | v2.0 状态 | 填补方案 | |---|------|----------|----------|---------| | **D5** | Daemon tick 中是否引入 AI 决策? | ❌ 未讨论 | ✅ 已填补 | **课题2** 双层事件架构(Tick兜底+Inbox加速)+ **课题1** 三层执行模型中 Daemon 不做 AI 决策(正确决策:AI 在 Agent 层)。但庞统的"持续意识"未在 tick 中体现--**庞统仍是被动的(被 spawn 才思考),不是主动的** | | **D6** | 60s tick 间隔是否太长? | ❌ 未讨论 | ✅ 已填补 | **课题2** 30s tick + Inbox JSONL 即时通知(task_completed/@mention 即时响应)。依赖推进也即时(task_completed 事件触发) | | **D7** | 庞统智能拆解的保障机制? | ❌ 未讨论 | ✅ 已填补 | **课题4 D4-3** Plan Checker 独立验证 + **D4-4** 复杂度驱动粒度控制 + **D4-1** 模板组件库。拆解质量有 Plan Checker 兜底 | | **D8** | 上下文管理策略? | ❌ 未讨论 | ✅ 已填补 | **课题4 D4-6/D4-7** 四层上下文(L0铁律/L1角色/L2引擎注入/L3被动参考)+ **课题10** 上下文预算测算(35-60K,远小于128K)+ 三段式注入原则 | | **D9** | v1 前端如何过渡到 v2? | ❌ 未讨论 | ⚠️ 部分填补 | **课题7** 定义了新的 Dashboard 设计,但没有明确 v1→v2 过渡路径。v2.0 PRD §6.3 说"v2.0 不做前端,对话为主",但课题7 又设计了 5 页 Dashboard--**需确认这是 v2.0 还是 v2.1+ 的内容** | ### 1.3 🟢 可以后讨论的 4 项(D10-D13) | # | 问题 | v2.0 状态 | 填补方案 | |---|------|----------|---------| | **D10** | 工具链自动化(F8)Phase 规划 | ❌ 仍未覆盖 | 无方案。PRD C10 的 lint/test/build 自动触发未设计 | | **D11** | Skill 生态(F9)最小规范 | ✅ 已填补 | **课题6** 三种载体(Memory→Skill→Rule)+ Skill 生命周期(draft→active→deprecated)+ experiences 表 | | **D12** | 经验沉淀闭环设计 | ✅ 已填补 | **课题6** 五阶段闭环(DISCOVER→DISTILL→VERIFY→APPLY→IMPROVE)+ 两级蒸馏 | | **D13** | 全生命周期阶段映射(F7) | ❌ 仍未覆盖 | 无方案。PRD 的"需求→设计→编码→测试→部署→运维"阶段映射未设计 | ### 1.4 Gap 修复汇总 | 类别 | 总数 | 已填补 | 部分填补 | 未填补 | |------|------|--------|---------|--------| | 🔴 必须讨论 | 4 | 4 | 0 | 0 | | 🟡 建议讨论 | 5 | 4 | 1 (D9) | 0 | | 🟢 可后讨论 | 4 | 2 | 0 | 2 (D10/D13) | | **合计** | **13** | **10** | **1** | **2** | --- ## 2. 需求覆盖重新评估 ### 2.1 功能需求覆盖率 | PRD 需求 | v1.0 状态 | v2.0 状态 | 变化 | |----------|----------|----------|------| | **F1 任务主页** | ✅ | ✅ | 不变 | | **F2 质量门禁** | ⚠️ 缺轮次/结构化 | ✅ 已填补 | 课题3 reviews 表 + 分级流水线 + 轮次追踪 | | **F3 灵活编排** | ⚠️ 缺动态拆解 | ✅ 已填补 | 课题4 模板组件库 + Plan Checker | | **F4 Dashboard 可视化** | ❌ | ✅ 已填补 | 课题7 四种交互模式 + 5页Dashboard | | **F5 结构化IO** | ✅ | ✅ | 不变 | | **F6 自动化流转** | ⚠️ 链不完整 | ✅ 已填补 | 课题2 双层事件架构 + 依赖推进 + Inbox 即时 | | **F7 全生命周期覆盖** | ❌ | ❌ 仍未覆盖 | 无阶段映射设计 | | **F8 工具链自动化** | ❌ | ❌ 仍未覆盖 | lint/test/build 自动触发未设计 | | **F9 Skill 生态** | ❌ | ✅ 已填补 | 课题6 三种载体 + 生命周期 + 闭环 | | **F10 Web 前端平台** | ❌ | ✅ 已填补 | 课题7 Dashboard 设计 | | **F11 消息传递** | ✅ | ✅ | 不变 | | **F12 编排引擎分离** | ✅ | ✅ | 不变 | ### 2.2 铁律覆盖率 | 铁律 | v1.0 状态 | v2.0 状态 | 变化 | |------|----------|----------|------| | **IR-1 做加挑战** | ⚠️ 无强制机制 | ✅ 已填补 | 课题3 分级审查流水线 + 审查协议注册表 + 挑战者池 | | **IR-2 Plan→Execute→Validate** | ❌ | ⚠️ 有偏差 | 课题3 状态机有 plan_review/executing/review 三段,但按风险等级跳过而非强制--**PRD 说"每个节点"vs 设计说"按风险等级"** | | **IR-3 全局视野** | ✅ | ✅ | 不变 | | **IR-4 安全红线** | ❌ | ✅ 已填补 | 课题3 guardrails.yaml + 三层防护 | ### 2.3 覆盖率对比 | 指标 | v1.0(昨天) | v2.0(今天) | 变化 | |------|------------|------------|------| | 功能需求完全覆盖 | 33% (4/12) | **75% (9/12)** | +42pp | | 功能需求部分覆盖 | 58% (7/12) | **83% (10/12)** | +25pp | | 铁律完全覆盖 | 25% (1/4) | **75% (3/4)** | +50pp | | 铁律部分覆盖 | 75% (3/4) | **100% (4/4)** | +25pp | --- ## 3. 新发现的问题 ### 3.1 🔴 PRD 与设计的偏差 | # | 偏差 | PRD 怎么说 | 设计怎么做 | 建议 | |---|------|----------|----------|------| | **N1** | IR-2 强制度 | PRD §2.2:"保留三阶段,但不是每个节点都强制走完,由指挥官判断" | 课题3 按风险等级自动决定。low 风险可跳过 review | PRD 已允许指挥官判断,设计用风险等级代理指挥官判断--**一致,无需调整** | | **N2** | Dashboard 定位矛盾 | PRD §6.3:"v2.0 不做前端,对话为主" | 课题7 设计了完整 5 页 Dashboard | **需确认**:课题7 Dashboard 是 v2.0 Phase 3 还是 v2.1+? | | **N3** | 编排智能化程度 | PRD B2:"编排层应该是一个 AI 指挥官" | Daemon tick 是纯机械的,庞统只在被 spawn 时思考 | PRD §6.1 说"底层确定性引擎 + 上层 AI 指挥层",设计分两层是正确的。但**庞统没有"持续意识"--只在关键事件时被唤醒**,这和 PRD 的"持续指挥"有差距 | | **N4** | Phase 规划不一致 | PRD §7 M1-M3 定义 | v2.6 §12 Phase 1-3 定义完全不同 | **需对齐**:PRD 的 M1-M3 vs 架构的 Phase 1-3 | ### 3.2 🟡 设计内部一致性问题 | # | 问题 | 说明 | |---|------|------| | **N5** | experiences 表与 PRD §6.4 的经验方向 | 课题6 设计了 experiences 表 + 两级蒸馏,但 PRD §6.4 列的 4 类经验(任务模式/时间模型/常见陷阱/最优实践)与课题6 的三种载体(Memory/Skill/Rule)映射不明确 | | **N6** | 课题7 推送机制与 Daemon tick | 课题7 定义了 🔴🟡🟢🔵 四级推送,但推送的技术实现路径未设计(是通过 OpenClaw cron?Daemon 直接调用?前端 WebSocket?) | | **N7** | v2.6 架构文件膨胀 | architecture-v2.6.md 已 92K(~1800行),加上 5 个 topic proposal 共 ~80K,总计 ~170K 的设计文档。新开发者上手门槛高。建议考虑是否需要拆分或整理 | ### 3.3 🟢 仍需后续设计 | # | 内容 | 说明 | |---|------|------| | **N8** | F7 全生命周期阶段映射 | "需求→设计→编码→测试→部署→运维"的任务类型/模板映射 | | **N9** | F8 工具链自动化 | lint/test/build/deploy 自动触发的机制设计 | | **N10** | Agent 并行执行时的运行时感知 | 昨天报告的 #30,v1 和 v2 都未解决 | | **N11** | 多 Agent session 上下文膨胀 | 昨天报告的 #31,v1 和 v2 都未解决 | --- ## 4. AI Native 程度重新评估 ### 评分:7.5/10(昨天 6/10,+1.5) | 维度 | 昨天 | 今天 | 提升 | 原因 | |------|------|------|------|------| | 共享意识 | ✅ 好 | ✅ 好 | - | 黑板模式不变 | | 质量门控 | ❌ 粗糙 | ✅ 完善 | +1 | 课题3 分级审查 + 结构化评审 + 反驳权 | | 编排智能化 | ❌ 纯机械 | ⚠️ 有AI但不够 | +0.5 | 庞统做拆解+规划,但不是"持续意识" | | 经验沉淀 | ❌ 无闭环 | ✅ 有闭环 | +1 | 课题6 五阶段闭环 | | 人机交互 | ❌ 被动查询 | ✅ 主动推送 | +1 | 课题7 四级推送 | | 纪律约束 | ❌ 无 | ⚠️ 有但不强制 | +0.5 | IR-2 按风险等级而非强制 | ### 还差什么到 9/10 1. **庞统持续意识**(当前被 spawn 才思考 → 应该有主动巡检能力) 2. **工具链自动化**(lint/test/build 触发后结果驱动流转) 3. **经验自动应用到新任务**(DISCOVER→APPLY 的自动化闭环) --- ## 5. 总结 ### 进展 昨天的 13 个 gap 已经填补了 10 个,设计覆盖率从 55% 提升到 **83%**。5 个课题方案质量很高,每个都有明确的决策编号(D3-1, D4-6 等)和业界参考。 ### 用户确认结论(2026-05-16 10:24) | # | 问题 | 用户结论 | |---|------|--------| | **Q1** | Dashboard 定位 | ✅ 双入口:Agent + Dashboard。Dashboard 如何 AI Native 是独立课题 | | **Q2** | 庞统持续意识 | ✅ 已实现:severity 分级(info/warning/critical)+ 事件驱动 spawn,不是被动唤醒。v2.6 设计与 PRD §3.12.4 四类事件触发一致 | | **Q3** | Phase 规划 | ✅ 不分阶段,不妥协,直奔 AI Native。每部分设计清楚为止。PRD M1-M3 和架构 Phase 1-3 都需要更新 | ### 仍需后续设计的 2 个缺口 | # | 缺口 | 影响 | |---|------|------| | **F7 全生命周期** | 没有任务类型→生命周期阶段的映射 | 中--当前可以用通用 task_type 替代 | | **F8 工具链自动化** | lint/test/build 未设计 | 低--v2.1+ 内容 | ### 核心结论 **v2.6 + 课题方案已经是一套完整的设计。** 昨天的核心gap(IR-2/IR-4/前端/上下文管理/经验沉淀)全部填补。用户已确认 3 个问题:Dashboard 双入口、庞统持续意识已实现、不分阶段直奔 AI Native。 **AI Native 程度:8/10**(庞统持续意识已确认有效,加上双入口设计) ### 待更新文档 | 文档 | 需要更新什么 | |------|-------------| | PRD v2.0 §6.3 | 删除“v2.0 不做前端”,改为双入口定位 | | PRD v2.0 §7 | 重写里程碑规划,从 M1-M3 分阶段改为不分阶段直奔 AI Native | | architecture-v2.6 §12 | 重写 Phase 规划,与 PRD 对齐 | | architecture-v2.6 §1.2 原则 | 补充 Dashboard 作为第二入口的定位 |