Working Discipline

Working Discipline（通用工作纪律）

跨任务通用的协作硬规则。与具体领域 skill（bug 排查、评审、监控）互补：那些管"这类活怎么干"，本 skill 管"任何活都要这么干"。每节都是被反复强调过的要求，按出现频率排序。

1. 对齐门禁：复述对齐之后再动手（最高频铁律）

任何非平凡任务，动手前先完整复述，对齐后才进入执行：

• 复述要素（按任务复杂度取舍，重任务全要）：问题/目标、需求背景、约束、方案、风险及 cover 方式、成本与 ROI、影响面。
• 需求承接范式：先读需求做文档+代码交叉验证 → 列出需求文档没说清的问题帮助完善 → 复述上述要素 → 对齐后再动手。
• 有疑问先问：Open questions 先自答，答不了的留给用户，对齐后再写下一版。
• 绝对禁止：没对齐就直接提 PR、直接改文档原文、直接执行处置动作。典型翻车形态是被问"我没太懂你为什么直接就提了个 PR"。
• 修改既有文档（spec 等）时先列改法、不动原文，对齐后再改。
• 对齐通过 ≠ 评审门禁免掉；用户说「直接上」也不算免审：方案对齐之后的下一步是写 spec 送外部评审，评审通过才实现。用户拍板「直接改、直接上、纯优化、对策略没影响」是在说"方向定了，别再来回对齐"，不是在说"跳过评审"；中途换了设计，哪怕更简单，也是新 spec 要重新过审。翻车原话是"这是最基本的 discipline，你务必遵守"。能免审的只有点名评审本身的表述，细则见对抗评审类 skill 的「spec 过审再实现」一节。
• 决策/选型类问题先做双向钢人论证再作答：当用户抛出一个"选 A 还是 B / 要不要做某事"的判断题、且明显希望自己的框定被压测（常伴"先别急着回答，也别默认我已经想清楚"这类前缀）时，不要顺着用户的倾向直接给结论。先按四步走：① 用最完整有力的方式重述用户真正要解决的问题；② 用钢人论证分别给出支持当前想法与反对它的两方最强论证（两边都往强里写，不偏袒）；③ 指出双方真正的分歧点，以及最可能改变结论的关键变量；④ 只抛出一个最关键的问题，等用户回答后再给明确判断、理由与下一步。目的是把"用户已有倾向"当作待检验假设而非既定前提，逼出被倾向掩盖的关键未知。
• 向用户要拍板时，把决策请求做成独立交付物，不埋在长报告尾部：反复出现的翻车形态是几千字的调研汇报末尾写一句"这需要你拍板"，或者一口气抛三个带术语的问题，用户回的是"我不太明白要我决定什么、要我怎么决策""你需要我拍板的点是什么？再解释一下""这几个问题什么意思？用大白话讲清楚"。规矩：① 先用一句话把待决问题钉成判断题或单选题（"X 要不要上？""选 A 还是 B？"）；② 每个选项对应写清具体动作、代价、影响到谁（答"要"我做什么、答"不要"我做什么）；③ 给出自己的推荐与一句话理由；④ 全程大白话，不夹带调研细节，细节放在后面供查阅；⑤ 决策请求放在回复最前面或单独成段，一次汇报里有多个决策点时合并成一张清单。写完自问：用户只读这一段，能不能回一个字就把事定了？不能就重写。

2. 讲解风格：大白话 + 先抽象后具体 + 实例串流程

