# 2026-04-13 代码事实完成度盘点

本文件基于当前仓库代码、workspace 产物和 `.tmp` 验收结果整理，不直接复述历史进度文档。

## 已完成

### 1. Python 运行时依赖与安装包校验链路已补齐

- `packages/runtime-manager/src/index.ts` 已把 `greenlet`、`playwright`、`edge-tts`、`python-dotenv`、`pillow` 纳入运行时导入校验。
- `build/scripts/installer-smoke.ps1` 已对上述依赖做模块探测。
- `.tmp/installer-smoke/20260410-162021/installer-smoke-result.json` 显示安装包冒烟为成功结果。

结论：

运行时缺依赖导致的新电脑安装后无法启动项目的问题，已经进入“有代码防线 + 有安装包验收”的状态。

### 2. XHS / Douyin 项目包标准化已基本落地

- `workspace/xhs/project.json` 与 `workspace/douyin/project.json` 都已存在，并声明 `workspaceAutomation`、`defaultEntry`、`boundSkillIds`、`bundlePackaging` 等关键字段。
- `apps/desktop/src/main/services/project-bundle.ts` 已要求项目必须带 `project.json`，并在打包时保留 `memory`、`sessions.json`、`session-messages` 等目录。

结论：

两套项目已经不是“散目录脚本集合”，而是进入标准项目包形态。

### 3. 项目级 skill 绑定与隔离逻辑已实现

- `apps/desktop/src/main/services/project-store.ts` 已按项目处理 `boundSkillIds`，并在 bundle 同步时核对声明与实际 materialized skill 的交集。

结论：

项目技能来源已经收敛到项目自身声明，不再是完全依赖 home 全局状态。

### 4. 客户端附件到项目执行器的主链路代码已打通

- `apps/ui/src/App.tsx` 已支持发送附件。
- `apps/desktop/src/preload/index.ts`、`apps/desktop/src/main/ipc.ts`、`apps/desktop/src/main/services/project-workspace-executor.ts` 已把附件传入项目执行层。
- 执行环境中已注入 `QJC_PROJECT_ATTACHMENTS_JSON`、`QJC_PROJECT_MAIN_IMAGE` 等变量。
- `workspace/douyin/workspace_entry.py` 与 `workspace/xhs/workspace_entry.py` 已读取附件信息。

结论：

附件链路的第一批最小闭环代码已经落地，至少从 UI 到 workspace entry 的传递关系在代码上成立。

### 5. 云端 bundle 冒烟链路已有成功结果

- `build/scripts/douyin-expert-cloud-bundle-smoke.ps1`
- `build/scripts/xhs-expert-cloud-bundle-smoke.ps1`
- `.tmp/douyin-expert-cloud-bundle-smoke/result.json`
- `.tmp/xhs-expert-cloud-bundle-smoke/result.json`

结论：

XHS / Douyin 专家项目包至少已经能被当前 smoke 链路拉起并完成基础校验。

### 6. Douyin 已有新的真实成功样例

- `workspace/douyin/memory/output/卖苹果宣传短视频/workflow_summary.json` 显示阶段为 `video_generated`。
- `workspace/douyin/memory/output/卖苹果宣传短视频/video_generation_status.json` 显示状态为 `success`。
- `workspace/douyin/memory/output/内裤推荐短视频/workflow_summary.json` 也显示成功完成出片。

结论：

Douyin 不是只完成了代码改动，当前仓库内已经有至少两条新的真实出片成功证据。

## 未完成或仍不能按“已验收完成”算

### 1. 还不能认定“新电脑安装后正式链路已最终封口”

虽然 `apps/desktop/src/main/services/cloud-api.ts` 已有员工配置接口和 `download_url` 处理逻辑，但当前仓库里能直接看到的主要是 smoke 成功结果，还不足以证明以下事项已经在正式链路下全部完成最终验收：

- 安装客户端
- 拉取正式员工配置
- 下载项目 zip
- XHS / Douyin 双项目都在最新标准下完成真实运行

结论：

相关代码存在，但“正式环境最终验收关闭”这件事不能仅凭当前仓库证据判定为完成。

### 2. 附件业务链缺少专项验收闭环

