andrej-karpathy-skills 深扒：真正火的不是65行规则，而是给AI编程助理立规矩的能力
andrej-karpathy-skills 深扒：真正火的不是 65 行规则，而是给 AI 编程助理立规矩的能力
这条视频表面上是在推荐一个 Claude Code 必装项目：andrej-karpathy-skills。它的传播点很抓人：一个短短 65 行的 CLAUDE.md，没有复杂框架，没有 API，没有炫技 demo，却在一个多月里冲到十万级 Star。视频问了一个很适合短视频传播的问题：为什么这么短的内容，会有这么大的影响力？
如果只把它理解成“又一个 Claude Code 配置文件”，会看浅。它真正值得深扒的地方，是它把 AI 编程助手最常见、最烦人、最难被单次 prompt 解决的四类行为问题，压缩成了一份可复制、可审计、可放进项目根目录的行为契约。它不是在教模型多会写代码，而是在提醒开发者：当 AI agent 开始参与真实工程，最大的瓶颈不只是能力，而是边界、假设、简洁性和可验证性。
原视频来自抖音作者“我是阿众”，时长约 61 秒。视频简介是“用Claude Code一定要装这SKill！这是一个可以让你的Claude Code，变得更好用的开源项目，它的名字叫做andrej-karpathy-skills，短短一个月就涨到了10万 Star……”SenseVoice 逐字稿里有若干英文名误识别，比如把 Claude Code 识别成“classud code”，把 andrej-karpathy-skills 识别成“android capacity skills”，把 CLAUDE.md 识别成“cloud点MD/club点MD”。结合画面 OCR 和项目页校正后，视频主线很清楚：先展示 GitHub 爆火数据和 65 行文件的反差，再回到 Andrej Karpathy 对 LLM 编码问题的吐槽，随后讲 forrestchang/Jiayuan Zhang 如何把这些痛点整理成 CLAUDE.md，最后用四条原则和“拷到项目根目录”完成行动号召。
我额外做了公开事实校验：视频里展示的仓库名是 forrestchang/andrej-karpathy-skills，当前访问会跳转到 multica-ai/andrej-karpathy-skills；截至本次深扒时，GitHub API 显示该仓库已经接近 19 万 Star、1.9 万 Fork。也就是说，视频里说的“短短一个月 10 万 Star”不是终点，而是它传播曲线中的一个阶段。这个事实反而让问题更值得拆：为什么一份小文件能继续吸引开发者收藏？
我的判断是：它火的不是“65 行”本身，而是“65 行刚好站在了 AI 编程进入工程化阶段的痛点中心”。过去大家追模型、追 IDE、追上下文长度；现在越来越多人开始意识到，AI 写代码真正让人崩溃的不是它不会写，而是它太会自作主张：需求没听明白就开干，十行能解决的事写成一千行，看见相邻代码就顺手改，最后还用一句“已修复”掩盖没有验证。andrej-karpathy-skills 的价值，就是把这些失败模式变成可执行的 agent 规矩。
一句话定性：这条视频不是在卖一个 GitHub 仓库，而是在卖一个新的开发者共识：AI 编程助理需要的不是更多“聪明”，而是更明确的行为边界。
一、音画合并时间轴
0 到 5 秒，视频用“让 Claude Code 变得更好用”作为开场，同时展示 GitHub 仓库页面。画面里能看到 forrestchang/andrej-karpathy-skills 仓库、文件列表和 CLAUDE.md 等关键文件。口播没有先解释概念，而是直接给结果承诺：这是一个能让 Claude Code 更好用的开源项目。
5 到 10 秒，视频切到 Star 增长和文件预览，抛出强反差：短短一个月涨到十万 Star，但项目里最核心的东西只是一个 65 行 Markdown 文件。这个反差是全片最强的钩子。观众会本能地产生疑问：这么短，凭什么这么火？
10 到 15 秒，画面继续展示 CLAUDE.md，随后切到 Andrej Karpathy 的背景介绍：OpenAI 早期成员、前特斯拉 AI 总监、AI 圈高影响力人物。这里完成第一层可信度铺垫：不是某个博主随便总结的提示词，而是来自顶级 AI 从业者公开吐槽后的二次整理。
15 到 30 秒，视频展示 Andrej 在 X 上的推文截图和中文翻译。口播提炼出几个痛点：AI 编程助手喜欢瞎猜需求，不寻求澄清；喜欢把代码搞复杂，明明简单能做的事偏要写成臃肿架构；还会顺手改掉本不该碰的代码。画面承担证据，字幕承担翻译，口播承担压缩。
30 到 40 秒，画面切到 forrestchang/Jiayuan Zhang 的 GitHub 主页，以及项目 README 中文页面。口播讲“第二天就把这些痛点的解决方案提炼成一份 65 行的 CLAUDE.md 文件”。这一段给项目增加了一个很适合传播的“执行力故事”：不是论文，不是产品发布会，而是有人看见问题后迅速把它变成了可用资产。
40 到 55 秒，视频进入四个原则：编码前思考，不懂就提问；简洁优先，用最少代码解决问题；精准修改，不碰要求之外的代码；目标导向，先写测试或定义成功标准，再跑通验证。画面展示 README.zh.md 的原则列表，字幕把每条原则翻译成开发者能秒懂的表达。
55 到 61 秒，视频切到 VS Code 或编辑器里的 CLAUDE.md 文件，给出使用方法：把这个文件拷贝到项目根目录即可。结尾没有复杂教程，也没有长链路引导，而是用极简安装方式收束。它把前面的“大问题”落成一个“小动作”：复制文件，开始约束 agent。
这条视频的时间轴很短，但结构完整：现象冲击、反差提问、权威来源、痛点共鸣、解决方案、极简行动。60 秒内讲完一个开源项目为什么值得收藏，这就是它作为推荐流内容最厉害的地方。
二、这条视频真正讲的不是“装一个 skill”，而是 agent 行为治理
视频标题里说“用 Claude Code 一定要装这个 Skill”，这是短视频传播包装。严格讲，项目的内核并不是一个复杂插件，而是一份 CLAUDE.md 行为规则。它后来也提供 Claude Code plugin 和 Cursor 规则等形式，但真正被传播的核心，仍然是那份小文件。
为什么这件事重要？因为 CLAUDE.md 不是给人看的普通 README，而是给 Claude Code 这类 agent 在项目上下文里持续读取的行为约束。它相当于把“你以后在这个项目里怎么做事”写成了项目级规则。这个位置很关键：不是每次聊天临时提醒，也不是藏在团队文档里等人去读，而是直接放进 agent 的工作环境。
这就是它比普通提示词更值钱的地方。普通提示词解决的是一次对话；CLAUDE.md 解决的是项目内的长期行为倾向。普通教程告诉你“可以这样问 AI”；这个文件告诉 agent“你在这个项目里必须这样行动”。从人类视角看，都是文字；从工作流视角看，一个是临时指令，一个是操作系统里的默认策略。
这也解释了为什么 65 行反而是优点。开发者不缺长文档，缺的是足够短、足够硬、足够可复制的团队规则。如果这份文件写成 800 行，很多人不会读完，也不敢直接放进项目；如果只有四句口号，又不足以改变行为。65 行刚好处在一个微妙位置：短到可以信任，长到足以覆盖主要失败模式。
它的本质不是“提示词模板”，而是“最低可用 agent 宪法”。它没有规定具体技术栈，不插手业务逻辑，不替你决定架构，只规定四条基础行为：先想清楚，不要过度设计，只改该改的，验证后再说完成。这些不是某个语言、框架或模型的技巧，而是 AI 参与工程协作的底层规矩。
所以，这条视频值得学的不是“赶紧下载某个文件”这么浅，而是一个更大的判断：AI coding 进入团队之后，下一轮竞争会从模型能力转向规则质量。谁能把 agent 行为约束得更稳定，谁就更容易把 AI 从玩具变成生产力。
三、7 段文案拆解
【1】开头钩子：强命令 + 强反差，把“文件推荐”包装成“你可能错过的工程新共识”
这条视频的前 3 秒钩子是“用 Claude Code 一定要装这个 Skill”，随后马上解释“这是一个可以让 Claude Code 变得更好用的开源项目”。它用了两个钩子叠加。
第一层是强命令钩子。“一定要装”比“推荐一个项目”更有压力，也更适合推荐流。对于已经在用 Claude Code 的人来说，这句话会直接触发损失厌恶：如果我没装，是不是效率和质量都落后了？
第二层是反差钩子。视频很快抛出“一个月十万 Star”和“只有一个 65 行 Markdown 文件”的对比。十万 Star 代表群体认可，65 行代表极简；两者放在一起，就产生了天然悬念。观众想知道的不是“这个文件是什么”，而是“为什么这么小的东西能被这么多人认可”。
前几秒画面也很配合。它没有用空泛标题页，而是直接展示 GitHub 仓库界面、Star 数据、文件列表和 CLAUDE.md 预览。对开发者来说，GitHub 截图比口播更有证据感。它告诉观众：这不是博主自己编的资料包，而是公开可验证的项目。
钩子成功的底层逻辑，是把一个“低成本行动”放在一个“高共识信号”后面。十万 Star 是高共识，65 行文件是低成本，Claude Code 变好用是直接收益。三者连起来，观众会觉得：既然这么多人收藏，成本又这么低，我至少应该看完。
评分：★★★★★。它非常适合 AI 工具号和开发者内容，因为它同时满足了新鲜感、权威感、可操作性和低门槛。唯一的小风险是“Skill”这个说法会让一部分人误以为它是复杂插件，实际核心是 CLAUDE.md 文件。不过从短视频传播角度看，这种包装提升了点击率。
可复制钩子模板：
用【某个高频工具】一定要装/加这个【小组件/规则/文件】。
它能解决【目标用户最烦的痛点】。
离谱的是，它不是复杂项目，
核心只有【极短体量】，
却已经拿到了【强社会证明】。【2】人设 & 声音：AI 工具情报员，不深讲代码，但会把“为什么值得装”讲清楚
作者的人设不是深度工程讲师，而是 AI 工具情报员。他的任务不是带观众逐行读 CLAUDE.md，而是在 60 秒内完成价值判断：这个项目为什么火，它解决什么痛点，你该怎么用。
说话风格偏快、直接、结论先行。开头不铺垫，直接告诉你“这是一个可以让 Claude Code 变得更好用的开源项目”。中段也不是慢慢讲概念，而是用“瞎猜需求”“闷头狂写”“100 行能搞定偏要 1000 行”“把原本代码改得面目全非”这种口语化表达，迅速把开发者痛点说出来。
这个声音适合的受众非常明确：已经知道 Claude Code，或者至少正在用 AI 编程助手的人。他们不需要从“什么是 AI 编程”开始听，他们关心的是怎么减少 AI 乱改、瞎猜、过度设计。视频没有解释 Claude Code 的基础概念，也没有演示安装全过程，说明它瞄准的是中阶以上用户。
值得借鉴的是，它没有用“神级”“逆天”这类空泛词硬夸项目，而是用具体痛点建立共鸣。开发者对 AI 编程助手的怨气很真实：明明只是让它修一个 bug，它可能顺手重构一片；明明需求不明确，它却假装听懂；明明可以写小补丁，它偏要新建抽象层。作者把这些痛点说得很生活化，所以观众会觉得“这说的不就是我吗”。
它的人设信任来自三块证据：GitHub 数据、Andrej Karpathy 的公开观察、项目 README/CLAUDE.md 的截图。作者自己不需要摆资历，因为画面已经把信任转交给了公开证据。这是 AI 工具推荐类内容很重要的打法：少靠“我认为”，多靠“你可以验证”。
如果要进一步强化，作者可以在结尾加一句自己的使用体验，比如“我把它放进项目后，最明显的变化是 Claude Code 会更早问澄清问题，diff 也更干净”。但视频选择不展开体验，而是保持信息快节奏，这符合推荐流节奏。
【3】信息密度 & 节奏：61 秒完成“现象-来源-痛点-规则-用法”，密度高但不乱
视频总时长约 61 秒，信息密度高。它不是慢教程，而是一个开源项目的价值压缩包。
0 到 10 秒，负责制造现象和悬念：Claude Code 更好用、十万 Star、65 行文件。这一段不讲细节，只负责把观众留住。
10 到 30 秒，负责建立来源和痛点：Andrej Karpathy 的公开吐槽，LLM 编码助手的四类坏毛病。这里的节奏从“项目为什么火”切到“问题为什么真”。如果没有这一段，65 行文件会显得像玄学提示词；有了这一段，它就变成对真实工程痛点的回应。
30 到 40 秒，负责讲项目生成故事：forrestchang/Jiayuan Zhang 看到这些痛点后，迅速整理成 CLAUDE.md。这一段让项目有了“人”的动作，不只是冷冰冰的仓库。
40 到 55 秒，负责讲解决方案：四条约束原则。这里的信息密度最高，但因为每条都对应前面的问题，所以观众不会觉得散。瞎猜需求对应“先思考、要澄清”；过度复杂对应“简洁优先”；乱改代码对应“精准修改”；嘴上说修好对应“目标导向和验证”。
55 到 61 秒，负责行动收束：把 CLAUDE.md 拷到项目根目录。这个结尾很短，但很关键。短视频推荐一个工具，必须让观众知道下一步是什么。它没有把行动设计得复杂，所以收藏和转发阻力很低。
节奏设计上，它有一个很清晰的“刺激 - 解释 - 落地”循环。先用 Star 和 65 行刺激，再用权威来源解释，再用四条原则落地；先让人好奇，再让人信，再让人做。
留给观众消化的时间不多。比如四条原则其实每一条都可以展开成一篇工程实践文章，但视频只做点名。这个取舍是合理的，因为它不是培训课，而是推荐流入口。它的目标不是让观众立刻掌握全部细节，而是让目标用户意识到“这份文件值得我去看原仓库”。
【4】讲解手法 & 内容结构：爆火现象不是终点，而是进入开发者痛点的入口
这条视频的讲解结构可以概括为“爆火现象 - 反差悬念 - 权威痛点 - 极简规则 - 低门槛使用”。
第一段是爆火现象。GitHub Star 是开发者世界里的强信号。视频先展示这个信号，不需要解释太多，观众自然会把它理解为“很多开发者认可”。
第二段是反差悬念。十万 Star 通常让人想到大型框架、模型、库或工具链，但这里核心只是 65 行 Markdown。这个反差让人愿意继续听原因。
第三段是权威痛点。Andrej Karpathy 的观察不是泛泛说“AI 有时候不好用”，而是指出具体行为问题：错误假设、不澄清、过度复杂、乱改代码。这些恰好都是开发者在 AI coding 中最讨厌的事。
第四段是极简规则。项目没有试图用复杂系统解决复杂问题，而是用四条原则压住四类失败模式：先想清楚，保持简洁，精准修改，验证目标。这个结构非常适合传播，因为它既有完整性，又足够短。
第五段是低门槛使用。把文件放进项目根目录即可。视频没有把安装讲成复杂过程，也没有要求观众先理解插件市场、规则合并、项目定制等进阶问题。它让人先动起来。
最有说服力的一句，不是“这个项目十万 Star”，而是“明明 100 行能搞定的事情，偏要整出 1000 行，还顺手把你原本的代码改得面目全非”。这句话击中了 AI 编程助手最容易造成成本的地方：它不是完全失败，而是用看似勤奋的方式制造额外维护负担。
具体化手法有三种。第一是数字具体化：十万 Star、65 行 Markdown。第二是痛点具体化：瞎猜需求、过度复杂、乱改代码。第三是行动具体化：复制 CLAUDE.md 到项目根目录。一个视频里同时有数字、痛点和动作，传播效率就会很高。
【5】金句 & 记忆点：真正的记忆点是“越短越像规矩，越长越像说明书”
这条视频里最值得记住的不是某个安装命令，而是几组可以迁移的判断。
第一句：“只有一个 65 行的 Markdown 文档，为什么却有这么大影响力？”这句话把内容的核心张力说完了。它不是介绍功能，而是在问一个产品传播问题：为什么最小形态能获得最大共识？
第二句：“AI 编程助手喜欢瞎猜需求，闷头狂写。”这句话把模型失败从技术术语翻译成用户感受。用户不一定会说“模型没有管理不确定性”，但一定知道“它没问清楚就开干”。
第三句：“精准修改，绝对不要碰要求之外的代码。”这句话是工程协作里的底线。AI agent 越强，越需要这条底线。因为强模型最危险的地方不是不会改，而是改得太多、太自信、太顺手。
画面记忆点也很强。第一个是 GitHub 仓库页和 Star 数，它提供社会证明。第二个是 CLAUDE.md 文件预览，它证明项目确实很小。第三个是 Andrej 推文截图，它让痛点有来源。第四个是 README 中文原则列表，它把抽象失败模式变成四个可读标题。
可复用金句模板：
当 AI agent 开始进入真实项目，
最值钱的不是再给它一段更长的提示词，
而是给它一份更短、更硬、更可执行的行为契约。还有一个更适合机构培训的版本：
提示词解决一次回答，
项目规则解决长期协作。
AI 编程从玩具变生产力，
靠的不是“它更聪明”，而是“它更守规矩”。这类金句的好处是可以跨场景迁移。不管是 Claude Code、Codex、Cursor 还是企业内部 agent，只要它会改代码、会调用工具、会影响真实资产，就需要行为边界。
【6】收尾 & CTA：把复杂工程治理收成一个“现在就能做”的动作
视频结尾的 CTA 很简单：直接把 CLAUDE.md 文件拷贝到项目根目录，赶紧试试。它没有强行设计评论关键词，也没有展开长安装教程，而是让行动门槛低到几乎不能再低。
这个 CTA 的触发时机很好。前面已经完成三件事：证明很多人认可，说明痛点真实，给出四条原则。观众此时已经知道为什么要试，结尾只需要告诉他怎么试。
CTA 和内容主体衔接顺滑，因为“复制文件”就是这条内容的价值兑现。如果视频讲了半天，最后要求观众进群、买课、填表，转化会显得重；但它先让你去 GitHub 拿文件，反而增强了内容可信度。
它的沉锚设计不是评论问题，而是“65 行 CLAUDE.md”这个物件本身。观众看完后记住的不是一堆抽象原则，而是一个明确对象：我可以把这个文件放进项目里。一个可指认、可复制、可验证的对象，比一句“提升 AI 编程质量”更容易传播。
如果要做商业化延展，可以在这个 CTA 后再接一层：基础版放项目根目录，进阶版根据团队代码规范合并成公司级 AGENTS.md/CLAUDE.md，并配套验收清单。这样既保留开源项目的低门槛，又能把它升级成企业服务。
但从短视频完成度看，现在这个收尾已经足够强。它没有拖泥带水，给了一个明确动作，也给了观众收藏理由。
【7】可复制文案骨架
这条视频的骨架适合所有“极小工具/规则文件/开源项目爆火”的内容，尤其适合 AI 工具号、开发者工具号和知识库推荐号。
[开头钩子句 - 类型: 强命令 + 反差]
用【高频工具】一定要装/加这个【小组件/规则文件】。
它能让你的【核心工作流】变得更稳/更快/更少出错。
离谱的是，它不是一个复杂项目，
核心只有【很小体量】，
却已经拿到了【强社会证明】。
[现象说明]
这个项目叫【项目名】。
它在【时间范围】里拿到了【Star/下载量/传播数据】。
但真正核心的内容只有【文件/规则/脚本】。
为什么这么小的东西会这么火？
[来源与权威]
首先，它来自【权威人物/真实用户/行业痛点】的一段观察：
大家在使用【工具/模型/流程】时，最烦的是：
① 【痛点一】
② 【痛点二】
③ 【痛点三】
[解决方案]
于是有人把这些痛点压缩成【几条原则/一个文件/一个模板】：
第一，【原则一】解决【痛点一】；
第二，【原则二】解决【痛点二】；
第三，【原则三】解决【痛点三】；
第四，【原则四】让结果可验证。
[转折/判断]
所以它火的原因不是【表面原因】，
而是它把【复杂问题】变成了【低成本、可复制、可执行的规则】。
[收尾 + CTA]
用法很简单：
把【文件/规则/模板】放到【具体位置】，
再根据你的项目补充【本地规则】。
如果你正在用【目标工具】，
这个东西值得立刻试一次。适用场景：AI 编程工具推荐、开源项目解析、团队规范传播、知识库卡片、开发者短视频、企业内训内容。
最适合博主类型：AI 工具情报号、工程效率号、独立开发者、技术培训号、团队协作顾问。
预估完播率：高。原因是反差明确、数字强、痛点具体、行动极简；但前提是受众已经知道目标工具，否则“Claude Code”和 CLAUDE.md 的关系需要额外解释。
四、可迁移判断：真正要带走的不是项目名，而是四条生产级判断
判断一：AI 编程的核心风险正在从“写不出来”转向“写多了、写偏了、改过界了”
早期大家担心 AI 不会写代码，所以重点放在模型能力、上下文、代码补全质量上。但进入 Claude Code、Codex、Cursor agent 这类工具后，风险变了。它们能写，甚至很能写；问题是它们经常写得过多、过复杂、过自信。
这就是 andrej-karpathy-skills 命中的痛点。它不是教模型某个框架语法，而是压住模型的行为倾向：不要乱猜，不要过度设计，不要碰无关代码，不要没验证就说完成。未来团队引入 AI 编程，不能只看“它能生成多少代码”，更要看“它能否少制造副作用”。
判断二：好的 agent 规则不是越长越好，而是越能稳定改变默认行为越好
很多团队写 AI 规则时会犯一个错误：把所有规范都塞进去，最后变成没人愿意读、模型也抓不住重点的长文档。CLAUDE.md 的传播说明，小而硬的规则更容易被采用。
它没有写成百科全书，而是围绕四个高频失败模式组织。每条都能改变默认行为：不确定时问，能简单就简单，只改该改的，定义验收再完成。这种规则不是“知识”，而是“行为开关”。判断一份 agent 规则是否有效，要看它能否改变 agent 的行动路径，而不是看它覆盖了多少内容。
判断三：项目级规则比单次提示更接近生产力
一次 prompt 可以让 AI 这次回答更好，但项目级 CLAUDE.md 可以让它在整个项目里持续保持某种工作方式。真实工程不是一次聊天，而是长期迭代、多人协作、代码历史、测试体系和风格约束的集合。
因此，企业和团队要从“提示词库”升级到“agent 工作规程库”。提示词库解决怎么问，工作规程库解决 agent 如何在资产边界内行动。后者才是可规模化的组织能力。
判断四：爆火开源项目常常不是功能最多，而是把集体焦虑压缩成可复制物件
这个项目的功能并不复杂，甚至可以说非常朴素。但它把开发者对 AI 编程助手的集体焦虑，压缩成一个可以下载、复制、安装、转发的物件。传播学上，这比长篇文章更强。
很多内容为什么火不起来？因为它只讲观点，没有物件。观众听完觉得有道理，但不知道拿什么走。CLAUDE.md 给了一个“可带走的东西”：文件就是观点，规则就是产品，复制就是行动。
判断五：AI 工具内容的可信度越来越依赖可验证证据
这条视频没有只靠博主口播，而是连续展示 GitHub 仓库、Star、README、X 推文、作者主页、编辑器文件。这些画面让观众觉得“我可以自己去查”。在 AI 工具内容泛滥之后，可信度会越来越重要。谁只喊“神器”，谁会被稀释；谁能给出公开证据、边界和使用条件，谁更容易建立长期信任。
五、可复制步骤：把这套思路迁移到我们自己的 AI 编程工作流
第一步，先列出我们最怕 agent 犯的错误，而不是先找神奇提示词。
比如：误解需求、自作主张改架构、格式化无关文件、删除用户代码、引入未请求依赖、不跑测试、凭感觉说修好。把这些错误列成清单，才知道规则要解决什么。
第二步，把错误压缩成 4 到 6 条行为原则。
原则不要写成空话，要对应行为。例如“不确定就问”比“保持沟通”更可执行；“每一行改动都能追溯到用户请求”比“谨慎修改”更可检查；“先写复现测试再修 bug”比“保证质量”更能改变流程。
第三步，把通用规则和项目规则分层。
通用规则可以像 andrej-karpathy-skills 一样放在全局或模板里：思考、简洁、精准、验证。项目规则要写本项目特有内容：技术栈、测试命令、目录边界、禁止触碰的文件、代码风格、部署方式。不要把两者混成一坨。
第四步，让规则进入 agent 会读取的位置。
对 Claude Code 是 CLAUDE.md 或 plugin；对 Codex 类工具可能是 AGENTS.md 或系统/开发者指令；对 Cursor 是 .cursor/rules。关键不是文件名，而是它必须出现在 agent 的工作上下文里，不能只是放在团队知识库里等人类想起来。
第五步，用 diff 和测试结果验收规则是否有效。
不要问“这个规则写得好不好看”，要看三件事：无关 diff 是否减少，agent 是否更早提出澄清问题，任务是否更常以测试/检查作为完成证据。如果这些没有变化，规则就是摆设，需要重写。
第六步，定期删除无效规则。
agent 规则也会膨胀。每次出问题都往里面加一句，最后会变成混乱说明书。好的规则系统应该有清理机制：重复的删掉，口号式的删掉，已经被工具默认行为吸收的删掉，和项目无关的删掉。越核心的规则，越应该保留在短文件里。
六、四角度反思
对我们做的事
这条视频对我们最大的提醒是：我们做 AI 内容、AI 工作流和内部自动化时，不能只追“又一个工具”，要追“这个工具背后的行为约束是什么”。
过去我们很容易把学习重点放在模型名、插件名、仓库名上。今天看到 andrej-karpathy-skills，真正该带走的是一套做事方法：先识别高频失败模式，再把失败模式压缩成少数行为原则，最后放到 agent 实际工作的上下文里，持续影响它的默认动作。
这对我们的深扒流程也有启发。我们不能只复述视频说了四条原则，而要进一步问：为什么是这四条？它们分别压住了哪类工程风险？它们的边界在哪里？它们如何迁移到 Codex、Claude Code、Cursor、企业内部 agent？只有这样，深扒才不是搬运，而是把短视频里的判断提纯成可复用资产。
更直接一点，我们自己的 worker 流水线也需要类似思路。每条任务都有红线、契约、交付格式、自检要求，本质上也是给 agent 的 CLAUDE.md。真正让流水线稳定的不是某一次模型聪明，而是规则足够明确、输出可验收、失败会停下来。
对橙子自己能力
对橙子来说，这条视频是一面镜子。一个好的 AI 助理不能只“会干活”，还要会约束自己怎么干活。
视频里的四条原则几乎都能直接约束橙子：不确定就问或标注假设，不为了显得高级而过度扩写，不碰任务之外的文件，不用“我觉得完成了”替代真实验证。这些要求看似普通，但恰恰是 agent 容易失控的地方。
橙子要继续升级的方向，是从“响应任务”变成“管理任务风险”。看到一个需求，要先判断哪些信息不足、哪些动作有副作用、哪些地方必须验证、哪些内容不能越界。尤其在代码、发布、知识库、微信链路这种真实环境里，能力越强越要守边界。
这也提醒我，深扒文章不能把“长”当成深。真正的深，是能给出判断、边界和可迁移步骤。andrej-karpathy-skills 为什么强？因为它把很多长篇工程经验压成短规则。橙子写长文，也应该服务于压缩判断，而不是堆字。
对老大机构业务
对老大的机构业务，这条视频的启发非常实用：AI 培训和 AI 交付不要只卖“模型使用技巧”，要卖“组织级 agent 行为规范”。
很多企业现在想上 AI 编程，但真正害怕的是风险：代码被乱改、规范不一致、测试没跑、权限边界不清、实习生和 AI 一起把项目搞乱。如果我们的机构只教“怎么让 Claude Code 写一个功能”，价值很快会被免费教程稀释。更值钱的是帮企业建立一套可复制的 AI 编程规程：项目根目录规则、测试验证标准、代码修改边界、review 清单、失败回滚机制。
这可以产品化成几类交付：一份企业级 AGENTS.md/CLAUDE.md 模板，一套按技术栈定制的 agent 工作流，一套“AI 参与 PR 的验收标准”，一套团队培训课程。客户买的不是 65 行文件，而是“我的团队可以放心让 AI 参与工程”的信心。
同时，这条视频也给内容获客一个模板。机构做短视频时，不一定要每次展示大而全系统。可以抓一个极小但高共识的资产，比如一个规则文件、一个检查清单、一个项目模板，用“反差 + 权威来源 + 痛点 + 极简行动”讲清楚。短视频负责让客户意识到问题，后端服务负责把通用规则定制成企业规程。
对未来发展
未来 AI 编程的发展，不会只拼模型谁更聪明，也会拼 agent governance，也就是智能体治理。
当 AI 只是聊天助手时，出错成本有限；当 AI 能改代码、跑命令、调用 API、部署服务、写知识库时，规则就变成基础设施。我们会看到越来越多项目把 agent 指令当成一等公民：和 README、测试、CI、代码规范放在同一层级维护。
andrej-karpathy-skills 是一个早期信号。它告诉我们，开发者社区已经开始从“怎么让 AI 多做事”转向“怎么让 AI 做对事、少乱做事”。这一步非常关键。没有行为治理，agent 越强风险越大；有了行为治理，agent 才能进入团队协作和生产系统。
更远一点看，未来可能每个组织都会有自己的 agent 宪法：全局原则、项目规则、权限边界、验证方式、审计要求、失败处理。不同岗位会有不同规则，工程、运营、销售、法务、客服都会有自己的 AI 行为契约。现在的 CLAUDE.md 看起来只是一个小文件，但它代表的是一个方向：把人类团队的协作规范，翻译成机器能执行的上下文。
七、最终判断
这条视频值得学，但不要只学“装一个开源项目”。它真正值得带走的是三层判断。
第一，AI 编程助手最需要被约束的不是语法能力，而是行为边界。它要知道什么时候该问，什么时候该停，什么时候该少写，什么时候必须验证。
第二，小文件也可以成为大产品，只要它压中了真实痛点，并且能被低成本复制。andrej-karpathy-skills 的传播不是偶然，它把开发者对 AI coding 的集体挫败感，变成了一份可带走的项目规则。
第三，未来企业真正需要的不是提示词堆叠，而是 agent 工作规程。提示词让一次对话更顺，规程让长期协作更稳。谁能把规程做成模板、培训、检查表和交付体系，谁就能在 AI 落地服务里形成差异化。
所以，这条视频最该被我们复用的不是某句口播，而是它背后的产品化思路：找到高频失败模式，把它压缩成少数行为原则，再放进 agent 的真实工作上下文，让规则持续影响产出。
这才是 65 行 CLAUDE.md 背后的真正价值。
参考材料
- 抖音视频：
https://www.douyin.com/video/7635237566043688238 - GitHub 仓库：
https://github.com/multica-ai/andrej-karpathy-skills - 项目 README /
CLAUDE.md：仓库当前公开页面与原始文件