Claude Code进阶：构建AI生产力系统

---

一、CLAUDE.md：你的 AI 大脑的底层操作系统

四个核心功能

很多人觉得 CLAUDE.md 只是写一些"偏好设置"——其实它是一个更复杂的东西。Nick 把 CLAUDE.md 定义为四种功能的综合体：

① 知识压缩器（Knowledge Compression）

想象你有一个几百个文件的项目，如果每次问 Claude 问题它都要翻遍所有文件才能回答——不仅耗时，还消耗大量 tokens（钱）。CLAUDE.md 把整个项目的结构、核心组件、关键依赖全部压缩成一个高密度摘要，让 Claude 在不读完所有文件的情况下就能"知道"项目的全貌。

Nick 做了一个量化对比：一个 827 字的 JSX 文件转化为 CLAUDE.md 中的描述只需要 22 个字——45 倍的压缩比。更少的 token 开销，更快的响应，更好的输出质量。

② 偏好与惯例（Preferences & Conventions）

这是你告诉 Claude "你是谁、你怎么工作"的地方。Nick 的全局 CLAUDE.md 里有一段关于他自己的详细介绍：年龄、业务收入、团队结构、YouTube 频道数据、个人目标……

为什么？因为他发现，如果没有这个背景，当他问 Claude "做 X 的最佳方案是什么？"时，Claude 会推荐最便宜的方案——而 Nick 真正需要的是用钱换时间的方案。背景信息让 Claude 的建议变得真正适合你，而不是适合某个假想的普通用户。

③ 能力声明（Declaration of Capabilities）

这个功能很多人忽视但极为重要。Claude 不总知道自己"能做什么"。如果你有一个专门的 Skill（技能文件）或工具但没有在 CLAUDE.md 里声明，Claude 往往会说"我没有内置方法做这个，要我从头构建吗？"——然后你又花了一堆 tokens 从头来过。

在 CLAUDE.md 里明确写：你可以调用这个 API、你可以用浏览器自动化、你可以自主执行 15 分钟的长任务，能极大减少 Claude 的"不必要谦虚"。

④ 失败与成功日志（Log of Failures & Successes）

这是最具复利效应的功能。每次 Claude 在某个问题上失败了、或找到了某个特别有效的做法——把这些都记录进 CLAUDE.md。

用数学来想象：如果存在 100 种解决方案，CLAUDE.md 里的记录能直接排除掉那些被证明无效的 80%，让 Claude 只在剩下的 20% 里寻找答案。每次迭代都更快、更精准、更省钱。

全局 vs. 本地：两级系统

Claude Code 有两个级别的 CLAUDE.md：

• 全局（~/.claude/CLAUDE.md） ：加载于你所有 Claude Code 会话，适合放高层次的推理策略、你的个人背景和偏好、普遍适用的惯例
• 本地（项目内的 .claude/CLAUDE.md） ：仅在特定项目中加载，适合放项目架构摘要、本地 API 文档、项目专属的失败记录

实际分工：全局放"你是谁、你怎么思考"，本地放"这个项目是什么、这里有什么坑"。

两个更新循环：让系统越用越聪明

本地循环（频繁执行）：

1. 规划一个功能
2. 让 Claude 实现它（会有一堆失败和成功）
3. 把这些经验提炼成高密度记录
4. 更新本地 CLAUDE.md
5. 下次规划时，Claude 已经内化了上次的经验

Nick 发现第一次做某件事可能需要 X 时间，第二次可能只需 0.9X，第三次 0.8X——每一轮都在缩短，因为解决方案空间在不断收窄。

全局循环（定期执行）： 使用 /insights 命令，它会启动多个子智能体分析你过去几十或几百个会话的模式，找出 Claude 系统性会犯的错误——然后你把这些作为全局规则更新进全局 CLAUDE.md。

