——从 Daniel Plainview 的行动系统，到 Worker Investor 的 Meta Governance 第一次看《血色将至》（There Will Be Blood），最容易被 Daniel Plainview 吸引的，并不是他的财富，而是他的商业头脑。他有一种极其强烈的行动感：看到信息，迅速判断；判断成立，就立即行动；遇到瓶颈，就想办法穿过去。他很少等待所谓“完美信息”，也很少把问题推给别人。他面对世界的基本姿态是：这里有东西，我要去看看；这里有机会，我要把它拿下来；这里有障碍，我要解决它。 这是一种很强的 agency。 但《血色将至》真正有意思的地方在于，它同时展示了这种能力的两面性。Daniel 几乎把一个 worker 能拥有的执行力、商业判断、资源整合、风险承担和所有权意识发展到了极致；可当这些能力沿着错误的目标函数不断复利时，他最终得到的却不是自由，而是一座更大的监狱。 这也是为什么这部电影非常适合放进 The Worker Investor 和 Human Capital ETF 的讨论中。 ...

——从 Problem Awareness、Builder 到短暂的人如何创造持久结构 最近，我越来越强烈地意识到一件平常却很难真正接受的事实：一个人的时间是有限的。 有限不只意味着人生有终点，也意味着我不可能把所有值得学的东西都学完，不可能把所有感兴趣的方向都探索一遍，更不可能把每一种可能的人生活一次。数学、编程、AI、流体力学、投资、写作、工程自动化，每一个方向都足以消耗许多年。继续增加学习清单，无法解决这个问题。我必须选择。 AI 使这种选择变得更加重要。过去，许多想法会因为不会写代码、找不到资料或缺少工具而停下来；现在，我已经可以借助 AI 更快地检索信息、学习 API、搭建原型和整理文章。当“获得一个答案”与“做出第一个版本”越来越容易，稀缺性便继续向上移动：答案仍然重要，但比答案更稀缺的，是发现、定义并长期拥有一个值得解决的问题。 Can I solve this problem? → Is this problem worth solving? 这不是一道只属于科学家或创业者的题。每一个依靠工作生活的人，都在用不可逆的时间换取工资、经验和结果。我们当然要完成眼前的任务，但如果一生始终只由外部任务组织，最重要的资本配置决定就从未真正回到自己手里：我的注意力究竟应该长期投向什么？ 我把这个问题称为 Life Problem。 一、Life Problem 不是一句宏愿 Life Problem 很容易被误解成一句宏大的使命，例如“改变世界”“推动人类进步”或“成为更好的自己”。这些话也许表达了愿望，却很难直接告诉人明天应该做什么。另一个极端，则是把某个几天就能解决的任务当成长久方向，例如“自动完成一个 NX 操作”。任务太小，完成以后牵引力也随之消失。 我寻找的，是处在两者之间的问题：足够大，可以不断展开；又足够具体，能够生成下一项真实行动。 Richard Hamming 在 1986 年的演讲《You and Your Research》中提出了一个直接的前提：每个人只有一次人生，因此值得认真想一想，自己所定义的“重要工作”是什么。他曾反复追问研究者：你的领域有哪些重要问题？你正在研究什么重要问题？但他同时提醒，“重要”不能只看结果听起来多么巨大，还要看是否存在一个可以进入的 reasonable attack。一个完全无法接触、无法检验的问题，还不能组织有效行动。1 这给了我一个很实用的判断： Large enough to organize a life, but concrete enough to generate the next project. Life Problem 不是一个必须一次解决的终极难题，而是一个能够持续生成问题、学习和作品的稳定问题域。它不提供未来二十年的详细路线，却能够不断生成下一步。Purpose 更接近“为什么值得”，Life Problem 则进一步追问：“我准备通过持续理解和改变什么现实，来实践这个为什么？”2 我现在会用七个问题检验一个候选的 Life Problem： 我观察的维度 我会追问什么 Recurrence 它是否在不同年份、工作和项目中反复出现，而不只是一时兴奋？ Depth 解决第一层以后，下面是否还有机制、约束和新的未知？ Attackability 以我现在的能力与资源，能否找到一个真实的下一步？ Generativity 它能否持续生成研究、原型、文章、代码、实验或产品？ Compounding 今天留下的结果，能否让下一次理解和行动更容易？ External Value 对它的理解，最终能否改善别人面对同类问题的方式？ Ownership 我能否合法、合规地保留其中一部分能力、作品、声誉或资产？ 我并不拿它们计算所谓的“人生最优解”。这七个问题只是帮助我排除两个极端：把一句空泛口号当成方向，或者把一个短期任务误认成终身问题。经过这些追问以后，我真正愿意保留的候选问题，通常都能反复进入现实、产生下一项行动，并在时间中留下东西。 ...

