我们都迷上了Claude Code

原始标题: We’re All Addicted To Claude Code

发布日期: 2026-02-06 | 来源频道: @ycombinator

📝 深度摘要

1. 讨论背景与核心主题

本期节目是 Y Combinator 合伙人 Gary 主持的深度对谈，邀请到了 Kelvin French——他是 OpenAI Codex 的早期创建者，也是客户数据平台 Segment（已成功退出）的创始人。Kelvin 最近连续九天沉浸式使用 Claude Code，仿佛找回了十年前作为程序员的感觉，他将这体验比喻为"获得了仿生膝盖，跑步速度提升了五倍"。

这场对话试图回答一个核心元问题：在 AI 编程工具爆发的时代，开发者如何真正成为超级生产者？什么才是编码代理的正确使用方式？ 讨论涵盖了从技术实现细节到创业策略的全方位洞察，特别关注上下文工程（context engineering）、模型架构选择、以及开发者工具的分发模式。

2. 核心干货概览

3. 深度战术拆解：YC 方法论实战

痛点再定义

初创公司在使用 AI 编程工具时最常犯的错误，是将工具当作全能的"代码生成器"而非需要精心引导的协作者。Kelvin 指出一个关键洞察：模型本质上擅长"基于现有上下文做更多扩展"，但当任务目标是"减少"或"重构"时，它们往往表现出乎意料地差——它们会不断添加代码、重复实现已有功能，而不是删除冗余。

另一个核心问题是上下文污染（context poisoning）。当对话过长时，模型会陷入某种"循环"——它持续参考错误的 tokens，继续执行看似合理但实际偏离目标的操作。Kelvin 将这种现象比作考试时间只剩五分钟却还有半卷子题目未做：“你只能慌不择路地乱写。”

核心策略推导

从第一性原理出发，Kelvin 提出 “上下文工程” 是编码代理最关键的竞争维度。他分析了 Claude Code 和 OpenAI Codex 两种截然不同的设计哲学：

Claude Code（Anthropic） 的做法是模拟人类工作方式——当你需要建造一个狗屋时，它会先去建材店采购材料，理解每块木材的用途，然后逐步搭建。这种方式更易预测、更适合需要精确控制的场景。

Codex（OpenAI） 则像一台 3D 打印机——给定一个目标，它直接从原材料生成整个结果，不需要中间步骤。这种方式可能产出更"超人类"的结果，但过程难以解释，有时会写出人类不会写的代码（比如用 Python 脚本直接修改文件系统）。

实战步骤 SOP

1. 选择正确的技术栈：优先使用自带大量模板的开箱即用平台（如 Vercel、Next.js、Cloudflare Workers），将复杂度压缩到一二百行代码以内
2. 主动管理上下文：当 tokens 使用超过 50% 时，Kelvin 会主动重置会话；他使用一个"金丝雀"技巧——在上下文开头插入一个随机事实（如"我早上八点喝了茶"），定期验证模型是否仍能记住
3. 建立测试护城河：Kelvin 描述他在使用 Claude Code 的第三天决定"重构日"，将测试覆盖率提升到 100%，此后开发速度"像疯了一样"提升
4. 使用结构化工具：相比语义搜索，grep 和 ripgrep 对代码场景更高效，因为代码是上下文密集且高度结构化的数据

细节支撑

Kelvin 分享了他用 Claude Code 调试一个嵌套延迟任务 Bug 的具体案例：该 Bug 隐藏在五层深的任务队列中，Claude Code 不仅定位到了问题，还自动编写了测试用例确保永不复发。他形容：“这太疯狂了——如果是以前，我得在 Stack Overflow 上翻几个小时，现在它直接读取 Rails 源码并理解了整个 Active Job 的内部逻辑。”

关于 Sentry 的 MCP（Model Context Protocol）集成，Kelvin 提到这本质上是一个"自动 Bug 修复器"——当 Sentry 检测到错误时，Claude Code 可以直接生成修复方案并提交 PR。

4. 技术护城河与工程实践

AI/ML 策略应用

Kelvin 提出了一个令创业者不安的预言：价值正在从工具层快速流向应用层。以 Segment 为例——曾经 Segment 的核心价值是帮你把数据同时接入 Mixpanel、Kissmetrics、Google Analytics，但在 AI 时代，告诉 Claude Code"把我的数据映射到这个格式"就能实现相同功能，Segment 的这部分价值已"暴跌至零"。

他同时指出**数据Gravity（重力）**依然存在：即使 AI 能生成代码，公司依然需要系统记录（system of record）来确保数据一致性。Slack 之所以限制 API 访问，正是担心用户直接基于 AI 构建竞品。

