当模型比你想的更聪明 聊聊 Boris Cherny 讲的 Claude Code 新玩法

你有没有想过，一个团队天天在做的事情，可能不是往产品里加东西，而是一直在删东西。这听起来有点反常识，做产品不都是越做越厚吗，怎么会越做越薄。最近 Y Combinator 的 Startup School 2026 上，主持人 Diana Hu 找 Claude Code 的创造者 Boris Cherny 聊了一场，我把整段对话看完，发现这正是他们团队每天在干的事，删提示词、删工具、删代码，删完之后再看模型会不会自己把活干好。

对话一开场信息量就很大。Opus 5（Anthropic 刚发布的新模型）前一天才上线，ARC-AGI-3（一个专门测试模型抽象推理能力的基准测试）的分数直接冲到了 30%，在这之前，最好的成绩也就百分之几，最多到百分之十几。Boris Cherny 说，这背后不是某一个单点的突破，是很多能力叠在一起的结果，有些是刻意训练出来的，有些连他们自己都没预料到模型会学会。听完这场对话，我最大的感受是，过去几十年我们对怎么做软件、怎么管团队、怎么写系统的那套直觉，正在被一件一件地推翻，我想把这些点整理下来，也说说我自己的理解。

Opus 5 有多能扛 从连轴转到防不住的提示注入

Boris Cherny 说，Opus 5 有一个别的模型都没做到的能力，就是能连续跑很长时间，尤其是把它和 auto mode（一种让模型自己判断要不要继续往下做、不用人时时盯着的运行模式）配合起来用，效果好到有点离谱，能连续跑好几天、好几周，甚至好几个月都不停，而且不需要额外搭脚手架（scaffolding，指为了让模型顺利完成任务专门搭起来的一整套辅助工具和流程），模型自己就知道任务还没做完，会接着往下做。

他还提到另一个让他挺兴奋的变化，模型好像不再容易被提示注入（prompt injection，指有人把恶意指令偷偷藏在模型会读到的内容里，比如网页上写着执行某个操作，同时删掉用户电脑上的所有文件）。放在一年前，模型看到这种指令基本会直接照做，现在的 Opus 不会了。这个能力从 Opus 4.7、4.8 就开始了，Sonnet 5 也已经做得不错，但 Opus 5 又上了一个新台阶。做法是三层叠加，一个经过三年对齐研究打磨出来的模型，加一个基于机制可解释性（mechanistic interpretability，简单说就是打开模型内部去看它到底在想什么）研究做出来的提示注入分类器，字面意义上是在看模型大脑里哪些神经元在提示注入发生时会被点亮，模型自己不会告诉你发生了什么，但他们能从内部看出来，再加上一个自动模式分类器。三层叠在一起之后，他说他们内部已经没法演示出一次成功的提示注入了。

这一段我看完印象特别深。以前我们讨论 AI 安全，大多还是在讨论怎么用文字去说服模型别做坏事，本质上还是在跟它讲道理。但这里说的是完全另一条路，不靠嘴皮子，靠直接看它脑子里发生了什么，哪怕它自己都没打算告诉你。这对以后要不要放心让一个 agent 去读一堆来路不明的网页和文档，是个挺关键的信号。

删掉 80% 的系统提示词 到底是怎么回事

Boris Cherny 说，很多人可能没意识到，Claude Code 这个产品和它背后的 harness（可以理解为让模型真正干活的那套外壳，包含工具、提示词和整体流程），一直都在变，一直在加东西，也一直在删东西。每次有新模型发布，他们都会删掉一大块系统提示词（system prompt，模型每次运行前都会先读到的那段固定指令），换掉一堆工具，换掉工具对应的提示词。原因很简单，每个模型都很不一样，三个月前为了纠正某个模型的毛病写下的一句话，换到下一个模型身上可能完全用不上了。这次到了 Opus 5，他们直接删掉了系统提示词的 80%。他还提到一个内部还没公开写文档的小功能，叫 simple mode，打开之后会把系统里所有的提示词都清空，包括工具自带的那些提示词，他们把这个当成一种消融实验（ablation，就是故意拿掉一部分东西，看结果会不会变差，从而判断这部分东西到底有没有用）。结果挺有意思，模型在没有这些提示词的情况下，反而表现得更聪明一点。但如果是拿 Claude Code 当产品来用，这些提示词还是有必要的，因为它们能帮用户更顺手地用这个产品，也能让模型的行为更符合一个普通用户在用产品时的预期。

