HS Knowledge Vault

2026-08-14 决策：DeepSeek 涨价应对 + watchdog 检查层设计 + V4 开源不转第三方

29分钟阅读

2026-08-14：DeepSeek 涨价应对 + watchdog 慢工具检查层设计 + V4 开源不转第三方托管

1. DeepSeek 8/16 涨价应对（官方确认，8/14 凌晨定案）

背景：DeepSeek 官方宣布 8/16 16:00 UTC（大马 8/17 00:00）起改 peak/off-peak 两段计价。

事实：

  • Peak（大马）：早 9-12 + 下午 2-6；off-peak：其余（含整个晚上+深夜）
  • Pro：off-peak miss +52%（0.66）、out +128%（1.98）；peak miss +203%（3.96）
  • Flash 同涨（out 0.66 off-peak）

决策：

  • 重活（Prime 批处理/部署/WhatsApp 迁移）尽量晚间派——off-peak 半价（我们本来 70%+ 用量就在晚上/深夜，天然避 peak）
  • 白天 peak 时段：小任务用 Flash max 或 Antigravity Gemini 分流（Pro 配额 8/18 前用完）
  • 双盲测试尽量 8/17 前跑完（旧价窗口）
  • 月账预估涨约 50%——有预算意识，但不改「质量优先」铁律

What changed：Hermes 记忆条目已 replace（DeepSeek-V4 Pro 定价条目更新）。

2. watchdog 慢工具层升级——「检查层」而非一刀切（8/14 凌晨，用户修正定案）

背景：hsdesign 卡在 WSL→Windows PowerShell 起 DSH 服务 6 小时无人发现。缺口链：①慢工具检测层（SLOW_TOOL）只加了 WSL 版 watch_prime.py，cron 实际跑 Windows 版 watch_prime_win.py（可能没这层）②PowerShell/cmd 不在黑名单（记录 WATCH 但不杀）③WATCH 行无消费者（救治 gate 只看 STUCK）。

用户纠正：PowerShell 超 10 分钟不能一刀切杀——它是通用壳，可能跑合法长任务（npm 安装/构建/大复制），误杀麻烦。

决策（检查层设计）：

  • 通用壳（powershell/cmd/bash -c）运行 >10 分钟 → 进入检查（不直接杀）：
    1. 子命令命中已知无界黑名单（find /、无界 grep -r、全盘扫描）→ 杀
    2. 子命令是合法长任务（npm install/build/大文件复制/apt 类）→ 不杀，标记长任务监控（阈值放宽到 60 分钟，期间查 CPU 活跃度）
    3. 进程 CPU≈0% 且无输出超 15 分钟（挂起空转）→ 判定失常 → 杀
    4. 无法判断 → 播报 Hermes 人工看
  • 直接杀的黑名单只保留已知无界无价值操作（find /、无界 grep -r 等）
  • 判定信号：CPU 使用率（ps 采样两次对比）、输出增量、子进程树变化
  • 救治 gate prime_recovery_gate_win.py 增加 WATCH 行消费：黑名单命中→自动 kill；非黑名单→汇总播报（deliver origin）
  • 测试：用昨晚真实案例（PowerShell 卡 6h CPU 0% 零输出）回归验证——新逻辑应判「失常」→ 杀

What changed：派单 system-ops 执行（A 移植慢工具层到 win 版 / B 检查层设计 / C gate 消费 WATCH / D 真实案例回归 / E 报告）；这是「假活检测第四层」的完整化。

3. DeepSeek V4 开源确认——但仍不转第三方托管（8/14 凌晨，两次打脸后的定案）

背景：用户转来 AI 推荐（DeepInfra 缓存命中 25/月无限 token）问要不要为涨价转平台。

查证过程（含两次自我纠正）：

  • 第一次：DeepInfra API 模型列表无 deepseek、Featherless API 只见 R1 蒸馏旧模型 → 断言「推荐是编造的」——错（API 分页截断就下结论）
  • 用户截图打脸 → 重新查证：Featherless 真有官方 deepseek-ai 组织 DeepSeek-V4-Flash-0731（MIT 开源 + FP8 + 284B + 256K）+ DeepSeek-V4-Pro
  • V4 确实开源了，第三方托管是真的