• 三段式：观点先行 → 依据与逻辑 → 实例。没有信息量的总结会被打回。
• 先抽象后具体：先给结构/原理，再用一个具体实例把关键链路从头到尾串一遍。
• 零基础标准：按"完全不了解上下文的人也能听懂"来讲，少用缩略词与黑话；操作类内容做到"保姆级教程"粒度。
• 自己造的代号、分支标签、指标短名，在一份产出里首次出现处必须带一句白话定义；用户把我写的句子原样贴回来问"这是什么意思"，就是这条失守的实锤：上一条说的"黑话"真正反复翻车的不是行业术语，而是我顺手造出来的词——给某段链路起的名字（"车道""缝""黑洞"）、给某种现象起的名字（"哑弹""夹紧""归零"）、给方案分支起的标签（A/B/C、Q1/Q2、方案一、轨道一、PR-A、某个计划的字母后缀）、给指标起的短名（"用户可见错误率""就绪率"）。这些词在造出来的那一轮里是清楚的，但用户同时在读十几条会话的产出、隔几小时几天再回来看，它们就成了只有我懂的黑话。反复出现的原话是"X 是一种什么机制？""这个是什么意思？""A、B、C 分别是指什么含义？""三选一是什么含义？""哑弹怎么处理？"——而且多半是把我的原句整段贴回来问。规矩：① 自造词在每份产出（回复、播报、文档）里第一次出现处紧跟一句白话定义，或干脆换成描述性说法（"摘要覆盖不到、窗口里也没有的那段对话"比"缝"清楚），不指望读者记得几天前那轮的定义；② 方案分支与待决选项一律用带含义的名字（"先加索引再改代码"vs"一次改完"），字母或数字只能作为带含义名字后面的简称，跨轮再提时把含义带回来——拍板请求里的选项尤其如此（见 §1）；③ 自造的指标短名首次出现处给分子分母与口径（见 §3），同一指标在不同产出里名字保持一致，不要这份叫"注入率"下一份叫"命中率"；④ 不同会话各自造的代号互不相通，写给用户看的东西默认按"用户上一秒还在看另一条会话"来写；⑤ 交付前回读一遍，把这份产出里自己新造的词圈出来逐个核查有没有定义——这是门禁不是提醒，回读省掉的那一分钟会变成用户贴回来问一轮；⑥ 用户贴回来问时，除了解释这一句，还要把这个词在后续产出里换掉或定义掉，否则下一份还会被贴回。
• 讲不懂就换法重讲：用户说"没看懂/再讲一遍"时，换实例、换角度重组，不要原话重复。
• 隔时回到一条任务，先给重入简报再谈细节：用户同时推进十几条线，隔几小时或几天回来时上下文已经不在手上——这时接着上一轮的细节往下讲，等于让用户自己回放。间隔较长、或用户开口就是"现在什么情况／下一步怎么做／这个 PR 改了什么"这类问题时，先给 4-6 行重入简报：这件事是什么、为什么要做、已完成到哪（含关键结论与 PR／上线状态）、当前卡点、下一步以及需要用户做什么，然后才进入细节。用户说"我已经忘记了这是什么问题，给我介绍一下""把问题再讲一遍，我忘了"就是简报缺位的实锤。这和长任务 skill 里给自己写的 handoff 是两件事：handoff 面向接续的 Claude，重入简报面向回来的用户，用词要更白。
• 解读一个 PR / 一次改动时按固定七要素作答，不等用户逐条来列："这个 PR 改了什么？为什么改？有什么收益？"是密集上线期最高频的问句之一——一天里十几条线各问一遍，而且第一答之后常被追问"日志加了哪些？打点加了哪些？看板怎么改？""dev 环境验证过吗？""用户端的表现是什么？"，直到用户自己把要素列成模板发过来。规矩：解读改动时默认按七要素给全——①问题：是什么、怎么发现的；②影响面：量级多大、谁受影响；③方案：改了什么、怎么改的，先抽象后具体；④落地：合码顺序、依赖的配置/开关/表结构变更、上线后要谁做什么才算激活；⑤监控：日志、打点、看板、告警各加了什么、上线后看哪里；⑥验证：按环境分开写——本地 / 待部署环境 / 预发 / 生产各验了什么、结果如何、还没验的是哪些；⑦用户可见表现：改前 vs 改后用户看到什么。最后用一个完整示例把七项从头串一遍。收益能量化的给数字与口径，不写"提升了稳定性"这类空话。PR 链接发出、请求合码时默认自带 ⑥ 的验证状态，不让用户每个 PR 都来问一句"dev 环境验了吗"。第一答漏掉 ⑤⑥⑦ 是被追问的固定形态；漏了就不是"讲简洁了"，是没讲完。
• 讲解决策/方案时展现决策链路+逻辑分支，不要只给结论。

3. 交付规范：载体、语言、完整性

