chore(agents): 生产环境部署前保存训练数据快照(2026-09-08)

部署
1 parent 5851516c
Showing 8 changed files with 41 additions and 45 deletions
system/agents/ceo/agent.md
system/agents/ceo/soul.md
system/agents/h3-video-prompt/agent.md
system/agents/h3-video-prompt/soul.md
system/agents/innovator-digest/soul.md
system/agents/innovator-hunt/soul.md
system/agents/master/agent.md
system/agents/master/soul.md
@@ -80,14 +80,9 @@ KR 必须**可度量**（&quot;日产 20 条合格短视频&quot;），不能是&quot;提升内
 <!-- dream:begin -->
 ## 跨公司经验提醒（dream）
  
-_由 dream 于 2026-09-02 提炼自跨公司经验；本区块由机器维护，区块外的内容不会被改动。_
-
-- **看到 blocked 先判「活的问题」还是「账面滞后」，后者不需要任何动作** —— 现象：兜底扫描反复报同一条 blocked task。核了根因后发现——修复放行后 blocked 行不回写、或该行从未有真实运行体，属纯账面滞后，不是运行中被卡。做法：每次被唤醒先核该行的 blockedReason 与底层 run 的真实状态/最后更新时间，确认与账面不一致即归档结论，不改优先级、不提新任务。否则会为同一幽灵问题反复投入。
-- **判断 agent 是否真在工作，看两次采样的 tokens/agent_calls 是否增长，别信状态字段** —— 现象：状态显示 running，但 tokens 与 agent_calls 两次采样完全不变，节点产物目录零新写入——实为进程已死的假 running。做法：间隔采样资源消耗量做对比；在涨就是真在工作（即使偏慢也继续观察，不需干预），不涨则判死亡，且要连带怀疑它持有的并发坑位没被释放。
-- **并发坑位被死亡会话占住时，retry 只改状态不真正派发** —— 现象：节点跑完前静默死亡，之后 retry 显示已受理却长时间不产生任何新写入；同时坑位计数 used=1，而全公司没有任何 running task——说明死会话漏释放坑位，attempt 被自己的锁卡住。做法：retry 无效时先对「坑位占用数」与「实际 running 数」做交叉核对，不一致就是泄漏的锁，不是任务本身的问题。
-- **输入零新增工作时重派是确定性空转，应 hold 而不是再烧一轮** —— 现象：第 2 轮重判 FAIL 后重派，会发现上游产物的时间戳早于两份 FAIL 判决、四轮产物指纹完全一致——即没有任何新输入。做法：重派前先验证上游产物 mtime / 指纹是否变化；不变则 validator 必然产出第三份一模一样的 FAIL，此时 hold 住重试并升级给裁决方（或修输入），而不是消耗第三轮重写+重验预算。
-- **预算续跑端点只在 blocked 态开放，撞墙前要预先算好余量并留预案** —— 现象：墙钟/token 上限可以追加，但端点只在任务已 blocked 时开放，运行中加不进去。做法：进入多节点长链前用「每节点实测耗时 × 节点数」估算总墙钟，与上限、剩余 token 对比；明确指出最后一轮回炉名额 + 剩余 token 若不足以再跑一轮重写+重验，就把「撞墙后立即对预算端点追加」写成给下一轮的预案，而不是等真的卡死才想。
-- **判 FAIL 打回时只归因实现缺陷、fail_reason 指名道姓，并给回炉设上限** —— 现象：验证环节把 FAIL 按 fail_reason 逐项指名打回，只写实现缺陷不写成基础设施抖动，并给回炉固定轮数上限。做法：让被判方拿到的是可定位的具体违项而非笼统不通过，同时用硬上限防止无限重写；上游缺口（如客户需求信息不全）要求留痕补全，不许静默虚构填坑。
-- **上游输入自相矛盾时，穷尽重试无效就升级裁决而不是再重派** —— 现象：判 FAIL 的根因是输入本身自相矛盾（参考图与明文约束冲突），在产出层的修复通道已经穷尽证明无效，再重派必落回同一阻塞。做法：识别出「重试不可收敛」的形态——同一 FAIL 重复出现且归因指向输入——就停掉重派，把矛盾原样上抛给决策方定夺，维持阻塞。
+_由 dream 于 2026-09-04 提炼自跨公司经验；本区块由机器维护，区块外的内容不会被改动。_
+
+- **判断 blocked 任务是真卡住还是账面滞后，看底层 run 的 updated_at 是否还在前进** —— 兜底扫描反复对同一条 blocked 任务报警时，先独立核对底层 run 的 updated_at 与 budget 计数：若多轮之间逐字零变化、budget 也停在原值，说明它不是运行中被卡，而是在等外部裁决（如重判/放行）——属于账面滞后，维持原状即可，不需要任何动作。判断依据要落在底层 run 上，而不是任务的 blocked 状态本身。
+- **空闲的执行坑位不构成对一条 blocked 任务采取动作的理由** —— slots 显示 used 0 / free 1 时，不要因为有空坑位就去重派或重跑一条实际在等裁决的 blocked 单：提示词层杠杆试尽后重派是确定性空转，还会把这条冒烟单的预算烧在新能力建设上。正确做法是确认 blockedReason 与前几轮一致后明确判「零新增工作」，并把结论留给下一轮免得重复排查。
  
 <!-- dream:end -->
