Ruosong320 Understand First
用户描述完规则后，agent 的第一反应不是动手，是证明自己没理解错。
理由很实在：规则复述可以靠复读蒙混过关，换个领域造例子不行。造得出跨领域的正例反例，说明抽到了规则本身；造不出，说明只记住了用户的措辞。这个 skill 存在的唯一目的，就是把"是否真懂"这件事提前到动手之前暴露出来，而不是实现完 300 行之后才发现方向就错了。
何时用
用：用户刚讲完一套可复用的判定规则或流程，接下来要按它产出/改造/批量执行。 典型信号——「我的思路是…」「本质是…」「限定输出必须满足①②③」「你理解一下再做」「重新理解一下并产出案例」。
不用：
- 单步明确指令（「把这个变量改名」）——直接做。
- 需求还没成形，边界不清 →
initer。 - 要的是技术方案不是理解确认 →
real-solution-plan。 - 要的是只读分析 →
analyze-only。 - 同一套规则本轮已经确认过 → 不要重复表演，直接执行。
硬流程
1. 压缩复述
把规则压成编号条目，不要整段复述用户原话——原话复述是零信息量的。
复述时必须做一次信息增益动作，至少一项：
- 补出用户没明说但逻辑上必然蕴含的条件；
- 指出两条规则之间的张力（例："②要求组合后能完成上级任务，③要求不偏离原目标；但拆得越独立越容易偏离，这对约束是有张力的"）；
- 指出规则未覆盖的情形。
只会原样复述 = 没理解，重来。两条规则直接互斥、压不成一组自洽条目时，取「理解卡壳时的兜底」表中以 两条规则直接互斥 开头的那一行处理，不得替用户裁决。
2. 跨领域造例（核心）
给 ≥3 个样例，硬性约束：
- 领域必须与用户举的例子不同。 用户举女鞋，就不许用女鞋、女鞋销量、女鞋市场——那是同一题换皮。跨到出海、RAG 上线、办发布会这种真正不同的语义空间去。
- 每个样例给正例 + 反例。 只给正例无法证明理解了边界；反例要标出违反了哪一条。
- 样例要具体到可以直接被判对错。 「一个好的拆分」不算样例，「合规准入 / 本地化运营 / 渠道建设」才算。
- 至少一个样例踩在边界上，即那种「看起来合规但其实违反某条」的情形——这是最容易暴露误解的地方。
格式：
样例 N｜<领域>
输入：<具体输入>
✓ <具体产出>
✗ <具体产出> —— 违反第 X 条：<原因>
🔴 CHECKPOINT — 样例交出去之前逐条过。任一条 ✗，先按该条箭头的动作处理再交，不得用「差不多」的样例换用户的确认。
- 领域真的与用户举过的例子不同吗？ 同题换皮（女鞋 → 女鞋销量）不算。✗ → 取兜底表中以 用户举的例子覆盖了整个目标域 开头的那一行处理。
- 每个样例都配了反例，且反例标了违反第几条吗？ ✗ → 补齐后重过。
- 至少一个样例踩在边界上吗？ ✗ → 补齐后重过。
- 样例具体到能直接判对错吗？ 「一个好的拆分」这种不算。✗ → 补齐后重过。
造不出真正跨领域的样例时，取「理解卡壳时的兜底」表中以 用户举的例子覆盖了整个目标域 开头的那一行处理；用户举的例子本身就违反规则时，取以 用户举例里本身就含有违反规则的情形 开头的那一行处理。不要自行降级。
3. 标出疑点
列出 1-3 条答案会改变实现的边界疑点，每条写清"若 A 则我会…，若 B 则我会…"。让用户看到分歧的后果，而不是问一句空泛的「这样理解对吗」。
没有真疑点就写「无阻塞疑点」，不要为凑格式硬编。
4. 实施骨架
3-6 行说明确认后要做什么、改哪里、怎么验。不展开细节——细节是 real-solution-plan 的活。
5. 等确认
🛑 STOP — 用户没回复就是没确认。把「等确认」当作默许动手，是本 skill 最常见的失败方式。
明确停下。用户纠正后，回到第 2 步重造样例（不是打补丁式地改一个例子），因为规则一变，之前所有样例的有效性都要重判——重造前先取「理解卡壳时的兜底」表中以 用户纠正的是规则本身 开头的那一行处理。用户沉默不回应，取同表中以 用户对复述与样例不回应 开头的那一行处理。
理解卡壳时的兜底
以上流程每一步都可能卡住。下列情况按表处理，不得静默降级成「差不多懂了」；下表不限于某几步。
| 触发条件 | 一线修复 | 仍失败兜底 |
|---|---|---|
| 用户举的例子覆盖了整个目标域，找不到真正跨领域的样例 | 别在同题换皮里打转：把行业抽象成机制再换场景（女鞋 → 选品与库存周转 → 冷链生鲜的选品与周转），证明的是同一个机制 | 换了机制仍无处可去 → 明说「此规则的跨领域样例造不出」，退为同域不同子场景，并声明证明力下降，不得假装仍是跨领域证明 |
| 用户纠正的是规则本身，不是某个例子 | 不要打补丁式改那一个例子：回到第 2 步整批重造，因为一条规则变了，其余样例的判定可能全变 | 重造一轮后用户仍全否 → 停止造第三个版本，改为逐条请用户指出「第几条你读成了什么」，把分歧收敛到具体条上 |
| 两条规则直接互斥，压不成一组自洽条目 | 不替用户裁决：把矛盾作为疑点提出，并给出「若 A 则我会…，若 B 则我会…」两条实现路径 | 用户仍不裁决 → 停在阶段一，明说这是进入实现的硬前置，不得自行选一条动手 |
| 用户举例里本身就含有违反规则的情形 | 当场指出该例是反例、违反第几条，并要求确认这是举例失误还是规则本身要改 | 用户坚持该例为正例 → 以用户认可的这条为准，同时在疑点里记下它与原规则的冲突，不静默改规则 |
| 用户对复述与样例不回应（沉默） | 用具体选项把球踢回去：「是第①条、第②条，还是都不对？」 | 仍无回应 → 停在等确认，在动任何手之前明说在等确认，不得把沉默当作默许 |
反模式
用用户的例子证明理解
✗ 用户举例「女鞋 → 品类/价格带/渠道」，agent 回「明白，比如女鞋可以拆成品类、价格带、渠道」
—— 这是复读，零证明力
✓ 换到「企业出海 → 合规准入/本地化运营/渠道建设」
只给正例
✗ 三个都是对的例子 —— 证明不了知道边界在哪
✓ 每个配一个具体的反例并指出违反哪条
样例全部安全
✗ 三个都是显然成立的简单情形
✓ 至少一个卡在边界上：「东南亚合规准入」看着像独立目标，
实则是「合规准入」的地域限定交织，违反独立性
假确认
✗ 「以上理解正确吗？正确的话我就开始了」然后不等回复直接动手
✓ 真停下
规则被推翻后打补丁
✗ 用户说「第②条你理解反了」→ 只改那一个例子
✓ 重造全部样例 —— 一条规则变了，其余样例的判定可能全变
与其他 skill 的关系
initer之后、real-solution-plan之前。initer 问的是"你要什么"，本 skill 证的是"我懂了你说的规则"。- 被
prompt-forge复用：改写 skill/prompt 前，先用本 skill 证明理解了用户的验收口径。 - 确认通过后，实质工作按 CLAUDE.md 门禁继续走
mission-spliter/scoped-code-change。