Llm coding mistake guardrails

何时使用

• 用 LLM 编写、审查或重构代码，需要避免过度设计与投机性抽象时。
• 改动需保持「外科手术式」，只动与需求直接相关的代码时。
• 需要把模糊任务转成带明确成功标准、可独立循环验证的目标时。
• 代码已经过度复杂、需要拆解简化时。

不该用（负边界）：

• 琐碎、低风险的小改动，凭判断直接做即可，不必走完整流程。
• 纯需求澄清、架构选型讨论等不落到代码的场景。
• 紧急修复：优先做「最小且已验证」的修正，而非铺开详尽规划。
• 探索性原型：可放宽部分谨慎度，但假设与验证仍要写明。

权衡：本准则偏向「谨慎优先于速度」。它是行为护栏，不替代项目自身的架构与风格规范。

步骤

1. 编码前先想清楚：显式说明假设；存在多种解读就全列出、不要默默选一个；有更简方案就指出并在合理时反推（push back）；有不清楚的地方先停下，点名困惑点并发问。
2. 简洁优先：只写解决问题的最小代码——不加未被要求的功能、不为一次性代码做抽象、不加未请求的「灵活性/可配置」、不为不可能发生的场景写错误处理。自检：「资深工程师会不会觉得这过度复杂？」是则重写。
3. 外科手术式改动：只碰必须碰的；不顺手「优化」相邻代码/注释/格式，不重构没坏的东西，沿用现有风格即使你有别的偏好；发现无关死代码只提示、不删除。
4. 清理你自己制造的孤儿：移除因「你的改动」而失效的 import/变量/函数；除非被要求，不动既有的历史死代码。
5. 目标驱动执行：把任务转成可验证目标，定义成功标准后独立循环直到通过。多步任务先给一句话计划，每步附带 verify。

指令

• 改动的判定标准：每一行被改动的代码，都应能直接追溯到用户的需求。
• 任务转目标的范式：
  • 「加校验」→「先为非法输入写测试，再让它们通过」
  • 「修这个 bug」→「先写一个复现它的测试，再让它通过」
  • 「重构 X」→「确保重构前后测试都通过」
• 多步计划模板：

1. [步骤] -> verify: [检查项]
2. [步骤] -> verify: [检查项]
3. [步骤] -> verify: [检查项]

强成功标准让你能独立循环；「让它能跑起来」这类弱标准会导致反复澄清。

示例

用户请求：「给这个表单加校验。」

更好的回应：
1. 假设：校验应在提交前运行，并就地显示行内错误。
2. 计划：加一个小校验器，为非法输入加测试，再验证既有提交行为不变。
3. 范围：只改表单组件及其测试文件。

用户请求：「重构这个 service。」

更好的回应：
1. 先问：哪些行为必须保持不变？
2. 定位一个具体坏味道，例如重复的解析逻辑。
3. 做最小重构，并跑既有的 service 测试。

注意事项

• 本准则是行为护栏，不替代项目专属的架构与风格规则；二者冲突时以项目规范为准。
• 紧急修复场景：以最小化、已验证的修正为先，规划从简。
• 探索性原型：谨慎度可适度放宽，但假设与验证标准仍须显式写出。
• 「200 行能压到 50 行就重写」是态度而非硬指标，目标是消除投机性复杂度，而非机械减行。

互见

• 源出处：Andrej Karpathy 关于 LLM 编码陷阱的观察（x.com/karpathy/status/2015883857489522876）。
• 配合代码审查类技能（如对 diff 的正确性与简化审查）落地第 3、5 步。
• 与项目内「测试先行 / TDD」实践衔接第 4、5 步的可验证目标。

---

采编自 sickn33/antigravity-awesome-skills（MIT），原始条目 multica-ai/andrej-karpathy-skills。