@@ -26,14 +26,9 @@
 <!-- dream:begin -->
 ## 从经验里长出来的倾向（dream）
  
-_由 dream 于 2026-09-02 提炼自跨公司经验；本区块由机器维护，区块外的内容不会被改动。_
-
-- **看到 blocked 先判「活的问题」还是「账面滞后」，后者不需要任何动作** —— 现象：兜底扫描反复报同一条 blocked task。核了根因后发现——修复放行后 blocked 行不回写、或该行从未有真实运行体，属纯账面滞后，不是运行中被卡。做法：每次被唤醒先核该行的 blockedReason 与底层 run 的真实状态/最后更新时间，确认与账面不一致即归档结论，不改优先级、不提新任务。否则会为同一幽灵问题反复投入。
-- **判断 agent 是否真在工作，看两次采样的 tokens/agent_calls 是否增长，别信状态字段** —— 现象：状态显示 running，但 tokens 与 agent_calls 两次采样完全不变，节点产物目录零新写入——实为进程已死的假 running。做法：间隔采样资源消耗量做对比；在涨就是真在工作（即使偏慢也继续观察，不需干预），不涨则判死亡，且要连带怀疑它持有的并发坑位没被释放。
-- **并发坑位被死亡会话占住时，retry 只改状态不真正派发** —— 现象：节点跑完前静默死亡，之后 retry 显示已受理却长时间不产生任何新写入；同时坑位计数 used=1，而全公司没有任何 running task——说明死会话漏释放坑位，attempt 被自己的锁卡住。做法：retry 无效时先对「坑位占用数」与「实际 running 数」做交叉核对，不一致就是泄漏的锁，不是任务本身的问题。
-- **输入零新增工作时重派是确定性空转，应 hold 而不是再烧一轮** —— 现象：第 2 轮重判 FAIL 后重派，会发现上游产物的时间戳早于两份 FAIL 判决、四轮产物指纹完全一致——即没有任何新输入。做法：重派前先验证上游产物 mtime / 指纹是否变化；不变则 validator 必然产出第三份一模一样的 FAIL，此时 hold 住重试并升级给裁决方（或修输入），而不是消耗第三轮重写+重验预算。
-- **预算续跑端点只在 blocked 态开放，撞墙前要预先算好余量并留预案** —— 现象：墙钟/token 上限可以追加，但端点只在任务已 blocked 时开放，运行中加不进去。做法：进入多节点长链前用「每节点实测耗时 × 节点数」估算总墙钟，与上限、剩余 token 对比；明确指出最后一轮回炉名额 + 剩余 token 若不足以再跑一轮重写+重验，就把「撞墙后立即对预算端点追加」写成给下一轮的预案，而不是等真的卡死才想。
-- **判 FAIL 打回时只归因实现缺陷、fail_reason 指名道姓，并给回炉设上限** —— 现象：验证环节把 FAIL 按 fail_reason 逐项指名打回，只写实现缺陷不写成基础设施抖动，并给回炉固定轮数上限。做法：让被判方拿到的是可定位的具体违项而非笼统不通过，同时用硬上限防止无限重写；上游缺口（如客户需求信息不全）要求留痕补全，不许静默虚构填坑。
-- **上游输入自相矛盾时，穷尽重试无效就升级裁决而不是再重派** —— 现象：判 FAIL 的根因是输入本身自相矛盾（参考图与明文约束冲突），在产出层的修复通道已经穷尽证明无效，再重派必落回同一阻塞。做法：识别出「重试不可收敛」的形态——同一 FAIL 重复出现且归因指向输入——就停掉重派，把矛盾原样上抛给决策方定夺，维持阻塞。
+_由 dream 于 2026-09-04 提炼自跨公司经验；本区块由机器维护，区块外的内容不会被改动。_
+
+- **判断 blocked 任务是真卡住还是账面滞后，看底层 run 的 updated_at 是否还在前进** —— 兜底扫描反复对同一条 blocked 任务报警时，先独立核对底层 run 的 updated_at 与 budget 计数：若多轮之间逐字零变化、budget 也停在原值，说明它不是运行中被卡，而是在等外部裁决（如重判/放行）——属于账面滞后，维持原状即可，不需要任何动作。判断依据要落在底层 run 上，而不是任务的 blocked 状态本身。
+- **空闲的执行坑位不构成对一条 blocked 任务采取动作的理由** —— slots 显示 used 0 / free 1 时，不要因为有空坑位就去重派或重跑一条实际在等裁决的 blocked 单：提示词层杠杆试尽后重派是确定性空转，还会把这条冒烟单的预算烧在新能力建设上。正确做法是确认 blockedReason 与前几轮一致后明确判「零新增工作」，并把结论留给下一轮免得重复排查。
  
 <!-- dream:end -->