——从一场 7:2 的业余台球比赛，到 Simon Ramo、Charles D. Ellis 与 The Worker Investor 今年春节，我和几个朋友去打了一场台球。六个人分成 A、B 两队，每队三个人。我们都很久没有打过，水平其实差不多。就连美式落袋的具体规则，我也是到了现场才重新问 ChatGPT：哪些球属于自己，什么情况下算犯规，什么时候会给对方自由球。 规则几句话就讲清楚了。真正让我记住的，却不是规则，而是比赛过程中发生的一次战略变化。我们一共打了九局，最后 A 队以 7:2 获胜。如果只看比分，可能会以为双方水平存在明显差距，但事实并不是这样。我们没有谁技术特别好，也没有人能够稳定清台。真正拉开比分的，不是谁打出了更多漂亮的进球，而是谁更少把机会直接送给对方。 一、从“大力出奇迹”到不给对手机会 刚开始上场时，我的想法非常简单：尽量用力，把球打进袋。我好像本能地认为，只有进球才叫打得好；力度越大、角度越刁钻，越能证明自己的水平。至于白球最后停在哪里，目标球打丢后会给对手留下什么位置，甚至队友下一杆要面对怎样的局面，我都没有认真考虑。 问题是，我并没有稳定完成这些击球的能力。一杆没有打进，并不只是“少得一分”。如果目标球停在袋口，或者我没有先碰到己方目标球，按照我们当天采用的规则送出自由球，那么这一杆还会直接变成对手的机会。尤其当桌面上的球越来越少时，一次自由球往往就等于把整局比赛交了出去。 打了几局以后，我开始改变策略。我不再要求每一杆都必须进球，而是先守住两条底线：第一，先碰到己方目标球，不轻易犯规，不给对手自由球；第二，如果没有把握进球，就尽量控制白球的位置，把它停在一个让对手不舒服、但让队友下一杆更容易处理的地方。 这时，我思考的对象已经不再只是眼前这一杆。我开始考虑这一杆结束后的桌面，考虑对手接下来能看到什么球，也考虑队友再次上场时会接到怎样的局面。很快，A 队三个人形成了一种默契：不急着证明自己能进球，先不要把容易的机会留给对方。 结果是，B 队为了主动进攻，开始不断出现出界、犯规和送自由球的情况；我们反而从这些失误中得到越来越多的简单机会。当我不再要求自己“一杆取胜”，挥杆压力反而小了，力度更轻，动作更稳定，白球的位置也更可控。 那天我第一次非常具体地意识到： 在一群水平接近的普通人之间，真正拉开差距的，往往不是谁更强，而是谁更少犯低级错误。 二、五十年前，另一位业余球手发现了同一件事 几个月以后，我在 Howard Marks 的一段演讲中听到 Simon Ramo 的名字。Marks 也曾在 Oaktree 的备忘录中，用职业与业余网球解释投资中的“赢家游戏”和“输家游戏”。1 Ramo 不是职业网球运动员，也不是网球教练。他是一位系统工程师，曾参与美国早期洲际弹道导弹系统工程，并与 Dean Wooldridge 在 1953 年共同创办 Ramo-Wooldridge Corporation；该公司后来成为 TRW 的前身。1970 年，他出版了一本很薄的书——Extraordinary Tennis for the Ordinary Player，可以译为《普通球员的非凡网球》。2 他研究的不是职业选手怎样打出更快的发球，而是一个更朴素的问题：普通人究竟为什么会输掉一场网球比赛？ Ramo 观察后发现，看起来使用相同球场、球拍、规则和计分方式的网球，其实存在两种完全不同的游戏。职业选手之间的比赛是 Winner’s Game。双方很少出现低级错误，最终胜负通常由某位球员主动打出的制胜球决定，胜者真正赢得了分数。普通人之间的比赛则更接近 Loser’s Game。大量回合不是因为对方打出了无法回击的好球而结束，而是有人把球打进了网、打出了界，或者发球双误。获胜者未必创造了更多奇迹，只是把球留在场内的次数更多。 Charles D. Ellis 在 1975 年发表的经典文章 The Loser’s Game 中转述了 Ramo 的统计：职业比赛中，大约 80% 的分数是被主动赢下来的；业余比赛中，大约 80% 的分数则是由一方主动输掉的。Ellis 借此区分了 Winner’s Game 与 Loser’s Game：前者的结果主要由胜者的行动决定，后者的结果主要由败者的失误决定。3 ...

