docs: reorganize docs — archive outdated, create brainstorming folder

- Create docs/brainstorming/ with 5 discussion records (Mar 16 - Apr 7)
- Archive ~30 outdated audit reports (V5-V11) to docs/archive/old-audits/
- Archive superseded analysis docs to docs/archive/old-analysis/
- Archive completed session plans to docs/archive/old-plans/
- Archive old test reports/validations to respective archive folders
- Remove empty directories left after moves
- Keep current docs: TRUTH.md, feature docs, deployment, knowledge-base, superpowers

docs/brainstorming/2026-04-07-第一轮发散探讨-产品愿景.md

@@ -0,0 +1,395 @@
+# ZCLAW 发散式头脑风暴记录
+
+> 日期: 2026-04-07
+> 状态: 进行中
+> 待归档至: docs/ 或 memory 系统
+
+---
+
+## 1. 项目起源与核心哲学
+
+### 1.1 OpenClaw 的启发
+
+ZCLAW 诞生的起点是 **OpenClaw 的人格系统**。其核心吸引力在于：
+
+- AI 不只是工具，而是**伙伴** — 能一起成长
+- 能**主动检讨**并学习，从而为用户解决问题
+- 长期相处中建立信任感和默契
+
+### 1.2 能力融合路径
+
+在 OpenClaw 基础上，吸收了三个系统的特长：
+
+| 来源 | 借鉴内容 |
+|------|---------|
+| **OpenFang** | Hands 自主能力体系 + 安全性设计 |
+| **OpenMaic** | 教育类专项技能 |
+| **DeerFlow 2.0** | 架构模式（clarification、渐进式加载、sub-agent） |
+
+### 1.3 终极目标
+
+**打造一个能解决用户任何问题的管家式系统。**
+
+---
+
+## 2. 产品定位：与市场差异化
+
+### 2.1 核心差异
+
+| 维度 | 市面 Claw 系统 | ZCLAW |
+|------|---------------|-------|
+| 用户画像 | 开发者、技术爱好者 | **非编程用户、不擅长用电脑的人** |
+| 交互模型 | 选模型、配参数、写 Prompt | **只管说，我来理解和执行** |
+| AI 角色 | 工具/助手 | **伙伴 — 会成长、会反思、会主动** |
+| 能力边界 | 用户能描述清楚的范围内 | **用户说不清楚的，也要想办法解决** |
+
+### 2.2 行业模板 + 潮汕特色产业
+
+SaaS Admin 端预设了行业 Agent 模板，聚焦潮汕地区特色产业：
+
+- **玩具** — 澄海"玩具之都"，全球供应
+- **制衣** — 潮汕纺织服装集群
+- **医疗** — 汕头医疗器械产业带
+- **教育** — 潮汕教育传统
+
+**目的**：不是给用户一个空白 AI，而是给一个"已经入行多年的学徒"。
+
+---
+
+## 3. 三层知识模型
+
+```
+┌─────────────────────────────────┐
+│  Layer 3: 用户独有记忆            │  ← 对话、操作、偏好、习惯
+│  （私有、不可共享、真正的差异点）    │     主要成长来源
+├─────────────────────────────────┤
+│  Layer 2: 行业知识库              │  ← 系统持续采集丰富
+│  （共享、持续丰富、运营驱动）        │     同行业 Agent 共享
+├─────────────────────────────────┤
+│  Layer 1: 行业模板                │  ← 预装基础能力、工作流、话术
+│  （共享、相对稳定、冷启动用）        │     冷启动起点
+└─────────────────────────────────┘
+```
+
+**成长模型**：
+- 模板是起点（Layer 1）
+- 系统持续丰富行业知识库（Layer 2）
+- **主要成长来自用户自己的对话和操作积累**（Layer 3）
+- 每个用户的 Agent 最终长得不一样
+
+---
+
+## 4. "成长时刻"的定义
+
+### 4.1 核心理念
+
+> **产品的价值体现于它能为用户解决多大的问题。**
+
+"成长时刻" = **Agent 主动发现行业痛点，制定解决方案并交付**。
+
+### 4.2 四层能力模型
+
+| 层次 | 表现 | 性质 | 示例 |
+|------|------|------|------|
+| L1 回答 | "CE 认证需要哪些材料？" | 百科全书 | 被动回答 |
+| L2 提醒 | "下周五要做 CE 检测了" | 秘书 | 基于日历/规则 |
+| L3 执行 | "我帮你填好了 CE 申请表" | 助理 | 代办事务 |
+| **L4 管家** | **"分析了 3 批退货原因，核心是包装合规。拟了新规范 + 供应商方案"** | **伙伴** | **主动发现 + 方案制造** |
+
+**ZCLAW 的目标是 L4。**
+
+### 4.3 触发方式：静默分析 + 主动推送
+
+- Agent 在后台**持续分析**用户数据和行业动态
+- 发现问题后**主动推送**解决方案
+- 不等用户提问，不等用户触发
+
+### 4.4 信任建立：全开 + 透明日志
+
+- **从第一天就全部能力开启**
+- 用户可以看到 Agent 在分析什么、怎么分析的
+- 信任来源于**透明**，而非渐进式引导
+
+**关键体验**：每个主动推送的洞察，都能追溯到用户自己的某次操作或对话：
+- "这个想法来自：您 3/7 提到'这批货又迟了' + 3/15 问了广州仓库租金 + 近 3 个月物流费用明细"
+
+### 4.5 痛点识别引擎：方案 A（LLM 自分析）
+
+**选择理由**：方案 B（规则筛选）需要行业专家定义规则，无人能保证规则质量，会降低体验。
+
+**流程设计**：
+
+```
+用户对话 → 对话结束 → LLM 自分析（Haiku，低成本）
+  "刚才的对话里，用户有没有遇到反复出现的困难？"
+    ↓ 有 → 存入 PainPoint 记忆
+    ↓
+  后台定期聚合同类 PainPoint，计次
+    ↓ 累积到阈值 → Sonnet 生成方案 → 推送给用户
+```
+
+**成本控制**：
+- 痛点分析用 Haiku（便宜 3x）
+- 跨会话聚合用 Haiku
+- 只在"生成方案"时用 Sonnet
+- 整体成本与方案 B 相当，但无需人工维护规则
+
+**行业模板的角色转变**：
+- 不再是"预定义痛点规则"
+- 而是"提供行业知识背景"，让 LLM 更懂这个行业的上下文
+
+---
+
+## 5. OpenViking：被忽视的 L4 基石
+
+### 5.1 已有能力清单
+
+OpenViking 记忆系统已经具备大量 L4 管家所需的基础能力：
+
+| L4 需求 | OpenViking 模块 | 说明 |
+|---------|----------------|------|
+| 对话记忆提取 | `memory/extractor.rs` | LLM 驱动，自动从对话中提取关键信息 |
+| 语义搜索 | `viking_find` + FTS5 + TF-IDF + embedding | 混合检索，70% embedding + 30% TF-IDF |
+| 上下文分层 | `context_builder.rs` | L0 概览 / L1 摘要 / L2 全文，token 预算控制 |
+| 记忆注入 | `injector.rs` + `viking_inject_prompt` | 将相关记忆注入 system prompt |
+| 自我反思 | `intelligence/reflection.rs` | Agent 自我反思引擎 |
+| 主动心跳 | `intelligence/heartbeat.rs` | 主动心跳引擎 |
+| 上下文压缩 | `intelligence/compactor.rs` | 长对话压缩 + 记忆刷出 |
+| 对话钩子 | `intelligence_hooks.rs` | 对话前后集成钩子 |
+| UI | `VikingPanel.tsx` | 语义记忆浏览面板 |
+
+URI 命名空间：`viking://user/memories/...` + `viking://agent/{id}/memories/...`
+存储：SQLite + FTS5 + TF-IDF
+记忆类型：Preference / Knowledge / Experience / Session
+
+### 5.2 关键认知修正
+
+之前的差距分析有误。L4 不是"从零建"，而是"激活已有基础 + 补最后公里"。
+
+**真正的差距**：
+- ~~痛点识别引擎~~ → reflection + extractor 已有，缺的是"痛点聚合 + 置信度评分"层
+- ~~透明推理链~~ → viking:// URI 已有溯源能力，缺的是"面向用户的白话解释"UI
+- ~~方案生成器~~ → Pipeline DSL + 技能路由已有，缺的是"痛点 → 方案"的自动编排
+- ~~主动推送~~ → heartbeat 已有基础设施，缺的是"推送时机决策"逻辑
+
+### 5.3 反思：为什么 OpenViking 没被充分利用
+
+这个问题值得深入思考。可能的原因：
+1. 模块存在但未被端到端打通
+2. reflection/heartbeat 能力存在但使用场景不够具体
+3. 记忆提取在运行但"提炼痛点"这一步没有闭环
+
+---
+
+## 6. 核心结论：L4 路径是"激活"而非"新建"
+
+### 6.1 诊断
+
+ZCLAW 的核心问题不是"缺什么模块"，而是"已有模块到底在不在工作"。
+
+项目存在一个反复出现的模式：**代码写了、能力定义了，但"写完 → 跑通 → 用户能感知到"这条链路经常断在最后一截。**
+
+- OpenViking 有 extractor/reflection/heartbeat/compactor — 不确定实际运行状态
+- 131 个 SaaS API — 前端未全部接通
+- 177 个 Tauri 命令 — 16 个 reserved
+- 75 个 SKILL.md — 大部分未做执行验证
+
+### 6.2 优先级修正
+
+之前的差距分析 → 修正后的优先级：
+
+| 之前以为的 | 修正后 |
+|-----------|--------|
+| 新建痛点识别引擎 | **验证 reflection.rs 是否在跑** |
+| 新建透明推理链 UI | **验证 extractor 输出是否能被用户看到** |
+| 新建方案生成器 | **验证 heartbeat 是否能触发推送** |
+| 新建主动推送基础设施 | **验证现有 heartbeat → inject → prompt 链路** |
+
+**第一步：端到端跑通 OpenViking 已有能力，确认哪些是活的、哪些是壳。**
+
+### 6.3 与稳定化阶段的一脉相承
+
+这个判断与已完成的稳定化工作完全一致：
+- Sprint 1-2：P0 修复 + 断链接通
+- Batch 5：GrowthIntegration 桥接
+- V12 审计：模块化审计 + @reserved 标注
+- 死代码清理：Automation/SkillMarket 删除
+
+L4 激活是这个方向的延续 — 不是新的建设阶段，而是**对已有投资的兑现**。
+
+---
+
+## 7. 技能市场悖论 — 结论
+
+**技能完全隐式。** SkillMarket 删除是正确决定。
+
+- 75 个 SKILL.md 定位为 AI 的内部能力图，不是用户的商品目录
+- 用户只感知"我说了需求 → 管家帮我搞定了"
+- 技能选择由 AI 语义路由自动完成
+- 管家面板不展示"技能列表"，而是展示"我帮你做了什么"
+
+## 8. Multi-agent — 结论
+
+**管家调度专家模式，尽快接通。**
+
+- 主 Agent（管家）是用户唯一对话的入口
+- 管家拆解复杂任务，分派给专家 Agent 并行执行
+- 专家 Agent 可以有独立的上下文窗口，深入各自领域
+- 用户感知不到 Multi-agent 的存在，只感知到"管家帮我搞定了"
+
+已有多 agent 资产：
+- 912 行 Director 代码（feature-gated）
+- sub-agent ID 匹配（已修复）
+- 行业 Agent 模板 → 可作为专家 Agent 的基础
+- OpenViking → 每个专家可以有独立记忆上下文
+
+## 9. 桌面端 vs SaaS — 结论
+
+**后勤部模式：三层服务架构。**
+
+```
+Layer 1: 运营层 (SaaS + Admin)
+  → 运营团队使用，管理行业知识库、模板、用户账户
+Layer 2: 管家层 (桌面端 Agent)
+  → 用户的私人管家，对话交互，技能隐式路由，Multi-agent 调度
+Layer 3: 用户层 (对话界面)
+  → 零门槛，零配置，只有聊天
+```
+
+SaaS 的 131 API 不需要全部被桌面端接通。
+桌面端只需接通：获取行业知识、同步模板、上报使用数据等关键接口。
+
+## 10. 非技术用户交互 — 结论
+
+**聊天窗口 + 管家面板。**
+
+聊天窗口是用户的主世界，管家面板是透明日志的 UI 化：
+
+管家面板内容：
+- 🧠 我最近在关注（主动发现的痛点 + 推理链）
+- 💡 我提出的方案（方案追踪、采纳状态）
+- 📝 我记得关于您（用户偏好、习惯、事实）
+
+管家面板不是设置页面，是"管家的工作台公开给用户看"。
+
+---
+
+## 11. 综合产品蓝图
+
+将所有讨论串成一个完整画面：
+
+```
+用户视角（非技术用户）:
+  打开 ZCLAW → 跟管家聊天 → 管家帮我搞定一切
+  偶尔打开管家面板 → 看看管家在关注什么、记住了什么
+
+管家内部（用户看不到）:
+  接收用户消息
+    → LLM 理解意图
+    → 语义路由到 75 个技能中的合适能力
+    → 复杂任务拆解 → 调度多个专家 Agent 并行
+    → OpenViking 记忆系统持续提取、反思、聚合
+    → 发现痛点 → 生成方案 → 推送给用户
+
+运营层（运营团队）:
+  Admin 后台更新行业知识库和模板
+    → SaaS 存储 → 同步到桌面端
+    → 管家获得新知识，不中断用户使用
+```
+
+三层知识模型 + 四层能力模型 + 三层服务架构，构成 ZCLAW 的完整产品 DNA。
+
+### 补充：LLM 供给架构
+
+**桌面端用户不使用本地 LLM，而是通过 SaaS 的 Token 池获取大模型能力。**
+
+```
+用户订阅 Plan（如 coding plan）
+  → SaaS 后端分配 Token 额度 + 配置可用模型
+    → 桌面端通过 SaaS API 调用大模型
+      → 不同厂家（OpenAI/Anthropic/Doubao/...）的模型统一通过 SaaS 路由
+
+用户端：零配置，打开就能用
+运营端：通过 Admin 管理 Token 池、模型配额、定价方案
+```
+
+这意味着：
+1. 用户不需要知道"模型"是什么概念 — 管家自动选择最合适的模型
+2. SaaS 后端承担模型路由、Token 计费、配额管理的职责
+3. 桌面端的"模型配置"UI 对普通用户应该隐藏，只对高级/开发者用户可见
+4. Token 池是核心商业模式 — 用户为"管家能力"付费，不是为"模型调用量"付费
+
+---
+
+## 12. 冷启动体验 — 结论
+
+**行业剧本预设：Admin 后台配置每个行业模板的冷启动流程。**
+
+- 管家开场白（行业定制）
+- 引导问题列表（快速了解用户具体业务）
+- 行业热点话题（展示"我懂你的行业"）
+- 用户回答存入 OpenViking → 即时个性化
+- 冷启动质量可运营：运营团队持续迭代剧本
+
+## 13. 管家人格 + 反馈闭环 — 结论
+
+**可配置人格：运营定基线，用户通过自然对话塑造。**
+
+Admin 配置：tone（语气）、proactiveness（主动性）、formality（正式度）、humor（幽默度）
+用户微调：通过对话自然发生（"别叫我王总了"→ formality 自动降低）
+
+反馈闭环设计：
+
+| 用户反应 | 管家行为 | 存入 OpenViking |
+|---------|---------|----------------|
+| "你说得不对" | 承认错误 + 请用户纠正 | lessons_learned |
+| "我不是这个意思" | 重新理解 + 确认 | patterns（修正偏好） |
+| "别再提这个了" | 立即停止 | preferences（排除项） |
+| "上次那个方案很好" | 强化权重 | lessons_learned（正向） |
+
+关键：管家的学习要"说出来" — "我记下来了，以后不会搞混了"。
+强化伙伴感：用户知道管家在听、在学、在改。
+
+## 14. 数据安全 + 离线 — 结论
+
+**强化安全路线，核心能力：数据脱敏令牌化（Data Tokenization）。**
+
+### 14.1 数据脱敏
+
+在中间件链中新增 `DataMaskingMiddleware`：
+
+```
+用户消息 → 脱敏（本地） → LLM（脱敏数据） → 还原（本地） → 用户看到
+例: "A公司" → "company_00234" → LLM 处理 → "A公司"
+```
+
+- 令牌映射表存在本地 OpenViking，永远不上传
+- SaaS 和 LLM 提供商只能看到脱敏后的数据
+- 产品承诺："你的商业数据永远不会离开你的电脑"
+- **这是核心产品差异化**
+
+### 14.2 离线模式
+
+- 离线时管家不可用（不能调用 LLM）
+- 所有本地数据可查看：历史对话、管家面板、记忆、方案
+- OpenViking 本地数据加密存储
+
+### 14.3 安全架构总结
+
+| 数据类型 | 存储位置 | 安全措施 |
+|---------|---------|---------|
+| 对话内容 | SaaS 中转 | 脱敏后传输，不留存原文 |
+| OpenViking 记忆 | 本地 SQLite | 加密存储，不上传 |
+| PainPoint 洞察 | 本地 OpenViking | 最敏感，脱敏 + 加密 |
+| 令牌映射表 | 本地 OpenViking | 永远不上传 |
+| 行业知识库 | SaaS PostgreSQL | 运营数据，正常管理 |
+
+---
+
+## 15. 后续行动
+
+- [ ] 归档讨论成果至 memory 系统
+- [ ] 可能产出：OpenViking 端到端验证计划
+- [ ] 可能产出：L4 激活路线图
+- [ ] 可能产出：DataMaskingMiddleware 设计文档
+- [ ] 可能产出：冷启动剧本模板设计