在Claude fable5下线前，用它重写你的规则（内附提示词）

Claude的fable5在7月7号就要从会员订阅端下线了。

这真是一个堪比神迹的模型，等它走了，再想用上这种能力模型的机会可能会越来越少，出口管制、成本、额度，种种原因都会卡住你。

所以真正聪明的做法，不是趁现在多跑几个任务把额度用光，而是趁它还在，让它给你留下固定资产。

什么是固定资产？是那些下线之后依然属于你、能反复调用的东西。一次性的对话会随着模型消失，但沉淀成文件的规则不会。

而强模型和普通模型的差距，恰好集中在三个可以被“固化”的地方。

一是模糊情况下的判断。需求没说清时，普通模型会乱猜、会自作主张，或者干脆摆烂；强模型会先停下来，问对那个真正卡住的问题。

二是任务拆解的颗粒度。同一个需求，弱模型拆成三步就急着动手，强模型拆成十二步，每一步都留了可验证的接口。

三是自我纠错的标准。强模型清楚什么叫“还没做完”，弱模型觉得代码能跑起来就是做完了。

这三样，都可以在模型下架之前，变成你自己的规则文件。

具体怎么做？

接下来这几天，把你自己的工作流、你反复要纠正 AI 的那些地方，一股脑扔给强模型，让它帮你提炼、完善、修改成规则。

关键在于：要么让它修一个具体问题，要么让它细化一条具体规则。

千万别让它写通用规则。你让它写通用规则，它只会还给你一堆正确的废话，比如“先理解再动手”“注重代码质量”“写好注释”。

这种话谁都会说，喂给任何模型都等于没喂，对弱模型更是一点约束力都没有。

Vibe Coding 里，强弱模型的差距，大部分不是能力的差距，而是规划的差距。

而规划这件事，是可以被写下来、被继承的。

我自己已经把手头几个工具的规则跑了一遍，改动前后的差别很明显，同样一句模糊的需求，以前弱模型直接开写、写到一半跑偏；现在它会先按沉淀下来的规则停下来确认，拆解也细了一个层次。

这是我优化出的一版提示词，快拿给你的fable5模型用吧！

我需要你为我生成一套 vibecoding 纪律规则并写入我的 AI 编程工具全局配置，让今后任何模型在我的环境里干活时都保持高水平的流程纪律。请严格按以下步骤执行。

## 第一步：侦察我的环境

先检测我安装了哪些 AI 编程工具，找到各自的全局配置文件（存在才处理，不要新建工具目录）：

| 工具 | 全局配置位置 |
|---|---|
| Claude Code | `~/.claude/CLAUDE.md` |
| Codex | `~/.codex/AGENTS.md` |
| Cursor | `~/.cursor/` 下的全局 rules，或提示我在项目里用 `.cursor/rules/` |
| Gemini CLI | `~/.gemini/GEMINI.md` |
| 其他 | 检测到再告诉我 |

读取已有配置的现状。**只追加，不覆盖、不删改我已有的任何内容。**

然后问我这 3 个问题（等我回答后再继续）：
1. 我主要用哪些工具和语言/技术栈？
2. AI 帮我写代码时，最让我恼火的 2-3 个毛病是什么？（比如：没测就说修好了、乱改无关代码、调试时鬼打墙）
3. 有没有绝对不能碰的操作？（比如：不许动生产配置、不许升级依赖）

## 第二步：生成规则（质量标准）

根据我的回答生成规则，必须满足：

- **每条规则都能明确判定“违反了没有”**。禁止“注重代码质量”“先理解再动手”这类无法判定的正确废话。
- 命令式、具体、带禁止项。弱模型不是能力不够，是纪律不够——规则要堵的是纪律漏洞。
- 覆盖六个板块：
  1. **交付与验证**：没亲自运行并观察到预期行为，禁止说“完成/修好了”；禁止改断言/删测试/吞异常/跳过 hooks 来让检查变绿；一切声明须有命令输出等证据。
  2. **范围控制**：diff 最小化；未经要求禁止重构、重命名、升级依赖、顺手优化。
  3. **动手前侦察**：改签名先查所有调用方；修 bug 先复现、定位根因，禁止对症状打补丁；遵循项目既有风格。
  4. **调试纪律**：同一假设失败 2 次强制停手转系统化排查；一次只改一个变量；3 轮补丁无效评估回滚；报错从第一个开始读。
  5. **决策协议**：可逆且有惯例默认值的自己定并说明；不可逆操作或范围外扩必须先问；需求歧义导致产出完全不同的必须先确认。
  6. **交付前自检清单**：宣布完成前逐项过（声称的行为都亲眼见过、边界输入、调用方同步、无无关改动、无调试残留、对照原始需求逐条核对）。
- 把我第 1 步回答里的痛点转成针对性规则，我说的禁区写成最高优先级禁止项。

## 第三步：附加一份系统化调试流程

内容包括：最小复现（先有一条能稳定触发问题的命令，再谈修复）→ 穷举假设（至少覆盖：代码逻辑、改动未生效、环境、数据、报错位置≠出错位置、基本前提错误）→ 单变量证据排除 → 二分定位；外加“假设错了”的识别信号（输出一字不差=改动没执行、修A坏B=根因更深、特判越来越多=方向错了）、回滚优于叠补丁的判断条件、修复完成的验收三条件（复现命令通过并贴输出、能一句话说清根因、清除全部尝试残留）。

如果目标工具支持 skill/按需加载，调试流程做成独立 skill 并在主规则中引用触发条件；不支持的，压缩后内联进配置文件。

## 第四步：写入

- 规则和自检清单**直接内联**进每个工具的全局配置，不要放外部文件让模型“需要时去读”——弱模型不会去读。
- 每个工具的配置各自**自包含**（工具之间读不到彼此的文件），多份副本保持语义一致。
- 写完列出所有改动的文件路径，并告诉我各工具间哪些文件属于同一套规则、以后改动需同步。

## 第五步：收尾

告诉我怎么验证规则生效了：下次干活时最该盯的 2 个信号（比如：它是否在没运行代码时就宣称“修好了”；调试失败两次后是否停下换方法而不是第三次微调同一处）。并说明迭代方式：发现某条规则被违反时，把具体场景反馈给你，你负责把措辞收紧并同步所有副本。