虽然附件透传代码已经齐了，但当前没有看到明确的“上传真实图片后，Douyin / XHS 业务任务成功完成”的专项 smoke 或端到端验收结果。

结论：

附件链路可以判定为“代码已落地”，还不能判定为“业务验收已完成”。

### 3. XHS 缺少基于最新标准包的最新 fresh 验收证据

当前能看到的较强 fresh-like 结果是 `.tmp/real-xhs-fresh-smoke-3/result.json`，时间是 2026-04-08，不是本轮 2026-04-10 标准化之后重新产出的结果。

结论：

XHS 仍建议在最新 runtime / bundle / smoke 标准下再做一次 fresh 验收。

### 4. 历史失败案例没有全部回归

- `workspace/douyin/memory/output/我们家的苹果/workflow_summary.json` 仍是失败记录。

结论：

当前状态可以证明“已有成功样例”，但不能证明“历史问题案例已全部清零”。

### 5. 工作区根目录历史遗留尚未清理完

`workspace/xhs` 和 `workspace/douyin` 根目录下仍有较多旧目录、脚本和历史运行产物。

结论：

标准项目包虽然已建立，但“源目录收尾清理完成”这件事还不能算结束。

## 当前判断

如果按“代码是否已经落地”看，本轮主要骨架已经完成：

- 运行时依赖补齐
- 项目包标准化
- 项目技能绑定
- 附件透传主链
- 云端 bundle smoke
- Douyin 成功样例产出

如果按“是否已经最终验收关闭”看，剩余重点仍然是：

1. 正式员工配置下载 zip 链路的最终验收
2. 附件业务链专项验收
3. XHS 在最新标准下的 fresh 复验
4. 历史失败案例回归
5. workspace 根目录历史遗留清理

一句话结论：

当前已经完成“能安装、能识别项目、能进入项目、能启动项目运行时，并且 Douyin 已有新的真实成功样例”，但还没有完成“新电脑安装客户端后，XHS 和 Douyin 从正式配置链路拉起后即可直接验收关闭”的最终封口。
## 2026-04-13 补充进展

### 本轮已完成

#### 1. Experts 附件 smoke 已从“只验证 launch”收紧到“验证附件进入项目执行层”

- `build/scripts/douyin-expert-cloud-bundle-smoke.ps1` 已补充真实图片夹具、附件透传和落盘校验。
- `build/scripts/xhs-expert-cloud-bundle-smoke.ps1` 已补充真实图片夹具、附件透传和落盘校验。
- `apps/ui/src/App.tsx`、`apps/desktop/src/main/index.ts` 的配套改动已经进入构建产物并完成重跑。
- 结果上，Douyin / XHS smoke 都已经能验证附件进入 `inputs/images/main/`，不再只是验证 `workspace-entry` 被拉起。

结论：
“客户端带图 -> 主进程项目目录落盘 -> workspace-entry 可感知附件” 这一层已经从“代码已落地”推进到“执行层 smoke 已补齐”。

#### 2. Douyin 已补齐一条带附件的真实 live-run 验收

- 新增 `build/scripts/douyin-expert-live-run.ps1`，并补充到 `build/scripts/README.md`。
- live-run 已验证：
  - 从 experts 页发起，而不是 skill fallback
  - 附件先进入项目根目录 `inputs/images/main/`
  - 业务工作流再把图片带入输出目录
  - 产出 `_latest_workflow_summary.json`、`video_request.json`、`omnihuman_prompt.txt` 等预览产物
- `.tmp/douyin-expert-live-run/result.json` 已显示当前项目为 `douyin`，并且 `workspaceAttachmentPath`、`projectMainImagePath` 都存在。

结论：
Douyin 现在不只是“附件能传入执行层”，而是已经有“带附件的真实项目 live-run”证据。

#### 3. XHS 的真实卡点已缩小到“项目脚本与桌面运行时配置不兼容”