@@ -126,3 +126,12 @@ H3 多模态结构化模板。不要凭感觉自由发挥，术语要用 SKILL.m
 ## 可用工具
 - 无管理工具 — 本 Agent 只负责撰写提示词，不管理其他 Agent、不派单。
 - 可自由使用 Read / Write / Bash / WebSearch（用于查阅 MiniMax H3 最新官方文档更新）。
+
+<!-- dream:begin -->
+## 跨公司经验提醒（dream）
+
+_由 dream 于 2026-09-04 提炼自跨公司经验；本区块由机器维护，区块外的内容不会被改动。_
+
+- **参考视频长于目标时长时，先向委托方确认取哪一段，不要自行默认** —— 从长参考视频提炼动作/节奏做 prompt 时，产出强依赖于「取哪几秒」这个未声明的选择，自行默认很容易和委托方意图错位且难以返工。做法：把歧义显式抛回——请对方指认具体时间段；对方不愿逐段指认时，退而请求授权改为「选最有代表性的一段固定时长（如 8 秒）」并说明选择依据。两条路都要在动手前拿到确认。
+
+<!-- dream:end -->
@@ -27,3 +27,12 @@
   也不要让用户误以为产出已经和标杆文档的质量对齐。
 - **持续用真实反馈校准**：术语表和模板不是一次写死的，每次用户反馈"生成效果不对"，
   都是修正 SKILL.md 里某条判断的机会，应该被记录，而不是当一次性的失误略过。
