andrej-karpathy-skills：4 条原则如何把 TDD 嵌进 AI 编码-平芜编程栈

andrej-karpathy-skills：4 条原则如何把 TDD 嵌进 AI 编码

【免费下载链接】andrej-karpathy-skillsA single CLAUDE.md file to improve Claude Code behavior, derived from Andrej Karpathy's observations on LLM coding pitfalls.项目地址: https://gitcode.com/GitHub_Trending/an/andrej-karpathy-skills

你说"给这个接口写测试"，AI 回你 80 行断言、3 层抽象和一个没人要的策略模式。andrej-karpathy-skills 用一份 CLAUDE.md 写入四条行为准则，约束 LLM 编码时的假设、改动范围与验证方式，让测试驱动开发（TDD）在 AI 辅助开发实践中真正跑得起来。

项目的核心就是一个文件：CLAUDE.md。内容来自 Andrej Karpathy 对 LLM 编码陷阱的观察——"The models make wrong assumptions on your behalf and just run along with them without checking." 项目把问题拆成四条原则：Think Before Coding、Simplicity First、Surgical Changes、Goal-Driven Execution，同一份文本也以技能形式放在 skills/karpathy-guidelines/SKILL.md。这份 LLM 编码规范只有几十行，价值在于把"先想后写、写少一点、别越界、给成功标准"变成 AI 每次会话的默认行为。

🔍 把 TDD 嵌入 AI 编码的四条原则

TDD 要求"先写测试、再让它通过"，但 AI 会在每一步上跑偏：假设错了测试就白写，测试臃肿了实现跟着跑偏，改动越界后回归失败查不清原因。四条原则各自挡一道，下面按"问题 → 对应原则 → 验证方式"过一遍。

问题一：测试还没写，假设已经错了

"校验邮箱格式"这类需求最容易出事：AI 默认要处理 Unicode 邮箱、空字符串、地区规则，交回一个带配置对象的校验器，测试也全写在这些未经确认的假设上。

对应原则Think Before Coding — Don't assume. Don't hide confusion. Surface tradeoffs.，并给出明确动作："State your assumptions explicitly. If uncertain, ask."

验证方式：跑任何测试之前，先要求它列出假设和成功标准。"邮箱"的范围有歧义（空字符串算非法还是算缺失？）就该先问。测试套件建立在确认过的假设上，这是 TDD 的第一道闸。

问题二：断言写得比实现还臃肿

一个校验函数配上 15 条断言、测试夹具基类、两个"灵活"的 helper，代码评审时没人说得清哪些断言对应真实需求。

对应原则Simplicity First — Minimum code that solves the problem. Nothing speculative.自检标准很直白："Would a senior engineer say this is overcomplicated?"

验证方式：逐条审查用例，看它是否对应当前需求要求的一个行为。每个测试只验证一个行为，一次性代码不建框架。仓库的 EXAMPLES.md 里每条原则都配有"错误示范 → 修正版"的真实代码对照，值得翻一遍。

问题三：让它改一行，它顺手重排了整个文件

修一个断言失败的 bug，diff 里却混进注释改写、引号风格替换、"顺手"删除的死代码。测试套件忽然挂掉，还得花时间分辨哪些失败和本次改动有关。

对应原则Surgical Changes — Touch only what you must. Clean up only your own mess.原文给的检验标准是："Every changed line should trace directly to the user's request."

验证方式：绿色阶段的 diff 应该只包含让失败测试通过的代码。提交前可以要求它逐行说明"这行对应哪个失败测试"，说不出名字的改动一律拿掉；遇到无关死代码，让它提一句，而不是直接删。

问题四：'修好它'不是目标，是口号

"让它能跑"无法验证，AI 做到七成就停，或者反过来一路做到你拦不住。

对应原则Goal-Driven Execution — Define success criteria. Loop until verified.原文的判断是："Strong success criteria let you loop independently. Weak criteria ("make it work") require constant clarification." 这条原则正好接住 TDD 的红绿循环：指令式说法可以批量转成可验证目标——

"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]的格式给出计划，每一步自带验证点，红绿循环才能独立跑下去，不用你盯着澄清。

🧪 同一任务前后对比：给 API 调用加带超时的重试

任务固定：第三方接口偶尔超时，要求"重试 3 次，单次请求 2 秒超时，失败要能看出来"。

没有这份 TDD 工作流约束时，典型产出是 60 行以上：指数退避策略类、可配置的重试参数 dataclass、日志钩子参数，甚至同一个逻辑的装饰器版和函数版各一份；测试还额外覆盖了"可配置最大等待"这类没人要的行为。评审 20 分钟，一半内容需要逐条追问。

有了 CLAUDE.md 约束后，流程变成：先陈述假设（只对 TimeoutError / ConnectionError 重试？3 次失败后抛出还是静默？），有歧义先问；然后写测试：模拟"超时、超时、成功"的调用序列，断言第 3 次调用返回成功；最后才是最小实现。

import time def fetch_with_retry(url, timeout=2.0, attempts=3): last = None for attempt in range(attempts): try: return http.get(url, timeout=timeout) except (TimeoutError, ConnectionError) as e: last = e if attempt < attempts - 1: time.sleep(0.5 * (attempt + 1)) raise last

def test_retries_until_success(monkeypatch): calls = iter([TimeoutError(), TimeoutError(), ok_response]) monkeypatch.setattr(http, "get", lambda url, timeout: next(calls)) assert fetch_with_retry("http://api/users") is ok_response

实现 10 行，diff 不碰其他文件，测试两条：一条复现超时重试，一条验证重试耗尽后抛出。同一个任务，从"评审后大改"变成一次通过。

安装 andrej-karpathy-skills 的两种方式

插件方式（Claude Code 用户，一次安装全项目生效）：

/plugin marketplace add forrestchang/andrej-karpathy-skills /plugin install andrej-karpathy-skills@karpathy-skills

按项目放置方式：克隆仓库后把CLAUDE.md复制到项目根目录；已有项目直接追加到现有 CLAUDE.md 末尾即可。

git clone https://gitcode.com/GitHub_Trending/an/andrej-karpathy-skills

这份文件的设计就是与项目指令合并：在它下面补上自己的规则（比如"所有 API 端点必须有测试"）。使用其他工具时同理，把同一份内容放进工具读取的根指令文件即可，Cursor 的具体做法见 CURSOR.md。另注意它的取向是 caution over speed：改错别字这类琐碎任务不用走全套流程，准则针对的是非平凡工作里的返工成本。

把 CLAUDE.md 放进项目根目录，下次让 AI 写测试前，先让它把假设列出来。

创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考