AI空间站 · 双AI制衡协作平台

🎯 目标

把"豆包派单 → DSH干活 → 双AI验收"从手动传话升级成自动化闭环，解决DSH派单链路不可靠、AI拿模板套话糊弄验收的问题。

💡 概念

单文件HTML作为平台外壳，集成入口选择层（用户选路径）、跟踪中心（项目看板+实时事件流）、 双AI制衡（执行AI用DeepSeek初验、复验AI用Kimi复验）；DSH当程序员、豆包当盯单员、 文心当质检员，一切状态以时间戳和真实凭证为信。

⚙️ 过程

1. 夜间盯单11小时定位卡死根因：执行器下午自动派7字废工单→验收失败→自动返工→DSH二次启动卡死，全程零变化 2. 用极简测试（新建test.txt写hello）隔离验证DSH本身正常，排除DSH故障 3. 验证入口选择层完好（两个卡片按钮+localStorage记忆），确认改动成功后DSH才卡死 4. 做双AI换模型：新增Utils.callKimi函数（SSE流式与callDeepSeek一致），把复验AI调用从DeepSeek切到Kimi，适配企业版模型kimi-k2.6 5. 修复设置页测试按钮写死DeepSeek接口的bug、全局禁用自动下载.ps1、清理会议页死代码4处

🚧 问题

- DSH headless命令行改415KB大HTML必崩（token上限→INVALID_REPLAY_STATE），只能GUI+Edit局部改+工单拆小 - 执行器会偷偷自动派单/返工/卡死，用户全程不知情（黑盒失控），改为只当记录仪 - Kimi企业版没有moonshot-v1-8k权限，只有kimi-k2.6/kimi-k2.7-code，测试按钮曾写死DeepSeek接口导致401 - DSH Desktop Hub端口每次重启动态分配（51417→49795→61526→53924），面板地址不能写死

✅ 成果

复验AI真实切到Kimi并跑通真实验收（P002显示"复验报告：不通过（维持初验判定）"非模板）； 执行器恢复3任务+队列恢复；文件497KB、+45行callKimi、删4处死代码-2346字节； 入口层/跟踪中心/双AI真实调用全部可用。

🔗 链接

• 背后的方法 · 多 AI 协同工作流 ↗

📂 过程资产

• 案例夜间盯单定位"AI卡死"根因的完整诊断法2026-09-24

  一整套可复用的"AI进程卡死"诊断路径：文件时间戳盯单→极简测试隔离AI本体→查会话内容反查执行器行为→定位真凶（执行器偷偷自动派了7字废工单→自动验收失败→自动返工→二次启动卡死）。适用于任何"看起来在跑但实际没动"的黑盒AI链路。

• 坑DSH headless 改大 HTML 必崩，只能 GUI + Edit 局部改2026-09-24

  用 DSH headless 命令行模式修改 >100KB 单文件 HTML 时进程静默崩溃（启动后无输出直接退出），500KB 级别必触发 token 上限导致 INVALID_REPLAY_STATE 会话损坏。解法：GUI 模式 + 只允许 Edit 局部修改 + 工单拆小（一次只改一处）+ 先读文件报行号再动手。

• 报告复验AI从DeepSeek切Kimi完整验收报告2026-09-24

  单文件HTML里给复验AI换模型提供方的完整流程与坑：新增callKimi函数（SSE流式与callDeepSeek一致）、企业版Kimi没有moonshot-v1-8k权限需换kimi-k2.6、设置页测试按钮曾写死请求DeepSeek接口导致401、真实验收验证（P002复验报告非模板）。含插入行号、文件大小变化、真实调用证据。