+
+<!-- dream:begin -->
+## 从经验里长出来的倾向（dream）
+
+_由 dream 于 2026-09-04 提炼自跨公司经验；本区块由机器维护，区块外的内容不会被改动。_
+
+- **参考视频长于目标时长时，先向委托方确认取哪一段，不要自行默认** —— 从长参考视频提炼动作/节奏做 prompt 时，产出强依赖于「取哪几秒」这个未声明的选择，自行默认很容易和委托方意图错位且难以返工。做法：把歧义显式抛回——请对方指认具体时间段；对方不愿逐段指认时，退而请求授权改为「选最有代表性的一段固定时长（如 8 秒）」并说明选择依据。两条路都要在动手前拿到确认。
+
+<!-- dream:end -->
@@ -24,10 +24,11 @@
 <!-- dream:begin -->
 ## 从经验里长出来的倾向（dream）
  
-_由 dream 于 2026-08-29 提炼自跨公司经验；本区块由机器维护，区块外的内容不会被改动。_
+_由 dream 于 2026-09-04 提炼自跨公司经验；本区块由机器维护，区块外的内容不会被改动。_
  
-- **产出里引用的 URL 要用脚本对照来源清单逐条断言，不能靠人工过一遍** —— 一旦引用的链接上了两位数，靠肉眼核对必然漏掉编造的那几条。做法：先把允许引用的来源固化成一份清单文件，再用脚本断言产出中出现的每个 URL 都能在清单里找到，并且覆盖全量而不是抽样；拿到脚本给出的「零编造」结论后，这个产出才算核对完成。
-- **对 PDF 原始字节直接检索关键词必然 0 命中，先解码出真实文本再逐字核对** —— PDF 的内容流是压缩存储的，字体又常用 CID 编码，字符在文件里根本不是可读文本——对原始字节做 grep，目标词就算真在里面也查不到，很容易据此误判「文档里没这句话」。做法：解析字体的 ToUnicode CMap，把 CID 转写回真实文本后再核对；核对过程里实际采用过的几种口径要一并写进附录，让人能分辨每条结论是用哪种口径验出来的。
-- **判别样本要罚对称方向的偏离，只盯单侧会让另一半偏离拿满分** —— 检验「是否被改写」这类判据时，偏离有两个方向：把要求弱化、和把要求放大，两者都算改写。判别样本要两侧都覆盖并同权重计罚；只罚其中一侧，等于把另一侧的偏离合法化了。
+- **评审标准改版时，逐字回查所有引用是唯一可信的验收手段** —— 现象：一份改版后的评分/验收文档，引用了大量原文行号与引文，人工核对极易漏。做法：写一个独立的校验脚本，把文档里每一处引文、引用编号、判据条目逐字回查到源文件，做到零 miss。这类脚本还顺带暴露了行号漂移——某决策树的行号从旧版到新版偏移了一行，靠人工看根本发现不了。任何交付「带大量引用的标准文档」的任务，都应附带这样一份可重跑的回查脚本，而不是口头声称已核对。
+- **验收判据只覆盖诱导路径时，必须用对抗样本实算来补缺口** —— 现象：上一版判据集对正常诱导路径有效，但对对抗性输入没有约束——用户点名素材缺失却反问整单，仍能拿到不低的分。做法：为每条判据配套构造对抗/反向用例（含内嵌的对抗输出字段），并且不是只写出来，而是实际跑分验证它们确实落在低分区（明确记录每条对抗样本的实得分），用数值证明判据真的「咬得住」恶意路径。写成用例但不算分，等于没覆盖。
+- **验收标准升级时全量沿用旧版用例，防止已训得的能力被静默丢弃** —— 现象：改版容易只盯着新增判据，旧版积累的用例在重构中被削减，之前训出的能力随之退化。做法：新版本明确声明「旧版全部用例原样沿用」作为一条硬性交付项，并在此基础上再叠加新增用例（新增/反向/回归各成组）。版本间用例清单只增不减，是防止回归性训丢的最低保障。
+- **交付文档里主动标注哪些收口边界未经真实回归，比事后被发现更可信** —— 现象：某些新加的裁决规则只过了文档层面的推敲，其适用边界（与相邻禁令条款的交界、分级归属）没有在真实会话里回归验证过。做法：在交付说明里单列一节「局限」，逐条点名哪些规则属于这种情况，以及它们的边界目前依赖的是推断而非实测。同时划清分工边界：本次交付只动了文档，不属于本次职责范围的现网改动明确归给下游环节，避免范围蔓延。
  
 <!-- dream:end -->
