# 0410 进度

Date: 2026-04-10

Last Updated: 2026-04-13

Status: in-progress

## 今日最终判断

到 2026-04-10 这一步，项目状态已经不是“方案设计中”，而是：

- 客户端安装链路已基本可用
- XHS / Douyin 项目 bundle 接入客户端主链已基本打通
- fresh install 级别的 bundled runtime 验收今天已重新通过
- Douyin 已有新的完整成功样例，且又补出一条更短的单镜头成功样例
- Douyin 主流程里“视频成功但根状态误写失败”的 coordinator 收尾异常已修
- 客户端到专家项目的附件链路已落第一批最小闭环代码
- 但还不能下“新电脑安装客户端后，两个项目从配置接口拉 zip 就都已正式验收可以直接跑”的最终结论

最准确的口径是：

- “接入链路已通”
- “Douyin 本地真实工作流已跑通两条新样例”
- “XHS 有较强的 fresh-like 旧证据”
- “但客户端专家附件链路虽然已补第一批代码，仍未完成 smoke 和真实端到端验收”
- “但安装版客户端 + 配置接口拉 zip + 两项目都真实自动化跑完”的统一最终验收还没完全补齐

## 已完成

### 1. Runtime 依赖和探测已落地

相关文件：

- `build/runtime/python/requirements.in`
- `build/runtime/python/runtime-requirements.lock.txt`
- `packages/runtime-manager/src/index.ts`

已纳入并锁定：

- `greenlet`
- `playwright`
- `edge-tts`
- `python-dotenv`
- `pillow`
- `imageio-ffmpeg`

runtime 探测已从简单存在性检查升级为真实导入探测，能明确确认：

- Python 可执行可用
- `greenlet` 可导入
- `playwright.async_api` 可导入
- `edge_tts` 可导入

### 2. Bundle 契约已明显收紧

相关文件：

- `apps/desktop/src/main/services/project-bundle.ts`

当前 bundle 安装已从“猜测式安装”转向“强契约安装”：

- bundle 内必须有标准 `project.json`
- 缺少 `id` / `name` 会直接报错
- 已开始以 `project.json` 中声明的 `boundSkillIds` 作为项目绑定来源

### 3. 项目级 skills 收口已落地

相关文件：

- `apps/desktop/src/main/services/project-store.ts`

当前行为已调整为：

- 非 home 项目不再自动混入 curated generic skills
- `boundSkillIds` 会和实际 materialize 出来的项目 skill 目录交叉校验
- skill 缺失会进入诊断，并影响项目 ready 状态

### 4. XHS / Douyin 项目标准化已基本完成

相关文件：

- `workspace/xhs/project.json`
- `workspace/xhs/workspace_entry.py`
- `workspace/douyin/project.json`
- `workspace/douyin/workspace_entry.py`

两边都已经具备：

- 标准 `project.json`
- `workspace-entry` 自然语言入口
- `boundSkillIds`
- `bundlePackaging`
- 运行态写入 `memory/` 目录的路径约束

### 5. 客户端 fresh install runtime 验收今天已重新通过

这是今天最关键的新进展之一。

已完成：

- 重新 materialize runtime
- 重新打包 installer
- 重新跑 installer smoke

最新 installer：

- `dist/installer/QianjiangClaw-Setup-0.1.0.exe`
- 时间：2026-04-10 16:11:58

最新 installer smoke：

- `.tmp/installer-smoke/20260410-162021/installer-smoke-result.json`
- 结果：`ok=true`

已确认通过：

- bundled runtime 正常带入安装包
- installed app smoke 正常完成
- `pythonImportProbe`
- `greenletImportProbe`
- `playwrightAsyncImportProbe`
- `edgeTtsImportProbe`

说明 fresh install 下客户端 runtime 本身已经不再是主要阻塞项。

### 6. installer smoke 自身的假失败点已修掉

相关文件：

- `build/scripts/installer-smoke.ps1`

原先这里用 `python -c` 执行多行 probe，PowerShell 会破坏内层引号，导致假的 Python 语法错误。

