TT DMTX Task Template Workspace
Solution 3 · Low-AI task workspace

DMTX Task Template Workspace：低 AI 化任务模板客户端方案

不做 Codex / Claude 插件，也不把简单操作强行聊天化；面向运营人员做任务模板型客户端，用内置任务、可复用自定义 skill 和定时器组织高频运营自动化。

查看三方案对比 对照方案 2

1. 结论摘要

推荐方向：把第二个客户端工具定义为 DMTX Task Template Workspace。它不是 Codex / Claude 插件，也不是纯聊天机器人，而是面向非开发运营人员的“任务模板 + 定时器 + 少量 AI 辅助”工作台。

AI 聊天不一定提升所有场景效率。上传联系人、选择文件、点击上传这类明确操作，应保持点击式流程；AI 更适合用于生成自定义任务、解释结果和优化模板，而不是替代简单按钮。

低 AI 化

简单任务不聊天

上传联系人、刷新分群、下载报告等任务保持按钮和表单，核心操作尽量 ≤ 3 步。

模板优先

常用任务预置

沉默用户检查、素材变量检查、旅程巡检、运营周报等高频 SOP 做成官方模板。

可复用 skill

高级用户自定义

用聊天生成任务草稿，转换为结构化模板后保存为个人/团队 skill，反复复用。

2. 需求澄清

本方案的产品方向可以拆成四条：不优先做 Codex / Claude 插件；不要过度 AI 化；借鉴 Claude Cowork 的任务概念；用内置任务模板和定时器支撑常用运营场景。

用户类型核心诉求设计策略
普通运营人员快速完成固定任务，不想学习复杂 AI 对话使用任务模板和表单化参数，核心操作 ≤ 3 步
高级运营人员调整模板、组合任务、形成个人 SOP支持复制模板、参数改写、定时执行和保存为自定义任务
实施 / 客户成功帮客户配置常用任务、排查问题支持模板库、执行记录、结果报告和客户空间配置
管理员控制权限、审批高风险操作、查看审计支持权限分级、审批、执行日志和回滚策略

3. 竞品调研

HubSpot、ActiveCampaign、Mailchimp 都没有把所有自动化都做成聊天，而是以模板、流程、等待/定时规则为核心，AI 更多作为创建和优化辅助。

HubSpot

Workflow Templates

支持从模板创建 workflow，也支持 based on schedule 的 enrollment trigger，按日/周/月等频率运行并结合筛选条件。

ActiveCampaign

Automation Recipes

用户导入 recipe 后修改触发器、等待、条件、字段和动作；日期敏感流程通过 Wait 和 Jump To 管理。

Mailchimp

Automation Flow Templates

模板包含触发器、分支、规则和动作；定时行为通过 time delay rules 和 date-based triggers 组织。

行业最佳实践

最佳实践DMTX 取舍
从模板开始，而不是空白流程DMTX 默认展示高频任务模板，弱化空白创建
简单任务保留按钮/表单联系人上传、下载报告、刷新分群仍保持点击式
复杂任务允许 AI 辅助生成仅在生成自定义任务、解释执行结果、优化条件时使用 AI
定时器和业务筛选绑定定时任务必须包含目标对象、过滤条件、执行窗口和失败策略
高风险动作 dry-run + 审批批量更新、发送、发布、导出必须先预览影响范围

4. 推荐方案

推荐将客户端定义为任务模板工作台：

常用任务 = 模板 + 参数表单 + 可选 AI 辅助 + 定时器 + 执行记录 + 审批审计。

它保留 DMTX 自有产品入口和客户级 UI 控制力，同时避免方案 1 一开始就做完整桌面端的高投入，也避免方案 2 过度依赖面向开发者的外部 AI 平台。

5. 用户体验设计

首页结构

DMTX Task Template Workspace 首页结构图 展示今日任务、常用模板、定时任务和自定义任务入口。 DMTX Task Template Workspace 今日任务 / 待审批 / 异常提醒 运营人员先处理明确事项，而不是先进入聊天框 上传联系人点击式 · 3 步 刷新分群模板参数 旅程巡检可定时 运营周报报告工件 定时任务中心每周一 09:00 · 沉默用户检查 · 失败通知负责人 AI 创建自定义任务自然语言 → 结构化草稿 → dry-run → 保存为 skill

普通任务操作流

1

点击模板「上传联系人」。

2

选择文件，系统自动识别字段并展示校验结果。

3

点击上传；如果存在风险，先 dry-run 展示影响范围。

高级用户自定义任务流

1

用户描述任务：每周一检查上周旅程异常，并发一份报告给我。

2

AI 生成任务草稿：触发时间、数据范围、检查项、输出报告、失败策略。

3

用户确认后保存为「团队任务模板」或「个人 skill」。

6. 任务模板设计

模板不是一段 prompt，而是结构化定义：输入 schema、执行步骤、风险级别、dry-run 要求、审批策略、默认定时配置。

模板场景是否需要 AI
上传联系人文件导入、字段映射、去重否
联系人去重检查定期检查重复邮箱/手机号否
批量打标签 dry-run批量标签更新前预览影响范围低
刷新用户分群定期刷新固定分群否
沉默用户检查查找 N 天未打开/未点击用户低
邮件素材变量检查检查变量缺失、链接异常低
旅程发布前检查检查触发器、分群、素材、频控中
旅程异常巡检定时检查执行失败和异常转化中
运营周报生成汇总发送、打开、点击、转化中
客户问题排查根据任务/日志生成排查报告高
问卷结果汇总生成问卷结果摘要报告中
生日/纪念日名单刷新基于日期字段生成名单低
安全要求：禁止保存纯 prompt 作为可执行任务。自然语言必须转换成结构化任务草稿，再经过风险分级、dry-run 和权限校验。