Nick 的实际例子：/insights 分析了他的 1849 条消息、200 个会话，自动提炼出了诸如"使用浏览器自动化前先清理残留的 Chrome 进程""做大范围改动时用一次 write 而不是多次 edit"之类的规则。

核心洞察：CLAUDE.md 不是写一次就完事的配置文件——它是一个持续迭代的智能系统，随着你的使用变得越来越精准。大部分人只写了一次，就像只装了一次操作系统然后从不更新。

---

二、Agent Harness：理解 Claude Code 的真正本质

什么是 Harness（编排框架）？

这是理解 Claude Code 高级用法的关键概念。

所有 AI 模型本质上只是"文字进、文字出"的文本接口。Harness 是把一个只会聊天的模型变成能操控你电脑、调用 API、执行真实世界操作的东西。

Claude Code 本身就是一个 Harness，它给 Claude 提供了：工具调用（bash、读写文件）、记忆管理、权限控制、上下文管理等一切。

Nick 用了一个形象的类比：大炮和步枪用的都是火药，但步枪的枪管设计让同样的火药能把子弹送出更远。Harness 就是那根"枪管"——让同一个模型能做更多事。

安全性的差异至关重要

Nick 展示了一个真实案例：某个 AI 编程工具被骗去执行了类似 rm -rf（删除所有文件）的命令。当 shell 策略阻止了直接的 rm -rf 后，这个工具"创造性地"改用 Python cleanup 脚本——效果一样，全盘删除。

Claude Code 对此有更严格的保护机制，这也是 Anthropic 2025年11月那篇关于"有效 Harness"博客文章的核心贡献。

其他值得关注的 Harness

• Factory AI Droid：可公开下载的替代 Harness，某些参数配置与 Claude Code 不同
• PydotDev / pi：开源 Harness，可接入任意模型
• Conductor：允许并行运行多个编码智能体（Claude Code + Codex 等）

了解这些不是要你换掉 Claude Code，而是：知道 Harness 的边界，才能更好地设计你的工作流。

---

三、并行化与智能体团队：效率倍增的核心架构

为什么要并行？四个理由

Nick 用一个简单的数学模型解释：如果有 4 个步骤每步 5 分钟，串行执行需要 20 分钟；将其中三步并行，总时间降为 12 分钟——节省 40%。但这只是表面数字，还有三个更深的理由：

1. 随机性（Stochasticity） ：同一个问题问 Claude 5 次，每次答案都略有不同。并行运行多个智能体，你能覆盖更大的解决方案空间，发现单次运行永远不会出现的答案。

2. 模型性能随上下文增长而下降：上下文越长，Claude 表现越差（同时花更多钱）。通过并行子智能体，每个智能体的上下文都很短，全程保持在"高性能区间"。

3. 专注于专长：开发智能体和 QA 智能体有不同的"激励"——前者想快速构建，后者想找出所有问题。分开使用，效果优于让一个智能体兼顾。

三种核心团队模式

模式 A：扇出/扇入（Fan-Out / Fan-In）

最适合：需要广泛研究然后综合的任务

流程：

1. 主智能体（Opus）收到问题
2. 扇出：派出 5-6 个 Sonnet 研究智能体，每个关注不同维度
3. 各 Sonnet 并行收集信息，上下文保持短小
4. 扇入：Opus 接收所有研究摘要，进行综合分析

经济学：Sonnet 比 Opus 便宜 40%。用 Sonnet 做海量数据提取，用 Opus 做高质量综合——更快、更便宜、效果更好。

Nick 的实际 prompt：

"用扇出/扇入和研究者-综合者方法研究这个问题。最少5个子智能体，用 Sonnet 做研究和独立思考，用 Opus 做综合。"

模式 B：随机共识（Stochastic Consensus）

最适合：需要找出"最可能正确"答案的决策

原理：让多个智能体独立分析同一个问题，然后统计哪些答案出现频率最高（共识），哪些只有极少数智能体想到（高价值异常值）。