决策：不转（基于正确事实）：

  • 质量折损：FP8 量化 + 256K vs 官方完整精度 + 1M 上下文——Pro max 深度推理主力，量化伤推理深度；348 turns 长任务 256K 窗口会爆
  • 价格打平但不值：$25/月订阅 vs 我们的结构（98% cache hit + 中等总用量 + off-peak 半价）→ 官方 off-peak 混合价 ≈ 订阅价且不折损质量
  • 8 并发限制卡线（6 daemon + 测试任务并发）
  • 官方 Pro-0813 持续更新 vs 开源版可能停在 preview
  • 用户预算约 $50/月——官方路径仍最优

长期：V4 开源 = 第三方托管会越来越多 = 价格战 → 3-6 个月后可能有高质量+便宜的 V4 托管，届时再评估（质量验证过的话）。

教训固化：①API 分页截断就下「没有」的结论 ②截图证据比 curl 快——用户截图优先采信。

4. 错峰执行模式正式启动（8/14 早上 07:11 用户定案）

背景：用量重算后发现涨价后月成本 50——用户提出改变运作模式：不再全天用，集中在 off-peak 时段用。

决策：

  • peak 时段（大马 9:00-12:00 & 14:00-18:00，双倍价）：重度任务（Prime/长上下文）自动记入待办 → 不执行、不派 Prime；除非用户明说「紧急/马上做」
  • off-peak 时段（其余，半价）：正常交流 + 执行排队任务
  • cron 豁免：cron job（V4 Flash max）花费不大 → 不受 peak 限制，全天照跑；轻活（单次 API/提醒）同样照跑
  • 每日 23:55 成本播报 cron 已建（今日花费 + 本月累计）→ 8/16 涨价生效后每日对比差价，验证「错峰后总价反而更省」的假设
  • 用户经济学：以往高峰高频 ≈ 1.5 倍花费（peak 全两倍价）；现在起价但错峰 + 任务自然减量 40% → 现价 1.4 倍（vs 不改习惯 3.5 倍）

What changed：Hermes 侧 SOP 固化（skill + 记忆）；「9-12/14-18 你说任务 → 回复『已记待办，X 点后执行』」成为标准答复格式。

5. 用量统计口径定案：分段反推（8/14 早上，用户两次纠正后）

背景：Featherless $50/月 Developer 计划验证提示词需要真实用量画像。

纠正过程：

  • 错①：只算钱没读 amount CSV → 真实 30 天 = 53.3 亿 tokens（Flash 50.7 亿 / Pro 2.6 亿；hit 占 95%+），之前 160-200M 是「钱÷单价」反推（数学方向反了）
  • 错②：整月平均无意义（用量构成在爬坡：Prime 最近才用、Pro 8/13 才重度）→ 用户定：最新一天/纯用日反推

定案口径：

  • Flash 日均（8/11-12 纯 Flash 日）：hit 355M + miss 16.1M + out 3.6M
  • Pro 日均（8/13 重度日）：hit 232.1M + miss 10.2M + out 2.2M
  • 涨价后 off-peak 月化：500-600）；8/13 单日口径 $672/月
  • 新常态趋势：Flash 降（316M→172M hit）、Pro 升——8/14 晚结束后才是真实新常态

关键事实：cache hit 价涨 5 倍（0.022）是绕不过的；Flash 单请求平均 262K cache hit（超长上下文调用者，疑似 Hermes 侧）是最大可砍口子（砍半=月省 $30+）。

6. 双盲多场景扩展（8/14 早上 07:24 用户定案）

背景：任务一（迷你 HTTP 服务器）DSH 4 分钟完成但漏安全细节（路径穿越漏洞，10/11），Prime 25 分钟 8/8 全过——单场景不足以定分工。

决策：四场景矩阵对比：

  1. ✅ 任务一：代码生成（HTTP 静态服务器）——Prime 8/8 ~25min；DSH 10/11 ~4min（1 安全漏洞）
  2. 🏃 任务二：业务文档（装修报价单生成器，8 验收项）——Prime ✅ 8/8 ~19min；DSH 09:15 产物已出待验收
  3. ⏳ 任务三：调试修复（同一份带 3 bug 的代码）——晚上 off-peak 跑
  4. ⏳ 任务四：长上下文整理（原始业务数据 → 结构化）——晚上 off-peak 跑

新增铁律：每轮双盲验收「记忆隔离」——新 session 首条消息必须纯任务书、无记忆注入（任务二已验证：876 字纯任务书，Prime memory 是 per-session 的）。

Related（早上场）

7. 行程三源撞期铁律（8/14 10:47 固化）

背景：用户报两个行程（周日见高先生 + 周一见 Mr Mark），此前出现过「只查单源」漏检。