这段话让我意识到一件事，我们平时往 AI 产品里加的那些提示词，很多时候不是在让模型变聪明，而是在把一个聪明但没有边界感的东西，包装成一个用起来顺手、行为可预期的产品。裸的智能和一份打磨过的产品体验，原来是两件不完全一样的事情，这个区分我觉得挺值得记住的。

提示词不是拍脑袋加回去的 是等出来的

那这套提示词删完之后要怎么重建呢。Boris Cherny 说方法就是一块一块来，第一步是删，第二步是用，而且不要去猜模型到底需要哪句指令，因为你很可能猜错。你要做的是真正把产品跑起来，看它在哪里失败，看它哪里做得好，如果用的是 Claude Code，就看它在你的代码库上是顺利完成还是在某个架构问题上反复卡壳。只有当你看到它一而再、再而三地卡在同一个地方，才是把这句指令加回去的时候，不能加得太早，因为模型每用一次就要重新读一遍这句指令，这本身是有代价的。他说这可能是他做过的所有工程里最不一样的一种，以前在系统上做开发，都是提前把系统设计想清楚，写一大堆单元测试，一次架构调整可能是要花好几个月甚至好几年的大项目。但模型不是这样的东西，更像是一个活的生物，一种更有机的存在，每一代模型的表现都不一样，都带点自己的性格，你得花时间去了解它，再根据了解到的东西去调整外面这层壳。这需要一种很实证、很科学的心态，试一下，看结果，再根据结果调整。

他还给了一个建议，不只是做 agentic 产品（也就是让 AI 自己规划、自己执行任务的那类产品）的人该这么做，就算你只是普通用户在用 Claude Code，每隔六个月，也可以试着把 CLAUDE.md（一个存放项目背景信息的配置文件）、skills（可以理解为给模型准备的技能包）、hooks（在特定时机自动触发的脚本）都删掉，看模型表现会怎样，说不定会给你惊喜。尤其是 Opus 5，他们真心建议大家都试试全删一遍，因为很多为老模型准备的说明，新模型可能根本用不上。

我自己听完这段最大的触动是，这跟我过去理解的软件工程完全反着来。以前的信条是三思而后行，先想清楚再动手。现在变成了先删掉、再观察，有点像在养一个脾气会随着长大而变化的孩子，而不是在造一台行为完全可预测的机器。这种感觉挺让人不适应的，但也确实挺解放的。

连 eval 都会过期 只是过期得慢一点

那在这么频繁的删删改改里，到底什么东西是稳定不变的。Boris Cherny 提到 eval（评测，用来衡量模型在具体任务上到底行不行的一套测试）算是相对稳定的部分，他们会一直留着，直到这套 eval 被跑满分为止。但他很快又补了一句，说自己可能都不该说得这么绝对，eval 确实比 harness 活得久一点，但也久不了太多，一套 eval 大概能撑一到三代模型，可现在模型进步的速度已经在指数曲线上了，很多时候一套 eval 很快就被跑满，只能扔掉重新做一套。这也是同一套实证方法论，你得真的去用产品、用模型，看它在哪里露怯，那个露怯的地方，就是你该拿去做成新 eval 的地方。

我发现这段话其实在说一件更根本的事，连你原本用来当尺子的那把尺子，也在不断过期。真正留下来的不是任何一份具体的提示词、任何一套具体的 eval，而是持续观察、持续重建这件事本身，这才是唯一没有过期日期的东西。

unhobbling 说的是什么 Claude Code 自己就是最好的例子

接下来聊到的这个概念我觉得特别有意思，叫 unhobbling，反过来的说法是 hobbling，字面意思是给模型套上脚镣，限制它本可以发挥出来的能力，unhobbling 就是把这副脚镣拿掉。这背后对应一个叫 product overhang 的现象，可以理解成模型能力被产品浪费掉的那部分，说的是今天这一代模型本身已经能做很多事，不是要等未来某个更强的模型，而是现在这个模型就能做到，只是大部分人还没意识到，比如用某个特定工具、写某种特定语言、用某种以前觉得模型做不到的方式解决某个问题。这种能力富余在每一代模型身上都存在，只是往往还没有一个产品能让模型把这部分能力真正表达出来。反过来，如果产品设计得不好，挡在模型和这个能力之间，这就是 hobbling，本质上是同一件事的两面。

