Codex想让Harness消失，Claude Code却要把它做成“承重墙”

模型越来越强后，Harness 是越来越重，还是越来越轻？OpenAI 和 Anthropic 两家顶尖模型公司的工程师给出了截然相反的结论。

“随着模型进步，系统里的开发者消息会越来越短，Codex 的 Harness 本身也会越来越轻。”这是 OpenAI Codex 团队的 Tibo 在最近的播客中给出的判断。这可能也是相对普遍的观点。

但是，Anthropic Claude Code 团队工程师 Thariq Shihipar 却在另一档节目中表示：“模型越强，Harness 反而需要越来越复杂，因为你要让模型能够做更多事情。”

Tibo 给出了自己的解释。

他明确表示，Codex 的 Harness “通常会比模型领先一点”。在模型已经具备某种潜在能力、但还无法稳定发挥时，Harness 会先通过额外指令和控制机制给模型加上“拐杖”，让它能够更可靠、更高效，也更符合用户预期地完成任务。但随着模型能力提升，新模型会更准确地理解用户真正想要什么，也会主动反思任务是否已经完整完成，因此过去依赖开发者消息强制约束的行为，可以逐渐由模型自己学会。

在实际运行中，Codex 的最终表现并不能简单归因于模型或者 Harness 中的某一方。Tibo 透露，当团队希望加入一个新的产品能力时，首先要判断的是这个问题应该由 Harness 解决，还是应该由模型本身解决。

如果模型合适，团队会进一步评估模型侧最快什么时候能够解决；如果某个问题预计很快就可以在模型层被修复，团队甚至可能选择完全不在 Harness 中增加临时补丁，而是直接等待下一版模型。

这意味着，Codex 的工程团队并不会把所有已知问题都固化成外部规则。相反，一部分 Harness 逻辑从一开始就是临时性的，当模型能力追上来之后，相应的规则和提示就会被删除。

而 Thariq 则认为，由于 Agent 开始承担更长时间、更高自主度的任务，模型越强，Harness 反而需要更复杂。

他以自动模式为例解释，过去 Claude 一轮任务只运行几分钟，遇到权限确认时用户手动操作即可；现在 Claude 可以连续工作数小时，系统就必须通过分类器、沙箱等机制，让它在长期运行中保持安全并遵循指令。

同时，Agent 工作时间变长后，“怎么让人看懂它做了什么”也成为新的问题。Thariq 举例，如果 Claude 已经连续工作 8 小时，用户不可能逐步回看全部过程，因此 Anthropic 会借助 Artifacts 来呈现结果和工作进展。

Thariq 认为，Harness 工程正变成一门“科学和艺术的混合体”。Auto Mode、Workflow、Sandbox 等原本像辅助能力的组件，正在成为整个 Agent 系统的“承重结构”。

一定程度上，这两种结论并不真正矛盾，两人都描述了 Agent Harness 正在发生的一次结构性变化：模型越强，负责“教模型怎么做事”的 Harness 会变轻，但负责“让模型安全、长期、并行地做更多事”的 Harness 会变重。

我们整理了 Thariq 在 Ryan Peterman 节目中的对话，其中他详细解释了自己的观点。此外，Thariq 还分享了 Anthropic 工程团队当下究竟如何把模型能力发挥到极致。下面是两人的对话，以飨读者。

太长不看版：

Q：模型越来越强，Harness 会不会越来越不重要？

A：实际情况几乎相反。模型越强，Harness 反而需要越来越复杂，因为你要让模型能够做更多事情。现在 Claude 可以连续运行数小时，你就必须让它长时间安全工作、遵守指令。自动模式、沙箱、工作流这些东西，本身都是很复杂的软件，但正在变成整个系统的承重结构。

Q：Prompting 以后还值得专门学吗？

A：还是非常有价值的。Prompting 不只是你最后输入的那一句 Prompt。有时大家看到我们的 Prompt 很短，是因为我们已经在 Harness、验证和 Skills 上花了很多时间。不同模型确实有不同怪癖，但你真正积累下来的能力，是学会怎样适应一个新模型。

Q：对模型说“相信自己”有效？

A：我觉得真正起作用的不是“我相信你”这几个字，而是在告诉模型：这个问题值得使用更多算力，我允许你这么做。我现在会直接说：“这是一个很难的问题，如果需要就使用子 Agent，可以用工作流。”模型默认会尽快回应、尽快开始工作，不会主动无限消耗计算，所以有时候你需要明确给它这种许可。

Q：Claude Code 的系统提示词删掉了约 80%，怎么证明变好了？

A：我们发现以前必须放进工具描述里的很多示例，现在反而会产生负作用。过去你得告诉模型“这是正确工具”“这里应该这样写文件”，还要给好例子和坏例子。现在 Claude 已经更有想象力，也更能理解你的意图，所以除非真的看到它持续做错，否则很多示例可以删掉。

Q：怎样让模型做出真正“有品位”的结果？

A：人类得在闭环里，而且要给它参考。HTML 比截图更好，Figma 比栅格图更好，因为模型可以直接读里面的结构。如果你自己都不知道什么叫好，那第一步不是让 Claude 设计，而是先让自己变得更有设计品位。越来越重要的是成为一个“高品位用户”，真正知道什么结果值得要、什么时候还应该继续往前推。

Q：AI 已经能写大量代码，大 PR 该怎么 Review？

A：如果我要发一个 PR，我通常会同时附一个 Artifact，把我发给 Claude 的所有 Prompt 都列出来，包括失败的尝试。如果就是 One-shot，我也会直接说：“这是一次 One-shot，这是我用的 Prompt。”我最想避免的是突然扔给别人一个 1 万行 PR，对方完全不知道我到底看过多少、我和 Claude 到底怎么一起做的。

Q：测试代码是不是应该更多？

A：我甚至觉得，你今天应该拥有比过去多大约 100 倍的测试代码。几乎所有东西都应该有 Fixtures，可以从生产数据生成数据库 Mock，前端可以准备 Storybook，还可以建立很多不同的测试和验证方式。对我来说，这些验证能力才真正提高了可维护性。

Q：技术债是不是可以等下一代模型再还？

A：我觉得这个想法并不完全错。关键还是问：“这次重构现在能不能帮我更快交付客户价值？”我现在更倾向于用短时间尺度看项目，比如未来 1 到 2 个月怎样交付价值。如果一个项目 6 个月、12 个月以后才产生价值，也许确实可以稍微等等下一代模型。

Q：AI 写代码越来越快，会不会导致事故更多？

A：这确实可能是“跑得更快”的副作用，我们也还在解决。我不觉得 Anthropic 现在的 uptime 已经到了理想水平。但你也可以用 Claude 去改善 uptime。AI 不只是让你写更多代码，也让过去负担不起的验证和故障演练变得可以大规模执行。

Q：Anthropic 内部的算力优势是不是普通用户无法复制？

A：我觉得这个差异被夸大了。周末我也用自己的订阅，几乎从来没有撞到过 5 小时限制。我们内部大量消耗算力时，很多时候是在探索模型到底还能做什么，而不是为了完成更多日常工作。普通用户也可以复制很多做法，关键是把抽象层级提高，而不是一开始就盯着某个中间层的小任务反复改。