7. 定时器设计

面向运营人员，定时器不应暴露 cron 输入框，而应显示为业务语言：每周一 09:00，检查上周旅程异常，并把报告发给客户成功负责人。

场景定时器任务模板
每周运营周报每周一 09:00运营周报生成
每日旅程巡检每天 08:30旅程异常巡检
月度联系人清洗每月 1 日 10:00联系人去重检查
生日名单刷新每天 07:00生日/纪念日名单刷新
素材发布前检查发布前手动触发邮件素材变量检查

8. 技术架构

DMTX Task Template Workspace 技术架构图 展示任务模板客户端、Task API/BFF 和 DMTX 现有后端之间的关系。 DMTX Task Template Desktop / Web Workspace 模板库 任务执行 定时中心 AI Composer 审批/工件 DMTX Task API / Desktop BFF Template Service · Task Instance Service · Schedule Service · Dry-run · Approval · Audit · AI Composer Template Runner Schedule Audit AI Existing DMTX Backend contact · material · journey · questionnaire · biz-in-one/gateway · task/log/report APIs

建议先做 Web 任务工作台，验证后再包装为 Electron/Tauri 桌面客户端。桌面阶段不强行嵌入所有编辑器，只做模板、定时器、审批、报告、结果工件和系统通知。

9. 数据模型与 API

模型关键字段说明
task_templateid, name, sourceType, riskLevel, inputSchema, stepDefinition, defaultSchedule, approvalPolicy官方/团队/个人/AI 生成模板
task_instancetemplateId, triggerType, inputValues, status, dryRunResult, approvalId, resultArtifactId一次任务执行实例
task_scheduletemplateId, configSnapshot, frequencyType, timezone, retryPolicy, nextRunAt, status定时任务配置
task_artifacttaskInstanceId, type, title, summary, storageUrl, visibility报告、CSV、预览、日志和建议

核心 API

  • GET /api/task-templates：获取模板列表。
  • POST /api/task-instances：创建任务实例。
  • POST /api/task-instances/{id}/dry-run：预执行并展示影响范围。
  • POST /api/task-instances/{id}/execute：确认执行。
  • POST /api/task-templates：保存为自定义模板。
  • POST /api/task-schedules：创建定时任务。

10. 权限、审批与审计

级别类型示例策略
L0无风险查看模板、查看帮助直接允许
L1只读/报告生成周报、查询分群记录审计
L2草稿/预览创建分群草稿、素材草稿dry-run + 人工确认
L3生产写操作批量打标签、发布旅程、导出数据审批 + dry-run + 审计

每次执行记录 taskInstanceId、templateId、tenantId、operatorUserId、参数摘要、dry-run 摘要、审批单、影响对象数量、执行状态和错误信息。

11. 边界情况

边界情况处理策略
定时任务执行时用户权限已变化执行前重新校验权限，不满足则暂停并通知负责人
模板升级后旧定时任务是否受影响保存 templateVersion 和 configSnapshot，默认使用快照，不自动升级
联系人上传字段无法识别提供字段映射确认页，不允许静默猜测后直接上传
dry-run 影响人数过大触发高风险提示并要求审批
AI 生成任务包含危险动作转为草稿，不允许直接保存为可执行模板
定时任务失败按 retryPolicy 重试，仍失败则生成异常工件并通知负责人

12. 工作量评估

模块工作量
产品/交互设计1 - 2 周
桌面壳 / 前端工作台3 - 4 周
模板库与表单渲染2 - 3 周
Task Runner / BFF3 - 4 周
定时任务中心2 - 3 周
dry-run / 审批 / 审计2 - 3 周
AI Task Composer2 - 3 周
首批模板实现3 - 5 周
测试与验收2 - 3 周
工期口径：Web MVP 6 - 8 周；桌面包装阶段在 Web MVP 基础上追加 4 - 6 周；如果产品验证、Web MVP、桌面包装串行推进，完整桌面 MVP 路径约 12 - 16 周，并行预研可压缩到 10 - 14 周。

13. 三个方案最终对比

维度方案 1：完整自研桌面端方案 2：Claude/Codex 插件化方案 3：任务模板型客户端
目标用户客户运营 + 内部团队开发、实施、高级用户普通运营 + 高级运营
产品形态完整桌面 AI 工作区外部 AI 平台插件/ConnectorDMTX 自有任务工作台
AI 使用方式深度 AI 化AI 平台主导低 AI 化，AI 辅助生成任务
简单操作效率中，取决于 UI低，不适合普通操作高，保留点击式操作
模板化能力可做，但不是核心依赖工具定义核心能力
定时任务可做外部平台不稳定核心能力
对外部平台依赖低高低
开发量高中低中
客户产品化价值高低到中高
当前推荐长期方向能力层可复用优先验证

14. 推荐实施路线

Phase 0 · 2 周

产品验证

梳理 20 个高频运营任务，选出 8 个 MVP 模板，画任务工作台原型，验证核心操作 ≤ 3 步。

Phase 1 · 6-8 周

Web MVP

支持模板库、参数表单、dry-run、执行记录、定时任务、结果工件和 AI 自定义任务草稿。

Phase 2 · 4-6 周

桌面客户端

包装为桌面客户端，增加本地通知、系统托盘、快捷入口和执行状态提醒。

质量自检

按 DMTX 方案评分标准，本方案覆盖需求澄清、竞品调研、用户体验、技术架构、数据模型、API、边界情况、工作量和差异化策略，评分 28 / 28，达到提交标准。