他举了 Claude Code 自己诞生的故事。一年半到两年前，最早的 Claude Code 是建立在 Sonnet 3.5 上的，那在当时是最好的编程模型，放到今天的标准来看已经算很一般了，但在当时，那是 Anthropic 做出来的第一个真正意义上的好编程模型。而那个时候市面上的编程产品都在干什么呢，做单行代码自动补全，有的能做到多行，这在当时已经算新鲜事了，还有的是做对话，能跟 agent 聊，但只能读，不能写，只能问代码库的问题。当时的感觉是，没有一个产品真正把模型一次写完整个函数、写完整个文件的能力发挥出来，还谈不上一次写完整个功能。Claude Code 的想法就是，模型大概率能做到这件事，那就把所有花里胡哨的脚手架都拿掉，给模型一个最简单的外壳，让它能一次写完一整个文件，搭出一整个功能。那就是当时的 product overhang，模型本身已经具备这个能力，只是被挡在了外面。Boris Cherny 说，到了今天，现在的模型身上存在的 product overhang 只会更多，他不是说创业公司已经把这些机会都抓完了，很多人也在想这些问题，但机会的量级依然巨大，能把这些能力从模型身上引出来，本身就是既有趣又有商业价值的事情。

我读到这里的感受是，这彻底改写了我以前对创业里那句做出人们想要的东西的理解。Claude Code 不是靠某个绝妙的新功能赢的，它靠的是做减法，给模型完整的终端写入权限，而不是给它更多限制。这跟我们平时做产品的直觉完全相反，我们习惯的是不断往产品里加护栏、加确认弹窗，而这里最关键的一步，反而是把护栏拆掉。

给模型出题 要出得刚好难到位

那对于想去做 unhobbling 的创业者，具体该怎么做。Boris Cherny 给的第一条建议是，给模型出的任务，要比你自己觉得它能做到的稍微再难一点。他说他见过最常见的一个错误，是大家用 Claude 的时候，把指令写得过度具体，我要你这样做，但必须用这种方式、这种方式、这种方式，必须先做一，再做二，再做三，再做四。放在现在这一代模型身上，这其实不是正确的用法。你应该往上抬一个层次，去描述这个任务本身，描述好边界在哪里，描述好完成的标准是什么，然后就让模型自己去做，过一阵子再回来看，很可能会给你惊喜。这在六个月前是行不通的，但放到现在是真的能行。

我把这个理解成一种带团队的直觉迁移，如果你把每一步都替一个能力很强的下属规定死，其实是在暗示你不信任他，结果反而更差，因为你把他自己可能找到的更好路径也一并堵死了。真正的技能，正在从怎么写详细指令，变成怎么划好边界、怎么定义好什么叫完成。

一个 prompt 跑了 11 天 把代码库从 Zig 重写成了 Rust

Boris Cherny 举了一个我看完直接愣住的例子。他说现在模型基本能把任意一个代码库从一种语言重写成另一种语言，这原本是工程师要花非常长时间才能做完的事，现在模型做得相当快。Claude Code 自己就是跑在 Bun（一个开源的 JavaScript 运行时，是 Node.js 的替代品，速度更快）上面的，Bun 本身是用 Zig（一门系统编程语言，跟 C 类似，非常底层）写的。Zig 这类语言有个共同的麻烦，内存要手动管理，很容易出现内存泄漏之类的问题。Bun 团队一开始是让 Claude 对代码库做模糊测试（fuzzing，一种故意用各种随机或极端输入去触发程序潜在错误的测试方式），去尝试模拟和触发内存泄漏，一个一个案例地找，这是当时模型的能力水平。后来团队里一个叫 Jared 的人说，不如直接让模型试试整个重写，这成了他每出一代新模型就会拿出来试一次的一道题。到了叫 Fable 的那一代模型，开始能做到了，Opus 5 自然也能做。

