程序员都在“养AI龙虾”，然后，其实先该养的是你的 Skill 文件“养龙虾”之所以能成为 AI 编码热梗，本质是大家开

最近大家都在说“养龙虾”，表面看是一个热梗，底层其实是在说一件更严肃的事：AI 不再只是聊天工具，而是开始进入执行层。

但很多人踩坑也踩在同一个地方：花了很多时间“养模型”，却没花时间“养自己的规则资产”。结果就是今天能跑，明天翻车；这个项目顺手，下个项目又从头来过。

说白了，决定你 AI 编码产出上限的，不只是模型能力，而是你有没有把“提示词 + 记忆 + 验收标准”沉淀成可复用资产。

一、真正该养的，不是一只“龙虾”，而是一套可复用的工作脑

“养龙虾”这个说法为什么传播快？因为它把复杂技术动作翻译成了日常语言。你不用先懂一堆术语，也能理解“养成”这件事：要喂、要训、要复盘，才能越来越顺手。

AI 编码也是一样。很多人以为自己在做“AI 提效”，实际上只是把同一个上下文反复喂了十遍。今天在 Cursor 里打一套 prompt，明天在另一个仓库里再重新讲一遍项目背景。看起来很勤奋，本质上是在原地内耗。

这就是为什么 andrej-karpathy-skills 这类项目会爆：它不是在比谁更会写一句神奇提示词，而是在做“把有效行为固化成团队可继承的文件”。当规则可见、可版本化、可迭代，AI 才会从“偶尔聪明”变成“长期稳定”。

AI 编码的第一性原理，不是让模型一次性答对，而是让系统越来越不依赖“临场发挥”。

把提示词资产化，我建议你先拆成三层，不要一上来追求“大而全”。

第一层是“任务模板层”。比如：需求澄清模板、代码评审模板、重构模板、测试补齐模板。每个模板都回答三件事：目标是什么、约束是什么、验收是什么。你会发现，很多返工并不是模型笨，而是你没有把验收条件写清楚。

第二层是“项目记忆层”。claude-mem 这类思路的价值，在于把上下文从“聊天窗口”搬进“可积累记忆”。例如：项目术语、历史决策、踩坑清单、禁改模块。这样 AI 每次进入任务时，不需要重新学习你的世界观。

第三层是“回归验证层”。每次 AI 产出都要过一轮“我要验牌”式检查：能不能跑、有没有破坏旧逻辑、是否符合团队风格。这里不要迷信全自动，关键是建立人机协同的闸门。

很多团队会卡在第二层，因为他们把“记忆”理解成了“无限追加上下文”。其实记忆不是越多越好，而是越结构化越好。你真正在养的，不是 token 消耗，而是你的交付确定性。

先看 andrej-karpathy-skills 这类实践。它给我们的启发很简单：把“你希望 AI 像谁一样工作”写进规则文件，而不是留在脑子里。比如代码风格、PR 说明格式、调试顺序、禁止操作清单。这些内容一旦落成文件，就能跨任务复用、跨成员传递。

再看 claude-mem 这一类记忆增强思路。它最实用的点，不是“记住一切”，而是“记住你下次一定还会用到的判断”。例如：

这两类能力叠加起来，才是“人格化配置”真正的含义：不是给 AI 起个名字，而是让它在你的工作流里越来越像一个靠谱同事。

你可以把它理解成：Skill 文件负责“性格边界”，记忆系统负责“经验沉淀”，而人工验收负责“最后签字”。

现在很多内容会把 AI 编码讲成“彻底替代开发者”，这件事短期内并不现实，也不应该作为团队目标。

真正可持续的路径是：让 AI 接管高重复、低歧义、可验证的部分；把高风险决策、业务取舍、上线责任留在人手里。你可以让 AI 先跑草稿、先补测试、先给重构方案，但最终合并代码的人必须承担可解释性责任。

这也是为什么我一直强调“先养 Skill 文件”。没有规则资产，你每次都在重新磨合；有了规则资产，你才可能在不同模型、不同 IDE、不同项目之间保持稳定输出。

如果你现在就想开始，我给你一个今晚能做的最小动作：

坚持一周，你会明显感觉到：AI 还是那个 AI，但你们的配合不再靠运气。