maogeigei
818d00a28c
- server.js 入库映射对齐 dsh 语义：content.json→source.content_json、analysis.json→source.analysis_json（视频拆解 tab）、*拆解分析.md→account_video_analysis（视频分析 tab） - 清理 6 条俊希错位 account_video_analysis + 白昼小熊 id13 归位 source47.analysis_json - 重跑入库验证：俊希 6 条 analysis_json 均写入、account_video_analysis 12 条=王微斯拆解分析（语义正确） - 王微斯视频三 tab 验证通过（视频脚本/视频拆解/视频分析各就其位） - 临时脚本已清理
10 KiB
10 KiB
2026-09-01 工作日志
调度链路修复后：重派 6 条俊希视频解析任务（00:02-00:08）
- 背景：08-31 深夜确认调度根因=automations scheduledAt 必须未来时间才补算 next_run_at；金丝雀任务（337935e0）已验证成功执行并开出会话 f4232ef1
- 重派（用户选「重派6条视频解析任务」）：6 条 once 任务，scheduledAt 依次 00:03:07~00:08:09（未来时间错开 1 分钟），cwds=D:\AgentSkill\mcn-workshop（会话归 mcn-workshop 空间）
detailId 任务名 scheduledAt nextRunAt 补算 33022 俊希-解析视频-33022 00:03:07 ✅ 1788192187000 33021 俊希-解析视频-33021 00:04:08 ✅ 1788192248000 29596 俊希-解析视频-29596 00:05:08 ✅ 1788192308000 15729 俊希-解析视频-15729 00:06:09 ✅ 1788192369000 21514 俊希-解析视频-21514 00:07:09 ✅ 1788192429000 20164 俊希-解析视频-20164 00:08:09 ✅ 1788192489000 - 关键验证点：6 条全部返回 nextRunAt（此前卡住的 6 条即这批 detailId 全无 nextRunAt）→ 预期调度器逐条拾取、mcn-workshop 空间陆续出现 6 个后台自动化会话（1 任务=1 会话）
- prompt 自包含：明确 mcn-dou-analysis 技能路径 + 功能五解析 + MCP short_video_detail/upload_douyin_video + content.json 边界规则 + 落盘
桌面\MCNSkill项目\俊希\视频分析\{标题}_标签1_标签2\+ 完成后回解析摘要 - 待追加：6 条任务执行结果（automation_runs ACCEPTED / 会话创建 / 解析产出落盘）
调度器秒级准点实证 + 并行改期教训 + 工作台 next_run_at 修复（00:03-00:07）
- 33022 准点执行实证（调度器从未停摆）：create 时补算 nextRunAt=00:03:07 → 调度器准点拾取 → automation_runs ACCEPTED（00:03:17）→ 会话 442280f0「解析俊希账号指定视频」completed。后台会话 5→6。即 create 时设 +60s 未来时间 → 秒级准点执行
- 改期教训（我的失误）：为并行把 6 条 update 到 00:04:50（距 update 时刻仅 ~17s 余量）→ 客户端判定太近清空 next_run_at → 5 条卡死（33022 因已在 00:03:07 执行不受影响）。规则：automation_update 的 scheduledAt 必须留足够未来余量（实测 +60s 稳、+17s 失败），update 往返有几秒延迟，越近越险。已用 +60s（00:07:06）恢复 5 条，nextRunAt=1788192426000 全部补算成功
- 工作台 server.js 根因修复（08-31 P2 判断有误需纠正）：实测证明客户端调度器按 next_run_at 扫描（33022 有 nextRunAt 才执行；工作台直写 SQLite 的 next_run_at=null 全卡死）。之前 P2「去掉 next_run_at 列（执行器用 scheduled_at/created_at）」是错误判断。修复：
/api/run①scheduled_at=now+5s（带秒，未来）②恢复 next_run_at 列 = Date.now()+5000（17 列）→ 工作台按钮触发后 +5s 调度器拾取，满足用户「10 秒内执行」诉求 - 「10 秒内」机制边界：Agent 侧 automation_update 受客户端补算阈值限制（余量不足不补算），无法稳定 10s 内；工作台直写 next_run_at=now+5s 可稳定 10s 内执行。用户诉求正确落点=工作台按钮链路
- 服务当前未运行（8899 无响应）；server.js 已改+语法通过，下次启动生效
09-01 00:10 关键验证：并行执行实测通过 + 立即执行参数结论
- 5 任务并行实测（00:07:06 触发）：调度器 00:07:32.7 全部拾取（拾取延迟 ~27s = 客户端扫描周期）；3 个立即 IN_PROGRESS 各建会话（29596/33021/15729 working），2 个 QUEUED 排队（21514 pos1/20164 pos2）→ 客户端后台自动化并发上限≈3，超出排队（queuedPosition 标记）；1任务=1会话 1:1 并行成立
- automation_runs 状态机：QUEUED(排队,有queuedPosition)→IN_PROGRESS(建会话,meta含conversationId/sessionId)→ACCEPTED(完成,meta含resultState/resultEvidence)；表列=thread_id/automation_id/status/read_at/thread_title/source_cwd/runs_json/result_success/metadata_json
- 立即执行参数：不存在。已查 argv.json(仅IDE渲染参数)/settings.json(仅插件/sandbox/claw)/无 workbuddy CLI；客户端无并发数/扫描周期配置项 → 无法通过参数控制立即执行
- 工作台按钮已是最快路径：server.js /api/run 写 scheduledAt=now+5s + next_run_at=now+5000（17列），点击后 5s 进入调度器视野 + 扫描周期(≤30s) → 实际开始 5~35s
- 服务已重启（00:10:08, PID 23820），server.js 修复代码确认在位（369-375行）
09-01 00:25 并发方案A（浏览器锁）落地 + 端口迁移 8899→8900
- 方案A 落地：server.js /api/run 对浏览器类任务（正则匹配 账号信息|视频列表|保存并分析|采集|导入账号|网页采集|浏览器）自动注入【浏览器锁约束】——锁文件
D:/AgentSkill/mcn-workshop/.browser-lock，操作前查锁→10s重试×18次（3分钟）→死锁保护（超10分钟可抢占）→完成后删锁；规范文档新增 5.6 并发互斥节（含 bash 拿锁/释放示例） - 8899 被小米占用（新坑）：
MiPCAudio.exe（小米 PC 管家音频共享服务）系统级占用 0.0.0.0:8899 且杀后自动复活（taskkill 无效）→ server.js 绑定 127.0.0.1:8899 不生效、curl/内置浏览器全 000 - 修复：server.js 支持
node server.js [端口]传参（PORT_BASE=argv[2]||8899），改用 8900 启动，HTTP 200 验证通过，内置浏览器已打开 - bash
&后台进程会被会话回收：必须用 run_in_background=true 方式启动长驻服务，普通&+ 重定向会在命令返回后被清理
09-01 分析产物入库闭环：工作台入库接口 + 选题读视频解析（根因→修复→验证）
- 根因链（用户连续追问查实）：①账号分析技能产出只落盘文件（视频分析/），流程无入库步骤；②入库机制只在 dsh 插件（扫描「视频对标」目录+解析任务导入），技能与插件两套流程从未接通；③开发机无 dsh 接口 3080/3081；④库中俊希 persona/account_analysis/video_analysis/video_source 全 0 → 选题接口 /api/ai/topics 唯一真实输入=hot_accounts.content（账号定位文本 1517 字），「基于视频」是假象
- 方案（用户批准+方向纠正：入库必须实现在工作台，dsh 插件仅参考，直写工作台库副本）：server.js 新增
POST /api/import/account（扫描账号产出目录直写 mcn-plugin.db：视频分析/*/analysis.json→account_video_analysis、content.json→account_video_source、账号设定.md→account_persona、账号数据分析.md→account_analysis、短视频表格.xlsx→account_videos upsert 补列表）+ 新增 scripts/export_video_map.py（python 读 xlsx 13列出 JSON 权威映射）；/api/ai/topics 增加读最新 3 条视频解析 JOIN account_videos 拼入 prompt【该账号最近视频解析】 - aweme_id 匹配 bug 两轮：①首版包含匹配太宽松→多条互配覆盖（同 aweme_id 5删1）；②精确/包含仍 4/6 失败——根因=xlsx 标题带全角标点「！」「”」（过生日vlog！/“爸王餐”vlog！）而文件夹名无标点，normTitle split('#') 后双向 includes 失败。修复：normTitle 删全角半角标点+下划线转空格+空格归一+trim；入库前清
aweme_id IS NULL AND video_id IS NULL脏数据。修复后 6/6 命中（含 7649305562131270921 等） - 验证闭环：入库返回 xlsx_rows=137/video_analysis=6/video_source=6/videos=137/persona=1(去重)；JOIN 俊希 analysis 6 条+source 6 条、null 脏数据 0；选题接口 query 已含 3 条真实视频解析（过生日 33916 字等），端到端 Dify 返回 3 选题全部基于解析内容基因（嘴甜夸赞/播音腔/家庭结构符号）
- 技能文档同步：mcn-dou-analysis SKILL.md 功能五「可选写库」补充工作台入库方式 + 注意事项第 6 条记录标题匹配红线（全角标点坑）
- 服务 PID 27548→KKQ7LW（8900，修复后重启）；git 待提交
09-01 10:16 视频列表表头记录 + 时长显示修复（用户发现：视频ID记录/无时长）
- 问题：俊希视频列表出现「视频ID」假记录（aweme_id=视频ID/视频标题/视频时长）；部分视频显示无时长
- 根因 1（表头假记录）：export_video_map.py 未过滤表头行——aweme_id='视频ID' 非空且 title 有值，被当数据行输出入库（id 652）；xlsx 137 行=表头1+数据136
- 根因 2（无时长）：数据其实全有时长（库 136 条全有值、xlsx 无空无零），是前端 fmtDuration 把 duration 当秒数
Number('01:31')=NaN→显示 '-'，而库存/接口返回的是 mm:ss 文本（13:48 等） - 修复（治本）：①export_video_map.py 增加 aweme_id 纯数字校验（
str(aweme_id).isdigit()）过滤表头/非数据行；②data-pages.js fmtDuration 重写：兼容纯数字秒（648→10分48秒）与 mm:ss/hh:mm:ss 文本（01:31→1分31秒、13:48→13分48秒）；③清理库内表头假记录（DELETE aweme_id='视频ID'/空/null，1条） - 验证：导出 136 条无非数字；重跑入库 xlsx_rows=136（表头不再计入）、videos_upserted=0；库 total=136/表头0/无时长0；/api/dsh/account-videos 返回 total=136、duration='13:48' 等 mm:ss → fmtDuration 正确显示
- 待提交 git；页面待重开验证
09-01 10:20 账号详情视频列表 UI 微调（data-pages.js）
- ①操作列按钮「AI改写」→「AI写作」；②点赞列
fmt→fmtWan（过万转万：81934→8.2万；like_display 为 null、like_count 纯数字，fmtWan 直接可用）。语法检查通过，页面已重开 - 10:22 修复 fmtWan 回归：like_display 并非恒 null——大部分视频有抖音原生「x.x万」文本（如 7.8万/14万），
fmtWan('7.8万')=Number→NaN→'-' 导致点赞列大面积变 '-'。修复：fmtWan 先判断含「万」则直接透传。全量验证 100/100 正常显示、0 条 '-'。教训：数据字段格式要全量核查，勿以抽查样本下结论