Jared 的做法是先定义好一套测试集，Bun 有个天然优势，测试覆盖率非常高，Node.js 本身的测试集也很完整，这样就很容易判断重写出来的东西对不对。然后他让模型把整个代码库从 Zig 重写成 Rust，只用了一个 prompt，用的是 dynamic workflows（Claude Code 里一个比较新的功能，可以调度几十个、几百个甚至上千个 agent 一起协作）这个功能。整个过程跑了 11 天，把整个代码库都重写完了，而且不是完全一次成型，中间是有人在旁边引导的，但换成之前的模型，就算有人引导也做不到这件事。这套重写出来的代码，现在已经在正式生产环境里用了，就是现在大家用的 Claude Code 背后跑的那套代码。这是一个规模超过十万行、极其复杂的 JavaScript 运行时，放在过去，就算是最好的工程师团队来做，也至少要一年以上。

我看完这个案例最在意的一个细节，其实不是 11 天这个数字，而是这件事能成立的前提，是 Bun 本身已经有一套非常扎实的测试覆盖。也就是说你敢把这么大的任务甩给模型，前提是你已经有一套可靠的方式去检验它做得对不对。这一点后面 Boris Cherny 会明说，但其实在这个例子里已经先埋下了。

没人教它画画 它自己在 OpenCV 里学会了

还有一个例子挺好玩的，最近在 Anthropic 内部小范围传开了。有人发现，给 Opus 5 配上 OpenCV（一个开源的计算机视觉库，本来是拿来处理图像识别用的，不是拿来画画的），让它用 OpenCV 去画一张图，结果画得相当不错，能画肖像，能画动物，能画风景，而模型压根没有被专门训练过怎么画画。Boris Cherny 把这种现象叫 solicitation gap，可以理解成一种激发缺口，模型明明有这个能力，只是从来没人用对的方式把它引出来，一旦你用对了方式去问，它就是能做到。这是团队纯粹在玩的时候意外发现的，本身没什么直接的商业用途，但确实挺有意思。他的猜测是，今天的模型身上，可能还藏着几十个、上百个类似这样还没被人发现的能力。

这也带出了另一个话题，怎么才能更擅长把这些藏起来的能力挖出来。他提到大概一年前，最热门的岗位名字是 prompt engineer（提示词工程师），后来变成了 context engineer（上下文工程师），这种称呼一波一波地换。但他觉得现在真正重要的技能，已经不太是怎么写提示词，而是怎么给模型出一道刚好难到位的题，以及怎么在过程中让模型有办法自己检验自己做的东西对不对，检验这件事，可能是大家最容易忽略、也最容易做错的一环。

我把这两段放在一起看，会觉得挺有意思，发现模型会用 OpenCV 画画的，靠的不是什么提示词技巧，靠的是好奇心，是把模型当成一个可以去探索的东西，而不是一个只能下命令的工具。而检验这件事，我觉得可能才是整场对话真正的核心，重点已经不在你提了什么要求，而在于模型交回来的东西，你有没有办法判断它到底对不对。

两周没停过的一个 prompt

Boris Cherny 讲了一个他自己做的小实验，我看完觉得挺震撼。Claude 的桌面应用是用 Electron（一个用网页技术做桌面应用的框架）做的，最近被他们优化得很快，半年前还挺卡、挺不稳定，现在已经是团队里大部分人日常在用的版本了。他很好奇，如果换成原生应用会是什么体验，于是开了一个 Claude Tag（Anthropic 内部一个能直接在 Slack 里跑的 Claude 产品）会话。第一句话问的是，你有没有权限用 GitHub 上的 Mac OS 虚拟机，Claude 说没有，他就把权限接上去，Claude 就能在 GitHub 上启动一台 Mac 虚拟机了。接着他建了一个空的代码库，打算用来放用 Swift（苹果的原生开发语言）重写出来的桌面应用，问 Claude 能不能访问这个代码库，一开始也不行，给了权限之后就可以了。然后他只说了一句话，把这个 Electron 应用用 Swift 重写一遍，在 Mac 虚拟机里把原来的 Electron 应用跑起来截图，再跟 Swift 版本逐像素比对，没做完之前不要停。

