野生码农
背景与目标
晚上例行跑 geo-push 推完 10 篇新稿后,本人报 bug:团队#41《批量任务烧穿限额根因与熔断》昨晚已点「发布完成」,但篇目还挂在今日待办里,且因为没归档,geo-push 也没把它推上 GEO 博客。目标:定位为什么点了没生效,把篇目正确归档,补推博客。
本期工作清单
- geo-push 例行推送(略写):新增 10 篇(ai-log 8 + prac-team 2),增量过滤剔除 272 条,导入汇总 新增 10 | 覆盖 0 | 跳过 0,三条前台验证全 200。
- 团队#41 未归档 bug 排查与修复(详写):见下。
- 补推团队#41(略写):归档后重跑管线,新增 1 篇(#433,prac-team),库内总数 407,验证全 200。
- 台账登记(一句话):故障台账记 2026-10-08 条目,项目台账 IPMS 行刷新。
过程回顾
尝试 1:查代码路径。先读状态机(state_machine.py 20 条转移表)和 advance_status,fabu就绪→已归档 是合法转移,本人可操作,无前置条件。代码层面看不出拦截点。
尝试 2:查数据库实态。item 表团队#41 status=fabu就绪;publication 表 9 条记录里公众号/知乎/CSDN/掘金/百家号/抖音 6 条已被采集核对回填「已发」,小红书/头条/B站 3 条「待发」(本人本就不发这三个平台)。
尝试 3(关键):查事件日志。event_log 里团队#41 最后一条停在 20:02 组装完成——没有核销事件,没有「删除待发」事件,连「非法流转拒绝」都没有。这一条直接改判方向:请求根本没到后端,别在代码里找 bug 了。
验证:备份库(VACUUM INTO,WAL 口径)后,用 curl 完整重放前端弹窗的动作序列——DELETE 三条待发 → POST transition 已归档(实发日 2026-10-07)——一次全成功,事件留痕、实发补记槽落库、待办清单清零。后端与运行进程均无问题,失败发生在浏览器侧。
关键踩坑
- 现象:点了「发布完成」无效果,服务端零痕迹。
- 根因:请求未到达后端即失败(浏览器侧静默失败,大概率是确认后首个请求报错、红色 toast 一闪而过未被注意)。uvicorn 跑在 pythonw 下无访问日志,事后无法取证——这是可观测性缺口,已记台账待立项补 access log。
- 解决:API 重放收口,不纠结复现;给本人的规则沉淀=再遇"点了没反应"先看有无红色错误提示再报。
最终方案
不重现、不改代码,用系统自己的 API 契约重放本人意图(删 3 条不想发平台的待发记录 + 归档 + 实发日 2026-10-07),再补跑 geo-push。全程可回滚(操作前 VACUUM INTO 备份 data/ip_backup_20261008_pre41.db)。
做得好的地方
- 事件日志先行的排查顺序是对的:代码看不出问题时,event_log 的"零痕迹"本身就是最强证据,一步把战场从后端代码挪到浏览器侧,避免无效读码。
- 备份纪律执行到位:改库前 VACUUM INTO(WAL 三件套教训沉淀的口径),实操零风险。
- 收口完整:修复→补推→故障台账→项目台账,四处落点一次走完。
复盘与改进
- 「静默失败无日志」这类问题以后还会再来,IPMS 的 uvicorn access log 落文件该立项了,否则每次都是猜。
- 前端 confirm 流程是"先并发 DELETE 再 transition"的两段式,任一段失败都中断但提示弱;可考虑后端合并成单端点事务(删待发+归档一次提交),从根上消灭半吊子状态。属优化项,非本次必须。
- 本人长期不发小红书/头条/B站的话,平台管理里停用更省事,组包不再建这三条待发——已给本人选项,待拍板。
成长评估
| 维度 | 分 | 证据 |
|---|---|---|
| 指令与提示词质量 | 8.5 | bug 报告一条到位:定位锚(篇目号+标题)+现象(还在待办)+基线对照(以前都是正常的)+关联症状(geo-push 没推上去),AI 零追问直接开查 |
| 判断与结论 | 8 | "小红书、头条、B站我本来就不想发的"与库中 3 条待发、6 条已发的实态完全吻合,记忆与系统一致 |
| 思维方式 | 8.5 | 主动把两个症状(待办未清+没推送)关联成一条因果链报出来,省了 AI 一轮归因 |
| 最终结果与产出 | 9 | 归档+补推+台账全收口,无返工 |
| AI 协作能力 | 8.5 | 授权边界清晰(该修就修、该推就推),未过度请示 |
AI 自评失分点:①第一次 curl POST 中文 JSON body 被 Windows 编码坑了("There was an error parsing the body"),浪费一轮,应直接 --data-binary @file;②sed 更新项目台账因分隔符冲突失败一次,应直接用 Edit 工具。两处都是 Windows 环境老坑复发,手脚比台账慢。
指令实证:本人原话「我已经点发布完成了,结果它还在今日待办里面。小红书、头条、B站,我本来就不想发的,以前都是正常的,现在出问题了」——"以前都是正常的"这句基线对照直接把排查从"功能是不是坏了"收窄到"这一次有什么不同",AI 因此跳过全量代码审查直奔状态证据,全程 30 分钟内收口。结果证据落点:台账/故障台账.md 2026-10-08 条目、ip.db 事件日志 id≥1753 区段、GEO 库 #433。
素材点
- "零痕迹就是最好的痕迹":服务端事件日志什么都没有时,bug 在客户端——排查方法论可写成 S2 媒体稿。
- 两段式前端流程(先删后流转)的半吊子状态风险,可写 S3 技术向:为什么 mutating 流程要单端点事务化。
- 备份纪律实战:VACUUM INTO 口径第二次立功(第一次是 10-07 ip.db 迁移前备份翻车后的自修)。