当 Andrej Karpathy 在社交媒体上指出大语言模型在编码任务中的典型陷阱时，他描述的现象令人深思：模型会 silently 做出错误假设而不检查，不管理自己的困惑，不寻求澄清，不呈现权衡，不在应该反对时反对。这种行为模式直接影响了 AI 编码助手的实用性与可靠性。围绕这一观察，开源社区衍生出两条截然不同的优化路径：一种是通过手动编写 CLAUDE.md 规则来约束模型行为，另一种是通过自动捕获与压缩会话上下文来增强记忆能力。本文深入分析 andrej-karpathy-skills 与 claude-mem 这两个代表性项目，探讨其工程实现差异与实际应用价值。
问题根源：LLM 编码助手的系统性缺陷
Karpathy 的核心观察揭示了当前 AI 编码助手的深层问题。在实际开发场景中，这些缺陷表现为多种具体形式：当用户要求 “添加验证” 时，模型可能直接实现一套复杂的验证逻辑，而不会先询问具体的验证规则或边界条件；当需要修改某个函数时，模型可能顺便 “优化” 相邻代码，即使这些代码与任务无关；当被要求实现一个功能时，模型倾向于构建过度抽象的架构，使用_future_扩展性理由添加当前不需要的参数和配置。这些行为模式并非偶发故障，而是模型训练目标与人类期望之间的系统性偏差。
手动规则工程与自动上下文压缩代表了两种不同的解决思路。前者试图通过预定义的显式指令来约束模型行为，相当于在模型行动之前设置 “护栏”；后者则通过增强模型的上下文感知能力，让模型在拥有更完整信息的前提下做出更好的决策。理解这两种范式的差异，对于架构师和开发者选择合适的优化方案至关重要。
andrej-karpathy-skills：手动规则工程范式
andrej-karpathy-skills 是一个仅包含单个 CLAUDE.md 文件的开源项目，其核心理念是将 Karpathy 的观察转化为可执行的编码规范。该项目定义了四项核心原则，分别针对不同的行为缺陷。
第一项原则：Think Before Coding（编码前思考）。这条规则直接回应了模型 “silent assumption” 问题。它要求模型在开始编码前显式陈述自己的假设，当存在不确定性时主动询问而非猜测，在遇到歧义时呈现多种可能的解释而非自行选择某一个，并且在感到困惑时明确指出不清楚之处而非假装理解。这不是简单的提示词技巧，而是一种根本性的行为改变 —— 将模型从 “执行者” 角色转变为 “协作伙伴” 角色。
第二项原则：Simplicity First（简单性优先）。针对模型的过度工程化倾向，该原则明确禁止实现未请求的功能、禁止为单次使用的代码创建抽象、禁止添加未被要求的 “灵活性” 或可配置性、禁止为不可能的场景添加错误处理。项目中给出了一个具体的量化标准：如果 200 行代码可以完成 50 行就能完成的工作，就应该重写。这一原则将 “简单” 从模糊的质量要求转化为可验证的工程约束。
第三项原则：Surgical Changes（外科手术式更改）。当编辑现有代码时，模型容易产生 “scope creep”（范围蔓延）—— 修改任务无关的代码、调整格式、删除被认为 “死代码” 的内容。此原则明确要求：不要 “改进” 相邻代码、注释或格式；不要重构没有破损的事物；匹配现有风格即使个人偏好不同；如果注意到不相关的死代码，只需提及而非删除。同时，该原则也划定了模型的责任边界：只有因自身更改而产生的孤儿代码（未使用的导入、变量、函数）才需要清理，事先存在的死代码不在处理范围内。
第四项原则：Goal-Driven Execution（目标驱动执行）。Karpathy 指出 “LLMs are exceptionally good at looping until they meet specific goals”。该原则将这一洞察付诸实践：不是告诉模型 “要做什么”，而是给出 “成功标准” 并观察其自主运作。具体的转换模式包括：将 “添加验证” 转化为 “编写针对无效输入的测试，然后让它们通过”；将 “修复 bug” 转化为 “编写能复现该 bug 的测试，然后让它通过”；将 “重构 X” 转化为 “确保测试在重构前后都能通过”。对于多步任务，模型被要求按照 “步骤 → 验证” 的格式规划，并在每个阶段声明可验证的检查点。
从工程实现角度，andrej-karpathy-skills 提供了两种集成方式：作为 Claude Code 插件全局生效，或作为项目级 CLAUDE.md 文件按需使用。插件方式通过 plugin marketplace add 和 plugin install 命令完成安装，适用于希望在所有项目中应用这些规则的开发者；CLAUDE.md 方式则通过 curl 命令下载并追加到项目根目录，更适合针对特定项目定制规则。这两种方式的并存体现了设计者对不同使用场景的考量：全局插件适合作为个人的默认行为准则，项目级文件则允许团队根据项目特性进行裁剪。
claude-mem：自动上下文压缩范式
与 andrej-karpathy-skills 的手工程规则不同，claude-mem 采用了一种完全不同的技术路径：通过自动捕获会话过程中的观察、生成语义摘要，并在后续会话中检索相关上下文。这意味着模型不需要预先被告知 “应该怎么做”，而是通过 “记住” 之前的操作经验来优化当前行为。
claude-mem 的技术架构由五个核心组件构成。生命周期钩子系统是整个方案的基础，它在会话的五个关键节点注入处理逻辑：SessionStart（会话开始）、UserPromptSubmit（用户提交提示）、PostToolUse（工具使用后）、Stop（停止）、SessionEnd（会话结束）。这些钩子在后台运行，自动记录模型的操作轨迹、使用的工具、产生的输出等关键信息。Worker 服务是一个运行在本地端口 37777 的 HTTP API，由 Bun 进程管理器托管，负责协调数据流并提供 Web 查看器 UI。SQLite 数据库存储会话记录、观察数据和生成的摘要，采用 FTS5 全文搜索支持高效检索。向量数据库（Chroma）提供语义搜索能力，使模型能够通过自然语言查询找到历史上相关的操作记录。mem-search 技能是面向用户的搜索接口，支持渐进式上下文披露模式。
claude-mem 的创新之处在于其三层工作流设计，在信息完整性与 token 消耗之间寻求平衡。第一层是 search 工具，返回紧凑的索引结果，每个结果仅消耗约 50-100 个 token，包含观察 ID 和基本描述。第二层是 timeline 工具，获取特定观察周围的时序上下文，帮助模型理解相关操作的历史背景。第三层是 get_observations 工具，仅针对筛选后的 ID 获取完整细节，消耗约 500-1,000 token。这种分层设计实现了约十倍的 token 节省，同时保证了关键信息的可用性。
从功能特性来看，claude-mem 提供了多项工程化能力。持久化记忆功能使上下文能够跨会话存活，解决了 Claude Code 每次启动都是全新会话的根本限制。渐进式披露机制允许按需获取信息，避免一次性加载过多上下文导致的 token 浪费。基于技能的搜索让开发者可以用自然语言查询项目历史，例如 “authentication bug” 或 “API integration”。隐私控制通过 <private> 标签排除敏感内容存储。上下文配置功能提供细粒度控制，决定哪些类型的上下文被注入到新会话中。
两种范式的工程差异对比
理解这两种方案的关键差异，需要从多个工程维度进行分析。
在优化时机方面，andrej-karpathy-skills 采用的是前摄性优化 —— 在模型产生任何输出之前通过规则约束其行为过程。这类似于在函数入口添加参数验证，虽然可能增加少量处理开销，但能有效防止错误行为的发生。claude-mem 则采用反应性优化 —— 让模型在操作后从记忆库中检索相关信息，然后在后续决策中参考这些经验。这类似于单元测试中的回归测试机制，通过历史经验来优化当前行为。
在信息来源方面，手动规则工程依赖显式知识 —— 这些知识由项目维护者预先编写，形式化为结构化的原则和子规则。自动压缩系统依赖隐式知识 —— 从实际操作中提取的模式和经验，不需要人工显式表述。前者的知识表达成本较高，但覆盖的是通用性原则；后者的知识获取成本较低，但依赖于实际运行过程中产生的数据。
在适用场景方面，andrej-karpathy-skills 更适合以下情况：项目有明确的编码规范需要遵守；团队希望建立一致的 AI 协作模式；需要预防特定类型的不良行为（如过度工程化、范围蔓延）；希望 AI 在不确定时主动询问而非自行决定。claude-mem 更适合以下情况：项目有复杂的长期上下文需求；需要 AI 记住特定项目的历史决策和实现细节；希望利用实际运行数据来优化后续交互；需要跨会话保持上下文连续性。
在资源消耗方面，CLAUDE.md 规则文件的体积通常仅有数 KB，读取成本可以忽略不计。它不引入额外的运行时依赖，也不会产生持续的后台进程。claude-mem 则需要运行 Worker 服务、维护 SQLite 和向量数据库，这些都会消耗系统资源。其优势在于一旦运行起来，能够提供的上下文信息远丰富于静态规则。
融合可能性与实践建议
这两种范式并非互斥，实际上存在融合使用的可能性。andrej-karpathy-skills 提供的四项原则可以视为 “行为准则层”，定义了模型应该遵循的基本工作方式；claude-mem 提供的记忆系统可以视为 “上下文增强层”，提供了项目特定的历史信息。两者的结合方式可以是：首先通过 CLAUDE.md 规则确保模型遵循良好的工作习惯，然后在规则框架内通过 claude-mem 检索的历史上下文来做出更明智的决策。
对于不同规模的团队和项目，推荐的实践策略也有所不同。对于小型项目或个人开发者，建议从 andrej-karpathy-skills 入手，其轻量级的特性几乎不需要任何运维成本，却能显著改善 AI 助手的输出质量。当项目复杂度提升、涉及多个模块或需要多人协作时，可以考虑引入 claude-mem 来管理项目特有的上下文信息。对于企业级应用，两者的结合使用可能是最佳实践，同时通过 CLAUDE.md 确保通用质量标准，通过记忆系统维护项目特定知识。
需要注意的是，andrej-karpathy-skills 在设计文档中明确指出，这些规则 “倾向于谨慎而非速度”。对于琐碎的任务（如简单的拼写修正、明显的一行代码修复），不应要求模型执行完整的分析 - 规划 - 验证流程。这一权衡体现了项目对工程实用性的关注 —— 过度严格的规则反而可能降低工作效率。claude-mem 也面临类似的信息过载风险，当记忆库变得庞大时，如何筛选出真正相关的上下文成为新的工程挑战。
资料来源
本文分析基于以下开源项目：andrej-karpathy-skills（https://github.com/forrestchang/andrej-karpathy-skills）提供了基于 Karpathy 观察的手动 CLAUDE.md 规则实现；claude-mem（https://github.com/thedotmack/claude-mem）提供了自动上下文捕获与压缩的系统方案。