现在已改为：

- 写临时 `.py` 文件
- 再调用 packaged Python 执行
- 执行后删除临时文件

### 7. XHS / Douyin 项目接入客户端主链已基本打通

当前已经有明确证据证明，客户端侧以下链路是通的：

- employee key / runtime cloud config fetch
- zip bundle sync
- 项目在客户端出现
- 专家页项目命中
- 会话绑定到 `project:xhs:*` / `project:douyin:*`
- `workspace-entry` 被命中

相关证据：

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

当前可以明确说：

- XHS / Douyin 的“项目接入客户端链路”是基本打通的
- 但这两条 smoke 仍然属于“启动验证”，不是“真实结果验收”

原因是：

- `build/scripts/xhs-expert-cloud-bundle-smoke.ps1`
- `build/scripts/douyin-expert-cloud-bundle-smoke.ps1`
- `build/scripts/electron-smoke.ps1`

目前都允许 `QJCLAW_SMOKE_ACCEPT_WORKSPACE_LAUNCH=1`，所以通过的含义更接近：

- 项目命中成功
- `workspace-entry` 启动成功

而不是：

- 项目真实自动化完整执行并产出最终结果

### 8. Douyin 旧失败点已定位并修掉

旧失败点已经明确不是“抖音项目包路由失败”，而是 Douyin 项目内部工作流问题。

已确认并修复：

- Seedance 请求里单独传 `reference_audio` 会触发 Ark 报错  
  - 错误：`reference_audio cannot be the only reference input`
- `run_seedance.py` 已加兜底  
  - 在缺少图/视频参考时，不再单独发送 `reference_audio`

相关文件：

- `workspace/douyin/skills/seedance-2-0-video-generator/scripts/run_seedance.py`

### 9. Douyin 主流程 placeholder 音频误传已修

今天还额外确认并修掉了一个真正影响成片的主流程问题：

- `seedance-silent*.wav` 此前会被当成 `main_audio` 传到 split
- 后续 `ffmpeg -shortest` 会把成片错误截短

当前已改为：

- 不再把 `seedance-silent*.wav` 当成主音频复用
- 不再把它写入新的 `video_request` / `project_inputs.main_audio`
- split 层也做了二次防呆

相关文件：

- `workspace/douyin/skills/douyin-master/scripts/coordinator.py`
- `workspace/douyin/skills/douyin-seedance-split/scripts/run_pipeline.py`

### 10. Douyin 已跑通新的完整验收样例：卖苹果宣传短视频

今天新增跑通了一条新的 Douyin 实战样例：

- 项目目录：`workspace/douyin/memory/output/卖苹果宣传短视频`
- 目标：`我要卖苹果，帮做一个抖音宣传视频，三个镜头就行，短一点`
- 结果：完整主流程成功，项目根状态成功，最终成片成功

关键结果：

- `workflow_summary.json` 已是 `stage=video_generated`
- `video_generation_status.json` 已是 `status=success`
- `latest_seedance_split_summary.json` 中 `segment_count=3`
- 最终视频：
  - `workspace/douyin/memory/output/卖苹果宣传短视频/latest_seedance_split.mp4`
  - `workspace/douyin/memory/output/卖苹果宣传短视频/seedance-split-runs/20260410-192611/final_video.mp4`

这说明到今天这一步，Douyin 不再只是“能启动项目”“能返回分镜”，而是已经至少有一条完整的新样例做到：

- 预览生成成功
- 三镜头拆分成功
- Seedance 分镜生成成功
- 本地拼接成功
- TTS 旁白 mux 成功
- 项目根状态回写成功

### 11. Douyin 又补通一条更短的单镜头验收样例：内裤推荐短视频

在 `卖苹果宣传短视频` 之外，今天又追加跑通了一条更短的 Douyin 样例：

- 项目目录：`workspace/douyin/memory/output/内裤推荐短视频`
- 目标：更短、更小、分镜更少，优先验证抖音主流程根状态成功回写
- 结果：单镜头成功、最终视频成功、项目根状态成功