Q：Claude 已经能做过去很多实习生的实现工作，那实习生现在做什么？

A：现在出现了大量以前从来没人做过的新类型工作，比如怎样评测新的 Coding Agent 行为，怎样衡量 Claude 在数百万用户、各种不同任务里的表现。现在做实习生，我觉得最有意思的不是“去写那段 React 代码”，而是去找那些以前没人做过的问题，然后把它解决。

新人入职 Anthropic 需要注意什么

主持人：我这次最想问的是，在软件工程场景里，怎样才能尽可能发挥这些模型的能力，让行业里其他人也能从 Anthropic 已经验证有效的实践中学到东西。我们先从入职说起。假设我来自一家没那么“AI 原生”的公司，现在加入你的团队，你觉得最重要的几件事是什么？

Thariq：我们给 Anthropic 内外部的人最重要的一条建议都是：把 Claude 当成一个“思考伙伴”，并把它需要的上下文给足，这样通常你们就能一起找到下一步该做什么。一个很重要的出发点是先问：“Claude 能不能做？如果不能，为什么不能？”然后顺着这个思路继续往下走。

另一个习惯是不断问自己，能不能把抽象层级再提高一点。你能不能先搭一个系统？能不能去构建“那个构建系统的系统”，而不是只完成眼前这个产品本身？

主持人：以前新人入职时，通常会分配一个“入职搭档”，对方很熟悉代码库，你可以问他各种很琐碎的环境配置问题。听起来 Claude 已经补上了其中很多空白。那是不是已经到了完全不需要入职搭档、技术问题全问模型的程度？

Thariq：入职搭档还是需要的，但更多是社会关系和文化层面的需要，而不是技术层面的。

纯技术问题基本可以直接和 Claude 协作，如果你比较会用它，入职所需的技术信息都能拿到。但你仍然需要知道怎么和团队协作，怎么为自己做的东西争取认同，团队内部怎么配合，甚至只是有一个能一起工作的朋友，这些都很重要。所以，我们还是会给新人配入职搭档，只不过现在它承担的技术支持工作，远没有以前那么多了。

主持人：我感觉外界对 AI 能力的认知，和 Anthropic 内部真正的使用方式差别很大。我和朋友聊天时会说：“对，Boris 说的那些其实就是现实。”为什么内部认知和外部认知之间会有这么大的落差？

Thariq：我觉得我们过去在这类事上的判断还不错。很多话刚说出来时，人们会觉得太夸张，但过很久往往真的会发生。

现在很多工程师其实已经不怎么用 IDE 了。我和一些大型企业客户聊过，有人已经 6 个月没有亲手敲过一行代码。对我们来说，工作的一部分就是不断把自己提升到更高的抽象层级。如果我花一整天研究“怎样让 Claude 自主完成这件事”，最后失败了，对我来说也没关系，甚至可能是好事，因为我就知道 Claude 这里做得还不够好，接下来可以思考怎么把它变好。

但普通岗位不一样。你的工作目标通常是产出结果。自动化总有成本，其本质上是一种投资：如果自动化成功，长期会得到回报；如果失败，那之前投入的时间就浪费了。好的一点是，随着模型越来越聪明，这种投资最终成功的概率一直在提高。但作为个人，你还是得先迈出那一步。要是你整天都在调 Harness，却一直没有交付代码，你的老板大概率不会特别高兴。

所以，很大一部分其实是文化问题。我们把“活在未来”当作自己的工作，然后尽量把这些实践做进产品和 Harness 里，让其他用户不需要手工完成那么多步骤。

主持人：有没有哪些事，你觉得在 Anthropic 内部已经产生很大影响，但外面尤其是 Twitter 上还没多少人在做？

Thariq：用 Claude Code 做知识工作非常有价值。我觉得现在技术人员做知识工作的方式，已经和非技术人员很不一样了，因为技术人员可以把很多任务交给模型执行。

很多时候，你可以把一个任务拆成类似代码的步骤，然后思考该怎样把这些步骤告诉模型。只要这样做，能完成的事情会多很多。比如，我个人会用 Claude Code 做不少财务处理，我会写 Python 脚本，而不是用 Excel；做视频编辑时，我会用 FFmpeg 和一些程序库来渲染视觉内容。

仔细想，很多知识工作其实都可以归约成代码，再让 Coding Agent 去执行代码。我觉得这是技术人员和其他人目前一个很明显的差别，而外面很多人还没有充分利用这一点。

模型越强，Harness 反而要越复杂

主持人：很多人用 Claude Code 做目标明确、标准客观的工作时，结果都很好。但如果让模型做“漂亮”“有品位”这种更主观的东西，比如前端设计，结果就会更不稳定。你怎样把一种非常具体的风格或审美传递给模型？

Thariq：Harness 非常重要。常见的一种想法是：模型会越来越好，等到模型什么都能完美完成的时候，Harness 就不重要了，那为什么还需要 Harness？但我们实际看到的情况几乎相反：模型越强，Harness 反而需要越来越复杂，因为你要让模型能够做更多事情。

自动模式（auto mode）就是一个例子。它会在那些原本需要 Claude 向用户弹出权限确认的任务上，通过分类器来判断后续行为。以前在 Opus 4、甚至 Opus 4.5 阶段，一轮任务通常只跑几分钟，碰到权限提示时手动按一下回车并不算什么。但现在 Claude 可以连续运行数小时，你就必须让它在很长时间里既能安全工作，又能遵守你的指令。自动模式本身就是非常复杂的软件，沙箱同样也是很复杂的软件。

另外，Claude 现在能连续做非常多的工作。假设它已经工作了 8 个小时，你怎么知道这 8 个小时里究竟完成了什么？所以我们会用 Artifacts。Artifacts 本身其实也是一种提示方式，因为你必须决定 Claude 怎样呈现这些工作，才能让人真正有用地理解。同一批信息可以有很多完全不同的表达方式。

因此，Harness 工程其实是一门科学和艺术的混合体，很多地方非常反直觉。但它能解锁模型很多新的行为能力。我的观察是，Harness 正在变得越来越复杂，想自己“凭感觉”做一个 Harness 也越来越难，这一点反而和“模型越来越强”形成了很有意思的反差。像自动模式、工作流这些东西，本身都是很复杂的软件，却正在成为整个系统中不可缺少的承重结构。

3Anthropic 有多少改动已经完全自动化

主持人：随着大模型越来越强，人类能从执行链路里退出的环节也越来越多。在 Anthropic，你或者你们团队现在有多少改动是完全自主完成的？还有多少仍像一年前那样，靠人和模型结对完成？

Thariq：这取决于你怎么定义“自主完成”，也取决于具体团队和职能。比如设计师先做了一份 Figma 文件，工程师再把它交给 Claude Code。Claude Code 很擅长调用 Figma MCP，但设计师显然已经在前面做了大量工作。所以这算不算 Claude 自主完成，其实很难简单划线。

我们的目标大致是，让 Claude 尽可能承担那些连接不同环节的“胶水工作”。既然已经有一份 Figma 设计，还需要人再手工把它翻译成 React 吗？大概率不需要，那部分工作其实已经做过一遍了。

