一份不到 100 行的 Markdown 文件为什么能在 GitHub 上一夜爆红？从设计师视角解读 Karpathy 的四条 AI 协作纪律。
一份不到 100 行的 Markdown 文件，为什么能在 GitHub 上一夜爆红？它给设计师使用 AI 的方式带来了什么启示？
2026 年 1 月 26 日，Andrej Karpathy 在 X 上发了一条长推，记录了他过去几周高强度使用 Claude Code 的观察。推文的核心不是「AI 编程真好用」，而是一份坦率的抱怨清单——LLM agent 在写代码时会犯什么错、为什么犯、他希望它们怎么改。
第二天，开发者 Forrest Chang 把这份抱怨清单翻译成了一份可以直接投喂 Claude Code 的 CLAUDE.md，发布在 GitHub 上。短短几天，这个仓库冲上 trending 第一，目前 45.3k stars、3.7k forks。
仓库名字叫 forrestchang/andrej-karpathy-skills。
它的有趣之处在于：它几乎没有代码。整个项目的核心就是一个 Markdown 文件，里面写了四条行为准则。没有框架、没有库、没有应用——只是一份「行为约定」。
Karpathy 在推文里描述了三类典型的 LLM 编码坏习惯，Forrest 把它们原文引用在了 README 开头。
第一类：静默假设 + 拒绝澄清
The models make wrong assumptions on your behalf and just run along with them without checking. They don't manage their confusion, don't seek clarifications, don't surface inconsistencies, don't present tradeoffs, don't push back when they should.
翻译：模型会替你做错误的假设然后一路跑下去，既不管理自己的困惑，也不主动澄清、不指出不一致、不呈现权衡、该推回时不推回。
第二类：过度工程 + 抽象膨胀
They really like to overcomplicate code and APIs, bloat abstractions, don't clean up dead code... implement a bloated construction over 1000 lines when 100 would do.
翻译：它们特别喜欢把代码和 API 搞复杂，膨胀抽象，不清理死代码——100 行能解决的，非要写成 1000 行的臃肿结构。
第三类：无关副作用
They still sometimes change/remove comments and code they don't sufficiently understand as side effects, even if orthogonal to the task.
翻译：它们有时会作为副作用去改动或删除自己其实没理解的注释和代码——哪怕那些代码和任务完全不相关。
这三段话值得反复读。作为一个每天在用 Cursor 和 Claude Code 的人，我在看到这三段时，脑子里立刻浮现出过去几个月遇到的无数次翻车现场。问题从来不是 AI 不够聪明，而是它太有自信——自信到不愿意暂停、不愿意承认不确定、不愿意只做被要求做的那点事。
Forrest 把 Karpathy 的抱怨整理成了四条对应的行为准则。这张表是整个项目最精华的部分：
| 原则 | 解决的问题 |
|---|---|
| Think Before Coding | 错误假设、隐藏困惑、缺失权衡 |
| Simplicity First | 过度复杂、膨胀抽象 |
| Surgical Changes | 正交编辑、不该碰的代码 |
| Goal-Driven Execution | 通过可验证成功标准获取杠杆 |
每一条都是「病症 → 药方」的直接对应，不是泛泛的最佳实践。
Don't assume. Don't hide confusion. Surface tradeoffs.
核心指令：
Minimum code that solves the problem. Nothing speculative.
核心指令：
Touch only what you must. Clean up only your own mess.
核心指令：
Define success criteria. Loop until verified.
这一条是整份文档最有杠杆的一条。Karpathy 的原话：
LLMs are exceptionally good at looping until they meet specific goals... Don't tell it what to do, give it success criteria and watch it go.
翻译：LLM 极擅长循环直到达成特定目标——不要告诉它做什么，给它成功标准然后看着它跑。
这句话直接颠覆了传统的 prompt 写法。对比看：
| 命令式（低杠杆） | 目标驱动（高杠杆） |
|---|---|
| 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 |
多步任务要给出带验证点的简短计划：
1. [Step] → verify: [check]
2. [Step] → verify: [check]
3. [Step] → verify: [check]
这是一份写给 Claude Code 用户的纪律守则，表面上和设计师关系不大。但读到第二遍我意识到——这四条原则对 AI 辅助设计工作流的适用性，丝毫不低于对编程的适用性。
把「代码」替换成「设计稿」、「组件」、「PRD」、「Token」——每一条都成立。
让 Cursor 或 Claude 帮你生成一个「首页 Banner 组件」，它默认会给你一个带渐变背景、圆角、带 CTA 按钮的常规方案——因为它的训练数据里 90% 的 Banner 都长这样。但你心里想的可能是极简通栏、可能是视频背景、可能是品牌定制字体展示。
Karpathy 说的「它们替你做错误假设然后一路跑下去」，在设计场景里就是它按照训练数据的中位数答案给你生成了一个 80 分但和你项目无关的方案。你看完觉得「还行」然后接受了，但它其实根本没理解你的品牌上下文。
Think Before Coding 原则在设计场景的翻译：让 AI 在动手前先把假设说出来——「我理解你要的是一个偏向哪种风格的 Banner？以下三种方向哪种更接近？」这个动作看起来在减速，实际在避免后续返工。
AI 写 React 组件会过度工程，AI 做设计同样会。让它帮你做一个品牌 Logo 网格，它可能给你加上 hover 动效、loading 骨架屏、空状态、错误态、i18n 切换、响应式断点、可访问性 aria-label——你只是想看三行四列的静态展示。
对设计系统维护者来说，过度生成比生成不足更危险，因为每一个多余的变体都会污染 Token 体系和文档库。
这一条我感受最深。你大概有过类似经历：让 AI 帮你改 PRD 的某一段，它顺手把上下文的标题层级、表格格式、甚至不相关段落的措辞都「优化」了一遍。表面上看都是改进，但协作文档最怕的就是无法追溯的广域修改——因为这会让 reviewer 的心智成本暴增。
「每一行修改都应该能直接追溯到用户的请求」——把这句话贴在 Notion 写作类 skill 的头部，可以解决 70% 的协作冲突。
这是对设计师最有价值的一条。传统的 AI 设计指令都是命令式的：「帮我生成一个 Hero 区」、「帮我改一下配色」、「帮我写产品需求」。结果就是来回十几轮对话，每一轮都需要你手动判断「对不对」。
目标驱动的写法会变成：
| 命令式 | 目标驱动 |
|---|---|
| 帮我生成一个 Hero 区 | Hero 区需要满足：(1) 首屏 3 秒内吸引注意力 (2) 包含明确 CTA (3) 符合 YDS 颜色 Token (4) 支持 PC/Mobile。请先列出方案，我确认后再出图。 |
| 优化这份 PRD | 这份 PRD 应达到：(1) 问题陈述不超过 3 段 (2) 每个需求有成功度量 (3) 风险章节列出至少 3 项。请按此标准检查并列出不达标项。 |
这其实就是 PRD 和需求文档的本质——它们之所以有价值，就是因为它们是目标驱动的规约，而不是命令式的指令清单。
作为设计从业者，这个 repo 本身的走红路径值得研究。它有几个教科书级别的产品决策。
时机精准到小时级。Karpathy 推文 1 月 26 日发出，Forrest 1 月 27 日就发布。在 AI 社区，一条 Karpathy 推文的流量热度窗口可能只有 48 小时——Forrest 完美吃下了这波红利。
抽象层次刚好。不是代码库（学习成本高），不是博客（不可执行），而是一份「拿来就能用」的配置文件。这恰好匹配 Karpathy 自己提到的 idea file 模式——分享想法而非实现。
README 的信息架构是设计范本。展开看它的叙事结构：问题（三段原话引用）→ 解决方案（四条原则映射表）→ 详细展开 → 安装方式 → 关键洞察 → 生效信号 → 取舍声明。每一段都在回答读者下一步的疑问。这种结构放在 PRD 里也完全适用。
心智定位精准。把 Claude Code 定义为「自信的初级工程师」（confident junior developer），这是所有开发者共鸣的痛点。一个好的产品定位不是描述你是什么，而是激活用户已经存在的感受。
Forrest 在 README 里给了一份可观察的评估清单，这一节我认为是整个项目的「设计师含金量」最高的部分：
对设计师来说，这个思路可以迁移到任何 AI 辅助流程的评估：
作者在 README 末尾特别加了一段 Tradeoff Note：
These guidelines bias toward caution over speed. For trivial tasks (simple typo fixes, obvious one-liners), use judgment — not every change needs the full rigor.
翻译：这份规则偏向谨慎而非速度。对于琐碎任务（改错别字、明显的一行代码修改），该简就简——不是所有修改都需要走完整流程。
这种自觉的边界声明很克制，也很 Karpathy-style。任何一套纪律如果不说明它的边界，就会变成官僚主义。这也是值得在 skill 文档里学习的态度。
如果你也用 Claude Code 或 Cursor，读完这篇文章可以立刻行动。
动作一：全局注入。把这份 CLAUDE.md 下载到你的 ~/.claude/CLAUDE.md，作为所有 Claude Code 会话的默认行为基线。成本 30 秒，收益覆盖你未来所有的 AI 会话。
curl -o ~/.claude/CLAUDE.md https://raw.githubusercontent.com/forrestchang/andrej-karpathy-skills/main/CLAUDE.md
动作二：改造现有 skill。在你已有的 skill（比如 PRD writer、design system helper）头部注入 Think Before Coding 的精神。尤其是分层追问策略——本来就是反对静默假设，加上这份原则会让它更刚性。
动作三：引入评估指标。给每个你依赖 AI 辅助的工作流（设计稿生成、PRD 撰写、组件开发、文档整理）各定义 2-3 个「生效信号」。一周后回看这些指标的变化，决定是保留还是优化当前的 skill。
forrestchang/andrej-karpathy-skills 火爆的本质，不在于它提供了什么新技术，而在于它把一种原本只存在于资深从业者脑子里的隐性知识，转译成了一份任何人都能使用的显性规约。
这种「把隐性经验变成显性约定」的能力，恰好是设计师和产品经理日常在做的事——设计系统、PRD、Design Review Checklist、Component API 规范，本质上都是同一类工作。
所以读这份文档时，你会有一种奇怪的熟悉感：这不是写给开发者的，这是写给任何一个需要和 AI 协作的知识工作者的。
只是它刚好先被程序员发现了而已。