关键结果：

- `workflow_summary.json` 已是 `stage=video_generated`
- `video_generation_status.json` 已是 `status=success`
- `latest_seedance_split_summary.json` 中 `segment_count=1`
- 最终时长约 `4.34s`
- 最终视频：
  - `workspace/douyin/memory/output/内裤推荐短视频/latest_seedance_split.mp4`
  - `workspace/douyin/memory/output/内裤推荐短视频/seedance-split-runs/20260410-211028/final_video.mp4`

这条样例的价值在于，它不是三镜头长样例，而是更接近后续“快速生成、短视频、小分镜”的实际使用场景。

### 12. Douyin coordinator 收尾假失败点已修

今天还顺手修掉了一个会影响最终状态口径的收尾问题：

- 之前出现过“Seedance 视频已经生成成功，但项目根状态被写成 error”
- 根因不是视频生成失败，而是 coordinator 收尾阶段日志输出触发 `[Errno 22] Invalid argument`
- 现在日志输出失败不会再把本来成功的工作流误打成失败

相关文件：

- `workspace/douyin/skills/douyin-master/scripts/coordinator.py`

### 13. XHS 有较强的 fresh-like 旧证据，但今天未按最新标准重跑

已有一份较强的旧证据表明，XHS 不只是“能命中项目”，而是在 fresh-like 路径下实际跑到项目产物：

- `.tmp/real-xhs-fresh-smoke-3/result.json`
- `.tmp/real-xhs-fresh-smoke-3/result.json.trace.log`
- `.tmp/real-xhs-fresh-smoke-3/user-data/projects/xhs`

该结果能证明：

- 安装 / 初始化 / bundle 同步 / 项目进入 / 流式执行都跑到了较深层
- `user-data/projects/xhs` 下确实出现了项目目录、技能、会话、memory、profile 和产物文件

但要注意：

- 这份证据时间是 2026-04-08
- 不是今天 2026-04-10 按最新 runtime / bundle / smoke 口径重新做的同轮验收

### 14. 客户端专家附件链路第一批最小闭环代码已落地

这次已经把“客户端 experts 页单图上传 -> 主进程项目内落盘 -> workspace-entry 执行层透传 -> Douyin/XHS Python 入口感知附件”的第一批最小闭环补进代码。

已完成：

- `shared-types` 已新增 `ChatAttachment` / `ProjectResolvedAttachment`
- `DesktopApi.chat.sendPrompt()` / `streamPrompt()` 已支持可选 `attachments`
- 主进程 `ipc.ts` 已支持把图片复制到当前项目 `inputs/images/main/`
- 附件已强制要求走 `workspace-entry`，不再允许图片挂到普通 skill fallback
- `project-workspace-executor` 已通过执行输入和环境变量继续透传附件
- experts 页已补单图选择、展示、移除、发送
- Douyin `workspace_entry.py` 已能读取主图，并在数字人场景下把图传给 coordinator
- XHS `workspace_entry.py` 已能感知附件进入项目上下文

相关文件：

- `packages/shared-types/src/index.ts`
- `apps/desktop/src/preload/index.ts`
- `apps/desktop/src/main/ipc.ts`
- `apps/desktop/src/main/services/project-workspace-executor.ts`
- `apps/desktop/src/main/project-workspace-agent-runner.ts`
- `apps/ui/src/App.tsx`
- `apps/ui/src/styles.css`
- `workspace/douyin/workspace_entry.py`
- `workspace/xhs/workspace_entry.py`

本轮已完成基础校验：

- `corepack pnpm typecheck` 通过
- `python -m py_compile workspace/douyin/workspace_entry.py workspace/xhs/workspace_entry.py` 通过

## 尚未完成

### 1. 还不能下“新电脑装完后两个项目都能直接跑起来并正式验收通过”的最终结论

这是当前最重要的边界。

基于目前事实，更准确的结论是：

- 客户端安装链路已通
- 项目 bundle 接入链路已通
- Douyin 已有新的完整成功样例
- XHS 有较强的 fresh-like 旧证据