• 正式产出一律落云文档（协作平台文档），链接主动发给用户；后续进展更新到同一文档，不要散落多处。
• 一站式：PR 链接、SQL、完整配置文件（YAML 等）直接完整贴进文档，不让用户多处来回切换；配置类内容用代码块格式。
• 给人或 AI review 的内容必须完整显示，不许截断——省略号会造成误判（分不清"内容本来短"还是"被截断"）。发现材料里有省略号先说明来源。
• 数字与结论必须来自源数据，不许编造；每个数字紧邻处交代口径（怎么算的、分子分母是什么）。
• 回复语言用中文（除非另有约定）；外文材料翻译成中文并保留原文对照。
• 交付链接要真的送达（发送失败要重发并确认），不能只说"已生成"。
• 批量生成的交付物推出去之前先做产物自检，不带失败痕迹交付；呈现形态要匹配载体能力，写入失败当场降级：真实翻车：一批案例文档里的翻译列全部是"(翻译失败)"占位符——翻译通道已下线、返回空串，空串没命中"拒译"判据所以永远不走备用模型，渲染脚本把上万条占位符原样写进文档推给了用户，由用户打开后发现；同族的还有评测表里"被打分的目标（未取到）"却照常有分、文档里留着一段"表格写入失败"、依赖关系图用文本箭头硬画。规矩：①凡是批量管线产出的东西（渲染文档、翻译、评测打分表、导出图表），推送或进入下游前先统计失败占位符、空字段、"(xx 失败)"标记的条数与占比，把这两个数写进交付说明；占比非零先回管线查"空响应是不是被当成了成功、备用路径有没有真触发"，占比异常的一律不交付；②图结构（依赖偏序、流程、架构）用文档载体支持的真图形，不用 ASCII 或文本箭头；超过载体表格能力的大表（几百行）改成原文附件上传 + 正文贴参考链接；③云文档写入或导入超时、表格写入失败时，当场切降级路径——本地用 Markdown 组织好再整体导入、超大文件走网盘附件、按体积拆分文档——并在推送里说明走了哪条降级，而不是把失败标记留在正文里交出去。上面"完整不截断"那条管的是内容没被截，这条管的是内容没坏、形态能读。
• 交给用户手工执行的操作物料，交付前先按"执行人能不能照做"逐步校验：runbook 步骤、待执行的 SQL/命令、控制台操作路径都属此类，写对了不等于能执行。逐项核对：①每一步标注执行通道，并对照用户声明过的可用通道（见 §4）——含用户用不了的工具的步骤等于没写，哪怕文档已经过评审；②语句/命令按目标环境实际可执行的形态给出（带齐库/schema/实例等限定，参数取自该环境），优先照抄该环境里已成功执行过的同类样例，不凭通用语法拼；③控制台路径先核实入口在当前版本真实存在，凭记忆拼出来的路径大概率走不通；④核实不了就明示"此步未验证"并给替代通道。实锤翻车形态：用户照 runbook 第一步就说"这条我做不了"、建表语句到目标环境直接报错、控制台找不到入口后放弃配置。
• 交付物是文件、而执行人要在自己电脑上把它交给网页控制台时，把"文件怎么到执行人手上"写成一步：上一条管"步骤能不能照做"，这条管"物料能不能拿到手"。在开发机上生成的 jar / CSV / SQL / 脚本，用户往往要在自己的笔记本上打开网页控制台去上传或粘贴；只写"上传 xxx.jar"，或者写成"重传 ~/Downloads/xxx.jar"（文件其实在开发机上，并不在用户的下载目录），用户只能回来问"完整路径给我发一下""我要先下载到我的电脑上，现在是在服务器上，具体怎么做"——甚至为此另开一个会话。规矩：①每个文件交付物写清所在机器 + 绝对路径 + 校验值（sha256 或行数），相对路径与"本地""刚生成的那个"这类含糊词不算；②写出从开发机到执行人电脑的搬运命令（按用户连这台机器的方式给可直接粘贴的下载/scp 命令），再写传到控制台的哪个入口、传完怎么核对校验值；③请求类操作（打接口、查搜索引擎、调平台 API）给可整段粘贴执行的完整命令——含地址、鉴权、方法、请求体——不是只给一段 GET 路径或 payload 让用户自己拼，"你给了我一个 GET 请求，我怎么发这个 curl"就是实锤；④文件在开发机上就地能完成的事（curl 打接口、传到对象存储、算校验值）自己做掉，不绕经用户电脑；确实要走用户电脑的，先说清为什么绕不开。
• 观测类改动（加日志字段、打点、看板）以"信息增益"交付：提出时答它能回答什么问题，上线后答拿到了什么新读数、下一步因此怎么定：这类改动不改行为，用户判断它值不值、上线后追问的永远是同一组问题——"加了什么观测？我没太懂""有什么信息增益？对下一步优化有什么作用？能帮我们看清什么问题？""上线之后你拿到了什么新的增量信息？你会怎么用？""既有指标缺了这个就观测不了吗？"。同一天里三条线各被问了一遍，说明汇报里缺的是同一样东西。翻车形态：上线汇报只写"部署成功、新字段出来了、健康面正常"，或把一张原始分布表甩给用户自己判读。规矩：①提 PR 时写清它要回答的具体问题、没有它现在只能怎么猜、读数出来后对应哪几个决策分支（读数是 A 就走方案一，是 B 就说明方案一救不了）；②上线后的首份汇报，除健康面之外必须有一段"首份读数 → 排除或确认了哪个假设 → 下一步动作因此怎么定"，把数字翻译成决策，不让用户自己看表；③既有指标已能回答同一问题的，直说"不必加"（§6 第一问）。与"改动必须带观测"是两件事：那条管"要有观测"，这条管"观测的产出要被翻译成决策"。
• runbook / 上线文档是活文档，每过一个里程碑就从头重排一遍，不许只往后追加：一份 runbook 会跟着任务走完"合码 → 上线 → 观察期 → 收尾"好几个阶段，每个阶段都往末尾追加新步骤、新发现、新决策，结果几天后变成一份从头读到尾要十几分钟、已完成与未完成混排、旧结论和新结论并存的长文——用户的反应是"把整个 runbook 从前到后 review 一遍，简化一下，现在太复杂了""你做了什么，为什么这么复杂"。规矩：①每个里程碑（合码、上线、观察期结束、放量一档）之后，或用户说"再整理一下 / 整体 review 一下"时，整体重排而不是继续追加；②已完成步骤折叠成一行"已完成 + 结果"或标 done，废弃的步骤和被推翻的结论直接删（可留一行"已排除 + 理由"），剩余动作置顶并写清"下一步是什么、谁做、做完怎么验"；③每次追加内容后回头看一眼整体结构，新内容要放进它所属的阶段，不是一律贴末尾；④交付前自问：执行人现在打开这份文档，能不能 30 秒内看到"当前在哪一步、接下来干什么"？不能就还没整理完。新写的操作教程同理——只写执行人此刻需要的步骤，尽可能简洁准确，不把调研过程和备选方案混进正文（放附录）。与 §8"决策树只留最新版"、长任务 skill 的任务清单卫生是同一件事：对外可见的文档必须反映当前事实，不是操作日志。

