1. 结论摘要
本方案不是完全不开发，而是把开发重心从「桌面客户端 UI / 打包 / 更新 / 本地沙箱」转移到更可复用的「DMTX AI 能力层」。
| 优先级 | 方案 | 建议 |
|---|---|---|
| P0 | 方案 2：DMTX AI Connector + Claude / Codex 插件化接入 | 优先做，用于快速验证价值 |
| P1 | 方案 2 增强版：权限、审批、审计、草稿生成 | 内部稳定后推进 |
| P2 | 方案 1：自研 DMTX Desktop Workspace | 等价值验证充分、客户级产品需求明确后再做 |
2. 背景与目标
方案 1 的核心思路是自研一个类似 Claude Cowork 的 macOS / Windows 桌面客户端，产品完整度高，但需要额外承担 Electron、安全沙箱、打包签名、自动更新、桌面登录态、多编辑器适配和 UI 工作区建设。
方案 2 更符合当前低投入验证诉求：用户安装插件或配置 Connector，完成授权后，就能在 Claude Cowork、Claude Code、Codex 等现成 AI 工作台里调用 DMTX 能力。
减少客户端开发
不先做完整桌面端，避免 macOS / Windows 打包、签名、自动更新和本地安全沙箱投入。
复用 AI 平台
直接使用 Claude / Codex 的对话、多步骤任务、工具调用和上下文能力。
沉淀能力层
把 DMTX 业务能力、权限、审计和 dry-run 做成未来可复用资产。
3. 推荐架构
推荐三层架构：AI 平台只作为入口，Adapter 负责协议适配，DMTX AI Connector Core 负责稳定业务能力。
4. 开发范围
DMTX AI Connector Core
核心资产。负责对接 DMTX API、工具定义、权限、脱敏、dry-run、审批、审计和错误兜底。
Platform Adapters
Claude 侧优先 MCP Server；Codex 侧可使用 OpenAPI Tool、CLI 插件或本地代理服务。Adapter 不承载业务逻辑。
| 工具域 | 示例能力 | 初始风险 |
|---|---|---|
| 客户 / 联系人 | 查询客户、联系人概要、标签、分群概况 | 中 |
| 分群 | 解释分群条件、分析成本、创建分群草稿 | 中 |
| 素材 | 查询素材、检查变量、生成邮件素材草稿 | 中 |
| 旅程 | 查询旅程配置、解释触发逻辑、生成优化建议 | 中 |
| 问卷 | 查询问卷、总结问卷结果、生成分析报告 | 低 |
| 任务 / 日志 | 查询任务状态、分析异常日志、生成排查报告 | 中 |
5. 能力边界
第一阶段：只读 + 分析
POC 阶段只开放低风险能力，避免 AI 直接修改线上数据。允许查询客户基础信息、联系人概要、分群、旅程、素材、问卷、任务状态和异常日志。
第二阶段：草稿生成
允许 AI 生成分群、邮件素材、旅程、问卷和排查报告草稿，但不直接生效，必须回到 DMTX 后台或审批流程由人工确认。
第三阶段：审批后执行
高风险动作必须走「AI 生成计划 → dry-run → 展示影响范围 → 人工确认 → 执行 → 审计」。
6. 平台升级风险
Claude Cowork、Claude Code、Codex 升级确实可能影响插件，但风险大小取决于接入方式。
| 资产类型 | 内容 | 受升级影响 |
|---|---|---|
| 稳定资产 | DMTX API Connector、权限、审计、dry-run、脱敏、业务工具定义 | 低 |
| 半稳定资产 | MCP Adapter、OpenAPI Adapter、CLI Adapter | 中 |
| 易变资产 | Prompt、Skill、工具描述、平台配置文件 | 中 |
| 高风险资产 | UI 注入、浏览器自动化、私有 API Hook | 高 |
7. 方案 1 / 方案 2 对比
| 维度 | 方案 1：自研 DMTX Desktop Workspace | 方案 2：Claude / Codex 插件化接入 |
|---|---|---|
| 核心模式 | 自研 macOS / Windows 桌面客户端 | 建设 DMTX AI Connector，挂到现成 AI 平台 |
| 上线速度 | 慢 | 快 |
| 初期开发量 | 高 | 中低 |
| 产品控制力 | 强 | 中低 |
| UI/UX 自主性 | 强 | 受平台限制 |
| 对 Claude / Codex 依赖 | 低 | 高 |
| 平台升级风险 | 低 | 中，取决于 Adapter 设计 |
| 安全边界 | 可完全自控 | 平台 + Connector 双重控制 |
| 适合用户 | 普通客户运营、客户级产品交付 | 研发、实施、运维、高级运营顾问 |
| 失败成本 | 高 | 低 |
| 阶段 | 方案 1 自研客户端 | 方案 2 插件化接入 |
|---|---|---|
| POC | 2 - 4 周 | 1 - 2 周 |
| MVP | 8 - 12 周 | 3 - 6 周 |
| 产品化 | 16 - 24 周 | 6 - 10 周 |
| 企业级交付 | 24 周以上 | 10 - 16 周 |
8. 安全与合规
方案 2 因为依赖外部 AI 平台，数据边界比方案 1 更敏感，必须默认采用最小数据原则。
- 联系人手机号、邮箱默认脱敏；
- 用户标签按权限返回；
- 行为轨迹只返回摘要；
- 发送记录默认聚合，不返回明细；
- 客户素材按租户策略决定是否允许返回；
- token、密钥、内部配置不得返回。
| 级别 | 类型 | 说明 |
|---|---|---|
| L0 | 公开元数据 | 工具说明、枚举、非敏感配置 |
| L1 | 只读摘要 | 客户、素材、旅程的脱敏摘要 |
| L2 | 草稿生成 | 创建草稿，不直接生效 |
| L3 | 生产写操作 | 必须审批、dry-run、审计 |
9. 落地计划
POC
实现 Connector Core 最小接口、Claude MCP Adapter、DMTX 测试环境、5 - 8 个只读工具、脱敏和调用日志。
MVP
完善权限分级、dry-run、审计日志、Codex Adapter、20 - 30 个业务工具、安装文档和 prompt / skill 模板。
增强版
支持分群、邮件素材、旅程、问卷草稿，支持审批后执行、影响范围分析和平台版本兼容测试。
10. 平台升级风险控制
方案 2 必须把平台变化限制在 Adapter 层，避免 Claude / Codex 升级直接影响 DMTX 业务能力。
Adapter 隔离
错误做法是把 DMTX 业务逻辑直接写在 Claude / Codex 插件里；正确做法是让 Claude Adapter、Codex Adapter 只负责协议转换，统一调用 DMTX Connector Core。
版本锁定
维护 Connector 与平台能力的兼容矩阵，记录当前支持的 Claude MCP、Codex Adapter、测试时间和已验证工具范围。
合约测试
每次平台升级后，验证工具注册、schema、调用链路、权限确认、返回内容理解、大结果集截断、错误提示和审计日志是否仍然正常。
| 工具 | Claude 支持 | Codex 支持 | 风险级别 | 审批要求 |
|---|---|---|---|---|
| 查询客户基础信息 | 是 | 是 | 低 | 否 |
| 查询联系人概要 | 是 | 是 | 中 | 脱敏 |
| 查询旅程配置 | 是 | 是 | 中 | 否 |
| 创建分群草稿 | 是 | 是 | 中 | 是 |
| 生成邮件素材草稿 | 是 | 是 | 中 | 是 |
| 发布旅程 | 暂不支持 | 暂不支持 | 高 | 必须审批 |
| 批量更新标签 | 暂不支持 | 暂不支持 | 高 | 必须审批 |
| 导出客户数据 | 暂不支持 | 暂不支持 | 高 | 必须审批 + 脱敏 |
11. 最终建议
推荐推进顺序：DMTX AI Connector POC → Claude MCP 接入 → Codex Adapter 接入 → 内部试点 → 沉淀高价值工具 → 补齐权限、审批、审计、dry-run → 再评估是否需要自研 DMTX Desktop Workspace。