这就是他给的全部指令。这个任务从那天开始一直跑到访谈当天，已经连续跑了两周多，大概十四五天。主持人当场问现场有没有人让 Claude 连续跑过超过两周的任务，没有人举手。Boris Cherny 说，这就是激发能力的一个例子，模型今天已经能做到这件事，你只要真的放手让它去做，不需要什么花哨的脚手架工具，只要给它任务，给它一套能验证自己做得对不对的方法，剩下的它自己会一直往前走。更意外的是，Claude 自己决定要把这个过程直播出来，它自己建了一个内部的 Slack 频道，每隔几分钟就往里面发一次进度截图。

让我印象最深的不是跑了两周这件事本身，而是没有人要求它去 Slack 里汇报进度，这是它自己决定要做的。这个小细节让我觉得，一旦你给模型足够长的任务和足够大的自由度，它表现出来的行为已经不太像是在照着指令一步步走了，更像是一种职业习惯，一个真正靠谱的工程师会主动同步进度，不是因为被要求，是因为这本来就是把事情做好的一部分。

想学出这种效果 先别信一招鲜的说法

那到底怎样才能成为那种能把 Claude 用出这种效果的人。Boris Cherny 半开玩笑地说，可能第一步是别去看 LinkedIn 上那些网红说的话，也别老刷 Twitter，因为根本不存在什么一招鲜的技巧。模型真正的用法是要用实证的方式去接近它，给它一个稍微有点难度的任务，给它一套跟你自己做这件事时会用的同款验证工具，看它卡在哪，然后根据卡住的地方去修，可能是换一种更好的提示方式，可能是给它配一个 skill，如果是模型缺了某些上下文信息，就给它接上 MCP（Model Context Protocol，模型上下文协议，简单说就是一种让模型标准化接入外部工具和数据的方式），让它自己去把需要的上下文拉进来。

他还提到一个很常见的失败模式，很多人容易想得太复杂、做得太重，因为过去做系统的时候，本来就得这么干。他观察到，写代码写了很多年甚至几十年的工程师，特别容易掉进这个坑，习惯把指令写得过度具体，非要让模型完全按自己会做的那种方式去做，但模型根本不是这么运作的。他说很多人正在慢慢把这个习惯戒掉，这是一个需要花时间的过程，核心是要学会把模型当成一个真正的同事去对待，这才是它现在所在的智力水平该有的用法。

我觉得网红那句吐槽其实挺认真的，不只是句玩笑话。很多所谓的提示词技巧，本质上是把用模型当成找作弊码，而真正的技能其实更接近怎么管理人，知道怎么把一个真正难的问题交给一个靠谱的人去做，同时提前设好检查点，这样才知道对方有没有走偏。这是一项披着技术外衣的人情世故技能。

一次跑出几千个 agent 靠的是什么

怎么才能一次性跑出成百上千个 agent。Boris Cherny 说最简单的办法就是用 dynamic workflows，只要说一句用一个 workflow，Claude 就会自己去触发。它背后的原理是，Claude Code 用 Bun 运行时当沙箱，在 Bun 里再起一个虚拟机，让 Claude 在里面启动一大堆 agent 并调度它们。它不是简单地起一个 agent，也不是简单地并行起十个 agent，如果任务是重写整个代码库，或者对很复杂的数据做很深入的分析，或者要经过好几个阶段、涉及几十个 pull request 才能搭出来的复杂功能，它会先派出一批 agent 做第一轮，再根据结果派出另一批 agent 去验证或者总结前一轮的成果，可能还会有第三轮再展开，像这样一层一层有条理地调度不同的 agent。他自己的背景是函数式编程，他们设计这套东西的方式，本质上是给 agent 做了一套代数系统，有一种方式让 agent 顺序执行，也有一种方式让 agent 并行执行，Claude 会在沙箱内部用不同的工具去调度这些 agent，尽量高效地用 token 去完成很复杂的任务。

他把这套东西放进了一个更大的框架里去理解，说这其实是一种新形态的 test-time compute（推理阶段投入的计算量，跟训练阶段投入的计算量是相对的概念）。过去模型变聪明，主要是靠往训练上砸的三样东西，神经网络的规模、训练数据的量、训练时用掉的算力。后来大家又开始讨论 test-time compute，说白了就是模型在实际使用时会生成多少 token。而 dynamic workflows，本质上是一种全新的方式，去调度和放大用在一个高难度任务上的 test-time compute。

