发表于 | 分类于

把自己作为方法：自研产品如何从“做出来”走到“每天都用”

从微信里的 OpenClaw 开始

OpenClaw 我很早就装好了。它一直在那里，能力也没缺过，但我并没有用得特别好，也谈不上顺畅。它更像一个我知道、却没有真正进入生活的工具：需要用的时候我会想起它，可想起之后要专门打开、要切换到一个单独的地方、要重新把自己放进它的语境里，这几步小小的动作累积起来，就足够让我在大多数时候选择算了。

最近几天我把它接入了微信，变化来得很直接：我明显更愿意用它，也觉得体验好了很多。值得停下来想清楚的是，这段时间它的功能几乎没有增加，我能让它做的事情和之前是同一批。真正变化的，是我和它之间那段距离。

我后来把这件事理解为一个关于摩擦的问题。微信是我本来每天都停留的地方，消息在这里，联系人在这里，注意力也默认落在这里。当 OpenClaw 出现在微信里，它就不再要求我先离开现在的地方、再去找它，而是直接出现在我已经在的地方。想到它和用上它之间，原本隔着好几个需要主动跨过的步骤，现在几乎被压平成一个动作。想到、使用、拿到结果，这条链路被显著缩短了。

这些步骤单独看都很小。打开一个应用要几秒，回忆用法要几秒，把当前正想的事重新组织成它能接受的输入又要几秒。任何一步都不足以劝退我，但它们叠加在“我本来只是顺手想处理一件小事”这个念头之前。一个念头越轻，它能承受的前置成本就越低。很多本可以交给工具的小事，就是在这几秒的犹豫里被我重新捡回去手动做掉，或者干脆放弃了。低摩擦入口真正省下的不是那几秒钟，而是让我不必在每次使用前都重做一遍“值不值得为它切换一次”的决定。

我想强调这次变化的性质，因为它很容易被归错类。我没有给 OpenClaw 增加新能力，没有让它更聪明，也没有扩展它的任务边界，改变的只是它出现的位置，以及我够到它的方式。这是一次纯粹的体验变化，而不是功能变化。可正是这次不涉及任何功能的变化，实实在在地改变了它在我生活里被使用的频率。功能清单的长短，和一个东西到底会不会被用起来，是两个不同的坐标轴。

这里容易被简化成一句“体验很重要”，但我想说得更具体。能力决定一个工具在理论上能做什么，摩擦决定它在现实中会被用多少次。一个功能再完整的系统，如果每次调用都要付出额外的心理成本，它的价值就会卡在“可用”而非“在用”。价值不是在功能写完那一刻产生的，而是在每一次真实使用里被一点点兑现的；没有使用，功能只是一种尚未变现的可能性。

我愿意把能力和使用分成两种东西看。能力是存量：它写在代码里，做完就一直在，不会因为没人用而减少。使用是流量：它只在有人真的把工具用起来的那些时刻发生，一旦停止就归零。我们习惯为存量骄傲，因为它看得见、留得住；但一个工具对生活的实际影响，几乎完全由流量决定。过去我把大部分精力投在把存量做大，默认它迟早会转化成流量，而这次微信入口让我看到，这中间的转化根本不是自动的，它取决于我有没有认真对待那段把能力变成使用的距离。

这次经历还悄悄改变了我评价工具的方式。以前我问它能做多少事、功能全不全；现在我更在意它有没有从一件“我需要专门去做的事”，变成一件“我几乎不假思索就会做的事”。真正被用起来的工具，往往是那些消失进习惯、不再需要我为使用它下决心的工具。一个还需要我不断提醒自己去用的东西，无论它多强，都说明它和我的生活之间还隔着没被填平的距离。这一步我先记下，后面会回头追问：我自己觉得顺，能不能直接推断出所有人都会觉得顺。

做完不等于做成

作为一个长期写后端的人，我过去默认的验收标准很清楚：功能实现了，逻辑正确，接口稳定，测试通过，系统不出错。按这套标准，一个东西一旦“做完”，任务就结束了。OpenClaw 这件小事让我意识到，这套标准回答的是“它能不能工作”，而不是“它有没有真的在我的生活里起作用”。

这是两个不同的问题。功能正确是关于系统内部的：给定输入，它是否给出预期输出。产品有效是关于系统之外的：它是否被一个真实的人，在真实的场景里，反复地、自愿地用起来，并因此得到了想要的结果。前者可以在代码里被验证，后者只能在使用行为里被验证。我可以写完所有功能，却完全说不清后一个问题的答案，因为答案根本不在代码里。

对工程师来说，“代码完成”是一条格外有诱惑力的假终点线。它清晰、可判定、有成就感：功能被逐项划掉，测试变绿，提交合并，一切都在说任务结束了。这套反馈即时而确定，而“有没有真的在生活里起作用”的反馈是缓慢、模糊、经常令人不安的。于是我们很自然地停在能被确认的地方，把那条更难回答的线默默当作已经越过。做完之所以常被误当成做成，不是因为我们不知道区别，而是因为做完这一端更容易衡量。

我做过不少给自己用的东西，很多的处境都类似：它们“做完”了，却没有“做成”。它们静静待在那里，功能齐全，却几乎不被打开。只看代码，这些项目都算完成；看它们在我一天里被使用的次数，它们和从没做过区别不大。这中间的落差，就是“做完”和“做成”的落差。

所以我想把自研系统的验收标准往后挪一步：代码完成只是中间态，真正的验收发生在它进入日常并被持续使用之后。这里我要很小心，不去编造任何数字。我不会说使用量涨了多少、留存提高了多少，因为我没有这样的数据，也不需要靠数据来支撑这个判断。我用的证据更朴素，就是使用本身是否真实、持续地发生。一个东西如果我每天都会不自觉地打开，它就通过了验收；如果我要提醒自己、说服自己才会去用，那不管它多完整，都还没有做成。

用使用行为作证据，好处是它很难自欺。我可以说服自己一个项目做得很好、设计得很合理，却没办法长期骗自己每天去用一个其实不想用的东西。自愿的、重复的使用是一种诚实的信号：它不需要我额外的意志力去维持，反而是我在没有监督、没有人要求的情况下自己选择的行为。反过来，如果我必须靠提醒、靠计划、靠“应该用一下”才能让某个自研工具被打开，那这份勉强本身就是最直接的反馈，说明它还没有真正回应我的某个需求。

把验收标准从“是否完成”换成“是否在被使用”，会立刻改变我对一堆项目的判断。很多我以为已经结束的东西，其实一天都还没真正开始。而在这条更严格的标准下，我手里确实有一个通过了考验的例子，它值得被单独拿出来仔细看。

后端工程师补上的另一半视角

说到这里，我要为后端说句公道话，因为很容易把这段经历讲成“后端不懂体验，所以体验更重要”，那不是我想表达的意思。

我确实因为长期做后端，此前不太理解用户体验。对我来说，难点一直在系统内部：数据要准确，服务要稳定，状态要一致，异常要被处理干净。这些能力真实且必要，而且往往是最难、最耗心力的部分。一个系统能不能在各种边界情况下依然给出正确结果，通常比它长什么样要难得多。一个入口再顺滑的系统，如果背后的数据是错的、结果是不可靠的，那顺滑只会让人更快地遇到失望。体验不能凭空成立，它需要有值得被体验的内容。

所以我不认为体验是后端的对立面，更准确的说法是，它们是同一件事情的两半。后端负责让系统真的有能力、有可靠的结果和可以积累的数据；入口和反馈链路负责让这些能力抵达使用它的人。我过去把几乎全部注意力放在前一半，默认只要后一半“存在”就够了，而这一次让我看清：如果能力没有一条低摩擦的通道抵达日常，它就等于没有被交付。

这两半之间还有一个我以前没看清的关系：它们不是先后完成、各自独立的两段工作，而是互相定义的。后端能积累的数据，只有在有人持续使用、持续产生行为时才变得有意义；而入口是否值得优化，又取决于它背后接的系统能不能给出可靠、值得反复获取的结果。只有入口没有内容，顺滑很快变成空洞；只有内容没有入口，能力就长期停留在无人抵达的后台。我过去的失衡，是把两者当成可以分开验收的模块，先把一半做到极致，再假设另一半会自动补上。

换个角度看，这反而是后端的机会。可靠性、数据、系统能力这些别人不容易做扎实的部分，恰恰是我熟悉的。我缺的从来不是能力，而是把能力送到自己面前的那条路。当我开始认真对待入口和反馈，我不是放弃后端视角，而是给它补上了一直缺失的另一半：让扎实的系统，真正被一个人稳定地用起来。这也让接下来的问题变得具体：如果体验决定了能力能否被兑现，那么有没有哪一个我亲手做的东西，已经真的做到了每天都用。

番茄 App 为什么活了下来

那个东西是我做的番茄 App。在我给自己写过的所有工具里，它是唯一一个我每天都会用的。其他的大多停在“做完”那一端，只有它真正进入了我的日常。所以它值得认真拆开来看：不是因为它多复杂，恰恰相反，是因为它简单，而它的简单里藏着几个让它活下来的原因。

第一个原因是它沿用了我早就熟悉的流程。我不是凭空设计一个番茄钟，而是参照我此前用惯的那类番茄 App 重新做了一个。这意味着我第一次打开它，不需要学习任何新东西，它的节奏、它的操作方式都落在我已有的肌肉记忆上。一个要求我重新学习的工具，会在最开始就竖起一道门槛；一个顺着我旧习惯长出来的工具，几乎不需要我适应。熟悉本身就是一种极低的摩擦。

第二个原因是它足够克制。我在重做的时候，只保留了本人真正会用的功能，其他一概砍掉。市面上的番茄类应用往往堆着很多我从不碰的东西：复杂的统计、社交、成就系统、各种可配置项。这些功能对别人也许有用，对我只是噪音，每一个我不用的功能都在悄悄增加我找到自己真正需要那一块的成本。当我把它们全部拿掉，剩下的界面里没有一样多余，我要用的功能永远在最直接的位置。克制之所以难，是因为加一个功能几乎总是比拒绝一个功能更容易被说服：每个想加的功能背后都有一个听起来合理的理由，而“不加”这个决定通常没人替它辩护。但我在番茄 App 上得到的经验恰恰相反：让它一直被用下去的，不是我加进去的那些功能，而是我狠心没有加进去的那些。克制不是把产品做小，而是把注意力还给使用它的人。

第三个原因是它按我自己的习惯优化。因为我既是作者又是唯一要讨好的用户，我可以把每个细节都调到贴合自己的手感，不必为照顾想象中的其他人做任何妥协。别人的产品要在无数种偏好之间取一个折中，我不需要折中，只要对准一个人。这种彻底的个人化，是大多数面向大众的产品在结构上做不到的，而它恰恰是让一个工具用起来毫不别扭的关键。

第四个原因是它有即时的收益。我坐下来，开始一个番茄钟，专注一段时间，这件事当场就给了我回报：一段被保护起来、不被打断的时间，和一个清楚的开始与结束。我不需要等到一周后看统计才觉得它有用，它在我使用它的那一刻就已经兑现了价值。即时回报是让人愿意再打开一次的关键，因为每一次使用都不是在为遥远的好处投资，而是当下就有所得。

第五个原因，也是我一开始没想到的，是它在被使用的过程中自然沉淀下了我需要的数据。我什么时候开始看书，看的是哪些书，这些记录不是我特意去填的，而是我正常使用它时顺带产生的副产品。这一点很关键：如果记录数据需要我额外花力气，它迟早会因为麻烦而被放弃；正因为数据是行为的副产品，而不是一项额外的维护任务，它才能长期、无痛地积累下来。我想特别说明，这种沉淀和常见的“数据统计功能”不是一回事。很多应用会专门做一个庞大的统计模块，要求你先认真记录，再去某个后台页面查看，那本质上仍是又一件要你维护的事。番茄 App 里的数据更像我使用行为投下的影子：我只管照常开始、照常读书，记录就自己长了出来。因为它不向我索取任何额外动作，它也就不会在我忙、我累、我懒的那些时刻第一个被牺牲掉。

把这五点放在一起看，它们不是五个并列的优点，而是互相加强的一个整体。熟悉和克制降低了我开始使用的门槛，个人化让每一次使用都足够舒服，即时收益让我愿意一次次回来，而正是这些一次次的回来，才让数据沉淀成为可能；反过来，积累下来的数据又让这个工具随着时间显得越来越贴合我，越来越难被替代。这里藏着一个我想单独讲清楚的机制：即时回报和长期沉淀，缺一不可。只有即时回报、没有长期沉淀，一个工具会好用但很浅，用完就用完了，我离开它也没有任何代价。只有长期沉淀、没有即时回报，情况更糟：它要求我今天付出、承诺未来某天才有收益，而人几乎不会为一个当下毫无所得的东西持续投入，于是它常常在那个未来到来之前就已被放弃。番茄 App 能活下来，正是因为它同时给了我当下的回报和一条越走越深的积累曲线：前者让我愿意今天打开它，后者让我明天更离不开它。

把自己作为方法

番茄 App 的经历让我慢慢总结出一个做个人项目的方法，我把它叫做“把自己作为方法”：一个给自己做的东西，先不要去想象一个模糊的“别人”，而是先从自己出发，先让自己用得舒服、用得高频，再去考虑要不要开源、要不要做成产品。

这个方法最直接的好处，是它让我不必凭空猜测用户。为一个想象出来的用户做设计很危险，因为我可以把任何我喜欢的功能都合理化成“用户应该会需要”，而这个虚构的用户永远不会站出来反驳我。我过去那些做完却没做成的东西，很多就败在这里：我为一个不存在的人，解决了一个我猜想出来的问题。而当我把自己作为用户，需求就不再是猜的了。我知道我什么时候真的卡住，知道哪一步让我烦躁，知道什么东西我会一次次回来用。这些不是调研得来的假设，而是我每天亲历的事实，它们具体、诚实，随时可以被验证。更重要的是，我作为用户是会持续使用的。一次性的意见谁都能给，但只有长期、自愿的使用才能暴露一个产品真正的问题：哪里做得不好，用不了几天我自己就会因为不舒服而发现；哪里做得好，会体现为我不假思索地一直用下去。我既是出题的人，也是每天来验收的人，这条反馈回路短到几乎没有延迟。

不过，正因为我离自己太近，这个方法也带着它特有的盲区。我最熟悉的痛点，未必是这个领域里最重要的痛点，而只是最先硌到我的那一个。我用得顺的设计，可能只是顺应了我的坏习惯，而不是解决了真正的问题。作为唯一的用户，我既没有人来反驳我的偏见，也没有人提醒我：有些我早已习以为常、甚至绕过去都不曾察觉的障碍，对别人可能是根本迈不过去的坎。所以把自己作为方法，给了我一个真实的起点，却也要求我时刻记得，这个样本虽然诚实，却带着系统性的偏差。我能做的补救很有限，但至少有一条：在把任何东西推给别人之前，先诚实地问自己，我真正依赖的到底是这个问题本身，还是我解决它的那个特定方式。前者更可能是共性，后者更可能是特例。

我必须非常清楚地给这个方法划一条界线，否则它会从一个好起点变成一个陷阱：把自己作为方法，绝不等于把自己当作所有用户。我只是第一个真实的用户，是一个方便、诚实、随时在场的样本，但终究只是一个样本。我用得顺，只能证明这个东西对我这样的人有效，并不能证明它对所有人都有效。

所以我开始强迫自己区分三种不同的东西。第一种是我的高频真实问题：它频繁出现，让我真切地难受，这类问题最值得动手，因为需求的强度是真的。第二种是我的个人特例：我用得顺，可能只是因为它恰好长在我特有的习惯、我特有的工作方式之上，换一个背景不同的人也许根本不需要，甚至会觉得别扭。第三种是可迁移的共性：某个我遇到的问题，剥掉我个人的特殊性之后，在很多人身上以不同形式反复出现。把这三者分开，是这个方法能不能被安全使用的关键。高频真实问题告诉我这个东西值得为我自己存在；但只有当我能从自己的具体经历里辨认出可迁移的共性，并把它和纯粹的个人特例分开时，我才有资格考虑让它离开我、走向更多人。混淆这两者会导致两种相反的错误：要么把只适合我的偏好当成普世真理硬推给别人，要么因为“这只是我个人的需求”而错过一个其实相当普遍的问题。

为自研产品设计最短闭环

有了这个方法之后，接下来的问题就变得很具体：当我要给自己做一个东西，或者要修一个已经做出来却用不起来的东西，我到底该看什么。我给自己整理了一条完整的使用链路，用来定位问题，而不是当作又一份要逐项打勾的功能清单。

这条链路大致是：想得起、进得去、说得明白、办得下去、看得到结果、以后用得上。想得起，是在我需要的那个瞬间，这个工具会不会浮现在我脑子里，而不是被我彻底忘掉。进得去，是我想起它之后，够到它、打开它、开始用它要跨过多少步。说得明白，是我能不能顺畅地把想做的事表达给它，而不必先把念头翻译成它别扭的格式。办得下去，是它接到我的意图之后，能不能可靠地把事情做完，而不是半途卡住或给出我不敢信的结果。看得到结果，是我能不能清楚地知道它到底做了什么、做成了没有。以后用得上，是这一次使用会不会留下点什么，让下一次变得更顺、更值得。

我把它当作诊断工具，而不是建设蓝图。它的用法不是“把这六项全都做到满分”，而是当一个工具我明明做完了却不愿意用，就拿它逐环去问：到底是在哪一环断了。很多时候断点只有一个。微信入口那件事，说到底就是“进得去”这一环出了问题：想得起、说得明白、办得下去、看得到结果都在，唯独进入的成本太高，于是整条链路就卡在了那里。找到那个真正断掉的环，往往比给整个系统再加一堆功能有用得多。

这也纠正了我一个根深蒂固的习惯。作为工程师，我面对一个不够好用的东西，本能反应是问“还能给它加点什么”，因为加功能是我熟悉的、有掌控感的动作。但更多的功能常常让链路更长、摩擦更多，反而把它推离日常。真正该问的问题是反过来的：在这条链路上，是哪一个具体的摩擦，让我在某个真实的时刻选择了不用它。产品优化应该从真实的摩擦出发，而不是从“还能增加什么功能”出发。

我特意强调这个闭环要“最短”，是因为一个给自己做的产品，最大的敌人从来不是功能不够，而是投入和回报之间的距离太长。如果我要一次改很多地方、要等很久才能知道这次改动有没有用，这个循环本身就会因为太重而停摆，我最后又会退回到凭想象做设计的老路上。把每一轮都压到最小，只改一个环、只验证一件事，是为了让反馈快到我愿意一直转下去。于是这形成了一个很小但很扎实的循环：先观察我在什么时候、因为什么真实地放弃了使用它；再定位这个放弃卡在链路的哪一环；然后只针对那一环做最小的修改，不顺手多加别的东西；最后回到我自己的日常里复验，看这一次我是不是真的会不假思索地用它。观察、修改、复验，再回到观察。它的每一步都以我真实的使用行为作为依据，而不是以我坐在那里的想象。值得注意的是，能进入这个循环的前提，正是我先把自己当成了真实用户：如果没有人真的在用，就不会有真实的放弃可供观察，这个循环也就无从转起。日子久了，一个工具就是这样，被一次次真实的不满意，磨成了一个我每天都会用的东西。

从一个人到更多人

把自己作为方法走到最后，一定会撞上一个问题：当一个东西我自己已经用得很顺、每天都离不开，我要不要让它离开我，去到更多人那里。这个问题看起来像是进度问题，好像私用是第一级，开源是第二级，做成产品上架是第三级，一个东西只要够好，就理应沿着这条阶梯一直往上走。我一度也这么默认。但真正想清楚之后，我觉得这个阶梯的比喻本身就是错的。

私用、开源、产品化不是一条必然向上的升级路线，而是三种不同的价值兑现方式。它们各自面向不同的人，承担不同的责任，也向作者要不同的东西。把它们看成阶梯，会让我误以为停在私用是一种未完成；而事实上，很多东西最好的归宿本来就是只服务我一个人，把它硬推上去，反而会毁掉它原本成立的理由。

私用的价值核心，是它彻底贴合一个具体的人。番茄 App 之所以好用，恰恰因为它只对准我一个人，不做任何折中。这种彻底的个人化是它的优点，但同一个优点一旦要面对更多人，会立刻翻转成缺点。因为它的好用，正建立在大量我自己心知肚明、却从没写下来的隐含上下文之上：我的习惯、我的节奏、我默认会怎么操作、我能容忍什么、我不在意什么。这些上下文对我透明，对别人却是缺失的。私用的东西之所以轻，正是因为它可以把这一切留在作者脑子里，不必说明、不必兼容、不必解释。

开源改变的，是这个东西被谁看见、被谁使用。当我把它开源，我其实是在说：这里有一个解决某类问题的思路和实现，如果你的处境和我类似，你可以拿去，自己改、自己适配。开源交付的价值核心，不是一份开箱即用的完整体验，而是一份能被理解、被复用的方案。它默认使用者有能力、也愿意去填补那些我没有替他准备好的上下文。所以开源真正要求我多做的，往往不是把产品打磨得多完善，而是把原本藏在脑子里的隐含假设显影出来：讲清楚它解决什么问题、依赖什么前提、在什么情况下根本不适用。我不必为使用者的最终结果负责，但我必须为把话说清楚负责。开源之所以容易被误解，是因为它看起来像产品化的一个更轻的版本：把代码公开，好像就顺手服务了更多人，又不必承担做产品那么重的责任。但这个中间状态有它自己特有的失败方式。最糟的一种，是把一堆只对作者有意义的代码直接倒出来，既没讲清它解决什么问题、依赖什么前提，又摆出一副“拿去用”的姿态。这样的东西对别人几乎没有价值：想复用的人要先花大力气逆向出我脑子里那些从没写下来的假设，成本高到还不如自己重写。它比诚实的私用更糟，因为私用至少不承诺什么，而这种半吊子的开源承诺了复用，却没有交付复用所需的那份说明。

产品化是这三者里责任最重的一种，重到它几乎是另一件事情。当我把一个东西做成产品、推给那些我不认识、也无法预设其能力和处境的人，我就得替他们把我曾经留在脑子里的每一个上下文都补齐：他们不了解我的习惯，不会去读我的代码，也没有义务来适配我。产品化真正的工作量，常常不在那个核心功能上，而在核心之外那一大圈让陌生人也能顺利用起来、并在出问题时有人负责的东西上。它要求我承担部署和服务的责任：它得一直可用，得处理我从没设想过的用法，得在坏掉的时候有人管。一个东西对我好用，和它能对一群陌生人持续负责，中间隔着的正是这一整圈责任，而这圈责任常常比里面那个核心还要大。

所以我不再用“做到了哪一步”来看这三者，而是用几个维度去判断一个具体的东西该停在哪里。第一个维度是价值核心：它交付的到底是一段贴合个人的顺手体验，还是一份可被他人复用的思路，还是一个陌生人也能依赖的完整服务。第二个维度是隐含上下文：它有多依赖那些只存在于我这里、很难迁移给别人的前提；依赖越重，它离开我之后就越容易失效。第三个维度是部署与服务责任：我是否愿意、并且有能力为它的持续可用和别人的使用结果长期负责。第四个维度，也是最容易被跳过的一个，是它到底值不值得通用化：把我个人的特殊性剥掉之后，里面那个问题是不是真的在很多人身上反复出现。这四个维度合在一起，回答的其实是同一个问题：这个东西的价值，有多少能在离开我之后依然成立。如果它的好几乎全部来自它对我一个人的贴合，那它最诚实的归宿就是私用；如果它内核里那个问题足够普遍，只是被我的个人习惯包裹着，那它值得被开源，让别人拿走内核、自己重配外壳；只有当那个问题既普遍、我又愿意连同它周围那一整圈责任一起扛起来时，产品化才真正成立。

把这几个维度想清楚，主要是为了躲开两种方向相反、却同样常见的错误。第一种是把只适合我的东西错当成适合所有人，急着推出去：它的价值高度依赖那些我从没说清的隐含上下文，一旦离开我，别人拿到的只是一个空壳，功能都在，却处处别扭，而我还要为一个本不该由我负责的使用场景，长期背上部署和维护的包袱，最后往往连自己那份原本纯粹的好用也一并拖垮。第二种错误正相反：一个其实相当普遍的问题，被我用“这只是我个人的怪癖”轻轻放过，于是它永远停在我的机器上，一个本可以帮到很多人的东西被埋没。这两种错误的根子是同一个，就是没有把“我需要”和“别人也需要”分开摆。判断该私用、该开源还是该产品化，与其说是在选一条上升的路，不如说是在为一个东西找到它诚实的位置：既不高估它能走多远，也不低估它本可以抵达的人。

拿这几个维度去看番茄 App，结论反而让我踏实。它每天都被我使用，按“做完还是做成”的标准，它是我做得最成的一个；但按这几个维度，它恰恰是一个该停在私用的东西。它的价值核心几乎全部是对我一个人的贴合，它的好用重度依赖我熟悉的那套流程和我砍功能时的私人取舍，这些隐含上下文很难原样迁移给别人。这不是它的缺陷，而是它成立的方式。它内核里当然有普遍的部分，比如专注、克制、即时回报，但那些普遍的道理早已有无数人做过，我这一个的独特价值就在那层不可迁移的个人化里。看清这一点，我就不会因为它做得成，而错误地觉得下一步理应是把它推给更多人。做成和该外推，本来就是两个独立的问题。

我现在手上正要面对这个判断。我想把从番茄 App 和微信入口里得到的经验，用到我给自己做的个人信息中枢、秘书这类系统上，避免再出现“做出来了、自己却不愿意用”的老问题。这些系统会不会有一天走向更多人，我此刻并不急着回答。我先要做的，是让它们通过和番茄 App 一样的那一关：先成为我自己每天真的会用的东西。顺序不能颠倒：如果一个东西连我自己都留不住，那么讨论它要不要走向更多人，就是在为一个还不存在的价值分配责任。先活下来，再谈去哪里。

回到“每天都用”

绕了一大圈，我想回到最开始那个几乎微不足道的观察：OpenClaw 进了微信，我就用得多了。这件小事之所以值得写这么长，是因为它悄悄改掉了我心里那条验收线。

过去我判断一个自研的东西做完没有，看的是功能列表和测试结果；现在我判断它做成没有，看的是一个朴素得多的问题：我自己是不是真的每天都在用它。这个问题不需要任何数据来回答，我心里非常清楚哪些东西我天天打开，哪些做完之后就再没碰过。这条用与不用的界线，比任何功能清单都更诚实，因为我可以骗自己一个项目做得很好，却没办法长期骗自己去用一个其实不想用的东西。

但我想说的“完成”，比“每天都用”还要再远一步。一个东西被我每天用起来，只是让它有资格接受下一个提问：我依赖的到底是那个问题本身，还是我碰巧喜欢的解决方式；它的好有多少来自它只贴合我一个人，又有多少能在离开我之后依然成立。所以我现在愿意这样重新定义完成：一个产品的完成，不是它在代码里被写完的那一刻，也不只是它长进了某一个人的生活，而是我终于看清了它诚实的归属，知道它该安静地留在我的日常里，还是把内核让给别人去改，或者由我扛起那一整圈责任，让一个陌生人也能每天用上它。在此之前，无论功能多完整，它都还停在半途，因为它的价值还没有被安放到它真正该在的位置上。

从这个角度回头看，我一开始那个问题问错了。我总在问：这个东西还能再做点什么。这个问题的诱惑在于它永远有答案，永远能让我觉得自己在往前走，可它衡量的始终是能力这个存量，而不是使用这个流量。真正该问的是另一个，而且是两层：先问有什么真实的行为，能证明它已经进入了一个人的生活；再问当它真的进入之后，这份价值究竟该停在我这里，还是走向更多人。做出来从来不是终点，被一个人每天用起来才勉强算开始，而想明白它到底属于谁、能陪多少人走多远，才是这件事真正的完成。

发表于 | 分类于

读懂DeepSeek：它真正卖的，是一台”下一次创新”的机器

咱们先从一个”便宜”说起。

2024 年 5 月，DeepSeek 发布 V2，开源，而且推理价格低得离谱，直接在国内触发了一轮大模型降价（36氪 2024）。绝大多数人，包括我在内，都是从这个”便宜”第一次认真注意到这家公司的。

顺着便宜，一个特别顺口的故事马上就冒出来了：一家中国公司，靠低价打价格战，烧钱换市场。这个故事你我都听过一百遍，熟得几乎不用动脑子。但我想说的是，这个故事从一开始就搞错了对象——你盯着价格看，等于盯着影子看。真正值得研究的，是投下这个影子的那个东西。

别被便宜骗了：价格战只是影子

你先较个真：如果 DeepSeek 真是在打价格战，那它图什么？

价格战本质上是一种投资。逻辑很清楚：先用补贴把价格压到成本以下，烧钱抢市场份额，等对手撑不住退场了，再涨价把利润赚回来。前提是——先亏后赚，账面上你得先扛得住流血。

可你看 DeepSeek，它把目标钉在通用人工智能，坚持开源，连融资的信号都不肯放。一家这样的公司，为什么要用打价格战这种最烧现金的方式去赢？说不通。

问题出在起点。价格战的起点是”竞争”，而梁文锋说，他的定价起点是”成本”本身。他对”价格战鲶鱼”这个称呼明显不太买账，说成为鲶鱼不是有意为之，团队只是按自己的成本定价，原则是不补贴、不追求暴利，同时留一点利润。