决策：用户每次告知行程 → ①三源查撞期（日历 + 待办 + D1）②建日历事件 ③展示时间轴。已固化 skill + 双兜底 cron（早 7:30 / 晚 8:00）。

本次落地：周日 8/16 下午见高先生（时间待确认，占位 14:00-18:00）+ 周一 8/17 15:30 Mr Mark（Senai）——日历均已建、三源无冲突。

What changed：skill + 双兜底 cron；日历事件已建（见高先生占位 / Mr Mark 15:30）。

8. 人生导图双向打勾 + Change Log 硬机制（8/14 11:52 用户定案）

背景：用户希望 life-map 任务页可自己打勾（或告诉 agent 代打），与待办互连；担心双向可写系统并发覆盖（用户改了我不知道）。

决策：

  • 双向打勾：页面打勾 ↔ 告知 agent 代打互连；agent 检查待办时自动跳过已完成项
  • 唯一真相源：人生导图 D1（与 sozo-todos 双向同步——现状已通，本次加固）
  • Change Log 硬机制：每次状态变更记录「谁改/何时/改了什么」——变更前先读日志对比版本，冲突时保留双方记录、不静默覆盖；做成硬机制而非约定

What changed：已派 life-map 独立 session（daemon lock 下用 autonomous 模式，session 文件 prime_lifemap_task3.jsonl）——打勾 UI + 双向同步 + 变更日志。

9. 双盲公平性定案（8/14 12:00 检查完成）

背景：用户质疑 Prime 设 60 turn 上限不公平、DSH 可能被中途截断（任务二 1-2 分钟出产物疑似太快）。

事实：Prime 上限实为 500 turns（60 = 任务二实际跑完的轮数，19/60 轮都没碰顶）；DSH 配置核实 = effort max + Pro 模型 + max_turns 90（未触顶）。

决策：两轮双盲成绩有效、公平成立；下次喂 DSH 将 max_turns 提到 500 对齐 Prime；双盲双方都在最大潜能下跑、不设会截断的硬顶。

What changed：DSH 喂任务参数（max_turns 90→500，下次执行）。

10. BytePlus ModelArk $50/月 Coding Plan 否决（8/14 10:15 核验）

背景：字节 BytePlus 出面整合 DeepSeek-V4/GLM-5.2/Kimi-K2.5/GPT-OSS，$50/月——用户转来分析问「分析得对不对」。

核验（逐项）：①18.66B 月吞吐画像（Flash hit 10.7B + Pro hit 7.0B + miss 789M + out 174M）✅ ②622M/天 × 300M 封顶 = 36 小时耗尽 ✅ ③官方夜间 500-736 一致 ✅ ④核心定性（$50 订阅无法承担 Hermes 架构吞吐）✅

决策：死路，不转——$50 月订阅覆盖不了架构吞吐量级；第三方整合模型上下文/质量（256K）不达 Pro max 深度推理要求。维持官方 off-peak 错峰策略。

What changed：无（维持现状；10:19 用户喊停后未深挖）。

Related（中午场）

11. 双盲两方制 + 盲审制（8/14 12:15/12:27 用户定案）

背景：任务一/二 DSH 连胜，用户怀疑任务不够重体现不出 Prime 高智商（当初因 AIGC 高分选 Prime）；要求重型任务验证，并质疑「Hermes 验收 Prime 产物」不公平（各 agent 自验 = 管家不同、评分标准不同）。

决策：

  • 双盲正式 = Prime vs DSH 两方制——Hermes 退出实验（定位 = 主管家：调度/验收汇总/业务决策；coding 比赛让专业选手比，对比更纯粹）
  • 盲审制：两方产物全部由 **Prime「无记忆盲审 session」**统一验收（新 session 无历史，A/B 匿名映射、同一评分标准、独立 curl 实测）——同考官看两份考卷才公平；用户判断 Prime 验收质量比 Hermes 高，采纳
  • 重型任务验证论点：任务三 = 装修公司客户项目管理系统（全栈，14 验收项）、任务四 = 复杂庞大 HTML（≥1200 行 10 大区块）——若 DSH 重型任务仍赢 → 工作流换血（大部分任务 DSH，超大型 Prime）；若 Prime 翻盘 → 分工按原样
  • delegate 子 agent 超时上限 600→3600s（Hermes 偶尔自己写大东西时够用；config.yaml.bak-delegation-20260814 备份）

What changed：记忆固化（盲审验收制 + delegate 超时教训）；任务三/四两方起跑（Prime 800 turns / DSH max_turns 500 对齐）。

