夜雨聆风
正 文 开 始
相逢即是缘，关注⭐星标不错过～，每天分享实操教程和技巧。
不是AI不听话，是你没给它喂对“说明书”
这70行代码，凭什么火遍GitHub？
最近，一套只有70行的提示词规则在GitHub上悄然登顶。它来自前特斯拉AI总监、OpenAI创始成员Andrej Karpathy对AI编程缺陷的深刻总结，被封装成一套“铁律”，专门解决AI写代码时的四大恶习：
• 急于求成：不思考就输出，脱离上下文 • 过度设计：杀鸡用牛刀，引入一堆不必要库 • 破坏性修改：改一个按钮，顺带重构整个CSS • 盲目自信：写完不测，直接扔给你
这套规则不复杂，就70行，但效果立竿见影。
本文不讲废话，直接教你怎么把这70行代码装进你的AI工具，并验证它真的“变乖”了。
一、规则长什么样？（可直接复制）
以下为完整规则，你可以直接复制保存为 .mdc 或 .md 文件：
---
description: Karpathy编程铁律 - 减少AI编码错误
alwaysApply: true
---
# 1. 编码前先思考
- 明确说明假设，不确定就问
- 存在多种解释时，列出方案让我选
- 如果有更简单的方法，直接说出来
- 困惑时停下来，指出不清楚的地方
# 2. 简洁至上
- 不要添加没要求的功能
- 不要为一次性代码创建抽象
- 不要加不必要的“灵活性”或“可配置性”
- 不要为不可能发生的场景做错误处理
- 能用50行写完，绝不写200行
# 3. 精准修改
编辑现有代码时：
- 不要“改进”相邻的代码、注释或格式
- 不要重构没坏的东西
- 匹配现有代码风格
- 发现无关死代码时，先告知，不要擅自删除
当你的改动产生孤儿代码时：
- 删除因你的改动而变得无用的导入/变量/函数
- 不要删除原本就存在的死代码（除非我要求）
# 4. 目标驱动，自己验证
把任务转化为可验证的目标：
- “加验证” → “先写无效输入的测试，再让测试通过”
- “修Bug” → “先写复现Bug的测试，再修复”
- “重构X” → “保证重构前后测试全绿”
多步骤任务，先列计划：
1. [步骤] → 验证: [检查]
2. [步骤] → 验证: [检查]以上即为全部70行。你可以根据自己的项目微调，但建议先用原版体验效果。
二、怎么装？分工具详解
🎯 场景1：Cursor（全局规则，所有项目生效）
适用：希望每个项目都自动遵守这套规矩。
步骤：
1. 打开Cursor → 点击右上角齿轮图标 ⚙️ → Settings2. 左侧菜单选择 Rules标签页3. 找到 Rules for AI区域 → 点击+ New4. 给规则起名，如 karpathy-guidelines5. 将上面70行代码完整粘贴到右侧输入框 6. 点击 Done保存
验证是否生效：
在Cursor Chat里输入一个模糊需求，例如：
“帮我写一个用户登录功能”
正常（未加规则）：AI直接甩出几百行代码，连OAuth、第三方登录都给你带上。
加了规则后：AI应该先反问：
“我需要确认几个问题：1. 用JWT还是Session？2. 是否需要记住密码？3. 登录失败最多尝试几次？请告诉我你的选择。”
✅ 一旦出现反问，说明规则已生效。
🎯 场景2：Cursor（项目级规则，推荐）
适用：不同项目用不同规则，且便于团队共享。
步骤：
1. 在项目根目录下，创建文件夹 .cursor/rules（如果没有就新建）2. 在 .cursor/rules/内新建文件，例如karpathy-guidelines.mdc3. 将上面70行代码复制粘贴进去 4. 关键：确保文件头部有 alwaysApply: true（上面的代码已经包含）5. 重启Cursor或重新打开项目
验证方法同上。
💡 项目级规则可以被Git追踪，团队成员clone后自动生效，强烈推荐。
🎯 场景3：Claude Code（命令行工具）
步骤：
1. 打开终端，进入项目根目录 2. 执行以下命令： mkdir -p .claude && touch .claude/instructions.md3. 用任意编辑器打开 .claude/instructions.md4. 粘贴70行规则，保存 5. （可选）你也可以把内容直接放在根目录的 CLAUDE.md中，效果相同
验证：
在Claude Code中输入需求，观察AI是否先提问而非直接输出代码。
🎯 场景4：GitHub Copilot / 其他AI编程工具
大多数AI编程助手都支持自定义系统提示词或项目指令（如Copilot的 copilot-instructions.md）。
通用方法：
1. 在项目根目录创建 .github/copilot-instructions.md（Copilot专用）或对应工具的指令文件2. 粘贴70行规则 3. 保存，重启编辑器
不同工具配置略有差异，但核心都是：把这段文本作为AI的预置指令。
三、常见问题 & 排坑指南
Q1：加了规则后，AI还是直接输出代码，不提问？
可能原因：
• 规则没有正确加载（检查文件路径、命名、格式） • 你用的AI工具不支持 alwaysApply或类似的强制指令• 需求太简单（例如“把变量a改成b”），AI认为无需提问
解决方法：
• 尝试一个明显需要澄清的需求：“给这个API加上限流” • 检查工具的文档，确认自定义指令是否生效 • 在规则最前面加上 IMPORTANT: You MUST follow these rules strictly.加强语气
Q2：规则会不会让AI变得太啰嗦，每个需求都问一遍？
不会。 规则的设计是仅在歧义或不确定时才提问。对于明确的需求（如“把第五行的颜色改成红色”），AI会直接执行。你可以根据团队习惯，删掉“适时提出异议”那一条。
Q3：我不想让规则全局生效，只想针对某个文件类型或某个功能？
Cursor项目级规则支持 globs 字段，可以指定只对某些文件生效。例如只对 *.tsx 文件应用规则：
---
globs:"*.tsx"
alwaysApply:false
---Q4：这套规则适合所有语言吗？
基本都适合。规则不涉及具体语法，而是行为准则。但如果你在写一些极其简单的一次性脚本（比如10行数据处理），建议临时关闭规则，避免过度谨慎。
四、效果实测：AI真的“不抽风”了
我们用一个真实案例对比：
任务：在现有React项目中，给一个按钮添加防抖（点击后1秒内不能再点）。
结论：规则并不是限制AI，而是让它更像个靠谱的高级工程师——先确认、少炫技、改哪是哪、自测再交付。
五、进阶：自定义你的“铁律”
70行只是起点。你可以根据项目特点增加规则，例如：
# 5. 安全底线
- 永远不要硬编码密钥、密码、token
- 如果用户代码中出现了密钥，提示我移除
- SQL查询必须使用参数化，禁止拼接或者针对团队规范：
# 6. 代码风格
- 缩进使用2个空格，不是4个
- 函数命名必须用动词开头（getUser, saveData）
- 注释用英文，变量名用camelCase把它们追加到70行末尾即可。
写在最后
这70行代码之所以能炸穿GitHub榜首，不是因为它有什么黑科技，而是因为它命中了AI编程的七寸——AI不缺知识，缺的是约束。
用了这套规则，你的AI会：
• ✅ 先问清楚，再动手 • ✅ 只写必要代码，不画蛇添足 • ✅ 只改目标区域，不伤及无辜 • ✅ 写完自测，跑不通不提交
不用这套规则，你的AI依然会：
• ❌ 没想清楚就输出几百行 • ❌ 引入一堆你不需要的库 • ❌ 在你修复一个Bug时造出三个新Bug
现在，花3分钟配置好它，然后忘掉它。 你会发现，AI突然变得靠谱了——就像那个天才实习生终于学会了“先问、再做、只做该做的”。
如果你在使用中遇到任何问题，欢迎留言交流。别忘了收藏本文，顺手转发给被AI折磨的朋友。
附：规则纯文本版（一键复制）
---
description: Karpathy编程铁律 - 减少AI编码错误
alwaysApply: true
---
# 1. 编码前先思考
- 明确说明假设，不确定就问
- 存在多种解释时，列出方案让我选
- 如果有更简单的方法，直接说出来
- 困惑时停下来，指出不清楚的地方
# 2. 简洁至上
- 不要添加没要求的功能
- 不要为一次性代码创建抽象
- 不要加不必要的“灵活性”或“可配置性”
- 不要为不可能发生的场景做错误处理
- 能用50行写完，绝不写200行
# 3. 精准修改
编辑现有代码时：
- 不要“改进”相邻的代码、注释或格式
- 不要重构没坏的东西
- 匹配现有代码风格
- 发现无关死代码时，先告知，不要擅自删除
当你的改动产生孤儿代码时：
- 删除因你的改动而变得无用的导入/变量/函数
- 不要删除原本就存在的死代码（除非我要求）
# 4. 目标驱动，自己验证
把任务转化为可验证的目标：
- “加验证” → “先写无效输入的测试，再让测试通过”
- “修Bug” → “先写复现Bug的测试，再修复”
- “重构X” → “保证重构前后测试全绿”
多步骤任务，先列计划：
1. [步骤] → 验证: [检查]
2. [步骤] → 验证: [检查]直接复制以上内容，按文中步骤粘贴即可。开始享受AI编程的丝滑体验吧！