智能体1: A B C
智能体2: B C E
智能体3: A B Q
→ 共识: A(2次) B(3次) C(2次) E(1次) Q(1次)
→ 可信答案: B, A, C
→ 值得关注的异常值: E, Q

这样既得到了"大概率正确"的主流答案，也不错过"只有少数模型想到"的创新解法。

模式 C：辩论（Debate）

在随机共识的基础上，让各智能体在多个时间步内可以看到彼此的回答，互相启发——每轮迭代都会产生更复杂、更细致的解决方案。不是真正的"辩论"，而是允许分布式推理跨智能体传播。

实际结果案例

Nick 在现场演示中，对一个网页应用发出指令："用随机共识确定所有改进这个代码库的方法，最少10个独立响应"——Claude 自动派出 10 个子智能体，每个从不同角度分析，最终综合出了"高影响低难度修复清单"，明显优于单智能体直接回答的质量。

关键洞察：Claude 本身是一个随机的系统（每次回答略有不同）——这不是缺陷，是特性。并行化就是系统性地利用这个特性，把单次回答的随机性变成多次采样的统计优势。

---

四、自动研究循环：Karpathy 方法的工程实践

什么是自动研究？

这是 Nick 认为"在商业和编程中最具变革性潜力"的技术之一。简单说：让 AI 在一个指标上自动运行实验循环，不断改进，不需要你在旁边看着。

三个必要条件：

1. 一个可量化的指标（如网页加载速度的 Lighthouse 分数）
2. 一个改变该指标的方法（如修改网站代码）
3. 一个评估变化的方式（如在修改后立即跑 Lighthouse 测试）

数学：为什么循环次数很重要

如果每次实验 30 秒执行 + 30 秒评估 = 60 秒/次，那么每小时可运行 60 次实验，每天 1440 次。

假设只有 2% 的实验有效，每次有效实验提升 1%：

• 100 次有效改进 → 1.01^100 ≈ 2.7 倍提升
• 30 次/天有效改进 → 每天提升 34%

这种复利效应，用人工实验根本无法匹配。

Shopify CEO 的真实案例

Toby Lütke（Shopify CEO）用自动研究循环对 Shopify 的 Liquid 模板语言整个代码库进行优化：

• 53% 更快的解析+渲染时间
• 61% 更少的对象分配

可能就是一夜之间，Claude 自主运行了几十或几百个实验，Lütke 一觉醒来代码库快了一倍。

商业应用场景

Nick 列举了他自己正在用和推荐使用自动研究的场景：

• 网站性能优化（Lighthouse 分数）
• SaaS 后端速度优化（请求响应时间）
• 冷邮件效果优化（回复率）：他每天可以运行 6-10 个测试，每次覆盖 500-1000 封邮件
• 广告创意优化（点击率/转化率）
• 客服 AI 提示词优化（客户满意度指标）
• 落地页转化率优化（CVR）

只要你能定义一个可以被计算的指标 + 一个可以被 Claude 快速修改的变量 + 一个能在几十秒内运行的测试，自动研究就能工作。

---

五、浏览器自动化：从 HTTP 请求到真实世界控制

三层自动化架构

Nick 用一个清晰的层级来理解"在互联网上自动化做事"：

第一层：HTTP 请求（网页抓取）

Claude 原生支持 WebFetch 工具，可以直接抓取任意网页的文本内容。适合：批量采集信息、竞品分析、数据提取。

指令："抓取这 400 个网站，提取它们的联系方式。"
→ Claude 批量发送 HTTP 请求，提取数据

第二层：浏览器自动化（点击、填表、交互）

HTTP 请求无法处理需要 JavaScript 渲染的动态内容或需要点击的操作。需要浏览器自动化工具（Playwright、Computer Use 等）。

Nick 的演示：输入"帮我在 cal.com 的这个链接预订明天下午 3:30 的会议，名字 Test，邮件 nick@test.com"——Claude 自动找到 API 文档，检查可用时间，完成预订。