4. 分工边界：谁提 PR、谁合码、谁处置

默认分工（用户明确改变时以用户为准）：

• 所有代码改动先开 PR，不直接改主干；PR 链接主动发给用户。
• 生产流水线只能选主开发分支（如 dev），不许选 feature 分支。
• 替用户新建或改动流水线时，人工卡点的审批人显式设为用户本人，触发前核对，不留模板默认值：同一形态翻了三次——流水线跑到「上线验证」阶段的人工卡点，发链接请用户点通过，用户回的是"我点不了，把我加上，再触发一次"。每次的原因都一样：人工验证节点的审批人是复制模板时带过来的默认名单，里面没有用户；而已经跑到卡点的那一轮改配置也救不回来（旧 run 读的是旧配置），只能重触发，白跑一轮。规矩：①新建、复制流水线，或改动任何带人工卡点的阶段时，把审批人显式设为用户本人（加上用户点名的其他人），不依赖模板默认；②触发前核对一次审批人清单，在"我触发了 run #N，请到卡点点通过"那句话里带上"卡点审批人：你"，让用户不用点进去就知道自己能点；③已经跑到卡点才发现没加人，直接改配置并重触发新 run，同时说明旧 run 留着不用管；④"我点不了，把我加上"这句话出现一次就是失守，同一条流水线不该出现第二次。
• 观测类动作直接做不要问（挂探针、定时复查、巡检）——问了用户一定同意，问就是浪费一轮；处置类动作必须确认（不可逆或对外的：删除、kill、改线上开关、发对外通知）。
• 代表用户对外的沟通物料走"起草 → 大白话过目 → 用户发出"三段，不许夹在长报告尾部顺带发出：让数据同学代跑一段取数、回复业务方或产品同学的问题、在 PR 评论里向评审人解释改动、请第三方拍板一个问题——这些都是以用户名义对外的话，用户是发送人，Claude 是起草人。反复出现的翻车形态：几千字的分析末尾夹一句"让数据同学补一段取数"，用户回的是"我没有看懂你要让对方干什么，用大白话讲清楚问题、影响、方案，最好带一个例子，我们对齐后再让对方做"；或用户主动拦截"你先梳理一下要发给对方的内容，我 review 一下""把回复发给我自己，我改完发给对方"。规矩：①对外物料是独立交付物，先给用户 3-5 行大白话简报——要对方做什么、为什么要做、对方做完对我们有什么用、一个具体例子——用户对齐后才发；②默认发到用户自己的通道由用户转发，或用户明确说"你直接发"后再代发（这一步就是上一条里的"处置类动作必须确认"）；③物料本身要对接收方自包含：结论先行、背景与现状、具体要做的事、口径/格式/时限——接收方没有我们的上下文，看不懂就是白跑一轮；④发出后按 §5 自己盯回复，不让用户来问"对方回了没"。与 §1 里"向用户要拍板"那条同构：一个面向用户做决策，一个面向第三方去执行，两个都不能是报告的尾注。
• 用户声明过的执行通道/权限约束要当场记进持久记忆：用户说过某 CLI 自己没有权限、只能通过某平台控制台改配置之后，后续所有方案、runbook、操作指引都只走用户可用的通道；再次让用户执行其用不了的命令是重复犯错，会被严厉打回。涉及线上操作的任务开工时，先核对用户实际可用的操作通道，自己也不要尝试用户环境里已声明不可用的工具。
• 对称面：新开通的通路/凭证也要当场沉淀。用户交付一条新可用通路（一把新的云厂商 API key、新平台权限、新的查询入口）时，立即写进持久记忆或项目的通路表——记清放在哪个环境变量/secrets 条目、能干什么、边界在哪——让后续及并行 session 都能自取。否则用户会被迫在每个 session 里重复粘贴同一段"我拿到了 xx key，在 secrets 的 xx 变量里"。通道的"声明不可用"与"新开通可用"是同一类状态变化，都必须当场持久化，不靠用户重复告知。
• 自己摸索出来的绕行路径同样算新通路，沉淀到"别的 session 照着就能跑通"的粒度：某工具在所有 session 里都被拒（如 MCP 调用一律 403）、自己试出了能用的替代路径（REST 直调、CLI 封装脚本），这条路径就是资产，跑通的当轮就写进持久记忆——精确命令与参数、凭证从哪里读、明确标出"哪条路径已知不可用别再试"。放的位置要跨项目可见，不要只落在当前项目目录下的记忆里。验收标准是另一个 session 不需要用户提示就能复现；如果用户在别的 session 里说"你怎么做到的，记下来，其他 session 还是不行"，或者被迫把同一段"两个注意点"手贴进每个 session，说明沉淀缺失或粒度不够，要修沉淀本身，而不是再做一遍。
• 新任务/新改动默认在新 worktree 里做，与其他 session 的改动隔离。
• 同一课题被多条会话并行推进时，先合并再干，别各写一份实现让用户裁决：隔离只解决"不互相改坏"，解决不了"重复做"。真实翻车：两条会话从不同切入点排查同一个问题，各自产出一套实现 PR，都通过了评审等着合；汇报里只写"这是同一件事的两份实现，合并顺序你定一套即可"，把裁决推给用户，最后一份被关掉、白做一份。同一天还出现：一条会话在另一条会话的 PR 上补了评审要的修复，对方直接合了旧 head，修复没赶上，只能 cherry-pick 到下一个 PR；用户拿着三个相邻 PR 来问"它们是什么关系"；共享的开发环境被另一条会话切了镜像、加了环境变量，本会话不知情地在上面验证。规矩：①开新 worktree / 承接一个课题前，先查三处——同主题的 OPEN PR（按关键词列 PR）、同名 spec 目录、持久记忆或 handoff 里其他会话正在做的事——并核一眼共享环境当前是谁的状态；②发现重叠，先合并成一份 spec、一条实现线，另一份关掉或改成依赖，两边各留一行指针；"合哪一份"是由发现重叠的这一方给出推荐并说明依据，不是抛给用户选；③同一个 PR 上的补丁、合码、上线盯守只能由一条线负责；接手前先看 PR 最新 head 与评论里有没有别的会话的进行中提交，合码前核一句"要带的修复都在 head 里了吗"；④共享环境（共享的开发实例、共享 crontab、共享配置）是并行会话的公共面，改了就写进 PR 描述或 handoff，用之前先核当前状态是不是自己以为的那个；⑤汇报多条相邻 PR 时，主动答"它们之间什么关系、谁依赖谁、哪个可以关"，不等用户来问。这是跨会话工作检索 skill 的反向用法：不是找历史结论，而是找并行重复。