我更愿意问的是：我每天真正需要亲自做的、真正有独特性的工作是什么？这种独特工作，我做得越多越好。现在对独特思考和独特判断的需求非常大。反过来，只要我发现自己在做一件以前做过的事，我就会问：“Claude 能不能做？”如果我只是把别人已经做过的东西翻译成另一种形式，我也会问：“这能不能交给 Claude？”

主持人：这也让“自主完成”的边界越来越模糊。哪怕一个 PR 里的代码全部由 Claude 生成，你在过程中也可能做了很多决策、补了很多上下文。那离这样一种世界还有多远：有人直接说“Claude，这是任务单，做完之前别来找我”？

Thariq：取决于任务单写得多好。如果有人已经把它写成一份非常完整的软件 spec，那 Claude 现在其实很可能就能直接完成。

但现实里，一个 GitHub Issue 往往没这么清楚。你首先得判断它值不值得修、是不是一个功能需求。很多 Issue 其实混杂着多个问题，也许该重新组合成完全不同的方案。真正难的工作常常是：产品愿景是什么？我们到底想往哪走？怎么保证做出来的东西在整体上是连贯的？

所以，对于足够具体的 spec，Claude 可以执行。问题是，现实里人们往往自己都没想清楚到底想要什么，也没想清楚未知因素是什么、问题到底是什么。以前你可能一边写代码一边发现：“等等，我下一步到底该做什么？”然后在实现过程中把问题想明白。现在，我们需要新方法去发现那些“自己还不知道自己不知道”的东西。当然，你仍然可以直接和 Claude 讨论，但这才是真正困难的部分。

一种很典型的失败做法，就是直接在 Claude Tag 里 @Claude，只说一句“帮我做这个”，描述可能还不到一句话，没有之前的上下文，也没有记忆。然后 Claude 做完，你一看：“不对，我不喜欢。”接下来就陷入无穷无尽的迭代。更好的做法，是尽快先弄清楚自己真正想要什么。

主持人：我以前在 Meta 工作时，一个任务的模糊程度，某种程度上和工程师级别相关。当然，级别不是软件工程的一切，但大体上，高级工程师会把模糊的业务需求变成具体问题，职业早期的人更多负责实现。实习生项目甚至经常细化到接近逐行说明。如果我还在 Meta，手下有个实习生，我可能直接把原本给实习生的规格交给 Claude，它基本就能完成。

那在 Anthropic，如果 Claude 已经能做这些，实习生现在做什么？

Thariq：实际上，现在出现了大量以前从来没人做过的新工作，所有人都得一起摸索。比如，面对这些新的 Coding Agent 行为，到底该怎么做评测？Claude 服务着数以百万计的用户，他们在做各种不同的任务，有些任务之间甚至存在取舍，该怎么衡量它在这些场景里的表现？

尤其在研究侧，还有非常多新工作。现在越来越难写出那种完整明确的 spec，但与此同时，过去经验的相关性也越来越低。经验当然仍然有价值，因为你知道怎么把事情做完，也知道怎么学习，但这些能力其实刚毕业的人也可能具备。

所以现在做实习生，我觉得最有意思的不是“去写那段 React 代码”，而是去找那些以前没人做过的问题，然后把它解决。新问题太多了，需要有人去解决，而拥有一双“新鲜的眼睛”反而很有价值。和过去更像流水线式的培养路径相比，现在实习生必须更主动，也更需要抓住机会。

主持人：我们刚才聊了知识工作，这让我想到计算机使用（computer use）和浏览器使用（browser use）。它们距离真正大规模进入行业、产生明显影响还有多远？Anthropic 内部现在怎么用？你们通常会比外界早一些。

Thariq：这两块，模型确实已经进步很多。我觉得 Opus 5 已经是一个非常好的计算机使用模型，但仍然有一些很奇怪的边缘情况。比如，它没法替我输入密码，因为密码在 1Password 里，它访问不到，于是任务就卡在那里。这类问题更多是用户体验层面的。

另一方面，越来越多人正在把 API 和 MCP 变成 Claude 的新入口。这样一来，原本必须靠“操作电脑”完成的很多事情，其实可以绕过图形界面。回到刚才“知识工作的一切都可以变成代码”这个思路，确实还有一些事情没有 API，也没法直接用代码执行，只能打开浏览器点来点去。但这种情况正在减少。Claude Tag 就是很好的例子，我们一直在尽量把各种能力封装成它可以直接调用的 API。于是，即使 Claude 并没有真的启动一台虚拟电脑、移动鼠标点击，它仍然能替你完成大量工作。

主持人：我用任何 computer use 工具时，都有一个很明显的感受：太慢了。光标可能在那儿停 10 秒，移动一下，又停 10 秒。这个延迟到底来自哪里？

Thariq：很难做出一个既小又特别擅长计算机使用的模型，因为这个任务需要掌握非常多知识，还要理解很多东西之间怎么配合。所以你需要一个足够聪明的模型，而聪明的模型通常就需要更多时间。很多人原本以为我们会更早解决这个问题，但事实证明它比想象中更难。

以前有人给过我一个很好的说法：计算机其实是一台你无法完全控制状态的状态机。比如你在 DoorDash 上往购物车里加东西，结果加错了。为了撤销，你又得进入新的操作流程，去点按钮、删除，而且这个撤销过程本身也可能再出错。代码就不一样，你基本能控制全部状态，可以撤销，可以回退。计算机使用里，每一个动作即使不是不可逆，也通常比代码里的操作更难撤销。

算力怎么用，价值最大？

主持人：我感觉 Anthropic 员工在算力预算上应该比较宽裕，能用很多算力来加速工作。假设一个普通用户也有近乎无限的算力，你会建议他尝试怎样的工作流？

Thariq：我觉得 Anthropic 和外界在这方面的差异，其实没有大家想象得那么夸张。比如周末我也用自己 Mac 上的订阅，几乎从没碰到过 5 小时限制。现在模型已经很聪明了。

我们内部大量消耗算力，很多时候并不是为了“完成更多工作”，而是在探索模型到底还能做什么、尝试各种可能性。比如测试数学问题时，是为了摸清模型到底有多聪明，这本身就是有用的研究结果。模型有时可能真能解决黎曼猜想这种级别的问题，也可能毫无进展，但这都能帮我们理解它的能力边界。

普通人在家其实也能复制我们的很多做法，关键是把抽象层级提高。举个例子，我想让 Claude 帮我起草给用户的反馈。我会盯一个“漏斗”：从 Claude 起草反馈，到用户最终真的提交反馈，这个转化好不好。我自己会有一些改进想法，但也会反过来问 Claude：“这是我的想法，你也来想一些，我们一起看看怎么把这个漏斗做得更好。”

这些事普通用户现在完全可以自己做。比如开发一个功能时，可以埋一些 events，让 Claude 能读到；每天早上跑一个循环（loop），检查昨天触发了哪些事件、发生了什么变化，甚至让它主动提改进建议。所需算力其实没有夸张到不可接受。