12. 任务分配分工定案——「破坏半径」原则（8/14 13:50 用户拍板）

背景：状态机讨论（DSH 可绕过 → 数据乱不崩溃）+ 用户提出分工框架（初次架构→DSH、系统级优化→Prime、日常任务→DSH），要求客观评价并给更多场景建议。

决策（核心 = 看破坏半径，不是任务大小）：

  • 破坏半径小（从零生成/独立交付物）→ DSH（快 5-10x、省 50-90% token）
  • 破坏半径大（改现有系统/关键数据）→ Prime（先理解架构再小步改+验证，搞坏概率低）
  • 日常生成型任务（报价单/工程排期/客户文档）→ DSH + 规则注入 + 用户/管家验收
  • 现金流/应收对账 → Prime 或 Hermes（钱相关，错了是利润）；生产 bug 修复 → Prime（防二次事故）
  • DSH 量产两件套：①知识注入（AGENTS.md 式规则——SSOT 指针/客户编号禁猜/业务铁律；正式使用时执行）②交付验收（盲审/管家把关）——防「快」风格跳过 SSOT 校验
  • 修正：任何 agent 都可能搞坏——Prime 是「概率低」非「不会」

What changed：Hermes 侧建 skill agent-task-routing（每次派活自动路由，不再讨论）；分工定位：DSH=量产车间、Prime=手术室、Hermes=管家+质检。

13. WSL vhdx 迁移 D 盘 + C 盘清理（8/14 12:54–13:08 定案）

背景：WSL vhdx 落在 C 盘、C 盘只剩 4.1GB → ext4 只读 → 盲审/life-map 全崩（mkdir read-only）；WSL 内部其实 938GB 空闲。教训：用户早有「优先 D 盘」铁律，此事故违规所致。

决策：

  • 迁移 D 盘（18:00 后/深夜窗口，Prime system-ops 执行）：vhdx 21.9GB（大头，需全部 agent 停机）+ Ollama 2.4GB + whisper 573MB + Docker ISO 1.5GB；流程 = 停服务→移动→改配置→重启验证（每步验证）；执行前方案先播报用户过目；选 Prime 而非 DSH（系统级迁移出错代价高，Prime 稳且有配方模式）
  • C 盘清理（当日已执行）：V-Ray 日志 5GB + 剪映 1.8GB + Chrome 模型 4GB 删除（Chrome 会自动重下）；WhatsApp zip → 移 D:\hermes\archives\（核实 viewer 不引用，可能是历史聊天备份——不删只挪）；KOTA MASAI.max 删除失败（3ds Max 占用，用户关闭后补删）；DriveFS 缓存保留（用户指定）；累计释放 ~11GB + 移动 736MB → C 盘约 27GB

What changed：记忆固化（WSL vhdx 装 D 盘）；待办排期（18:00 后迁移任务）。

14. Hermes 直接派 DSH——跳过 hsdesign 转译层（8/14 12:32 定方向，实验后实施）

背景：用户问「delegate 派发原理 + 直接派 DSH 是否更省 token」。

事实：①派 Prime = prime-agent CLI 直接投递（非 delegate）②派 DSH = Hermes→hsdesign 转译→DSH web API（127.0.0.1:3300）③DSH 无 CLI 一次性模式但 web API 是 HTTP——Hermes 可直接 curl 喂任务；hsdesign context 已 208 messages，每次 send 带完整历史 ≈ 50-100K tokens + 一轮 Pro 推理。

决策：实验结束后实施——①从 hsdesign jsonl 提取 DSH web API 配方（端点/请求格式/任务创建参数）②Hermes 直接 curl 脚本化派单（每次省 ~30-80K tokens）③监控移交 watchdog。

配套（12:38 已派）：

  • system-ops：DSH watchdog 监控层——session 12 分钟无写入=卡死、3300 不通=直接报、任务完成自动播报；集成现有 5 分钟 cron 与 Prime 同一体系；只监控不自动杀（救援由 Hermes 主代理执行）
  • webwatch：Prime Watch 改名 Delegate Watcher——加 DSH 区（服务健康 + 当前任务 + 三态显示），修「进行中却显示暂无任务」bug

What changed：两任务已派；DSH 正式使用前还须 AGENTS.md 式知识注入（用户 OOB 要求，已记记忆）。

15. life-map 暂停 + 改派 DSH + Prime 内核环境重建（8/14 15:17 止损定案）