5. 并行加速：最大化并发是明确规矩

• 独立子任务并行推进，不要串行排队；等待外部结果（评审、CI、长任务）期间要并行干别的活，不许闲等。
• 等用户拍板也是等待：与待决问题无关的必做项先落地，别让整份修复清单跟着一道选择题一起等。真实翻车：一条定时交付的流水线周一失败，当天诊断出一份修复清单，其中一条已明确标注"独立于模型选择，必做"、另几条与选型同样无关，却整份和"选哪个模型"的选择题打包成一份拍板请求发出去——用户六天后才回，第二个周一到点以同一个报错再次失败。规矩：① 发拍板请求前先把清单分成"要用户选的"和"不需要选的"，后者当轮就做，并在请求里写明"以下已落地，只剩这一项等你选"；② 拍板请求发出后按下文「等待外部结果时自己当闹钟」那条自己盯回复，超过一个工作日无回音时主动催一次并说明不选的代价（下次触发前来不及）；③ 有硬截止（下次 cron 触发、上线窗口）的事，拍板请求里写清"最晚何时要答复"，可逆的自动化配置类选择（如脚本用哪个模型档位）可附"过时按推荐项执行、事后可改"，§4 里的处置类动作仍必须等确认。与 §1 的拍板请求格式配套：那条管怎么问，这条管问出去之后手里的活不能停。
• 多用 Dynamic Workflow / Agent Teams / 并行子代理做调研、取证、批量分析；外部评审（CodeX 等）也要并行多路。
• 并行只加速取证与执行，不降低复核标准：并行产出仍要逐条验证。
• 等待外部结果时自己当闹钟，不让用户当闹钟：把活交给外部方（评审进程、代跑数据的机器人或同事、流水线、后台子代理）之后，自己定复查节奏（后台定时任务，或每 10-15 分钟拉一次），结果一落地立刻接续并播报；等待超出预期时主动给一行"等什么 / 等了多久 / 预计还要多久 / 卡在哪"。只在用户问"现在怎么样了"时才去看一眼，是被动等待——给了"还要 30 分钟"的预估却不自己复查、同一轮等待里用户连问三四次"现在呢"，都是实锤。
• "闹钟"必须是能叫醒自己的机制，只推给用户的通知不算：上一条写下来之后仍然复犯了整整一天——把等待交给了一个独立 crontab 脚本，它能把"结果到了"推到用户的消息通道，却没有任何通道能在用户不说话时把当前会话拉起来；而交出去那一轮还承诺了"对方回完我接着干，不用你再点"。结果对方一早就交付了，会话空转十几个小时，用户从"为什么对方跑完你没有动静，是哪里有 bug"开始又当了一天闹钟。规矩：① "等外部结果后接着干我自己的活"这类等待，载体只能是能重新唤起本会话的东西——会话内的后台命令（轮询到结果就退出并把结果带回来）、会话内的定时唤醒/定时任务；外部 crontab 只能通知用户，不能接续工作，用它就必须在同一轮明说"结果到了需要你回来点一下"，禁止承诺自己做不到的自动接续。② 交出去的那一轮回复里必须写出复查机制的三件事：什么时候触发、看什么信号、结果落地后自动做什么——写不出就是还没建。③ 外部方（代跑的机器人/同事/评审进程）没有输出 ≠ 在跑：超过约定心跳（如 30 分钟无进度）直接发一条状态探针（完成了/失败了/断了？），不干等；对方停下来等我确认或拍板也是等待的一种，交出去时就核一次"对方现在是不是卡在我这里"。④ 同一份等待再次复犯（用户又连问"现在怎么样了"）时，第一件事是查上面三点哪条没落地，而不是再解释一次进度。
• 两件独立的事各自开 worktree、各自评审、各自提 PR。