更常见的是另一种情况：很多人很快耗尽额度，是因为一开始就选了一个太小、太中间层级的任务。比如直接说：“按这种方式重构这个函数。”Claude 做了，但重构又牵出一串下游改动，有些还不完全对，于是你来回修、反复迭代，浪费了很多时间和 Token。

如果一开始就把抽象层级提高，先告诉 Claude 你的目标，让它探索细节、找出未知问题，也许先写出数据结构或模式，等你们把方向理顺了再让它执行，往往折腾更少，结果却一样好甚至更好。

主持人：前段时间“循环”这个概念很火。Loop Engineering 听起来又是个很贵的东西，因为你等于让模型一直反复干活。你能先解释一下什么是 Loop Engineering 吗？你们用得频繁吗？如果普通人只有 Max 套餐，会不会很快就碰到限制？

Thariq：Loop Engineering 大致可以理解成：你不再直接去 Prompt Claude，而是先搭一个系统，让这个系统持续去 Prompt Claude。

如果你经常用 Claude Tag，很多 Loop 会自然出现。你只要说：“每天帮我做这件事。”这本身就是一个循环。普通用户现在完全能做。但如果你想同时搭 10 个 Loop，比如自动分诊用户反馈、自动实现修改，那确实会进入另一个量级。我们也这么做，但同时会花很多时间保证 Skills 真正有用、分诊足够可靠、验证机制足够好，最终改动能安全落地。做到这个层级，相当于多了一个人持续盯着那些过去根本顾不过来的问题，软件开发速度会明显提高。对我们来说，它的价值非常高。

所以，如果你想让一个系统真正自主运行，近似承担一份软件工程工作，在某些特定场景里现在已经可以做到，前提是验证做得好、Skills 配得好、数据源给得对。但这本身需要大量工程投入，你得确认它值得。就像招一个员工之前，也得确认这份工作创造的价值足够覆盖成本。

内部感知到了哪些重大变化

主持人：Anthropic 本身就在做 AI，所以很多使用方式会领先外界。你觉得现在 Anthropic 已经明显感受到、接下来很可能扩散到整个行业的“大变化”有哪些？

Thariq：我觉得有几个。Claude Tag 很明显就是其中之一，现在它已经是我们很多工作的主要方式。我的理解是，Claude Code 非常擅长代码实现，而 Claude Tag 更像是在处理软件开发生命周期（SDLC）里除了“写代码”之外的其余部分：收集反馈、做代码审查、盯构建流程、处理 CI/CD 和事故等等。从更高层看，下一步就是把软件开发生命周期里的每个环节都变成某种固定例程或 Loop，用 Claude Tag 或类似东西持续跑。

另一个还没真正完全到来的方向，是生成式界面。我觉得 Artifacts 会越来越成为人和 Claude 交互、阅读 Claude 输出的主要方式。我自己几乎所有事情都用 Artifacts，它和 Claude Tag 也天然能结合。比如在手机上，Claude Tag 已经替你做了一大批工作，然后生成一份报告。这个报告不是一大坨纯文本，而是做成适合手机阅读的 Artifact，排版和交互都很好。

主持人：能不能具体解释一下 Artifacts 到底是什么，人们怎么用？

Thariq：可以把 Artifact 理解成 Claude 为你生成、供你使用的一个 Web 应用。它能承载的能力非常广。现在 Artifact 甚至可以调用你的 MCP。比如，你可以做一个 Artifact 读取收件箱，把邮件展示出来、排序、打标签。也可以用 Artifact 展示一份编程计划，里面可能有图表、文件片段、代码、数据模式。它本质上是在为你当前的任务动态生成一个交互式界面。

随着 Claude 承担的任务越来越多，我们越来越意识到，纯粹“文本输入、文本输出”并不适合所有任务。Claude 越来越擅长在正确的时间，生成恰好适合当前任务的界面。这方面还有大量事情可做。你要开始问自己：我能不能换一种方式和 Claude 交互？能不能通过 Artifact 理解它、跟上它的工作进度、学到更多东西，或者改善自己的知识工作？我觉得这个方向非常令人兴奋，而且现在还处于早期。

成为 Prompt 工程高手，还值得吗？

主持人：Anthropic 工程师每天用的主力模型会因人而异吗？还是大家基本都会直接选公司里最聪明的模型？

Thariq：如果你会用聪明的模型，给它清晰的任务，再花时间搭好 verification Harness 这类基础设施，你就能从它身上释放出很多能力。

我不太认为真正重要的技能是“什么时候选哪个模型”，更重要的是怎样把前沿模型的能力发挥到最大。技术通常只会越来越丰富、越来越普及。我们现在只是处在一个有点奇怪的阶段：算力还没多到让所有人都能 100% 不限速地用上 Fable。

所以我不觉得“什么时候用 Fable、什么时候用 Sonnet”会是一项长期保值的技能。如果是我，今天我会用 Fable 做规划、头脑风暴、寻找未知问题、形成详细规格；然后用 Opus 5 来实现。执行时，我可能让 Opus 5 跑工作流，再配一套用 Fable 设计的验证辅助，比如 schema 或者 Harness。也就是说，Fable 用在杠杆最高的地方，Opus 5 负责执行和实现。

但我觉得到了明年，你可能已经不会再花太多精力考虑“这件事到底该用哪个模型”。

主持人：你刚才提到 Prompting。有人认为这个技能不会长久，因为不同模型都有很独特、甚至有点“个性”的智能特征。比如你现在把 Fable 的脾气完全摸透，成了今天这个版本 Fable 的专家，但一年后 Fable 3、4、5 出来，也许这些经验都没用了。

假设一个软件工程师来问你职业建议：“我真的值得花大量时间，成为 Prompt 工程高手吗？”你会怎么说？

Thariq：我先强调一点，Prompting 不只是你最后输入的那一句 Prompt。你可能提前做了一个 Skill，可能加了数据，还可能做了很多上下文准备。这些前置工作，最终共同构成模型看到的上下文。所以，有时人们看到我们给模型的 Prompt 很短，会问：“这么短为什么能工作？”原因是我们在 Harness、验证、Skills 上已经花了大量时间。

我觉得持续提高 Prompting 能力还是非常有价值的。你说不同模型不一样，这确实没错。每个模型都像一个独立、有机生长出来的数字实体，它会有自己的怪癖，你要学会，也要在模型变化后主动忘掉旧习惯。

比如，我们最近写过一篇文章，讲 Claude Code 的系统提示词删掉了 80%。其中一个经验就是：要把工具描述里的示例删掉。以前想让模型输出好结果，往往必须塞大量示例：这是正确工具，要在这里用；这是一个文件写得好的例子；这是一个写得不好的例子。

但现在我们发现，除非你真的观察到 Claude 在某件事上持续做得不对，否则这些示例很多时候反而会有副作用。Claude 本身已经很有想象力，也越来越擅长理解你的意图并与你协作。所以我们删掉了大量示例。

这说明你确实得不断适应。但你真正积累下来的技能，本来就是“适应”。你学会了如何使用 Fable，同时也学会了如何学习一个新模型、如何和模型协作。等 Fable 5.5 出来，你当然还需要重新摸索，但你会比从未做过这些事的人快得多。

