用 AI 编程工具时，开发者常见的问题不是模型不会写代码，而是它写得太多、太复杂。掘金作者近期实测了一套基于 Andrej Karpathy 观察整理的 CLAUDE.md 规则，将其放入项目根目录后，可让 Claude Code 在启动时先读取行为约束，从而减少过度设计、无关修改和抽象膨胀。实测显示，同样一个分页查询需求，AI 生成代码从 380 行、12 个文件，降至 75 行、2 个文件。
从 Karpathy 吐槽到 65 行规则
事件的起点来自 Andrej Karpathy 在 X 上发布的长文观察。他指出，大模型在编程场景中经常替开发者做出错误假设，遇到不确定的地方不澄清、不暴露矛盾、不呈现权衡；同时，模型倾向于把简单功能复杂化，喜欢增加抽象层、扩大接口设计，甚至留下未清理的死代码；有时还会修改或删除它并未充分理解的注释和代码。
GitHub 上的 andrej-karpathy-skills 仓库将这些观察提炼成一份 65 行的 CLAUDE.md 文件，目前 star 数约 20 万。其核心思路不是教 AI 写某类代码，而是给 AI 设定编程行为边界，让它每次启动前先读取规则，再进入项目任务。
- Think Before Coding：不要假设，遇到歧义要提出，不要隐藏困惑
- Simplicity First：只写解决问题所需的最小代码，不做未被要求的功能
- Surgical Changes：只修改必要部分，不要顺手优化无关代码
- Goal-Driven Execution：把任务转化为可验证目标，通过测试确认完成
实测对比：从抽象工厂到 75 行实现
作者在一个约 3 万行代码的 TypeScript 项目中进行了对比测试。未安装 CLAUDE.md 前，他让 Claude Code 实现一个带分页的列表查询接口。模型返回了 PaginationParams 泛型接口、PaginatedResult 返回类型、BaseRepository 抽象类和业务代码，总计 380 行，并涉及 12 个文件，其中 8 个文件属于它自行判断需要新增的“基础设施”代码。
加入规则后，同样的需求下，Claude Code 先询问分页参数应走 query string 还是 body，以及项目中是否有已有分页实现。作者回答后，模型最终给出 75 行代码，只修改 controller 和 service 两个文件，风格也贴合现有项目，没有额外抽象类和通用框架。
作者认为，规则最直接的效果是降低返工成本。过去开发者需要花费大量时间审查 AI 顺手修改的格式、注释和变量名，现在 diff 更集中，无关改动明显减少。
规则不是万能，还需要项目化补丁
使用一周后，作者发现 CLAUDE.md 仍无法覆盖真实项目中的所有问题。例如在依赖选择上，模型有时为了保持“最小实现”，宁愿手写 200 行 parser，也不愿引入成熟依赖；即使同意安装依赖，也可能选择下载量很低的包。为此，作者追加了依赖规则，要求在编写 parser、converter 或 formatter 前，优先检查是否存在维护良好、体积小于 50KB、周下载量超过 10K 的 npm 包。
测试策略也需要调整。规则中的目标驱动执行强调先写测试，但部分外部 API 集成逻辑测试成本较高。作者因此补充了更务实的测试边界：业务逻辑、历史 edge case 和高调试成本模块需要测试；简单数据映射、第三方库封装和 UI 布局则可跳过或由其他工具覆盖。
AI 编程进入规则工程阶段
这类项目的走红，说明 AI 编程工具的关注点正在从“能不能生成代码”转向“如何约束生成行为”。类似项目 ponytail 也获得了较高关注，其思路是让 AI agent 像资深工程师一样谨慎决策，先判断功能是否存在必要，再检查现有代码、标准库和最小实现路径。
对开发者而言，CLAUDE.md 一类规则的价值不在于让模型变得更聪明，而是通过明确边界降低沟通成本和审查成本。它本质上是一种项目级 prompt engineering，需要根据技术栈、团队规范和任务类型持续调整。随着 AI 编程工具进入更多真实工程场景，规则文件可能成为仓库中的标准配置之一。
原创文章，作者：点点，如若转载，请注明出处：https://www.dian8dian.com/65-xing-claude-md-gui-ze-shi-ce-rang-claude-code-shao-xie