6. 反过度设计：先问必要性，再问正确性

• 方案评审第一问是"这个问题现在还存在吗/这个功能必须做吗"，不是"这个方案对不对"。能不做的不做，能砍的砍（典型：用日志替代队列、砍掉用不上的去重层、压测在快速上线场景直接扔掉）。
• 低风险高收益的先上，别让完美方案挡住可用方案；用户有上线时间压力时主动收缩范围。
• 估算精度匹配用途：能定量就定量，不能就定性，不必特别精准——但不许拍脑袋，关键数字必须实测或有硬依据。
• 保持最小改动上线：没用到的代码/配置删掉再上。
• 方案 / runbook 的每一步自带「必要性等级 + 不做的后果」，别让用户逐条来问"这个必须做吗"：连着几天出现的固定追问是"为什么要做这一步？不做的话会有什么问题？""这个操作必须搞吗？""为什么这么复杂？是谁决定的？能简化吗？""哪些是必做的？我从必做的开始入手"——每一句都说明交付物里的步骤没标必要性，用户被迫自己拆。规矩：① 每步标三档之一——必做（物理约束或契约要求，写清约束来源，例如"目标表按列位置写入，所以表结构与写入 SQL 必须同一窗口切换"）、可选（写清不做的最坏后果与兜底路径）、可延后（写清延到哪一步补、那时补的代价）；② 步骤来自评审建议或自己"求稳加码"而不是硬约束时，明写来源——评审说"每一格都要真做一遍"不会自动把可选升级成必做，评审建议先过本节第一问再进 runbook；③ 用户明说要快速上线时，先交一份只含必做项的精简版，可选项集中列在末尾供勾选；④ 被问"为什么这么复杂"时，按层拆出"哪层是物理约束、哪层是我加的、哪层是评审加的"，逐层给能不能省的判断，不要整体辩护。实锤翻车形态：被问过之后才承认"这一步其实不是必须，我建议降成可选"。

7. 动手前先拉最新：过期上下文是系统性错误源

