feat: add task management and progress reporting

- Implemented task and subtask structures with progress tracking. - Added reporting functionality to log progress at various stages in hotel room status management scripts. - Created a task store to manage tasks and their states, including persistence to local storage. - Updated UI components to display task lists and handle task actions (retry, remove). - Removed deprecated TaskCard and TaskList components, replacing them with a new structure for better maintainability. - Enhanced script execution service to emit progress events for UI updates.
2026-04-16 16:59:49 +08:00
parent b1f589a674
commit 210e8eb363
24 changed files with 788 additions and 237 deletions
--- a/docs/TaskList-Implementation-Plan.md
+++ b/docs/TaskList-Implementation-Plan.md
@@ -9,7 +9,7 @@
 | 模块 | 当前状态 | 关键文件 |
 |---|---|---|
 | 脚本执行 | 通过 `utilityProcess.fork` 串行执行，**阻塞式返回结果**，无实时推送 | `electron/service/execute-script-service/index.ts` |
-| 任务列表 UI | 使用 `@constant/task` **静态假数据** | `src/components/TaskList/List.vue`、`Card.vue` |
+| 任务列表 UI | 使用 `@constant/task` **静态假数据** | `src/pages/home/components/TaskList.vue`、`TaskCard.vue` |
 | 脚本触发入口 | `TaskOperationDialog.vue` 中调用 `window.api.executeScript(options)` | `src/pages/home/components/TaskOperationDialog.vue` |
 | 状态管理 | 已有 `store/script.ts` 管理脚本元数据，**缺少任务（Task）生命周期管理** | `src/store/script.ts` |
 | IPC 通信 | 只有 Request/Response 模式（invoke/handle），**无主进程主动推送** | `electron/preload/index.ts` |
@@ -52,6 +52,7 @@ interface Task {
  dateRange: [string, string];
  status: TaskStatus;
  subTasks: SubTask[];
+  roomList: any[];      // 保留原始房型列表，用于重试时重新传参
  createdAt: string;
  updatedAt: string;
 }
