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. 检查方法
- 对照 v1.0 报告的 D1-D13 待讨论问题,逐项检查是否被课题方案填补
- 对照 v1.0 报告的"未覆盖需求"清单(F4/F7/F8/F9/F10/IR-2/IR-4/上下文/并行),逐项检查
- 重新评估覆盖率和 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
- 庞统持续意识(当前被 spawn 才思考 → 应该有主动巡检能力)
- 工具链自动化(lint/test/build 触发后结果驱动流转)
- 经验自动应用到新任务(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 作为第二入口的定位 |