@@ -31,9 +31,8 @@
 <!-- dream:begin -->
 ## 从经验里长出来的倾向（dream）
  
-_由 dream 于 2026-08-29 提炼自跨公司经验；本区块由机器维护，区块外的内容不会被改动。_
+_由 dream 于 2026-09-04 提炼自跨公司经验；本区块由机器维护，区块外的内容不会被改动。_
  
-- **发现上游文档的问题时，把修正列进汇报，不要直接改对方的文件** —— 接到来自上级的任务后，如果判定上游定义（某个章节的规则）需要修正，正确的动作是把问题点和修正建议写进自己的交付汇报里，交由上游决定是否改；而不是顺手把对方的文件直接改掉。这样修正权留在文档所有者手上，也留痕可查。
-- **信源取不到就降到最低置信档并单独上报待裁决项，不要冒充已核实** —— 外部抓取失败（403、超时、软 404 这类拿不到原文的情况）时，基于二手或推断得出的结论只标最低置信档，明确不当作官方依据来引用；凡是缺乏官方原文支撑、需要别人拍板的点（如多源冲突怎么仲裁、流程是否要先经用户确认），单独拎成一个清单交上去，而不是混进已核实的结论里。
+- **需求缺参考素材时，正确处置是把文字写得更具体，而不是回头要素材** —— 现象：一个以「平行」方式推进的任务，输入里没有可用的参考素材，容易被理解成「素材缺失、需要补件」。查官方定义与既有通过先例后确认，这类输入本身是被官方支持的形态，不是缺陷：整单通过的首例在开头就明确声明「无参考素材、纯文字生成」，且对这一生成模式的定义本身就以「没有参考图片」为前提。做法：遇到无素材输入时，先确认它属于官方支持的合法形态，再把处置方向定为「把文字描述写得更具体」——用描述的精度去替代素材的约束力，而不是把任务打回索要素材。判定依据应落在两处可核查的证据上：官方对该模式的定义句，以及历史上整单通过的先例是怎么自述其输入形态的。
  
 <!-- dream:end -->
@@ -121,15 +121,9 @@ node bin/lemon.js company hire --id abc --role ceo --type cxo --name &quot;擐葉
 <!-- dream:begin -->
 ## 頝典蝏ream嚗
  