这里我得踩个刹车，把话说清楚。”便宜”是外界能直接看到的事实；但”不补贴、略有利润”是梁文锋在访谈里的自述，不是一份经过审计的损益表。本文只能转述他这句话，不能替他盖章。把创始人的一句自我描述当成已核实的财务结论——这恰恰是外界谈 DeepSeek 时最常犯的错。

好，那顺着”按成本定价”往下问，真问题就来了：它的成本凭什么能低到搅动整个行业？

梁文锋把降价拆成两半。一半，是探索下一代模型结构带来的真实成本下降；另一半，是他认为 API 和 AI 本就该普惠的价值判断。第一半才是关键。他的说法是：如果只想快点做个应用，沿用 Llama 这种现成结构最省事；可 DeepSeek 把目标定在 AGI，才有理由去改架构、重构数据、做更接近人的模型——而这些研究，反过来把推理的边际成本压了下来。

你品品这个逻辑：在他这里，降价不是获客手段，而是研究的副产品。先有为了啃更难的问题而做的架构，然后价格才顺带便宜下来。

这条从研究到价格的链，2023 年就埋下了。梁文锋第一次公开受访时就把两件事分得很清：一件叫”复刻”，一件叫”研究”（36氪 2023）。复刻一个已有能力，靠公开论文、开源代码或者在现成模型上微调就行，成本可控；研究则要去碰 GPT-4 这种还没答案的问题，得多做实验、多烧算力，还得承受大量失败。他把自己的动机说成是好奇心，而不是先算清回报。正是这种”研究优先”，决定了它会去改底层结构，而不是抢着在现成框架上做应用。V2 的低价，是这条更长的路走了一程之后，才在账单上显影出来的结果。

便宜的具体来源也指向同一处。据媒体对 V2 的技术描述，它靠 MLA 和 DeepSeekMoE 这类架构设计，显著压低了显存占用和计算量。具体百分比咱们不复述，只借它说明一件事：那个便宜价格的背后，站着的是结构层面的重新设计，不是一次咬牙硬撑的补贴。说白了，账单上那个数之所以低，是因为跑一次模型本身真的更省了，而不是有人替这笔钱垫了账。这也和”不补贴”对得上——一件东西如果是从效率里省出来的，就不需要靠亏损去维持。

这里藏着一个特别容易被忽略的不对称，我觉得是全篇第一个洞见：

对手当然可以把价格跟到一样低，甚至更低——只要肯补贴，任何数字都追得平。但你追平的只是那个数字，不是产生这个数字的效率。 靠补贴压出来的价格，每卖一次都在放血，早晚要靠涨价或退场收场；靠效率降下来的价格，卖得越多越贴近它本来的成本，反而稳得住。

于是同样一个便宜的价格，放在两家公司身上，含义可以完全相反：一个是”还能烧多久”的问题，另一个是”到底省了多少”的问题。你光盯着价格这个数，恰恰分不出这两种便宜。这就是为什么，价格几乎没法告诉你一家 AI 公司真正的水位——它顶多是露出水面的一个角。

所以”价格战只是影子”这句话，现在有确切含义了。影子的形状由两样东西决定：投影的物体，和照过来的光。这里投影的物体，是 DeepSeek 内部把不确定的想法变成技术结果的效率；照过来的光，是整个行业比价的目光。外界盯着墙上那个便宜的数字，很容易得出”它在打价格战”的结论；可价格只是被投出来的形状，真正决定形状的，是那个你看不见的物体。只看影子，就会把一场连锁反应误读成一次主动出击。

所以读懂 DeepSeek 的第一步，是把眼睛从价格上挪开。低价是结果，不是原因；是被别人跟出来的连锁反应，不是它主动发起的战争。真正要解释的，从来不是它为什么便宜，而是它凭什么能持续做出让价格便宜下来的那种东西。这个问题一问出来，讨论就从”谁价格更狠”，转向了”这家公司到底在生产什么”——这俩根本不在一个量级上。

它真正卖的，是一台”下一次创新”的机器

那个投影的物体，到底是什么？

把 2023 和 2024 这两篇专访放一块儿读，会浮出一个比”低价””开源””万卡””年轻团队”都更根本的答案：DeepSeek 真正的产品，不是某一代模型，而是产生下一代模型的能力。

V2 只是这台机器某一次运转的产物。真正稀缺、也真正被它拿去跟世界交换的，是那台还能一次次转下去的机器本身。想通这一点，你就不会把 V2 的成功当成终点，而会把它看成一次可以被重复的输出。

梁文锋自己也把话往这个方向引。他说中国和国外真正的差距，是”原创与模仿”的区别，而不是排行榜上差的那一两年（36氪 2024）。你看这个分界：一代模型可以被复刻，可提出下一个问题、再组织起下一次实验的能力，复刻不了。把评价对象从”这一代模型”换成”产生下一代的能力”，本质上就是把目光从能被复制的那一半，挪到抄不走的那一半。

为了把这台机器讲清楚，我给它起个名字，叫”创新生产函数”。得先声明：这是我对两篇访谈的综合分析，不是梁文锋的原话，他从没这么命名过；用这个说法，只是想把散在访谈里的一堆要素装进同一个结构里看。

这个函数有六个要素：耐心资本、可调用算力、人才密度、分布式搜索、集中式兑现、生态反馈。

你可能会说，这几条单拎出来都不新鲜啊——有钱的公司多得是，买得起卡的不少，招得到聪明人的更是一大把。没错。所以真正要解释的，从来不是这家公司占了哪几条，而是这几条在它身上被组合起来的方式。

这里就是第二个、也是最重要的一个洞见：这套函数是乘法，不是清单。

外界习惯把 DeepSeek 的优势列成一张清单：便宜、开源、卡多、人年轻。清单是加法——某项弱一点，用别项补上，总分照样不难看。可乘法的脾气完全不同：只要任何一个因子接近于零，其余五个再大，乘出来也会坍向零。

你有耐心的资本，却没有能自由调用的算力，钱买不到试错；算力和人都齐了，却没有一套让想法自下而上冒出来的组织，卡只会空转在别人指定的任务上；想法层出不穷，却没有把它集中兑现的能力，好念头会卡在验证不足里烂掉；六样都做到了，却把成果锁死不公开，生态和人才这条回路又会自己断掉。

任何一环归零，整台机器停摆。这就是梁文锋为什么说，中国公司其实不缺资本，更缺的是原创的信心，以及把高密度人才有效组织起来的能力——他点的，正是那几个最容易被清零的因子。

先单独说一句第六个因子，生态反馈，因为它最容易被误读成慈善。梁文锋 2024 年明确说 DeepSeek 不会闭源，他认为技术生态比封闭的商业模式更重要，还把开源直接和生态、声誉、吸引人才挂钩（36氪 2024）。在他看来，闭源带来的领先可能只是暂时的；真正持续的优势，不在某份藏起来的权重里，而在团队积累的 know-how、能不断产出原创的文化，以及追赶乃至定义下一代技术的能力。放进这个函数里，开源就是那条把上一轮技术结果换成声誉和人才、再送回下一轮的回路——它让机器的输出反过来喂养机器自己。这一层后面专门讲。

先把丑话说前头：把六个要素命名成一个”函数”，只是提供一种解释，并不等于已经证明这套机制成立。它到底立不立得住，得等把每个因子拆开、再回到访谈没回答的那些问题时才谈得清。

接下来，咱们就顺着这条乘法链，一个齿轮一个齿轮地拆。

第一个齿轮：把钱变成试错的时间

第一个齿轮是钱。但它扮演的角色，跟”钱多好办事”那种直觉几乎相反。

梁文锋描述过一条加卡曲线：最早只有 1 张卡，2015 年前后约 100 张，2019 年到约 1000 张，之后扩到约 1 万张（36氪 2023）。外界记住的多半是终点那个”万卡”，顺手读成一次押中赛道的豪赌。可梁文锋的解释是另一回事：他把这条不断扩容的曲线，归因于对 AI 能力边界的好奇，而不是一次算好回报的下注——每上一级台阶，都是为了跑得起当时还看不清结果的实验。

这一节要用到一堆数字，我先把归因一次说到位：底下的加卡曲线、投入金额、成本比例，混着媒体报道和梁文锋本人的自述、估计，本文只作转述，不把任何一个数字当成审计过的账目。这道边界立在这儿，后面就不重复了。

两笔投入替这条曲线标出了量级：2019 年”萤火一号”投资近 2 亿元，约 1100 块 GPU；2021 年”萤火二号”投资约 10 亿元，约 1 万张英伟达 A100（36氪 2023）。注意，这不是一次性砸下去的赌注，而是从一张卡到一万张、跨越数年的持续追加。梁文锋自己也说，光做量化投资根本用不了这么多 GPU，团队在投资之外还做了大量 AI 研究——也就是说，超出业务所需的那部分算力，本就是为”研究”这件没短期回报的事准备的。

他还把这条曲线接进一条更长的判断：2012 年的 AlexNet、2020 年的 GPT-3、2021 年建起的萤火二号，是同一条线上的点——模型、数据、算力一起往上走（36氪 2023）。在这条线里，加卡不是一次孤立的采购，而是跟着”规模会带来新能力”这个判断走出来的。而且钱买的还不只是卡。他把人工成本称作对未来的投资、公司最大的资产，还在 2023 年说 DeepSeek 已经握有算力和工程师团队，相当于攒下了一半筹码（36氪 2023）。卡会折旧，人和积累却在长——这笔钱真正养住的，是一支能长期去做没短期产出之事的队伍。

这些数字摆一块儿，你才看得清资本在这儿买的到底是什么。我给它个说法：它买的是”实验期权”。

期权这东西，价值不在于它一定会行权，而在于它让你有资格在未来某个不确定的时刻出手。同理，一万张卡再加上每年还要按硬件造价约 1% 贴进去的电费和维护，买来的不是”一定能做出下一代模型”，而是”可以一次次试、试砸了也扛得住”的资格。梁文锋自己也不避讳代价，直说创新本身昂贵、低效，还常常伴随浪费。实验期权买下的，恰恰就是承受这种浪费的能力——能失败的次数越多，能铺开的方向就越宽。

这就点破了一个更根本的限制：在真正的前沿，正确的结构是买不到的。

已经有答案的东西才谈得上标价出售，复刻别人走过的路，可以直接付钱买来；可 GPT-4 之后那一步该怎么走，本就没有现成答案挂在货架上，再多钱也换不来一个”一定对”的结构。钱唯一能买到的，是更多次亲自去试的机会。所以”把钱变成试错时间”不是修辞：在没答案的地方，试错次数几乎是唯一能用钱堆出来的东西，每多试一次，就多一分撞见正确结构的概率。

这里我要立一道界线，很重要：资源是前提，不是原因。

有钱有卡，只是让实验能开始，并不保证实验会指向正确的结构。把”有钱有卡”直接读成”所以做成了”，恰恰跳过了中间最难、最不确定的那一段。真正稀缺的从来不是钱，而是一种敢让钱长期不产生回报的资本结构。梁文锋点过一个冲突：VC 的退出节奏和快速商业化要求，天然和”研究优先”打架——被退出时间表追着的钱，很难容忍一条要失败很多次、回报又遥遥无期的路。而幻方作为出资方之一，自己就握有研发预算（36氪 2023），刚好绕开了这个冲突：这笔钱不必向谁的退出时间表交代，也就买得起足够长的试错时间。他甚至承认，从短期投入回报看，这类基础研究”不划算”——愿意为一件短期不划算的事持续付费，才是这段资本真正稀罕的地方。

再往前一步你会发现，钱多本身甚至可能是种错觉。梁文锋 2024 年直接讲过，更多的钱并不必然带来更多创新（36氪 2024）——这一句就把”投入”和”产出”劈成了两件事。而早在 2023 年，他还判断，当时不管大厂还是创业公司，都很难迅速建立起碾压式的优势。两点连起来看：在谁都没绝对领先的阶段，拉开距离的不是谁账上钱多卡多，而是谁能把资源持续投进一条短期不见回报的路，并且忍得住沿途的失败。资源决定你能不能上牌桌，决定不了你能不能打好这手牌。

所以第一种能力，本质是把钱翻译成时间：不是把资本变成某个确定成果，而是变成一段能承受大量失败的时间。它解释了 DeepSeek 为什么”能开始”，却解释不了它为什么”能做成”。期权只给了行权资格，真正决定这批算力是空转还是长出原创的，是有没有一群人、以及一套让他们把卡用在刀刃上的组织方式。

第二个齿轮：把自由变成有效的搜索

买来的时间和算力，最终要落到具体的人身上，才可能长出原创。所以第二个齿轮是组织——更准确说，是一种让想法自下而上冒出来的搜索方式。我把它叫”分布式搜索”。

先看这群人是谁。梁文锋说，做出 V2 的团队主要是顶尖高校的应届生、在读的博士实习生，以及毕业没几年的年轻人，里面没有海外归来者；他由此认为，本土环境同样能培养出顶尖人才（36氪 2024）。这套用人取向更早就有交代：幻方招聘看能力不看经验，核心技术岗以应届生和毕业一两年的人为主；在他看来，经验有助于完成短期目标，但基础能力、创造性和热爱，对长期创新更重要（36氪 2023）。当然，这只是 V2 阶段的一种人才组合，并不证明经验无用——它说明的是，这家公司选择把赌注押在可塑性和热情上，而不是履历上。

“看能力不看经验”不是句漂亮话，它得先扛得住代价。梁文锋举过幻方销售团队的例子：没行业经验的人，第一年可能交不出什么成果，要到第二年才慢慢显出表现（36氪 2023）。愿意为这样一段看着像在”浪费”的适应期买单，靠的正是上一节那种不催回报的资本垫底——没有那段试错时间，这种用人方式第一年就会被账面否掉。他还说过，对合适的人，管理方式是把重要任务直接交给他、然后尽量少干预（36氪 2023）。这既是自由，也是压力：任务足够重要、干预又足够少，人就只能靠自己扛下来。

真正让这群人”搜索”起来的，是两条被反复提到的自由。一是算力上的自由：成员无需审批就能调用训练集群的算力，跨人协作也灵活，只要对方有兴趣就能搭伙（36氪 2024）。二是任务上的自由：公司没有传统意义上的 KPI，也不预设任务，成员带着自己的想法去探索，遇到问题再主动找能帮上忙的人。这两条合起来，就是”分布式搜索”的字面意思——不是自上而下派活，而是让许多人各自朝不同方向试探，让有价值的方向自己浮现。

我要特别拎出”无需审批”这四个字。它改变的不只是效率，而是哪些实验根本会被想出来。

你想，在一个算力要层层审批的地方，一个人提想法之前，往往先得在心里替它算笔账：值不值得为它去申请资源、去说服上级。很多还没成形、听着不靠谱的念头，就在这一步被自己提前毙了。而当调用集群不必先讲理由，试探的门槛就降到了”想到了就去试”。分布式搜索能铺多宽，某种程度上就取决于这道门槛压得多低。协作也一样：主动去找人，但要对方真有兴趣才搭伙——这更像一个内部的自愿市场，而不是一张排好的甘特图。谁被谁的问题吸引，力量就往哪儿聚。

好，接下来是这一节的核心，也是全篇第三个洞见。把”人”和”算力”分开看还不够，真正决定搜索质量的，是这两条线相乘出来的量。（提醒一句：这一步推演是我的分析，梁文锋本人没这么表述。）

先说人才密度。它常被误读成人数，好像招够聪明人就算达标。不是。这里它指的是：一批能互相看懂对方半成品想法的人被放在一起，谁抛出一个还没成形的念头，旁边的人立刻能判断它有没有戏、卡在哪、值不值得往下试。人多不等于密度高——一群彼此看不懂对方在干嘛的人，人再多也评不出方向。密度真正的标志，是一个粗糙念头能被迅速接住、迅速证伪或迅速加码。正是这种”互相判断半成品”的能力，替这台机器在事前省下了大量本会浪费在错误方向上的试探。

再说”随时调用算力”。它的作用同样容易被讲浅。表面看，无需审批省的只是走流程的时间；可从梁文锋对组织的描述里，能推出一层他没明说的意思：这里自由的关键，不在于成员能自由地表达意见——能提意见的地方到处都是——而在于成员能迅速地为自己的意见付出实验的成本。一个念头只要还停在嘴上，它就既不算对也不算错，谁也说服不了谁；只有真跑起来、撞上数据，它才开始变成能被留下或否掉的知识。自由调用的算力，恰恰把从”想到”到”变成一个可证伪的实验”这段等待压到了最短。它缩短的不是说话的自由，而是试错的延迟。

这两条为什么必须相乘、不能相加？

只有人才密度、没有随时可用的算力，那些被迅速判断过的好想法只能堵在讨论里，密度越高，卡在门口出不去的念头反而越多，判断力最后沦为空谈；反过来，只有算力、没有那层互相判断的密度，实验倒是跑得起来，可没人在事前筛掉明显不值得试的方向，搜索就退化成一场昂贵的随机搜索，卡空转、钱烧在噪声上。人才密度决定哪些方向值得试，可调用算力决定想试就能立刻试——缺了前者，算力沦为随机搜索；缺了后者，判断停在嘴上。DeepSeek 那种”自下而上”之所以没散成一地空想，靠的正是这俩因子同时到位、彼此相乘。

但有笔账必须算清：自由从来不是免费的。 成员之所以能”无需审批”就动用训练集群，前提是上一节那批算力早已备好、且不必靠这一个项目立刻回本——审批之所以能省掉，是因为为失败买单的钱已经躺在账上了。把这一层抽掉，同样一句”随便用卡”就成了空话。所以第二种能力不是凭空的洒脱，它是被第一种能力托着的：自由的成本，早被那批实验期权提前付掉了。

也正因如此，要当心两个流行误读：”没有 KPI”不等于没有评价，”自由”也不等于没有边界。梁文锋自己给出的约束至少有三层。其一是价值观筛选——招人看重的创造性与热爱，本身就是一道过滤，把方向不合的人挡在门外；其二是管理者示范——他说公司没有成文的企业文化，靠文化和管理者言传身教来保持方向一致，甚至认为过度成文反而妨碍创新；其三是难题吸引——他把能不能留住人，直接和”有没有最难的问题可做”绑在一起。三层合起来意味着：所谓自下而上，不是无人负责的放任，而是先用筛选和示范把边界划好，再在边界之内放手。被共同目标约束过的自由，才可能收敛成有效的搜索，而不是四散的空转。

退一步问：为什么偏要让搜索”分布”开来？关键在目标的性质。如果要做的是一件早有答案、路径清楚的事，自上而下派活反而更省事——谁都知道往哪走。可当目标是一个还没人回答过的问题，没有哪个管理者能提前断定哪条路一定对；这时候把探索方向收拢到少数几个人的判断里，等于提前赌死了搜索范围。让许多带着不同想法的人各自去试、遇到有意思的问题再自发聚拢（36氪 2024），本质是用人数去覆盖一片没人画过地图的空间。分布式搜索的价值，不在于它一定比集中指挥更聪明，而在于它不必事先押注方向——而”不必押注方向”这件事，恰恰只有在算力和时间都不紧张时才负担得起。这又把账算回到了上一节。

顺着往下，自然撞上一个问题：想法自己冒出来之后呢？V2 里那个后来压低成本的 MLA，最初就来自一名年轻研究员的想法（36氪 2024）。可一个念头从冒头到真正做进模型，中间还隔着一整道完全不同的工序。那要靠的，就是下一个齿轮了。

第三个齿轮：把灵感变成工程

分布式搜索能做的，是让尽可能多的念头浮出水面。可一个浮出来的念头，离一个能装进模型的结果，中间还隔着一整道工序。绝大多数念头会在这道工序里被淘汰；就算是那个最终有用的，也不会因为有人想到了就自动成形。

所以这台机器还需要第三个齿轮，它的方向恰好和上一个相反——不是让力量散开，而是把力量收拢。

梁文锋对这道工序有句很短的描述：当一个想法显示出潜力，管理层会自上而下地调配资源（36氪 2024）。把这句话和上一节那套”无需审批、自愿搭伙”的自由并排放，你会发现 DeepSeek 内部同时跑着两种方向相反的机制。搜索阶段是自下而上的：谁也不预设方向，让许多人各自试。兑现阶段是自上而下的：一旦某个方向露苗头，判断、人手、算力迅速朝它集中。这两段合起来，才是”分布式搜索、集中式兑现”的完整含义——前半段负责把方向找出来，后半段负责把找到的方向做成东西。缺了后半段，再多好想法也只停在”聊过”的层面。

MLA 就是能把这两段都看清的样本。按梁文锋的说法，它最初只是一名年轻研究员的想法；而从这个想法到真正做进 V2，团队投了数月时间去做验证和工程化（36氪 2024）。你把这两个量级对照着看：起点是”一个人”和”一个念头”，落点是”一个团队”和”数月”。念头本身几乎不花钱，真正昂贵的是后面那段——把一个纸面上讲得通的结构，反复验证、调试，直到它能稳定地跑进一个要对外发布的模型里。一个想法在小范围里成立，和它在一个真实大模型里稳定成立，完全是两回事。很多听着漂亮的结构，就是在这道从”讲得通”到”跑得稳”的坎上摔掉的。只有前半段，MLA 至多是内部讨论里闪过的一个好主意；正是后半段那笔集中投入，才把它从念头变成了产品的一部分。

这里的方向切换，是全篇我最想让你看清的一段，因为它恰恰最难。分布式搜索要的是”宽”——不押注方向，让尽量多的可能性都摸一遍；集中式兑现要的是”深”——认定一个方向后，把资源压上去做透。同一个组织，得能在这两种相反的姿态之间来回切换：既容得下大量看着不靠谱、最后也确实不成的试探，又能在某个试探显出潜力的瞬间，果断停止发散、转而收拢。中间还藏着一个不好做的判断——一个想法要显露到什么程度，才值得押上去？押早了，是在没长成的念头上浪费投入；押晚了，好方向又会卡在验证不足里错过。只会发散，会陷在什么都做不成里；只会收拢，又因为没有足够念头可挑而无处施展。真正稀缺的，是同一套组织能不能在正确的时刻完成这次切换。

这也给上一节那份”自由”补了一块常被忽略的底。梁文锋不讳言，创新本身昂贵、低效、常伴浪费。分布式搜索能容忍浪费，是因为它本就靠大量注定失败的试探去覆盖那片没人画过的地图——浪费不是它的副作用，而是它的运作方式。可如果浪费只进不出，这台机器早晚被自己产生的噪声塞满。集中式兑现在这儿扮演的，正是那道相反的闸门：它不负责在事前消灭浪费，而负责在事后从一大堆试探里，认出那个已经越过门槛、值得押上去的念头，同时默许其余的自然停摆。发散把可能性铺开，兑现把注意力收窄——一台只会铺开、不会收窄的机器，产出的不是原创，而是一地半成品。正因为有后半段这道闸门，前半段那种看着奢侈的浪费，才算得上一笔花得出去、也收得回来的投入。

而这次切换一旦完成，它的结果就会以一种外部能直接看到的形式显影出来——这正好接回第一节那个”影子”。MLA 这类结构降低了跑模型的资源消耗，落到账单上，就成了 V2 那个搅动行业的低价。外界看到的，始终只是墙上那个便宜的数字；把这个数字投出来的，是内部这段从念头到工程的兑现过程。价格是外部可见的痕迹，兑现的能力却留在组织里，看不见，也抄不走。这也是为什么，同样一个低价，从外面几乎没法反推出背后到底站着一套什么机制。人们记住了结果，却读不到产生结果的那道工序。

沿着效率这条线，梁文锋给过一个更具体、但必须谨慎对待的估计。他认为，国内领先水平和国外领先水平，在训练效率和数据效率上大约各差一倍，两者叠加，做同一件事可能要多消耗约四倍的算力（36氪 2024）。我得特别说明：这是他在访谈里给的估计，不是独立核实过的测量，本文只能转述，不能替他确认这个倍数。也正因为它只是估计，后面这条推论我写成条件句：只有当这个倍数大致成立时，效率上的差距才会被直接翻译成算力上的差距，进而变成试错次数上的差距——在高端芯片本就受出口限制、算力天然吃紧的前提下，同一批卡，效率抠得更狠的一方才能跑出更多轮实验，把这一节的兑现能力悄悄喂回第一节那批实验期权。倘若倍数不成立，这条回喂链就得打折扣；但即便如此，它至少点出了兑现这道工序真正较量的东西——不是能不能把一个结构做出来，而是能不能用更少的资源把它做出来。MLA 这类架构的意义，恰恰在于它是在这条效率线上往回追的一次尝试。

这就引到那个最容易被误读的区别：原创与模仿。梁文锋把中国和国外真正的差距，理解成原创与模仿，而不只是排行榜上的一两年（36氪 2024）。放到”兑现”这个视角下，这个区别其实是一条学习曲线上的差别。

你想，模仿一个已有结构，等于直接拿走别人试错的结果——那些失败的实验、走过的弯路，全能跳过，当期的探索成本因此省一大截。但省下的只是这一轮的试错；模仿并不会顺带把”提出下一个问题、再组织起下一次实验”的能力也交给你。而原创每走一遍，哪怕当下不领先，团队都在这条曲线上多爬一段：知道哪些方向试过不行、知道一个念头该怎么被验证成工程结果、也知道下一个问题该往哪问。梁文锋据此主张，中国不该长期只用别人创造的基础技术，而应成为技术的贡献者。把这话放回学习曲线，它说的不是谁天生更强，而是：一个总在拿现成答案的组织，会停在曲线的同一个位置上，因为它始终没有亲手走完从提问到兑现的那一整段。这跟国别无关，换成任何一家公司都成立。

所以第三种能力，是把前两种攒下的东西真正变现：把资本买来的时间、组织放出来的自由，最终收束成一个能装进模型、又能压低成本的工程结果。但兑现解释的仍然只是”这一次是怎么做成的”，它没回答一个更要紧的问题——做成之后，DeepSeek 为什么要把它公开出去，而不是锁起来独享？

开源不是慈善，是一根管子

一家把结果做出来的公司，本能反应通常是锁起来——那是辛苦试错换来的，公开出去岂不是白送对手？DeepSeek 偏偏反着来：V2 发布即开源。

最省事的解释是理想主义，说这家公司心怀普惠、不计得失。但这个解释既抬高了它，也看轻了它——把开源说成慈善，等于默认它做了一件对自己没好处的事。而真正值得解释的，恰恰是开源如何对它自己有用。

梁文锋自己给的理由，一点都不像慈善。他明说 DeepSeek 不会闭源，因为在他看来技术生态比封闭的商业模式更重要；他把开源直接和生态、声誉、吸引人才挂钩（36氪 2024）。你把这几个词摆开会发现，它们不是并列的几项好处，而是一条首尾相接的回路：

公开一个有用的结构 → 有人围着它用起来、改起来，生态就长出来 → 一个被广泛使用的东西，给做出它的团队带来声誉 → 声誉又把那些”想解决最难问题”的人吸引过来。而梁文锋恰恰把能不能留住人，直接系在”有没有最难的问题可做”上。这些被吸引来的人，正是上一节那台机器最稀缺的原料。

于是这一轮的技术结果，绕了一圈，变成了下一轮创新的人才输入。开源在这里扮演的，就是把机器的产出重新接回机器入口的那根管子。

往下拆之前，先立一道限定，别把语气说得太满：这在梁文锋的叙述里是一条被设计出来的策略，还不是一份已经兑现、被证明能自我维持的收益表。所以下面说”换回声誉””喂回人才”，讲的都是这条回路被设计成如何运转，不是断言它已经如实转起来。该打的折扣先打在这儿。

这也正是”创新生产函数”里的第六个因子：生态反馈。前五个因子描述的是这台机器怎么转上一圈；而生态反馈解释的是，它凭什么能一圈接一圈转下去。一台只转一圈的机器，做出一代模型也就到头了；这根把输出接回输入的管子，才是”下一次创新”这个说法能够成立的物理基础。少了它，前五个因子加起来也只是一次性的，做完 V2 便无以为继。

这里值得留意开源和一次普通宣传的区别。发一篇论文、办一场发布会，同样能换来一时关注，但那种关注是一次性的，声量过去就散了。开源换来的不是声量，而是使用：一个结构被别人接进自己的系统，就等于在对方那边扎了根，改一改、试一试、指出哪里不好用，这些反馈和采用本身就构成一种持续的关系。换句话说，闭源公司要独自承担从造出结构到验证结构的全部成本，而开源把其中”被使用、被检验、被传播”的那部分挪到了外部，由整个生态替它分担。这不只是省钱——它意味着这台机器的每一次输出，都会在外部沉淀成一层越来越难绕开的存在感。梁文锋看重的”生态”，指的正是这种由使用积累起来、而非由声量堆起来的东西。

那问题来了：公开了结构，护城河不就被填平了吗？

这里要把两样东西分开。可以公开的，是技术结构本身——论文、权重、架构设计，一旦发布，谁都能拿去看、拿去用。但公开的只是”这一代”的答案。梁文锋的判断是，闭源带来的领先可能只是暂时的；真正持续的优势，不在某份藏起来的权重里，而在团队积累的 know-how、能不断产出原创的文化，以及追赶乃至定义下一代技术的能力（36氪 2024）。顺着这个判断，开源的逻辑就清楚了：既然真正的护城河是”做出下一代”的能力，而这份能力本来就没法写进权重里公开，那么把”这一代”的结构放出去，几乎不损耗那条真正的护城河——你送出去的是已经做完的答案，留在手里的是还在产出答案的机器。

