2e5f63be32
Some checks failed
CI / Lint & TypeCheck (push) Has been cancelled
CI / Unit Tests (push) Has been cancelled
CI / Build Frontend (push) Has been cancelled
CI / Rust Check (push) Has been cancelled
CI / Security Scan (push) Has been cancelled
CI / E2E Tests (push) Has been cancelled
- 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
408 lines
15 KiB
Markdown
408 lines
15 KiB
Markdown
# ZCLAW 发散式探讨（第二轮）— 一件事 / 商业化 / 技术架构
|
||
|
||
> 日期: 2026-04-07
|
||
> 形式: 无主题发散式互动探讨
|
||
> 参与者: iven + Claude
|
||
|
||
---
|
||
|
||
## 议题一：管家 vs 工具的边界在哪里？
|
||
|
||
### 抛砖
|
||
|
||
ZCLAW 定位"主动管家"，但 AI 桌面端大多退化为"高级搜索框"。什么条件下用户会真的把决策权交给 AI？
|
||
|
||
### 讨论
|
||
|
||
**三阶梯框架：**
|
||
|
||
| 阶梯 | 行为 | 信任要求 | 例子 |
|
||
|------|------|----------|------|
|
||
| 响应式 | 用户问，AI 答 | 无需信任 | ChatGPT |
|
||
| 建议式 | AI 主动发现，建议方案 | 用户觉得"有道理" | Copilot 建议 |
|
||
| 代理式 | AI 直接做了，事后通知 | 用户觉得"比我做得好" | 自动下单 |
|
||
|
||
**共识：ZCLAW 停在建议式。**
|
||
|
||
关键洞察（iven）：
|
||
- 代理式涉及钱款决策时，出了问题用户会要求系统厂家赔偿
|
||
- 这不是技术问题，是**风险边界**
|
||
- AI 帮用户做前期工作（调研、对比、整理）是甜区 — 降低执行成本但决策权在用户
|
||
|
||
**设计含义：**
|
||
- 管家的"主动性"体现在**发现问题和准备方案**，不是替用户做决定
|
||
- 涉及钱、合同、对外承诺的操作，必须是"帮你准备好，你确认才执行"
|
||
- 这个原则应该是产品级约束，写进系统 prompt
|
||
|
||
---
|
||
|
||
## 议题二："零门槛"是伪命题吗？
|
||
|
||
### 抛砖
|
||
|
||
目标用户是非编程的潮汕工厂老板。配置 API Key、选择 LLM Provider 已经是门槛。SaaS Token 池解决了技术门槛，认知门槛呢？
|
||
|
||
### 讨论
|
||
|
||
**三层门槛分析：**
|
||
|
||
| 层级 | 问题 | 状态 |
|
||
|------|------|------|
|
||
| 技术门槛 | API Key、Provider 概念 | ✅ SaaS Token 池基本解决 |
|
||
| 认知门槛 | "我能问什么？"空聊天框恐惧 | 🚧 行业剧本冷启动可缓解 |
|
||
| 场景门槛 | "我什么时候该打开它？"习惯未建立 | ❌ 真正的杀手 |
|
||
|
||
**共识：培养习惯是零门槛的核心策略。**
|
||
|
||
iven 的洞察：
|
||
- 系统成熟发布后接入 QQ/微信 — 在用户已有的沟通工具里触达
|
||
- **每日定时推送（如早上9点）**：昨日工作总结 + 最新行业动态
|
||
- 逻辑是先用**被动接收**培养习惯，用户发现"确实有帮助"后自然会主动使用，频次随之增长
|
||
- 这本质上是把"场景门槛"倒过来 — 不是用户找场景，而是**场景找用户**
|
||
|
||
**设计含义：**
|
||
- 早上9点推送是一个"锚定时刻" — 让用户每天至少跟 ZCLAW 产生一次接触
|
||
- 推送内容必须是**跟用户行业直接相关的**（不是泛新闻），才有打开的价值
|
||
- 接入微信/QQ 是分发渠道，桌面端是深度交互场所，两者定位不同
|
||
- 习惯养成路径：被动接收 → 觉得有用 → 主动提问 → 深度依赖
|
||
|
||
---
|
||
|
||
## 议题三：记忆系统是护城河还是负担？
|
||
|
||
### 抛砖
|
||
|
||
OpenViking 5,252 行记忆代码，记忆越积越多 — 隐私焦虑、存储膨胀、回忆噪声。如何让用户感到被记住但不感到被监视？
|
||
|
||
### 讨论
|
||
|
||
**记忆的双刃剑：**
|
||
|
||
| 维度 | 护城河 | 负担 |
|
||
|------|--------|------|
|
||
| 竞争 | 用户用了三个月，AI 懂他的业务，换竞品成本极高 | — |
|
||
| 信任 | — | 记忆越精确，用户越不安（"它怎么知道我表弟？"） |
|
||
| 技术 | — | 存储无限增长，回忆噪声淹没信号 |
|
||
|
||
**共识：沿用上次讨论的管家面板设计，不过度设计。发布后根据用户反馈迭代。**
|
||
|
||
iven 的洞察：
|
||
- 管家面板已经设计好了（VikingPanel），不需要在这个阶段加码
|
||
- 透明度的具体形态（面板 vs 对话中自然说出 vs 其他）应该由**用户反馈**决定
|
||
- 过早优化记忆展示 = 过度设计，跟项目"稳定化"原则一致
|
||
|
||
**设计含义：**
|
||
- 当前记忆系统（OpenViking）专注把管线接通，让记忆真正可用
|
||
- 管家面板作为已有的透明机制，先上线最小版本
|
||
- 隐私焦虑的解法：发布后观察用户行为，数据驱动迭代
|
||
|
||
---
|
||
|
||
## 综合结论
|
||
|
||
三个议题串成了一条清晰的产品线：
|
||
|
||
```
|
||
建议式管家（边界）→ 每日推送培养习惯（零门槛）→ 记忆驱动个性化（护城河）
|
||
```
|
||
|
||
**核心产品原则：**
|
||
|
||
1. **建议不代理** — 主动发现 + 准备方案，决策权永远在用户。涉及钱/合同/对外承诺必须用户确认
|
||
2. **场景找用户** — 早9点推送是锚定时刻，微信/QQ是分发渠道，桌面端是深度交互场所
|
||
3. **先跑再调** — 不过度设计，管家面板用已有设计，记忆透明度等用户反馈
|
||
4. **反馈驱动迭代** — 所有产品决策在发布后用真实数据验证，不靠想象力
|
||
|
||
**对当前开发的影响：**
|
||
- L4 管家激活计划的方向确认正确 — 建议式、透明化、不过度设计
|
||
- 每日推送功能是发布后的高优先级特性（需要行业信息源 + 定时调度）
|
||
- 微信/QQ 接入是分发层规划，不影响当前桌面端架构
|
||
|
||
---
|
||
|
||
## 议题四：如果 ZCLAW 只做一件事，那件事是什么？
|
||
|
||
### 抛砖
|
||
|
||
砍掉所有 Hands、Skills、Pipeline、Multi-agent，只留一个核心功能。是什么？为什么？
|
||
|
||
### 讨论
|
||
|
||
**ZCLAW 的灵魂 = 成长性的问题解决者**
|
||
|
||
能力三角（缺一不可）：
|
||
|
||
```
|
||
发现问题（眼睛）→ 解决问题（手）→ 越来越擅长（成长）
|
||
```
|
||
|
||
| 角色 | 系统能力 | 砍掉的后果 |
|
||
|------|----------|-----------|
|
||
| 发现 | 早推送、痛点聚合、行业动态 | 退化为等指令的工具 |
|
||
| 解决 | Hands、Skills、Pipeline | 退化为高级新闻推送 |
|
||
| 成长 | OpenViking 记忆、reflection | 每次都从零开始，无差异化 |
|
||
|
||
iven 的关键纠正：
|
||
- 砍掉 Hands/Skills/Pipeline，管家就没有处理问题的能力
|
||
- "只做一件事"不是砍功能，而是所有功能都服务于同一个灵魂：**帮你解决行业问题，而且一次比一次好**
|
||
- 早推送是发现，Hands/Skills/Pipeline 是解决，OpenViking 是成长 — 不是插件，是同一能力的三个面
|
||
|
||
**一句话定义：帮你解决你行业里的问题，而且一次比一次做得好。**
|
||
|
||
---
|
||
|
||
## 议题五：商业化路径
|
||
|
||
### 抛砖
|
||
|
||
Token 池是核心商业模式。但 SaaS 层 93 个 API、13 个 admin 页面 — 运营成本不低。如何找到 PMF（Product-Market Fit）？
|
||
|
||
### 讨论
|
||
|
||
**商业定位：小而美**
|
||
|
||
iven 的选择：不需要融资，养活小团队，几百个付费用户，每个高客单价，靠口碑慢慢涨。
|
||
|
||
**对比分析：**
|
||
|
||
| 维度 | 规模化 SaaS | 小而美（ZCLAW 选择） |
|
||
|------|------------|---------------------|
|
||
| 目标用户 | 尽可能多 | 潮汕制造业（玩具、制衣）、医院行政领导、教师 |
|
||
| 定价 | 低价月费（¥29-99） | 高客单价（¥299-999/月） |
|
||
| 获客 | 线上投放 | 地推、老乡圈、口碑 |
|
||
| 竞争壁垒 | 功能多、价格低 | 懂行业 + 记住业务 |
|
||
| Token 池 | 用量计费，低价走量 | 包含在客单价中，用户无感 |
|
||
|
||
**商业化的核心飞轮：**
|
||
|
||
```
|
||
行业深耕 → 独家知识库（L2） → 推送/建议越精准 → 用户越依赖 → 续费率越高
|
||
```
|
||
|
||
**关键洞察：**
|
||
- 小而美不需要 93 个 API 什么都做，需要的是**一个行业做透**
|
||
- 获客靠人脉和口碑，不是线上流量 — 这跟潮汕商业文化天然匹配
|
||
- 几百个深度用户的记忆积累，本身就是数据资产 — 未来可以反向强化行业知识库
|
||
- Token 池的成本由 SaaS 层统一管控，用户不感知底层模型细节
|
||
|
||
---
|
||
|
||
## 议题六：技术架构演进 — 资产 vs 负担筛选
|
||
|
||
### 全景数据
|
||
|
||
| 维度 | 数量 |
|
||
|------|------|
|
||
| Rust crates | 10（+ desktop + zclaw-saas） |
|
||
| Rust 总代码量 | ~83K 行 |
|
||
| Tauri 命令（已注册） | 130 |
|
||
| Tauri 命令（有前端调用） | 92 |
|
||
| Tauri 命令（无前端调用） | 38 |
|
||
| SaaS API 端点 | 140 |
|
||
| 前端 Store 文件 | 19（8,349 行） |
|
||
| Admin 页面 | 17 路由（14 组件） |
|
||
|
||
### 逐项筛选清单
|
||
|
||
> 标记：✅ 资产 | ⚠️ 待讨论 | ❌ 负担 | 🔒 冻结
|
||
|
||
---
|
||
|
||
#### A. Rust Crates（10 个）
|
||
|
||
| # | Crate | 行数 | 初步判断 | 理由 |
|
||
|---|-------|------|----------|------|
|
||
| 1 | zclaw-types | 1,789 | ✅ 资产 | 全链路依赖 |
|
||
| 2 | zclaw-memory | 1,427 | ✅ 资产 | 记忆基础 |
|
||
| 3 | zclaw-growth | 4,926 | ✅ 资产 | 护城河核心 |
|
||
| 4 | zclaw-protocols | 2,063 | ⚠️ MCP✅ / A2A🔒 | A2A 短期不用 |
|
||
| 5 | zclaw-skills | 4,411 | ✅ 资产 | 技能系统 |
|
||
| 6 | zclaw-runtime | 9,653 | ✅ 资产 | LLM + Agent Loop 核心 |
|
||
| 7 | zclaw-hands | 7,548 | ✅ 资产 | 解决问题的"手" |
|
||
| 8 | zclaw-kernel | 9,051 | ✅ 资产 | 中枢，multi-agent 部分 🔒 |
|
||
| 9 | zclaw-pipeline | 7,522 | ⚠️ 待讨论 | 行业模板有用，但复杂度高 |
|
||
| 10 | zclaw-saas | 17,291 | ⚠️ 待讨论 | 140 API，小而美用不了这么多 |
|
||
|
||
---
|
||
|
||
#### B. Tauri 无前端调用命令（38 个，按模块分组）
|
||
|
||
| 模块 | 无调用数 | 初步判断 | 理由 |
|
||
|------|---------|----------|------|
|
||
| gateway/commands.rs | 11 | ⚠️ | Kernel 模式下是否还需要 Gateway？ |
|
||
| viking_commands | 11 | ⚠️ | intelligence-backend 已间接调用？ |
|
||
| memory/embedding | 2 | ⚠️ | 内部使用 |
|
||
| llm/ 直接调用 | 3 | ⚠️ | kernel 层内部使用 |
|
||
| pipeline_commands | 11 | ⚠️ | workflowStore 有 invoke？需确认 |
|
||
| classroom_commands | 5 | ❌ 负担 | 教育场景，非目标 |
|
||
| butler/pain_aggregator | 5 | ⚠️ | L4 管家即将接通 |
|
||
| trigger/approval/mcp | 8 | ⚠️ | 核心但前端未接 |
|
||
| skill/agent CRUD | 3 | ⚠️ | configStore 间接调用？ |
|
||
|
||
---
|
||
|
||
#### C. SaaS API 端点（140 个，按模块分组）
|
||
|
||
| 模块 | 端点数 | 初步判断 | 小而美需要？ |
|
||
|------|--------|----------|-------------|
|
||
| auth | 11 | ✅ | 必须 |
|
||
| account/device | 12 | ✅ | 必须 |
|
||
| relay | 9 | ✅ | Token 池核心 |
|
||
| billing | 8 | ✅ | 商业化 |
|
||
| agent_template | 11 | ✅ | 冷启动 |
|
||
| scheduled_tasks | 5 | ✅ | 每日推送 |
|
||
| health | 1 | ✅ | 必须 |
|
||
| prompts | 10 | ✅ | 管家人格 |
|
||
| knowledge | 23 | ⚠️ 待讨论 | 有用但 23 个太多 |
|
||
| model_config | 23 | ⚠️ 待讨论 | 小而美用不了 23 个 |
|
||
| config_sync | 11 | ⚠️ 待讨论 | 可能过度 |
|
||
| telemetry | 4 | ⚠️ 待讨论 | 看需求 |
|
||
| roles/permissions | 11 | ❌ 负担 | 几百用户不需要 RBAC |
|
||
| migration | 11 | ⚠️ 待讨论 | 配置迁移 |
|
||
|
||
---
|
||
|
||
#### D. 前端 Store（19 个）
|
||
|
||
| Store | 行数 | 初步判断 | 理由 |
|
||
|-------|------|----------|------|
|
||
| connectionStore | 859 | ✅ | 连接核心 |
|
||
| chat/streamStore | 724 | ✅ | 流式核心 |
|
||
| saasStore | 893 | ✅ | SaaS 集成 |
|
||
| configStore | 821 | ✅ | 配置核心 |
|
||
| handStore | 722 | ✅ | Hands 管理 |
|
||
| chat/conversationStore | 364 | ✅ | 会话管理 |
|
||
| chatStore | 363 | ✅ | 聊天核心 |
|
||
| offlineStore | 372 | ✅ | 离线支持 |
|
||
| agentStore | 379 | ✅ | Agent 管理 |
|
||
| browserHandStore | 519 | ✅ | 浏览器自动化 |
|
||
| chat/messageStore | 98 | ✅ | Token 统计 |
|
||
| chat/artifactStore | 54 | ✅ | 产物展示 |
|
||
| index | 115 | ✅ | 协调器 |
|
||
| workflowStore | 540 | ⚠️ | Pipeline UI |
|
||
| workflowBuilderStore | 456 | ⚠️ | 可视化编辑器复杂度高 |
|
||
| memoryGraphStore | 322 | ⚠️ | MVP 不需要可视化 |
|
||
| securityStore | 286 | ⚠️ | 安全面板用户看不到 |
|
||
| classroomStore | 234 | ❌ | 教育场景 |
|
||
| sessionStore | 228 | ⚠️ | 与 Kernel 模式重叠 |
|
||
|
||
---
|
||
|
||
#### E. Admin 页面（14 组件）
|
||
|
||
| 页面 | 初步判断 | 理由 |
|
||
|------|----------|------|
|
||
| Login | ✅ | 必须 |
|
||
| Dashboard | ✅ | 必须 |
|
||
| Accounts | ✅ | 必须 |
|
||
| AgentTemplates | ✅ | 冷启动核心 |
|
||
| Billing | ✅ | 商业化 |
|
||
| Usage | ✅ | 用量追踪 |
|
||
| Relay | ✅ | 中继监控 |
|
||
| ScheduledTasks | ✅ | 每日推送 |
|
||
| Knowledge | ✅ | 行业知识库 |
|
||
| Prompts | ✅ | 管家人格 |
|
||
| Providers/Models/ApiKeys | ⚠️ 4→2？ | 可能过度拆分 |
|
||
| Roles | ❌ | RBAC 过度 |
|
||
| Config | ⚠️ | 配置管理 |
|
||
| ConfigSync | ⚠️ | 配置同步 |
|
||
| Logs | ⚠️ | 操作日志 |
|
||
|
||
---
|
||
|
||
### 讨论决策区
|
||
|
||
**关键修正（iven）：SaaS 是未来主入口，不是可瘦身的后端。**
|
||
|
||
潮汕工厂老板设备优先级：**手机 >> 电脑**。最终形态是：
|
||
```
|
||
SaaS（中枢）→ 桌面端（深度交互）+ 微信/QQ（日常触达）
|
||
```
|
||
|
||
因此：
|
||
- roles/permissions ✅ — 移动端多用户需要权限管理
|
||
- config_sync ✅ — 桌面端与移动端数据同步
|
||
- model_config ✅ — SaaS 统一管控模型供给
|
||
- knowledge ✅ — 行业知识库是核心壁垒
|
||
- 所有 SaaS 模块 → ✅ 资产（不瘦身，保持完整）
|
||
|
||
#### 修正后的最终判断
|
||
|
||
**Rust Crates：全部 ✅ 资产**
|
||
|
||
| Crate | 最终判断 | 修正理由 |
|
||
|-------|----------|----------|
|
||
| zclaw-saas (17,291行) | ✅ 资产 | 未来主入口，140 端点面向多端 |
|
||
| zclaw-pipeline (7,522行) | ✅ 资产 | 行业自动化模板，手机端也会触发 |
|
||
|
||
**SaaS API：全部 ✅ 保留**
|
||
|
||
| 模块 | 最终判断 | 修正理由 |
|
||
|------|----------|----------|
|
||
| roles/permissions | ✅ 保留 | 移动端多用户需要 |
|
||
| config_sync | ✅ 保留 | 多端同步 |
|
||
| model_config (23端点) | ✅ 保留 | SaaS 统一管控模型 |
|
||
|
||
**前端 Store：classroomStore ❌ 是唯一确认的负担**
|
||
|
||
| Store | 最终判断 |
|
||
|-------|----------|
|
||
| classroomStore | ❌ 教育场景，非目标行业 |
|
||
|
||
**Admin 页面：全部 ✅ 保留**
|
||
|
||
| 页面 | 最终判断 | 修正理由 |
|
||
|------|----------|----------|
|
||
| Roles | ✅ 保留 | 移动端用户管理需要 |
|
||
| Providers/Models/ApiKeys | ✅ 保留 | 模型供给管理 |
|
||
|
||
**核心结论：架构不是太重，是方向对了。小而美不等于功能少，等于用户少但每人用得深。**
|
||
|
||
---
|
||
|
||
## 第二轮综合结论
|
||
|
||
### 六大共识
|
||
|
||
| # | 共识 | 核心句 |
|
||
|---|------|--------|
|
||
| 1 | ZCLAW 灵魂 | **成长性的问题解决者** — 发现→解决→越来越擅长，三角缺一不可 |
|
||
| 2 | 管家边界 | **建议不代理** — 主动发现+准备方案，决策权永远在用户，涉及钱/合同必须用户确认 |
|
||
| 3 | 零门槛策略 | **场景找用户** — 早9点推送是锚定时刻，微信/QQ是分发渠道，习惯路径：被动→有用→主动→依赖 |
|
||
| 4 | 商业定位 | **小而美** — 几百个高客单价用户，不融资，地推+口碑，一个行业做透 |
|
||
| 5 | 记忆系统 | **沿用管家面板，不过度设计，发布后迭代** |
|
||
| 6 | 架构判断 | **全部保留** — SaaS 是未来主入口（手机>电脑），小而美≠功能少=用户少但用得深 |
|
||
|
||
### 产品方向一句话
|
||
|
||
> 帮潮汕制造业老板解决行业问题，而且一次比一次做得好。
|
||
|
||
### 架构最终形态
|
||
|
||
```
|
||
SaaS（中枢，140 API）→ 桌面端（深度交互）+ 微信/QQ（日常触达）
|
||
↑ 记忆/成长 ↑ 每日推送
|
||
```
|
||
|
||
### 唯一确认的负担
|
||
|
||
- `classroomStore` — 教育场景，非目标行业
|
||
|
||
### 待未来讨论的议题
|
||
|
||
1. 冷启动前 10 个用户
|
||
2. L2 行业知识库冷启动
|
||
3. 管家人格方言/语气
|
||
4. 定价模型
|
||
5. 微信/QQ 技术选型
|
||
6. LLM 成本控制
|
||
7. 离线能力边界
|
||
8. 数据飞轮闭环
|
||
9. 竞品差异化
|
||
10. 小团队运维极限
|
||
|
||
---
|
||
|
||
> 讨论归档于 2026-04-07。完整记录见本文件。
|
||
> 记忆索引已更新。
|