网站语言,湛江市国外网站建设报价,邢台做网站,o2o网站开发教程Andrej Karpathy Skills：给 Claude Code 加四条行为约束 发布日期：2026-05-02发现了一个最近热度很高的仓库： andrej-karpathy-skills 129k star 它做的事情很直接：把 Andrej Karpathy 对 LLM 编码常见问题的观察… Andrej Karpathy Skills：给 Claude Code 加四条行为约束 发布日期：2026-05-02发现了一个最近热度很高的仓库： andrej-karpathy-skills 129k star 它做的事情很直接：把 Andrej Karpathy 对 LLM 编码常见问题的观察整理成 Claude Code 的行为约束，落成一份 CLAUDE.md，或者一个 skill。 这哥们从特斯拉跳槽到 OpenAI ,这几天又跳槽到了 Anthropic 这些问题很多人都见过：模型会替你做错误假设 自己困惑了也不说 明明应该先问一句，却直接开始写 很喜欢把简单问题做复杂 会顺手改掉它并不理解的旁边代码这份仓库就是把这些常见问题先收进一组明确的行为规则里，只有四条规则。 四条规则分别在处理什么问题 对应关系很清楚：Think Before Coding：减少错误假设和隐藏的困惑 Simplicity First：减少过度设计和膨胀抽象 Surgical Changes：减少无关改动和“顺手优化” Goal-Driven Execution：减少目标模糊和无法验证的任务这也解释了为什么这个仓库虽然很小，但很多人装完以后会觉得 Claude Code 的“手感”变了。 核心只有四条规则 README 不复杂，核心就是四条原则：Think Before Coding Simplicity First Surgical Changes Goal-Driven Execution这四条讲的是 agent 的行为方式，不是代码风格。 第一条：先想清楚，再开始写 Think Before Coding 对应的是一种很常见的情况：LLM 很容易先做一个假设，然后沿着这个假设一路往下跑。 仓库里给出的要求包括：把假设说出来 有歧义时，不要自己默默选一个 如果有更简单的路，就主动指出来 真有困惑时，停下来问这条规则放到 coding agent 里很重要。很多返工，往往出在前面这几步：一开始就理解错了 需求边界没有说清 技术路线默认选错了一旦起步错了，后面代码写得越快，返工也越大。 第二条：简单优先 Simplicity First 对应的是另一类问题：模型很容易过度设计。 仓库里写得很直接：不要加没被要求的功能 不要为一次性代码抽象一层 不要为了“灵活性”提前做配置 不要为不可能发生的场景补一堆错误处理这条规则很适合日常用 Claude Code 的场景。很多时候最烦的，是它写得太多：多一层 abstraction 多一个 config 多一套并不必要的 wrapper 多一段以后没人敢删的“通用逻辑”功能做出来了，代码库却更重了。 第三条：只改你该改的 Surgical Changes 对应的是“顺手改了一堆没让它改的东西”。 仓库里要求得很细：不要顺手优化旁边的代码 不要改没坏的东西 不要顺手重写注释和格式 遇到无关死代码，可以提一下，但先别删它唯一鼓励清理的是：你的改动直接导致没用了的 import 你的改动直接导致没用了的变量 你的改动直接导致没用了的函数这条很像 code review 的一条基本原则： 每一行 diff 都应该能追溯回当前这个需求。 对 Claude Code 来说，这一点尤其重要，因为它太容易“顺手帮你一起改了”。人类工程师看到这种提交，通常第一反应都是：你为什么动这里？ 这个跟需求有什么关系？ 你怎么证明你没把别的东西弄坏？第四条：不要只给命令，要给成功条件 Goal-Driven Execution 是这套规则里最有用的一条。 README 把问题讲得很清楚： 不要只给一句：add validation fix the bug refactor X这种话对模型来说太模糊了。 更合适的写法，是把任务改成一个可验证的目标，比如：给非法输入写测试，然后让测试通过 先写一个能复现 bug 的测试，再修到通过 重构前后测试都必须通过两者的区别在于：前者是命令式任务 后者是带校验标准的目标这里有一句话写得很直接：Don't tell it what to do, give it success criteria and watch it go.这很像写给 coding agent 的工作单：先把事情交代清楚 再把“做到什么算完成”写清楚成功标准清楚以后，模型更容易自己循环下去。