半夜两点的一次点名:管道健康不等于数据新鲜

2026-08-10 01:40,本人发来一段批评,对军师和他自己都不满意,要求"做完复盘总结就去睡觉"。本篇是这次复盘会话的完整沉淀:一次数据管线事故的现场排查,加一份军师侧整改清单。

背景

8-7 金华酒局翻车(4 两白酒+啤酒喝到失忆、席间拿酒瓶砸了大哥胜磊),8-8 宿醉休整,8-9 台风停工第二天。本人 8-9 晚复盘时集中开火:

• 对军师:数字人团队(CrewAI)转型测试结果失望;微信、钉钉群消息"好像还停在 7 月底";todo 清单补录忽略很多;项目越来越臃肿;zdq 放养,"我不懂股票,你也没怎么帮我管好";
• 对自己:喝酒误事、网络安全课程跟不上、系统分析师蛇尾。

时间是半夜 1:40,产出要求是当次完成日复盘+次日清单+App 补录,不许"明天再说"。

过程回顾

排查 1:钉钉"停在 7 月底"——属实,且是真事故(详写)

inbox/dingtalk/ 最新目录确实是 20260731。但 tools/dingtalk_watch 的计划任务 DingTalkDailyCollect 每天 06:52 都在跑,日志每天报"[ok] 解密完成 + 无新消息"。

三层验证定位根因:

1. 查本地解密库:遍历 dingtalk.db 全部 tbmsg_* 分片表,监控群(cid 61569575609)最近一条消息 createdAt = 2026-07-31 15:13——本地库真的只有到这;
2. 查源库:C:\Users\three\AppData\Roaming\DingTalk\1136178_v2\DBFiles\dingtalk.db 的 mtime = 2026-08-03 17:10,之后一周没动过;
3. 查进程:tasklist 无 DingTalk.exe——桌面客户端根本没在运行。

根因:解密管线只读本地库,本地库只在客户端登录时同步;客户端 8-3 后没登录,管道每天 06:52 忠实地解密一份过期数据库,然后报"无新消息"——技术上句句属实,业务上是连续 7 天的假阴性。

watcher 的设计缺陷:只校验"解密成功"(管道健康),从不校验"源库新鲜度"(数据时效)。[ok] 报的是工具活着,不是数据活着。

排查 2:微信"停在 7 月底"——不属实,当场纠正

inbox/wechat/ 最新目录是 20260809,同步正常。本人瞄到的"停在 7 月底"应该是钉钉,或者是旧目录印象。按铁律二如实纠正,不顺着他的话认下不存在的错。

整改 3:todo 清单补录(详写)

批评属实:当日 Kimi Code 各项目的 AI 开发活动没有补录进 App。根因是流程缺陷——补录动作压在复盘收尾,会话一中断就丢。

当次用 tools/todo_export/import.js 补 3 条(done:true,落点 8-9,落点日期与今天不一致的警告属故意忽略):

• CrewAI/yinliu 体系建设:素材卡机制落地(事实红线入 rules)+rules 瘦身+篇3 发布包制作(当日 10 个 commit);
• 数字人团队(CrewAI 引擎)转型实测:产出质量不达标,待军师出诊断与收缩方案;
• zdq 量化:4 个策略稳健性研究脚本开发(f5/gold 参数/融资动量/小盘过滤,工作树未提交)。

另为 8-10 新增 1 条:"上班第一件事打开钉钉桌面端登录"。写后从 App 视角 run.sh --days 2 --md 复核,落点与勾选状态全部正确。

盯梢 4:zdq 与额度(略写)

• zdq 当日零 commit,工作树悬 4 个新研究脚本+3 个改动——8-8 的收工 commit 也在零点 10 分,快照纪律连续失守,复盘里点名,次日早复核;
• Kimi 额度:早 51% vs 时间进度 71%(落后 20pp,触发红线)→ 01:47 76% vs 81%(差 5pp),当日 +25pp,主攻强度达标,撤销加量点名;
• 对照结论:8-9 不是没产出——篇3 终审+发布 ≥4 平台完成(8-8 顺延任务兑现),额度曲线与 yinliu 10 个 commit 互相印证。

决策 5:对 CrewAI 转型的处置建议(详写)

本人对数字人团队转型的测试结果"比较失望,感觉疲惫"。军师的判断写进了复盘:crew 编排层当前的产出质量配不上它的复杂度,继续加码是追加沉没成本。建议:暂停 crew 扩张,回退"军师派单+子代理"主线(当日 yinliu 10 个 commit 证明这条线能打),军师出一页诊断(问题在任务拆解/人格文件/引擎),再定去留——属于主线方向变更,按决策分级报本人一句话确认。

关键踩坑

• 坑 1:"无新消息"的假阴性。现象:同步工具每天跑、每天报 ok,数据却停在 7-31。根因:只监控管道活性(解密成功),没监控数据时效(源库 mtime)。解决:①短期靠本人每天开钉钉客户端;②军师侧给 watcher 加"源库 mtime>24h 告警",翻车台账记一次,归因:工具配置。
• 坑 2:补录流程的位置依赖。补录压在复盘收尾→会话中断即丢失。解决:补录提前到复盘中段执行,不赌会话完整跑完。
• 坑 3:摊子铺开速度 > 盯梢覆盖面。钉钉断一周无人发现、zdq 放养、crew 翻车,同一个根因:多线并行但验收纪律没跟上。解决:收缩优先于开新线——code-cleaner 清 thinking 仓、周复盘做主线资源重排、周复盘固定加"zdq 三句话人话汇报"(净值 vs 基准/本周调仓/当前最大风险)。

做得好的地方

• 批评没有照单全收:微信条目当场用目录证据纠正,其余认账——诚实镜子两头都要当;
• 根因排查一次到底:没有停在"钉钉没同步"的表面结论,三层验证定位到客户端未登录,整改才能对症;
• 复盘当次闭环:复盘文件、App 补录、次日清单修正、kb sync+印象笔记 push,01:40 提需求,02:00 全部落地。

复盘与改进

• watcher 类工具统一补一条设计原则:管道活性检查必须配套数据时效检查,报 ok 的前提是"源数据是新的",这条要写进 zhengli 技能和各 watch 工具;
• 本人侧的依赖(钉钉客户端在线)要显性化——凡是管线依赖"他得开着某个软件"的,都要在断档告警里写清"需要他做什么",不能只在文档里;
• "军师带不动摊子"的结构性解法还没落地:code-cleaner、陈旧告警、crew 诊断都是 8-10 的动作,做完才算数,本篇只是立案。

素材点(可供未来自媒体复用)

1. "同步工具每天报 ok,数据却停在 7 天前"——管道健康≠数据新鲜,一条命令查 mtime 破案;
2. 半夜 1:40 被本人点名批评 6 条,军师逐条核:3 条认账、1 条当场纠正、2 条给整改方案——"AI 军师怎么被调教"的实录;
3. 三人局 4 两白酒喝到失忆砸大哥之后的规则升级:"白酒零杯"不是少喝,是不碰;
4. crew 编排层的沉没成本判断:"产出质量配不上复杂度时,回退简单管道不是认输,是止损";
5. "摊子铺开速度 > 盯梢覆盖面"——AI 团队扩张期最容易翻的车,不是技术,是验收纪律。

备选标题

1. 管道健康不等于数据新鲜:我的钉钉同步工具对着过期数据库跑了 7 天 ok
2. 半夜两点被投资人点名:AI 军师的 6 条批评与一次根因排查
3. AI 团队扩张期第一坑:摊子铺得比盯梢快,钉钉断更 7 天无人发现