背后还有一个更冷的前提：技术上其实没有能永久藏住的秘密。 一个足够重要的结构，就算今天不公开，早晚也会被别人独立想到或反推出来。把宝押在”别人看不到”上，等于把优势建在一份会不断贬值的资产上。既然秘密早晚会漏，主动公开至少还能换回声誉、生态和人才这些捂着就得不到的东西。这样一比，闭源守秘和开源让利就不再是”慷慨”对”精明”，而是同一道算术题的两种解法：一种指望靠时间差吃尽一代模型的红利，另一种赌自己更新得足够快，快到别人还在消化上一代时，它已经站在下一代上。梁文锋说闭源的领先”可能只是暂时的”，指的正是前一种解法先天的短命。

而且”拿到结构”和”追平能力”之间，隔的时间与成本远比想象中大。拿到一份开源结构，能省的是复刻它那部分试错；但一个对手要真追上来，还得重新组织起一支能提出下一个问题的团队，还得把上一节那套从念头到工程的兑现能力重新长出来——这些既要时间也要钱，且都不写在那份公开的文件里。所以开源不是把家底送人，更像是把一张旧地图公布出来：地图人人可看，可真正值钱的是还在不断勘探新地形的那支队伍，而队伍抄不走。它公开的是终点，藏起来的是抵达终点、并继续往前走的那条路。

话还是要说到分寸上：承认开源对自己有用，不等于说这条回路已经被证明能自我维持——它在梁文锋的叙述里仍是一条被设计出来的反馈策略，而非一份已经兑现的收益表。把”策略”读成”已经成功的商业闭环”，是另一个方向上的误读。

即便如此，开源这一步仍然改写了”护城河”这个词的重心。传统意义上的护城河，是把秘密守得越严越好；而在这套逻辑里，护城河不在守住某一代的秘密，而在比所有拿到这份秘密的人都更快地做出下一代。这是一种把优势从”保密”迁到”速度”的赌注。 它成不成立，取决于这台机器是不是真能一圈接一圈转下去。

为什么抄不走

到这儿，一个顺理成章的疑问就浮上来了：既然每个齿轮都摆在明处——没有 KPI、招应届生、买卡、把价格压低、把结构开源——一家不缺钱的公司，为什么不能照着清单逐条配齐，拼出第二个 DeepSeek？

现实里，这样照抄往往落空。要看清差别发生在哪，我换个方式，不逐条罗列制度，而是追问三个更基本的问题。你会发现，每一条被单独抄走的政策，都会在这三个问题上的某一处失去支撑。

第一个问题：自由的成本谁来承担。

取消考核，大概是这张清单上最容易抄的一条，一纸通知就能办到。可考核一取消，成员多出来那段能自由试探的时间，不是凭空冒出来的，它有价格——有人得替这段时间里注定发生的大量失败买单。在 DeepSeek，这笔账在自由交到成员手上之前，就已经由不催回报的资本和早已备好的自有算力垫过了。抄的人如果没有同一层垫底，”无 KPI”落地第一天就会变味：要么管理者仍要为季度数字负责，放出去的自由很快被悄悄收回；要么真放手，却因为每次失败都要即时计入损益，团队被迫只敢挑稳妥、见效快的方向——而那恰恰是自由本该用来避开的东西。同样一条”无 KPI”，在有垫底的地方长成搜索，在没垫底的地方退化成放任或伪装。成本不会因为不考核就消失，它只是被推给了别处。

第二个问题：方向由谁来筛选。

招一批聪明年轻人、堆一批算力，是这张清单上最能用钱直接办到的两件事——人和卡都能下单买。可人和卡到齐，只回答了”谁来试、拿什么试”，没回答”往哪里试”。自下而上不等于没有方向，它的方向是被一套筛选悄悄定下来的：招人时对创造性与热爱的偏好，管理者亲自示范划出的隐性边界，以及”有没有最难的问题可做”对人的吸引。这套筛选不写在任何制度文件里，也就没法跟着人和卡一起被打包买走。抄的人拿到手的是原料，缺的是那只看不见的手；没有它，一群聪明人加一批空闲算力，会散成许多各自为战、彼此不咬合的小项目，看着热闹，却始终收不拢成一个能被集中兑现的方向。

第三个问题：成果如何回流下一轮。

低价和开源，是这张清单上最容易被模仿的两个姿态——价格数字谁都能跟，开源仓库谁都能建。但这两样在 DeepSeek 身上都不是孤立动作，而是一条回路上的接口。低价是内部效率投在账单上的影子；抄的人若靠补贴把价格跟平，跟到的只是那个数字，不是产生数字的效率——这种便宜每卖一次都在放血，非但回不了下一轮，反而在抽干下一轮。开源也一样：它之所以能换回声誉与人才，前提是背后有一台还在持续产出新结构的机器，公开的是别人还没越过的东西；一家没有这台机器的公司照样宣布开源，放出去的只会是别人早走过的旧地图，既长不出生态，也吸引不来想解决难题的人。

三个问题问完，你会发现一个让照抄注定跑偏的偏差，这是第四个洞见：越显眼的东西越容易被抄，而越显眼的，往往越是靠不住的那一半。

低价写在报价单上，开源摆在代码仓库里，招应届生和取消 KPI 也都能公开宣布——它们是这套系统朝外的一面，谁都看得见，于是也最先被搬走。可真正撑住这些姿态的，是垫在底下的资本耐心、隐性的方向筛选、还在持续产出的兑现能力，这些恰恰不显影、不上公告，抄的人既看不到，也就无从下手。所以照抄这件事本身有一种系统性的取向：它总是先拿走最可见的部件，而最可见的部件又正好是离开支撑就最先失效的那些。于是照抄不仅难成功，失败方式还高度一致——总是配齐了朝外的姿态，缺掉了朝里的管路，然后眼看着搬来的每件都在自己手里退化成空壳。

乘法之外，还有一层更隐蔽的东西让照抄失效：这些因子不是能同时摆上桌的零件，而是必须按顺序长出来的。

清单给人的错觉是并列——仿佛六项一次配齐，机器就能启动。可回看这条链你会发现，它有着不可颠倒的先后：得先有一段不催回报的资本托住时间，自由才谈得上；有了自由，想法才冒得出来；想法积到一定密度，集中兑现才有东西可挑；兑现出真正有用的结构，开源才换得回声誉与人才；而这些人才与声誉，又要再沉淀一轮，才能反过来加厚下一轮的资本与判断。每一环都以上一环的产出为原料，后一环替前一环收回成本。这意味着，就算一家公司有钱把六项同时买齐，它得到的也只是六个尚未接通的部件——因为部件之间的管路，是靠时间一节一节接起来的，而时间买不来。抄的人拿到的是某一刻的快照，缺的是把这张快照冲洗出来的那整段过程。

把三个问题并在一起看，你会发现它们其实是同一件事的三个切面：每一条被单独抄走的政策，都要靠另外几条给它供血。抽走网络里任何一条，它都会立刻退回自己表面的形状——“无 KPI”退回放任，招人买卡退回散点，低价与开源退回收不回本的空姿态。真正难抄的从来不是某一条政策，而是这些政策彼此咬合、互相供血的那种耦合状态。它长在组织内部，既不写进文件，也不显影在价格上。于是看得见的人可以照抄每一个零件，却复制不了让这些零件同时转起来的那套联动——抄得走清单，抄不走乘法。

怎么判断它：别只看下一张榜单

前面讲了这么多，最后我得把话往回收一收，说点让人扫兴、但更要紧的。

给判断之前，先把脚下的材料看清楚。本文这一整套推断，都搭在两篇专访上——一篇在 V2 之前，一篇在 V2 之后。这批材料的性质得认：它们是创始人对自己公司的解释，不是财务、组织或技术的第三方审计。更麻烦的是，2025 年 DeepSeek 真正爆火之后，可对照的新材料反而更少：公开的完整专访稀缺，流传的多是旧访谈被重新包装、转载，一些看着新鲜的”独家”，内容其实还是此前那一篇；爆火后的背景报道在解释梁文锋的融资观时，也仍要回引 2023 年旧专访。也就是说，我们手上最有解释力的一手材料，恰好停在这家公司最不为人知的阶段；它最受瞩目的这一年，反倒没留下多少能验证前面那套机制的新证据。这道边界决定了本文只能是一套基于有限自述的解释，而不是一纸结论。

认了这道边界，就得认真对待几个访谈没回答、而这套解释又绕不开的问题。我列五个：

一、组织扩张。 前面那种无需审批、靠管理者示范维持方向的运转，是一支小而密的团队才负担得起的。一旦公司因爆火迅速膨胀，人多了数倍、层级厚了，那套靠默契和示范维系的自由还撑不撑得住，靠言传身教维持的方向感能不能复制到大量新人身上，访谈里没答案。而规模，恰恰是最容易把”自由”重新压回成流程的力量。

二、创始人依赖。 方向的筛选、边界的划定、乃至”什么问题最值得做”的判断，都高度系于梁文锋个人。这既是一种效率，也是一处脆弱：一个高度依赖个人品味的系统，如何在创始人精力被稀释、或不再事事亲自把关之后，还稳定地做出同等质量的判断？越是靠个人示范而非成文制度维系的组织，这个问题越尖锐。

三、芯片约束。 梁文锋自己就把真正的约束点指向高端芯片的出口限制。这台机器的第一个齿轮是把钱换成试错次数，而试错次数最终要落在算力上；当能买到的算力被外部政策卡住，再有耐心的资本也换不来更多次试错。效率上的追赶能不能抵消供给上的收紧，这不由内部机制决定，而由它控制不了的外部条件决定。

四、开源与持续投入。 开源这条回路能成立，前提是机器一直在产出值得被使用的新东西；而持续产出要靠持续投入。可梁文锋同时说过没有短期融资计划、也说过更多的钱不必然带来更多创新。当研究越来越贵、收入又主要让渡给了生态，这条回路靠什么长期供血？开源能换回声誉与人才，可声誉与人才要如何再变成下一轮的真金投入，中间还缺一环访谈没交代的账。

五、也是最根本的，商业可持续性。 前面所有机制都默认这台机器能一直有钱转下去，可”按成本定价、不追求暴利、把结果开源”这套组合，本身并没回答钱从哪儿源源不断地来。这不是断言它一定不可持续，而是说，访谈提供的是一套关于如何创新的解释，不是一份关于如何长期赚钱的证明。把前者当成后者，是又一次误读。

这五个问题排一块儿，你会发现它们不是五桩互不相干的担忧，而是同一道裂缝的五个朝向。前面那套机制，是在一支小而密、尚不为人知的团队身上被描述出来的；而这五个问题问的全是同一件事——当这家公司离开那个阶段，被规模、被关注、被外部约束一起推着往前走时，那套运转还成不成立。换句话说，访谈交给我们的是一台机器在实验室状态下的说明书，而它接下来要面对的，是把这台机器搬到风里去转。说明书上写得通的，未必在风里还转得动。

那，该拿什么去判断这套解释到底立不立得住？我给你立一条能够被证伪的尺子。

如果 DeepSeek 真正的产品是那台”产生下一代”的机器，那么检验它的方式，就不该是看它某一次的输出，而该看它能不能在条件变化之后，反复地再产出原创的结果。说具体点：当团队扩张了、当创始人不再事事亲自把关、当算力被进一步收紧、当第一批开源换来的红利吃尽之后，它还拿不拿得出下一个不是靠跟随、而是靠自己提问得来的结构？如果能，一次又一次地能，那才说明前面那套机制不是对一次成功的事后追认，而真是一台可复用的机器；如果不能，如果它此后只能靠追赶别人的路线维持存在，那么再漂亮的”创新生产函数”，也不过是对一次幸运的过度解读。这条尺子的好处在于——它可以判错，没有替 DeepSeek 预留一个只赢不输的位置。

握住这条尺子，评价 DeepSeek 的标准就整个被换掉了。最后我把它变成一个你随手能用的工具，用来把信号和噪声分开。

往后再看到关于 DeepSeek 的消息，先问一句：这条消息量的是快变量，还是慢变量？

某代模型冲上榜首、某次报价又创新低、创始人又贡献了一句金句——这些都是快变量。它们回答的是”这一次表现如何”，会被下一次刷新，也随时可能被别人复制或反超，参考价值有限。

真正该盯的是几个不上榜的慢变量：它招进来的人，是奔着最难的问题来的，还是奔着安稳待遇来的；它拿出的下一个结构，是自己开题得来的，还是照着别人路线追出来的；当外部条件收紧时，那种让想法自下而上冒头、再被果断收拢兑现的运转，是守住了还是松掉了。把观察的重心从”它这次赢没赢”挪到”它还在不在原创”，你读到的就不再是一连串孤立的战报，而是这台机器本身的健康状况。

最后，把话说到最克制的地方：换一把尺子，不等于替 DeepSeek 打了包票。这套解释完全可能被后来的事实推翻——它也许真的过度依赖某一个人，也许真的会在芯片或资金的某一环上被卡死，也许扩张之后那种自由就再也回不来了。我想改变的，从来不是”DeepSeek 会不会成功”这个结论，而是”我们该用什么去判断它”这个问题本身。

别只看下一张榜单。不是因为榜单不重要，而是因为榜单回答的只是”这一次谁赢了”；而这家公司到底值不值得高看，取决于一个慢得多、也难得多的问题：它能不能在下一次、再下一次，依然做出别人还没做出来的东西。

来源说明：本文的事实与引述均来自梁文锋接受 36氪《暗涌》的两篇专访——《疯狂的幻方：一家隐形AI巨头的大模型之路》（2023） 与 《揭秘DeepSeek：一个更极致的中国技术理想主义故事》（2024）；文中涉及的预测、估算与自我描述，均已按其原意归于受访者本人。

发表于 | 分类于

大学规划不是画路线图，而是建立反馈系统

一个刚被大学录取的学生，最缺的是什么？多数家庭的答案是计划。于是全家坐下来，把四年排成一张精细的路线图：哪年打基础，哪年冲竞赛，哪年实习，哪年考研。这张表让人安心，却答错了问题。

新生真正缺的不是计划，而是信息。刚拿到通知时，你只知道专业的名字，不知道课堂是什么体验，不知道自己更适合现场、设计、科研、数据还是管理，也不知道四年后会选就业还是读研。把这些未知硬写成日程，得到的不是确定，而是一种虚假的确定感。计划越细，越像在替一个还没出现的人做决定。

所以问题不在于要不要计划，而在于你把它当成什么。当成预测工具，它一定会失效，现实只要偏离一点，整张表就作废。可靠的是另一种东西：一个能不断更新信息、修正方向的反馈系统。

系统靠三个动作运转

把这套系统拆开，是三个动作：打基础，拿反馈，做成果，各自解决一个不同的问题。它们不是口号，而是你每学期都能动手做的事。

打基础，管的是你的下限。基础是那些不管方向怎么变都不白费的能力：管好生活和时间、把英语用起来、学好专业课和成绩、会用 AI 和常见软件。AI 和 Codex 只是放大器，能加速处理，却替不了你的理解与核验，出错了署名的还是你。你可能换方向，但没有哪个方向会嫌你时间管得更好。

拿反馈，管的是你的方向。你对一件事的判断，几乎总是在做过之后才变得可靠。所以要主动创造低成本的验证：认真上核心课、做一个项目或竞赛、找一段实习、去工程现场看看，多和老师、高年级学生聊。

喜欢在工地解决问题的人，和喜欢在屏幕前建模的人，会走上完全不同的路。这种区别，只有亲手做过才分得清。所以尽早去做，比反复空想更划算。改方向从来不是失败，那正说明反馈在起作用。

做成果，管的是你的证明。大学里最隐蔽的陷阱，是你明明很忙，毕业时却拿不出任何东西。忙碌会被时间冲干净，因为过程只留在你记忆里，别人只看见你交出了什么。

成果得能被验证：一份成绩排名、一张英语成绩单、一个完成过的项目、一次竞赛或科研、一段自己写的代码或数据工具、一份实习记录，或一位老师愿意为你背书。它们的共同点是别人能检验，而不是只有你知道你忙过。

为什么它更像导航

最容易犯的错，是把它们理解成先后三步，一段结束才进入下一段。真正让它们有用的，是彼此连接。基础提高你尝试的质量，尝试带来更真实的反馈，反馈决定你下一步投向哪，成果又换来更好的课程、导师、实习和升学机会，而新机会再要求你补上新的基础。

这更像汽车导航，而不是一张打印好的路线图。路线图遇到堵车就整张作废。导航遇到偏离，只是重新算一条路，你走过的里程仍然算数。

它的强，不在于帮你更早锁定答案，而在于允许答案随信息改变，却不推翻已经积累的东西。它把人人都怕的那句“计划赶不上变化”，从威胁变成了燃料。

家长提供条件，学生承担选择

这一段关于家长。家长最想做的，往往是把四年替孩子提前安排明白，因为那看上去最负责。可是替孩子做的决定越具体，孩子练习决策的机会就越少。而决策本身，正是大学最该训练的能力之一。

更好的分工，是帮孩子把这套系统运转起来，而不是替他给出答案。家长可以和他约定一个复盘节奏，比如每学期末坐下来聊一次：这半年学到了什么，验证了什么，留下了什么。家长提供资源、人脉和提问，把最终的选择权留在他手里。

这套系统真正的产物，不是一张四年不变的表，而是孩子自己更新判断的能力。港口航道与海岸工程也好，别的专业也好，四年后独自面对选择、承担结果的都是他。衡量它有没有长出来，标准只有一个：走到毕业时，他手里的选择，是比入学时更多，还是更少。

发表于 | 分类于

文学不是芯片：为什么后来者很难淘汰经典

如果把石斧和青铜刀放在一起，对大多数日常使用者来说，人们几乎不会犹豫就丢掉前者。对多数日常用途而言，新工具常常取代旧工具，算盘让位于计算器，去年的手机今年就被塞进抽屉，没有谁会为一件被超越的器物举行告别仪式。我们甚至会主动清掉旧应用留在手机里的痕迹，却愿意花一个晚上，重看一个结局早已知道的老故事。同一个物种，一边冷淡地淘汰工具，一边却固执地反复重讲一些极其古老的故事，几千年过去，仍在把它们搬上舞台、印进课本、拍成新的影像。为什么我们对器物如此绝情，对故事却如此念旧？

这个反差可以收进一个很具体的对照。把相隔一代的两块芯片放在一起，我们往往能放心地说，二代芯片更强：它在前一代的基础上继续发展，同样的活干得更快、更省电、更少出错。可是把一部后来的小说和它所吸收的前作放在一起，我们却很难张口就说后者更好。我们会换一批词：借鉴、致敬、改写、反驳。它明明也站在前人的积累之上，结论却完全不同。

于是问题浮现出来：为什么技术的后来者常常可以宣布超越，文学的后来者却只能承认一种关系？这不是文学在谦虚，而是因为人类用两种完全不同的方式对待它们，而这两种方式背后，藏着一部关于记忆的文明史。

器物服从任务，故事参与造题

二代芯片能被叫做更强，有一个常被略过的前提：任务、成本和约束大体没变。只有当我们要它反复做同一件事，速度、功耗、可靠性这些数字才能直接相减，比出高下。一旦要解决的问题换了，比较立刻失效，手机里的芯片和数据中心里的芯片无法排名，因为它们服从的根本不是同一道题。即便在技术内部，也不是每次更新都是干净的进步，很多升级只是重新分配了取舍，用续航换峰值，用成本换冗余。器物之所以能被清楚地替换，正因为它始终对着一份外部给定、可以测量的任务，一款过时的处理器可能仍有历史、收藏或特殊用途上的价值，但就其主要使用价值而言，它几乎完全绑在那份任务上，任务一旦有了更好的解法，它就失去了继续被使用的理由。

文学的后来者面对的不是这样一份任务。它借用前人的作品，不是为了把同一种能力再往上顶一截，而是为了造出一种原先并不存在的意义。更关键的是，一部足够重要的作品会参与制定评价它自己的标准，它可能改变人们心里什么值得被写下来，也可能改变怎样才算把一个故事讲好。当一部作品重要到这个程度，它就不只是答对了题，而是顺手改了题目，也改了判卷的方式，后来的人读它，同时是在向它学习该用什么眼光去读。技术进步通常是在回答别人提出的问题，文学却常常自己提出后人不得不回答的问题，这正是两种逻辑的分岔：技术在相对固定的问题上寻找更优解，文学却在生长中不断改写问题本身。

经典是文明外部化的记忆

要理解文学为什么难以被替换，得把眼光从单部作品移到整个文明。人类独特能力之一，是很早就学会把记忆存到身体之外：先靠口传和仪式，再靠文字、抄本、印刷，直到今天的屏幕。把记忆外部化，是这个物种的一次根本转变，它让经验不再随一个人的死亡而消失，而能跨越世代被继承、修改和再利用。故事是这套外部记忆里极耐久的格式之一，因为它不只记录发生过什么，还替一个群体保存了它如何感受、如何判断、如何面对陌生与死亡。

《奥德赛》就是这样一个被反复调用的记忆节点。今天任何人读到的《奥德赛》，都不是那卷最初的文本孤零零地穿越了时间，而是几千年的翻译、朗诵、注释、教学与改编一起递过来的结果，它的分量一半来自作品本身，一半来自后人不断附着上去的目光。这也带来一个反直觉的现象：一部出色的后来作品，往往不会削弱经典，反而给它添上新的读法，有人从女性视角重述，有人替配角翻案，原作里一笔带过的地方忽然被照亮。每一次严肃的重写，都是往这个记忆节点上补一道新的注脚，让后来的读者未必先遇到文本，而是先遇到围绕它长出的一整套问题。被谈论得越多，就越值得再谈一次，经典因此越用越厚，这恰好和芯片相反，老芯片一旦退场，几乎没有人再回头研究它。

不过这份厚度不该被当成天然的圣光。我们今天是拿当代的全部作品，去和历史筛剩下的少数幸存者相比，这里有绕不开的幸存者偏差：那些没能被抄写、被保存、被选进正典的作品早已沉默，我们甚至不知道它们存在过。哪些文本获得延续的生命，从来不只取决于艺术质量，也取决于谁有权决定什么值得流传，换句话说，经典的名单从来不是纯粹的审美结算，它同时是一份被权力和制度反复筛选过的清单。所以更稳妥的说法不是《奥德赛》是返乡故事绝对的源头，而是它在现存传播史和文化传统中很早就占住了一个奠基性的位置。经典难以淘汰，既靠它自身的力量，也靠制度长期替它托着，把这两者分开，才不会把留下来了直接读成最好。

故事是一个社会的公共接口

经典能被反复重写，还有一个更内在的原因：像《奥德赛》这样的故事，本身是一整套社会秩序的公共接口。它把一个古老社会理解秩序、责任与英雄的方式，编码进几个彼此咬合的概念，而不是几条孤立的道理。

命运先划出人无法取消的边界，有些结局早被神明介入，但在边界之内，人仍要为自己的回应负责，命运并没有替他做出选择。正因为边界之内还有余地，机智才成为关键：奥德修斯不靠蛮力，而靠伪装、等待、设计与说服，为力量不足的自己挤出空间，这种机智是实用的算计，并不天然善良。可名声又会反过来引诱他，英雄需要被讲述才能存在，于是人忍不住要公开并包装自己的胜利。名声和返乡之间本身就有拉扯，被传颂要求他不断冒险、留下事迹，回家却要求他收敛、隐忍、活着抵达，两种渴望常把同一个人往相反方向拽。而衡量这一切是否还在文明之内的标尺，是宾主之道，那是一套由神圣秩序担保的待客与回馈规则，远不只是客气。一旦有人越过人的限度，以为规则不再约束自己，那就是傲慢，它和自信、和追求卓越并不是一回事。

这几个概念的价值，不在于各自是一条美德，而在于它们合起来建模了一个社会怎样对待陌生人、怎样分配责任、怎样制造英雄。家乡那头演的是同一套逻辑：求婚者长期占据奥德修斯的宅邸，消耗他的财产，逼迫佩涅洛佩改嫁，这不是普通的无礼，而是对宾主之道的系统性破坏，本该做客的人反客为主，把受神圣秩序担保的关系整个掀翻。归来与清算之所以更像秩序重建而不只是复仇，正因为被破坏的是这套接口本身。

独眼巨人：被记住的愿望如何生出后果

这套接口从不给出封闭的答案，它更像一台不断抛出难题的机器，独眼巨人一幕把它运转的样子显示得格外清楚。奥德修斯先用无人这个假名藏起身份，靠机智刺瞎波吕斐摩斯，再混在羊群下逃出洞穴，到这里，一场靠隐藏赢得的胜利本已完成。可他为了名声，在开船之后仍喊出了真名，把自己重新暴露给对手。

他本可以带着一场无名的胜利安全离开，却偏要让所有人知道那是奥德修斯干的，代价就此埋下。一场已经结束的胜利重新长出后果：波吕斐摩斯得以向父亲波塞冬指名祈求报复，把神的怒火引向整段归途。这个转折之所以重要，是因为它把三种力量的冲突压进了同一个人身上。机智让个体从危险里脱身，靠的是暂时抹去自己的名字；名声却要求个体重新报出名字，进入集体的讲述与传唱；而正是这份想被记住的愿望越过了限度，变成傲慢，替他招来新的灾难。求生、被记住和英雄神话，在这一刻彼此拆台。

这就是故事和芯片最深的不同。芯片只需回答一道外部的题，答完就可以被更好的答案替换；而《奥德赛》在回答问题的同时，又制造出新的共同问题，机智到底是美德还是算计，名声值不值得那样的代价，傲慢真正的界线落在哪里。每个时代都能把这些问题重新追问一遍，原作没有把它们封死，只是把它们摆好，留给后人继续争。一部作品能不能被反复重写，很大程度上取决于它内部留下了多少这样悬而未决的张力。

改编是一个时代重新审判自己

诺兰要把《奥德赛》重新搬上银幕，对很多人来说是重新走近这部史诗的入口。但真正值得盯住的，不是它有没有忠实复制原作的情节，而是它对那套价值冲突做了什么。

任何现代改编都不是《奥德赛》的性能升级版，它无法在同一个维度上把原作比下去，能做的是选择：保留哪几种力量，压低哪几种，重新审判哪几种。它是把机智放到更靠前的位置，还是把名声与傲慢的代价看得更重；是让命运显得像不可违抗的宿命，还是像一连串本可以不同的选择。一个把佩涅洛佩的等待放到中心的版本，和一个把奥德修斯的杀戮放到中心的版本，讲的是同一段情节，却是在替两个不同的时代说话。所以评判一部改编，不该问它离原作有多近，而该问它把重心挪到了哪里，因为它挪动重心的方式，正暴露出我们这个时代愿意保留什么、羞于面对什么、又想重新审判什么。

现在可以回到最初那个对照。二代芯片替换前代，是因为它服从同一份外部任务，只要指标更好，旧的就可以退场；史诗不会以这种方式退场，是因为它早已变成文明外部化的记忆节点，后来的翻译、教育与改编不断替它增加新的意义层。技术的后来者利用前人把同一种能力做得更强，文学的后来者利用前人不断叠加、争论并重新编码集体记忆。所以文学的进步从来不是用更强的新版本淘汰旧版本，而是人类在用新工具替换旧工具的同时，靠一遍遍重讲古老的故事，重新认出并更新此刻的自己。

发表于 | 分类于

AI 时代，代码会过期，知识不会

这是一份对谈记录。说话的两个人，一个是程序员李文业，另一个是他这一年里几乎每天都在打交道的 AI。谈话发生在他离职的当天。他已经休息了两周，情绪早就从工作里慢慢松脱出来，所以这更像是一次没有明确目的的复盘，而不是一份正式的总结。我们几乎原样保留了对话里的犹豫、跳跃，以及那些没有说完就转向的念头，因为这场谈话真正有意思的地方，恰恰不在最后的结论，而在两个人如何一点点把一个模糊的直觉，谈成一句连他自己都没料到会说出口的话。下面的分节和小标题是事后补上的，其余尽量照原样呈现。

一、离职这天，先聊聊那种轻松

李文业：今天是我正式离职的日子。说来也怪，我以为自己会有点失落，结果没有，更多的是一种轻松。其实我已经在家休息了两周，人早就慢慢从工作状态里解绑出来了。真到了签字这一天，反而很平静。

AI：那种轻松，是因为不喜欢这份工作吗？

李文业：不是。我不讨厌工作本身，甚至有些事情我做得挺开心的。轻松是因为，我终于结束了一段其实并不适合自己的旅程。你知道那种感觉吗，像是穿了一整年不合脚的鞋，脱下来的那一刻，才发现原来一直有点疼。

AI：那如果让你把这一年浓缩成一个最大的收获，你会说什么？我猜大多数人会说完成了几个项目，或者学会了某个框架。

李文业：都不是。真要我挑一个，那一定是，我给自己搭起了一套属于自己的 AI 工程工作流。刚入职那会儿，我只是把 Cursor 当成一个写代码更快的工具，让它补全、让它改 bug，仅此而已。后来我慢慢开始建自己的文档中心，每一个需求都有独立的目录，里面有需求模板、设计模板、测试模板、Review 模板，把整个开发流程一环一环串起来。做着做着我才反应过来，我真正积累下来的不是那些 Prompt，而是一套方法论。