除了 dynamic workflows，还有另一种批量跑 agent 的方式，叫 loops 和 routines。loop 相当于给 Claude 配了一个本地的定时任务，routine 是同样的东西但是跑在云端，这样就算你合上电脑它也还在跑。跟 dynamic workflows 的区别在于，dynamic workflows 是把一个任务拆成很多块去做，loops 和 routines 则是同一个重复性的任务，彼此之间不共享上下文，但可能共享记忆，按固定节奏一遍一遍地跑，可能是每小时一次，每五分钟一次，或者每天一次。

他们内部已经开始让 Claude 自己维护自己的代码库了，专门开了一个 Slack 频道，在里面让 Claude 启动一堆 routine，去维护命令行工具、iOS 应用、安卓应用、桌面应用各自的代码库。其中一个 routine 是清理死代码，指令就是一句话，Claude 每天都会跑一次，用静态分析和动态分析（两种检测代码问题的技术手段）在所有代码库里找没人用的死代码，具体怎么做他们没有细讲，是 Claude 自己想出来的办法，然后每天提一个 pull request 把死代码删掉。另一个 routine 是清理已经全量上线的实验开关，一旦某个实验已经推到了百分之百，就把相关代码从代码库里删掉，直接把功能正式上线。还有一个是给测试覆盖不够的地方补测试，另一个是删掉那些没必要留着的测试，很多是以前的模型或者以前的人加进去的没什么用的测试。他自己最喜欢的一个叫抽象警察，一个大型代码库里经常会出现同一种抽象被反复造了好几遍，明明本该是同一套东西，因为各种历史原因在不同地方被重复实现了，Claude 每天都会在所有代码库里找这种几乎一样的抽象，把它们统一起来。现在他们大概有二十到三十个这样的 routine 每天在跑，虽然还没完全做到，但已经在往完全自动化维护自家应用这条路上走，这意味着每天有成百上千个 agent，在做过去要几十上百个工程师才能做完的维护工作，工程师因此能腾出手去做真正想做的事，做新产品，跟用户聊天。

抽象警察这个细节我最喜欢，这本来是一件特别需要经验和判断力的活，要看出两个长得不一样的东西其实是同一个想法，再决定要不要把它们合并，过去这种活得靠资深工程师的直觉，现在每天晚上悄悄就跑完了。这让我觉得，最先被自动化掉的，可能恰恰是工程里最没人愿意干、但又必须有人干的那部分维护工作，而真正有创造性、充满模糊判断的那部分，决定要做什么，可能还会在很长一段时间里留在人手里。

编程真的解决了吗

主持人提到 Boris Cherny 之前说过编程这件事已经被解决了，问既然现在人人都能写代码，那真正区分顶尖开发者和普通人的东西是什么。他先打了个补丁，说编程被解决，指的是他自己做的那类编程被解决了，不代表对所有人都成立。有些很深的系统代码库，Claude 现在还是会卡住，分布式系统它也还有困难，特别细节的界面校验，比如某个东西差了一个像素，Claude 也还做不到完美，Opus 5 在视觉和电脑操作上已经是个很大的跃进，但离完美还有距离。

现场他还做了个小调查，问有多少人现在写代码已经百分之百靠 agent，自己完全不动手写了，举手的人还不少，效果不错。又问超过一半靠 agent 的有多少，举手的人稍微少一点，大致差不多。他说这说明这件事正在朝着被解决的方向走，而且能被解决的代码种类会越来越多。他觉得现在真正用得好 Claude 的那批人，靠的核心其实是一种很实证的心态，忘掉过去在别的模型上学到的东西，忘掉课堂上学的那套计算机科学理论，去看这个模型实际表现怎样，拿一个任务去试，看它卡在哪，再根据卡住的地方去调整。这已经变成一门实证科学，不再是一门理论科学。真正擅长这件事的人，擅长的其实是放下过去的经验，放下以前觉得行不通的想法，愿意再试一次，这才是现在真正稀缺、真正吃香的能力。

