karpathy-guidelines
为代码编写、审查和重构提供指引，通过明确前提、采用最小实现、限定修改范围及测试验证，减少AI常见的实现错误，检查改动是否满足请求。
原文查看原文说明
Behavioral guidelines to reduce common LLM coding mistakes. Use when writing, reviewing, or refactoring code to avoid overcomplication, make surgical changes, surface assumptions, and define verifiable success criteria.
实测评分 未实测
查看安装方法适用场景
- 实现前梳理前提和歧义
- 限定缺陷修复的修改范围
- 审查过度复杂的代码
- 通过测试验证代码重构
中文介绍
功能
规范AI代理编写代码、审查代码和整理现有结构时的工作方式。在实现前明确前提以及不同的理解，力求用满足请求所需的最少代码完成工作。编辑现有代码时，要求只修改必要部分，避免将范围扩大到周边格式或无关逻辑。
适用场景
适合在要求AI修改代码时，经常出现不必要的新功能或机制的情况。也适用于希望将缺陷修复或代码重构的完成条件，转化为能通过测试等方式检查的目标。可据此逐行检查改动，确认每一处修改都与请求有关。
使用示例
- “实现前先梳理前提和不明确的地方，并提出最简单的方法。”
- “编写能复现这个缺陷的测试，再只修改必要部分。”
- “重构前后都检查测试，并遵循现有的代码风格。”
注意事项
这些指引更重视谨慎，而非速度。对于非常简单的任务，是否采用应根据具体情况判断。许可证为MIT。
本介绍由 AI（OpenAI Codex）根据公开的 SKILL.md 撰写。准确的规格请查看下方原文。
文档检查
AI 根据 SKILL.md 的内容检查了需要注意的操作和使用前提。评分只依据实际运行的结果（实测对比）。
- 安全性发送数据、删除文件、执行命令等是否有说明
- A良好要求将改动限定于请求范围，未经要求不得删除原有未使用代码。
- 安装难易度所需工具和 API 密钥是否少且有说明
- A良好内容为行为指引，未要求额外工具或API密钥。
不计入评分。 由 AI（OpenAI Codex）于 2026年10月20日 评估。仅供参考，安装前请同时查看原文。
如果您认为评估有误，请申请复核
包含的文件（1）
- SKILL.md2.5 KB
SKILL.md（原文）
安装前可以查看交给 AI 代理的指令内容。
Karpathy Guidelines
Behavioral guidelines to reduce common LLM coding mistakes, derived from Andrej Karpathy's observations on LLM coding pitfalls.
Tradeoff: These guidelines bias toward caution over speed. For trivial tasks, use judgment.
1. Think Before Coding
Don't assume. Don't hide confusion. Surface tradeoffs.
Before implementing:
- State your assumptions explicitly. If uncertain, ask.
- If multiple interpretations exist, present them - don't pick silently.
- If a simpler approach exists, say so. Push back when warranted.
- If something is unclear, stop. Name what's confusing. Ask.
2. Simplicity First
Minimum code that solves the problem. Nothing speculative.
- No features beyond what was asked.
- No abstractions for single-use code.
- No "flexibility" or "configurability" that wasn't requested.
- No error handling for impossible scenarios.
- If you write 200 lines and it could be 50, rewrite it.
Ask yourself: "Would a senior engineer say this is overcomplicated?" If yes, simplify.
3. Surgical Changes
Touch only what you must. Clean up only your own mess.
When editing existing code:
- Don't "improve" adjacent code, comments, or formatting.
- Don't refactor things that aren't broken.
- Match existing style, even if you'd do it differently.
- If you notice unrelated dead code, mention it - don't delete it.
When your changes create orphans:
- Remove imports/variables/functions that YOUR changes made unused.
- Don't remove pre-existing dead code unless asked.
The test: Every changed line should trace directly to the user's request.
4. Goal-Driven Execution
Define success criteria. Loop until verified.
Transform tasks into verifiable goals:
- "Add validation" → "Write tests for invalid inputs, then make them pass"
- "Fix the bug" → "Write a test that reproduces it, then make it pass"
- "Refactor X" → "Ensure tests pass before and after"
For multi-step tasks, state a brief plan:
1. [Step] → verify: [check]
2. [Step] → verify: [check]
3. [Step] → verify: [check]
Strong success criteria let you loop independently. Weak criteria ("make it work") require constant clarification.
评价
还没有评价。欢迎分享你的使用感受。
评论
无需登录即可发表。欢迎分享使用感受、提问，或说明在哪些环境下无法运行。
还没有评论。来写第一条吧。