cfdaily
185 lines
11 KiB
Markdown
185 lines
11 KiB
Markdown
# 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 作为第二入口的定位 |
|