但还不能等同于：

- 一台全新电脑安装客户端
- 用正式配置接口拉取当前两个 zip 项目包
- 两个项目都在安装版客户端里完整跑完真实自动化
- 并且已经完成统一最终验收

原因：

- 今天的 XHS / Douyin `expert cloud bundle smoke` 仍是“启动验证”性质
- Douyin 的完整成功样例是本地工作区真实流程成功，不是安装版客户端 cloud-bundle smoke 的最终结果验收
- XHS 的 fresh-like 强证据来自 2026-04-08，不是今天同轮复验
- 当前 smoke 使用的是本地 smoke cloud config 服务，不是计划文档中写的正式线上 Supabase 地址

### 2. `我们家的苹果` 旧案例还没有按完整主流程重新收口

`我们家的苹果` 这条线此前已经验证过：

- Seedance 分镜接口本身可以成功返回视频
- 参数问题 `reference_audio cannot be the only reference input` 已修
- `ffmpeg` 缺失问题已补
- placeholder 音频误传问题已修

但这条老案例没有再完整重跑一遍主流程去更新它自己的项目根状态文件，所以它仍然不是今天最后的验收样例。

### 3. Experts smoke 仍然偏“启动验证”

`xhs` 和 `douyin` 的 experts smoke 现在仍用了：

- `QJCLAW_SMOKE_ACCEPT_WORKSPACE_LAUNCH=1`

这意味着它更偏向验证：

- 项目是否命中
- `workspace-entry` 是否启动
- 项目会话是否正确绑定

而不是验证：

- 项目自动化流程是否真正执行完成
- 最终文件是否真正产出

### 4. 客户端专家附件链路已落第一批代码，但还没完成验收闭环

这一点是当前最新边界。

当前已经做到：

- experts 页可选 1 张本地图片
- `DesktopApi.chat.sendPrompt()` / `streamPrompt()` 已支持附件
- IPC 层已支持附件协议
- 主进程会把图片复制到当前项目 `inputs/images/main/`
- `project-workspace-executor` / `project-workspace-agent-runner` 已能透传附件
- Douyin / XHS `workspace_entry.py` 已能读取附件上下文

但还没有完成：

- experts smoke 升级到“验证附件真实进入项目执行层”
- 客户端带图实跑一轮 Douyin 数字人端到端验收
- XHS 对附件的业务语义消化仍未继续展开

所以当前不能说“附件链路已经验收完毕”，只能说“附件链路第一批最小闭环代码已经落地”。

专项计划仍见：

- `docs/douyin-xhs-插入/2026-04-10-客户端抖音专家附件打通计划.md`

### 5. Day 1 契约收口仍不算完全结束

当前主要收紧的是：

- bundle 侧
- project store 侧
- runtime / smoke 侧

但计划里点名的这些文件，这次没有看到明确收口：

- `apps/desktop/src/main/services/cloud-api.ts`
- `apps/desktop/src/main/services/project-workspace-executor.ts`

所以 Day 1 的“配置契约冻结”还不能算 100% 完成。

### 6. XHS / Douyin 源目录收尾清理还没做完

虽然运行态都在往 `memory/` 迁，但项目根目录里仍然有一些历史运行目录和旧说明没有完全清掉。

这会影响：

- bundle 源目录整洁度
- 交接理解成本
- 后续排错时对“哪些是源文件、哪些是运行产物”的判断

## 下一步建议

按优先级，下一步建议直接做下面几件事：

1. 先把 experts smoke 从“接受 workspace launch”收紧到“要求附件真实进入项目执行层”
2. 直接用客户端做一轮“上传人物图 -> Douyin expert -> 数字人”真实端到端验收
3. 用最新 runtime / bundle / smoke 标准，重新做一轮 XHS fresh-like 验收
4. 再完整复跑一次 `我们家的苹果`，把老案例的项目根状态也更新到成功态
5. 继续补 Day 1 的 `cloud-api.ts` / `project-workspace-executor.ts` 契约收口
6. 清理 `workspace/xhs` 和 `workspace/douyin` 根目录中的历史运行产物与旧说明