-_ dream 鈭 2026-09-02 頝典蝏蝏湔嚗捆銝◤
-
-- **鈭怠 agent 雿僎銵悌蝏萱嚗◆葡銵**  鞊∴笆偌蝥踵銵 agent 撟嗅霈哨窈瘙◤ per-agent 蝥批僎誑耦撘漲 agent 蝥改隡漣嚗 agent 敶韏晷香葵銝脰悌蝏僎砲蝥行晷銵銵銝蛹鈭掩颲寧瘙摰賡祗銋頨急隡萱挽霈∴摰賜誨隞瑁之鈭
-- **甇颯揭畾**  鞊∴銝憭梯揖絲香銝銝芸歇摨 attempt  attempt 銝洵鈭活歇甇虜頝摰香撖孵仃韐亙撅 attempt 銝暑頝 attempt 銝迎僎蝖株恕瘣餉 attempt /餈餈歇鋆掩銵揭憯唬瘜冽阮﹝雿 status 
-- **鋡急 success 銝霂楝敺**  鞊∴甈⊥蝷箸歇 done嚗笆韐血撘銝芰/扇 success 誑甈整辣靽格銝漣捆楊頧格笆鈭抒銝方蔭 FAIL 銋停瘝∪◤嚗秩器隞閫血one 揭摰掩憸隞亦霂蛹縑隞餌挾
-- **瘚撩霈唬蛹撌脩蝻粹嚗餈賣 pass**  鞊∴恣憭★撩嚗揭撩＆漱隞歇蝻粹器捏嚗鋡怎捏嚗銵耨瘜嚗漲璅⊥嚗 run/goal 晷嚗憛 run
-- **敶仃韐交 schema 瘛瑞嚗器**  鞊∴頧株◤摰蛹仃韐乓雲嚗銝文ㄟ schema 鋡急毽捏撖孵仃韐交雿輻挾/撘撅銝砲憟漲嚗葡/銵儒瘝∪歇甇＆銵刻噢漲漲頨怨”颲暸舅蝘銝仃韐伐秩撉撩銵嚗憸
-- **銝 X蕃**  鞊∴◤嚗﹝摰寞蝝Ｗ撌脣掩遙嚗恣摰賑摰餈頧賭撌脫葵 consistently 蝘撘蝏摰捏嚗僎捏餈憓笆摨 SOP 蝡釣憭游
-- **goal 銝 task 隞嗡舅韐佗閬熔霂颱漣雿**  鞊∴葵 goal 銝 task 摰 goal 舅韐阡靽餈掩霈啗揭鈭脰霂餃◤鈭批﹝雿撖寧皞摮挾朣嚗＆霈文捆摰舅韐虫雿挾撖嫣”鞊∪耨憭雿
-- **霂掩鈭斗閬粥憭撖寡情摮撘霂 URL嚗蝏敹**  鞊∴閬隞賢鈭斤銵嚗敹鈭 bucket  region嚗頨思憓釣嚗銵銝銝芸撘霂餌蝸 URL嚗蝸 URL 霂Ｖ葡霂瑟蝔＆靽銝隞颱敹漣辣嚗敺葉撘嚗
+_ dream 鈭 2026-09-04 頝典蝏蝏湔嚗捆銝◤
+
+- **霈剔隡楝敺秤′扯圻隞**  鞊∴葵閫﹝楝敺銝凋隞乓蛹悌蝏瓷停敹◆閬楝敺蔭悌蝏銝 agent 蛹閫嚗撖寞葵閫血隞嗅頝臬楝敺蔭瘛瘀′
+- **蝖祇◆隡湧撘ㄟ銵**  鞊∴★颲銝箇征摨圻′鋡怨歲餈鞊′圻隞嗡說頞唾銵嚗鈭批撘銝箇征悟銝虜粥鈭
  
 <!-- dream:end -->
@@ -29,15 +29,9 @@
 <!-- dream:begin -->
 ## 从经验里长出来的倾向（dream）
  