关于 上下文窗口的限制，Kelvin 认为这是当前最大的技术瓶颈。Claude Code 的架构是将任务拆分到多个子上下文窗口中分别处理，最后合并结果——Anthropic 在这方面"有独到的见解"，但当问题规模超过单窗口容量时，“再多的压缩也无济于事”。

工程化决策逻辑

grep vs 语义搜索：Cursor 使用嵌入（embedding）进行语义搜索来确定相关代码；而 Claude Code 和 Codex 实际上直接使用 grep。Kelvin 认为这在代码场景中非常有效，因为每行代码通常少于 80 个字符，上下文密度高，且可以尊重 .gitignore 过滤无关文件。

微调 vs 基础模型：Kelvin 提到 Codex 团队曾对 03 推理模型进行强化学习微调，但大多数开发者不需要这样做——关键在于理解"向代理提供什么上下文"才能获得最佳结果。

Sandboxing（沙箱）的取舍：OpenAI 的 Codex 采用严格的安全沙箱策略，而 Claude Code 选择直接访问用户本地环境。Kelvin 坦言他在生产环境中直接让 Claude Code 访问生产数据库——“它可以直接操作，我信任它”。这反映了创业公司与企业在安全态度上的根本差异：初创公司追求速度，大公司担忧风险。

5. 反直觉洞察与避坑指南

创业非共识

反直觉一：网站不转化往往不是因为 UI 难看，而是因为缺乏"自下而上的分销"。Kelvin 指出，当今时代最有效的分发模式是让工程师直接下载使用——CTO 们会纠结于安全、隐私、控制等层层顾虑，而开发者只需"安装并开始使用"。他以 Netscape Navigator 为例：最初免费供个人使用，人们自发下载用于商业目的，netscape 再通过追踪 IP 地址来"发现"违规用户并推销许可证。

反直觉二：最优秀的编码代理用户是资深工程师，而非新人。Kelvin 观察到，模型擅长将"想法转化为行动"，而资深工程师恰好最擅长提供清晰的高层意图——他们可以在代码库中看到问题时，只需描述"我希望这里有所不同"，代理就能完成执行。这种"赋能与放大"效应对于架构师级别的开发者价值最大。

反直觉三：AI 编程反而让"系统理解"变得更加重要。Kelvin 提到他在 YC 面试 18-22 岁的年轻工程师时担忧：他们从未经历过"管理模式"的工作——没有处理过数十万条错误、没有经历过数百万 jobs 的队列管理。而 AI 代理可以代替执行，却无法代替理解系统的全貌。

“死亡之谷"预警

陷阱一：上下文中毒导致的无声失败。当代理在错误方向上越走越远时，它不会报错，而是持续产出看似合理但实际无效的代码。Kelvin 的解法是定期重置会话，以及使用"金丝雀验证"技巧。

陷阱二：代理的"添加"本能。模型默认倾向于"做更多"而非"做更少”。当你需要重构或删除代码时，必须明确指令，否则它会不断添加新文件和重复实现。

陷阱三：对特定技术栈的支持差异。Kelvin 指出 OpenAI 的模型在 Ruby/Rails 生态中的表现不如 Python——因为他们的内部数据组合偏向自身技术栈。这提醒创业者：AI 工具的能力边界取决于其训练数据，选择工具时需考虑项目实际使用的技术栈。

6. 金句

• “编程曾经需要把整个系统的上下文装进自己的脑子——类名、函数名、所有触达的代码，构建这个上下文需要数小时。十分钟的碎片时间根本不值得开始。现在有了 Claude Code，我可以在会议的间隙完成一个功能，它就像火箭推进器一样不可思议。”
• “在 AI 时代，最好的分销模式是自下而上——工程师直接下载使用，而不是等待 CTO 批准采购。CTO 们会没完没了地讨论安全、隐私、管控，而开发者只想快点干活。”
• “模型就像考试时时间不够的学生——当上下文窗口快用完时，它的输出质量会断崖式下降。你必须学会在 50% tokens 时主动重置会话。”
• “我对 Ruby 社区最大的遗憾是：没有足够的人往模型里贡献 Rails 的优质代码。如果你是某个框架的核心维护者，你有机会通过让 AI 更好地理解你的框架来建立巨大的护城河——因为这本质上是在定义模型的认知边界。”
• “我们正在见证一个深刻的变化——以前初创公司需要四小时的完整时间块才能写代码，现在十分钟的间隙就够用。这意味着编程从’制作人模式’真正变成了’经理模式’——你更多是指挥代理，而不是自己动手。”

📺 视频原片

视频ID: qwmmWzPnhog