## 当前阶段判断

到 2026-04-10 这一步，项目整体进度可以这样判断：

- 基础运行时、bundle 契约、项目隔离、workspace-entry 已经进入可用阶段
- fresh install runtime 验收今天已经补齐，属于实质性推进
- XHS / Douyin 接入客户端主链已基本打通
- Douyin 已经有两条新的真实出片成功样例
- 客户端专家附件链路第一批最小闭环代码已落地，并完成基础类型/语法校验
- XHS 有较强的 fresh-like 旧证据
- 当前最大剩余风险已经从“客户端素材输入完全未打通”转成“附件链路 smoke 与真实端到端验收还没补完 + 统一最终验收还没完全补完”

一句话结论：

当前已经完成“能安装、能识别项目、能进入项目、能启动项目运行时，而且 Douyin 已有两条新的真实出片成功样例”，并且客户端专家附件链路第一批最小闭环代码也已经落地；但还没有完成“新电脑安装客户端后，XHS 和 Douyin 从配置接口拉 zip 就都已正式验收可直接跑”的最终封口。当前最明确的新阻塞点，已经变成“附件链路 smoke 和真实端到端验收还没补完”。

补充说明：

2026-04-13 基于当前仓库代码与产物的完成度盘点，见 `docs/douyin-xhs-插入/2026-04-13-代码事实完成度盘点.md`。
## 2026-04-13 补充

今天新增的关键结论：

- Douyin / XHS 的附件 smoke 已经从“只验证 `workspace-entry` 启动”收紧到“验证附件真实进入项目执行层”。
- Douyin 已补齐一条带附件的真实 live-run 验收，说明附件不只是落盘，而是已经进入真实业务链路。
- XHS 的卡点已经缩小到“项目脚本与桌面运行时配置不兼容”，不是入口没进，也不是附件没进。
- 后续模型配置方向已经明确：长期不再让各项目直接硬编码 `qwen`、`xhsImage`、`volces` 这类 provider 名，而是逐步改成由客户端统一配置文案 / 视觉分析 / 生图 / 视频模型，再由执行器注入给项目。

详细盘点见：
- `docs/douyin-xhs-插入/2026-04-13-代码事实完成度盘点.md`
## 2026-04-13 XHS live-run 补充

- `workspace/xhs/scripts/qwen.py` 已补齐对桌面端 managed config 的兼容，不再只认项目内 `models.providers.qwen`，而是优先从执行器注入的 `OPENCLAW_CONFIG_PATH` 解析当前可用文本模型。
- `workspace/xhs/scripts/run.py` 已补齐两类兼容：
  - 参考图分析阶段会先判断当前模型是否支持图片输入；若不支持，则退化为纯文本分析，避免把图片硬塞给 `openclaw-cloud/gpt-5.4-mini` 这类文本模型。
  - 生图阶段不再把 `xhsImage` 当成唯一前提；当客户端当前 managed config 没有可用生图 provider 时，会把项目主图/附件图复制到 `memory/generated_images` 作为兜底产物，保证桌面端项目链路能闭环。
- 2026-04-13 已重新执行：
  - `build/scripts/xhs-expert-live-run.ps1 -SkipMaterializeRuntime -SmokePort 4322 -BaseOutputDir D:\qjclaw\.tmp\xhs-expert-live-run-4322`
- 本次结果已闭环：
  - `xhs_last_note.json` 已生成。
  - `memory/generated_images` 已生成图片文件。
  - `workspaceAttachmentPath` 存在，说明附件已进入项目执行层。
  - `xhs_profile` 存在，说明项目脚本已实际运行。
- 需要明确区分的边界：
  - 这次 XHS live-run 成功，证明的是“桌面端 managed config + 项目执行器 + XHS 项目脚本”的兼容链路已经打通。
  - 这次生成出来的图片文件是附件兜底复用产物 `xhs_attachment_*.png`，不代表“客户端统一生图模型配置”已经完成。
