Andrej Karpathy：“克劳德90%的错误来自于缺乏背景，而不是一个薄弱的模型。” 数字支持了这一点。 41%的错误率，没有CLAUDE.md.11%，有基本的4规则基线。3%，12条规则版本如下。 高级工程师决定： 编码前要三思而后行。明确陈述假设。这个模型无法读懂你的心思。 简单第一。代码最少，没有推测性抽象。“为了未来的灵活性”是您下个季度将删除的200行如何添加的。 手术改变。 只触摸你必须触摸的东西。让Claude改进相邻代码是PR爆炸的原因。 目标驱动的执行。提前定义成功标准。 没有他们，克劳德要么永远循环，要么过早停止。 该模型仅用于判断电话。分类、起草、总结、摘录。不是路由、重试、状态代码或确定性转换。如果代码可以回答，代码就会回答。 代币预算不是建议性的。每个任务4000，每个会话30000。 通过长调试的消息40，Claude正在重新建议您在消息5中拒绝的修复。 表面冲突，不要平均。代码库中的两个模式意味着选择一个。混合它们是错误被两次吞下的方式。 先读后写。导出、调用程序、共享实用程序。Claude将在它从未读取的函数旁边添加一个重复的函数。 测试验证的是意图，而不仅仅是行为。当业务逻辑发生变化时不会失败的测试是错误的。 当函数返回一个常数时，所有12个测试都可以通过。 检查每一个重要步骤。克劳德在步骤4的中断状态下完成了步骤5和6。一个小时没人注意到。 匹配代码库约定。类组件意味着不要默默地分叉到钩子。 大声失败。“已成功完成”，14%的记录被悄悄跳过，这是最糟糕的一类错误。 真正复合的是：CLAUDE.md作为跨会议的机构记忆。Eval驱动的变化不是氛围驱动的。 检查站超速。无声混合中的明显冲突。一个仓库，一个规则文件，没有例外。 你不需要更好的人工智能。你需要更好的上下文工程。 下面是完整的剧本。