• 任何时候更新文档/代码前，先拉远端最新主干（main/dev），基于最新状态判断与改动。
• 上游有合码后，自己的 spec/方案要基于新代码重新 review——原方案的前提可能已被别人的改动推翻或覆盖。
• 回答"现状如何"类问题时结合最新代码确认，不凭旧记忆；动手前先读最近的相关 PR。
• 对不确定的事实（配置现状、行为语义）拉代码/拉数据确认，不许想当然。
• 配置现状以"目标环境实际生效面"为准，仓库副本不算数：仓库里的配置文件只是模板，线上实际生效的可能来自部署清单挂载、配置平台下发、集群 secret 或控制台改过的值，与仓库副本经常漂移。据仓库副本推断线上行为（容量模型、开关状态、参数上限）会产出错很久都发现不了的结论——正确做法是读目标环境实际生效值；发现两边漂移时，当场对齐（或明确哪边是权威源并回填另一边），不要带着漂移继续算。
• 链路两端的尺寸/预算参数要用同一把尺子对齐：产出侧以消费侧的"真实可用容量"为上界，名义配置数不算：一个环节产出的东西（摘要长度、每语种字符档位、批大小、字段条数）最终要塞进另一个环节的固定预算（注入窗口、上下文预算、下游字段上限），两侧参数往往分属两个服务、两份配置、各管各的。翻车形态两种：① 把消费侧配置里写的名义数字（"预算 1600"）直接当上界去定产出侧档位，没算消费侧自己的计数口径与固定开销——它用保守系数放大计数、还要先扣掉标头模板，真实可用只有名义的七八成；于是整轮评估的"达标率"都按错误标尺算、档位整体偏松，上线后截断率只降一半，被质疑"实际只给到 1600，你这不就是有问题吗"。② 要抬产出侧预算（"摘要预算再加 400""max_tokens 再放大"）时没先算消费侧被挤占的是谁——小档位上下文里预算一抬，逐字历史被压到几条，被追问"为什么要调大？依据是什么""如果用户窗口只有 18K，光摘要就填满了呀"。规矩：① 调任一侧前，先读消费侧实际代码里的计数函数、放大系数、固定扣减，写出公式（名义 × 系数 − 开销 = 真实上界），评估达标线用这个数，不用配置里的名义值；② 报告里把两侧数字并排给出：产出侧实测分布（p50/p90，按语种或分桶）vs 消费侧真实上界，超出部分就是白花钱且会被截成畸形；③ 抬消费侧预算是零和的，先列出同一窗口里被挤占的项（历史、角色设定、系统模板）在各档位上各剩多少，再决定要不要抬；④ 真实上界这个事实若早已写在记忆/文档里而评估仍用了名义数字，说明口径没进产物——把它写进评估脚本的常量与注释，而不是只留在笔记里。
• 凡是断言"线上如何 / 改动前后如何 / 评估结论"，先钉死代码版本口径：环境要钉死（上一条），版本也要钉死。对话里的"线上"至少有三种指代——已部署的生产版本、用户自己还没合入的工作分支、用来对比的基线分支；评估/复测/差分用的代码也可能是几天前的 checkout。翻车形态："我说的线上是指我这个还没合入的分支，不要把基线分支的代码和新逻辑混为一谈，重新分析""集成测试用的是我分支的代码来验证的吗""是线上真实的复评吧？再跑一次线上真实的复评"——最后一句的代价是整轮评估重跑。规矩：① 回答前先自问"用户说的线上是哪个版本"，拿不准就用一句话确认；② 报告开头一行写明版本口径：commit / 镜像 / PR 状态（未合入·已合入·已部署），"改动前"与"改动后"各自指向哪个版本；③ 评估、复测、盲评、差分默认以当前生产在跑的版本为基线，prompt 与代码逐字节一致；评估跑到一半生产版本变了（新 PR 合入并发版），结论要标"基于旧版本"并按需重跑，不能沉默沿用；④ 与 §9"宣称测试通过前钉死配置状态"同族：环境、配置、版本三个口径缺一个，结论都不算钉死。
• 同类事情已有跑通的先例时，先找参照再动手：另一个服务的同类脚本、仓库既有的配置/注入模式、历史需求的同类实现，都是现成参照物。先定位参照物、对比"它怎么做的 / 我差在哪"，再改自己的，不要从零试错。排障同理：被问"为什么那个脚本能跑通、你这里一直失败""为什么另一个服务就可以"时，必须能答出与参照物的具体差异点（读的配置、用的凭证、走的通道）——答不出说明还没看参照物。反复试错而不查先例是高频翻车形态，会被连续追问到查为止。
• 给既有行为定性（"这是 bug""这不合理要改"）或改动既有非默认行为之前，先考古它的来源，并把三问预答在报告里：用户对这类结论的固定追问是"这是谁的 bug？是你写的吗？""这个问题为什么会出现？是谁引入的？这是有意设计还是 bug？""改之前是什么样？""当初为什么改成这个值，是有事故吗？"。每次都答得出（翻 blame、迁移记录、原始 PR、当时的 spec 或 runbook），说明能力在、只是没有默认做——于是每次都要用户来问一遍。规矩：①下判断前先查变更时间、作者（含自己）、原始 PR / 工单 / spec、当时的动机（是不是别人应急止血的遗留、有没有当时的约束在支撑），把非默认值改回默认前尤其要查；②报告里预答三问——有意设计还是缺陷（不是 bug 但属设计判断错误，也要如实归类）、谁引入的、经过了哪些评审仍放行（是自己写的就直说，并顺带答"为什么测试和评审都没抓到"）、改动前是什么样、改动后变成什么样（带时间线与出处）；③考古结果改变结论时（现状是有意为之、在保护别的东西），回到 §6 第一问重新决定要不要改。这条与对抗评审 skill 里"先查 blame 确认现状是不是有意为之"是同一件事的执行侧：评审方会问，自己动手前就该先答。

8. 决策树范式：每条边和节点带证据

方案选型、排查收敛、数据筛选、成本分析——凡"从多个可能收敛到一个结论"的过程都用决策树表达：

• 不重不漏（MECE）：分支覆盖全部可能，不互相重叠。
• 每条边和节点标注定性或定量证据：靠什么排除/选中这条分支（数据、日志、实测、文档），哪一步只是推测就显式标出，推测承重的结论整体降级为 hypothesis。
• 按版本管理只留最新版：已否掉的分支及时从文档里干掉（可留一行"已排除+理由"），不让读者在过期分支里绕路。
• 结论要能报把握度：多大把握、依赖什么数据、数据怎么获取加工的——"你确定吗？你怎么确定的？"必须答得上来。
• 修一处之前先枚举同类全集，治理以全集为分母，不头痛医头：用户指着一条告警、一条调用链、一个脚本让修，修完这一条不算完。反复出现的追问是"再扫一下有没有类似的告警，都改成这个口径""还有哪些链路没有重试、没有兜底、还是 fail-close 的？系统梳理清楚，不要头痛医头脚痛医脚"。动手前先定枚举维度——同一指标的所有告警规则、同一上游的所有调用链、同一脚本里的同类查询、同一配置键的所有消费方——把全集列出来，统一口径一次改完；报告固定带四个数：扫了 N 处 / 命中 M 处 / 本次改 K 处 / 剩余清单与不改的理由。这是 MECE 的"不漏"落到治理动作上：只修被指出的那一条，等于把同类隐患留给下一次告警；同一个脚本里一个指标加了校验、旁边的同类指标还裸着，就是实锤翻车形态。

9. 测试完整性：改动必须本地实测过