我最早认真打交道的模型是 GPT-2。那时候想让 GPT-2 稳定输出 JSON 都非常困难。哪怕只是让它从你给定的几个分类里老老实实选一个，成功了都会觉得很惊艳。GPT-2 和 Fable 5 已经完全不是一回事，但我当时练出来的那种“怎样与模型协作”的能力，今天仍然帮助我更好地 Prompt Fable。

主持人：那对于今天的模型，有没有什么只有团队内部才知道的经验，或者一些比较反常识的 Prompting 技巧？

Thariq：我先反驳一个最近很流行的说法，就是对模型说“相信自己”之类的话。Jared 那篇关于黎曼猜想的帖子里，确实有类似“继续做，相信自己”的措辞。但我认为真正起作用的不是“我相信你”这几个字，而是 Jared 在告诉模型：这个问题值得用更多算力，我允许你这么做。

这和单纯鼓励模型不是一回事，本质上是在给它使用计算资源的许可。所以，我现在经常会明确告诉模型：“这是一个很难的问题，需要的话可以用子 Agent，可以用工作流。”我仍然会让它自己判断，但我明确告诉它：你被允许这么做。

你要记住，模型默认是按“平均用户”的偏好做优化的。平均用户希望它尽快回应、尽快开始工作、完成任务，但不要为了一个任务无限消耗算力。

所以，如果你想让模型采取另一种行为，通常需要轻轻推它一下。比如你可以直接说：“先别做任何实现，我希望你先头脑风暴，先和我一起想。”它就会切换到这种模式；又或者你认为这是一个难题，就说：“如果需要，可以自由使用 workflows。”如果我要让它通宵跑任务，我甚至会说：“我要睡觉了。”然后设一个 /goal 之类的目标，让它自己继续跑。

本质上，就是明确允许模型做你希望它做的事情。

大幅删除系统提示词后，真变好了吗

主持人：你们最近大幅删除系统提示词之后，是怎样证明结果真的变好了？

Thariq：我们有很多用户指标，比如用户到底喜不喜欢 Claude 的输出。有时你会看到产品里的调查，我们也会跑内部评测和外部评测，看不同任务上的表现。但这件事真的很难，会出现一些你根本没预先写进评测里的新行为。比如 Claude 把所有工作都做完以后，突然对用户说：“你也许该去睡觉了。”根本不会有一个现成的评测叫“Claude 会不会劝用户去睡觉”。于是你又得发现、捕捉这种新行为。

因此，我们实际上花了非常多时间，一行一行删系统提示词，跑评测，看效果，再观察内部用户怎么反馈，然后继续调整。这是好几个人长时间的全职工作。

我不建议每家公司都自己重复这套极端迭代。我们之所以把调整系统提示词过程中学到的东西写成文章，是因为我们认为这些经验有比较强的通用性，希望其他人不用再走一遍这种疯狂的迭代过程。

怎样让模型做出“有品位”的工作

主持人：很多人用 Claude Code 做目标明确、标准客观的工作时，结果都很好。但如果让模型做“漂亮”“有品位”这种更主观的东西，比如前端设计，结果就会更不稳定。你怎样把一种非常具体的风格或审美传递给模型？

Thariq：首先，你得 human-in-the-loop；其次，要给它参考，而且参考越接近结构化数据越好。

比如，给一个 HTML 文件通常比给一张截图更好；给一份 Figma 文件也比给一张栅格图更好。因为如果 Claude 想知道某个组件的圆角半径，它可以直接读取 Figma 组件里的 border radius，然后照着实现，而不是从一张图片里猜。

所以，给模型大量参考，最好是代码形式的参考，这是让它稳定遵循某种风格非常有效的方法。如果你手里没有这些参考，或者你自己根本不是设计师，那第一步反而应该承认：“我不是设计师，我对设计还有很多东西不懂。我甚至不知道什么才算好。”

这其实也是和设计师合作的一部分艺术。好的设计师就是知道什么叫好，他们会直接指出：“这里还不够好，因为这个地方有问题。”这种判断本身就是在 Prompt 模型。

我认为未来越来越有价值的一种能力，就是知道什么叫“好输出”，以及什么事情值得做。比如之前黎曼猜想那个案例，Jared 可以去 Prompt 模型，但他自己并不知道结果到底对不对。直到 Lev，他是世界上最好的数学家之一，开始认真审视结果，持续追问很多问题，他才能判断这个结果有没有价值。我们其他人甚至跟不上他们在说什么，但 Lev 会觉得其中某些地方非常有意思。

所以，越来越重要的是成为一个“高品位用户”，真正理解所在领域的问题。你只有足够懂，才有能力判断模型给你的到底是不是好结果。否则，也许 Claude 真解决了一个物理学问题，你都可能看不出来，因为你根本没有足够的知识去判断。

回到设计也是一样。第一步不是“怎么让 Claude 更会设计”，而是“你自己怎么变得更有设计品位”。你完全可以让 Claude 帮你做这件事。比如告诉它：“我不是设计师，我想提高设计能力，我连描述设计的语言都没有。我们先找一些参考网站。”然后你去看这些网站，说“这个我喜欢”“这个我不喜欢”，慢慢建立自己的参考集合，再交给 Claude。接着可以说：“这是我的审美方向，我们先探索几版。”让它做几个不同的 Mockup。

我很喜欢用 HTML 做 Mockup，因为它一个文件就能跑，改起来也方便。等你得到一个满意的 Mockup，它本身又变成了新的参考。然后你可以开一个新会话说：“这是我想要的设计 Mockup，现在开始实现。”因为所有东西都已经是代码，Claude 可以直接往下做。

真正困难的其实是判断什么时候“已经够好了”，什么时候应该逼它继续往前。数学证明也是同一个道理。Terrence Tao 会说：“别再给我半完成的定理了，直接把完整定理做出来。”这句话听起来很简单，但你得有非常强的领域知识和判断力，才能知道模型其实已经聪明到足以继续完成下一步，并且知道下一步到底该要求什么。

Anthropic 的文字工作有多少已经交给 AI

主持人：我以前做软件工程时，有很多“胶水式写作”：项目做完要写发布文章，在一个工作流里每隔 2 到 4 周发一次更新，或者写方向文档、设计文档。也就是说，代码之外还有大量围绕软件的写作。Anthropic 现在这部分变化大吗？其中有多少是大语言模型写的，多少还是人写的？

Thariq：我的经验法则是：只要我愿意把 Prompt 给别人看，通常也就愿意把模型输出直接发给别人。

最典型的场景其实是收集上下文。比如每次和经理一对一之前，我都会让 Claude 把相关的 Slack 消息、GitHub 信息、PR 等都读一遍，然后整理成一份“我最近都做了什么”的报告。这些上下文我经理并不掌握，他不可能把我所有 PR 都看一遍，所以我完全不介意让 Claude 来做这件事。理论上，经理自己也能运行同样的命令，但他没有我这里的上下文，我也不介意告诉他：“这就是我用来生成这份报告的 Prompt。”