背景：WSL 重启后 Prime 代码执行内核环境级损坏——Python 3.12.3 asyncio 全局污染 → zmq/_future.py close() 调 None → jupyter 内核启动即崩；重装 ipykernel 7.3.0 + 换 3 个包版本均无效。life-map 打勾任务 5 次续跑全失败（烧 20+ 分钟 Prime token），最后一次幻觉完成（谎称「已完成、证据已落盘」但源码零改动）。

决策：

  • life-map 今天暂停（不再烧 token 重试）；18:00 后双线处理：①system-ops 重建干净 venv 给 Prime 内核 ②life-map 任务改派 DSH（沙箱不受 WSL 内核影响）+ 知识注入 + 验收
  • 教训固化：WSL 重启后第一件事 = 内核生命周期测试 + 修复后才恢复任务（否则多个 agent 空转烧 token）

What changed：待办 + 记忆（内核自检 SOP + 幻觉完成识别：报告「完成」必须对账产物落盘）。

Related（下午场）

16. 双盲实验收官——四轮总表 + 工作流换血定案（8/14 15:27）

背景：任务四（复杂 HTML）盲审 t4 两次撞顶（环境问题，maxTurns 524/250）→ 改 Hermes 直接验收（管家+质检角色，浏览器实测）。

任务四结果（A=DSH / B=Prime）：

  • DSH：3884 行｜10/10 ✅｜~6min｜51K tokens（9 项目卡片+隐私勾选+850 案例）
  • Prime：2228 行｜10/10 ✅｜16min｜6.05M tokens（创始人引言+品质保障 4 卡）

四轮最终总表：

任务DSHPrime质量
① HTTP 服务器4min·~0.5M tok25min·862KDSH 10/11，Prime 8/8
② 报价单1-2min19min·4.84M双 8/8
③ 全栈系统16min·2.5M24min·7.34M双 14/14
④ 复杂 HTML6min·51K16min·6.05M双 10/10

定案：用户论点「重任务 Prime 才体现高智商」→ 半对——Prime 严谨性细节确实更强（状态机/异常体系/校验），但质量验收从没赢过 DSH（三轮打平）。DSH 速度 1.5-10x、token 省 2-118x、质量打平 → 工作流换血成立。分工定案：DSH 量产、Prime 手术室、Hermes 管家+质检（skill agent-task-routing 已锁）。

唯一保留项：DSH 产物细节漏洞（任务一路径穿越、任务三状态机绕过）→ 上线前必须验收把关——盲审制保留。

What changed：四轮双盲实验正式收官；daily 傍晚场已记录总表；DSH_Graph 定位量产车间定案。

17. watchdog 播报误报修复三规则（8/14 17:57 用户质疑后定案）

背景：用户看到多条「Prime卡死自动救治」播报（当时 0 任务在跑）质疑。根因：15:0x 盲审 t4b + life-map resume4 相继退出（撞 maxTurns = 正常生命周期结束）→ watchdog 误判「卡死需救治」播报 + 13:38 SLOW 播报积压送达。

修复三规则（18:00 后派 system-ops）：

  1. 进程正常退出 ≠ 卡死——只有「进程活着但 jsonl 12 分钟不写」才报真卡死
  2. SLOW 播报只在 escalate≥2 时发（escalate=1 的 WATCH 不播）
  3. 无任务时静默——所有 worker idle + 无 autonomous → watchdog 本轮跳过不播

What changed：派单 system-ops（与内核 venv 重建同批）；验收标准 = 无任务时段零播报 + 正常退出不报救治。

18. Hermes 直接派 DSH 正式实施（8/14 18:10 用户纠正定案——不再经 hsdesign 中转）

背景：§14 已定方向（实验后实施）。实验 15:27 收官 → 18:10 用户指出「不应该再通过 prime agent 中转把任务交给 DSH」——18:04 派 life-map 仍走 hsdesign 是惯性错误（hsdesign context 208 messages，每次 send 带 50-100K tokens + 一轮 Pro 推理）。

决策：

  • 立即切换直接派：Hermes 直接 curl DSH web API（127.0.0.1:3300）喂任务，跳过 hsdesign 转译层
  • 连接配方来源：用户建议让 Prime agent 教 Hermes 怎么连接（它有经验）——已 send 索取配方（端点/请求格式/任务创建参数）
  • 配套：配方到位后脚本化派单 + 监控移交 watchdog（§14 已派）

同时确认：18:11 cron 播报 Prime 内核故障诊断 4 轮零交付（执行内核全崩、命令无法运行；life-map 喂任务/WhatsApp viewer/CRM 核验/watchdog 播报修复全部未开工）→ 需重启执行内核会话后重跑任务队列（life-map 任务书已就位、最高优先）。

