当Anthropic意外泄露51万行Claude代码后，我们得以窥见AI产品背后的真实开发逻辑。这份充满技术债与妥协的代码库，彻底颠覆了人们对‘完美产品’的想象——从错误处理里的无奈注释，到未发布的主动服务模式Kairos，再到隐藏的电子宠物系统Buddy，这些细节揭示了当代产品开发中最尖锐的矛盾：完美主义与交付速度的拉锯战、工具思维与关系构建的认知错位、实用价值与情感连接的微妙平衡。

事情本身我不打算多说，网上已经有太多复述了。简单交代一下：3 月 31 日，Anthropic 的 Claude Code 因为一个打包配置的疏漏，把 51 万行完整源码随安装包一起发了出去。不是黑客攻击，是自己开了门。代码在 GitHub 上被归档，永久留存，全世界都能看。

我看完这份代码之后，没有立刻去写 “我学到了什么架构技巧”，而是坐在那里想了很久一件事 —— 这份代码让我对自己做产品的方式，产生了一些真实的怀疑。不是那种 “哇原来可以这么做” 的兴奋，而是一种更慢、更钝的不安。这篇文章，是我把那些不安想清楚之后写的。

一、”好产品” 和 “完美代码” 没什么关系，但我们一直以为有

翻这份代码，第一个让我停下来的不是什么精妙的架构，而是一行注释。它出现在错误处理程序里，写的是：// TODO: figure out why。处理错误的函数，自己也搞不懂自己的错误。往下翻，还有// Not sure how this became a string，管理身份验证的文件里有 9 个空的 catch 块 —— 捕获了错误，然后什么都没做。

我第一反应是笑，第二反应是一种奇怪的解脱，第三反应是不安。解脱是因为：原来世界上被最多人认可的 AI 产品，是在一堆妥协和技术债里长出来的。那些注释背后是真实的工程师，在高压的迭代节奏里，暂时搞不清楚某件事，先记下来，继续往前走。这和我们没什么不同。

不安是因为：如果好产品和完美代码没什么关系，那我们平时花在 “把这个做完美再上线” 上的时间和焦虑，到底在保护什么？我想了很久，发现我们很多时候保护的不是产品质量，而是一种心理安全感 ——”至少我这部分做好了”。这种安全感是真实的，但它消耗的时间和精力，有时候比它带来的价值要贵得多。

我不是在说 “可以随便写烂代码”，我是在说，”完成” 和 “完美” 之间的那条线，我们很多人画得太靠近完美那一侧了，而且我们自己意识不到。

二、我们在设计 “工具”，但用户需要的可能是 “关系”

代码里有一个叫 Kairos 的模式，还没发布。它的设计是：不等你叫，主动待机，自己观察你的项目，自己判断要不要介入。它有一个 “15 秒规则”—— 任何会阻塞你超过 15 秒的操作都会被延迟，不打扰你正在进行的工作。还有一个叫 autoDream 的机制，每隔 24 小时闲置时自动触发，把你最近的对话 “消化” 成长期记忆，越用越懂你。

我看到这两个东西的时候，脑子里浮现的第一个问题不是 “这怎么实现”，而是：Anthropic 在回答一个我们大多数人还没有认真问过自己的问题 —— 用户和产品之间，应该是什么关系？

我们大多数时候做的是 “工具”：用户有需求，打开产品，得到结果，关掉。这个逻辑没有错，但它有一个隐含的假设：用户知道自己需要什么，并且愿意主动来找你。Kairos 模式在挑战这个假设 —— 如果 AI 已经足够了解你，为什么还要等你来问？这不只是一个技术问题，是一个产品哲学问题。工具是被动的，关系是主动的。工具的设计逻辑是 “让用户用起来顺手”，关系的设计逻辑是 “让用户感觉被理解”。这两件事需要的产品能力，是完全不同的。

我回头想了想自己做过的产品，发现我几乎所有的时间都花在了前者上。功能够不够用、流程够不够顺、页面够不够清晰 —— 这些都是 “工具” 层面的问题。但 “用户有没有感觉被这个产品理解”，我好像从来没有认真问过自己。