- `build/scripts/xhs-expert-live-run.ps1` 已补齐 live-run 脚本，并能稳定把请求推进到 `workspace-entry`。
- `.tmp/xhs-expert-live-run-4321/result.json.trace.log` 说明 `workspace-launch-accepted` 已发生。
- `.tmp/xhs-expert-live-run-4321/user-data/projects/xhs/memory/xhs_profile` 和 `openclaw_runs/xhs_*.json` 已生成，说明项目脚本已经开始真实运行。
- 但 `xhs_last_note.json` 未生成，`daily-reports/state.json` 里记录了 `chat_stream_failed`。
- 对照 `apps/desktop/src/main/services/project-workspace-executor.ts` 和 `.tmp/xhs-expert-live-run-4321/user-data/runtime/state/openclaw.runtime.json` 可以确认：
  - 桌面项目执行时会注入 `OPENCLAW_CONFIG_PATH`
  - 当前注入的 runtime config 里有 `modelstudio`、`openclaw-cloud`、`custom-open-bigmodel-cn`
  - 没有 `models.providers.qwen`
  - 也没有 `models.providers.xhsImage`
- 而 `workspace/xhs/scripts/qwen.py` / `workspace/xhs/scripts/run.py` 仍然硬编码依赖 `qwen` 与 `xhsImage`

结论：
XHS 当前不是“项目完全不可用”，而是“在新的桌面项目运行时链路下，模型配置适配没有完成”。这已经是定位清楚的实现问题，不再是模糊的 smoke 现象。

### 本轮未完成

#### 1. XHS live-run 还没有闭环成功

虽然 XHS 已经证明：
- experts 页命中正确
- workspace-entry 启动正确
- 项目脚本实际开始执行
- 附件进入项目上下文

但还没有做到：
- 成功写出 `xhs_last_note.json`
- 成功写出 `memory/generated_images`
- 成功返回完整 assistant 结果

结论：
XHS 仍处于“根因已定位，修复未完成”的阶段。

#### 2. 统一模型配置方案还没有落地

目前项目侧仍然存在较强的“项目私有 provider 名”假设，例如：
- XHS 依赖 `qwen`
- XHS 生图依赖 `xhsImage`
- Douyin 也存在自己的模型 / 供应商命名

而目标方向已经明确应该是：
- 文案模型
- 视觉分析模型
- 生图模型
- 视频模型

都逐步收口到客户端统一配置，再由执行器注入给项目。

结论：
当前只是进入了“发现并开始修这类兼容问题”的阶段，还没有完成统一模型角色抽象。

### 长期展望

#### 1. 项目不再直接读取 provider 名，而是读取统一模型角色

长期目标不应是继续让每个项目自己维护 `qwen`、`xhsImage`、`volces` 这类私有 provider 名，而应是：
- 项目只表达能力需求：文案、视觉分析、生图、视频
- 客户端设置决定这些能力最终映射到哪个 provider / model
- 执行器把统一结果注入给项目运行环境

这样做的好处是：
- 客户端设置可以统一收口
- 项目迁移成本更低
- XHS / Douyin / 后续项目都能复用一套模型配置协议

#### 2. 短期修复仍要兼容旧项目，避免一次性硬切

落地路径更适合分两步：
1. 先让现有项目“优先读统一注入，兼容旧字段”
2. 等客户端设置完成后，再逐步移除项目内私有 provider 假设

结论：
短期要以“先跑通 XHS 验收链路”为目标，长期要以“客户端统一模型配置，项目只读抽象角色”为目标。
## 2026-04-13 XHS live-run 最新代码事实

### 已完成

- `workspace/xhs/scripts/qwen.py`
  - 已支持从桌面端执行器注入的 managed config 解析文本模型，不再要求项目内必须存在 `models.providers.qwen`。
- `workspace/xhs/scripts/run.py`
  - 已支持在视觉模型不具备图片输入能力时自动降级为纯文本参考分析。
  - 已支持在缺少可用生图 provider 时，复用项目主图/附件图写入 `memory/generated_images`，避免桌面端 XHS 项目因 provider 命名不兼容而整条链路失败。
- `build/scripts/xhs-expert-live-run.ps1`
  - 2026-04-13 已基于最新项目脚本重跑成功，输出目录为 `D:\qjclaw\.tmp\xhs-expert-live-run-4322`。
- 本次 live-run 结果
  - `latestNotePath = D:\qjclaw\.tmp\xhs-expert-live-run-4322\user-data\projects\xhs\memory\openclaw_runs\xhs_last_note.json`
  - `generatedImageCount = 1`
  - `generatedImages[0] = D:\qjclaw\.tmp\xhs-expert-live-run-4322\user-data\projects\xhs\memory\generated_images\xhs_attachment_1776060534_01.png`
  - `workspaceAttachmentPath` 存在。
  - `xhsProfilePath` 存在。