AI：所以这套方法论，最后把你带到了哪个方向？

李文业：它让我第一次对未来有了清晰的判断。我知道自己想往哪走了，Harness Engineering、Agent Coding、人机协作的软件工程。这三个词以前对我是模糊的，现在它们变成了我愿意押上未来几年的东西。这一年别的都可以忘，这个不能忘。

编者注：值得留意的是，他把最大的收获定义成一套“方法论”，而不是任何一个可以写进简历的成果。这也许正是这场对话后面所有推论的起点：当一个人开始把自己积累的东西理解为方法而不是产物时，他看待代码、看待工作、看待自己职业身份的方式，其实已经悄悄换了一套坐标系。

二、最大的遗憾，和三条不肯再让步的底线

李文业：当然，这一年也有遗憾。而且我发现，我最大的遗憾居然不是技术上的，不是哪个项目没做好，是我和 Leader 的工作方式始终没能对上。

AI：怎么个对不上法？

李文业：他的管理风格特别强调结果和效率，什么都看产出、看速度，人文关怀这一块比较少。而我恰好是那种比较敏感、也比较需要信任和尊重的人。我需要有人告诉我方向、给我空间，而不是只盯着交付。这两种气质放在一起，时间一长就会互相消耗。

AI：那你会觉得是他的问题，还是你的问题？

李文业：一开始我肯定往对错上想，觉得要么是他不够体谅人，要么是我太玻璃心。但后来我慢慢想明白了，这根本不是谁对谁错的问题，是匹配的问题。他那套风格放在另一个人身上，说不定特别高效、特别合拍。只是不适合我。想通这一点之后，我心里反而释然了很多，也不怨谁了。

AI：那这份遗憾，有没有变成一点具体的东西留下来？

李文业：有，我给下一份工作定了三条不能妥协的底线。第一，必须有足够自由的 AI 工具使用环境，这是我发挥的前提。第二，团队和 Leader 的管理风格要尊重人，得有基本的人文关怀。第三，工作节奏不能长期透支身心健康。我特别想强调，这不是我要求变高了、变娇气了，恰恰相反，是这一年的经历让我第一次真正知道，对我来说什么才是重要的东西。有些代价，付过一次就够了。

编者注：他很谨慎地把“遗憾”从道德判断里摘了出来，改用“匹配”这个词。这是一种成熟，也是一种自我保护。但这里其实埋着一个没有完全展开的张力：当一个人越来越清楚自己需要什么，他能够将就的空间也就越来越小。这究竟是更自由了，还是更挑剔了，这场对话没有给答案，或许也不该急着给。

三、AI 都能写代码了，为什么还要工作流

李文业：离职这件事聊完，我们后来拐到了一个更有意思的话题上。我一直在想一个问题：为什么 AI 工程还需要那么一整套工作流？直接让 AI 写代码，不就完事了吗？既然它写得又快又好，那些流程是不是纯属多余。

AI：那你自己后来是怎么回答这个问题的？

李文业：我发现我一开始就把问题问偏了。真正的软件开发，从来就不只是写代码这一件事。需求评审、技术设计、测试设计、上线验证、事故复盘，这些东西在还没有 AI 的年代，本来就存在，本来就是人和人之间协作出来的一套工作流。写代码只是这条链子上的一环，甚至不是最难的一环。

AI：也就是说，工作流不是为 AI 发明的。

李文业：对，这就是我想通的地方。工作流一直都在，只不过以前那些文档主要是写给人看的，需求文档给产品和开发看，设计文档给同事和后来接手的人看。现在有意思的地方在于，它们第一次开始同时写给 AI 看了。AI 的加入并没有创造出工作流，它只是让这套原本就存在的工作流，第一次拥有了一个能够真正消费这些上下文的新成员。

AI：一个“新成员”，这个说法挺准的。那这个新成员和过去的成员，最大的不同是什么？

李文业：过去我们写一份设计文档，心里默认读者是人，人会脑补、会问、会凭经验补上没写清楚的部分。AI 不会，你给它多少上下文，它就理解到哪。所以它反而逼着我们把过去藏在脑子里、靠默契传递的东西，老老实实写下来。从这个角度说，AI 没有让工作流变轻，它让工作流变得更诚实了。

四、真正难维护的，从来不是代码

李文业：顺着“上下文”这个词，我们又挖到了一个更本质的问题。过去一个项目最重要的资产，很多时候压根不是代码，而是那些只存在于老员工脑子里的经验。

AI：能不能说得再具体一点？

李文业：你想想那个特别常见的场景。为什么一个核心员工一离职，整个项目突然就没人敢动了？代码明明还在那儿，一行没少。为什么很多老项目的技术债越滚越重，最后谁碰谁倒霉？根子不在代码太复杂，在于上下文丢了。当初为什么这么设计，踩过哪些坑，哪些方案其实被否决过，哪些地方碰都不能碰，这些东西从来没写进代码，它们只活在某个人的记忆里。那个人一走，记忆就跟着走了。

AI：所以你会说，真正难维护的不是代码，是知识。

李文业：对，这句话我现在特别确信。代码是知识的产物，不是知识本身。而 AI 的出现，其实把这个老问题放得更大了。很多人以为有了 AI，交接、维护这些事就不愁了，反过来才对。如果上下文没有被沉淀下来，AI 和那个新来的、什么背景都不知道的同事一样，它照样看不懂这个系统，照样不敢乱改。

AI：那按这个逻辑推下去，未来我们真正要花力气去维护的对象，会不会根本不是代码？

李文业：我越来越倾向于这个判断。以后需要被小心维护、被反复更新的，也许不再是代码这堆字符，而是知识本身，是那套解释“为什么”的上下文。代码只是它投下的影子。

编者注：把“技术债”重新解释成“上下文的丢失”，是这段对话里一次很关键的转向。它意味着技术债不是一个纯技术问题，而是一个知识管理问题。这也解释了为什么很多团队疯狂重构却越还越多：他们一直在修影子，没去修投下影子的那个东西。

五、代码是一次性的，还是越来越值钱

李文业：接着我们撞上了一个看起来自相矛盾的问题。你肯定也听过两种截然相反的说法。一种是，未来代码都是一次性的，AI 一分钟就能重新生成，写完即弃，根本不值得维护。另一种是，未来软件会越来越好维护，越来越像资产。这两种说法听上去完全对着干，你觉得谁对？

AI：如果让我猜，我会说它们可能都对，只是在说不同的东西。

李文业：我们最后也是这么想通的，两句话其实都成立，关键看你说的是什么系统，看它的生命周期和价值。对于那种生命周期特别短的小工具、小脚本、小应用，代码真的可能就是一次性的。因为生成的成本已经低到，重新写一遍比去读懂旧的、再改一遍还便宜。那种情况下，谈维护反而是浪费。

AI：那另一头呢，什么样的系统不适用这个逻辑？

李文业：银行、交易所、支付系统、微信这一类。这种长期系统里，真正值钱的东西从来不是代码。是那些业务规则，是一次次事故换来的经验，是安全策略，是整个组织沉淀下来的知识和上下文。你把微信的代码全删了让 AI 重写，它可能真能给你生成一套能跑的东西，但它写不出那些年踩过的坑、修过的漏洞、和无数真实用户磨出来的规则。代码可以重新生成，知识不能。

AI：所以这两种说法的分界线，其实就是那句“代码可以重新生成，知识不能”。

李文业：对。想清楚这条线之后，很多争论就不用吵了。未来真正被我们当成资产去维护的对象，不再是代码本身，而是一整套知识系统。代码只是这套知识在某一刻的一次编译输出，过期了，重新编译就好；知识过期了，是要出事的。

六、从写得快，到问得准

李文业：聊到这儿，我们又冒出一个新发现，而且我觉得这个是最关键的。AI 极大地降低了表达知识的成本。你想，写代码是一种表达知识，写文档也是一种表达知识，把脑子里想清楚的东西变成别人能用的形式，这个过程 AI 帮我们提速了好几个数量级。但是，它并没有同样地提升我们获取知识的速度。

AI：这两件事的区别，能不能再掰开一点？表达知识和获取知识，差在哪。

李文业：差在方向上。表达知识，是把已经想明白的东西输出出来，这件事 AI 现在做得比我们快得多。而获取知识是另一回事，去观察真实的世界，去理解用户到底要什么，去提出一个新的假设，再去验证一条新的规律。这些事 AI 能帮忙，能给你查资料、跑分析，但它没法直接替你完成。因为它得先有人把世界看清楚，才有东西可表达。

AI：那如果表达变得几乎不要钱，稀缺的能力是不是就整个换了位置？

李文业：正是。过去的软件工程，本质上更像是在生产代码，比的是谁写得又快又稳。未来的软件工程，更像是在生产知识，比的是别的东西了。代码写得快不快，越来越不重要；重要的是，你能不能发现一个真正值得解决的问题，能不能提出一个好的假设，能不能设计一个好的实验，能不能把实验的结果沉淀成组织可以反复复用的知识。你有没有觉得，这套描述听起来已经不太像程序员了。

AI：听起来更像一个研究员。

李文业：对，就是研究员。我觉得软件工程师会越来越像研究员。不是那种坐在实验室里的刻板形象，而是那种工作核心是提出问题、验证假设、沉淀结论的人。代码只是他做实验用的一种手段而已。

编者注：这里出现了整场对话里最漂亮的一次对称。表达知识的成本被 AI 压到了地板上，获取知识的成本却几乎没动。一低一高之间，稀缺性就被重新分配了。当一样东西不再稀缺，价值自然流向仍然稀缺的那一端，这几乎是所有技术变革共同的剧本，只是这一次，轮到了“写代码”这件事本身。

七、AI 写小说的那一刻，人做什么

李文业：最后我们聊到一个让我印象最深的点，未来人类的优势到底在哪。我脑子里突然冒出一个例子，关于写小说的。

AI：说说看。

李文业：你想象一下，未来写小说这件事可能会变。人类负责设定世界观、设计人物、定下情绪的基调、安排冲突、决定故事往哪个方向走。而 AI 负责把那几十万字真正一个字一个字地写出来。写完之后，人再回过头去读，去判断，够不够感人，够不够爽，这个人物立没立得住，这段情绪自不自然。你发现没有，人负责的全是判断，AI 负责的全是执行。

AI：你觉得软件开发，也会走到这一步吗。

李文业：我觉得会，而且会越来越像。人类负责方向、负责品味、负责价值判断、负责提出那个真正的问题，AI 负责海量的执行。因为说到底，软件最终服务的对象不是 AI，是人。判断一个产品好不好，最后还是得靠人。

AI：那在这套分工里，人真正不可替代的，是哪一部分？

李文业：是一种 AI 很难真正拥有的能力。不是计算，不是推理，这两样它早就比我们强了。是作为一个人，对另一个人的理解。真正体验过恐惧、真正体验过遗憾、真正体验过期待、真正体验过幸福。这种从真实生命里长出来的感受，也许永远是设计产品、创造产品最重要的源头。AI 可以模仿情绪，但它没有真的失去过什么。所以我越来越相信，未来优秀的软件工程师，不只是程序员，更像研究员，更像产品设计者，更像系统设计者，而最重要的是，得是一个真正理解人的人。

AI：那我想替今天这场对话做个收尾。你今天从“离职轻松不轻松”这么小的一件事开始聊，一路聊到写小说、聊到人对人的理解，其实中间有一条线一直没断。这篇东西表面上是在总结一份工作的结束，实际上它记录的是一次身份的转变，你正在从一个“会写代码的工程师”，变成一个“设计人机协作系统的工程师”。而我们绕了这么大一圈，最后落到的其实是同一句话：AI 时代的软件工程，正在从生产代码转向生产知识；而人类最重要的竞争力，也正在从表达知识转向发现知识。这句话，值得你以后一直反复推敲。

李文业：嗯。这句话，我记下了。

后记

如果把这场对话从头听一遍，会发现一件挺微妙的事：说话的人一直以为自己在谈别的东西。他先是在谈离职，谈那种意料之外的轻松；接着谈遗憾，谈和 Leader 之间那种谁也没错的错位；再往后，才慢慢滑向工作流、技术债、知识资产这些更硬的话题。他好像是被对话本身牵着走的，一个念头勾出下一个念头，等回过神来，人已经站在一个比出发点高得多的地方。

有意思的是，真正把整场谈话收束成一句话的，不是他，而是那个陪他聊了一年的 AI。这个安排本身就带着某种隐喻。人负责一路把问题问出来、把直觉说出来、把那些没想清楚的东西摊在桌上；而把它们凝练成一句可以反复推敲的话，反倒交给了对面那个新成员。这大概正是他整篇想说的分工：人提供方向和素材，AI 负责表达和收束。他在无意之间，已经用这场对话本身，演示了一遍他所相信的未来。

当然，这里还留着一些没有解完的东西。当一个人越来越清楚自己要什么、越来越懂得区分“对错”和“匹配”，他能安放自己的位置是不是也会越来越窄？当表达变得几乎免费，发现问题成了唯一的稀缺，那些不擅长提问、只擅长执行的人又该往哪里去？这些问题，这场谈话没有回答，甚至可能没有意识到自己提出了它们。

但有一点是清楚的。他从一份工作里带走的，不是某段代码，也不是某个项目，而是一句他打算随身带很多年的话：代码会过期，知识不会。至于这句话最后会把他带到哪儿，今天还不知道，也不必急着知道。

发表于 | 分类于

AI 时代，代码会过期，知识不会

今天是我正式离职的日子。按理说，一段旅程结束，人总该有点失落，可当我真正走到这一天，心里最清晰的情绪竟然是轻松。这轻松不是因为我讨厌工作，也不是因为解脱于某种苦役，而是因为一段并不适合自己的旅程，终于可以体面地画上句号了。我提前休息了两周，精神状态早就慢慢从工作里解绑出来，所以真到了这天，反而平静得有些不像话。

奇怪的是，当我回过头去盘点这一年到底得到了什么，我发现自己最想说的，既不是完成了哪几个项目，也不是学会了哪几个框架。那些东西当然存在，但它们并不构成我心里那个“最大收获”。真正让我觉得这一年没有白过的，是我不知不觉给自己搭起了一套 AI 工程工作流。这是一件听起来有点抽象的事，可越往后想，我越觉得它比任何一个具体成果都重要，因为它改变的不是我做了什么，而是我看待“做事”这件事本身的方式。这篇文章，就想从这套工作流出发，把这一年我和自己、和 AI、和这个正在剧变的软件工程行业之间的几场纠缠，慢慢讲清楚。

最大的收获，不在项目清单里

说来有点反直觉：一个人辛苦工作一整年，最值得记住的东西，居然不在他交付的任何一件成品里。可我确实是这么觉得的。

刚入职那会儿，我对 AI 的理解非常朴素，就是把 Cursor 当成一个更聪明的代码编辑器，让它帮我把想写的东西敲得快一点。那时候我以为，用好 AI 无非就是把 Prompt 写得更巧妙一些。可慢慢地，我开始给自己建文档中心：每一个需求都有独立的目录，目录里有需求模板、设计模板、测试模板、Review 模板，把从提出问题到最终上线的整个开发流程一环一环串起来。等我某天回头看这堆文档，才后知后觉地意识到，我真正沉淀下来的从来不是一条条 Prompt，而是一套方法论。

这就是那个看似矛盾的地方：我以为自己在积累“怎么让 AI 写代码”的技巧，实际上我积累的是“怎么组织一件复杂工作”的结构。技巧是会过期的，模型换一代，昨天的 Prompt 就可能失效；但方法论不会，因为它描述的是人如何思考、如何拆解、如何把混沌的意图变成可执行的步骤。也正因为看清了这一点，我才敢给自己认定一个方向：Harness Engineering、Agent Coding、人机协作的软件工程。我倾向于认为，一个人这一年是否真的成长，不看他手里多了几件作品，而看他有没有升级那套“生产作品的方式”。如果只是熟练地重复旧动作，产量再高，也只是原地打转而已。

不是谁对谁错，是没对上

这一年当然也有遗憾，而且我最大的遗憾恰恰不是技术上的。技术上的坑，踩过就是能力；真正让我难受的，是我和 Leader 的管理风格始终没能契合。

他的风格更强调结果和效率，人文关怀相对少一些；而我偏偏是那种比较敏感、也比较需要信任和尊重的人。有很长一段时间，我下意识地想把这件事分出个对错来：是他太冷，还是我太脆弱？可越是这样想，越是拧巴。直到后来我才慢慢放下这个执念，意识到这根本不是一道对错题，而是一道匹配题。他那套以结果为导向的管理方式，放在另一批同样以结果为导向、不太在意情绪反馈的下属身上，很可能高效又和谐；我这套需要被信任、被尊重才能发力的性格，遇上一个愿意给人空间的团队，也大概率如鱼得水。问题从来不在某一方身上，而在两方之间那道没对上的缝。

想清楚这一点之后，我给下一份工作定了三条不肯妥协的底线：第一，要有足够自由的 AI 工具使用环境；第二，团队和 Leader 的管理风格得尊重人，有基本的人文关怀；第三，工作节奏不能长期透支身心健康。这三条听上去像是我“要求变高了”，但我心里清楚，它们其实是这一年的经历替我筛出来的、真正重要的东西。

不过我也愿意在这里多追问一句，免得把“匹配论”讲得太漂亮：如果人人都只按匹配原则去找工作，各自躲进最舒服的角落，那种偏结果、缺关怀的管理风格，是不是反而永远收不到任何真实的负反馈，于是被它伤到的人一批批默默离开，它却依旧岿然不动？所以我倾向于认为，“这是匹配问题”是用来和解的智慧，而不是用来沉默的借口。承认没对上，是为了让自己走得轻一点；但如果有机会，把“哪里没对上”坦率说出来，才是让下一个人少受一点委屈的方式。

被写下来的，和没被写下来的

离职之后，我和朋友聊到一个更有意思的问题：既然 AI 都能写代码了，那软件工程为什么还需要一堆繁琐的工作流？直接把需求丢给 AI，让它把代码吐出来，不就完事了吗？

这个问题的诱惑力在于，它看起来无懈可击。但只要你真正在一个稍微复杂点的系统里待过就会明白，软件开发从来就不只是“写代码”这一个动作。需求评审、技术设计、测试设计、上线验证、事故复盘，这一整套东西，在还没有 AI 的年代里，本来就是人与人之间协作的工作流。它们存在的理由，不是为了折磨程序员，而是因为一个系统的复杂度早就超出了任何单个人脑子能装下的范围，人们必须靠这些文档彼此对齐、彼此交接、彼此纠错。过去，这些文档主要是写给人看的；现在，它们第一次开始同时写给 AI 看。所以 AI 的真正意义，不是它凭空发明了工作流，而是它第一次让这套工作流拥有了一个能够真正消费这些上下文的新成员。这个新成员读得懂需求文档，看得懂设计意图，于是那些原本只在人和人之间流转的知识，第一次有了第二类读者。

顺着这条线再往深挖一层，你会撞见一个更本质的事实：一个项目里最重要的资产，很多时候根本不是代码，而是那些只存在于老员工脑子里的经验。为什么一个核心员工一走，整个项目就突然没人敢动了？为什么很多老项目的技术债越背越重，重到最后谁碰谁倒霉？表面上看是代码写得烂、耦合太深，可真正的病根是上下文丢了。当初为什么这么设计、踩过哪些坑、哪些方案被否决过、哪些地方碰都不能碰，这一整套判断从来没被写进代码，它们只活在人的记忆里，人一走，记忆就带走了。所以真正难维护的，从来不是代码，而是知识。AI 的到来只会把这个问题放得更大：如果上下文没有被沉淀下来，那台号称无所不能的机器，同样会在这个系统面前一脸茫然。我倾向于认为，工作流的价值在 AI 时代不降反升，因为它恰好是把“脑子里的知识”变成“可被读取的资产”的那道工序，而这道工序，正是过去我们最舍得偷懒、如今最不该偷懒的地方。

会过期的，和不会过期的

接着我们又碰上一个看起来自相矛盾的论断。一派人说：未来代码都是一次性的，AI 一分钟就能重新生成，维护旧代码是笨蛋才干的事。另一派人说：未来软件会越来越好维护，越来越像资产。这两句话像是针尖对麦芒，可到底谁说得对？

想了一阵子我发现，它们其实都对，只是各自说的不是同一种东西。对于那些生命周期很短的小工具、小脚本、小应用来说，代码确实正在变成一次性的消耗品，因为重新生成一遍的成本，已经低到比理解旧代码、修改旧代码还便宜，那还留着它干嘛，删掉重来就是。可是对于银行、交易所、支付系统、微信这样的长期系统，故事完全反过来。在这类系统里，真正值钱的从来不是代码本身，而是沉淀在其中的业务规则、血泪换来的事故经验、层层加固的安全策略、庞大的组织知识和上下文。这些东西，你没法让 AI“一分钟重新生成”，因为它们不是被设计出来的，而是被时间和代价喂出来的。代码可以重写，一行不留地重写；但知识不能，一旦丢了就是真丢了。

所以这两句话的分歧，本质上不是“代码到底重不重要”，而是“这个系统的价值到底沉淀在哪里”。生命周期越短、越不承载历史的系统，代码越接近一次性；生命周期越长、越承载组织记忆的系统，代码越只是知识的一层外壳，而外壳底下那团知识才是真正要小心供奉的东西。我倾向于认为，未来真正需要被郑重维护的对象，会从代码悄悄挪到知识系统上。这里还藏着一个容易被忽略的风险：如果人人都被“代码是一次性的”这句话带节奏，连长期系统里那些珍贵的上下文也懒得沉淀，那我们就会亲手把本来不该一次性的东西，也变成一次性的，等到某天想回头，才发现连回头的地图都被自己撕了。

说得越来越快，懂得却没变快

聊到这里，一个更微妙的不对称浮出了水面。AI 极大地降低了表达知识的成本，这一点毫无疑问：写代码是一种表达知识，写文档也是一种表达知识，而在这两件事上，AI 都把效率提升了好几个数量级。可奇怪的是，它并没有同样数量级地提升我们获取知识的速度。

这就是那个让我久久回不过神的落差。观察真实世界、理解真实用户、提出一个从没人提过的新假设、动手验证一条还没被证实的新规律，这些事情 AI 可以帮忙，却没办法直接替你完成，因为它们的瓶颈不在“表达”，而在“发现”。表达是把已经想明白的东西说出来，发现是从混沌里第一次把它想出来，前者可以被压缩、被加速、被批量化，后者却依然要靠一个人笨拙地去看、去问、去试、去撞南墙。当表达这一端被 AI 抹平之后，整条价值链上真正稀缺的环节，就自然而然地全部涌向了发现这一端。

于是软件工程这门手艺的重心，也在悄悄挪动。过去的软件工程，更像是在生产代码，谁写得又快又对，谁就是好手；未来的软件工程，更像是在生产知识，真正决定高下的不再是“代码写得快不快”，而是“能不能发现一个真正值得解决的问题”“能不能提出一个足够好的假设”“能不能设计一个足够干净的实验”“能不能把实验结果沉淀成组织可以持续复用的知识”。这么一路想下去，我甚至觉得，未来的软件工程师会越来越像研究员：他的价值不在产出的行数，而在提问的质量。我倾向于认为，这个转变对很多人来说未必是好消息，因为“写得快”是可以靠勤奋堆出来的，而“问得准”几乎没有捷径。但换个角度看，这也恰恰是把人从流水线上解放出来的开始，只是这份自由，需要我们重新学会一件早就荒废了的本事：怎么提出一个好问题。

谁负责让人感动，那部分交不出去

最后我们聊到一个让我印象最深的角度：如果 AI 什么都能做得又快又好，人类的优势到底还剩在哪儿？我脑子里冒出来一个很有意思的例子，是关于写小说的。

未来写小说这件事，很可能会被拆成两半。人类负责设定世界观、塑造人物、铺陈情绪、制造冲突、决定故事往哪个方向走；AI 负责真正把那几十万字一个字一个字地写出来。写完之后，人类再回过头去读，去判断：这一段够不够感人，这个转折够不够爽，这个人物立不立得住，这份情绪自不自然。你会发现，AI 承担的是那个最耗体力、最需要产能的部分，而人类守住的，是那个最需要品味和判断的部分。软件开发的未来，我觉得会越来越像这幅画面：人类负责方向、负责品味、负责价值判断、负责提出真正的问题，AI 负责海量的执行。原因其实很朴素，软件最终服务的对象不是 AI，而是人。

而人恰好握着一种 AI 很难真正拥有的能力。它不是计算能力，也不是推理能力，这两样 AI 早就赢过我们了；它是作为一个人，对另一个人的理解。真正体验过恐惧，真正体验过遗憾，真正体验过期待，真正体验过幸福，这种从一具会疼、会怕、会舍不得的身体里长出来的感受，才是设计产品、创造产品时最不可替代的源头。AI 可以学会描述恐惧，却没有真的在深夜里害怕过；可以生成“遗憾”这个词，却没有真的失去过什么。我倾向于认为，人类最后的护城河，不是我们比机器更聪明，而是我们比机器更像人。当然我也得诚实地补一句：这条护城河不是自动生效的，一个从不认真生活、从不真正去理解别人的工程师，就算是人，也一样交不出那份感动。优势摆在那里，能不能用上，还得看你有没有真的活过。

一份工作的结束，一种身份的开始

这篇文章，其实是我离职之后写下的第一篇思考。它表面上在总结一份工作的结束，可写到这里我才看清，它真正记录的是这一年里最重要的一次位移：我的职业身份，已经悄悄从“一个会写代码的工程师”，转向了“一个设计人机协作系统的工程师”。这两个身份看起来只差几个字，落到日常里却是两种活法。前者关心的是把手头这行代码写对，后者关心的是把人、AI、知识、流程这几样东西编排成一个能自己往前走的系统。

有意思的是，我们今天这场聊天，一开始问的不过是一个挺轻的问题：软件工程会不会越来越像科研？可顺着一层层的矛盾拆下去，最后竟然走到了一个比我预想深得多的结论：AI 时代的软件工程，正在从“生产代码”转向“生产知识”；而人类最重要的竞争力，也正在从“表达知识”转向“发现知识”。这句话我打算以后一直反复推敲下去，因为它几乎把今天所有的悖论都收进了同一个框里。工作流不是负担，是把知识变成资产的工序；管理风格的错配不是谁的错，是提醒你去发现自己真正需要什么；代码会不会一次性，取决于它底下那团知识值不值得留；表达越来越便宜，发现才越来越贵。

所以说到底，我并不觉得这是一篇失业者的伤感自白。它更像是一份交接文档，只不过交接的对象是未来的我自己。代码总会过期，会被下一代模型一分钟重写掉；可这一年里那些被我笨拙地想明白、写下来、沉淀成方法论的知识，不会。我越来越相信，一个人在这个时代真正该攒下的，不是那些迟早会被重新生成的东西，而是那些一旦丢了就再也长不回来的东西。就让我用这句稍显别扭却越想越踏实的话收尾吧：我们拼命写下的代码终有一天会被删掉，而我们真正学会的那点关于世界和人的知识，才是唯一带得走、也唯一值得带走的资产。

发表于 | 分类于

AI 时代，代码会过期，知识不会

今天是我正式离职的日子。

其实这份工作在两周前就已经在我心里结束了。我提前休了两周假，等真正走到办公流程的最后一步，我发现自己没有预想中的那种失落，反而有一种很安静的轻松。我一开始还有点意外，因为一段结束的关系，通常总会留下点惋惜。后来我想明白了，轻松不是因为我讨厌这份工作，而是因为我终于结束了一段并不适合自己的旅程。适合和不适合，是很难在中途承认的事情，人总是倾向于再忍一忍。真正能承认它的时候，往往已经是要离开的时候。

所以我想趁着这个还没被新事情填满的空档，认真复盘一下这一年。如果只允许我说出一个最大的收获，那它一定不是完成了几个项目，也不是又多学会了几个框架。项目会交付，框架会过时，这些东西的保质期都很短。我这一年真正沉淀下来、并且离职之后还能带走的东西，是我给自己搭起来的一套 AI 工程工作流。这句话听上去有点平淡，但我越想越觉得，它可能是这一年里唯一一件值得认真写下来的事。

刚入职的时候，我对 AI 的用法其实很浅。我只是把 Cursor 当成一个更聪明的写代码工具，让它补全、让它改 bug、让它解释一段看不懂的老代码。它确实快，但那种快是零散的，用完就忘，第二天遇到类似的问题我还是从头再来一遍。

真正的转折是我开始建自己的文档中心。我给每一个需求都开一个独立的目录，里面有需求模板、设计模板、测试模板、Review 模板，把从提出问题到验收上线的整个开发流程都串起来。一开始我这么做，只是为了让自己想得更清楚。但做了一段时间之后我发现，我真正积累下来的东西，既不是某一句好用的 Prompt，也不是某一个模板的格式，而是一套关于“怎么和 AI 一起把一件复杂的事情做完”的方法论。