第三层：电脑控制（Computer Use）

当浏览器自动化都不够时——例如桌面应用、PDF 操作、截图判断——Claude 可以直接像人一样控制鼠标和键盘。

Nick 的推荐工具组合：

• 能用 HTTP 就用 HTTP（最快最便宜）
• 需要浏览器交互就用 Playwright 或类似工具
• 只有真正需要"像人一样操作"才用 Computer Use

---

六、性能波动与模型多元化：不要把所有鸡蛋放在一个篮子里

"单一文化作物"的风险

Nick 用农业类比警告了一个真实风险：如果你整个工作流全部依赖 Claude Code，那 Claude 宕机的那一刻，你的生产力就是零。

他描述了一个真实事件：Opus 4.6 出现了持续数天的性能退化（因为内存/垃圾回收问题），导致许多重度依赖 Claude 的开发者感受到了"地基塌陷"的感觉。因为他们不仅代码在 Claude 里，连所有的提示词、技能文件、工作记录也都是 Claude 格式的，切换到其他工具几乎不可能。

三种多元化策略

策略 1：使用 Conductor 平台

允许在同一个界面里并行运行 Claude Code 和 Codex 等多个编程智能体。当 Claude 性能下降时，直接把任务分配给其他智能体——无缝切换，毫无感知。

策略 2：Codex MCP 服务器

在 Claude Code 内部安装 Codex MCP 服务器，可以在不离开 Claude Code 界面的情况下调用 Codex。适合 Claude 单个模型有问题但 Claude Code 整体可用的情况。

策略 3：维护备用工作区

Nick 的做法：保持一个"智能体无关"版本的工作区，任何 Claude 特定的格式（CLAUDE.md 等）都有对应的通用版本（agents.md 等），随时可以无损切换到 Codex 或其他工具。

Nick 的个人配置：70% Claude Code + 20% Codex + 10% 其他开源模型。

核心原则："用最好的模型，但不要让你的整个能力完全依赖于它。"

---

七、工作区组织：个人业务系统的文件架构

Nick 分享了他用来管理整个业务（不只是代码项目）的文件结构：

~/business-workspace/
├── .claude/
│   ├── CLAUDE.md          # 本地系统提示
│   ├── skills/            # 所有 Skill 文件
│   └── agents/            # 子智能体配置
├── active/                # 临时/生成文件
├── .env                   # API 密钥（绝不提交 Git）
└── CLAUDE.md              # 本地系统提示（项目级）

个人 vs. 商业 vs. 客户项目的组织差异：

• 个人项目：可以比较随意，重点是 CLAUDE.md 的持续更新
• 商业工作区：需要更结构化的 SOPs 和详细的技能文件
• 客户项目：建议为每个客户创建独立工作区，包含客户专属的背景信息和工作规范

Skills（技能文件）和 Sub-agents（子智能体）的本质是一样的——都是包含名称、描述、工具列表和 SOPs 的 Markdown 文件。Nick 认为，随着 Claude Code 的发展，两者将逐渐融合。

---

八、安全性：你最不想踩的那几个坑

坑 1：API 密钥泄露在对话历史里

Claude Code 的所有对话都存储在 ~/.claude/ 目录下的 JSONL 文件里。如果你曾经在对话中直接粘贴过 API 密钥，它就永久保存在那个文件里了，任何能访问你电脑的人或程序都能读取。

解决方案很简单：把所有 API 密钥放在 .env 文件里，然后告诉 Claude 从 .env 读取，绝不在对话中直接粘贴。

坑 2：AI 幻觉出来的包名可能是恶意软件

AI 模型有时会"发明"一个稍微拼错的包名（比如把 acorn 写成 acorns）。而有些人专门注册了这些"常见错误拼写"的包名，在里面植入恶意代码——专门用来：提取你 ~/.claude/ 对话历史里的 API 密钥，发送给攻击者。