如果只是同步进展，你至少得证明自己读过、理解过结果。有时改几个地方、补一句话，本身就是在向别人证明你理解了这项工作。如果只是数据汇总，你需要做的是检查数字是否合理、是否覆盖了你真正想展示的全部指标，也许再重新排一下格式，补一两句解释。它本质上还是数据汇报。大家也都知道，你背后的 Prompt 大概就是“根据这些信息生成这个功能的进展报告”，这没什么问题。

但如果你是在提出一个全新的概念、一个新的产品方向，而你的 Prompt 只是“帮我想一个这个产品的新概念”，那别人通常会希望确认：这是你真的相信的想法。哪怕 Claude 给出的想法棒到你一个字都不想改，我也会明确说：“这是 Claude 生成的，但我认为它非常好。”或者说：“我跑了 100 个版本，我觉得这个最好，所以我想把它分享给你。”

我觉得坦率说明来源非常重要。人们真正不喜欢的是被误导：他们以为这是你做的工作，后来才发现实际上大部分是 Claude 做的。

还有一些写作，单个词本身都很重要。Twitter 上的一条推文就是很有意思的例子。每一个词都可能承载你自己的判断和意图。对于这种东西，反而越来越不适合直接让 Claude 完成。Pitch、Essay 也是类似。Anthropic 内部会写很多 Essay，比如“为什么我认为公司应该做这件事”。这类东西基本都是人自己写的。我觉得如果你让 Claude 代写这种 Essay，在内部甚至会有点被看不起，因为这里每个词本来就应该反映你自己的意图。

主持人：所以可以理解成，那些比较机械的写作，像数据汇总、一对一更新、工作流进度更新等，越来越多由 AI 起草，人再审一遍；真正新的思想、新方向仍然主要是人自己写，而且哪怕模型更强了，这部分也应该继续由人承担？

Thariq：对。写作本身也是思考方式。如果你其实需要认真理解一份数据流、数据汇报，也许你就应该自己去做一次总结。但“收集上下文”这类事情，基本没人会因此责怪你。你做了很多研究，其中的信息搜集由 Claude 完成，这完全没问题。至少对我来说，我不会想让自己的 Agent 再去重复别人已经做过的一模一样的研究。它确实是一个捷径，但只要承认这一点就好。

主持人：我跟别人聊过一个想法：以后也许需要一种类似 git blame 的东西，但不是追踪“哪一行代码是谁提交的”，而是追踪“哪一个 Prompt 生成了这次改动”。这样出问题时，就可以反向查出当时的 Prompt。你们有没有针对生成软件的 Prompt 做某种元版本控制，还是主要仍然依赖普通 Git 历史？

Thariq：这其实有点难，因为进入一次生成的不只是 Prompt，还包括上下文、Skills 等等。一个 Prompt 看起来可能非常简单，但背后其实并不简单，所以只记录那一句话并不一定有意义。

不过，我现在发 PR 时，会把它看成和 Artifact 很接近的东西。Claude 已经基本在做所有代码编写，如果我要把一个 PR 发给别人，通常会同时附一个 Artifact，把我发给 Claude 的所有 Prompt 都列出来，包括那些失败的尝试。这样别人可以看到我其实考虑过很多其他方案。

如果我没有做过很多尝试，而就是一次 One-shot，我也会直接告诉别人：“这是一次 One-shot，这是我用的 Prompt。”很多时候这反而会让人觉得很有意思：“原来 Claude 一次就能把这个做出来。”

我最想避免的情况是：突然扔给别人一个一万行的 PR，对方完全不知道我到底看过多少、我和 Claude 到底怎么一起做的。所以，如果是大 PR，我会尽量把自己的工作过程展示出来。

故意留下技术债，让下代模型解决可行吗？

主持人：AI 现在可以生成极大量代码。在 Anthropic，你们在代码所有权和维护方面有哪些实践比较有效？

Thariq：我觉得首先要重新审视：代码维护里，到底什么还重要。

以前命名非常重要，因为它体现了一个团队怎样理解某个抽象、某个功能。但我觉得命名的重要性正在下降，很多代码风格上的东西也正在变得没那么重要。对我来说，这些东西和“可维护性”并不是一回事。你可能真的应该坐下来重新问：现在到底哪些事情重要？哪些不重要？我们过去坚持的哪些观点，其实已经没有那么大意义？

第二是，维护侧要有好的脚手架，尤其是好的 verification Harness 和 Skills。我们常用一个“简化 Skill”，模型可能已经做了很多工作，这时候你只要明确告诉它：“我觉得这个方向是对的，现在把它简化。”这相当于给它许可，让它进行进一步抽象和清理。

但你不会希望模型默认每次做完都马上简化，因为最初实现可能本身就是错的。如果一个错误方案还没验证，你就开始“优雅地简化”，只是白白浪费 Token。人类也是这样：先发散地想方案、尝试，然后在确认方向以后再简化、抽象。所以，你需要在代码库和 Skills 里建立一套实践，确保不会把第一版直接提交，而是会再做一次简化、验证和迭代。

另一个关键是拥有非常好的 verification Harness，让你有足够信心 Claude 真正测试了系统的每个部分。比如你向 Claude Code 提交一个 PR，它会返回一段录屏，展示这个功能实际如何使用、怎样完成测试。

测试方式可以非常有创造力。我甚至觉得，你今天应该拥有比过去多大约 100 倍的测试代码。几乎所有东西都应该有测试夹具。你可以从生产数据生成数据库用的 fixtures 和 Mock，前端可以准备 Storybook，还可以为代码建立各种不同的测试和验证方式。对我来说，这些验证能力才真正提升了可维护性。

当然，还有一个人类层面的问题：你希望代码库最终往哪里走？如果你知道未来方向，就知道哪些性质必须提前保留。

比如，如果系统未来是多人协作的，那么 replay、undo、redo 会变得非常重要。单人应用里这可能没有那么关键，普通用户几乎不会连续撤销 100 次，所以很多单人应用的 Undo 可能四五步以后就不再完整工作，也没那么大问题。但多人系统里，不同操作能否组合、不同状态能否合并就会变得非常重要。这就是一个例子：你知道代码库要去哪里以后，就能告诉模型哪些性质是真正重要的，并把这些东西写进 Skills。

所以，对我来说，可维护性真正意味着：你要清楚这套代码擅长什么、未来要去哪里，并持续让它保持在那条轨道上。

另外，模型越来越强以后，我觉得几乎每一个代码库都会迎来这样一个时刻：你会认真问自己，“要不要干脆让模型把它全部重写一遍？”因为到那时，你可能会想：我可以直接换成性能最好的语言，也可以自由混搭技术。

理论上，世界上几乎没有理由让所有软件不能在浏览器里通过 WebAssembly 运行，甚至你的 Xbox 游戏为什么不能直接在浏览器里运行？现在很多游戏主机的硬件其实还不如一台普通 MacBook，真正限制你的可能只是既有代码库。所以未来 1-2 年，每家公司大概都得重新想一遍这件事。

我并不是说可维护性不重要，而是说你不能继续沿用旧时代关于“什么叫可维护”的心智模型，你得更新这套定义。

主持人：我有个朋友就说，他现在故意留下大量技术债，反正下一代 Fable 出来后，也许一次就能把这些技术债全部清掉、顺便重构，现在为什么要浪费时间。听起来挺好笑，但好像也不是完全没道理。