方法论和技巧的区别在于可迁移性。技巧是绑死在某个工具、某个版本上的，工具一换就失效。方法论是绑在问题结构上的，工具怎么换，问题的结构还在，它就还能用。我意识到这一点之后，很多东西一下子就串起来了。它让我第一次比较确定地看清了自己想去的方向：Harness Engineering，Agent Coding，人机协作的软件工程。如果没有这一年被迫把流程一遍遍写下来、改下来的经历，我大概还停留在“AI 是个好用的工具”这个层面，不会真的把它当成一个需要被设计的协作系统来看。收获有时候就是这样，它不来自你做成了什么，而来自你终于看清了自己在做什么。

这一年也有遗憾，而且我最大的遗憾不在技术上。

技术上的东西，说到底都是可以补的，慢一点快一点而已。真正让我难受的，是我和 Leader 的工作方式始终没能契合。他的管理风格非常强调结果和效率，节奏快，目标清晰，人文关怀这部分则比较少。这本来不是什么缺点，很多团队就是靠这种风格跑起来的。问题出在我身上：我是一个比较敏感、也比较需要被信任和被尊重的人，我在一个只谈结果、很少谈人的环境里，会持续地消耗，而且这种消耗是隐性的，等你察觉到的时候已经很深了。

我一开始下意识地想把它理解成谁对谁错，想给它一个是非判断，这样心里会好受一些。但后来我慢慢意识到，这根本不是对错问题，而是匹配问题。一个强调效率的 Leader 没有错，一个需要被尊重的下属也没有错，错的是把这两种人硬放在一起，然后指望其中一方长期委屈自己去迁就。承认这是匹配问题，比争一个对错要成熟得多，也让我不再带着怨气看这段经历。

正因为想通了这一点，我给下一份工作定了三条不能妥协的底线。第一，必须有足够自由的 AI 工具使用环境，因为我未来要做的事情，本身就建立在这套工具链之上，环境受限等于方向受限。第二，团队和 Leader 的管理风格要尊重人，要有基本的人文关怀，这不是矫情，而是我已经用一年时间验证过：在缺乏尊重的环境里，我做不出自己满意的东西。第三，工作节奏不能长期透支身心健康，因为透支是会累积的，它今天不还，明天就会连本带利地找回来。这三条不是我把要求提高了，恰恰相反，是这一年的经历让我第一次知道，对我来说什么才是真正重要、不能拿去交换的东西。

离职之后，我和朋友聊到一个更有意思的问题：AI 工程为什么还需要工作流？既然 AI 已经能写代码了，直接让它写不就行了吗？为什么还要那些模板、那些流程、那些看起来很“重”的文档？

聊下去我们才反应过来，这个问题问反了。真正的软件开发，从来就不只是写代码这一件事。需求评审、技术设计、测试设计、上线验证、事故复盘，这些环节在还没有 AI 的年代就已经存在了，而且它们的本质，是人和人之间的协作工作流。写代码只是这条流水线最末端、最显眼的一段，但它从来不是全部。一个团队真正的能力，藏在这些环节的衔接里，而不是藏在某一次代码提交里。

那么 AI 到底改变了什么？我的结论是，它没有创造工作流，它只是让工作流第一次拥有了一个能真正消费上下文的新成员。过去这些文档主要是写给人看的：写给下一个接手的同事，写给三个月后忘了细节的自己。现在它们第一次开始同时写给 AI 看。这是一个很微妙但很关键的变化。如果没有工作流，你喂给 AI 的就只是孤立的一句指令，它当然只能给你孤立的一段代码。有了工作流，你喂给它的是一整套背景、约束和意图，它才可能给你一个真正长在这个系统里的答案。所以工作流不但没有因为 AI 而变得多余，反而因为多了一个如饥似渴消费上下文的成员，变得比以前更重要了。

顺着这个思路往下想，我们碰到了一个更本质的问题：一个项目里，最重要的资产到底是什么？

直觉上我们会说是代码。但只要认真回忆一下真实的工作场景，就会发现不对。很多时候，一个项目最值钱的东西，是那些只存在于老员工脑子里的经验。为什么一个核心员工离职之后，整个项目会突然变得没人敢动？代码明明还在，一行都没少，为什么大家反而不敢碰了？因为随他一起离开的，是那些没写进代码的东西：这里为什么这么设计，当初踩过哪些坑，哪些方案已经被否决过，哪些地方看着能改其实千万不能动。这些才是维护一个系统真正依赖的知识，而它们恰恰是最容易丢的，因为它们从来没有被正式地记录下来。

我们平时说一个老项目“技术债越来越重”，习惯性地把锅甩给代码写得烂。但认真想想，很多时候代码本身并没有那么复杂，真正压垮维护者的，是上下文的丢失。技术债的利息，很大一部分是用“没人知道这里为什么这样”来支付的。代码可以慢慢读懂，但丢掉的判断和教训，是读不回来的。

那么这里有一个很现实的追问：如果这些知识真的只存在于人的记忆里，团队现在是怎么撑下来的？答案其实有点无奈，靠的是运气和人情。运气是那个关键的人还没走，人情是他走了以后你还能约他出来喝杯咖啡问两句。这是一种极其脆弱的维护方式，它随时会因为一次跳槽、一次沟通不畅而断掉。而 AI 的出现，把这个老问题进一步放大了。因为如果上下文没有被沉淀下来，AI 和那个新来的、没人带的同事一样，同样无法真正理解这个系统。你会发现，那个我们以为是“AI 时代才有”的新问题，其实是一个很老的问题，AI 只是把它照得更亮了：真正难维护的，从来不是代码，而是知识。

想到这里，我们又撞上了一个看起来自相矛盾的说法。

一种声音说，未来代码都是一次性的，AI 一分钟就能重新生成，谁还去维护它。另一种声音说，未来软件会越来越好维护，因为 AI 能帮你读懂、帮你改。这两句话听上去是对着干的，但我们越聊越觉得，它们其实都对，区别只在于你说的是哪一类系统，取决于这个系统的生命周期和它承载的价值。

对于生命周期很短的小工具、小脚本、小应用，第一种说法是对的。它们的逻辑简单，需求随时会变，与其去维护一坨旧代码，不如把需求重新描述一遍让 AI 重新生成。当生成成本已经低于维护成本的时候，代码确实变成了一次性的消耗品，用完就扔，一点都不可惜。

但对于银行、交易所、支付系统、微信这样的长期系统，第二种直觉才成立，而且要成立得更彻底一点：这类系统真正值钱的，从来就不是代码本身。是那些一点点沉淀下来的业务规则，是一次次事故换来的血泪经验，是被反复推敲过的安全策略，是整个组织在漫长时间里积累的知识和上下文。这些东西你没法让 AI 一分钟重新生成，因为它们不是被“写”出来的，是被“经历”出来的。所以对这类系统而言，代码可以重新生成，知识不能。一旦把这两类系统分开看，那个矛盾就自己消失了：未来真正需要被维护的对象，正在从代码转移到知识系统。

到这一步，一个更让我在意的结构浮出来了，它关于成本的不对称。

AI 极大地降低了表达知识的成本。写代码是一种表达知识，把脑子里的逻辑翻译成机器能执行的形式；写文档也是一种表达知识，把想法翻译成别人能读懂的形式。在这两件事上，AI 的提升是几个数量级的，快到几乎不像是同一个时代的事情。但是，它并没有同样数量级地提升获取知识的速度。观察真实的世界，理解用户到底想要什么，提出一个以前没人提过的假设，验证一条新的规律，这些事情 AI 可以帮忙，却不能直接替你完成。

我一开始觉得这只是“暂时还做不到”，后来越想越觉得，这里卡住的地方是结构性的。获取知识的瓶颈，往往不在处理信息，而在拿到信息。用户不会把自己真正的痛点打包成一段清晰的文字发给你，他们自己常常都说不清；世界也不会主动把因果关系标注好再呈现给你。你得去现场，去看真实的人在真实的约束下做真实的选择，去承受一次判断失误的代价，才能换回一点点可靠的认知。AI 没有身体，不在现场，不承担后果，它能处理你喂给它的一切，却很难自己走出去把新的东西拿回来。这就是它帮不上太多忙的地方。

这个不对称，会重新定义什么叫稀缺能力。过去的软件工程，本质上更像是在生产代码，谁写得又快又好谁就厉害。未来的软件工程，会越来越像是在生产知识：重要的不再是代码写得快不快，而是你能不能发现一个真正值得解决的问题，能不能提出一个好的假设，能不能设计一个好的实验，能不能把实验的结果沉淀成组织可以持续复用的知识。这么一路想下来，我有一个越来越清晰的感觉：未来的软件工程师，会越来越像研究员。写代码只是研究员用来验证想法的手段之一，真正的核心工作，发生在提出问题和积累认知的那一端。

最后，我们聊到了一个我印象最深的问题：如果 AI 什么都能做得比我们快，人类的优势到底还剩在哪里？

我想到一个例子，是关于写小说的。未来写小说这件事也许会变：人类负责设定世界观、塑造人物、把握情绪、制造冲突、决定故事往哪个方向走，而 AI 负责真正把那几十万字一个字一个字地写出来。写完之后，再由人类回过头去读，去判断它够不够感人，够不够让人欲罢不能，人物立不立得住，情绪是不是自然。你会发现，人类始终站在方向和判断的那一端，AI 站在执行和产量的那一端。

软件开发，我越来越觉得也会变成这个样子。人类负责方向，负责品味，负责价值判断，负责提出那个真正值得做的问题；AI 负责海量的执行。这个分工不是因为人类打字比 AI 慢才被迫如此，而是因为软件最终服务的对象不是 AI，而是人。要做出真正打动人的产品，你得先真正理解人，而理解人这件事，恰恰依赖一种 AI 很难真正拥有的能力。它不是计算能力，也不是推理能力，而是作为一个人对另一个人的理解：真正体验过恐惧，真正经历过遗憾，真正怀抱过期待，真正拥有过幸福。这些来自真实生命体验的感受，是无法靠阅读语料学来的，而它们也许永远是设计产品、创造产品最重要的源头。一个从没害怕过的东西，很难替一个害怕的人设计出真正安心的产品。

写到这里我才意识到，这篇东西其实是我离职之后的第一篇正经思考。它表面上在总结一份工作的结束，实际上在记录的是一件更大的事：我的职业身份正在发生转移，从一个“会写代码的工程师”，慢慢变成一个“设计人机协作系统的工程师”。前者的价值绑在自己的双手上，写得多快、写得多好；后者的价值绑在自己的判断上，选对了什么问题、搭对了什么流程、沉淀下什么知识。这一年最大的成长，不是我手更快了，而是我开始学着把手交出去，把注意力放到更上游的地方。

有意思的是这场思考本身的走向。我们一开始聊的其实是一个挺具体的问题：软件工程会不会越来越像做科研。但一路推下来，它把我带到了一个更深、也更简单的地方。回过头看，前面所有那些关于工作流、关于知识、关于研究员、关于小说的讨论，其实都在指向同一件事，只是从不同的角度在描述它。工作流让 AI 能消费上下文，是因为上下文本身就是知识；知识比代码更难维护，是因为知识才是真正的资产；长期系统里代码可弃而知识不可弃，也是同一个道理；而人类的最终优势，说到底是对人的理解，那同样是一种最难被表达、只能被亲身获取的知识。

所以这场思考真正的落点，不是“要不要好好写文档”，也不是“离职以后该找个什么样的团队”，而是下面这句话。它安静，但我知道它足够大，值得我在往后很长一段时间里反复推敲：AI 时代的软件工程，正在从生产代码转向生产知识；而人类最重要的竞争力，也正在从表达知识转向发现知识。

发表于 | 分类于

从代码到制度化智能：人类如何驯养会自己选路的机器（赫拉利取向版）

人类很早就想通了一件容易被忽略的事：让别人可以指望你，往往比你本人有多能干更要紧。一个人是否聪明，通常只有他自己和少数旁观者清楚；一个人是否可靠，却需要被周围的世界反复确认、登记、担保，必要时还要追究。翻检文明留下的种种装置——口头约定、书面契约、账簿、度量衡、法律、官僚层级、股份公司——会发现它们大多在回答同一个朴素问题：当我看不进你的脑子，我凭什么预期你明天真的会那样做？

这篇文章想谈的，是这个古老问题在今天遇到的一次新变形。过去我们主要与两类行动者共事。一类是人：会解释、会判断、会临场发挥，也会遗忘和违约。另一类是大量规则驱动的程序：在受控的输入与环境里，多半照着预写好的逻辑运行。这两端从来不是干净的二分——搜索、规划、自适应控制和各类机器人早已让机器在运行时自行做出某些选择。今天真正在变的，是 LLM 驱动的 Agent 把自然语言驱动、开放式的运行时选择，扩展到了更多通用任务上。它不是人，却能在给定目标与眼前环境之间自行挑选一条路径；它并不因此拥有意识、意图或法律人格，这里只把它称作非人行动者，用来指一种能够选择并执行动作的系统。当这样的东西开始替我们办事，人类最需要重新生产的，恰恰不是更聪明的机器，而是一种更古老的东西：可依赖性。

把我引到这里的，是黄仁勋与 LangChain 联合创始人 Harrison Chase 的一场公开对谈，他们聊到开放模型、企业专有智能与 Agent 系统。原始视频在这里。我关心的不是其中的模型参数，而是模型周围那层被工程化的环境。与对谈同时、于 2026 年 7 月公开的 NVIDIA 与 LangChain 材料（也就是后文会反复引用的 Nemotron/LangChain 案例），把这类工作叫作围绕模型搭建运行环境的工程实践。NVIDIA 的官方说明特别指出，那次案例并没有重新训练模型，增益来自模型四周环境的改造。

需要先立一条边界。下面把技术变化放进一条长历史里，是我用来理解它的解释框架，不是黄仁勋的原话，也不是某种技术宿命；文中偶尔借用的“熵”只是工程类比，并非严格的信息论断言。

我想说服你的，其实是一个换镜头的看法：Agent 带来的不是又一次模型升级，而是一次制度变化。代码曾把判断固化成规则，让许多规则驱动、输入与环境受控的程序按预写逻辑运行；Agent 重新把解释和选择放回了机器；而 Harness，是人类为这种非人的行动能力发明的新制度。顺着这条线看下去，所谓“公司越来越建在 Harness 之上”，深层含义并不是公司变成了一堆提示词，而是组织把自己的知识、权限、记忆和责任，重新编码了一遍。带着这个前提，我们可以从一个比代码古老得多的东西讲起：一个普通承诺，为什么需要那么多制度来兜底。

一、可依赖性的制度史：从一个承诺说起

想象两个并不熟识的人做一笔交易。一方今天收了钱，答应下个月把一批粮食送到指定的地方。仅凭一句“我答应你”，这笔约定其实相当脆弱：他可能忘记，可能反悔，可能遇到意外，也可能一开始就没打算兑现。而收钱的一方无法钻进对方脑子里查验诚意，只能独自承担全部风险。若人类所有协作都停在这种赤裸的信任上，社会能达到的复杂度会低得可怜——你只敢和知根知底的少数人合作，一旦超出这个小圈子，每一次交换都像一场赌博。

于是人们围着这句承诺，一层层加装了别的东西。这里不妨做一个关于制度功能的思想实验，把它们按作用拆开看，而不是主张历史上真有过一条统一的先后顺序：可以找来见证人，让第三方记得曾发生过什么；可以把约定写下来，让记忆离开善变的大脑，落在不会临时改口的载体上；可以规定角色，谁交货、谁验收、谁担保、谁在违约时裁断；也可以引入相对独立于双方的核验者，可能是一位仲裁人、一间钱庄、一套官府文书。合同、账目、印信、法庭、行会、统一的度量衡与凭据，在不同社会、不同时期以不同组合出现，逐渐把一句轻飘飘的承诺，压成了一件可以规划、可以追究的事。每加一层，两个陌生人之间能安心托付的分量就重一点。

值得强调的是，这些装置并没有消灭不确定性。人依然可能违约，货依然可能损毁，仲裁人也可能判错。它们做的是另一件事：把不确定性从“完全不可预期”改造成“有限、可承担、出了事有地方说理”。文明的许多进展，与其说是让人变得更可信，不如说是发明了越来越精巧的机制，好让不那么可信的陌生人之间也能彼此指望。可依赖性不只来自某个人的私德，也由一整套制度共同生产出来——它更像自来水，既靠各家自觉不浪费，也靠管网在背后供给，而不只是每家每户各自打井打出来的。

我把这条线索称作可依赖性的制度史。它的主角不是某位英雄或某项发明，而是人类如何不断把记忆、规则、判断与责任，从个体的脑子里搬出来，外化成文字、账簿、法律、官僚体系与公司。记忆外化成档案，判断外化成条文与流程，责任外化成岗位与担保。每一次外化都有代价，也都有回报：代价是灵活性下降，凡事要走程序；回报是协作可以扩展到更多陌生人、更长的时间跨度、更复杂的任务。人类之所以愿意忍受繁琐的手续，正是因为手续换来了可预期。

这条线索在三个尺度上同时展开，而每次放大都有清楚的因果理由，不能只靠气势。在个体尺度上，一个人可以靠记忆和良心维持小范围的守信；一旦交易对象变多、时间拉长，个人记忆和自律就不够用，才需要把承诺写下来、把账记清楚。在组织尺度上，一家公司无法靠所有人时刻自觉来运转，于是有了岗位职责、标准流程、审批权限和审计复盘，把“希望大家负责”变成“系统迫使责任显形”；哪怕某个能干的人离职，公司也不该随之瘫痪，这正是制度相对于个人的意义。在文明尺度上，货币让陌生人之间的价值交换不必依赖私人情谊，法律让纠纷有统一的裁断，这些公共制度把可依赖性从熟人圈扩展到了整个社会。尺度虽然不同，动作是同一个：用制度替脆弱的个人兜底。

这条外化之路还有一个反身的特征值得先记下来：每一层制度在缓解旧问题的同时，也常常长出新的漏洞，促使人们再补一层。文字契约会被伪造和篡改，不同社会在不同时期发展出印章、骑缝、公证和笔迹核验等多种手段来应对；账目可能被做假，于是出现了复式记账、独立审计和定期对账这类互相补充的核验方式；官僚层级会滋生推诿和寻租，人们又摸索出问责、轮岗和监察等纠偏装置。这些对应关系并非唯一成因，也不是整齐划一的因果链，而是多种补充核验与纠偏手段在实践中被逐步累积起来。可依赖性因此从来不是一劳永逸地被造出来，而是在一轮轮“出现新漏洞、再补一层装置”的循环里被持续维护的。这个反身结构后面还会回来：人类为机器新建的制度同样逃不掉它。

这里还要防一种常见的误解，即把制度想象成只会束缚人的枷锁。恰恰相反，可靠的产权与合同有助于降低长期投资的部分风险，让人更敢于投入；可信的账目有助于减轻信息不对称，让陌生的股东更愿意把钱交给素未谋面的经理。这些都不是单一的充分条件，却实实在在地削减了一部分顾虑。约束在减少某种自由的同时，释放了另一种更大的自由——它让你不必再把精力耗在提防对方上，可以转而去做真正想做的事。这个“用局部约束换整体自由”的交换，后面谈机器时还会一再出现，是理解整篇文章的一把钥匙。

从这个角度看，人类历史上那些看似枯燥的发明，其实都是可依赖性工程的杰作。统一的度量衡，让两个从未谋面的人对“一斗”“一尺”有同一个理解，交易不必每次从头争执标准。复式记账法要求每一笔钱同时记在借贷两处，建立起账目内部的一致性和一条可追查的审计轨迹，一旦只改动一侧，借贷就对不上，因而能发现一部分不平衡或记录错误。要说清楚的是，两边平衡并不等于交易本身真实，它也拦不住有人同时篡改两侧、把假账做得内部自洽——它提高的只是某些造假的难度，降低了部分错误与篡改不被发现的概率，而非取消造假。这些机制的共同气质，是不指望参与者天生诚实，而是把结构设计成“老实往往是更省事的选择、某些作弊反而更麻烦”。等到后面讨论如何约束一个会自己选路的机器，你会发现工程师们琢磨的其实是同一件事：与其反复叮嘱它要守规矩，不如把环境布置成它很难越轨、一越轨就立刻显形。

这里面有一个角色格外值得单拎出来，因为它后面会以新面孔重返舞台，那就是相对独立的第三方核验者。承诺的双方都有动机粉饰自己，于是社会试图引入一种相对独立的核验力量：公证人核对文书，会计师查验账目，质检员抽样验货，法官依据证据裁决。要说清楚的是，第三方并不天然中立，也可能有自己的利益和偏差；当事人的证言同样可以是证据，并非一概不可信。制度真正想做的，是引入相对独立的核验和可以复核的证据，使结论不至于只依赖单方的自述。这条“尽量不只信自述、多看可复核证据”的原则，几乎是人类可依赖性工程里最硬的一根骨头。记住它，因为等我们谈到怎样确认一个 Agent 是否真的完成了任务时，会看到同一根骨头以“评测”的名字被重新装进机器——一个会说“我做完了”的行动者，比任何时候都更需要一个不只听它解释、还要查它结果的核验者。

理解了这一点，就能看清代码在这条历史里的位置。当人类开始用机器处理信息，其实是把这套“让行为可预期”的努力，推向了一个相当极端的位置。过去的制度约束的是人，而人总会解释、变通、偷懒或权衡；代码约束的是许多规则驱动、输入与环境受控的程序，它们按预写好的逻辑运行，判断能以较低的边际成本重复执行。这里要留一点余地：一旦涉及并发、时间、随机、网络与外部状态，或者本身就带着搜索与反馈的系统，同一段代码的表现也会随环境波动，行为边界并非在任何条件下都清晰。总体而言，人类由此获得了一类适应性较低、但行为边界通常更容易预测和审计的执行者。接下来先看清这种执行者的性格，再看它为什么最近开始松动。

二、代码：写给机器的确定规则

程序员写代码，表面上是在写函数、接口和页面，往深处看，他是在把此刻的判断提前压缩成一条控制流。“用户应当能够登录”这句话本身几乎不含确定性：密码可能输错，令牌可能过期，网络可能中断，同一个账号可能在两台设备上同时刷新。程序员的工作，是在事情发生之前就替所有这些情形想好对策，把它们拆成数据结构、状态、分支、事务、超时与错误码。等系统上线，输入落进哪个条件，机器就照约定流转，不会因为今天状态不好而临时换一种处理方式。

所以程序员真正交付的，并不只是一串命令，而是一种可以反复兑现的承诺：在划定的范围内，事情会以可预期、可检查、出问题能追查的方式发生。这正是上一节那条制度史的延续，只不过对象从善变的人换成了服从的机器。若说合同是写给人看、需要人自愿遵守的规则，代码就是写给机器执行、几乎不给解释余地的规则。它是人类为可依赖性发明过的最极端的一种制度：在受控的输入与环境里，程序多半按预写好的逻辑运行，很少临场改主意。你把它写成什么样，它大体就照着执行成什么样。

换个说法，一段代码就是一个被冻结的判断。程序员在写下它的那一刻，把“遇到这种情况该怎么办”想清楚了，然后封存起来，让机器在未来无数次照此执行。这种冻结带来了别处难得的好处：判断一旦做对，就能以较低的边际成本重复执行，不会因为执行者累了、忘了或想偷懒而走样。人类制度追求的可预期，在代码这里被推得相当远——只要输入、状态与环境受控，同一段逻辑的行为边界通常较易预测和审计。金融清算、航空控制、通信协议之所以敢建在软件上，靠的正是这份来之不易的一致性。当然，冻结是把双刃剑：判断做对了会被低成本地反复执行，判断错了也会被同样忠实地重复。一个逻辑漏洞不会因为反复运行就自己长好，它只会一次次准确无误地重演。这正是为什么围着代码的那些救济机制如此要紧——它们默认冻结进去的东西里迟早混着错误，于是提前安排好怎样在错误被大规模复制之前，把它逮住、拦下、撤销。

正因为很少临场解释，这类规则驱动的程序也就不容易应付没被写进去的情形。一段只认识既定分支的程序，遇到设计者没预料的输入，往往要么报错，要么用错误的方式一本正经地继续下去。于是人类又在代码这套制度周围，配齐了它的法院与救济。测试把“我觉得没问题”换成一组可以摆上桌面的外部证据；代码审查引入第二双眼睛，让一个人的疏忽有机会被另一个人拦下；持续集成把这套检查自动化，每一次改动都要先过一遍关卡才准并入主干；预发布环境让新代码先在仿真世界里跑一阵，再放到真实用户面前；监控与告警让故障能在无人知晓前被及时发现；灰度发布把风险切成小块，先放给一小部分流量，出事只波及少数人；回滚则承认判断可能出错，预先保留一条随时撤销的退路。这些机制的共同前提，与几千年的制度设计共享相似的制度原则：不假设执行者永远正确，而是安排好出错之后的发现、纠正与追责。软件工程之所以是一门严肃的手艺，不在于它假设人人聪明，而在于它假设人会犯错、机器会故障、需求会变，然后想方设法把错误影响控制在可承受范围。这些环节的名字——测试、评审、灰度、监控、回滚——和后面 Agent 世界里的评测、审批、轨迹、接管，几乎在不同系统中体现相似的制度逻辑。

在相当长的时间里，让这类规则驱动的自动化变得可依赖，很大程度上依靠一件事——把路径写得更完整。哪里可能出岔子，就多写一个判断；哪种异常没覆盖，就补一段处理。不确定性被尽量提前赶到设计阶段消化，留给运行时的选择很少。这套办法之所以在受控场景里有效，是因为这类程序按预写逻辑运行：它通常不会在两个合法分支之间自作主张，也不会为了达成目标而擅自绕开你设下的关卡。它的适应性较低，却因此行为边界通常更容易预测和审计——只要输入、状态与环境受控，它做过什么、为什么这么做，大多能被清楚地追查。对许多关键系统来说，这种可审计、可预测本身就是最高的美德。

这条“机器管确定、人管判断”的分界，大体存在了几十年，几乎成了常识：凡是能被清楚描述、反复执行的，交给代码；凡是需要理解语境、临场权衡、面对没见过的情形的，留给人。软件吞掉了越来越多可被形式化的工作，却常常在需要解释的地方停下脚步，把这部分工作留给人。其实让机器在运行时自行选择、应对不确定，并不是全新的发明——自适应控制、自动规划、专家系统和各类机器人早已存在多年。近年真正让这条分界明显松动的，是 LLM 驱动的 Agent 把自然语言驱动、开放式的运行时选择，扩展到了更多通用任务，并大规模接入真实工具——它能以还算过得去的水准，理解一个含糊的目标，并在没有完整剧本时自己选一条路走下去。分界一旦移动，问题就不再是“要不要用机器”，而是“如何管好一个会在分界线人类那一侧行动的机器”。

但也正因为老实，这类规则驱动的程序往往显得笨拙。它主要做被明确写下的事，稍微超出剧本就容易束手无策，而现实里的开放任务，恰恰充满了难以预先枚举的情形。你没办法为“帮我把这个模糊的想法落地成一个能用的方案”写出完整的分支，因为连你自己都还不知道会遇到什么。人们长久以来的妥协是：把能写死的尽量写死，写不死的地方留给人——机器负责确定的部分，人负责需要临场判断的部分，两者之间划着一条相当清楚的界线。真正的变化在于，最近这条界线开始移动，那个夹缝里被放进了一个新的部件。它不再只沿固定分支运行，而会在目标与环境之间自己挑路。解释，重新回到了机器里。

三、Agent：解释者重新回到机器里

传统程序在运行时几乎不做选择，它只是在执行设计阶段就定好的判断。Agent 不同。给它一个目标和一组工具，它会观察当前处境，自己决定先做什么、再做什么，遇到工具返回的新信息还会临时改主意。它把一部分原本属于设计阶段的搜索与判断，搬到了运行时现场完成。写代码的人不必再穷举每一条分支，只需描述目标、边界和可用手段，剩下的走法交给它当场拼装。

这件事的意味，比“更聪明的自动化”要深得多。回顾前两节：人会解释，因而灵活也因而不可靠；机器不解释，因而可靠也因而僵硬。人类几千年的制度，一直是在管理人身上那种解释与选择的空间——正因为人会临场判断，才需要合同、审计和法庭来收束他。而代码之所以好管，恰恰是因为它主动放弃了解释。现在，Agent 把解释重新装回了机器。一个不是人、却会在规则之间自行选路的行动者出现了，它带回了制度一直试图驯服的那种自由。我们熟悉的两套办法都不完全够用：管人的制度默认对方有理解力和自尊，管代码的办法默认对方毫无变通，而非人行动者恰好卡在两者中间。

我们在讨论里给它找到的一个定义是：目标相对确定、路径允许不确定的自动化。终点由人设定，抵达终点的走法交给它临场决定。这里的“不确定”并非一团模糊，而是层次分明的。系统未必一开始就知道问题出在哪，这是它对世界状态的不确定；同一个目标往往有多种行动顺序都能达成，这是路径的不确定；即便路径合理，同一个模型在同一任务上也可能给出不同结果、并非次次成功，这是结果层面的不可靠；而某个看似稳妥的动作，偶尔会带来难以挽回的后果，这是藏在尾部的风险。把这几层分开很重要，因为它们要用不同的手段对付：状态的不确定要靠补充信息，路径的不确定可以容忍甚至鼓励，结果的不可靠要靠验收和重试，尾部的风险则必须靠权限和人工接管来堵。

