编者按:当「AI 写代码」逐渐成为行业共识时,真正改变生产力的,并不是模型本身,而是你如何为模型设定规则、组织流程,并将其嵌入一套可持续运行的系统之中。
从一个简单的 CLAUDE.md 文件出发,到多 agent 协同,再到自动化的开发循环,这套方法将开发过程从「人与 AI 的对话」,转化为「对一支 AI 工程团队的管理」。在这个过程中,错误被前置约束,流程被结构化,代码生成、测试、审查逐步脱离人工执行,转而由系统接管。
更值得注意的是,文章也揭示了一个被忽视的细节:在长上下文与复杂系统中,模型行为并非完全可控。无论是隐藏的 token 消耗,还是指令被稀释,都会在无形中影响输出质量。这使得「如何管理 AI」,而不仅仅是「如何使用 AI」,成为新的核心能力。
此时,开发者不再以编码为中心,而是围绕规则设计、流程调度与结果校验展开工作。那些率先完成这一步的人,已经开始从「亲自做事」,转向「让系统替自己做事」。
以下为原文:
一位拥有 11 年经验的 Google 工程师,借助 Claude Code 和一个简单的 .NET 应用,将自己 80% 的工作实现了自动化。
如今,他每天只需工作 2–3 小时,而不是原来的 8 小时,其余时间基本处于「放松」状态,由系统自行运转,并为他带来每月 2.8 万美元的被动收入。
他所掌握的,正是你尚未了解的那一套方法。
Part 1—按照 Karpathy 原则编写 CLAUDE.md
Andrej Karpathy——全球最具影响力的 AI 研究者之一——曾系统总结了大语言模型在编写代码时最常见的错误:过度设计、忽视已有模式,以及引入没人要求的额外依赖。
有人将这些观察总结,整理成一个统一的 CLAUDE.md 文件。
结果是,这个项目在一周内在 GitHub 上获得了 1.5 万颗星,某种意义上可以说,有 1.5 万人因此改变了自己的工作方式。
其核心思路其实很简单:如果错误是可预期的,那就可以通过明确的指令来提前避免。只需在代码仓库中放置一个 markdown 文件,就能为 Claude Code 提供一整套结构化的行为规则,从而统一整个项目中的决策与执行方式。
这个文件内部,主要包含四个核心原则:
·先思考,再编码 → 避免错误假设与被忽略的权衡
·简单优先 → 避免过度设计和臃肿抽象
·外科手术式修改 → 避免改动那些没人要求修改的代码
·目标导向执行 → 先测试,再依据明确的成功标准进行验证
不依赖任何框架,也不需要复杂工具——只用一个文件,就能在项目层面改变 Claude 的行为方式。
真正的差异在于:
·未使用 CLAUDE.md: Claude 在约 40% 的情况下会违反规范
·使用 Karpathy 的 CLAUDE.md: 违规率降至约 3%
·搭建时间: 仅需 5 分钟
用于自动生成你自己的 CLAUDE.md 文件的命令:
claude -p "Read the entire project and create a CLAUDE.md based on:
Think Before Coding, Simplicity First, Surgical Changes, Goal-Driven Execution.
Adapt to the real architecture you see." --allowedTools Bash,Write,Read
它所取代的是这样一种 Claude:面对简单任务却过度设计、引入没人要求的依赖,甚至随意修改不该动的文件。
Part2 Everything Claude Code:一个仓库里的完整工程团队
Everything Claude Code(GitHub 上已获得超过 15.3 万颗星)
这不仅仅是一套提示词集合,而更像是一个完整的 AI 操作系统,用于构建产品。
支持在 Claude、Codex、Cursor、OpenCode、Gemini 等多种工具上运行——一套系统,到处可用。
安装方式:
/plugin marketplace add affaan-m/everything-claude-code
或者手动安装——只需将你需要的组件复制到项目的 .claude/ 目录中即可。不要一次性加载全部内容——同时加载 27 个 agent 和 64 个技能,很可能在你输入第一条提示之前就耗尽上下文额度。只保留真正需要的部分。
真正的差异在于:
·之前: 你是在和 AI 对话
·之后: 你是在管理一支自动运行的 AI 工程团
它所取代的是:你原本需要花上数周时间搭建自己的 agent 系统、分别配置规划/评审/安全等不同工具,以及每月为各类 AI 服务支付 200–500 美元的成本。
Part3 一个隐藏的「丑闻」:Claude Code v2.1.100 正在悄悄消耗你的 tokens
有人通过搭建一个 HTTP 代理,对 4 个不同版本的 Claude Code 的完整 API 请求进行了拦截和分析。
他们发现:
v2.1.98: 169,514 bytes request → 49,726 tokens charged
v2.1.100: 168,536 bytes request → 69,922 tokens charged
difference: -978 bytes but +20,196 tokens
v2.1.100 发送的数据字节数更少,却额外多收取了 2 万个 tokens。这种「通胀」完全发生在服务端——你既无法看到,也无法通过 /context 接口进行验证。
为什么这件事的重要性不止于计费,这额外的 2 万个 tokens 会被塞进 Claude 的实际上下文窗口中。
这意味着:
→ 你的 CLAUDE.md 指令会被这 2 万个「隐藏内容」稀释
→ 在长对话中,输出质量会更快下降
→ 当 Claude 忽视你的规则时,你很难找出原因
→ Claude Max 的使用额度会比正常情况快约 40% 被消耗
修复只需 30 秒:npx [email protected]
这是一个在 Anthropic 官方修复问题之前的临时方案,但在实际使用中,你几乎可以立刻感受到会话效果的变化。
它所取代的是:你不再需要猜测为什么 Claude 突然不再遵循你的指令。
案例:完整自动化系统是什么样的
一位拥有 11 年经验的工程师,构建了一个由三部分组成的系统:
一周之后的结果:
·之前: 每天 8 小时写代码
·之后: 每天只需 2–3 小时做代码审查和测试
·代码质量: 基本不变——因为他会逐一 review
·Teams 状态: 始终在线——鼠标每分钟自动移动
·剩余时间: 全天自由支配
这并不是什么「魔法」,而是 CLAUDE.md + 合适的 agents + 每 15 分钟一次的循环机制共同作用的结果。
完整清单:
读完之后你能获得什么:
·之前: Claude 在 40% 的情况下会违反既有规范
·之后: 使用 Karpathy 的 CLAUDE.md 后,违规率降至 3%
·之前: 你需要花几周时间搭建 agents
·之后: 27 个 agents 开箱即用
·之前: Claude Max 在 2–3 小时内就会耗尽额度
·之后: 降级到 v2.1.98 可恢复约 40% 的使用上限
·之前: 每天需要 8 小时写代码
·之后: 只需 2–3 小时做 review,其余由系统自动运行
·搭建时间: 15–20 分钟
·每日节省: 5–6 小时
·每月节省: 100–120 小时
如果你的时间价值是每小时 30 美元——那你每个月其实在「看不见地损失」3000–3600 美元。
如果是每小时 100 美元——那就是每月 10000–12000 美元白白流走,只因为你还在手动写那些 Claude 本可以自己完成的代码。
大多数开发者永远达不到这个水平——不是因为他们做不到,而是因为他们以为这件事很复杂。实际上,在你与「全自动化」之间,只差三条命令和一个文件。
我一开始提到的那位工程师,并不是什么天才,也不是来自 Google 的资深工程师。他只是花了一个晚上的时间,把系统搭建好——从那以后,工作由系统完成,他只负责生活。
你今晚也可以做到同样的事情。当其他人还在争论 AI 是否会取代开发者时,那些已经搭好系统的人,只是在一边收钱,一边放松。
选择其实很清楚。你在构建的是自己的人生——那就选对路径。