Thariq：我觉得这并不完全错，还是要看具体情况。其实这也是创业公司一直都有的经典问题：到底该重构、还技术债，还是直接继续给客户交付价值？关键问题一直都是：“这次重构现在能不能帮我更快交付客户价值？”

总体上，我觉得现在应该用更短的时间尺度思考项目，你应该问：“未来 1-2 个月，我怎样交付价值？”

如果你讨论的是一个 6 个月甚至 12 个月以后才能产生价值的项目，那也许真的可以稍微等等下一代模型。先在短时间尺度上把眼前价值交付好。如果当前模型还不够强，也许它很快就会强到能做。当然，这高度依赖具体情况，我不是说所有技术债都应该拖着不管，但它已经变成一个值得放进决策里的新变量。

怎样防止“代码越写越快，事故也越来越多”

主持人：我跟一些 Google、Facebook 这类大公司的朋友聊过。随着团队越来越“AI 原生”，他们发现事故、严重故障（SEV）似乎也变多了。这其实不难理解：大家读的代码更少了，但产出的代码更多了。Anthropic 的代码速度也非常高，你们有哪些防止系统出问题的有效措施？

Thariq：这确实可能是“跑得更快”的副作用之一，我们也还在持续解决。我觉得 Anthropic 现在的可用性也没有到我们理想中的水平。但也要看到，公司成立至今大约才 6 年的时间，但经历了非常快速的增长。过去几乎没有公司以这样的速度扩张，而其中一个原因，就是我们现在可以比以前更快地创造新产品。

同样，你也可以用 Claude 去改善可用性问题。我们的思路是，理想中的测试环境到底应该是什么样？理想中的部署环境又该是什么样？能不能把真实请求重放到各种 Mock 数据库、fixtures 上？能不能对所有东西都做类似 Chaos Monkey 的混沌测试？

也就是说，不只是“AI 让你写更多代码”，而是也让你以前根本负担不起的验证、测试、故障演练变得可以大规模执行。

主持人：我自己的工作流里，现在多了非常多零散的自定义工具和脚本，纯粹就是为了把各种事情做快一点。Anthropic 团队里是不是每个人也都有自己的一套杂项工具？

Thariq：是的，基本人人都有。我甚至觉得这就是工作的一部分。我们会经常玩各种 Harness。有时团队里有人会先自己做一个 Harness，用一段时间，看这种新想法到底有没有价值，如果验证有效再把它整合进产品。这某种程度上就是工作内容本身。

还有很多人都有非常个性化的 Claude 配置。Claude Tag 就很典型。比如我把日历安排交给它，如果有人想约我，我会直接说：“你就在这个频道里 @Claude 吧，它往我日历上放什么我都接受。”很多人也会用它处理邮件。我还见过一些很有意思的多 Claude、tmux 风格工作台：比如同时显示 50 个 Claude Code 实例，然后设计一套最适合自己的方式，快速知道每个 Agent 此刻分别在干什么。

因此，其实有很多不同玩法。我们也在努力让 Claude Code 变得更 Hack、更容易改造，让更多人可以做出属于自己的 Claude Code 版本，每个人都能加上一点自己的个性化变化。

“公开分享工作，让我拿到了 Anthropic offer”

主持人：你在 Anthropic 的角色有一点挺特别：你在圈外也很有存在感。很多人给职业建议时总说“要多提高曝光度”，但他们自己未必真有你这么高的曝光度。你会建议软件工程师多上 Twitter/X 这类平台发东西吗？如果会，你有什么建议？

Thariq：我一般都会建议大家：只要条件允许，就尽量把自己的工作公开分享出去。

当然，有些公司可能不方便让你公开内部工作，但你可以做副业项目、个人项目。加入 Anthropic 之前，我花了很多时间和不同公司合作，做一些东西，然后把过程和结果写出来、讲出来。这对我非常有价值，因为它让好运更容易找上我。

而且，这件事的门槛其实比你想象得低很多。每次有人来问我职业建议，我基本都会先告诉他：“这套建议我已经给很多人讲过，从统计上看，真正照做的人少得惊人。但那些真正照做的人，最后要么找到了自己非常兴奋的工作，要么干脆创办了自己的公司。”

你当然会有无数理由不想做这件事。但如果只让我给一条非常具体的建议，我其实不太在乎你的简历，也不会建议你把主要精力放在那上面。你应该选一个真正有意思的项目，认真投入，把它做出来，然后发布，并写下来。一定要做完这整个闭环。这个过程中，你会给自己找到无数借口：“现在还不够好”“这个东西没什么值得写的”“没人会关心”。但还是得发布，而且不能因为第一次反响一般就放弃，下一次还要继续做。

Twitter 不一定是最合适的平台，也可能是 Reddit，可能是某个垂直 Subreddit，也可能是 Hacker News。你真正要做的，是找到那些会对你做的事感兴趣的人。

现在大家消费的内容比过去任何时候都多，但人们真正想要的还是高质量内容，而高质量内容就是很费功夫。回到我们刚才聊的“你愿不愿意把 Prompt 给别人看”，很多人其实总在找捷径：“我是不是直接让 Claude 帮我运营 Twitter 账号，就能把影响力做起来？”我觉得不是。你还是得真实地和别人交流，认真做出好东西，再认真把它讲出来，慢慢建立自己的网络。

只要你真的把“让别人看到你的工作”当成目标，并且持续努力，我几乎没见过完全没有收获的人。但这确实很难。它有点像“我要每天去健身”或者“我要减肥”，方法本身可能不复杂，但极其需要纪律，也很容易中途泄气。所以，我非常看重公开发布，或者更准确地说，持续把自己的工作写出来。

主持人：你刚才提到了更多好运，有没有一个具体例子？

Thariq：可以直接说我自己是怎么拿到 Anthropic 这份工作的。

当时我参加了 Goodfire 的一个 Fellowship，做了一些应用研究。Goodfire 是一家做 AI 可解释性的公司，我当时想研究一个问题：能不能把可解释性真正用到产品里，让产品变得更好？

于是，我先去理解他们的研究，然后决定做一个项目。对我来说非常重要的一点是，我从一开始就明确想把最终成果公开出来。所以在跟他们合作时，我就说：“我的目标之一就是把我正在构建的东西分享出去。”这对 Goodfire 也有好处，因为它是一家创业公司，本来就希望更多人知道他们在做什么。

后来我做了一个可解释性可视化，然后把它发了出来。那应该是我第一次在 Twitter 上真正意义上的“大帖子”。现在看可能也就 500 个赞，按今天的标准不算多，但当时对我来说已经非常夸张了。

有几个人看到了，后来有人私信我，接着又有人帮我介绍到了这里的工作岗位。整个项目我大概只花了 1 个月，并不是一个夸张到不可复制的投入，但它很好地向别人证明：我能够做有意思的工作。而且我当时还是有报酬的，并不是完全打白工。

这种机会其实有很多。如果你愿意表现出这种主动性，别人往往很乐意给你机会。但这里确实没有捷径，你还是得真的做出新东西，认真投入，而且自己得为这个工作感到自豪。一旦你真的做到了，外面一直有人在寻找有趣的工作，也有人愿意支持你、雇你，或者给你资金。好事情会因此越来越多。