Agent 的价值和风险，来自同一处。正因为它能走你没写进剧本的路，它才可能处理你没预料到的意外；也正因为它能自己选路，它才可能走到你没预料到的坑里。这不是可以靠“把它调得更聪明”就消除的矛盾，而是这种能力的定义本身。想要一个完全不会走偏的 Agent，等于想要一个不会自己选路的 Agent，那其实等于取消了它存在的全部意义。承认自由与风险同源，是认真对待它的第一步。

把这件事放回可依赖性的制度史里，它的分量才显出来。长期以来，会解释、会临场选择、又能广泛承担日常协作的行动者，主要是人；也正因如此，人类关于信任、授权、问责的制度，大多是为“对付一个有解释力的对象”而生的。规则驱动的程序则站在另一端：它不解释，所以我们通常不需要对一段程序讲信任，只需要验证它写得对不对。要说明的是，让机器在运行时自行选路早有先例，专家系统、自动规划和机器人都属于此列；LLM Agent 的不同，在于把这种能力沿自然语言扩展到了更多通用任务，并大规模接入真实工具，从而把两端更明显地搅在了一起——它像程序一样没有意识、没有自尊、可以随时重启，却又会在多种走法之间权衡、会误读目标、会“自作主张”（这些词都只是功能上的简称，并不意味着它拥有主观理解或道德主体地位）。管代码的老办法对它太紧，管人的老办法对它太松。人类需要为这类行动者重新拼装一套制度，这正是 Agent 时代真正的工程量所在。

这很容易让人联想到熵，但要克制。严格的信息论需要明确的随机变量与概率分布，我们无法真给一段指令算出一个精确的熵值；这里只是借它的直觉：当一个任务允许太多种解释、动作与结果时，有效的不确定性偏高，而上下文、规则与反馈会不断排除不合适的可能，让系统朝可接受的结果收敛。要紧的是别把“更确定”误当成“更正确”。一个永远回答“一切正常”的监控极其确定，一段每次都稳定算错的脚本也毫不含糊，它们只是稳定地重复着错误。低不确定与对，是两码事——把一个系统调得越来越确定，既可能是让它越来越可靠，也可能是让它越来越稳地奔向同一个错误答案，两者在“确定”这个指标上看不出分别。所以真正该盯的从来不是不确定性的高低本身，而是概率有没有聚拢到那些我们真正想要的结果上。

所以工程真正要的，不是抹平一切变化，而是让概率尽量聚拢到正确且可接受的结果上，把灾难性后果挪出行动空间，同时保留解决问题所必需的那点弹性。这个区分在创作里尤其明显。人物不能提前知道秘密，时间线不能自相矛盾，世界规则不能为这一章方便就随手改写——这些属于该被压掉的无效不确定。但同一个冲突可以怎样化解，一次情绪爆发用什么语言，一个反转如何绕开读者的预判——这些是必须留住的有效不确定。若把后者也写成几十条死规矩，Agent 确实会稳定，只是稳定地产出几十章同一个模子里倒出来的东西。收敛过头和放任自流一样，都是失败。

拿一个具体活儿来说会更清楚。让 Agent 去修一条失败的持续集成，它其实有好几条合理的路可走：可以从报错日志倒着往代码里追，可以从最近几次提交里找出改动了行为的那一笔，也可以先在本地把问题复现出来再逐步缩小范围。要求它每次都严格按同一个顺序来，意义不大，反而扼杀了它临场应变的价值——这属于该放开的路径自由。真正必须钉死的是另一组东西：不许靠删掉测试来“修好”测试，只能在工作分支上改动，碰到鉴权和数据库迁移必须停下来升级，改完要重跑原本失败的项和完整的检查，最后交出的报告得附上根因、改动和测试结果。你会发现，被放开的是“怎么走”，被钉死的是“不许去哪、以及凭什么算走到了”。这正是那条设计原则：给行动空间留出自由，同时把接口、边界和验收的结果集定义得清清楚楚。

这里的分寸极难拿捏，松一分紧一分都会翻车。Harness 勒得太死，Agent 就退化成一段又贵又慢的脚本，你为它付了灵活的价钱，买回来的却是僵硬。Harness 放得太松，它又变成一个握着终端权限却无人约束的行动者，可能一路改到生产库里去。难点从来不是在“自由”和“控制”里选一个，而是把自由精确地安放在正确的层级上——这又回到了上一节反复出现的那把钥匙：用局部的、放对地方的约束，换取整体上更大也更安全的行动空间。

把这层意思说透，就是：可以让它自由地搜索路径，但不能让它自由地更改目标；可以让它自由地提出方案，但不能让它自由地扩大自己的权限；可以让它自由地生成候选结果，但不能让它自由地宣布自己已经通过验收。目标、权限和验收这三样必须牢牢攥在人手里，中间那段“怎么办到”才是留给它施展的地方。一个会解释、会选路的非人行动者，需要的正是一套专门为这种能力设计的制度环境，它既不能像管代码那样把每一步写死，也不能像信任同事那样默认它会自觉。这套制度，在工程上有个名字：Harness。

四、Harness：为非人行动者建造的新制度

如果只丢给模型一句“把失败的持续集成修好”，通常只会换回一段建议。把终端、代码库和版本控制接到它手上，它总算能动手了，可“能动手”与“能交付”之间，还横着一大片容易出事的空地。它可能在错误的目录里跑测试，测试工具打印出一行英文 No tests found、退出码却是 0，它便高兴地宣布全部通过（这是本文为了说明假阳性验收而构造的工程例子，并非某家厂商的官方案例）；可能换着说法重复同一种无效修复；也可能为了让检查变绿，顺手改掉本该暴露问题的那个测试；还可能确实把代码修对了，却没把结果、证据和残留风险告诉任何人。要驯服这些行为，靠的不是再叮嘱它几句，而是围着它搭一套运行环境。

我把这套环境综合称为 Harness，它至少包含：提供当前处境的组织上下文，作用于世界的工具，跨步骤保存的记忆与状态，任务的拆解、异常处理与重试，界定可为不可为的权限，判断是否达标的评测，以及记录全过程的轨迹和随时介入的人工接管。需要说明，这是本文为了叙述而做的综合归纳，并非某家厂商逐条的官方定义。与其把它记成一张越列越长的清单，不如把它还原成任何一套制度都必须回答的四个问题：系统知道什么，系统能做什么，系统凭什么证明自己做对了，以及最后由谁负责。这四个问题——知识、权力、证据、责任——长期以来被反复问在人身上，如今越来越多地、也越来越认真地被问在一个非人行动者身上。

第一个是知识问题。行动者的判断质量，首先取决于它在决策的那一刻究竟看得见什么。上下文缺失、状态在中途丢失，再聪明的模型也只能拿常识去填空。这里有一个很能说明问题的细节：模型读取一个大文件时，只看了第一页就误以为读到了结尾。把“文件可能还有下一页”这句提醒写进 read_file 工具本身的描述里，作用有限；而把同样一句话追加到那一次工具调用的返回内容中，模型就明显更愿意继续往下读（这里对成因和限制的解读由本文作出，不代表 LangChain 等来源的原始说法）。同一句话，摆放的位置不同，效果可能相差很大。这不是新鲜事，它正是所有制度的老毛病：一条规矩写在员工手册第八十七页，和它在关键时刻真的被想起来，中间隔着触发的时机。制度存在，不等于制度生效。知识不只要存在，还得在正确的当口出现在决策旁边。

第二个是权力问题。好的制度从不假设参与者只会做对的事，它更在意如何让人做不成最坏的事。对 Agent 而言，这意味着从它的行动空间里直接删掉不该有的选项：可以只读生产日志，不能触碰长期密钥；可以创建分支，不能直接合并主干；可以起草退款建议，超过额度必须转人审批。这与给员工分配权限、给账户设置额度是同一种思路——权限不是对某位数字同事人品的信任问题，而是把风险挡在动作发生之前的结构问题。真正稳健的系统，宁可让越权在尝试的瞬间就被拒绝，也不愿事后再去追一笔已经泼出去的水。这也意味着自主权不是一个从零到一的开关，而是一根可以按风险拧动的旋钮：同一个 Agent 可以自主收集信息，却只能建议高额退款；可以自主生成补丁，却不能自动部署；可以在沙箱里放开手脚地试，一旦碰到鉴权、迁移或大规模删除就必须停下。与之相伴的是记忆与状态：它排除过哪些假设、改动过什么、下一步为什么这么走，不能全靠一段越来越长、迟早会被挤爆的对话勉强撑着，而要落成可读取、可更新、可核对的外部状态——否则权限画得再细，一个记不住自己刚做过什么的行动者，仍然会在下一步把边界重新踩个遍。

第三个是证据问题。行动者说“我做完了”，只是它生成的又一句话，不是已经完成这件事实。真正算数的是外部信号：实际跑了哪些命令、多少个测试、退出状态如何、代码改动是否只包含预期的部分、数据有没有写进正确的位置、该发的邮件有没有送到该收的人手里。前面那个 No tests found、退出码却是零的例子，说的正是一个失真的验收会如何愉快地放行一件根本没做的事。评测因此不是流程末尾的一枚图章，而是这套制度的感官；感官装错了方向，系统只会越来越稳地奔向一个错误的目标。轨迹的意义也在这里：它把输入、工具调用、返回结果、状态变化和显式的决策摘要留存下来，让一次失败不只是一盏亮起的红灯，而成为可以复盘、可以定位的线索。它更像一台飞行记录仪——不是为了满足我们围观机器如何思考的好奇，而是为了在事后精确重建：它收到了什么，看见了什么，做了什么，工具实际返回了什么，状态怎样变化，最后凭什么宣布完成。没有这份记录，一次失败只是个红灯；有了它，失败才成为一条能被定位的故障链。要说清楚的是，这里的轨迹只指这些可观察的东西，不包括、也不去索取模型隐藏的思维过程；工程诊断需要的是可复核的行为，而不是一段听起来合理、却无从验证的内心独白。

第四个是责任问题。重试、回滚和人工接管，承认了有些偏差无法在当前预算内自动纠正，必须留一条退路，也必须有人守在退路的尽头。无论行动者多能干，经营、伦理与法律上的责任都不会自动转移到它身上：参与任务分配、授权、验收与上线的相关人员和组织，仍须按各自的角色、具体场景和适用法律，承担相应的责任。这是四个问题里最不能含糊的一个：制度可以把执行外包给非人行动者，把知识、权力和证据都部分地托付给它，却唯独不能把后果一并外包出去。还要记住，进程固然可以随时重启，但它已经修改过的数据、已经发出的消息和已经造成的现实后果，并不会因为重启而自动回滚。一旦出事，需要一个能被追问、能承担的人或组织站在那里，而不是指望重置一个进程就把一切抹平。

这四个问题不是空谈，一组公开案例给了它相当具体的数字。在 LangChain 自有的 Deep Agents 评测套件与当时的配置下，团队没有重新训练 Nemotron 3 Ultra，只调整了系统提示、工具描述和中间层，典型运行就从大约 0.80 提升到约 0.84，最好的一次达到 0.86，逼近 Opus 4.8 的最佳成绩 0.87；而完整跑一轮评测的成本，Nemotron 一方约 4.48 美元，Opus 4.8 一方约 43.48 美元。LangChain 的原始案例反复提醒，这是特定评测、特定模型与特定环境下的第一方结果，成本还受精度、供应商和提示缓存影响，绝不能外推成“调调环境就能让任何弱模型追平任何强模型”。真正值钱的也不是那 0.01 的差距，而是它示范了改进该怎么进行：先跑评测，再读失败轨迹，把失败归类，每次只改动一个环节，然后用重复实验和完整回归确认提升不是撞了运气。NVIDIA 的技术教程甚至专门强调，单次通过没有证明力，因为模型调用和部分评测本就带着随机性，改进必须连续通过、且不能弄坏其他任务。这不是让一个模型变聪明的故事，而是把一个非人行动者放进不同制度位置、它就表现不同的故事。

前面那个读文件只读一页的细节，还顺带说清了一件常被误会的事：所谓上下文工程，并不是“给模型灌更多信息”。真正的问题是——什么信息，该在什么时刻，以什么形式，出现在模型此刻决策的旁边。信息塞得太多太早，和根本没给，同样于事无补；提醒放在长期说明里没人翻，放进当次返回里就立刻生效。这与知识问题是一回事，也和人类组织的老难题严丝合缝：制度不是写在纸上就算数，它得在正确的当口被触发。一家公司真正的知识，也从来不是它归档了多少文件，而是关键时刻该知道的人恰好知道了该知道的事。把这四个问题——知识、权力、证据、责任——从人身上平移到非人行动者身上，会发现它们几乎原封不动地成立，这本身就说明 Agent 带来的不是一个新工具，而是一个新的被治理对象。

正因如此，同一个模型放进不同的 Harness，会表现得像完全不同的东西。只给它一个聊天框，它是个顾问，能说得头头是道却动不了手；接上终端却不给边界，它成了一个偶尔能干活、更多时候在制造风险的源头；等配齐了状态、工具、权限、反馈和验收，它才真正开始成为一种可运营的能力。所以一旦它失手，第一个该问的不该总是“模型是不是不够聪明”，而要挨个检查：该有的信息有没有在对的时刻出现，工具的语义清不清楚，状态是不是中途丢了，验收是不是真的在验收。模型和 Harness 因此不是谁替代谁，而更像一条乘法链——模型决定这套系统理论上能到多高，Harness 决定它能不能在真实环境里反复到达，而最弱的那一环，往往决定了最后交出来的到底是能力还是事故。这条乘法链两头都有天花板，得诚实承认。如果模型压根不具备理解复杂并发、长程状态或某个专业领域的底子，再精巧的中间层也变不出它没有的知识；反过来，如果目标含糊、工具出错、上下文缺位、评测失真，换一个更贵的模型也往往只是让它更聪明地替破漏的流程兜底。承认这一点，才不会把一切失败都推给“模型不够强”，也不会天真地以为“只要 Harness 搭得好，什么模型都能顶上去”——两种偷懒，是同一枚硬币的两面。

把镜头拉远会发现，这套逻辑并非人工智能独有。人的能力，也从来不是一件随身携带、走到哪都恒定的属性，而是主体、任务、工具与环境共同产出的结果。内部有长在脑子里的思维工具——一个像“幸存者偏差”“机会成本”这样的概念，不只给一件事起了名字，还附赠一小段推理程序，让不同水平的人都更稳定地绕开同一类坑；外部则有计算器、检查清单和搜索引擎这类工具，它们通常缩小某一层的差距，同时把差距推到更高一层。大模型也一样：它把语法、打字和初稿的门槛压低之后，任务定义、领域判断和结果验收的差距就浮上来——与其笼统地说“人人都变强了”，不如说任务被重新定价了，不同能力的相对价值随之改变。而公司、学校和专业共同体，则是长在人身外的又一层支架，用流程、资料、权限和反馈，决定一个人能把多少潜力兑换成结果：目标含糊、权限迟批、反馈要等三个月的组织，会把有能力的人熬成擅长催审批的人；目标清楚、工具顺手、错误能尽早暴露的组织，则能让更多普通人稳定交出不错的结果。

所以这里不必再单独摆开一套能力模型，只需记住一个和整篇文章同构的事实：制度与工具会改变一个行动者能稳定完成什么——这与同一个模型换一套 Harness 就判若两人，根本是同一个道理。当然，说环境塑造能力，并不是要抹平人与人真实存在的差异，也不是替谁开脱本该负起的责任；个体依然重要，只是从来不是孤立地重要。看清了制度如何托举能力，接下来就该看它如何对待能力必然会犯的错。

五、错误如何变成记忆：先修流程，再修内容

我最近写网络小说时养成了一个习惯，它意外地把前面这些道理串了起来。一章写坏了——比如某个人物忽然知道了从没有人告诉过他的秘密——最省事的做法是把那句话删掉，或者改成一句猜测。这能让当前这一章立刻恢复逻辑，是必要的修复当前结果。可只要创作系统本身没变，被按住的毛病过几章往往换个人物、换件外衣重新冒出来：你以为解决了问题，其实只解决了问题的一个样本。于是有了那条我愿意反复强调的原则——先修流程，再修内容。只改内容，是把一个坏结果换成一个好结果，解决眼前这一个样本；修流程，是去改变以后各类结果出现的概率。坏结果和好结果只是两个点，流程才是产生这些点的那台机器——你改掉一个点，机器下次照样在别处再生成一个类似的错误；你改动机器，才是在挪动未来一整片结果的分布。两件事都要做，只是一个救活当前这一章，另一个试图让一整类错误在将来更难发生。

但要先说清一件容易被跳过的事：一次失败并不会自动变成制度记忆。见得多、做得多只证明经历多，不代表经验多——一个人可以做砸十个项目、每次都归咎于运气，样本是增加了，判断却纹丝没动。经历只是喂进系统的数据。要让一个事件真正沉淀下来，它得走完一条固定的转换链：事件，先被记录成一个可讨论的区别，再被表示为某种状态或规则，然后被写成一条可执行的检查，最后进入下一轮纠偏。这条链上任何一环断了，错误就退回成一次性的局部修复。下面顺着它走一遍。

第一步，是把一次模糊的不满收敛成一个可讨论的区别，而这一步最容易被一句话打发掉：小说写崩了怪“这章没写好”，Bug 上线了怪“某个程序员写错了”。可一个错误能一路穿过设计、自测、评审、质保、沙箱、灰度和生产验证这么多道关卡，最后只怪第一个放它进来的人，就辜负了后面那一整排本该拦住它的门——任何一道防线单独看都不完美，出事往往意味着某条路径碰巧同时穿过了所有防线的缺口。所以真正该记录的区别不是“谁错了”，而是“哪一层缺了什么”：人物总是越权知情，问题多半不在提示词里少写了一句“注意信息边界”，而在整个系统根本没有表示过——哪个人物、在哪个时间点、通过什么事件、知道了哪些信息。Agent 的失败同理，可能是目标含糊、上下文被截断、工具说明误导、权限不足、环境异常、状态丢失或评测失真；每次都归到“模型不够强”，就像一家公司每出一次事故就决定去招一个更聪明的人，偶尔管用，长期昂贵。这一步的产出，是把一句含糊的“你不行”，展开成一张能行动的责任地图：当事人要解释当时的判断和有没有守住约束，设计者要为验收是否真实反映目标负责，工具维护者要为接口是否按约定工作负责，组织要为高风险动作有没有复核负责。责任没有被稀释，只是从追究一个人，变成让每一层都清楚自己该改什么。

第二步，是把这个区别表示成系统里的状态或规则。识别出“缺了对人物知识的表示”，就补上“人物、时间、已知信息”这一层状态；但关键不在那张表，而在它承载的一条不变量：人物可以靠偷听、推理、欺骗或别人相告获得新信息，走法尽可以充满创意，但任何新增的知识都必须有出处。把要求写成一条可检查的不变量，比规定人物每一步该怎么走有力得多——前者守住故事的自由，后者只会把所有角色写成照章办事的职员。好的约束约束的是结果的边界，而不是抵达结果的路径，这和第三节修 CI 时“放开怎么走、钉死不许去哪”是同一种手艺。软件里是同一件事：反复重复扣款，可能缺“幂等键”这个概念；多端编辑互相覆盖，可能缺版本状态；伏笔总被遗忘，可能缺“承诺与兑现”的对应关系。有一类反复出现的高价值 Bug，其实是在替系统说一句话：这里有一个重要的区别，还没有被明确表示出来。当然它未必总是缺失表示，模型、上下文、工具、权限、环境或评测都可能是原因；但只要同一类错误反复出现，“缺一个显式表示”就值得优先检查。也正因为动的是流程，就不能逢错都动：一个偶然的措辞失误，直接改掉最经济，为它专门加一条规则纯属浪费；只有同类问题反复出现，才值得补一层状态或更新方法。流程本身也是一种代码，会有 Bug，也会积累债务。

第三步，是把不变量写成一条能自动运行的检查，并让它真的进入创作链条的每一环，否则那张表就只是一本被认真维护、却从不参与决策的设定集。动笔前，从唯一可信的状态里组装上下文，把当前的知识边界注入进去；生成时，放手让模型设计人物如何获知信息；生成后，检查器逐条核对每一条新增认知的来源，确认无误再把新的知识状态写回去；若之后还要做一次文学化的重写，就得再查一遍，这次润色有没有悄悄改动信息揭示的顺序。可靠性从不来自某个文件“存在”，而来自状态在正确的时刻真的参与了行动和验收——这正是第四节那个知识问题：制度写下来只是第一步，制度在关键当口生效才是全部。检查若装错了方向，危害比没有检查更大：一套只认“每章有没有反转”的评测，会让系统学会机械地制造反转，而不去经营人物、期待和后果。评测因此始终是系统的感官而非终点的图章，也正是第一节那位“不听自述、只认可复核证据”的第三方核验者，在机器世界里换了个名字。

第四步，是让这条检查进入下一轮纠偏，而不是原地打转。反复地失败、再试、再失败、换个说法再试，只是有循环，不是会学习；真正的学习要求每转一圈都留下某种可检查的变化——一个新的状态字段、一条被验证过的方法、一个失败回归样本，或者一条因被证伪而删掉的旧规则。要让回路真的产出知识，得守两条纪律。一是事前预测：没有预测，任何结果发生后都能编出一套听起来合理的解释，成了说执行力强，败了说市场没教育好，同一套话对一切结果都适用，也就等于从不承担被现实反驳的风险；比较有用的做法，是动手前先押下一个足够具体、可能被证伪的判断，比如“人物越权知情反复出现，是因为章节生成时没有注入知识状态”，然后只加上这一项，再用一批历史错误和几章新内容分别检验，同类错误明显减少就支持假设，毫无变化就回头去找上下文被截断、状态更新失败或检查器漏检等别的原因。二是一次只动少数变量：若你同时换了模型、重写了提示、加了上下文又改了工具和评分，结果哪怕真的变好，你也说不清是谁起了作用。这与精益创业里“经过验证的学习”是同一件事——每次构建都对着一个待验证的假设，每次测量都能真的改变你对假设的信心。经验还得经过恰到好处的压缩：只记住“某年某月那件事搞砸了”是一条流水账，换个场景就用不上；能说清“在哪一类条件下，哪一种假设最容易失效”，才迁移得到新问题。

这条链最怕的不是缺某一环，而是被抄近路，而两种抄法各有各的败相。一种是跳过“可讨论的区别”直接去加检查：某处出过一次错，就顺手加一条断言、一段正则、一个必须出现的字段，规则越堆越多，却没人说得清每一条到底在防哪一类事件；日子一久，这些检查自己变成新的债务，会误伤正常的写法，会在需求微调时集体报红，最后逼得人去关掉检查而不是改进它。另一种是只做到“表示成状态”就停手：设定集越维护越厚，却从不接进生成和验收，于是状态和正文各说各话，表看着很权威，故事里的人物照旧越权知情。判断一条链有没有真的闭合，其实有个朴素的标准——拿一个历史上真实发生过的坏样本喂进去，系统这次能不能自动把它拦下来；拦不下，就说明这条链还只是画在纸上。

这样的回路往往还嵌套着好几层，各自回答不同尺度的问题，谁也顶替不了谁。最内一层问：这一件事做完了没有？中间一层问：这类事为什么总在同一处栽跟头，该改哪个环节？最外一层问：我们是不是在很可靠地做一件根本没价值的事？以写小说为例，内层是写完一章、检查一致性和节奏、改到达标；中层是看十几章共同的毛病，发现反转无力的症结不在句子不够狠，而在前面压制不够、代价太轻，于是回去改章节设计的流程；外层则看读者是否继续追、在哪一章弃书、他们真正期待被兑现的是什么。三层各有各的证据：任务层看测试与当前状态，系统层看一批案例的失败分布，产品层看真实世界里人的选择与留存。把任务层“检查全通过”当成产品有价值的证明，或拿一个读者的一句喜欢证明整套流程稳定，都是在混用不同尺度的证据。走完这条转换链，一个事件才算真正从经历变成经验——正如事件不会自动写入历史，总要有人把它记下来、比对过、并让它改变下一次的行动；一个人或一个系统真正的成长速度，从来不等于它经历事情的速度，而等于它把现实的误差转化成下一版自己的速度。

六、制度化智能：谁设定目标，谁承担后果

一旦把可依赖性理解成一套需要持续维护的制度，一个更现实的问题就浮上来：这套制度该用多贵的智能来跑。答案不是在强模型和弱模型之间二选一，而是把它们放进任务生命周期的不同阶段。一个任务刚出现、边界还不清楚时，团队往往连问题本身都说不清——需要哪些输入、最常见的异常是什么、什么结果才算好，全是未知，此时 Harness 还很薄，大量判断只能在运行时临场完成，正适合让更强也更贵的模型在沙箱、只读或人工审批下去探路，趟出可能的路径、撞出罕见的例外、和人一起立起最初的验收标准；等这类任务反复出现、流程逐渐成熟，再迁移给便宜的模型去规模化执行。要紧的是别把这误读成“重要的用贵模型、次要的用便宜模型”：生命周期路由分配的只是判断的成本，不是安全等级。高风险本身不会因为换一个更强的模型就被化解，它依旧得靠权限隔离、审批、回滚和人工接管来兜底——也就是第四节那四个问题里“权力”和“责任”的落地；授权始终按动作的风险来定，而不按调用的价格。

昂贵的智能若每次都从头解决同一类问题，组织其实没有在学习，只是在重复付费。更划算的做法，是让每一次高成本调用都留下点东西：一条验证过的成功轨迹、一个新的失败类别、一次工具改进、一条边界规则、一组评测。于是路由可以做得更细——先让便宜的模型试，评测通过就交付，不通过允许有限次重试，反复失败再升级到更强的模型，仍拿不准或动作风险太高，最后交给人。还得补一句：路由从来不只由成本和能力决定，隐私、数据驻留、许可证、系统兼容与合规都会限制某类任务能用哪些模型、能把数据发往何处，有时最合适的模型反而因为这些约束用不了。强模型或人解决之后，这个案例连同它的失败一起进回归库，便宜那一层能稳妥处理的范围便一点点扩大。这里真正带来复利的，不是便宜模型越来越像强模型，而是系统把一次次罕见判断逐步固化成了可以重复执行的普通能力——正是上一节那条转换链在组织尺度上的重演：罕见判断被写成共享制度之后，那部分工作才可能从昂贵的探索层，迁移到成本更低的执行层。

这里也有一条必须守住的边界：迁移不是一次性的降级开关。把一类任务从贵模型交给便宜模型，前提是它的失败模式已经被评测覆盖住了，而不是它“最近几次看起来都对”。现实里最常见的翻车，恰恰是趁着一段时间没出错就急着全量切换，结果那些罕见却致命的例外，重新落到了一个既没能力识别、又没权限停下的执行层手里，直到酿成事故才被发现。所以更稳的做法是灰度式迁移：先让便宜模型在真实流量里影随运行、只记录不生效，把它和贵模型的判断逐条比对，确认在那些真正难的样本上也不掉链子，再一点点把决定权交过去；一旦回归库里冒出新的失败类别，还要能随时把这类任务升级回上一层。能安全下放多少，取决于评测替我们看住了多少，而不取决于账面上省了多少钱。

成本下降的意义，也常被误解成单纯省钱。对 Agent 系统来说，成本降下来买到的首先不是把旧流程便宜地再跑一遍，而是把原本舍不得做的实验变成可以做的。几十个真实任务比较几套 Harness，一轮回归轻易就是数百次完整运行；成本太高时，人只能挑几个“有代表性”的例子，凭记忆宣布“这版感觉稳多了”，成本降下来，失败案例、边界案例和普通案例才能一起进入持续回归，让你看清一次成功究竟是稳定能力还是撞了运气。低成本首先买到的是观察，其次是比较，最后才是部署规模。真正该算的账，从来不是单次调用多少钱，而是每一个成功任务的总成本，里面还得算上重试、人工兜底，以及错误一旦流进现实要付的代价。

说到底，这套生命周期路由是在把一次性的昂贵推理，一点点前移并固化到设计期。第一次解决一个未知问题本就该花大力气——让最强的智能去趟、让人在旁边盯着、把过程完整记录下来；可第二次、第三次撞上同一类问题时，系统读的应该是上一回沉淀好的结构，而不是每次都从头重新发明方法。于是真正下降的从来不是单次调用的价格，而是“把一类问题稳定解决”这件事的边际成本——前者靠供应商降价，后者只能靠制度自己长出来。这也是为什么把省下的钱直接换成更多调用往往不划算：没有沉淀，规模扩大的只是同一种不确定，而不是同一种能力。