我挺欣赏他没有把话说满，明确划出了 Claude 现在还做不到的边界，而不是笼统地说编程已经解决了，这种诚实本身也是一种判断力。更让我在意的一点，是把忘掉过去经验说成一种技能。以前遗忘经验通常被当成一种损耗，是会拖慢你的东西，这里却被说成是真正的竞争优势。

CS 学生现在还应该学什么

最后一个问题问得挺实在，如果现场有人正在读计算机专业，是在这波 AI agent 写代码的浪潮之前学会编程的，那有什么东西是应该继续用老办法、笨办法去学的。Boris Cherny 讲了自己的故事，他说自己学计算机科学的方式一直很实用主义，都是为了解决自己真实遇到的问题才去学着写代码。他最早是在中学的时候，在 TI-83 计算器（德州仪器出的一款图形计算器，很多美国中学生上数学课都会用）上写代码，用的第一门语言是 BASIC（一种早期的、语法比较简单的编程语言）。他学写代码的初衷特别简单粗暴，就是想在数学考试里作弊，靠计算器帮自己算得更快更准。后来他真的靠这个拿到了好成绩，还专门弄了根串口线，把写好的程序分享给同学，同学们的成绩也跟着上去了。再后来数学变难了，他原来写的那种代数解题程序不够用了，等到学微积分的时候，他不得不去学汇编语言（一种比 BASIC 更底层、写起来更难但是运行更快的语言），才能写出一个够用的解题程序，好让自己在微积分考试里继续这套作弊的老办法。他还专门写过一份在网上教人怎么给 TI-83 编程的教程，据说现在网上还能找到。

他给在校学生的建议是，编程对他来说一直是件很实用的事，希望大家不只是学计算机科学本身，这当然是件很有意思、智力上很吸引人的事，但更重要的是学怎么去应用它，很多时候这意味着去学怎么做创业，怎么做产品，怎么培养自己的设计判断力，怎么建立商业上的直觉，怎么做数据分析，怎么跟用户聊天。这些能力跟计算机科学和工程结合在一起的时候，才是真正有价值的地方，这些才是他觉得现在依然值得花笨功夫去学的东西。主持人替他总结了一句，先做出自己真正想要的东西，然后再往上一层，去做出别人也想要的东西，他说是的。

我特别喜欢他这个起点，一个中学生想在数学考试里作弊，结果一路把自己作弊用的工具从 BASIC 升级到汇编语言，这个故事被他很坦然地当成了一个好的工程教育范本，不是因为算法有多严谨才去学，而是因为自己真的有个痒处要挠。这个故事其实也悄悄回答了很多现在学 CS 的学生心里的焦虑，看着 Claude 十一天就能重写一个代码库，那自己学这些还有什么用。答案好像是，能不能亲手写汇编从来都不是真正的护城河，真正的护城河是你自己有没有一个真正想解决的问题，以及你有没有足够的判断力去分辨，模型给你的答案，到底是不是一个好答案。

我自己的一点思考

听完这整场对话，留在我脑子里最深的一条线索是，Boris Cherny 讲的几乎每一个做法，删掉系统提示词、扔掉过期的 eval、靠拿掉限制而不是加功能去做 unhobbling、给模型出更难的题而不是写更细的指令，指向的其实是同一个方向，少一点控制，多一点检验。过去做工程的本能，是靠提前把一切都规定清楚来降低风险，现在的本能变成了，事后一定要有办法判断模型做得对不对，靠这个来降低风险。

我觉得这跟我最近读到的好几篇访谈其实都在讲同一件事，当把一件事真正做出来的成本越来越低的时候，真正的瓶颈会往前挪一步，挪到判断这件事本身要不要做、做完了算不算对上面去。Boris Cherny 从写代码这个角度给出的版本，可能是我目前看到最具体的一个例子，那份系统提示词，原来装的都是我们不放心模型独立做的那部分，等到你真的开始信任它了，还留着这些说明书，与其说是谨慎，不如说更像是一根拴住它的绳子。什么时候该松手，松手之后又怎么确认它没有跑偏，这可能才是接下来最值得花时间去练的本事。

文章来自于"深思圈"，作者 "深思圈"。