LLM编程规范指南Skill：用四条行为准则治好 AI 写代码的"过度设计病"
- 它是什么：一个轻量的行为约束型 AI 技能，把 Andrej Karpathy 关于 LLM 编码陷阱的观察，落地成 4 条可执行准则：编码前思考、简单优先、精确更改、目标驱动执行。
- 它解决什么：AI 写代码最常见的四类翻车——乱猜需求、过度设计、顺手改坏无关代码、交付一个"看起来能跑"却无法验证的结果。
- 它不提供代码，只提供"行为纪律"：不新增任何运行时依赖，不改动你的技术栈，作用对象是 AI 的思考与动手方式。
- 适合谁：日常用 AI 写代码、审查代码、重构遗留系统的开发者，以及需要给团队统一 AI 协作规范的技术负责人。
- 成本与门槛：极低。技能本体遵循 MIT 许可（以官方说明为准），安装后即可生效，无需编写提示词模板。
一、该技能叫什么？如何下载安装 AI 技能提升开发效率？
技能中文名：LLM编程规范指南Skill 技能英文名：karpathy-guidelines 技能ID：13731
它要解决的问题非常具体：大模型写代码时"太能干"反而帮倒忙。你说"加个校验"，它给你建了一套可插拔的校验器框架；你说"修个 bug"，它顺手把旁边三个函数的命名风格改了；你说"重构一下"，它交付了 300 行新代码，却没有任何办法证明重构前后行为一致。这个技能就是把这些"AI 式热情"按下去，让模型在动手之前先说话、在动手之时只动该动的地方、在动手之后能自证结果。
为什么强调"一键安装"？ 传统做法是把这些规范写成一大段系统提示词，每次对话粘贴一遍，或者塞进项目里的规则文件——容易漏、容易版本不一致、换个工具就失效。AI 技能（Skill）的形态把这些规则封装成一个可复用的能力单元，安装一次，在支持技能调用的客户端里即可自动加载，团队共享时也只需要共享同一个技能条目。
安装思路与步骤（通用流程，具体入口以官方说明为准）：
- 确认前提：你使用的 AI 编程客户端 / Agent 环境支持"技能（Skill）"机制，并已登录账号。若不支持技能加载，则需要换用支持的环境，或改用把规范粘贴进对话的方式手动使用。
- 找到技能：在技能市场或技能库中，用技能名
karpathy-guidelines（即 LLM编程规范指南）搜索，或直接按技能ID 13731 定位。 - 一键安装并启用：点击安装 / 添加，确认该技能在会话中处于启用状态。本技能不引入任何外部依赖与工具权限，属于"纯行为指南"型技能。
- 验证是否生效：开启一个新会话，给出一个故意模糊的需求（例如"帮我优化一下这段代码"），观察模型是否先复述假设、指出多种解释、并给出可验证的成功标准，而不是直接甩出一大段改写后的代码。如果它开头就问"你希望优化性能、可读性还是可测试性"，说明技能已生效。
- 团队落地：把技能名与技能ID记录进团队的协作文档，统一安装，避免出现"同一个项目里，两个人让 AI 按两套规范干活"的情况。
二、该技能的主要功能和特点
- 编码前思考：不假设、不隐藏困惑、揭示权衡。 强制模型在实施前列出假设；有多种解释时全部呈现而非默默选一个；存在更简单方案时主动说明，必要时提出反对；遇到不清楚的地方就停下来提问。
- 简单优先：解决问题的最少代码，拒绝推测性设计。 明确禁止四类动作：加需求之外的功能、为一次性代码造抽象、加没人要的"灵活性/可配置性"、为不可能发生的场景写错误处理。还配套给了一个自查句——“资深工程师会说这过于复杂吗？”
- 精确更改：只触及必须的部分。 编辑既有代码时，不"顺手美化"相邻代码与格式，不重构没坏的部分，匹配现有代码风格，发现无关死代码只提出不删除。每条改动都必须能直接追溯到用户请求。
- 目标驱动执行：把任务转成可验证的成功标准。 把"添加验证"翻译成"先为无效输入写测试，再让测试通过"；把"修复错误"翻译成"先写一个能复现错误的测试"；把"重构 X"翻译成"确保重构前后测试都通过"。多步骤任务要先给出"步骤 → 验证方式"的简要计划。
- 自带边界感：偏向谨慎而非速度。 技能本身声明这是一份"权衡"，对简单任务允许使用判断力，避免把轻量需求也拖进冗长的确认流程。
- 和普通"代码风格指南"的根本差别：风格指南管的是"代码长什么样"，这个技能管的是"模型怎么想、怎么动手、怎么交付证据"。它约束的是过程，而过程才是 AI 编码翻车的主要来源。
三、如何使用该技能？
第 1 步：安装并确认启用。 参见第一部分，安装后在会话中确认技能已加载。
第 2 步：在任务开场用一句话点明意图（可选但推荐）。 例如：“用 karpathy-guidelines 的方式来做，先不要写代码。”
第 3 步：观察它是否先"说话"再"动手"。 输入一个模糊需求：
帮我给
createOrder这个函数加上参数校验。
按照技能规范，模型的正确反应应该是：先说明假设（要校验哪些字段？非法输入是抛异常还是返回错误码？是否有既有的校验工具类？），指出可能的多种解释，而不是直接返回一版新实现。
第 4 步：让它把模糊目标转成可验证目标。 继续追问："请把它变成可验证的成功标准。"你会得到类似这样的输出：
目标：为
createOrder增加参数校验，且不改变现有正常路径行为。
- 为缺失必填字段编写测试用例 → 验证：用例失败（红）
- 实现最小校验逻辑 → 验证：该用例通过（绿）
- 运行全量既有测试 → 验证：无新增失败
第 5 步：在重构或修 bug 时要求它先出计划。 例如输入："重构 parseConfig，按技能的格式给我计划。"预期输出：
- 提取纯解析逻辑，不改行为 → 验证：现有单测全绿
- 为异常配置补充测试 → 验证：新增用例覆盖三类错误输入
- 替换调用点 → 验证：全量测试与构建通过
第 6 步：验收时看"改动账本"。 检查它是否只改动了与请求直接相关的行；如果它删除了某个看似无用的函数，应当确认：这是它的改动导致的孤儿代码，还是本就存在的死代码？后者它只应该"提出"，不应该"删除"。
第 7 步：在代码审查场景中反向使用。 让模型以该技能的视角审查一次合并请求：“用 karpathy-guidelines 审查这段 diff，指出过度设计与越界改动。“它会更倾向于说"这 200 行里有 150 行属于推测性设计”，而不是泛泛地夸"代码结构清晰”。
四、同类型竞品对比分析
| 方案名称 | 定位 | 核心功能 | 安装/使用门槛 | 适用场景 | 优势与不足 |
|---|---|---|---|---|---|
| karpathy-guidelines（LLM编程规范指南Skill） | 约束模型编码行为的轻量指南 | 编码前思考、简单优先、精确更改、目标驱动执行四条准则 | 极低，技能市场一键安装；无外部依赖 | 日常 AI 结对编程、代码审查、遗留代码重构、修 bug | 优势：零配置、直击过程失误、模型无关的行为约束；不足：不提供语法级检查，效果依赖模型是否遵守指示 |
| 通用大模型裸用（不加载任何规则） | 直接对话式编码 | 由模型自行决定表达方式与实现范围 | 最低，打开即用 | 一次性脚本、思路咨询 | 优势：自由度高、速度快；不足：极易过度设计、乱改无关代码、交付不可验证结果 |
| 项目内手写规则文件（如项目说明文档或系统提示词） | 团队自定义的 AI 协作规范 | 可写入任意团队约定、技术栈偏好、目录规范 | 中等，需要人工撰写与持续维护 | 有稳定技术栈与专有约定的长期项目 | 优势：高度贴合团队实际；不足：需要持续维护、跨工具复用差、容易与代码现状脱节 |
| 静态代码质量工具（如代码检查与质量平台） | 机器可判定的代码质量与缺陷扫描 | 语法规则、安全漏洞、复杂度阈值、重复代码检测 | 中等，需接入构建流水线并配置规则集 | 提交前门禁、CI 质量卡点 | 优势：确定性强、可自动化卡点；不足：只能事后发现"结果问题"，无法在模型生成阶段阻止过度设计与越界改动 |
怎么选？ 三者不是替代关系：静态质量工具守最后一道门，手写规则文件管团队特有约定，而 karpathy-guidelines 管的是"模型在生成那一刻的思维方式"——它补的正是前两者覆盖不到的过程层。
五、该技能的典型应用场景与实际体验情况
场景一：后端工程师在遗留系统上做小需求 痛点：老项目风格杂乱，AI 一动手就"顺便"重排缩进、替换工具类、改掉别人留下的注释，导致 diff 大得没法评审。 使用方式：加载技能后提出需求，并在结尾加一句"只做精确更改"。实际体验：diff 体积明显收敛，评审时能逐行追溯到需求本身；注意事项是当项目确实需要清理时，要显式授权，否则它只会"提出"而不会动手。
场景二：独立开发者做早期原型 痛点：原型阶段最怕过度设计——一个还没人用的功能被做成了可配置、可扩展、带插件机制的系统，结果改需求时被自己的抽象拖住。 使用方式：直接描述目标，让它先判断"最简单的可行实现是什么"。实际体验：上手难度几乎为零，产出代码量通常明显小于裸用模型；注意事项是简单任务上不要反复追问，技能自身也提示"对简单任务请使用判断力"。
场景三：技术负责人做代码评审 痛点：AI 生成的 PR 描述往往很漂亮，但很难快速判断"这堆改动里有多少是必须的"。 使用方式：把 diff 贴给模型，要求以该技能的四条准则逐条打分，重点是"是否存在推测性设计"和"是否有改动无法追溯到需求"。实际体验：评审意见从模糊的"可以再简化"变成具体的"这 3 处抽象只被调用一次"；注意事项是仍需人工判断业务必要性。
场景四：修 bug 时先写复现测试 痛点：AI 常见操作是"看一眼报错就改一行"，改完不知道是否真的修好，也不知道有没有引入新问题。 使用方式：使用技能中的翻译规则，把"修 bug"表述为"先写一个能复现该错误的测试"。实际体验：修复闭环从"看起来好了"变成"红转绿"，尤其在偶发问题上有明显帮助；注意事项是某些环境难以写自动化测试时，需退化为明确的手工验证清单。
整体手感：这是一个"零学习成本、但需要一点耐心"的技能。它增加的是开头几分钟的澄清时间，换来的是后面少绕的弯路。对极其简单的任务，它的提问可能略显啰嗦——这也正是技能文档里主动声明的那份"权衡"。
六、该技能能为用户带来的价值
- 减少返工：过度设计是 AI 编码最大的隐形成本。少写的那 150 行推测性代码，意味着未来少 150 行的维护、测试和解释成本。
- 让 diff 可评审：当每行改动都能追溯到需求，代码评审从"通读全文"变成"核对账本"，评审时间与争议都显著下降。
- 把"能跑"升级为"可验证"：目标驱动的执行方式让每次交付都自带成功标准，减少了"看起来没问题"带来的后期排查。
- 压低 AI 协作的使用门槛：不需要学会写复杂提示词，不需要背诵规范条款，安装即用；对刚接触 AI 编程的开发者来说，它相当于一位随时提醒"别想太多、别改太多"的结对伙伴。
- 长期价值在于习惯沉淀：四条准则本身就是一套可迁移的工程判断力训练——编码前揭示假设、用最少代码解决问题、只改必要之处、以可验证目标驱动工作。这些并不只对 AI 有效，对人同样有效。
七、常见问题 FAQ
Q1：这个技能怎么安装？需要改代码或装依赖吗？
不需要。它是纯行为指南型技能，不引入任何运行时依赖，也不会改动你的项目。在支持技能机制的客户端中搜索技能名 karpathy-guidelines 或技能ID 13731 一键安装启用即可；具体安装入口与支持的客户端范围以官方说明为准。
Q2：它是收费的吗？ 技能本体标注的许可为 MIT（以官方说明为准）。你实际产生的费用主要来自所使用的大模型调用，与本技能无关。
Q3：它适合谁用？不适合谁？ 适合日常用 AI 写代码、审查代码、重构遗留系统的开发者，以及需要统一团队 AI 协作规范的技术负责人。如果你只是想让模型快速生成一个一次性脚本、且不在意实现是否精简，它的澄清流程可能显得多余——技能自身也说明：简单任务请使用判断力。
Q4：它和项目里手写的 AI 规则文件、代码质量工具冲突吗？ 不冲突，是互补关系。代码质量工具在提交后发现问题，手写规则文件承载团队特有约定，而该技能作用于模型生成代码的过程本身，从源头减少过度设计与越界改动。三者可以同时启用。
Q5：装上它会不会让 AI 变慢、事事都来反问我？ 技能明确声明"偏向谨慎而非速度"，因此会在需求模糊时停下来提问。实践中的建议是：需求清晰时直接给出明确目标（含验收方式），模型就会减少反问、直接进入"计划 → 验证"的节奏；只有在需求本身存在多种解释时，提问才是它应有的表现。