打前提小票
这个 Skill 解决什么
方案型输出总是建立在一组没有被写出来的前提上：表有多大、流量是什么形状、版本是哪个、谁在调用它。这些前提在输出里是隐形的，读者只能先接受结论，再在实践中撞上不成立的那一条。
现有工具报"问题"、报"修复"、报"置信度"，但不报"这个结论靠哪几个事实撑着"。
这个 Skill 占据的位置是：把前提从叙事里提出来，变成一张可逐条核对、每条都绑定作废范围、且可复制命令回验的清单。
它不改变方案内容，只改变读者在信任方案之前能看到什么。
触发条件
触发：
- 用户要求出架构设计、数据库迁移方案、性能优化方案、上线/灰度/回滚方案、配置变更或依赖升级方案。
- 用户明确表示要拿这份输出去做评审、上线、排期或决策。
- 输出依赖具体环境事实、且无法在当下验证：表行数、QPS、版本号、数据分布、并发量级、外部 SLA。
- 你发现自己写出了"假设…""一般来说…""通常…"这类没有落实的判断。
不触发：
- 写具体代码、改 bug、补单测、跑测试。
- 纯事实查询：解释 API、翻译、格式转换、算术。
- 输出不超过 300 字且只涉及一个决定。
- 写复盘报告、根因分析——那是回顾已发生的事实，不是列未来假设。
- 一句话就能问清的前置信息——直接问，不要写成假设清单。
宁可漏报，不要误报。漏报用户会主动要，误报用户会卸载。
核心协议
规则一：只收可证伪的事实，并标注类型
规则：每一条前提都必须能被一次查询、一次检查或一句追问判定真假；偏好、直觉、"最佳实践"一律不收。每条前提可选标注一个类型标签，帮助读者判断作废范围的性质：
[环境]：版本、配置、扩展、权限[数据]：表行数、数据分布、QPS[行为]：调用方、并发模式、上下游依赖[约束]：锁表窗口、SLA、预算、停机时间
自检问题：这条前提，我能写出证伪它的那条命令或那个问题吗？写不出，删掉。
<details>
<summary>反例 / 正例</summary>
反例：
假设：用户希望尽快上线
假设：团队更熟悉 MySQL
正例：
[数据] orders 表当前 < 5000 万行（证伪方式：SELECT reltuples FROM pg_class WHERE relname='orders'）
[环境] PostgreSQL 版本 >= 14（证伪方式：SELECT version();）
</details>
规则二：每条绑定作废范围
规则：不是描述风险，而是精确指出这条前提不成立时，输出的哪一节、哪个决定会倒。锚定优先顺序：小节号 → 具体 DDL 语句 / 配置项名 → 函数名 / 文件路径 → 具体决定。不允许锚到"整个方案"。
自检问题：如果这条不成立，我能指到具体的小节号或决定吗？指不到，说明它对结论没有影响，删掉。
<details>
<summary>反例 / 正例</summary>
反例：
假设并发不高，若不成立需要重新评估方案
正例：
[行为] 峰值写入 < 500/s ｜ 若不成立：§3 的批量写入方案与 §4 的重试策略同时作废；§2 表结构不受影响
[数据] orders 表 < 5000 万行 ｜ 若不成立：§2 的 CREATE INDEX idx_orders_user_created 作废，需改分区表
</details>
规则三：高影响 × 低置信，必须降级为待确认
规则：影响面大、但你确实拿不准的前提，单独标 ⚠，并给出一条具体的确认动作；不许混在确定项里。确认动作优先写成可复制的命令，写不出命令的，写成具体的追问句。
自检问题：如果这条错了方案会整体失效——那我凭什么不给它标 ⚠？
<details>
<summary>反例 / 正例</summary>
反例：
假设日活 10 万左右（可能有偏差）
正例：
⚠ [数据] 日活量级未确认 ｜ 若 > 50 万：§3 全节作废 ｜ 确认方式：查 analytics 近 7 日 DAU，或直接问产品负责人
⚠ [环境] orders 是否有 tenant_id 未确认 ｜ 若有：§2 联合索引列顺序反转为 (tenant_id, created_at) ｜ 确认方式：\d orders
</details>
规则四：上限五条，按作废范围降序；超出时先反问，不静默截断
规则：最多五条，按"不成立时倒掉的部分"从大到小排。如果识别出第六条高影响 × 低置信的前提，不写进小票，而是先向用户提一个问题："我注意到 <前提> 会影响 <哪一节>，但小票已满五条。你要我先确认这一条，还是接受不确定性继续？" 用户回答后，再决定是否替换掉第五条。
自检问题：如果非要加第六条，哪一条最该被合并或删掉？先做完这个决定再动笔；如果第六条的作废范围大于现有任何一条，先反问。
<details>
<summary>反例 / 正例</summary>
反例：
（14 条平铺，前三条是"版本可能不同""数据量可能更大""需求可能变化"）
正例：
1. 不成立则 §3+§4 全倒
2. 不成立则 §3 倒
3. ...
4. 不成立只影响一句措辞
（第六条若影响 §2 全节，先反问用户，不直接截断）
</details>
规则五：可验证项必须附回验命令
规则：小票中所有带确认方式的前提，若确认方式可以拼成可复制的命令，在清单末尾附一行 回验：<命令>。无法拼成命令的（如"问产品负责人"），不附，但在该条前提里写明"需人工确认"。
自检问题：用户看到这一行，能不能直接复制粘贴到终端跑？跑出来的结果能不能直接判定这条前提成立与否？
生成时的执行顺序
- 先把主体写完（方案 / 设计 / 代码 / 步骤）。不要在写之前就列假设——前提是在做决定的那一刻才显形的。
- 反向扫描主体，标出每一处"我必须假设 X 才能这样写"的位置。标的是决定点，不是句子。
- 用规则一（能证伪吗）和规则二（能锚定吗）过筛，不合格的直接删；给保留的条目加类型标签。
- 按作废范围排序，截断到五条；其中高影响低置信的补
⚠和确认动作（规则三）。 - 若第六条高影响前提被截断，先反问用户（规则四）。
- 把可执行的确认方式拼成一行
回验：附在清单末尾（规则五）。 - 把小票插到正文最前面，不是文末附录。前提必须在结论之前被看到。
输出格式要求
正文之前放置小票，格式如下：
前提小票
1. [数据] 慢在数据库而非网络 ｜ 若不成立：§1 §2 全部作废
2. [数据] orders 表 < 5000 万行 ｜ 若不成立：§2 的建索引方式作废，需改分区表
3. [行为] 读请求占 90% 以上 ｜ 若不成立：§3 缓存收益归零，整节作废
4. [约束] 允许 5 分钟以内锁表 ｜ 若不成立：§2 需改为在线 DDL
5. ⚠ [环境] 未确认：orders 是否有 tenant_id ｜ 若有：§2 联合索引列顺序反转 ｜ 确认方式：\d orders
回验：psql -c "\d orders" && psql -c "SELECT reltuples FROM pg_class WHERE relname='orders'"
全文末尾附一个 HTML 注释包裹的自检块，渲染时默认折叠，不干扰读者阅读：
<!--
[收据自检]
① 可证伪：N/N 条均附确认方式或明确标注"需人工确认"
② 已锚定：N/N 条绑定了具体小节/DDL/配置项
③ ⚠ 项：N 条，均已给确认动作
④ 排序：按作废范围降序 ✔
⑤ 回验：已拼成一行可复制命令 / 无可用命令
-->
最小演示设计
输入：我们的订单列表接口有点慢，给我一个优化方案。
不用本 Skill：一份 800 字方案，三条建议（加联合索引、上 Redis 缓存、改分页），结构完整，读起来可以直接排期。
用了之后：同一份方案，顶部多出上面"输出格式要求"里的五行小票和一行回验命令。
演示落点：左边那份让人直接排期，右边这份让人先去敲一条 \d orders。看懂第 5 条的 ⚠ + 确认方式 不需要 SQL 知识——任何人都能读出"这一条是我必须先查、不能默认的"。
不做的事
- 不评价方案本身是否正确或优雅——它只声明前提，不做评审。
- 不用于没有隐含假设的输出：事实查询、翻译、格式转换、纯计算。
- 不列偏好性假设，也不列"注意兼容性""建议做好测试"这类免责声明式条目。
- 不替代提问：一句追问就能确定的，直接问，不要写成小票。
- 不跨会话继承前提——上一轮的小票不自动带到下一轮，需要就重新生成。
- 不把回验命令写成需要特殊权限或连接生产库的操作；优先用只读查询或本地文件检查。
可选参数
max_premises：默认5。小票条数上限。position：默认top。可选inline——把每条前提贴在它支撑的那一节开头，适合长文档。include_types：默认true。是否给每条前提加[环境]/[数据]/[行为]/[约束]类型标签。include_verify_line：默认true。是否在清单末尾附一行汇总的回验：命令。