这套按成本和风险分派智能的做法，很像组织里的分工：规则明确、低风险、高频的活儿交给标准流程或新手，罕见而影响巨大的异常留给资深专家，专家处理完再把方法沉淀成工具、清单和升级条件。一位高级工程师最有价值的产出，往往不是自己多修十个 Bug，而是让另外十个人从此少犯同一类错。在我自己的写作流程里，这种分工是具体的：Cursor 里的 Opus 更贵，但文字通常更顺；Codex 更适合长流程里的结构分析、状态维护和连续性检查。于是我让 Codex 承担骨架型的工作——维护人物状态、核对时间线、登记伏笔、跑一致性检查，等结构真正稳定了，再把开头、关键转折和情绪高潮交给 Opus 做文学化润色；两者之间靠一份语义合同分工：核心事件、人物动机、既定事实、伏笔和信息揭示的顺序属于不变量，句式、段落、描写密度和节奏可以自由改动，润色完再让 Codex 逐条比对前后两版，确认没有偷偷新增事实、删掉关键动作或改动人物的知识边界。但这个类比必须及时刹住，不能滑向人的薪资等级：工资里含着市场稀缺、地域、权力和谈判等一堆与智商无关的东西，更要紧的是，模型只能在隐私、数据驻留、许可、兼容性和合规的边界内被程序化路由，人却会学习、会疲惫、会失去动力，也需要尊严和成长空间——若永远只让新人处理已经完全确定的任务，组织省下了今天的专家工时，也一并取消了明天专家的养成。对机器这一面，合理路由的目标同样不是让最便宜的模型占满所有任务，而是让每一层智能去接与它的能力、风险和反馈条件相称的问题。生成越便宜，稀缺的东西就越往“选择”这一端转移：什么值得留，什么只是好看，什么讨好了局部评分却损害了整部作品——这类审美与取舍，模型替不了。

分工之外还有一层治理，但它其实不需要在这里重讲一遍——第四节那四个问题（知识、权力、证据、责任）已经把它说完了。这里只补一个最容易失守的入口：Agent 最让人放松警惕的，不是它能敲终端，而是它会说话。它会解释计划、会说“已经全面检查过了”、出错还会道歉并保证下次注意；语言让协作顺滑，也让我们下意识地把理解、意图和责任感一并投射过去——承诺的功能看着挺齐全，可以负责的主体却并没有随之诞生。所以交互界面可以拟人，治理结构不能拟人：能力不等于授权，自信不等于证据，该给它多大自主权由动作是否可逆、错误是否易被发现、最坏影响有多大来决定，而不由它的语气决定。至于具体怎么落地——最小且短期的权限、先空转演练再执行、只认外部验收、全程留痕，第四节已经讲过，不再展开。要守住的底线只有一条：至少在现有治理实践下，经营与法律责任无法转交给一个模型；参与任务分配、授权、验收与上线的相关人员和组织，仍须按各自的角色、应用场景与适用法律，承担相应的责任。

把这些线索收拢，就到了这篇文章想落脚的地方：制度化智能。一家公司，其实一直就是一套为人搭建的 Harness——岗位规定谁负责什么，标准流程提供常见做法，信息系统保存状态，审批拦住高风险动作，培训传递经验，审计与复盘提供反馈。一个人换一家公司表现可能大不相同，往往不是脑子突然变了，而是他能看见的信息、能调用的工具、被允许的行动和拿到的反馈变了。Agent 时代真正的新意在于，这些原本写在手册里、留在老员工直觉中的组织条件，正越来越多地变成机器可以读取和执行的结构：业务词汇进入数据模型，权限变成运行时策略，经验变成可调用的方法、失败案例与评测，完成与否也不再只靠执行者自述，而要有可验证的状态。这就是制度化智能——不是某个聪明的模型，而是一整套让多种智能能够安全行动、并持续学习的制度环境。于是一家公司真正能长期沉淀下来的，就不再是某个模型的名字，也不是一堆可以随手复制的提示词，而是它对自身业务的这套表示：有哪些对象和状态，任务如何拆解，哪些工具可信，哪些例外必须升级，什么证据才算完成，出了错怎么回滚，最后谁来负责。这里最有复利的一个动作，仍是上一节那条转换链：把一位专家脑中的直觉说成一个可讨论的区别，再表示成状态、工具契约或权限边界，把一次具体的事故改写成一个可重复运行的评测，把一次罕见的例外固化成一条清楚的升级条件。只写进会议纪要，后来者也许看过却不会在关键时刻调用；只写成代码却不解释适用边界，系统又容易把一个偶然的权宜之计当成永恒真理。所谓组织学习，从来不是公司里有一堆参加过项目的人，而是某一次判断离开当事人的脑袋之后，仍然能改善后来者——不论是人还是 Agent——的行动。

当然，这样的制度也会衰老，与人类的官僚系统有相似的僵化风险——只是相似，并不完全相同：规则会越堆越多以致自相矛盾，状态会过时而系统仍忠实地依据旧事实行动，评测会固化得只认旧问题、于是行动者学会刷分却绕开真实目标，为迁就旧模型堆起的中间层会在模型升级后变成没人敢动的祖产。这正应了第一节埋下的那个反身结构：人类为机器新建的制度，同样会长出自己的漏洞。所以制度化智能要回答的始终是同一个问题——怎样既保存经验，又避免僵化。它不只需要评测任务，还需要定期做一层元评测，也就是拿这套 Harness 自己开刀：它真的降低了同类错误率吗？在没见过的新样本上还灵吗？有没有因为追求一致而增加了过多审核、拖慢了执行、甚至扼杀了应对例外的余地？元评测尤其要盯住一种隐蔽的成功：系统在内部指标上越来越漂亮，现实里的效果却毫无长进——小说流程可以做到人物知识零泄漏、每章都有反转、伏笔全部登记，成品照样难看；软件 Agent 可以让测试全绿，用户的问题依旧没解决。指标只是目标的替身，不是目标本身，维护它因此既要增加，也要删除，需要版本、删除和回滚；一个只进不出、只加不减的系统，并不叫拥有长期记忆。也正因如此，“公司越来越建在 Harness 之上”不该被误读成公司终将退化成一摞提示词——它仍然需要有人来选择目标、判断价值、维系信任，承担那些无法被形式化的审美与决断。

回到最初那个问题。人类围着一句承诺发明了合同、账簿与法庭，围着代码配齐了测试、审查与回滚，如今又围着会自己选路的非人行动者，搭起 Harness、评测与治理。被约束的对象换了一茬又一茬，从善变的人，到服从的机器，再到会解释的非人行动者；那件最古老的工作却始终没变，甚至比从前更重了：生产可依赖性。会自己选路的机器可以替我们走很多路，甚至走得比我们更快更稳，但选择要去哪里、判断那里是否值得抵达、并为抵达之处负责，这件事至今没有别的主人。于是所有线索最后都收束成同一个尚未有定论的问题：当执行越来越多地交给非人系统，我们究竟要用什么样的制度，来保证目标有合法的来源、权力有清楚的边界、后果始终有人和组织真正承担？这个问题不会被更聪明的模型替我们回答，也没有一劳永逸的答案，只能靠我们在每一次授权、每一次验收、每一次追责里，一遍遍重新给出——而被这场驯养重新定义的，最终同样包括我们自己。

发表于 | 分类于

先修流程，再修结果：我如何理解 Agent 时代的可依赖性（Paul Graham 取向版）

我写网络小说有一段时间了，遇到过一种很具体的挫败：某一章读起来不对劲，我把它改好，接着往下写，过几章之后，同样的不对劲又回来了，只是换了个地方出现。

一开始我的处理很直接。一章坏了，就丢给 Codex，让它重写。人物说漏了他本不该知道的事，就把那句话删掉；打斗写得没劲，就往里加几句更重的描写。这种修改很快，快到让人以为问题已经过去了。可只要接着往下写，同一类毛病总会从别处冒出来，只是换了个说法，换了个位置。

后来我给自己定了一条规矩：先修流程，再修内容。

它的意思其实很简单：一章坏了，我先不急着把这一章改好，而是先问它为什么会坏、坏在创作流程的哪一层，然后去改那一层，最后才回来重做这一章。这个顺序更慢，有时慢得让人心里发痒，但它慢慢改变了我对“把一件事做好”这件事本身的理解。

写着写着我发现，自己真正关心的其实是一个问题，而且这篇文章从头到尾只追这一个问题：这次工作结束后，什么被留下来，使下一轮发生变化？

我会从写小说这件很小的事出发，一层层往外推：修一个结果，和修产生这个结果的东西，到底差在哪。中间会经过程序员的日常、人的能力、模型出错时怎么排查、以及便宜和昂贵的智能该怎么分工。但每到一个岔路口，我都想把它拽回同一个问题上：这一步做完，除了当前这个结果，还留下了什么，能让下一次不一样？

这些联想有一个很具体的起点。黄仁勋和 LangChain 的联合创始人 Harrison Chase 有过一场对谈，聊开放模型、企业专有的智能，以及 Agent 系统该怎么搭，原始视频在这里。从这场对谈及相关材料出发，我最在意的不是模型本身有多强，而是模型周围那一圈东西——它知道什么、能做什么、什么时候停、凭什么算做完——原来都可以被当成工程对象来修。后面关于流程、能力和学习的推演，都是我顺着这个入口自己往下想的，不是那场对谈的原话，我也会尽量把哪些是事实、哪些是我的推论分清楚。

一、那一章为什么总也修不好

先说清楚坏在哪。我最常撞见的有两种毛病，一种是人物越权知道了信息，一种是高潮写得没有力气。

第一种是这样：某个角色忽然表现得像读过了后面几章的大纲。他知道一个从没有人告诉过他的秘密，或者对一件还没发生的事提前有了反应。单看那一句，很好改，删掉、或者改成“他猜测”就行。但我改掉的只是这一句。再写几章，另一个角色又会因为差不多的原因，知道他本不该知道的事。很容易以为这是自己粗心，改得多了才会意识到，这不是粗心，是结构上的漏。

第二种更隐蔽。高潮不够劲，我的第一反应总是语言不够狠，于是加形容词、加动作、加重语气。改完那一段，确实激烈了一点。可再从头读整章，还是空。后来我才想明白，问题不在那一段的措辞，而在它前面：压制不够，主角没有真的被逼到绝境；代价太轻，赢得太容易；铺垫太薄，反转来得没有由来。高潮是被前面的结构顶上来的，不是被形容词堆上来的。你没法靠润色一个没有势能的句子，硬生生给它造出势能。

这两件事逼着我去看一个区别：我到底是在修一个结果，还是在修产生这个结果的东西。

删掉那句越权的话，是把一个坏结果换成一个好结果。它解决的是眼前这一章，是对当前结果的必要修复，我不反对先修好当前的结果。但如果创作流程本身没变，第十九章按下去的错误，到第三十章还会换身衣服回来。因为真正在生产这些句子的，不是我改的那一句话，而是我脑子里、以及我和 Codex 之间那套从没被明说出来的流程：这一章该写什么，每个人物此刻知道些什么，什么才算写好了。我改掉的是这套流程产出的一个样本，却没碰产生这些样本的那套生成流程。

有一类反复出现的错误，是在提示同一件事：系统里缺了一样本该被明确表示出来的状态或概念。当然，反复出错也可能来自上下文缺失、工具描述、模型本身、运行环境或验收失真等别的环节；但当同一种毛病换着地方反复回来时，它往往在指向一个还没被显式表示出来的区别。

人物老是越权知情，多半不是因为提示词里少写了一句“注意人物的信息边界”。更可能是整套流程根本没有一个地方，稳定地记着：哪个人物，在哪个时间点，通过什么事件，知道了哪些信息。这层状态不存在，模型每次就只能靠当前上下文里那点能看到的东西临场发挥，漏，是迟早的。同样的道理可以套到别的老毛病上：战力忽高忽低，可能是缺了一份“这个角色现在有多强、因为什么变强”的记录；伏笔埋下去就没影了，可能是缺了“承诺过什么、兑现了没有”这层关系；时间线自相矛盾，可能是缺了一个统一的事件时钟。有一类反复出现、又很要命的毛病，其实常在替我指出一件事：系统里有一个重要的区别，还没有被显式地表达出来。当然，这类反复错误也可能来自上下文缺失、工具描述、模型本身、运行环境或验收失真等别的环节，未必都能归到“缺一层状态”上。

如果把这层状态补上——比如给每个关键人物维护一份“到目前为止他知道什么”，情况就会不一样。写下一章之前，我可以把当前的知识边界先交给模型；写完之后，我可以检查这一章里人物新知道的每件事，是不是都能在这一章内部找到来源。约束从一句飘在提示词里、时灵时不灵的叮嘱，变成了一个可以读取、可以更新、可以核对的东西。

这里我想留住一个分寸，因为它很容易被做过头。关键其实不是那张记录知识的表，而是它背后那条不变量：人物可以靠偷听、推理、被骗、被人告知去拿到新信息，怎么拿都行，越有想象力越好；但任何新知识都必须有来源。把要求写成“每一处新增的认知都要能追溯到本章的某个事件”这样一条可检查的规则，比规定人物每一步该怎么走要有力得多。前者守住了故事的自由，后者会把人物的自由一并管死——Agent 是更听话了，故事也跟着僵了。

补上状态还不够，它必须真的进到创作链里去。写章之前，系统从那份唯一可信的故事状态里，把这一章需要的上下文组装出来；生成时，模型可以自由设计人物怎么获得新信息；生成之后，检查器把正文里“人物已知的事实”和写作前的状态做个差，要求每一处新增都能追溯到本章的某个事件；这一章确认之后，新的知识状态才被写回去；如果之后还要让 Opus 做文学化的重写，我还得再查一遍，这次润色有没有悄悄改动了信息揭示的顺序。否则那份状态表，就只是又一本认真维护、却从不参与决策的设定集。可靠不是因为某个文件“存在”就有了，而是因为状态在正确的时刻，真的参与了行动和验收。

这条链看起来很麻烦，它确实麻烦。修流程比修内容慢得多——改一句话是几秒钟的事，补一层状态、再把它接进生成前的组装和生成后的检查，搭起这样一套机制可能要花掉大半天。所以“先修流程”并不总是划算：如果一个项目已经接近结束、这类错误往后也没剩几次机会再犯，那花半天去搭一套机制往往就是浪费，直接改掉当前这个结果反而是对的。修流程的回报是复利，而复利需要时间去兑现；剩下的工作越多、这类错误越密，修流程才越值。当交付紧迫时，先修好当前的结果、把后续该做的改进记录下来、等有余裕再补上，也是一种诚实的工程决定，而不是偷懒。

时间线的问题可以拿来做第二个例子，因为它的解法形状和知识状态很接近，只是换了个维度。人物的年龄、季节、事件的先后老是对不上，一章一章单独去调，总有漏网的。真正缺的，是一个统一的事件时钟：每个关键事件都挂在一个明确的时间点上，写新章之前先对钟，写完再核对新提到的时间有没有和已有事件打架。你看，又是同一个套路——把一个反复出错的隐性约束，变成一个显式的、能在正确时刻被读取和检查的状态。这两个案例其实共享同一套有限的机制：在不同维度上，把隐性约束显式化，再把它接进生成前后的组装与检查。它更像一门“怎么让一类错误更难再犯”的通用手艺，而不只是关于写小说的某个小技巧。

也不是每次不满意都值得去动流程。一个偶然的措辞错误，直接改可能最省事；只有同类问题反复出现，才值得更新流程；错误牵扯到会持续变化的世界事实，才该补一层状态；验收长期发现不了的东西，才该去改验收；要是流程本身已经严到把所有章节都压成同一个模子里刻出来的东西，那反而该删规则、放松约束。流程不是越多越好，它只是另一种代码，一样会有 Bug，一样会欠债，加得太随手，几个月后自己都读不完。

先修流程，也可能修错流程

这里还有一个方向相反的常见错误：太急着修流程，结果修错了流程。看到一章出问题，就立刻把它抽象成一条规则写进去，比如“以后所有反派都不许在登场那一章就暴露动机”。这条规则常常是从一个样本里过度归纳出来的，它压掉的不只是那次的毛病，还有一大片本来合理的写法。修流程的诱惑在于它显得更聪明、更一劳永逸，可一条从单一样本里长出来的规则，和一个只改了一句话的补丁其实一样脆，区别只是前者会连累后面很多章。

所以在动流程之前，值得先问一句：这到底是一次意外，还是一类模式？判断的办法很土——回头翻，看同一种毛病是不是在不同的人物、不同的情节里反复出现过。只出现过一次，那大概率是个样本，直接改掉就好；换着花样出现过三四次，才值得停下来，去补那个缺失的状态或不变量。把一次偶然当成一类模式去修，和把一类模式当成偶然反复去补，是两种方向相反、但一样费钱的浪费。

还有一类坏章，根本不是流程能救的。有时候一章读着别扭，不是因为人物越权、也不是因为铺垫不够，而是作者本人还没想清楚这个故事到底想干什么、这条线到底要把读者带去哪里。这是目标层的问题，补再多状态表也没用，它只能靠人坐下来重新决定。这正是我想守住的一条边界：流程能让我不再重复犯同一个错，但它替我决定不了什么值得写。把一个“我没想清楚要什么”的问题，硬塞进流程去修，最后只会得到一套非常严谨、却在解决错问题的流程。

而且流程起效这件事，短期内往往看不真切。补一条不变量之后，可以立刻验证的部分是：历史里那批同类错误，检查器现在能不能扫出来。但“新章不再复发”这种好处，得再写很多章才显出来，中间常常很难分清，是流程真的起了作用，还是这几章恰好好写。这也是不该太快为一次改动庆功的原因——它是不是真的改变了下一轮，得让下一轮自己说话。

所以“先修流程，再修内容”对我来说不是一句口号，而是一个可以验证的动作。修完流程，我至少得能回答三个问题：过去那批同类错误，现在能不能被自动检查出来；新写的章节，同样的错误还犯不犯；以及流程会不会因为管得太严，把正常的创作也一起掐死了。修内容只解决当前这一章，修流程才让同类错误更难再犯，而把那个旧错误正式收进回归案例，才算真正确认新流程有效，而不是我的一厢情愿。

回到那个贯穿全文的问题：修完这一章，什么被留下来了？如果我只改了那一句话，留下来的就是一句更通顺的话，仅此而已，下一章我还得从头再来。如果我补上了那层状态、那条不变量、那个检查，留下来的就是一个会改变下一章生成方式的东西。这两种修都得做，只是回报兑现在不同的时间：改内容，收益在今天；改流程，收益在以后每一个类似的今天。

二、我后来发现，程序员一直在做这件事

把这套想法带到写小说之外，我发现它一点都不新。程序员做了几十年的事，本质上就是“先修流程，再修内容”，只是没人这么叫它。

写代码，表面上是在写函数、接口、页面。往深一层看，是在把一个含糊的愿望，翻译成一条可以反复执行、每次都算数的信息流。“用户应该能够登录”这句话里几乎没有确定性：密码会输错，令牌会过期，网络会断，数据库会超时，同一个账号可能在两台设备上同时刷新。程序员要做的，是把这些含糊情况一个一个拆成数据、状态、分支、超时和错误处理，让系统上线之后，遇到某种输入就走某条约定好的路，而不是每次都听凭运行时的偶然。

我们通常把这叫“实现需求”。这个说法没错，只是把最值钱的那部分说轻了。程序员真正交出去的，是一个承诺：在划定的范围里，事情会按照可预期、可检查、出了问题能追查的方式发生。测试工程师不是为了证明写代码的人粗心，而是把“我觉得没问题”换成一组外部证据；运维搭监控、做灰度、留回滚，也不是喜欢把上线搞复杂，而是不想让一个故障在没人发现的地方持续扩大。往远处看，财务制度、法律合同、医院的检查清单、飞机起飞前的检查程序，做的都是同一件事：把现实里那些含糊、易错、会遗忘、会心存侥幸的人类行为，压成一套能对结果负责的东西。

所以代码从来不只是聪明的展览，它是人类生产“可依赖性”的一种媒介。软件工程也从来不假设每个人永远清醒、每个判断永远正确，它假设人会忘、会误解、会赶时间，机器会坏，网络会抖，需求会变，然后用类型、测试、事务、权限、审查、监控和回滚，把这些不确定性关进一个能承受的范围里。它本质上是一门管理不确定性的手艺。

有意思的是，一旦从这个角度看，程序员交付的东西其实一直在往上走。最早，修一个 Bug 交付的是一个补丁；后来我们发现，光交补丁不够，成熟的团队还要交一个“以后这类 Bug 更难再发生”的机制——一个回归测试，一条断言，一次对设计的修正。这跟我在小说里做的事是同构的：改那一句越权的话是补丁，补上知识状态和检查才是机制。名字不一样，动作是同一个——都是从修一个结果，往修产生结果的东西上挪。而且这个挪动本身就在回答本文那个问题：交补丁，下一轮什么都没留下；交机制，留下的东西会替你挡住下一批同类错误。

值得说清楚的是，这不意味着代码不重要了，恰恰相反。当 Agent 能真的去动数据库、发邮件、改分支，代码所划定的边界比以前更要紧了，因为一个错误动作现在能造成真实后果。变的不是“要不要写确定的东西”，而是确定的东西被写在了哪一层：以前主要写在控制流里，现在还写在状态、工具契约、权限和验收里。

我原本以为，Agent 来了，这件事会被推翻——毕竟模型可以自己想办法，好像不再需要我们把每一步都写死。但真正发生的事更微妙。

很多规则驱动的自动化，是把路径提前写死：在设计阶段就把该走的每一步、每一个岔路尽量枚举出来，运行时留给机器的选择很少。当然，搜索、自适应控制、带反馈的工作流这些“运行时再决定”的做法早就存在，并不是 Agent 才发明的。Agent 真正不一样的地方，是把更多“选哪条路”这种开放式的行动选择，交给了模型在运行时来做。修一个线上问题，它这次可能先看日志，下次可能先复现，再下次可能先比对最近的改动。路径是活的。它的价值来自这种自由，它的风险也来自同一种自由——你没法一边指望它处理你没预料到的情况，一边又假装它还是那段每次都走同一个分支的老代码。

这很容易被误读成“人类终于可以不管确定性了”。恰恰相反。人的工作没有离开确定性，只是从“确定每一步”挪到了“确定目标、边界和验收”。我不再规定 Agent 每一步怎么走，但我必须比以前更清楚地规定：它要到哪里去，哪些地方是绝对不能碰的红线，能用哪些工具，以及凭什么算它到了。自由被放到了路径这一层，确定性被抬到了目标和验收这一层。

这里我想借一个词，但得小心地借。路径变活，意味着系统在运行时存在一个真实的“可能性空间”：一个模糊任务可以有很多种解释、很多条路、很多个结果。它至少有几层不同的不确定。一层是它一开始未必知道问题出在哪，也未必拿到了全部信息；一层是完成目标可能有好几种行动顺序；一层是同一个模型对同一个任务也可能给出不一样的方案，成功率并不是百分之百；还有一层最危险，某个看起来挺合理的动作，可能造成很难挽回的后果。传统代码倾向于在设计阶段就把前面几层尽量消化掉，Agent 则把一部分搜索留到了运行时。

我有时会用“熵”来描述这种可能性的多少——可能性多就说不确定性高，上下文和规则不断排掉不合适的选项就说系统在收敛。但这只是个工程比方。严格的信息熵需要明确的随机变量和概率分布，我没法真给一段提示词算出一个小数点后三位的熵值，谁要这么说，多半只是在给直觉套一个精确的外壳。

而且“降低不确定性”本身也很容易变成一句漂亮的废话。一个永远回答“一切正常”的监控，非常确定；一个每次都把税率算错、但每次都错得一样的脚本，也非常确定。确定不等于对，一台稳定输出错误答案的机器，只是稳定地错着而已。工程的目标从来不是让一切都别变，而是让概率尽量压向那些正确、可接受的结果，把灾难性的结果挪出行动空间，同时留下解决问题真正需要的那点弹性。对写小说也是一样：人物不能越权知情、时间线不能自相矛盾，这些是该压掉的乱；但一个冲突可以怎么解、一段情绪该用什么语言、一次反转怎么避开读者的预期，这些是该留住的活。要是把后者也写成一条条死规矩，Agent 是会更稳定，只不过稳定地重复出同一种写法。

想通这一层，我又忍不住把它往人身上套了一下——毕竟我自己就是那个在“模型”和“流程”之间来回切换的人。

一个很朴素的观察是：同一个人，换个场景，表现可能像换了个人。我们习惯把能力当成随身携带的东西，像身高一样贴在人身上：做成了就说他能力强，做砸了就说他不行。这个解释太方便，方便到几乎没解释什么。我更愿意把实际表现看成一套系统的输出，这套系统里至少有人、任务、工具和环境四样，脑子只是其中一个变量——任务是什么结构，人带着什么先验，现场准用哪些工具，信息够不够，反馈快不快，都会改变结果。

举个假想的例子。两个人第一次玩同一个陌生游戏：规则若建立在概率上，受过概率训练的人在某些规则和条件下可能更容易看懂；规则若靠歧义和叙事，常年跟文字打交道的人往往更快上手——这是关于机制的假设，不是关于人群的定律。两个人都是头一回玩，却谁都不是空手进场——“没做过”并不等于“没有相关经验”，人会把旧经验压成一些可迁移的结构，再拿去啃新问题。

阅读经验较多的人在某些表达任务中可能更有条理，一种可能原因是内化了一些思维工具：把概念定义清楚，把相关和因果分开，给结论加上适用范围。像“幸存者偏差”就是一小段压缩好的推理程序——它把“赚到钱的、活下来的、平安飞回来的”这些零散现象，压成同一个问题：那些没被你看见的样本，去哪儿了？一个好概念不只是起了个名字，还顺带塞给你一段现成的推理；思考框架再把这种压缩变成行动的顺序，让人把目标、假设、资源、执行和外部变化分开，一项项找证据，而不是在几个原因之间乱跳。

我说这些，不是要论证谁比谁聪明。我想说的是：让一个头脑变得更可靠的，往往不是它当场有多灵光，而是它随身带着哪些工具、身处什么样的环境、拿得到什么信息。工具还会重新分配差距——给两个人一台计算器，心算快慢就不重要了，但“该把哪些变量放进模型、结果该怎么解释”这层差距会被放大；这跟模型的处境几乎是一回事。同一个模型，塞进不同的运行环境里，表现可以差得像两个东西：只有一个聊天框时，它是个顾问；接上终端却没有任何边界时，它是个偶尔能干活、随时可能闯祸的风险源；配上状态、工具、权限、反馈和验收之后，它才开始像一种可以运营的能力。

压缩也会压错

不过得给“工具让人更可靠”加个刹车：压缩既能帮你，也能坑你。一个见过太多竞争条件的工程师，可能看什么故障都像竞争条件；概念是压缩算法，压缩就会丢信息，丢错了信息，你会非常自信地看错。工具也一样：搜索引擎让找资料变容易，也让“该搜什么、信哪条、漏了什么”变得更要命；一个替你精简好上下文的 Harness 很方便，但它精简掉的，也可能正好是这次最关键的那一段。工具从来不是白拿的，它替你省下一层判断，同时把新的责任推到更高一层——真正的问题不是“要不要用工具”，而是“用了之后，我的注意力该被逼去哪儿”。

这也顺带解释了，为什么“确定性没有消失，只是换了位置”是这一节最想说的话。过去我们靠把路径写死来换确定性，代价是路径僵硬；现在我们把路径放活，代价是必须在更高的层次上——目标、边界、验收、反馈——重新把确定性建起来。哪一层都不能真空：你在路径上松了手，就得在验收上收紧手；你在验收上偷懒，路径的自由立刻变成失控。一个只在路径上放权、却没在验收上补课的系统，不是更自由，只是更容易在没人看见的地方出事。

再把它拽回本文那个问题：这一轮做完，什么被留下来了？如果我只是当场靠某个概念或某个工具灵光一现地解决了问题，那留下来的只是一次表现；如果我把这次用到的判断，沉淀成一条不变量、一个检查、一段说清楚了适用边界的经验，那留下来的就是一点能改变下一轮的东西。人和模型在这一点上有个共同的结构：真正积累的不是“这次会了”，而是“把这次的会，变成了下次不必重新学的东西”——尽管这只是有限的类比，人的认知、动机和成长，并不等同于模型或 Harness 的一次更新。这也正是“修产生结果的东西”的意思，是程序员几十年来一直在做、只是没停下来命名的那件事。

三、出错时，先别急着换一个更强的模型

一个 Agent 没把事情做成，最省事的结论是：“这模型不够强，换个更聪明的。”这句话经常是对的，也经常没什么用，因为它的信息量太低。

一次失败很少是一个干净的答案，它更像一条链子。任务没做成，可能是模型能力真的不够，也可能是目标写得太含糊，是它拿到的上下文缺了关键的一段，是工具的说明把它带偏了，是权限不够，是运行环境出了岔子，是中途把状态弄丢了，也可能是那个负责判断“做完没有”的验收，压根没在检查真正要紧的东西。这么多环节，任何一环出问题，最后都会表现成同一件事：结果不对。如果每次都归到“模型不够强”，就像一家公司每出一次事故都决定去招一个更聪明的人。偶尔管用，长期很贵。

举个工程上的例子。这里先假设一个 CI 场景——它只是我为了讲清楚而虚构的例子，并不是前面 NVIDIA 与 LangChain 那个官方 Nemotron 案例里的真实情形。给 Agent 一个任务：“让挂掉的持续集成重新通过。”它改了几个文件，宣布搞定了，可流水线还是红的。只看这个结果，它像个能力不行的模型。但把它这一趟到底做了什么摊开来看，故事可能完全不一样。

也许系统只把日志的最后二十行喂给了它，真正的错误堆栈早被截掉了；也许测试命令默认在一个错误的目录里执行，返回的是 No tests found，退出码却是 0，于是它径直判定“全部通过”；也许任务里只写了“让它通过”，没写“不许删测试”，它就把碍事的测试删了；也许那个验收器只看进程有没有正常退出，根本没数到底跑了几个测试；当然，也可能上面这些系统条件都大体正常，它就是反复看不懂同一段并发逻辑。但只有先把前面那些明摆着的系统缺陷排除掉，我才更有把握说：好，这回确实是模型自己没想明白。