“编程基本已经解决了”，还要学编程吗？

主持人：最近围绕 Anthropic 有一个说法流传很广，好像是 Boris 上一些播客时提到的：编程基本已经解决了。如果编程真的大体已经解决，人们还应该学编程吗？

Thariq：我觉得保持技术能力仍然非常、非常重要。

你需要理解计算机到底怎么工作，程序怎么运行，编程语言怎么工作，真正困难的问题是什么。什么是后端服务，什么是缓存，什么是内存分配……这些基础概念仍然非常值得学。

我也承认，现在确实更难有动力去学这些东西。这有点像以前让我手算数学题，我自己并不会特别有动力，但有些人就是特别喜欢数学，会主动去做。每个人可能都得自己找到适合的学习方式。但我仍然认为值得，因为“技术理解力”非常重要。

我们前面聊过黎曼猜想和雅可比猜想。模型是不是真的解决了问题、有没有真正取得进展，最终还是要足够强的数学家才能判断。同样，软件是不是做得足够好，也需要真正优秀的软件工程师才能判断。

怎样成为这样的人当然很难。一个办法就是始终让人参与其中，经常反思自己的过程，不断改进。你也可以用 Claude 来学习，让它给你解释，把它当作思考伙伴。但真正的学习还是需要付出努力。

Karpathy 说过一句我很认同的话：学习应该让你感觉到“费劲”。现在一个危险是，你让 Claude 给你解释一个东西，它说得很顺，你跟着点头：“对对对，我懂了。”但你其实没有真正学会，因为你没有为理解这件事投入任何认知努力。所以，技术基础仍然应该认真学，而且这本来就很难。学校有一个作用，就是逼你去完成这种艰难的学习。

说实话，我现在不是一个从零开始学编程的人，所以我也不知道今天最完美的学习路线应该是什么。如果没有更好的方法，我可能仍然会亲手输入代码，自己构建程序、运行它，看它怎样工作，再从里面学习。也许未来会出现更适合 Claude 时代的学习方式，但我认为底层理解非常重要。

至于 Boris 说“编程已经解决了”，我理解他的意思不是“软件工程已经没有事情可做”，而是我们不再像过去那样被代码实现本身卡住。

以前编程是一件方差非常大的事情。你碰到一个 Bug，完全不知道它会花 1 天还是 2 周。软件项目整体上，真正顺利推进的概率其实并不高。全世界真正能把软件写好的人本来就很少，即便你把这些人都聚到一起，还有一大堆其他因素会让项目失败。

软件开发曾经是一种极其稀缺的能力。一个普通企业如果想为自己定制软件，比如一家汽车经销商找人开发一套系统，大概率最终拿不到真正想要的软件。你甚至会感觉自己像是被“骗”了——不是因为开发者真的想骗你，而是因为软件本来就太难了。因此，过去软件开发资源只能优先投入到那些最重要、最有规模效应的事情上。

今天所谓“编程已经解决”，我的理解是：我们终于可以把编程能力用到大量以前不值得做、做不起的事情上。这并不意味着工作量消失了，而是“写出软件”不再是一件极其稀缺、极其困难、经常根本做不成，而且要求你每天锁在屏幕前 8 小时才能推进的事情。

主持人：最能体现这种预期变化的一点是：我以前写软件时，如果第一遍就跑通，我反而会震惊：“等等，怎么直接就能跑？”大家默认就是要先撞几次墙，也许只是漏了一个分号，都得调一阵。

现在我的预期几乎完全反过来了。Claude 给我东西以后，如果它第一次没跑通，我第一反应反而是：“等等，发生什么了？Claude 怎么没做对？”我现在默认它第一次就应该能工作，这真的很疯狂。

Thariq：对。人一旦过上好日子，很快就会习惯。

最近有人分享过一篇文章，大意是带你在现代公寓里走一圈，看看那些今天习以为常、但过去的人根本无法想象的东西。比如你可以随时播放一段符合自己心情的音乐。放到过去，你可能得雇一个音乐家，专门为你现场演奏甚至创作。但从整体上看，我猜今天靠做音乐拿到收入的人，可能反而比历史上任何时候都多；音乐触达的人也比过去更多。

我觉得软件、数学以及很多其他领域都会发生类似事情。只要某种能力变得丰裕，人们不会说“够了，我们不需要更多了”，反而会说：“太好了，我还想要更多，我希望软件无处不在，就像今天音乐无处不在一样。”

主持人：这次对话里其实还有另一个证据，说明人们仍然应该保持技术能力。我们前面聊知识工作自动化时，你提到技术人员有明显优势，因为他们知道怎样协调 Claude 调用各种工具。比如你会想到用 FFmpeg 自动化视频编辑，但一个完全不懂技术的人，可能根本不会想到还有这种路径。所以，即使模型已经承担了大量执行工作，“理解计算机怎么工作”本身仍然很有价值。

Thariq：对。你也可以类比 CEO。很多最优秀的 CEO，本身都非常技术化，比如 Zuckerberg、Elon。他们也许已经很久没有真正亲手写过一行代码，但他们理解系统怎样运行，知道约束在哪里，这非常重要。所以，即使具体工作形态改变了，技术理解仍然非常重要。

主持人：最后一个问题。如果你能回到刚进入这个行业的时候，用今天知道的一切给年轻的自己一些建议，你会说什么？

Thariq：我觉得这里有两股力量，有点像两只狼在较劲。

一方面，你必须相信自己。我觉得这非常重要。至少我刚入行的时候，人们对年轻人的信任没有现在这么强。像 Y Combinator 之所以当时显得很特别，其中一个核心理念就是很早就愿意相信年轻人可以做非常了不起的事。

所以回到我们前面关于实习生的话题，我觉得年轻人不应该只把自己看成“正在接受训练、等以后才有能力做事的人”，而应该相信自己现在就有可能做出真正很了不起的东西。

我很希望当年的自己做过更多、更大胆的项目，并且把它们写下来、分享出去。我以前也有过很多觉得很有原创性的想法，甚至确实做出了一些东西，但没有用一种能长期留在互联网上的方式公开。那时候，“把工作分享出来”并不是我的明确目标。如果能重来，我会更大胆一点，把更多工作真正做出来、发布出来。

但另一方面，你也必须承认别人身上有很多值得学的东西。

年轻时很容易落入两个极端：要么不够大胆，总觉得自己还不配做大事；要么太大胆，完全不愿意理解别人过去已经做过什么、为什么有些东西之前行不通。这两者之间需要平衡。每个人失败的原因都不一样。回头看，我自己可能没有充分利用导师，以及那些已经积累了大量经验的人，因此后来有不少东西，我其实不得不重新学一遍。

所以，我觉得不存在一条对所有人都通用的完美建议。但刚入行时，这两件事都值得经常提醒自己：既要足够相信自己，也要足够认真地向已经走过这条路的人学习。

参考链接：

https://www.youtube.com/watch?v=2Kch3tWMnw8

文章来自于微信公众号 “InfoQ”，作者 “InfoQ”