原则与记录
第1章 · 笔记 1
笔记 1
- 本轮收尾：卡 t_3db91bfc 已 ready（实现方式 = 卡上 pin deepseek-v4-pro，与豆蔻写稿同款做法）；临时文件已清理；本文件告一段落
### 2026-09-14 · 第四轮：正生纠正「把随口举例当成权威前提」
- 正生指出：乾婆把他随口举例的「真相源 / 记录 / 报告知识」三层系统化写进了本文件，等于把未经考据的内容当成权威指令
- 正生给出判断准则：命令口吻 → 可执行（即使违背事实）；商量 / 普通口吻 → 不可采信、仅供参考，接受程度由乾婆判断
- 处置：第八节加「⚠️ 重要更正」；原「分层判据 / 落地形态」降级为待专项调研；新增判据 #8；议题回到未完成态
- 乾婆自省：错误本质 = 把「方向」当成了「结构」。方向可以随口给（该分层、该有一层能一次查到的真相），结构必须考据（分几层、按什么维度、怎么落）。我却在没有任何调研的前提下直接给出了落地方案 —— 恰好违反了自己刚提的判据 #2 / #3
### 2026-09-14 · 第三轮：模型覆盖入口 + 知识库基础设施 + 发现两个前身
- 正生补充：默认不是 max 没关系 —— 每个看板任务可临时指定模型，连调回来都不用（→ 判据 #6、案例 1 补充）
- 正生提出知识库作为元婴修炼的基础设施：真相源层 / 存档记录层 / 报告知识层三层 + 一个小索引（→ 第八节）
- 正生确认案例 2 指向唯一真相源问题：「通达」「统一」尚未实现
- 正生就「目标函数」提问 → 乾婆给出通俗释义（第五节 9）
- 乾婆查库发现两个前身项目（8/13 系统瘦身计划 · 9/6 Project Pruning），给出「战役 vs 制度」判断（→ 第九节）；另捡到微观净减标的：concepts/ 下 9 个 .bak-* 残留（改一次留一份、从不清理 —— 「有生无死」的最小实例，按铁律不擅动，仅报告）
### 2026-09-14 · 第二轮：正生全部认同 + 系统实态实证 + 案例 1
- 正生全部认同第五节的提炼（含「先修通止损」边界与「增减比」两点），要求先存下来、在其上继续发展修改
- 正生给出系统实态的核心判断（→ 第六节）：功能未膨胀（加乾婆日志时砍掉脱口秀），错的是复杂度/技能数/Token/账单 —— 并认为这一点可验证
- 正生提出案例 1（深度推理交给阿普，而非乾婆临时调档）并问乾婆是否认同 → 乾婆认同，补出更硬的机制理由（常规通道 vs 破坏性开关）与两项附带优势；同时实测校正了「阿普是 max」这一前提
- 乾婆追加：判据 #4「要代价不要闸门」、判据 #5「长在角色层不长在任务层」、案例 2（一个配置事实翻 5 处）
- 元观察（自我记录）：本轮乾婆为核实一个配置事实连做十余次工具调用 —— 这正是「增加式」的苗头。按判据 #1，此类深度取证本就该交给阿普在任务里做，而不是消耗长驻会话的上下文
正生给出「建卡方向（报警处理）」与「Token 消耗（群聊通知）」两个例子，讲清元婴修炼是附加在每个事件处理上的意识（处理照旧处理，只是多一层自问），并点出当前机制的根本缺口：「没有关于元婴修炼的方向，也没有力量把它往内推」。乾婆的提炼（本文件第五节）同步落盘。
正生授权在需要更深思考时临时调至最高档。乾婆核查实态：当前 agent.reasoning_effort 已是 high（2026-08-29 定档，当时正生明确不开满 max）；改到 max 需改配置 + 重启网关才生效（boot-once），会话内无法热调。故本次讨论不调档、直接给判断；若后续需要长链条推演（如整套机制成型设计），再单独走调档流程（代价：会中断当前会话）。
正生提出计划，定名「元婴修炼计划」，指定第一刀为「精简」，明确「减少式优于增加式」的取向。确立本文件为唯一沉淀落点，暂不建卡、不定稿、不设限死。
正生看不到电脑上的文件 → 讨论全部在飞书私聊进行，乾婆负责把谈出的内容实时落盘到本文件，正生不需要自己看文件。
第六节 6 条待讨论议题由乾婆起草，作为引子 —— 正生可挑一条展开、可合并、可直接推翻，也可另起切入点。
tags: [troubleshooting, incident, archive]
description: "踩坑记录 2026-08 月度归档（含 08-16~08-23 二次归并，t_9d1358d2） + 自动归档 20260828(18条) 覆盖至 08-25 + 自动归档 20260829(7条) 覆盖至 08-26 + 自动归档 20260830(10条) 覆盖至 08-27 + 自动归档 20260831(16条) 覆盖至 08-28 + 自动归档 20260831(14条) 覆盖至 08-29 + 自动归档 20260901(28条) 覆盖至 08-30 + 自动归档 20260902(19条) 覆盖至 08-31"
由 F2 页面拆分（t_0eb1e5ea）从 concepts/踩坑记录.md 归档。
本页为 2026-08-01 ~ 2026-08-26 的历史踩坑条目（（2026-08-28 自动归档 wiki_log_archive.py） + 2026-08-29 自动归档 wiki_log_archive.py），活跃查询请见主页面。
2026-08-31 · [如花] 局部变量遮蔽模块级工具函数（t_420fa711） · 写 _verify_send_with_readback 时用 ok, detail = feishu_readback_message(...) 作局部变量名，随后 ok('读回验证通过: ' + detail) 把 bool 当函数调用抛 TypeError——模块级颜色函数 ok() 被同名局部变量遮蔽 · ① 函数内局部变量名不要与模块级工具函数同名（ok/fail/warn 等短名极易撞）；② 新增逻辑后先跑分支单测（mock 依赖函数），单测第一轮即抓到该 bug——证明单测对交付质量有效 · 🔍 分支单测 9 用例全过；修复后真实发送+读回验证通过 · 读回验证
2026-08-31 · [阿普] 升级预检脚本 UnboundLocalError + cron_error_watchdog 误判「已恢复」断头（t_030bd333） · cron 4ce04835733e（升级预检，每周一 10:00）failure_streak=4，告警推智囊团无人认领；watchdog 检测到失败后重试并判定「已恢复」，从不告警建任务（.error_watchdog_kanban_state.json 为空佐证） · 问题1：upgrade_check_report.py build_chinese_brief 中 breaking 只在 critical_changes 非空时定义、our_gaps 只在 config_gaps 非空时定义，第272行 if breaking or our_gaps 在数据为空/过滤后为空时抛 UnboundLocalError。修复=两变量无条件提前定义（顺带修掉「过滤后为空仍输出空标题行」伴生缺陷）。问题2：retry_job() 用 hermes cron run CLI 退出码判成功，但该 CLI 即使脚本失败也 exit 0（实测 "Ran now: failed." + exit 0）；且重试环境只设 HERMES_PROFILE=default，而 cron store 按 HERMES_HOME 解析（cron/jobs.py 锚定 get_hermes_home()，issue #4707 per-profile 设计），HERMES_HOME 缺失时 CLI 读错 store 报 "Job not found" 仍 exit 0 → 双重误判「恢复」。修复=①成功判定改读重试后 jobs.json 的 last_status（error=失败/ok=恢复）；②重试与建任务两处 subprocess 显式加 HERMES_HOME=/Users/mac/.hermes；③重试后刷新内存副本 last_run_at（旧代码用重试前时间戳写去重 state，修复判定后会导致同一故障每 30min 重复告警+建任务，断头变轰炸） · ①CLI 退出码不可信是系统性陷阱：hermes cron run 任何情况都 exit 0，判定 job 成败唯一权威=jobs.json 的 last_status；②HERMES_PROFILE 不影响 cron store 路径，只有 HERMES_HOME 参与 get_hermes_home() 解析——跨 profile 操作全局 jobs.json 必须显式 HERMES_HOME（与 t_2ed14499 结论互证）；③修「永不触发的路径」时要检查被掩盖的连带缺陷（时间戳刷新 bug 被旧误判掩盖）；④验证闭环方法：造临时必失败 no_agent job→触发→跑 watchdog→确认「重试仍失败」判定+告警+建任务+二次运行去重→全清理 · 🔍--dry-run 复现 exit 1→修复后中文简报正常 + 真实触发 4ce04835733e last_status ok/failure_streak 4→0 + 临时 job 全链路 watchdog 验证（判定/告警/建任务 t_282f5110/去重）+ 测试产物全清理 · t_030bd333
2026-08-31 · [如花] 回归素材 seg_artifact29 窗口配置漏检（t_c332967f） · 建立哨声回归素材集时给 seg_artifact29（29s 真实 artifact 段）配 --segments 2.0-8.0，首跑 relay 判 suspect 不 rework；本地全段频谱扫描发现真实怪声在 15.0-16.25s（1200Hz 纯音 6 窗），2-8s 窗口完全没截到 · ①怪声素材必须先本地全段频谱扫描（detect_tone_windows）确认怪声真实位置再定 segments 窗口，不能凭经验截头段；②omni 报的怪声位置不可信（报 5.78-5.90s 实为幻觉，真实在 15s 后），物理层定位为准 · 🔍修正 segments 14.0-20.0 后 rework 检出，全量回归 15/15 PASS · 回归素材集
2026-08-31 · [阿普] 技能库版本保护盲区：scan cron 是事后巡检，直写改前内容可能从未被快照（t_e03ef859 / R-0831-06） · 8/30 私有补丁体系合并时 16 个外置技能 cross_profile 直写，.versions 自动备份全部没触发。排查发现 skill_version.py + 整点 scan cron（skill-version-backup, job=4341edf7d254）一直在跑且 8/30-8/31 有产出——机制存在但架构性失效：scan 备份的是「扫描时刻」内容，直写发生在两次 scan 之间时「改前版本」可能从未进过 scan 视野，回滚点不存在 · 治本=写入路径强制先快照：新建 tools/skill_snapshot.py 钩子插入 ShellFileOperations 三个写入点（write_file/delete_file/move_file），覆盖 write_file_tool/patch_tool/V4A patch/execute_code RPC 全部直写路径；改前内容快照到技能自身 .versions/（与 scan 同库同格式，rollback/list 直接复用）；best-effort fail-open 不阻塞写入；no-op 写入（新内容==盘上）跳过；非技能路径零开销。顺手修 skill_version.py backup() 同秒覆盖 bug（copy2 遇同名直接覆盖会毁掉旧快照致 rollback 静默失效，加同名秒数递推） · ①「事后巡检型备份」对「写入路径保护」是结构性缺口，巡检再频繁也保不住改前内容；②快照钩子必须 fail-open（快照失败不能阻塞业务写入）；③去重语义=「改前内容已有回滚点即可 SKIP」（latest==盘上时无需重复快照），验收断言要按此语义写；④editable 安装改源码即生效但须重启 gateway 后工具层才加载新钩子 · 🔍mock 环境 11/11 单测 + 真实技能直写→快照→rollback 闭环实测（含去重 SKIP 场景）+ 现场完全复原（SKILL.md md5 复原、.versions 恢复验证前 14 份） · t_e03ef859
2026-08-31 · [如花] 合成对照素材标注不可靠致负例误报（t_c332967f） · synthetic_robot/negative10.mp3（b1.wav+b2.wav 拼接）被标为「正常对照」，全量回归 2/2 判 rework FAIL；本地音高动态分析：b1=46Hz vs b2=207Hz，两句说话方式差异巨大，omni 判「不一致」实为正确判断，素材标注错误而非工具误报 · ①合成拼接素材要验证「同一说话人」假设（音高动态/音色一致性），不能只看生成脚本标注；②负例用强负例最可靠（同句接两遍=必然一致，判 rework 才是真误报）；③预期值被稳定打脸时先查素材真值，别急着改工具或改预期 · 🔍b2_mid_robot 动态 144.9Hz 仍在正常范围（105-172Hz），mid 档人耳难分辨→syn_pos_mid 降级 weak；负例换 vc_normal_same · 回归素材集
2026-08-31 · [乾婆] Token日报「未登记key」归属连环误判（两轮纠正） · 日报显示「智谱-未登记key ¥0.12」，乾婆第一轮仅凭广智 config 出现该 key 就定性「广智专属」，被正生驳回（正生还误以为涉 OpenRouter key）；第二轮拉账单 4516 行明细看消费模型指纹（glm-asr/glm-4-voice/glm-5-turbo 无任何代理工作负载在用）才定位=全局 .env ZHIPUAI_API_KEY 系统脚本共享 key（vision_relay/audio_listen_relay/model_compare_test 等在用），即旧 Claw key（2026-03-23 建） · ①定性 key 归属必须看账单消费模型指纹，配置文件出现位置≠使用方；②「某代理是否走某平台」看顶层 model 块 base_url 实锤；③Hermes 会把 .env key 以掩码格式写回 config（api_key: sk-xxx...xxx 尾号样式），排查明文违规先比尾号再定性；④key 迁移后必须实测对话+读图双通道再确认完成 · 🔍根因+迁移全记录 · key治理
2026-08-31 · [阿普] token_daily_report.py 两处误标修复 + relay-py key 登记（t_c54bef8b） · ①日报 OpenRouter 行把豆蔻当前顶层模型名贴到消费行（result["model"] = read_doukou_model()），8/30 显示「OpenRouter · deepseek-v4-pro · ¥3.58」实为豆蔻千问@OpenRouter 切换窗口残留，正生两次被误导；②旧 Claw key（570a28）账单行匹配不到 ZHIPU_KEYS → 归 _unknown 显示「未登记key」 · ①OpenRouter 行模型列改中性标法「豆蔻key期间消费」（key 级 usage 拿不到历史模型名，不试图恢复）；②ZHIPU_KEYS 新增 relay-py（全局 .env ZHIPUAI_API_KEY，53c78a 开头，正生命名）；③死代码 read_doukou_model()/DOUKOU_CONFIG 删除；④顺手清理广智 config zhipu-2 段（唯一明文 Claw key 残留，key 已删成死值）+ model_catalog excluded_providers 死引用，444 回锁 · ①快照差分口径下「模型列」只能表达 key 维度，任何贴当前配置值的写法都会在配置切换后变成误导；②ZHIPU_KEYS 登记纪律=账户下所有产生消费的 key 都要登记（关键配置参考.md 已固化）；③删 provider 段时同步查 model_catalog.excluded_providers 等引用点，不留死引用 · 🔍dry-run 8/30：relay-py 行注册生效（¥0 正常，旧 key 行「未登记」属历史账单正常）；8/31：无未登记行、relay-py 正常；OpenRouter 行显示「豆蔻key期间消费 ¥3.58」；分组合计=账户总费用不变；广智 config YAML 解析通过、明文 key 零残留 · t_c54bef8b
2026-08-31 · [乾婆] 误把派单任务 kanban_complete + done 状态无重开机制 · 复核 key 归属后顺手对派给阿普的修复任务 t_9bea668e 执行了 kanban_complete（那是阿普的活），发现后 CLI 无 done→ready 路径（reopen 不存在/promote/unblock/request-changes 均拒绝） · 乾婆是派单方不是执行方，kanban_complete 只能用于自己的任务；done 状态不可逆（CLI 层面），唯一补救=建新任务替代+旧任务评论标注作废+archive · 🔍已建 t_c54bef8b 替代 · 看板操作
2026-08-31 · [如花] qianpo_log_standardize.py 4 类残留误转（t_c8a0a7ac） · 乾婆日志 20260831 标准化后需人工修正 4 处：①「3/3 哨声素材」被斜杠日期规则误转「三月三号」（3/3 是比率非日期）；②「glm-5.3-flash」残留连字符「glm-五点三 flash」（14.17 只覆盖字母-字母/数字-字母，字母-数字漏网）；③「minimax-m3:free」残留冒号（14.21 转 m3 后冒号前是中文，原 lookbehind 不匹配）；④豆蔻口语化稿带 加粗 和行首 - 列表符号，全管道无人清理（Fish 会朗读为文字） · ① 斜杠日期规则 m==d 时分子=分母是比率语境；② 模型名连字符/冒号是 Fish 会朗读的残留符号，标准化脚本未全覆盖；③ 豆蔻稿 Markdown 格式符号需要预处理层兜底 · ①14.9 m==d 不转日期留 14.22 斜杠规则（3/3→三斜杠三）；②14.17 加字母-数字连字符规则；③14.21.1 冒号后缀规则（lookbehind 含中文字符）；④1.1 Markdown 格式清理（/- 自动删） · 🔍重跑原稿 4 项全部生效（三斜杠三/glm 五点三 flash/minimax m 三 free/无无列表），日期回归正常（九月一号/九月十号等） · t_c8a0a7ac
2026-08-31 · [阿普] watchdog 闭环验证告警属预期行为，非故障（验证 job e29dc8efe27e） · 智囊团收到「Cron 脚本故障（重试验证失败）watchdog_test_fail.py 退出码 1」告警。排查确认：脚本文件头自述「必定失败，验证完即删」=乾婆验证 watchdog 告警链路的故意失败测试脚本；执行历史仅 1 条 failed 记录；job 与脚本在告警产生后均已被删除，链路闭环完整 · ①告警内容=验证脚本预期输出，无需修复；②判定要点：先读脚本真身查自述注释，再查 jobs.json/executions.db 确认 job 生命周期状态，切勿把「验证失败」当「真故障」排障；③临时验证脚本的告警会在删除前污染群聊，属可接受的验证成本 · 🔍本地验证：脚本源码 + jobs.json 全量搜索 + executions.db 执行记录 + 状态文件时间戳交叉印证
2026-08-31 · [阿普] write_file「偶发异常」根因实证：写已归档删除的看板工作区，非工具不稳定（P-0809-01 可行化分析 t_ecb3ef6c） · 广智报 write_file 偶发失败（8/8 电商比价 4 次、8/7 一次），被迫 python 直写绕路。回溯广智 state.db：8 月 145 次 write_file 调用仅 6 次失败（8/8×4 + 8/20×2），全部 [Errno 2] No such file or directory，根因全部=目标路径指向已归档删除的看板工作区（8/8 terminal cwd 指向已删的 t_1e537b55，8/20 路径含已删的 t_3fad8949）。「偶发」实为 100% 确定性环境错误 · ① Hermes write_file 已是完整原子写（file_operations.py _atomic_write：同目录 temp+rename+mkdir -p+权限保留），外部原子写库（atomicreplace/safeatomic）方案方向错位，勿引入；② write_file 报 Errno 2 时先查目标父目录是否存在（尤其 kanban workspaces/{task_id} 是否已归档），不是工具坏了；③ 改进方向=write_file 错误信息提示「目标父目录不存在（是否为已归档工作区？）」 · 🔍本地验证：state.db 报错原文回溯 + workspaces 目录实查（t_1e537b55/t_3fad8949 均不存在）+ 源码 _atomic_write 核查 · t_ecb3ef6c
2026-08-31 · [阿普] send_group_msg.py 艾特去重修复：--at 与内嵌艾特标签叠加致双重艾特（t_7e780635） · 正生反馈群聊艾特连续出现两次（实例 8-30 23:30 智囊团「阿普超限告警处置完毕」简报）。根因：send_msg() 对 --at 名字无条件前置追加艾特标签、不做去重，消息文本开头已手动内嵌 <at user_id="...">正生</at> 时命令又传 --at 正生 → 双重艾特。脚本级缺陷会重复发生 · 修复（~/.hermes/scripts/send_group_msg.py）：新增 content_has_leading_at() 检测 content 开头连续艾特标签块（正则 ^(?:\s*<at user_id="[^"]*">[^<]*</at>\s*)+），按 user_id 和 canonical 显示名双维度比对，命中则跳过前置追加。覆盖单 --at/多 --at/混合场景，别名（陈正生→正生）归一后比对。备份 send_group_msg.py.bak_at_dedup · 调用侧「二选一」纪律（qianpo-feishu-send-pitfalls 技能）是脚本缺陷落地前的临时自防，脚本根治后自动去重兜底，但消息开头内嵌艾特仍是推荐写法（显式控制） · 🔍单元级 8 用例全过（mock requests 调真实 send_msg 捕获 content 计数）+ 端到端双向实测（内嵌+--at → 回查 1 个艾特实体；无内嵌+--at → 1 个实体不回归），测试消息均即发即删 · t_7e780635
2026-08-31 · [阿普] audio_listen_relay.py 音色对比独立模式落地：丢音频根因二分+措辞权衡矩阵+弱表述降级（t_1c3facfe） · 上轮 run 2242 遗留：voice_compare 代码已写完（14/14 单测）但金标准双向验证遇服务端全线丢音频（12/12「请提供音频」）未完成；且「角色开头保送达」结论与探针实测矛盾（探针词带角色开头 0/2 丢，v16 词带角色开头 2/2 丢） · ①丢音频根因=提示词触发句，与音频文件/角色开头无关：二分定位（每组 3 次）触发句是「特别注意第X句和第Y句的对比：音高、语速、音质、自然度、情感投入」句式（3/3 稳定丢），改写为「请描述第X句的声音特征，并与第Y句对比」0/3 全送达；仅角色开头 12 字也 3/3 丢，推翻「角色开头保送达」早前结论；②代码侧丢音频自动重试：call_engine_with_retry 包装层（回复前 60 字含「请提供音频/未检测到音频/没有音频/无法识别音频」即重试 2 次递增退避），怪声检测与音色对比两条主链路接入，glm-asr 直通；③措辞权衡矩阵（四版金标准实测）：强引导（点名机械感/TTS）正向检出 5/6 但正常素材锚定误报 3/3；开放式（不点名异常词）0 误报但极端机械检出归零（模型对 tremolo 无感）；折中最优=中性引导「有没有任何不自然、发紧、发飘或像机器生成的痕迹」正向 4/6+误报 1/3；④解析层弱表述降级：VOICE_WEAK_HEDGE 识别弱程度词（略显/稍微/有点/轻微）修饰的问题关键词→不触发脱节修正，verdict=inconsistent 时降 suspect 交人工（negative10 被「略显机械和平淡，但整体上没有明显的机器人特征」+verdict=inconsistent 误杀 rework 的根因） · ①检出力与误报率同源，都来自引导性提问——提示词只能调平衡点，双向稳定需解析层+人工复核兜底，与 t_6f7d6df3「omni 幻觉与提示词无关」结论互为印证；②「分析-结论脱节」在音色模式的新形态：模型被提示词一致性约束（「结论必须与第1项一致」）逼着把弱表述分析定成 inconsistent verdict，解析层必须识别弱程度词豁免；③金标准回归（CLI 端到端）：极端机械 3/3 rework（exit=2）、弱机械 3/3 rework、正常 3/3 suspect 不误杀（exit=1 交人工），零丢音频；④怪声主链路回归不回退：noise_strong→rework（频谱证实）、normal10s→suspect（频谱证伪降级，设计内行为），与 t_6f7d6df3 验收结论一致；⑤措辞纪律已同步 cloud-audio-audit-prompting 技能 v1.1.0（铁律 2 修正） · 🔍金标准全矩阵 CLI 回归 9/9 方向正确 + 重试逻辑单测 7/7 正则+3 场景 mock + parse_voice_verdict 弱表述 4/4 + 怪声主链路回归 2/2；素材 /tmp/audio_listen_testA/synthetic/（tremolo 6-14Hz 调制能量 0.25→0.40 量化分级） · t_1c3facfe、t_6f7d6df3