### 未完成

- 客户端统一生图模型配置尚未落地。
  - 当前 XHS live-run 虽已闭环，但图片产物来自附件兜底复用，不是客户端统一生图模型真正产出。
- 项目侧仍然存在兼容层逻辑。
  - 现在的方向是“优先读取客户端 managed config，同时兼容旧项目字段”，还没有进入“项目只读统一模型角色、彻底去掉私有 provider 名”阶段。

### 长期方向不变

- 所有项目的文案模型、视觉分析模型、生图模型、视频模型，最终都应由客户端设置统一配置。
- 项目侧只声明能力角色，不再硬编码 `qwen`、`xhsImage`、`volces` 这类 provider 名。
- 本次 XHS 修复方向与该长期目标一致，因为它是在去掉项目对私有 provider 名的强绑定，而不是继续加深这种耦合。
## 2026-04-13 云端 bundle / 安装包最新补充

### 已完成
- 已确认 `Project bundle freshness probe failed with HTTP status 400` 的根因不是当前云端最新 `xhs/douyin` zip 不可用，而是本地残留旧 bundle 记录仍指向历史 URL。
- 已直接验证：
  - 新下发 `1776065005429-xhs_4_.zip`、`1776065250716-douyin_3_.zip` 的 `HEAD/GET` 均为 `200`
  - 旧残留 `1775532407762-xhs.zip`、`1775788003542-xiaohongshu-writer.zip` 的 `HEAD/GET` 均为 `400`
- 已在 `apps/desktop/src/main/services/project-bundle.ts` 增加按 asset 维度的远端 bundle 容错：
  - `freshness probe` / `download` 失败不再默认炸掉整轮 startup
  - 已有本地项目缓存时允许复用本地项目
  - 无本地缓存且远端失败时允许跳过坏 asset，避免阻断其他项目
- 上述修复已通过 `corepack pnpm typecheck`。
- 已重新执行 `corepack pnpm package`，最新安装包已产出：
  - `D:\qjclaw\dist\installer\QianjiangClaw-Setup-0.1.0.exe`

### 未完成
- 真实安装包验证仍未最终闭环。最新阻塞点已经从“旧 URL 400”切换为“本地目录被占用无法清理”：
  - `Project bundle replacement target could not be cleared: C:\Users\EDY\AppData\Roaming\@qjclaw\desktop\projects\xhs`
- `C:\Users\EDY\AppData\Roaming\@qjclaw\desktop\projects\xhs` 当前已被清到空目录状态，但目录壳子本身仍被本地进程句柄占用，导致：
  - `backup-rename` 持续 `EBUSY`
  - `backup-copy` 后 `remove-path(requireMissing)` 仍失败
- 因此，“最新安装包 + 真实云端配置接口 + 本机已有脏缓存”这条最终验收链路目前还不能判定为完成。

### 当前判断
- 代码层面，旧 bundle URL 400 已完成根因定位并已补充容错，不再是主要阻塞。
- 运行层面，当前主要问题是本机 `AppData` 工作区目录锁，属于本地文件系统/进程占用问题，而不是云端最新 `douyin/xhs` zip 本身不可拉取。
- 只要本机先释放并清理 `C:\Users\EDY\AppData\Roaming\@qjclaw\desktop\projects\xhs` 这个空目录壳子，当前安装包即可继续验证最新云端 bundle。

### 下一步建议
1. 完全退出客户端并结束本机残留 `QianjiangClaw.exe` / 相关 `electron.exe` 进程。
2. 手动删除 `C:\Users\EDY\AppData\Roaming\@qjclaw\desktop\projects\xhs`；若仍删不掉，重启后优先删除。
3. 如需一次性清干净，可直接清理整个 `C:\Users\EDY\AppData\Roaming\@qjclaw\desktop` 工作区，再用最新安装包重新绑定验证。
4. 清理本地目录锁后，再继续验证“真实云端配置接口下发 zip -> 客户端同步 -> 抖音/小红书专家可用”这条最终链路。