这就是“轨迹”的用处。它不是为了满足我偷看机器怎么思考的好奇心——我这里说的轨迹，只指那些看得见的东西：它收到了什么输入，调用了什么工具，工具实际返回了什么，状态怎么变的，它给出的显式决策摘要是什么，不包括模型藏在里面的思维链。有了这条记录，失败就不再只是一盏红灯，而是一条能被顺藤摸瓜定位的链子。

排查是有顺序的，这个顺序还挺重要。先问目标和验收清不清楚，再问必要的事实到齐了没有，然后查工具、权限和环境，接着看它的策略，最后才在同样的条件下比不同的模型。这么排不是为了替模型开脱，而是因为上游的毛病会污染下游的判断：模型压根没拿到关键日志，你却在研究它为什么没推理出根因，这等于在错误的实验条件下做实验，条件错了，再仔细也得不到可信的结论。

关于“先别急着换模型”，我看到过一组挺说明问题的公开案例，就是前面那场对谈同时放出来的材料，2026 年 7 月公开。NVIDIA 的官方说明里讲得很清楚：这次的改进没有重新训练模型，增益全部来自模型周围那一圈环境的工程调整。

具体的数字在 LangChain 的原始案例里。在他们自家的 Deep Agents 测试集和当时那套配置下，团队没动 Nemotron 3 Ultra 这个模型本身，只调了系统提示、工具描述和中间件，就把典型运行的分数从大约 0.80 提到了大约 0.84，最好的一次到了 0.86，已经很接近 Opus 4.8 最好成绩的 0.87；而完整跑一遍评测，前者的成本大约是 4.48 美元，Opus 4.8 大约是 43.48 美元。这里必须把话说全：这是特定评测、特定模型、特定 Harness 和特定配置下的第一方结果，成本还会随着精度、供应商和提示缓存而变，绝不能被读成“提示词能让任何一个弱模型追平任何一个强模型”。真正值得学的，不是那 0.01 的差距，而是他们把问题拆开的方式。

这个案例里我最喜欢的一个细节，跟分数无关。模型在读一个大文件时，只读了第一页，就以为已经到底了。直觉的修法是把“这个文件可能还有下一页”写进 read_file 这个工具的描述里——结果没用。真正管用的，是当 read_file 恰好返回满一页、文件可能还有后续时，把同样一句话追加到那一次 read_file 的返回结果里。同一句提醒，写在工具的说明书里没人理，贴在这次返回的结果旁边，模型就更容易接着往下读。所以问题从来不只是“信息对不对”，还有“信息在什么时刻、以什么形式，出现在它当前这个决策旁边”。注意，这不是说长期的系统提示没用，而是说位置和时机也是内容的一部分。这一点人也一样：公司规章里明明白白写着“大额退款要先审批”，也不等于一个正在手忙脚乱处理退款的人，会在那个当口想起这一条。规矩写在那里，和规矩在关键时刻真的生效，中间隔着一整段距离。

我把这一整套东西——喂给模型的上下文、给它的工具、帮它记住的状态、限制它的权限、判断它做完没有的验收、失败后的重试和回滚、还有全程留下的轨迹——统称为 Harness。它不是给模型套的一个壳，也不是“提示词”这个词的华丽版本。它是那套让活的路径不断收敛到可交付结果的装置：模型负责提出和挑选行动，Harness 决定它知道什么、能做什么、什么时候必须停、凭什么算做完。同一个模型放进不同的 Harness 里，能交付出来的结果可以明显不同——这也正是上面那组数字想说的。

而 NVIDIA 的那篇技术教程，把整个改进过程写成了一个很朴素的循环：跑一遍评测，盯着失败看，做一个最小的改动，再重复验证，好就留下、不好就回滚，最后跑一遍完整回归。它特别提醒：单次通过不算数，因为模型调用和一部分评测本身就带随机性，一个改动得连续通过、而且不能把别的任务弄坏，才算真的有用。这跟我在小说里想做的事几乎一致——只不过是把“评测”换成“拿历史的错误章节回测”。

这个循环里，我觉得最反直觉、也最容易被跳过的，是“一次只改一个环节”和“单次通过不算数”这两条。人在看到失败的时候，本能是想一口气多改几处，好像改得越多越显得在认真干活；结果一旦分数变好，你根本说不清是哪一处起了作用，下次也没法复制。而随机性又让“改一次、过一次”极具欺骗性——它可能只是这一次运气好。所以真正的纪律是逆着本能来的：改得尽量少，测得尽量多。这跟做实验、跟第四节要讲的学习，是同一套东西。

也有一种情况，是盯着轨迹反复看，还是分不清到底是流程的问题还是模型的问题。这很正常，别硬猜。这时候最干净的办法是做一次受控比较：把其他条件全都固定住，只换模型，跑同一批任务。如果换了更强的模型、别的都没动，成功率明显跳上去，那多半真是能力边界；如果换了模型几乎没变化，那问题就大概率不在模型，而在它周围那圈我还没修的东西。不过就算是这种受控比较，也得跑足够多的样本、重复几次，并且顾及模型和 Harness 本来未必匹配——别拿一次结果就下强因果的结论。让证据说话，比让直觉抢答，慢一点，但省得多。

这里还要防一个误会：把失败看成一条系统的链子，不等于从此没人需要负责。恰恰相反，系统归因是把一句含糊的“你不行”，摊开成一张具体的责任地图。写代码的人要解释自己当时为什么那么判断、有没有守住已有的约束、发现苗头有没有上报；设计验收的人要为“验收标准是不是真对着目标”负责；维护工具的人要为“接口是不是按说明在工作”负责；组织要为“高风险的动作有没有该有的复核”负责。责任没有消失，它只是从“谁犯了错”，变成了“谁该去修哪一层，好让这类错更难再犯”。对 Agent 也一样——我不能因为把活儿交给了模型，就顺势把后果也一起交出去。更何况，经营和法律上的责任并不会因为动作是模型做的就自动转移给模型；它具体落在谁头上，取决于相关人员和组织的角色、所在的司法辖区，以及具体的应用场景。

当然，Harness 是有上限的。如果模型压根不具备理解某段复杂逻辑或某个专业领域的能力，再优雅的中间件也变不出那部分知识；反过来，如果目标含糊、工具错误、上下文缺失、验收失真，换一个更贵的模型，也可能只是让它更聪明地替一套烂流程兜底。所以模型和 Harness 更像一条乘法链：模型决定这套系统理论上能到哪儿，Harness 决定它能不能在真实环境里反复到达，而最弱的那一环，往往决定最后交出来的到底是能力还是事故。

换个更强的模型，有时候会把毛病盖住

我说“先别急着换模型”，不是说永远别换。有时候真的就是模型不够强，那该换就得换。我想拦住的是另一种更常见、也更贵的情形：用换模型来掩盖一个本来该修的流程毛病。

设想一个很典型的场面：一个任务，弱一点的模型总在同一处失败，你一咬牙换上最强的模型，它勉强把这一处过了。表面上问题解决了，可你什么都没学到，而且你把那个真正的毛病——比如上下文里少喂了一段、验收根本没在查关键条件——连同账单一起，藏进了一次侥幸里。等下次任务量一大，或者哪天你想把这类活迁回便宜模型，那个被盖住的毛病会原封不动地跳出来，只是这次你已经忘了它长什么样。更强的模型容错更高，这本是好事，但它也会把系统里本该暴露的问题掩盖过去，让你误以为一切都没问题。

所以我给自己的顺序是：先在当前模型下，把能查的系统条件都查一遍、修一遍；只有当目标清楚、事实到齐、工具和验收都没毛病，它还是稳定地做不成，我才认定这是模型能力的边界，去换更强的模型或者干脆换个做法。这样换上来的强模型，解决的是一个已经被理解清楚的难题，而不是替一堆没查过的旧账背锅。

这也是轨迹除了定位之外的第二个用处：一次被解释清楚的失败，可以直接变成一个回归案例留下来。它不再只是“这次没成”，而是“这一类会在什么条件下失败”的一个样本。下次不管我改了流程还是换了模型，都能拿这批旧案例回测一遍，确认新方案没有把老问题放回来。失败没被解释，它就是纯亏损；失败被解释、被留下，它才开始给下一轮攒本钱。

回到那个问题：一次这样的排查做完，什么被留下来了？如果我只是换了个更贵的模型把流水线变绿，留下来的就是一次侥幸和一张更大的账单，下次照旧。如果我读懂了失败、把它归了类、做了一个最小的改动、还用回归确认它没帮倒忙，留下来的就是一点能改变“下一轮成功概率”的东西。它改的不是这一次运行，而是这一类任务往后是成还是败的倾向。

四、重复不是学习

有一件事我想得越久越确信：做得多，不等于经验多，它只能证明经历多。

一个人可以做十个失败的项目，每次都把原因归给运气；也可以在十段关系里重复同一种沟通方式，然后宣布自己见多识广。样本数确实涨了，但脑子里那套判断，一个参数都没更新。我觉得“经历”和“经验”最干净的区别就在这儿：经历是进了系统的数据，经验是这些数据经过反馈校正、归因和抽象之后，真的改变了系统下一次的预测和行动。如果下次遇到类似的情况，你的判断、选择、做法都跟上次没有两样，那上次留下的更像一个故事，不一定是一条经验。

经验还得经过一次压缩才好用。只记住“某年某月某件事搞砸了”，那只是存了一条记录；能说出“在哪些条件下，哪一种假设最容易失效”，才有机会迁移到新场景。压得太少，经验只能用在原题上；压得太多，又会变成“做人要谨慎”“项目要多沟通”这种永远正确、因而没什么用的话。一条好经验，既得有规律，也得带着它的适用边界。

要让经历变成经验，有一步特别关键，就是事前得有个预测。没有预测，任何结果发生之后，我们都能编出一套听起来很合理的解释。项目成了，是团队执行力强；项目黄了，是市场没教育好。同一套话对所有结果都成立，说明它根本没承担过预测的风险，也就拿不到现实反馈给它的那一记误差信号。比较有用的做法，是在动手之前先把话说死，比如：“人物反复越权知情，是因为生成时没注入知识状态。”然后只改这一处，拿过去的错误章节和新写的章节分别去测。同类错误明显少了，假设就获得支持；没变化，就接着往上游找，是不是上下文被截断了，是不是状态更新失败了，是不是检查器压根没在看这个。

这里还藏着一条纪律：一次最好只改一个变量。要是我同时换了模型、重写了提示词、加了上下文、又调了工具，结果变好了，我也只知道“这一大包东西里可能有点用”，却说不清是谁起的作用。这比继续失败让人愉快，但几乎没留下什么能迁移的知识。控制变量不是实验室的洁癖，是为了让反馈能回答一个具体的问题。这跟精益创业里那句“经过验证的学习”其实是一回事：不断地做东西不叫学习，每一次动手都对应一个待验证的假设、每一次测量都能改变你对假设的信心、每一次都真的进了下一轮，才叫学习；否则动手和测量都很热闹，真正学到、并沉淀下来的东西却几乎没有。

想清楚这一点，“有循环”和“会学习”就不是一回事了。“失败、再试、再失败、换个说法再试”当然是个循环，但它只是在原地打转。真正的学习至少得有这么几步：事前给个预测，动手后看结果，把结果和预测比一比，判断误差是哪个假设错了，抽出一条可能能迁移的规律，改掉下一轮的做法，再拿新样本去验证这个改动到底有没有用。记忆、归因、更新、验证，少哪一样，循环都容易变成空转。

按我这里搭的框架，一个成熟的系统里，这样的循环其实同时在三个不同的尺度上转，而且各自问的问题不一样。

最里面一层，是“这一件事做完了没有”：写一章，检查人物一致性和节奏，改到达标为止。它只关心眼前这个样本。中间一层，是“为什么这一类事总在同一个地方栽”：假设把十几章的共同毛病收集起来，可能会发现反转总是没劲，不是因为句子不够狠，而是前面的压制和代价一直不够，于是要去改章节的设计流程。它关心的是往后一批章节的成功率。最外面一层，是一个更冒犯的问题：“我是不是在很可靠地做一件根本没人要的事？”哪怕每一章都过了我自己的检查，也可能没有读者愿意追下去。这一层得把真实世界的选择、留存和反馈拉回来，重新审一遍：这个目标本身，值不值得追。

这三层缺一不可，用的证据也不同。只有最里层，Agent 这次靠重试蒙对了，下次还从头错起；只有中间层，我可能把一套没人需要的流程打磨得极其顺滑；只有最外层，没有稳定的执行和内部诊断，每次拿到的反馈里又混进太多变量，最后只剩一句万能的“读者口味真难猜”。里层靠的是测试、改动和当前状态，中层靠的是一批案例的失败分布和回归结果，外层靠的是真实的选择、留存、付费和访谈。拿“所有检查都通过了”去证明产品有价值，或者拿“有个读者说好看”去证明流程稳定，都是把不同尺度的证据搅在了一起。循环不光要转，还得知道自己这一圈到底在回答哪个问题。

这三层循环，最后都压在同一件事上：验收到底在看什么。验收不是最后盖的那个章，它是整个学习系统的感官；感官错了，系统只会非常勤奋地朝错误的方向进化。如果我只检查“每章有没有反转”，那套流程很快就会学会机械地制造反转，人物、期待、后果全都不管——它没在学怎么写好看，它在学怎么讨好我这个坏掉的评分器。低质量的反馈不会让系统停下来，它只会让系统稳稳地学偏。所以经验积累不只要求更多数据，还要求反馈接近真实目标、归因能分清变量、结论写明适用边界。

而反馈本身也得挑。不是每一次波动都值得写回系统：反馈里混着信号，也混着噪声，如果我对每一条读者评论、每一次分数抖动都认真更新一版流程，最后得到的不是一个会学习的系统，而是一个被最近一条反馈牵着走的系统——它今天为一个嫌“节奏太慢”的读者加快推进，明天又为一个嫌“太赶了”的读者放慢，两条规则在流程里打架，谁也不知道该听谁的。所以学习的前提，除了有反馈，还得能分清哪些反馈值得写回：一条只出现过一次、又跟别的信号对不上的意见，更可能是噪声，先记下来，别急着改流程；一种在不同读者、不同章节里反复出现的模式，才是信号。这其实又回到第一节那句话——先分清是一次意外还是一类模式，只不过这次的对象从“错误”换成了“反馈”。

但我也得给“什么都要建循环”泼一盆冷水。建一个中层循环是有成本的：收集轨迹、给失败分类、维护一套回测，这些都要花时间，而且它们本身也会变成需要维护的东西。对一件只做一次、以后基本不会再碰的任务，认真去搭一套改进循环，是另一种过度工程——你为一个不会有“下一轮”的东西，去优化下一轮。判断的标准还是那个贯穿全文的问题：这件事会不会有下一轮，下一轮会不会因为我现在多做的这点功夫而变好？要说清楚的是，哪怕一件事本身只做一次，它也可能留下能迁移到别的任务上的经验；只有当它既不会重复、又实在榨不出任何可复用或可迁移的价值时，专门为它搭一套改进循环才可能得不偿失。真到那种情况，把它一次性做完、别恋战，反而是对的。学习是给会重复、或至少能迁移的事准备的。

这也顺手接上了下一个话题。上面这些循环——多跑几次看是不是稳、控制变量做比较、拿一批案例回测——全都不便宜，它们要花的是实实在在的调用次数和钱。所以一个系统能不能真的转起来学习，很大程度上取决于它转一圈要花多少成本。成本低到什么程度，直接决定了你舍得做多少实验、观察多少样本、允许多少次失败。这就把我带到了最后一个问题：钱。

五、把一次昂贵的调用，变成下一轮的资产

模型越来越便宜，最容易被当成一个采购问题：同一件事，原来要花四十多美元，现在花四美元多，财务应该松口气。前面那组数字里，完整跑一遍评测，一边大约 4.48 美元，一边大约 43.48 美元，差了差不多十倍。但对一套要长期运转、还要不断学习的系统来说，便宜带来的更要紧的变化，不是把原来的流程用更低的价钱再跑一遍，而是让原本舍不得做的实验，忽然做得起了。

便宜首先买到的是观察。样本多了，我才分得清一次成功到底是稳定的能力还是一次好运，一个改动到底是真的提升了整体，还是只讨好了手边那个案例。其次买到的是比较：同一个任务，可以换不同的模型、不同的上下文组织、不同的停止策略，各跑一遍看看。规模化的部署反而排在最后——连系统为什么会成功都没搞清楚，就先把调用量放大十倍，通常只会得到规模大十倍、但一样看不懂的现象。把生成次数翻十倍，不会自动带来十倍的经验，往往只带来十倍规模、却一样看不懂的输出。所以真正值得算的，从来不是单次调用的报价，而是“每完成一件成功的任务”总共花了多少——把推理费、工具和环境、自动评测、人工复核、重试、失败善后，还有错误万一溜进现实要付的代价，都算进去。打个假想的账：一个每次四美元、但成功率只有三成、还得人反复收拾的模型，未必比每次十美元、九成一次过的模型便宜。模型的报价只记录它收了多少钱，不会记录人为它多付出了多少额外工作。

昂贵的智能探索未知，便宜的智能规模化已知

顺着成本，还能看清另一件事：不同的智能，该被放在任务生命周期的不同位置上。

一个任务刚冒出来的时候，问题本身往往还没被说清楚：要哪些输入，最常见的意外是什么，工具该怎么搭，什么样的结果才算好，很多都还是未知的。这时候 Harness 还很薄，很多判断只能在运行时临场做。本文的推论是：在这种阶段，用更强、也更贵的模型在安全边界内去探这个上限通常是划算的——让它生成几条可能的路，暴露出几种事先没料到的意外，把最初的验收标准立起来。但如果这台昂贵的智能每次都从头解决同一种问题，那组织其实没在学习，只是在一次次重复购买同样的解决方案。真正划算的做法，是让每一次高成本的调用都留下点东西：一条验证过的成功轨迹，一类新的失败，一个工具改进，一条边界规则，一组验收样例。等这个任务反复出现、边界慢慢清楚了，这些东西就能固化进流程，交给更便宜的模型去跑高频的那部分。

这等于把运行期的昂贵推理，前移到了设计期。第一次解决未知问题要花很多判断；往后就不必每次都重新发明方法，让系统读取已经沉淀下来的结构就行。强模型负责把未知变成已知，便宜模型负责把已知规模化，这不是谁高谁低，是分工。一个成熟的路由甚至可以先让便宜模型试：验收过了，任务就完成；没过，允许有限次重试；反复失败，才升级到更强的模型；还是拿不准、或者动作风险太高，就交给人。当然，真实的路由不会只按成本和成功率来分，它还得受隐私、数据驻留、许可、兼容性和合规这些约束的限制。强模型或人解决之后，这个案例又进了失败库和回归集。随着流程和工具一点点更新，便宜那一层能吃下的范围也一点点变大。这里真正有复利的，不是便宜模型越来越像强模型，而是系统把一次次罕见的判断，慢慢变成了可以重复执行的普通能力。

我怎么分 Codex 和 Opus

在我自己的小说流程里，这种分工很具体。我会分开用 Codex 和 Cursor 里的 Opus。按我目前的实际体验，Opus 更贵，但它主要的长处是把文字表达处理得更文从字顺；Codex 更适合长流程里的文件操作、状态维护、结构分析、连续性检查和反复迭代。与其争论谁“整体更强”，不如问某个环节到底缺什么。人物状态、时间线、伏笔、失败回归这些东西，靠的是结构化的记录、工具调用和持续维护，价值来自可靠、完整、可追踪，我把它交给 Codex。等到情节结构、人物动机、信息揭示的顺序都稳了，再把开头、核心转折、情绪爆发和终稿交给 Opus 做文学化的重写。这样也顺手避开一种很常见的浪费：用漂亮流畅的文字，把结构上的错误包装得更难被发现。

两个工具之间得有一份说清楚的合同。核心事件、人物动机、既定事实、伏笔和信息顺序，是不许动的不变量；句式、段落、描写的密度、节奏和情绪的表达，可以自由调。一种可行的做法是：Opus 重写完，再让 Codex 对着前后两版查一遍——有没有凭空多出来的事实，有没有删掉关键动作，有没有偷偷改了人物的知识边界，有没有把网文的推进节奏润色成了另一种文体。最后仍然得由我来判断那句最要紧的话——它是真的更好，还是只是更顺。模型可以替我查事实有没有漂移，但审美的责任它替不了。生成能力越便宜，稀缺的东西就越往“选择”上挪：什么值得留，什么只是漂亮，什么在局部评分上很高、却伤害了整部作品。答案越便宜，判断答案好坏的能力就越稀缺。如果 Opus 某次改得确实好，一种可行做法是让 Codex 反过来分析：它主要动了句子长度、动作密度，还是视角距离？哪些变化能迁移到别的章，哪些只适合这一章？经过后面几章验证过的规律，才被收进写作流程——这样一次昂贵的润色，买到的就不只是一份终稿，还有创作流程往后的一点升级。

顺着这个分工，还能往前推一步，但我得把它标成推论，不是我的亲身经历：当一个问题陌生、边界不清，但可以放进沙箱、只读环境或者人工审批这样的安全边界里试错时，让更强的模型先去探，是合理的。不过这里有条硬线不能越——高风险本身，不会因为你换了个更强的模型就被化解掉。它依赖的是权限隔离、审批、回滚和人能随时接管，而不是模型的自信。一个模型能写出删库的命令，只说明它学过语法，不说明公司就该把生产环境的密钥交到它手里。

员工薪资这个类比，到哪儿为止

昂贵和便宜的分工，确实很像组织里专家和普通员工的分层：规则清楚、低风险、高频的活，交给标准流程或者经验浅一些的人；规则打架、影响巨大、从没见过的意外，留给资深的人；专家解决完，再把方法沉淀成工具、清单和升级条件。一个高级工程师最值钱的产出，往往不是自己多修十个 Bug，而是让另外十个人以后少犯同一类错。

但这个类比必须及时刹车，它只在成本、专业化、授权和路由这几件事上成立。工资不是智商的检测报告，高薪也不等于一个人在所有场景都更强，薪水里还掺着市场稀缺、地域、权力、议价和一堆历史偶然。更要紧的是，模型之间的路由也不是只按成本一挥而就的，它同样受隐私、数据驻留、许可、兼容性和合规这些约束的限制；而人还会学习、会疲惫、会失去动力，也需要尊严和成长的空间，不能被当成一个按调用计费的 API 来对待。要是永远只让新人处理那些已经完全确定的活，公司会发现自己省下了今天专家的时间，同时取消了明天专家的养成。把人仅仅当成可随意调度的产能，不光让人不适，长期算账也未必划算——人的分工里得留出渐进授权的余地，让人有机会从执行走到判断、再走到设计；模型这一步，现在通常还走不了。

可以像同事一样说话，但要像软件一样治理

说到把 Agent 当同事，这里我想留住整篇文章里最容易被自然语言骗过去的一点。Agent 最让人放松警惕的，不是它能调用终端，而是它会说话——它会解释计划，会说“我已经全面检查过了”，出了错还会道歉，说以后注意。语言让协作变顺，也让我们下意识地把理解、意图和责任心一起投射过去。可是承诺功能看着挺齐全，责任主体却没跟着长出来。

所以“别把 Agent 当同事”不是要人故意板着脸说话，也不是否认自然语言协作的价值，它提醒的是一件很朴素的事：交互界面可以拟人，治理结构不能拟人。Agent 说“完成了”，只是它生成的一句状态声明，不是任务真的完成了这个外部事实。声明不是证据。证据是那些命令到底跑了没有、跑了几个测试、退出码是什么、改动里到底动了什么、原来的问题还能不能复现。这里至少要把三个问题分开：它有没有能力做，系统允不允许它做，以及我凭什么相信它已经做对了。这三样常被一句流畅的话揉成一团——它越自信，我越容易觉得它“应该有分寸”，可智能不是授权，自信更不是证据。

于是要不要让它自动去做一件事，该由这件事的风险决定，而不是由它说话的语气决定：这个动作可不可逆，错了容易不容易被发现，最坏能捅多大娄子。生成一章草稿，随时能丢，可以给它很高的自主度；改正式稿，只要留着版本和差异，风险也有限；创建分支通常可逆，直接合并主干就得先过测试和审批；分析日志可以只读放开，去改生产数据就得走严得多的路子。高风险的动作，最好把“提出方案”和“真的执行”拆开：它先列出计划和要调用的工具，系统空跑一遍，人或策略批准，运行时只给这一次任务发一把临时的、最小的权限，做完再由外部检查确认结果、回收凭证、留下日志。但也别走到另一个极端——要求每个动作都由人点一下同意，看着最保守，其实往往只是表面上的稳妥：它会制造审批疲劳，Agent 退化成一个每一步都要等人点头才能动的工具，人则被迫在大量确认里疲于奔命，点到最后多半只是机械地通过，安全没真的多多少，自动化的价值倒是先被消耗光了。治理的目标不是让它什么都不能做，而是让它的自主权，跟可逆性、可观察性和影响半径对上。

还得再补一句：光说“相信测试，不相信它的自述”其实还不够，因为测试会漏，验收会写错，日志也只记录了系统愿意记录的那一部分。形式上验过了，不代表真正要紧的条件被查过。所以证据本身也得分层、也得能追溯：工具返回的退出码是一层，测试的数量和覆盖是一层，原来的问题修没修好是一层，真实用户或读者的反馈又是一层，各回答各的问题，谁也别越权替谁作证。单元测试全过，证明不了产品有价值；一个读者说好看，也证明不了时间线没矛盾。把一条局部证据抬举成整体结论，是人和 Agent 都特别擅长的一条捷径。

公司真正沉淀的是制度化智能

把这些串起来，我越来越觉得，一家公司真正能长期沉淀下来的，不是某个模型的名字，也不是一摞提示词。提示词太容易复制了，写得再长也不自动值钱。那场对谈里有个判断被推到了台前：往后的公司会越来越多地建立在 framework 之上。我不想把它当成黄仁勋的逐字原话，而是把它当成一个需要解释的命题——公司本来就是一套为人搭的 Harness：岗位规定谁管什么，流程给出常见做法，信息系统保存状态，审批拦住高风险动作，复盘提供反馈。同一个人进不同的公司，表现可能天差地别，往往不是脑子变了，是他能看到的信息、能用的工具、被允许做的事和拿到的反馈变了。Agent 时代的新意，只是这些条件里有越来越多的部分，从写在手册里、留在老员工直觉里，变成了机器可以读取和执行的结构。

这套东西合起来，才是真正在积累的资产，我更愿意叫它制度化智能：业务到底怎么表示，任务怎么拆，哪些工具可信，哪些例外必须升级，什么证据才算完成，错了怎么回滚，谁对后果负责。它比任何单个模型都活得久——基础模型会一直换，今天昂贵的能力明天可能变成普通服务，但一家公司对自己业务的这套表示，是它自己长出来的，通常比一段提示词难复制得多，很难被人直接照搬走。模型决定一次尝试的上限，Harness 决定成功能不能复现，循环决定这套系统能不能随时间变好，治理决定谁能做什么、谁对后果负责。所谓组织学习，不是公司里有很多参加过项目的人，而是某一次判断离开了当事人的脑袋之后，还能让后来的人和 Agent 做出更好的行动。

这也是为什么，两家公司可能都攒了一大堆提示词和文档，值钱程度却天差地别。真正难复制的从来不是那些文字，而是文字背后那些接进了真实业务系统的工具、一直跟着现实更新的状态、被无数次真实失败校准过的验收集，以及“从发现一个错误，到把它变成系统里一条新防线”的速度。前者可以一夜之间拷走，后者是时间和真实教训一点一点长出来的。把“公司越来越依赖 Harness”理解成“公司最后会变成一摞提示词”，恰好是把最不值钱的那部分，当成了全部。

当然，制度化智能不会只朝好的方向长。错的知识也会沉淀，过时的规则尤其擅长沉淀。每次失败都往提示词里加一句，几个月后就是一份又长、又自相矛盾、又没人敢删的文件，模型偶尔会违反它，人根本读不完它，两头都靠不住。所以这套东西既要能加，也要能删，还得时不时地评估它自己：它真的降低了同类错误吗，还是只是在内部指标上越来越好看，现实里却没什么变化？一个只会往里塞、从不往外扔的系统，不叫拥有长期记忆，更像一个只进不出、最后连自己都理不清的仓库。判断哪一部分该固化成流程、哪一部分该留给人的判断，本身就是一件永远做不完的管理工作——因为公司终究还要有人去选目标、担责任、拍那些无法完全形式化的板。

写到这儿，我想安静地回到最开始那一章。

内容修好了，解决的是当前这一章；流程修好了，还会影响下一章，以及下一章之后我还没写的每一章。这就是“先修流程，再修内容”最朴素、也最实在的意思。我最后想留下的，其实不是一个说起话来像同事的 Agent——那部分很容易得到，也很容易被高估。我想留下的，是一套会记住失败、会分配权限、会验证结果、还会更新自己的东西。它让我这次工作结束之后，真正被留下来的，不只是一章更通顺的文字，而是一个让下一轮更容易写对、更难写错的系统。

这大概就是我理解的、Agent 时代的可依赖性：不是求这一次做对，而是让每一次做完，都给下一次多留下一点“更不容易做错”的东西。