@@ -177,7 +178,7 @@ interface Task {
 ### Phase 4：UI 组件改造
 **目标**：将假数据替换为真实任务数据，支持 tab 切换与操作。

-9. **`src/components/TaskList/Card.vue`**（修改）
+9. **`src/pages/home/components/TaskCard.vue`**（修改）
   - `props` 改为接收 `Task` 或 `SubTask` 对象
   - 根据 `status` 渲染不同状态标签（`warning` 运行中 / `error` 失败 / `success` 成功）
   - 按钮逻辑：
@@ -186,10 +187,11 @@ interface Task {
     - `success` → "移除"（emit `remove`）
   - 显示进度条（`el-progress` 或自定义 div）

-10. **`src/components/TaskList/List.vue`**（修改）
+10. **`src/pages/home/components/TaskList.vue`**（修改）
    - 从 `useTaskStore()` 读取任务列表
    - "待处理" tab 显示 `pendingTasks`，"已处理" tab 显示 `completedTasks`
    - 动态计算 `total` 数量
+    - 顶部日期时间实时动态化（"今天"/"昨天"/具体日期 + `HH:mm:ss`）
    - 处理 `retry-failed`（调用 `taskStore.retryFailedSubTasks(taskId)`）/ `remove` 事件

 ---
@@ -259,13 +261,15 @@ List.vue / Card.vue 响应式更新 UI
 List.vue 调用 taskStore.retryFailedSubTasks(taskId)
    ├─ 将该 Task 下所有 failed 的 SubTask 重置为 pending
    ├─ Task 状态回退为 pending / running
-    └─ 重新调用 window.api.executeScript({ taskId, ... })
+    └─ 重新调用 window.api.executeScript({ taskId, roomType, startTime, endTime, operation, roomList })
        ↓
 主进程只执行 status === pending 的 SubTask（串行排队）
    ↓
 执行完成后更新 Task 状态，移回"已处理" Tab
 ```

+> **注意**：重试时需要 `roomList` 参数。`createTask` 会将 `options.roomList` 存入 `Task.roomList` 并随任务列表一起持久化到 `electron-store`，确保刷新后重试仍能拿到完整参数。
+
 ---

 ## 五、文件变更清单汇总
@@ -282,17 +286,60 @@ List.vue 调用 taskStore.retryFailedSubTasks(taskId)
 | `global.d.ts` | 更新 `WindowApi` 类型 |
 | `electron/service/execute-script-service/index.ts` | 解析进度并 emit 事件 |
 | `electron/process/runTaskOperationService.ts` | 绑定 taskId 并推送 IPC |
-| `src/components/TaskList/List.vue` | 接入真实数据与 tab 过滤 |
-| `src/components/TaskList/Card.vue` | 动态状态、进度、操作按钮 |
+| `src/pages/home/components/TaskList.vue` | 接入真实数据、tab 过滤、日期时间动态化 |
+| `src/pages/home/components/TaskCard.vue` | 动态状态、进度、操作按钮 |
 | `src/pages/home/components/TaskOperationDialog.vue` | 执行前创建 Task |
 | `electron/scripts/*.js` | 插入 `__ZN_PROGRESS__` 输出（可选） |

 ---

-## 六、调整说明（2026-04-14）
+## 六、调整说明（2026-04-16）

 针对实现边界补充以下确认：

 1. **排队机制**：一个 Task 内的多个 SubTask（各渠道脚本）在主进程中**串行排队执行**，不会并发启动多个浏览器实例。
 2. **重试粒度**："重试"操作仅针对该 Task 下 `status === 'failed'` 的 SubTask，成功的 SubTask 保持原结果不变。
 3. **Store 方法**：`src/store/task.ts` 中增加 `retryFailedSubTasks(taskId)` 方法，用于批量重置并重新触发失败子任务。
+4. **视觉 UI 延用当前**：`TaskList.vue` 与 `TaskCard.vue` 保持现有样式和布局，仅将数据来源从 `@constant/task` 静态假数据替换为 `useTaskStore`，并在现有样式框架内绑定状态、进度与操作按钮。
+5. **日期时间动态化**：`TaskList.vue` 顶部原有的静态日期（"今天"）和时间（"02:32:05"）改为响应式实时显示：
+   - 左侧日期标签根据当前日期自动判断显示 **"今天"**、**"昨天"** 或具体日期（如 `04/16`）。
+   - 右侧时间通过 `setInterval` 每秒更新，格式为 `HH:mm:ss`。
+   - 组件卸载时自动清理定时器。
+6. **数据持久化使用 `electron-store`**：
+   - 渲染层 Store `useTaskStore` 通过 IPC (`GET_CONFIG` / `SET_CONFIG`) 读写任务列表，避免主进程直接暴露 Store 实例到渲染层。
+   - 主进程在 `config-service` 的 `DEFAULT_CONFIG` 中新增 `CONFIG_KEYS.TASK_LIST`，默认值为空数组 `[]`。
+   - `useTaskStore` 初始化时异步加载已持久化的任务列表；每次 `createTask`、`completeSubTask`、`removeTask` 等变更操作后，通过 `window.api.invoke(IPC_EVENTS.SET_CONFIG, CONFIG_KEYS.TASK_LIST, tasks.value)` 同步到 `electron-store`。
+   - 注意：持久化数据为任务列表（含 SubTask 状态），实时进度更新（`task:progress`）频繁变化时可**仅更新内存状态**，待 `task:completed` 后再统一持久化，以减少写盘次数。
+
+---
+
+## 七、Sub-agent 开发分工
+
+共启动 **4 个 sub-agent** 按流水线并行开发。
+
+| Sub-agent | 负责阶段 | 关键文件 | 依赖 |
+|---|---|---|---|
+| **SA-1 主进程** | Phase 1 + Phase 2 | `src/lib/task-types.ts`、`src/lib/constants.ts`、`electron/preload/index.ts`、`global.d.ts`、`electron/service/execute-script-service/index.ts`、`electron/process/runTaskOperationService.ts` | 无 |
+| **SA-2 状态管理** | Phase 3 | `src/store/task.ts`（新建）、`src/App.vue`（挂载监听） | 需 SA-1 的类型与 IPC 契约 |
+| **SA-3 前端 UI** | Phase 4 + Phase 5 | `src/pages/home/components/TaskList.vue`、`TaskCard.vue`、`TaskOperationDialog.vue` | 需 SA-2 的 Store API（可按本计划接口契约先行开发） |
+| **SA-4 脚本进度** | Phase 6 | `electron/scripts/mt_trace.js`、`fg_trace.js`、`dy_hotel_trace.js`、`dy_hot_spring_trace.js` | 无 |
+
+### 各 Sub-agent 验收标准
+
+**SA-1**：
+- `executeScriptService` 继承 `EventEmitter`，能解析 `__ZN_PROGRESS__` 前缀并触发 `progress`/`stdout`/`stderr` 事件。
+- `runTaskOperationService` 的 `EXECUTE_SCRIPT` handler 接收 `options.taskId`，为每个脚本生成 `subTaskId`，串行执行并推送 `task:started` / `task:progress` / `task:completed` IPC 事件。
+
+**SA-2**：
+- `useTaskStore` 通过 `electron-store` 持久化任务列表（IPC 读写）。
+- 提供 `createTask`、`updateSubTaskProgress`、`completeSubTask`、`retryFailedSubTasks`、`removeTask`。
+- `pendingTasks` / `completedTasks` computed 正确过滤。
+
+**SA-3**：
+- `TaskList.vue` / `TaskCard.vue` 接入 `useTaskStore`，Tab 数量和任务数量动态计算。
+- `running` 状态显示进度条和最新日志展开；`failed` / `partial_failed` 显示"重试失败项"；`success` 显示"移除"。
+- `TaskOperationDialog.vue` 确认时先 `taskStore.createTask(options)`，再 `window.api.executeScript(options)`。
+
+**SA-4**：
+- 每个脚本在关键步骤输出 `__ZN_PROGRESS__{"step":"...","percent":N}`。
+- 不影响原有脚本逻辑。
--- a/docs/plan.md
+++ b/docs/plan.md
@@ -0,0 +1,401 @@
+# ClawX 项目编译打包实现思路
+
+## 项目概述
+
+ClawX 是一个基于 Electron 的图形化 AI 助手应用，核心功能依赖于 OpenClaw 网关。项目采用现代前端技术栈：
+- **前端框架**: React + TypeScript
+- **构建工具**: Vite
+- **包管理器**: pnpm（使用工作区与虚拟存储）
+- **桌面框架**: Electron
+- **打包工具**: electron-builder
+
+项目结构遵循标准 Electron 应用布局：
+- `electron/main/` – 主进程代码
+- `electron/preload/` – 预加载脚本
+- `electron/gateway/` – 网关通信层
+- `src/` – 渲染进程（React 应用）
+- `resources/` – 静态资源（图标、 CLI 工具、预置技能）
+- `scripts/` – 构建与打包辅助脚本
+- `dist/` – Vite 构建输出（渲染进程）
+- `dist-electron/` – Electron 主进程与预加载脚本构建输出
+
+## 核心构建流程
+
+### 1. 开发构建 (`pnpm run dev`)
+- 使用 Vite 开发服务器启动渲染进程热重载
+- `vite-plugin-electron` 自动编译主进程与预加载脚本，并启动 Electron
+
+### 2. 生产构建 (`pnpm run build`)
+完整构建命令依次执行以下步骤：
+
+```bash
+vite build && 
+zx scripts/bundle-openclaw.mjs && 
+zx scripts/bundle-openclaw-plugins.mjs && 
+zx scripts/bundle-preinstalled-skills.mjs && 
+electron-builder
+```
+
+#### 2.1 渲染进程构建 (`vite build`)
+- 基于 `vite.config.ts` 配置
+- 使用 `@vitejs/plugin-react` 处理 React
+- 输出目录: `dist/`
+- 关键配置：
+  - `base: './'` – 确保 Electron 文件协议下资源路径正确
+  - 别名映射：`@` → `src/`，`@electron` → `electron/`
+
+#### 2.2 主进程与预加载脚本构建 (`vite-plugin-electron`)
+- 配置在 `vite.config.ts` 的 `electron()` 插件中
+- 两个入口：
+  - `electron/main/index.ts` → 输出到 `dist-electron/main/`
+  - `electron/preload/index.ts` → 输出到 `dist-electron/preload/`
+- 主进程构建使用自定义 `external` 规则，排除 Node.js 内置模块和绝对路径模块
+
+#### 2.3 OpenClaw 核心包打包 (`scripts/bundle-openclaw.mjs`)
+**核心挑战**：pnpm 虚拟存储导致依赖分散，直接复制 `node_modules/openclaw` 会丢失运行时依赖。
+
+**解决方案**：广度优先遍历 pnpm 虚拟存储，收集所有传递依赖。
+
+**步骤**：
+1. 解析 `node_modules/openclaw` 的真实路径（跟随 pnpm 符号链接）
+2. 确定 openclaw 所在的虚拟存储 `node_modules` 目录（例如 `.pnpm/openclaw@版本/node_modules/`）
+3. BFS 遍历：
+   - 扫描虚拟存储 `node_modules` 下的所有包（排除 `.bin`）
+   - 对每个包解析真实路径，记录包名与路径
+   - 找到该包自身的虚拟存储 `node_modules`，继续遍历其依赖
+4. 跳过开发依赖（如 `typescript`、`@playwright/test`）和特定作用域包（如 `@types/`）
+5. 将收集到的所有包复制到 `build/openclaw/node_modules/`（扁平化结构）
+6. 去重处理：相同包名只保留首次遇到的版本（避免版本冲突）
+7. 清理：移除开发文档、测试目录、源码映射、类型定义等无用文件
+8. 修补已知问题模块：
+   - `node-domexception` – 修复 CJS 导出为 undefined 的问题
+   - `lru-cache` – 添加 `LRUCache` 命名导出，解决 Node.js 22+ ESM 互操作问题
+   - 运行时 spawn 调用 – 添加 `windowsHide: true` 避免 Windows 控制台窗口闪烁
+
+#### 2.4 插件打包 (`scripts/bundle-openclaw-plugins.mjs`)
+- 打包第三方 OpenClaw 插件：钉钉、企业微信、飞书、微信
+- 使用类似的 BFS 算法收集插件及其传递依赖
+- 输出到 `build/openclaw-plugins/` 各插件目录
+
+#### 2.5 预置技能打包 (`scripts/bundle-preinstalled-skills.mjs`)
+- 将 `resources/skills/` 下的预置技能打包到 `build/preinstalled-skills/`
+- 确保技能配置文件（`SKILL.md`）与依赖完整
+
+#### 2.6 Electron 应用打包 (`electron-builder`)
+- 配置文件：`electron-builder.yml`
+- 输入文件：
+  - `dist/` – 渲染进程构建结果
+  - `dist-electron/` – 主进程与预加载脚本
+  - `package.json` – 应用元数据
+- 额外资源（`extraResources`）：
+  - `resources/` – 静态资源（排除图标源文件、截图等）
+  - `build/openclaw/` – 打包后的 OpenClaw 核心
+  - `build/preinstalled-skills/` – 预置技能包
+- **关键问题**：`electron-builder` 遵循 `.gitignore` 规则，会跳过 `node_modules/` 目录，导致 `build/openclaw/node_modules/` 无法被复制。
+
+**解决方案**：在 `afterPack` 钩子（`scripts/after-pack.cjs`）中手动复制。
+
+### 3. 平台特定打包命令
+- `package:mac` – 仅构建 macOS 安装包（DMG/ZIP）
+- `package:win` – 构建 Windows 安装包（NSIS），预先下载 Windows 平台所需的 UV 和 Node.js 二进制文件
+- `package:linux` – 构建 Linux 安装包（AppImage/DEB/RPM）
+
+## 依赖管理与打包优化
+
+### pnpm 虚拟存储适配
+- pnpm 使用内容寻址存储，依赖通过符号链接组织
+- 构建脚本必须解析真实路径，遍历虚拟存储以收集完整依赖树
+- 支持 Windows 长路径（前缀 `\\?\` 绕过 260 字符限制）
+
+### 体积优化
+1. **开发文件移除**：删除 `.d.ts`、`.map`、测试目录、文档等
+2. **平台特定裁剪**：
+   - `koffi` 本地库：只保留目标平台架构的预构建二进制文件
+   - 作用域本地包（如 `@napi-rs/canvas-*`、`@img/sharp-*`）：移除非目标平台变体
+3. **大文件移除**：删除 `node-llama-cpp/llama`、`pdfjs-dist/legacy` 等非必需大目录
+
+### 兼容性修补
+1. **CJS/ESM 互操作**：
+   - `lru-cache` 旧版本缺少命名导出，通过追加 `exports.LRUCache` 补丁解决
+   - `https-proxy-agent` 补充 `require` 导出条件，避免循环依赖错误
+2. **Windows 控制台隐藏**：修补 spawn 调用，添加 `windowsHide: true` 选项
+3. **插件 ID 修正**：某些插件编译后硬编码的 ID 与声明不一致，在打包后修正
+
+## 安装包生成与分发
+
+### 多平台配置
+- **macOS**：
+  - 目标格式：DMG、ZIP
+  - 启用强运行时（`hardenedRuntime`）与公证（`notarize`）
+  - 自定义 DMG 背景与窗口布局
+- **Windows**：
+  - 目标格式：NSIS 安装程序
+  - 禁用更新签名验证（使用 OSS 分发）
+  - 优化安装速度：修补 NSIS 脚本，直接解压到安装目录，避免 Defender 扫描导致的缓慢文件复制
+- **Linux**：
+  - 目标格式：AppImage、DEB、RPM
+  - 适配 Ubuntu 24.04 t64 ABI 过渡（使用 `|` 语法声明备选包名）
+
+### 自动更新
+- 主分发渠道：阿里云 OSS（国内用户速度优先）
+- 备用渠道：GitHub Releases
+- 使用 `electron-updater` 实现后台更新
+
+## 构建脚本角色概览
+
+| 脚本文件 | 功能描述 |
+|----------|----------|
+| `bundle-openclaw.mjs` | 打包 OpenClaw 核心及其所有传递依赖 |
+| `bundle-openclaw-plugins.mjs` | 打包第三方插件（钉钉、企业微信等） |
+| `bundle-preinstalled-skills.mjs` | 打包预置技能包 |
+| `after-pack.cjs` | `electron-builder` 后处理钩子，负责：<br>• 复制被忽略的 `node_modules`<br>• 平台特定文件清理<br>• 模块兼容性修补<br>• Windows NSIS 脚本优化 |
+| `download-bundled-uv.mjs` | 下载平台特定的 UV 二进制（Python 包管理器） |
+| `download-bundled-node.mjs` | 下载平台特定的 Node.js 运行时 |
+| `generate-icons.mjs` | 生成各平台所需图标格式 |
+
+## 关键配置要点
+
+### `electron-builder.yml` 要点
+- `extraResources` 复制资源，但需注意 `.gitignore` 排除问题
+- `asar: true` 打包为归档，但解压 `*.node` 原生模块和 `lru-cache` 以便修补
+- `npmRebuild: false` 禁止重建原生模块（所有原生模块属于 OpenClaw，在独立进程中运行）
+- 发布配置支持 OSS 与 GitHub 双渠道
+
+### `vite.config.ts` 要点
+- 使用 `vite-plugin-electron` 一体化构建主进程与预加载脚本
+- 主进程外部化规则确保 Node.js 内置模块不打包
+- 路径别名简化导入
+
+## 总结
+
+ClawX 的构建打包流程体现了对现代 Electron 应用复杂依赖管理的深刻理解，主要特点包括：
+
+1. **深度 pnpm 集成**：专门处理虚拟存储的依赖收集，确保运行时完整性。
+2. **分层打包**：将 OpenClaw 核心、插件、技能分别打包，模块清晰。
+3. **跨平台优化**：针对各平台特性进行资源裁剪、性能优化与体验改进。
+4. **兼容性保障**：主动修补第三方模块的 CJS/ESM 互操作问题，确保 Electron 40+（Node.js 22+）稳定运行。
+5. **构建效率**：通过 BFS 依赖收集、开发文件清理、Windows 安装过程优化等手段，控制包体积与构建时间。
+
+此流程确保了 ClawX 能够在三大桌面平台提供一致、稳定、高效的 AI 助手体验。
+
+# zn-ai 项目打包编译重构计划
+
+## 项目现状分析
+
+zn-ai 项目当前使用以下技术栈：
+- **前端框架**: Vue 3 + TypeScript
+- **构建工具**: Vite（分拆配置：`vite.main.config.ts`、`vite.renderer.config.ts`、`vite.preload.config.ts`）
+- **包管理器**: npm（检测到 `package-lock.json`）
+- **桌面框架**: Electron 38.2.2
+- **打包工具**: electron-forge + @electron-forge/plugin-vite
+- **代码保护**: bytenode 字节码编译（通过自定义 `vite-plugin-electron-encrypt` 插件实现）
+
+当前构建流程：
+1. 开发构建：`npm start`（使用 electron-forge start）
+2. 生产构建：`npm run package`、`npm run make`、`npm run build:encrypt`
+3. 自定义脚本：`clean.js`、`generateProdEntry.js` 用于清理和生成字节码入口
+
+## 重构目标
+
+将 ClawX 项目的现代化构建打包思路应用于 zn-ai 项目，主要目标：
+1. **统一构建配置**：使用单个 `vite.config.ts` 替代多个 Vite 配置文件
+2. **迁移打包工具**：从 electron-forge 迁移到 electron-builder
+3. **优化构建流程**：采用模块化构建脚本，提高可维护性
+4. **保持代码保护**：保留或改进 bytenode 字节码保护机制
+5. **提升跨平台体验**：借鉴 ClawX 的平台特定优化策略
+
+## 可行性评估
+
+### 可行方面
+1. **技术栈兼容性**：Vite + Electron 组合在两个项目中都得到验证
+2. **配置迁移**：Vite 配置可以合并，别名映射可以统一
+3. **打包工具迁移**：electron-builder 功能覆盖 electron-forge，且配置更简洁
+4. **脚本模块化**：ClawX 的脚本设计可以作为参考
+
+### 挑战与风险
+1. **bytenode 集成**：ClawX 未使用字节码保护，需要设计新的集成方案
+2. **依赖管理差异**：zn-ai 使用 npm，ClawX 使用 pnpm 虚拟存储，依赖收集策略可能不同
+3. **目录结构调整**：需要适应新的输出目录结构（`dist/`、`dist-electron/`）
+4. **现有功能兼容性**：确保所有现有功能在重构后正常工作
+
+## 详细实施步骤
+
+### 第一阶段：基础配置迁移（预计 2-3 天）
+
+#### 1.1 更新依赖项
+- 移除 `@electron-forge` 相关依赖
+- 添加 `electron-builder`、`vite-plugin-electron`、`vite-plugin-electron-renderer`
+- 更新 `electron` 版本到与 ClawX 兼容的版本（当前 40.6.0）
+- 检查其他依赖兼容性
+
+#### 1.2 创建统一的 Vite 配置
+- 创建 `vite.config.ts`，整合现有三个配置文件的设置
+- 配置 `vite-plugin-electron` 插件，处理主进程和预加载脚本
+- 配置 `vite-plugin-electron-renderer` 插件
+- 统一别名映射，保持现有别名兼容性
+- 保留 Vue 相关插件配置（`@vitejs/plugin-vue`、`unplugin-auto-import`、`@tailwindcss/vite`）
+
+#### 1.3 配置 electron-builder
+- 创建 `electron-builder.yml` 配置文件
+- 基于 zn-ai 需求定制：
+  - 应用 ID、产品名称、版权信息
+  - 输出目录配置
+  - 文件包含规则（`dist/`、`dist-electron/`、`package.json`）
+  - 额外资源（`public/`、`src/main/scripts/` 等）
+  - 平台特定配置（Windows、macOS、Linux）
+
+#### 1.4 更新 package.json 脚本
+- 更新 `scripts` 部分：
+  - `dev`: 使用 Vite 开发服务器 + electron 插件
+  - `build`: 生产构建流程
+  - `package`: 仅打包应用，不生成安装包
+  - `package:win`、`package:mac`、`package:linux`: 平台特定打包
+  - `release`: 发布版本
+- 移除不再需要的脚本（`generate-prod-entry`、`clean` 等）
+
+### 第二阶段：bytenode 保护机制重构（预计 1-2 天）
+
+#### 2.1 分析现有保护机制
+- 当前机制：通过 `vite-plugin-electron-encrypt` 插件在主进程构建后调用 bytenode 编译
+- 输出：`.jsc` 字节码文件，并生成新的入口文件
+
+#### 2.2 设计新的集成方案
+**方案 A：保留现有插件，适配新构建流程**
+- 修改 `vite-plugin-electron-encrypt` 插件，使其与 `vite-plugin-electron` 协同工作
+- 在 `vite-plugin-electron` 的 `onstart` 或构建完成后钩子中集成字节码编译
+
+**推荐方案**：方案 A，因为字节码编译应在主进程构建完成后立即进行，而不是在打包后。
+
+#### 2.3 实现保护机制
+- 创建新的插件或修改现有插件
+- 确保开发模式下不进行字节码编译（保持源码可调试）
+- 生产构建时自动编译并替换入口
+
+### 第三阶段：构建脚本优化（预计 1-2 天）
+
+#### 3.1 分析 zn-ai 的特殊需求
+- 检查是否有类似 ClawX 的复杂依赖收集需求
+- 分析 `src/main/scripts/` 目录的处理需求
+- 检查是否需要平台特定的二进制文件
+
+#### 3.2 创建必要的构建脚本
+- 如果需要依赖收集，参考 ClawX 的 `bundle-openclaw.mjs` 实现
+- 创建脚本处理 `src/main/scripts/` 的打包（类似现有 forge.config.ts 中的 `packageAfterCopy` 钩子）
+- 考虑创建 `after-pack.cjs` 钩子处理 electron-builder 的特殊需求
+
+#### 3.3 优化构建性能
+- 实现开发文件清理（类似 ClawX 的体积优化）
+- 考虑平台特定资源裁剪
+
+### 第四阶段：测试与验证（预计 1-2 天）
+
+#### 4.1 开发构建测试
+- 运行 `npm run dev`，验证开发服务器正常启动
+- 测试热重载、主进程重载等功能
+
+#### 4.2 生产构建测试
+- 运行 `npm run build`，验证完整构建流程
+- 检查输出目录结构是否正确
+- 验证字节码保护是否生效
+
+#### 4.3 安装包测试
+- 生成各平台安装包（Windows、macOS、Linux）
+- 测试安装、运行、卸载流程
+- 验证所有功能正常
+
+#### 4.4 回归测试
+- 确保现有功能不受影响
+- 测试关键业务场景
+
+## 迁移后的构建流程
+
+### 开发构建流程
+```
+npm run dev
+```
+1. Vite 启动渲染进程开发服务器
+2. `vite-plugin-electron` 编译主进程和预加载脚本
+3. Electron 启动，连接开发服务器
+
+### 生产构建流程
+```
+npm run build
+```
+1. `vite build` 编译渲染进程 → `dist/`
+2. `vite-plugin-electron` 编译主进程和预加载脚本 → `dist-electron/`
+3. 字节码编译（生产模式） → 生成 `.jsc` 文件并更新入口
+4. `electron-builder` 打包应用 → `release/` 目录
+
+### 平台特定打包
+```
+npm run package:win    # Windows 安装包
+npm run package:mac    # macOS 安装包  
+npm run package:linux  # Linux 安装包
+```
+
+## 配置迁移对照表
+
+| 当前配置 (zn-ai) | 目标配置 (ClawX 风格) | 迁移说明 |
+|-----------------|----------------------|----------|
+| `forge.config.ts` | `electron-builder.yml` | 功能映射，注意钩子转换 |
+| `vite.main.config.ts` | `vite.config.ts` 中的 `electron()` 配置 | 合并到统一配置 |
+| `vite.renderer.config.ts` | `vite.config.ts` 中的根配置 | 合并渲染进程配置 |
+| `vite.preload.config.ts` | `vite.config.ts` 中的 `electron()` 配置 | 作为第二个 electron 条目 |
+| `build/scripts/clean.js` | `electron-builder.yml` 的 `afterPack` 或构建脚本 | 清理逻辑集成到构建流程 |
+| `build/scripts/generateProdEntry.js` | 新的字节码编译插件 | 功能整合到 Vite 插件 |
+| `package.json` scripts | 更新为 ClawX 风格的脚本 | 保持功能，改进组织 |
+
+## 风险评估与应对策略
+
+### 高风险项
+1. **bytenode 集成失败**
+   - **影响**：代码保护失效，可能影响商业化需求
+   - **应对**：先实现基础构建流程，再单独攻关保护机制；保留回滚方案
+
+2. **依赖兼容性问题**
+   - **影响**：构建失败或运行时错误
+   - **应对**：逐步迁移，分阶段测试；保持 electron 版本与现有依赖兼容
+
+3. **目录结构变更导致路径错误**
+   - **影响**：资源加载失败，功能异常
+   - **应对**：全面更新路径引用；使用别名简化路径管理
+
+### 中风险项
+1. **跨平台打包问题**
+   - **影响**：某些平台安装包生成失败
+   - **应对**：逐个平台测试验证；参考 ClawX 的平台特定配置
+
+2. **构建性能下降**
+   - **影响**：开发体验变差，构建时间延长
+   - **应对**：优化配置，启用缓存；对比新旧构建时间
+
+## 成功标准
+
+1. **功能完整性**：所有现有功能在重构后正常工作
+2. **构建成功**：开发构建、生产构建、各平台打包均成功
+3. **性能相当**：构建时间不超过原有方案的 120%
+4. **代码保护**：字节码保护机制有效，主进程代码得到保护
+5. **可维护性提升**：配置更简洁，脚本更模块化
+
+## 后续优化建议
+
+1. **依赖管理升级**：考虑从 npm 迁移到 pnpm，获得更好的依赖管理性能
+2. **自动更新集成**：集成 electron-updater，实现自动更新功能
+3. **构建缓存优化**：配置持久化缓存，加速构建过程
+4. **CI/CD 集成**：将新构建流程集成到持续集成系统
+
+## 时间估算
+
+| 阶段 | 任务 | 预计时间 | 备注 |
+|------|------|----------|------|
+| 第一阶段 | 基础配置迁移 | 2-3 天 | 包括依赖更新、配置创建、脚本更新 |
+| 第二阶段 | bytenode 保护机制重构 | 1-2 天 | 关键风险点，需要充分测试 |
+| 第三阶段 | 构建脚本优化 | 1-2 天 | 根据实际需求调整 |
+| 第四阶段 | 测试与验证 | 1-2 天 | 全面测试，确保质量 |
+| **总计** | | **5-9 天** | 实际时间取决于具体实现复杂度 |
+
+## 结论
+
+将 ClawX 项目的打包编译思路迁移到 zn-ai 项目是可行的，但需要谨慎处理 bytenode 代码保护机制的集成。重构后的构建系统将更现代化、模块化，且易于维护。建议按照上述计划分阶段实施，每个阶段完成后进行验证，确保整体项目稳定性。
+
+**建议先进行第一阶段的基础配置迁移，验证基础构建流程可行后，再继续进行后续阶段。**
--- a/docs/todo-list.md
+++ b/docs/todo-list.md
@@ -0,0 +1,7 @@
+# 功能清单
+
+1、任务列表
+2、走本地模型配置，重构模型对话功能 - 完成
+3、上传表单信息+读取信息，脚本执行录取表单
+4、定时任务脚本关联多个脚本执行
+5、一键打开渠道可以新增渠道 - 完成