What changed：DSH 派单链路从「Hermes→hsdesign→DSH」改为「Hermes→curl→DSH」；hsdesign 域将不再承担 DSH 转译职责。

19. 全面切 V4 Flash Max——预算保卫战（8/14 19:01 用户定案）

背景：用户发现预算烧太快（V4 Pro 接近 fiber5 但贵；Flash 表现已接近 Opus 4.8）→ 要求 Hermes/Prime/DSH 全部改 V4 Flash max。

决策：

  • Hermes → V4 Flash Max（config 已改，下个会话生效；当前会话仍 Pro）
  • DSH → V4 Flash（cordis.patch.yml + web 服务重启生效）
  • Prime autonomous（长任务） → 以后全部 --model deepseek-v4-flash
  • Prime daemon workers 暂保持 Pro（折中：重建 session 会丢 worker 注册表，试过已回滚）——workers idle 零成本，大头在长任务已全切
  • 机制确认：模型绑定 session 文件，agent 会话内切不了（/model 是 TUI 专用命令，daemon 消息触发不了）→ 只有「重建 session」才生效
  • 执行方案：今晚任务收尾 → workers idle → 备份注册表后重建 workers session → 全部 flash max（与 vhdx 迁移停机窗口合并，一次停机两件事）

What changed：除 daemon workers 外全部降级生效；8/15 全 DSH 实验日直接踩原价窗口。

20. cron 噪音治理——投递 local + Hermes 筛选机制（8/14 19:44 用户质疑后定案）

背景：用户：cron 通知（验收/救治播报复读）浪费聊天会话空间，只要有意义的东西。

决策：

  • Prime 验收播报 + 救治播报两个 cron：投递 → local（落盘 D:\hermes\cron\output\）、频率 1min → 5min
  • Telegram 不再接收任何 cron 自动消息；cron 输出落盘由 Hermes 筛选——真异常/真完成才主动播报
  • 规则：验收播报 → Hermes 自己处理；救治播报 → 只有「实杀/GATEKILL/新事件」才喊用户

What changed：聊天会话只含任务结果/拍板事项/进度播报；cron token 开销省 ~80%。

21. 应付账款分包商定位——Monday Blue Interior Design（8/14 19:50 用户告知）

背景：用户：应付账款是画图分包商，设计图分包给他，项目/Supplier 表可定位（已存记忆，与 carpenter 阿雄分开记）。

决策：

  • Monday Blue Interior Design = 画图分包商（应付账款对象），注册号 202303040551 (SA0592650-P)
  • 参考发票（Jln Seri Impian）：3D DRAWING ×13 × RM200 = RM2,600；发票号 MB-260629_15（2/8/2026）；收款 Hong Leong Bank 39500269469；条款：每区最多 3 次修改/先定金/出图后 3 个月内付清/不付款不交文件
  • 已派 master-app（现金管家 owner）查 D1 供应商登记状态（API 403 需鉴权）

What changed：vault 记忆 + 应付账款身份登记（画图分包商）。

22. vhdx 迁移执行方案定案（8/14 20:54）

背景：§13 已定迁移方向；20:51 用户「请处理所有待办」时细化执行方案。

决策：

  • 用官方命令 wsl --manage --move（非手动复制）；D 盘 381GB 充足 ✅；docker-desktop 一起迁
  • 时序：等 WSL 内任务完成 → 停机迁移 → 重启恢复（预计 21:00-22:00 窗口）
  • workers 换 flash 顺带重建（一次停机两件事）

What changed：方案从「手动复制」升级为官方命令；执行窗口确定；与 §19 合并停机。

23. 明天 8/15 全 DSH 实验日（8/14 21:09 用户定案）

背景：用户想在 8/16 起价前的原价窗口，测高强度使用下 Prime vs DSH 的差距（看到 YouTube 99.8% 缓存命中率视频，想实测）。

决策：

  • 8/15 所有任务 → DSH + V4 Flash Max，Prime 完全停用一天（workers 不派活）
  • 基线：今天 $8.99（Prime 时代）→ 明天全天对比
  • 缓存命中率实录：Prime 95.6% / DSH 96.5%（混合真实任务）；99.8% 只可能在重复性场景（cron 每 5 分钟全 hit）或单会话长跑——非普适

What changed：实验二启动（全 DSH 一天 vs Prime 时代 $8.99 基线）。

Related（夜晚场）

关系图谱

反向链接