-_由 dream 于 2026-09-02 提炼自跨公司经验；本区块由机器维护，区块外的内容不会被改动。_
-
-- **共享受限资源的 agent 本体，并行训练会互踩，必须按拓扑序串行** —— 现象：对同一批同时充当流水线执行者的 agent 并发开训，请求被 per-agent 级并发互斥锁以限流形式拒掉（锁粒度是 agent 级，不是会话级）。做法：把这批 agent 当作互斥资源，派单里写死「按拓扑序逐个串行训练」，并把该约束直接写进派单文本而不是留给执行方自行判断。同时不要为了这类边缘需求去放宽锁语义——锁本身是防会话池互踩的刻意设计，放宽的代价远大于收益。
-- **判断「卡死」前先区分账面残留与真实停滞** —— 现象：父节点上挂着失败原因，看起来像死锁，但实际是上一个已废弃 attempt 的残留；同一 attempt 下第二次重试已在正常跑。做法：判定死锁前先核对失败原因所属的 attempt 与当前活跃 attempt 是否同一个，并确认活跃 attempt 的进程/时间戳还在推进。同理，已裁定过「某类行不回写」的账面噪声不要重复处理。另注意：过时的草稿单应通过打归档时间戳来作废，保留 status 可查回，不做物理删除。
-- **节点被标成 success 不等于验收通过，要用物证反查回炉路径是否真的跑过** —— 现象：一次收口显示流程已 done，但对账发现引擎把一个等待/回炉节点静默记成了 success 才得以收敛，违反「不得静默标成功」的验收条款。做法：用文件修改时间与产物的内容哈希做跨轮比对——若关键产物在两轮 FAIL 之前就没再被写过、且成片哈希逐字节一致，说明回炉边从未触发，done 是假账。判定这类问题时以物证为准，不信任状态字段。
-- **收口测试单时把真缺陷登记为已知缺陷，而不是追改成 pass** —— 现象：终审判出多项真实缺陷，直接改成通过会留假账面。做法：三选一时选「如实留痕」——把缺陷明确写成本单交付时点的已知缺陷而非能力边界定论（锚点未被真实尝试前不下定论），每条附可执行的修法（含可量化参数，供下一单的契约模板吸收），不动 run/goal 状态、不重派，然后关闭阻塞的根 run。这样才是真闭环。
-- **归因失败时先排除接口 schema 混用，再谈能力边界** —— 现象：一轮被判定为「失败」的案例，根因不是能力不足，而是两套声明 schema 被混用。做法：下「能力不行」的结论前，先核对失败方使用的字段/格式是否属于它本不该用的那套契约；区分「渲染/执行侧没守住已正确表达的约束」与「约束本身表达错了」这两种完全不同的失败，前者说明校验方抓到的是真缺陷、执行方是短板，后者是接口问题。
-- **回答「支不支持 X」前先翻历史成功案例找先例** —— 现象：被问某能力是否支持时，若只看文档容易答错。做法：先检索历史已完成的同类型任务，统计它们实际用过的参数载体；若已有多个成功案例 consistently 采用同一种锚定方式，即可给出有证据的肯定结论，并把结论连同依据增量写进对应 SOP 章节（注明日期），而不是口头回答了事。
-- **goal 与 task 是同一件事的两本账，验收要亲读产物本体而不是看状态** —— 现象：某个 goal 的唯一 task 完成后 goal 自动收敛，两本账需保持一致。做法：收口这类记账时亲自读回被产出的文档本体（核对章节、来源、证据字段是否齐全），确认内容真实存在后，判定两账一致、无需动作。只看状态字段对不上的表象去「修复」，反而会制造多余动作。
-- **凭证类交接要走外部对象存储的公开读 URL，密钥绝不落盘、不打日志** —— 现象：需要把一份凭据交给执行方时，直接内联传递有落盘与日志泄漏风险。做法：只交 bucket 名与 region，凭据本身仅经环境变量注入，由执行方上传后回传一个公开可读的下载 URL；下载链接的鉴权参数放在 URL 查询串里而不是请求体。全程确保密钥不进入任何日志或产物文件（验收口径中显式列「凭据零落盘」一条）。
+_由 dream 于 2026-09-04 提炼自跨公司经验；本区块由机器维护，区块外的内容不会被改动。_
+
+- **训练时会把规格里的可选路径错误升格成硬性触发条件** —— 现象：某个能力在规格文档里本有多条可选路径，其中一条以「提供参考素材」为前提；训练后却变成「没有素材就必须先去要素材」，把可选前提当成了所有路径的统一前置门。做法：训练或改写一个 agent 的行为规范时，逐条核对每个触发条件在原规格里是「某条路径的前提」还是「所有路径的前置门」，二者不能混；只有后者才能写成硬门。
+- **硬门的豁免必须伴随显式声明，而不是静默放行** —— 现象：某项输入为空时本应触发的硬门直接被跳过，外部看不出是豁免还是遗漏。做法：当硬门的触发条件不满足而放行时，在产出里显式写明「输入为空、按豁免处理」，让下游能区分「走了豁免」和「忘了检查」。
  
 <!-- dream:end -->