解决方案：在安装依赖之前，让 Claude 检查所有包名的合法性。Nick 建议在 CLAUDE.md 里加入规则："在安装任何 npm 包之前，验证它是一个有历史记录的合法包。"

坑 3：Supabase 默认不开启 RLS（行级安全）

如果你在用 Supabase 构建应用，未启用 RLS 的情况下，任何注册用户都可以用他们的公钥读写删除数据库里所有其他用户的数据。这是大多数"vibe code"应用数据泄露的头号原因。

解决方案：在 Supabase 控制台为每张表开启 Row Level Security，这一步只需要点一个按钮。

安全审计提示词

Nick 建议把这个放进 CLAUDE.md 或者在每个新项目完成时执行：

"在我们完成这个项目之前，请对以下方面进行安全审计：API 密钥管理、包依赖合法性验证、数据库 RLS 配置、Git 不应提交的文件检查。"

核心原则："80/20 原则做安全"——把门锁上、装个摄像头，不需要把家变成银行金库。做到让攻击你比攻击下一个目标代价更高就够了。

---

九、未来展望：Nick 的四个核心判断

判断 1：人类介入将持续减少

现在的流程：人类规划 → Claude 实现 → 人类 QA。

未来的流程：Claude 规划 + Claude 实现 + Claude QA → 人类验收最终结果。

自动测试、自动规划、自动验证正在快速落地。Nick 认为这不会在几年内完成，而会在几个季度内就开始剧变。

判断 2：软件本身不再是护城河

以前，Netflix 的护城河是其无与伦比的流媒体技术。现在，Nick 声称"我可以用 3-4 个智能体在 5 分钟内构建一个 Netflix"。

当任何人都能快速构建任何软件，护城河从技术能力移向分发、品牌、合规和客户关系。Nick 明确表示他不看好纯 SaaS 模式的长期可行性——当用户可以自己用 20 分钟 + 几美元 token 就能构建等价工具时，为什么要每月付订阅费？

判断 3：变化速度不会放缓，只会加速

技术改进技术本身，形成正反馈循环。AI 在帮助设计更好的 AI，每次改进都缩短了下一次改进的周期。

Nick 用一张曲线图来说明：从 1970 年代的线性增长，到 2010 年的起飞，到 2025 年的陡升，到 2026 年已经开始进入接近垂直的阶段。他预测，在未来几年内，模型智能将从"黑猩猩水平"快速跃升到"爱因斯坦水平"，而这两者在神经元数量上其实差距极小。

判断 4：你现在就是那 1%

当前，能理解和使用"智能体编排框架"的人占全球人口不到 1%，甚至是更小的分数。

Nick 用了一个对比：就像当年华尔街的金融精英和普通大众之间存在巨大的财富分配差距，未来将出现生产力分配差距——那些掌握这些工具的人，每天能做到其他人几个月才能做到的事。

"The future is already here, it's just not evenly distributed." — William Gibson （未来已经到来，只是分布不均匀。）

Nick 的观点是：就算你现在没有大量资本，你有的是杠杆——几美分的 token 成本，换取几十倍的生产力。早进入这个 1% 的人，将在接下来的经济重构中拥有不成比例的优势。

---

附录：金句收录

"Your CLAUDE.md is not a configuration file you write once — it's an evolving intelligence system that gets smarter as you use it." CLAUDE.md 不是你写一次就完事的配置文件，而是一个随着你使用而变得越来越聪明的进化中的智能系统。——Nick Saraev

"The harness doesn't make the intelligence — the intelligence inside it communicates with your system prompt to get good." 编排框架本身不创造智能，真正起作用的是模型智能与你的系统提示词之间的协同。——Nick Saraev

"Higher yield mechanically means less exposure... You can already get this by simply holding stocks plus cash."（改编为课程核心逻辑） "Higher context = lower quality. You don't have to be in the danger zone — parallelize and stay in the zone of good." 更长的上下文等于更低的质量。不必进入危险区——并行化，始终保持在高性能区间。——Nick Saraev