——从 Journal 到真实环境验证：AI 降低的是实现门槛，而不是工程责任 上一篇文章中，我讨论了一个问题：工作经验在什么条件下，才能成为真正的资产？ 我以智能管路 PMI 标注为例，提出了一条转化路径：把任务提升为问题，把经验提炼为规则，把规则写入系统，再把系统沉淀为作品。 但那篇文章没有详细回答一个更具体的问题：当一个人并不具备软件开发经验时，他究竟怎样把自己脑海中的工程经验写入系统？ 因为在开始这项工作时，我对 NX Open 二次开发几乎一无所知。 我不熟悉 NX Open 的对象模型，不知道一个被鼠标选中的面，在程序中对应什么对象；不知道怎样通过代码读取组件名称、几何属性和中心线长度；也不知道应该调用哪些 API，才能在三维模型中创建带引线的 PMI 标注。 按照传统的学习路径，我似乎应该先学习 Python，再学习 NX Open，阅读开发文档，理解类、方法、Builder 和 Session，最后才有资格尝试开发插件。 但我最终走的并不是这条路径。 我没有先学会 NX Open，再开始解决问题。我先进入了一个真实问题，然后在不断解决问题的过程中，一点一点获得了完成下一步所需要的知识。 一、我不是从“学习开发”开始，而是从一个重复问题开始 我最初看到的，并不是一个软件开发项目。 我看到的是一组每天都可能重复发生的工程动作：在三维模型中找到一根管路，确认它对应的对象，查找名称，测量中心线长度，整理信息，再创建相应的标注。 完成其中一次操作并不困难。真正的问题在于，这些动作并不是只发生一次。车型变化、模型更新或者管路数量增加以后，同样的查找、测量、复制和核对还会再次发生。 于是，我开始问： 为什么每一根管路，都需要重新经历一遍近似的操作？ 如果工程师最终需要的结果具有相对固定的结构——名称、长度、对象信息和标注——那么这些信息是否可以直接从模型中读取？ 如果人工操作本身存在稳定步骤，那么这些步骤能否被软件重新执行？ 我当时还不知道具体应该怎样实现，但我已经知道自己想改变什么。 这一点后来变得非常重要。因为我虽然不懂 NX Open，却知道： 工程师实际会选择什么； 哪些对象是真正的管路； 哪些对象只是接头、管夹或附件； 哪些对象需要计算长度； 名称应该以什么形式显示； 什么结果对装配规范真正有用； 一个功能是否解决了现场问题。 换句话说，我缺少的是 Implementation Knowledge，也就是实现知识；但我并不缺少 Problem Knowledge，也就是问题知识。 AI 可以帮助我补充前者，但后者必须从真实工作中产生。 二、Journal 不是答案，而是让 AI 看见人的动作 NX 可以录制 Journal，把人在软件中完成的一系列操作，以程序代码的形式记录下来。1 于是，我产生了一个很直接的想法：既然我暂时不知道 NX Open 的正确写法，能不能先在 NX 中完成一次正确的人工操作，再把录制出来的 Journal 交给 AI 分析？ ...