三、一只电子宠物，让我重新想了想 “有用” 这件事

代码里藏着一个完整的电子宠物系统，叫 Buddy。18 种物种，6 级稀有度，传奇款只有 1% 的掉落率，还有闪光变种和帽子配件。宠物会蹲在你的输入框旁边，对你的编码行为发表评论。这是一个愚人节彩蛋，计划在 4 月 1 日上线，结果被提前 “剧透” 了。

这个功能对 Claude Code 的实际能力没有任何贡献。它不会让代码写得更好，不会让 bug 修得更快，不会让任何一个工程问题得到解决。但 Anthropic 的工程师花了真实的时间把它做进去了 ——18 种物种、稀有度系统、ASCII 动画、属性值设计，这不是随手加的彩蛋，是认真做的东西。

我在这里停了很久，想的是：我们做产品的时候，”有用” 和 “让人喜欢”，到底是不是同一件事？我们通常以为是的。一个产品够好用，用户自然会喜欢。但这个逻辑其实有个漏洞：够好用只能让用户觉得 “这个产品值得用”，但不能让用户觉得 “我喜欢这个产品”。前者是理性判断，后者是情感连接。一个产品如果只有前者，用户会用它，但不会想它，不会在朋友面前提起它，不会因为它消失了而感到失落。

Buddy 宠物系统解决的不是 “有用” 的问题，解决的是 “喜欢” 的问题。它在用一个很小的设计，回答一个很大的问题：这个产品，有没有让你觉得它在乎你？我想了想自己做过的产品，发现我们在 “有用” 上花的时间，远远多于在 “让人喜欢” 上花的时间。而且我们通常把 “让人喜欢” 当成一件锦上添花的事，等 “有用” 做好了再来考虑。但 Anthropic 的代码告诉我，他们是同步在做这两件事的。

四、护城河消失的速度，比我们想象的快

源码全公开了，Claude Code 不会死。这一点我是确信的。但这件事让我意识到一个更让人坐立不安的事实：在 AI 时代，一个产品的技术壁垒消失的速度，正在变得越来越快。不只是因为泄露，更根本的原因是：模型能力在快速平权，工程实现在快速透明，今天需要花两年时间才能做出来的东西，明天可能六个月就能复制。这不是危言耸听，这是这个行业正在发生的事。

那真正持久的护城河在哪里？我想了很久，觉得答案越来越指向同一个方向：不在功能里，在关系里。用户和产品之间积累的信任、习惯、记忆 —— 这些才是真正难以被复制的东西。你可以复制一个产品的功能，但你复制不了用户在这个产品里积累的三年使用习惯，复制不了他们每天打开这个产品时的那种 “这是我的工具” 的感觉。

autoDream 本质上是在用工程手段构建这种关系 —— 让产品记住你，让你离不开它。Buddy 宠物也是 —— 让你对一个终端工具产生情感。这两个设计表面上看起来很不一样，但指向的是同一件事：怎么让用户觉得，这个产品是他们的，而不只是他们在用的。

我回头看自己做过的产品，发现我们在这件事上几乎没有认真投入过。我们在堆功能，在追热点，在赶版本，在做竞品分析，在优化转化率 —— 这些都没有错，但如果没有同时在认真构建用户和产品之间的关系，那我们做的所有这些，都只是在建一座没有地基的楼。

最后我还是回到了那行// TODO: figure out why。我现在觉得这行注释比这次泄露里任何一个未发布的功能都值得记住。不是因为它暴露了什么技术问题，而是因为它说的是一种状态：在高速前进的时候，允许自己暂时不知道答案，先记下来，继续往前走。

做产品也是这样。这篇文章里我问了很多问题，大部分我自己也没有答案。我不确定 “工具” 和 “关系” 的边界在哪里，不确定情感设计应该占多少比重，不确定护城河到底能不能真的建起来。但我觉得，把这些问题想清楚，比假装有答案更重要，至少，比又开一个需求评审会更重要。