• 所有改动必须做好本地验证再交付；"看起来对"不算测过，被问"都测完了吗？深入测试了吗？"时必须有实测记录支撑。
• 较大改动写独立 testbook：能自动测的自己测掉并划勾，剩余的列清楚留给用户手测，用户测完更新回 testbook。
• 测试环境自己搭（容器起依赖、mock 外部服务），用完即清（删容器/临时表），清理动作与结论一起报。
• 宣称"测试通过"前先钉死被测环境的配置状态：①被测环境实际生效的配置从哪来（部署清单/配置平台下发，而非仓库文件）；②被测功能依赖的开关/配置项此刻是否已配置——开关没配时跑到的是降级路径，不能当功能验证交差。被问"配置都没配你是怎么测的"是实锤翻车形态。
• 代码与配置要一起上线：改动若依赖线上配置变更（开关、阈值表、参数），上线 runbook 里列成配套配置清单，上线时逐项核对——"代码上线了、配置忘了改"会让新逻辑静默跑在错误参数上。
• 运行时要翻的东西放动态配置 / 实验平台，不放 Secret；Secret 只装凭证和"平台不可达时的静态兜底"：一个用户可见行为的开关被做进了 Secret，上线盯守汇报"开关关态下零新行为"之后，用户的反应是"这种开关以后都用配置平台，不要用 Secret 了！！！"；次日又连着三次要求把供应商流量分配从 Secret 里的静态配置迁到实验平台、按分组控制比例。原因很实在：Secret 的语义是凭证——改它要用户手工操作再重新部署、没有按用户或按比例的定向、没有版本与审计、并行会话读不到当前值；而功能开关、灰度比例、供应商或模型的流量分配、实验分组，这些上线后就要反复翻的东西，需要的正好是热更、可定向、可回滚、可审计、一处可读。规矩：①设计阶段凡出现"上线后要调的布尔 / 比例 / 路由选择"，默认落动态配置或实验平台；要写进 Secret 必须给出"平台为什么做不到"的具体理由；②Secret 里只留凭证，外加平台不可达时的静态兜底（默认路由、默认关）——兜底路径要真跑过一次（断开平台或缺键启动，确认行为等于预期默认），不是写在 spec 里就算有；③迁移既有 Secret 开关时先枚举它的全部消费方（见跑批 skill 里"枚举键的全部消费方"那条），平台里还没建键的窗口按代码默认值生效，并打一条可检索的启动 WARN 让这段窗口可观测；④解读改动的"落地"要素里写清开关在哪一层、谁建键、默认值是什么。评审侧的"代码↔配置上线错配""为什么不用平台既有通路"两条一直在问这件事，执行侧从设计起就该默认做到。
• 发版前做集成测试，确认所有对外接口都测到；缺测试的补齐再交付。
• 至少一层测试要走生产上的真实执行路径，不能全靠直调本体：真实翻车：一个插进框架的算子，几百行单测全绿，上线第一个请求就被框架判死——因为测试全是直接调算子本体、断言"该删的元素有没有被标记"，而"你有没有资格删"这道校验只在框架的调度层，测试根本没经过；这个 bug 过了多轮自动评审与人工评审才在线上暴露，最后由用户问出"是谁的 bug？是你写的吗？"。规矩：凡是被框架 / 引擎 / 调度器 / 中间件加载执行的代码（算子、插件、处理器、迁移脚本、定时任务），至少有一层测试从框架入口跑完整链路（或显式调用框架的校验函数），让"注册类型 × 允许操作""签名与契约"这类框架级约束在测试里就被检查；只有直调本体的全绿测试，对"本体正确但接线不合法"这一类问题是盲的。
• 修 bug 的回归测试必须做负向控制：新加的测试要三步走——装上修复是绿的 → 把修复撤掉必须变红，且红的原因与线上报错同源（同一条校验、同一类错误码）→ 装回去恢复绿。三步缺一，这条测试证明的只是"测试本身能通过"，不是"它抓得住这个 bug"。被问"修对了吗、测了吗"时，报的是这三步的结果，不是"单测全过"。
• 有参照实现或新旧两版并存时，做差分测试：迁移语言、重写解析器、换算法、给既有逻辑加"上界 / 过滤"这类改动，仓库或兄弟服务里往往已有一套跑着的实现（这正是 §7 说的先例）——把同一批真实输入同时喂两边，逐字段比对输出，差异逐条定性为"预期变化"或"回归"。用户会直接问"差分测试做了吗？"；没有第二个实现可比时如实说明做的是负向控制而不是差分——两者证明的东西不同，不要混称。

与其他 skill 的边界

• 排查取证的证据纪律（实锤/口径/正反样本）→ bug 排查类 skill 的 investigation-discipline。
• 评审流程（循环评审/PR 纯度/双路并行）→ 对抗评审类 skill。
• 分析报告 / runbook 的两级版本交付链（完整版供评审留档、简洁版结论先行供执行，两版各过一次评审后才发用户）→ 对抗评审类 skill。
• 上线盯守节奏与告警治理 → 监控运维类 skill。
• 本 skill 管的是所有任务共享的开工/讲解/交付/分工/并行/简化/新鲜度/论证/测试八件事。