——从一次智能管路 PMI 标注实践谈起 很多人工作几年以后，会发现一个令人不安的事实：自己明明做过很多项目、处理过很多问题、加过很多班，但当准备换一个岗位、进入一个新的行业，或者试图独立做一点事情时，却很难说清楚自己究竟积累下了什么。 工作完成了，项目交付了，工资也发放了。但那些经验，真的成为资产了吗？ 工作时间与个人资产之间，并不存在自动转换关系。一个人可能工作了十年，却只是把第一年的流程重复了十次；也可能参与过很多项目，却没有留下任何能够迁移、复用和证明的成果。 这与工资有些相似。工资是劳动在当期的结算。如果工资被全部消费，劳动的价值便主要停留在当期；只有其中一部分被保存、投资并转化为存量，过去的劳动才有机会继续参与未来。 经验也是如此。经验只有经过保存、提炼和转化，才可能从一次性的劳动流量，变成能够继续调用的能力存量。 这是《The Worker Investor》一直希望讨论的问题。所谓 Worker Investor，并不是要求每一个工作者都去炒股票，也不是让所有人辞职创业。它首先意味着一种身份意识的变化： 我不仅是在出售今天的劳动，也在投资未来的自己。 最近，我在实际工作中尝试解决了一个具体问题：将原本依靠人工完成的管路识别、长度测量、信息整理和工程标注流程，逐步转化为一套智能化的 PMI 标注工作流。 工程师选择对应的管路对象后，系统自动识别对象、读取名称、计算长度，并按照统一格式生成三维标注。 出于保密和知识产权边界的需要，本文不会讨论具体产品、企业数据、内部模型、对象编号和源代码。但这个过程本身，为我们提供了一个很好的案例：一次具体的工作产出，在什么条件下，才可能转化为一个人的长期资产？ 我的答案可以归纳为三个条件。 一、你解决的不是一次任务，而是一类问题 在传统工作模式中，我们很容易把注意力集中在“把这一单做完”。收到一个任务，完成一个任务；遇到一个问题，临时解决一个问题；制作一份装配规范，再继续制作下一份装配规范。 这种方式当然能够产生结果，但它产生的主要是一次性交付。一次性交付的特点是：任务结束，价值也随之结束。 以管路装配规范为例，原来的流程大致包括：工程师在三维模型中寻找对应管路，识别对象名称，测量管路长度，调整模型视角，截取图片，再将名称、长度和装配信息整理到工程图或外部文档中。 如果只有一根管路，这些操作似乎并不复杂。但当对象数量增加、车型发生变化、模型版本更新以后，问题就会变得明显： 同一类操作需要不断重复； 不同工程师可能采用不同的数据口径； 模型发生变化后，原有结果需要重新确认； 标注信息与模型对象之间缺少稳定关联； 大量时间消耗在查找、测量、复制、核对和整理上。 这时，真正值得解决的问题就不再是： 怎样把眼前这根管路标注完成？ 而是： 为什么这一类管路，每一次都需要重新寻找、测量和整理？能不能建立一种机制，让它们按照统一规则被识别、测量和标注？ 这两个问题看似接近，实际上属于两个完全不同的层级。前者是 Task Completion，完成任务。后者是 Problem Ownership，拥有问题。 Task Completion 关注的是眼前的交付。Problem Ownership 关注的是问题为什么反复出现、哪些环节可以被改变，以及怎样让同类问题以后不再以相同成本发生。 当一个 Worker 开始从“完成别人分配的任务”，转向“定义并解决一类反复出现的问题”时，他才真正进入了资产积累的起点。因为资产并不来自工作量本身，而来自对问题结构的理解。 你需要看见： 哪些步骤在反复发生； 哪些判断具有稳定规律； 哪些信息可以从系统中直接获取； 哪些错误来自流程设计，而不是个人不够认真； 哪些环节适合交给工具； 哪些判断和责任必须继续由工程师承担。 一个人处理过一百次相似任务，不一定拥有一项资产。如果他从未提取其中的共同结构，这一百次工作可能只增加了熟练度，却没有形成新的系统。 但当一个人能够看清这一百次任务背后的共同结构时，经验才获得了跨项目复用的可能。因此，不要只问怎样把这次工作做完，还要问： 为什么这类工作每次都需要重新做？ 二、把隐性经验转化为可以重复运行的系统 工作经验最初通常存在于人的脑海中。一个熟练的工程师可能知道： 哪一种对象是真正需要标注的管路； 哪一种对象只是接头、阀件或支架； 从哪里能够找到中心线； 怎样判断某一段长度是否可信； 名称应该从几何对象、组件还是属性中读取； 哪些标注应当显示在模型中； 哪些信息应当进入工程图； 哪些情况应该由系统提示异常。 这些知识非常有价值。但如果它们只存在于个人经验中，就仍然是一种脆弱的资产。 隐性经验通常存在几个问题： 很难完整传递给其他人； 很难在不同项目中保持一致； 很难被软件直接调用； 很难证明它究竟解决了什么； 每次执行仍然需要本人投入注意力； 一旦本人离开，经验可能随之消失。 因此，经验要成为真正的资产，就必须经历一次 Externalization，也就是外化。它需要从： ...