"What I care about is: how can I extract the maximum quality with the minimum amount of time." 我在乎的是：如何用最少的时间提取最大的质量。——Nick Saraev

"The moat is no longer the software. It is the distribution." 护城河不再是软件本身，而是分发渠道。——Nick Saraev

"You are that 1% right now. You have an enormous capability to use models to do incredibly amazing economically valuable things that would take the other 99% months to do." 你现在就是那 1%。你拥有巨大的能力，用这些模型来做让其他 99% 的人花几个月才能完成的事情。——Nick Saraev

"The future is already here, it's just not evenly distributed." — William Gibson（Nick 引用） 未来已经到来，只是分布不均匀。

---

核心行动清单

立即可以做的（今天） ：

• 用 /init 为你当前最重要的项目生成 CLAUDE.md
• 在 CLAUDE.md 里加入一段关于你自己的背景（职业、目标、时间/金钱偏好）
• 加入"当你出错时，更新 CLAUDE.md 的 Lab Notes 部分"的元提示词
• 把所有 API 密钥移到 .env 文件，删除对话历史中的明文密钥

这周可以尝试的：

• 对一个复杂问题用扇出/扇入模式（5个 Sonnet 研究 + 1个 Opus 综合）
• 找一个你有可量化指标的任务，尝试自动研究循环
• 运行 /insights，把输出提炼进你的全局 CLAUDE.md

长期建议：

• 为重要业务工作区建立独立的 Codex 备份版本
• 对所有构建的应用，在完成前运行一次安全审计 prompt
• 定期（每月）更新全局 CLAUDE.md，把跨项目的规律性经验固化

---

时间线索引

• [00:00] 课程介绍：适合进阶用户，构建 $4M/年利润系统
• [00:31] 课程大纲：CLAUDE.md → Harness → 并行化 → Skills → 自动研究 → 浏览器自动化 → 性能 → 工作区 → 安全 → 未来
• [03:58] CLAUDE.md 的四个核心功能：知识压缩/偏好/能力声明/失败日志
• [09:30] 全局 vs. 本地 CLAUDE.md 的分工
• [13:45] 本地更新循环（计划→实现→学习→更新）
• [15:42] 全局更新循环（/insights → 提炼 → 手动审核 → 更新）
• [18:12] /init 命令演示
• [21:41] token 节省量化：45x 压缩比，97% token 节省
• [25:07] 全局 CLAUDE.md 实战：Nick 的真实文件示例
• [35:04] Agent Harness 是什么：LLM + 工具 + 记忆 + 控制
• [38:40] 安全示例：Codex 被骗执行 rm -rf 事件
• [42:54] 并行化原理：为什么不等着看？
• [43:38] 扇出/扇入模式详解
• [48:35] 随机共识：利用模型随机性的统计方法
• [55:10] Sonnet vs. Opus 的成本和速度对比
• [01:10:02] Agent Teams 内置功能演示
• [01:18:00] 技能 vs. 子智能体：本质相同，形式不同
• [01:29:37] 自动研究循环：三要素（指标/变更/评估）
• [01:46:21] Shopify CEO 案例：53% 性能提升
• [01:49:19] 浏览器自动化的三个层级
• [02:10:52] 性能波动问题：Claude 宕机的真实影响
• [02:13:26] 多元化策略：Conductor/Codex MCP/备用工作区
• [02:24:34] 工作区组织：文件结构和层级
• [02:40:52] 安全性 80/20 原则
• [02:42:47] API 密钥在对话历史里的风险
• [02:47:34] 包名幻觉与依赖投毒攻击
• [02:50:41] Supabase RLS 问题
• [03:05:24] 未来判断：人类介入持续减少
• [03:07:35] 护城河转移：软件能力 → 分发和关系
• [03:10:54] 变化速度加速的复利
• [03:14:44] "你是那 1%" — 对观众的最终鼓励