Automation

——从 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，也就是外化。它需要从： ...

2024 年底，我进入比亚迪，开始做汽车热管理。第一次真正接触项目时，负责带我的同事恰好不在现场。我对业务、软件和工作流程都不熟。很多时候，我在电脑上点两下鼠标，就得停下来问一句：“下一步该做什么？” 几个月后，我用 Python 写出的工具开始在团队内部使用，我也第一次站到同事面前，讲解它解决了什么问题、应该怎样使用。这两个画面之间没有天赋觉醒，也没有突然开窍。中间只有一连串很普通的动作：不会，记录，犯错，重做；熟练之后发现低效；抱怨之后，再多问一句——这件事能不能被改变？ 回看工作第一年，我真正完成的变化，不只是从不会到会。 我开始从只能适应工作，走到尝试改造工作中的一小部分。 为保护同事与内部信息，文中对项目、工具和组织细节做了必要模糊处理。 一、一个没有准备好的开局 我并不是为这份工作准备了很多年。本科时，我读的是过程装备相关专业；研究生阶段，我做的是掺氢燃烧与 CFD。毕业前，我原本还在申请海外 PhD。后来，我在两周内改变方向，开始找工作，随后进入汽车行业。 燃烧、流体和传热的基础并非毫无用处，但它们不能自动变成工程经验。我在学校里更习惯边界清楚的问题：题目给出条件，老师知道答案，学生按照某套方法求解。真实工作却不是这样。问题可能只以一句模糊的需求出现；需要哪些输入、怎样判断结果、出了异常该找谁，往往都不会同时写在一张纸上。 刚入职时，我经历过一段“漂浮期”。每天坐在工位上，看起来很忙，心里却不知道自己究竟该掌握什么。身边的人都有任务，只有我像一块尚未接入系统的零件。 我当时有一个隐含期待：先把整套业务学会，再独立做事。后来才发现，工作并不按这个顺序发生：你不是学会以后才开始做，而是在开始做以后，才知道自己究竟要学什么。 对新人来说，第一项真实任务的价值不只在于交付。它会把抽象的“我要尽快成长”，压缩成一组可以回答的问题：哪个步骤不懂？哪个判断没有依据？什么结果才算正确？遇到异常应该怎样定位？任务给学习划出了边界，压力也第一次有了方向。 二、工作不是一场闭卷考试 第一个项目开始后，我最明显的感受是害怕。我怕问得太多，显得基础差；也怕不问，最后把事情做错。因为负责带我的同事不在现场，我只能把一个大问题拆成许多小问题，向不同的人求助。于是就出现了那个略显狼狈的状态：每操作几步，停下来确认；理解一点，再往前推进一点。 一开始，我把这种频繁请教看成能力不足。后来我才意识到，我当时的问题不在于问得多，而在于有没有让答案沉淀下来。所以，我开始记录：记操作步骤，也记每一步背后的判断；记别人给出的答案，也记自己原来错在哪里；记报错是怎样发生的，更记下一次应该先检查什么。当天弄清的问题，尽量当天整理。遇到相似任务时，先查自己的记录，再决定是否需要打扰别人。 这些笔记最初只是为了活下来。它们像一根临时拐杖，让我第二天不至于回到原点。但记录得多了以后，我发现自己正在建立一张属于新人的业务地图：哪些环节彼此关联，哪些规则最容易混淆，哪些异常经常一起出现。这张地图不完整，也未必漂亮，却比“我好像懂了”可靠得多。 工作不是闭卷考试。请教、查资料、复盘都不是作弊。真正重要的是，每一次借来的答案，能否逐渐变成自己的判断。 三、熟练以后，我才开始看见低效 随着任务逐渐熟悉，我不再需要每走一步都问人。也正是在这个阶段，我第一次清楚地看见流程里的重复劳动。有些操作本身不难，却需要不断点击、核对和重复输入。做一次还可以接受，连续做很多次，人就会烦躁。最初，我也把这种烦躁当作工作的一部分：既然流程一直如此，也许忍一忍就过去了。 但抱怨里其实藏着信息。当一件事让人反复厌烦，可能不是因为人不够有耐心，而是因为任务中存在尚未被识别的自动化机会。于是我开始问：哪些步骤必须由工程师判断？哪些只是机械重复？输入和输出能否被明确描述？出错以后，程序应该如何提醒人，而不是替人悄悄做决定？ 我用 Python 写了一个很粗糙的脚本，尝试处理其中一部分重复操作。第一版并不好看。它没有完整界面，只覆盖我眼前最熟悉的情形。但它确实跑通了。原本需要反复操作的过程，第一次被我拆成一组可以交给程序执行的步骤。 这件事带来的成就感，并不只是“我会写 Python”。更重要的是，我第一次感受到：一个员工除了接受流程，还可以在理解流程之后，对它提出新的实现方式。 抱怨只说明哪里让人痛苦；把痛苦翻译成清楚的问题，改变才真正开始。 从那以后，我再遇到重复工作，会刻意区分三件事：什么不能省，什么可以标准化，什么值得被工具化。这个判断本身，比某段代码更重要。代码会过时，具体软件会变化，但识别问题、划清边界和验证结果的能力可以迁移。 四、把自己踩过的坑，变成别人可以绕开的路 一个只在自己电脑上运行的脚本，很容易给人一种虚假的完成感。自己知道输入放在哪里，也知道程序出现异常后应该手动检查什么。换一个人使用，这些没有写下来的前提就会全部暴露出来。当同事开始试用我的工具时，我收到的问题比预想中多：输入不符合预期怎么办？结果该怎样核查？某个特殊情况是否适用？程序为什么没有按预期运行？这些反馈让我意识到，个人脚本和可复用工具之间，隔着的不是更复杂的代码，而是对他人负责。 我开始补充输入检查、异常提示和使用说明，也重新审视自己习以为常的规则。后来，我又做了一个用于辅助表格一致性核查的小工具。它的业务逻辑并不神秘，困难在于把散落在经验里的判断，变成明确、可检查的规则。为了向同事说明工具，我必须回答几个此前可以含糊带过的问题：它究竟解决什么？不解决什么？输出是否可信？使用者怎样发现程序没有覆盖的情况？ 讲解工具的过程，也是在重新理解工作。如果一套方法只有我能运行，它更像个人技巧；当别人能够理解、使用、质疑和验证时，它才开始成为团队资产。分享不是开发结束后的包装，而是检验思路是否完整的一部分。 这也是我工作第一年里一个很重要的转折。过去，我主要关心“这项任务我能不能完成”；后来，我开始关心“我解决问题的方式，能不能让下一次工作更容易”。 五、AI 放大的，是已经想清楚的问题 在完善第二个工具的通用编程部分时，我第一次更系统地使用 AI 辅助。我只让它处理公开、通用、边界清楚的编程问题。例如解释一个不熟悉的 Python 概念，提供通用界面的实现思路，或提示一段不含内部信息的示例代码中可能存在的明显错误。这些工作过去需要我翻很多资料，现在可以更快获得起点。 在不接触内部背景的前提下，AI 并不知道我真正面对的业务问题。它不知道哪些判断必须保留给工程师，也不知道某个结果在现实工作中意味着什么。核心规则仍然需要我从任务里抽取，再通过内部资料和同事确认。我也给自己划出了一条边界：公开可查的编程概念和通用实现，可以请 AI 协助；涉及内部流程、数据与设计规则的内容，必须留在合适的内部环境中处理。 这段经历让我对“AI 提高效率”有了更具体的理解。AI 可以很快给出代码草稿，却不能替我决定什么值得自动化；可以给出一个看似完整的答案，却不能替我为结果负责；可以放大执行速度，却不会自动补上我对问题的理解。 当问题没有想清楚时，AI 很可能只是让模糊更快地变成代码。 因此，真正稀缺的并不是会不会复制一段程序，而是能否在具体工作里发现问题，定义输入与输出，识别风险，并知道最后应该由谁判断。 六、从完成任务，到积累可以复用的资产 如果只看职位描述，我的第一年大概可以被概括为：从跨专业新人，逐渐学会了本职工作，并额外做了两个小工具。但对我来说，真正留下来的不只是这些结果。我学会了在没有准备好的时候开始，用真实任务决定学习顺序；学会了把提问变成记录，再把记录变成自己的判断；也学会了把抱怨拆成需求，把个人解决方案推向可以被别人使用和检验的工具。 这些变化让我开始用另一种眼光看待工作。工资当然重要，完成组织交付的任务也很重要。但一段工作经历除了产生工资和项目结果，还可以留下可迁移的专业能力、处理问题的方法、合作中的可信度，以及对真实系统的理解。具体工具和工作成果应当遵循公司的归属与保密要求；能够合规地沉淀在个人身上的，是定义问题、建立方法和承担结果的能力。 这正是 The Worker Investor 想追问的问题：一个仍然依赖工资、身处组织中的普通人，怎样让自己的劳动不在任务结束后完全归零？答案不是把公司的东西变成自己的，也不是把每一项工作都包装成副业。答案是认真完成工作的同时，问清楚自己正在积累什么：今天遇到的问题，是否提高了明天的判断？这次踩过的坑，是否沉淀成了方法？一次性的劳动，是否留下了可以复用的能力？ 回到刚入职时那个每点两下鼠标就要问人的自己，我并不觉得那段狼狈需要被掩饰。它说明我确实从不会开始，也说明后来的变化不是凭空发生。一年里最重要的进步，不是我终于可以少问几个人，也不是我多会写了几段 Python，而是当我再次遇到一件重复、混乱、令人烦躁的工作时，我开始知道应该怎样靠近它：先理解，再拆解；先记录，再验证；最后问一句—— 这一次，我能不能不只把事情做完，还让下一次做得更好？

——从使用 AI，到拥有生产率的残余 在上一篇文章里，我把人类知识比作《火影忍者》中散落在世界各处的查克拉，把不同的大模型比作拥有不同能力、规模和性格的尾兽。这个比喻帮助我理解：模型并不是知识本身，而是一个能够吸收、压缩、重新组织并调用知识的认知容器。 但如果继续追问，就会遇到一个更重要的问题：尾兽的查克拉来自哪里？又是谁拥有尾兽？ 在《火影忍者》的设定中，十尾可以转化为神树，神树的根则会从星球上的生命吸收查克拉。1 今天的大语言模型也呈现出一种相似的结构：它先从人类已经写下的文字、代码、图像和知识中学习模式；进入现实世界以后，又通过评测、反馈和具体工作流程，越来越深入地参与人类如何表达、判断与完成任务。 这不意味着每一次对话都会直接进入下一轮基础模型训练。不同产品、账户类型与隐私设置的数据政策并不相同：以 OpenAI 的公开政策为例，个人服务中的内容可能用于改进模型并允许用户退出，企业产品与 API 的输入输出则默认不用于训练，除非客户明确选择共享。2 更准确的说法是，在获得授权或用户主动提交反馈时，评测结果、错误报告、使用模式和任务分布都可能成为产品改进的信号。 数字劳动研究也提醒我们，价值生产不只发生在传统办公室和正式工时里。一层是数据标注、内容审核、转录和数据处理等有偿却常被外包、拆分的微任务；另一层是用户生成内容、评价、点击与反馈等参与活动，其中一部分会被平台转化为数据和产品改进信号。不过，后一类活动是否应当一概称为“劳动”，本身仍是研究中的争论。3 因此，AI 不只是一只储存知识的尾兽。它正在成为一只学习如何工作的十尾。 现代 worker 真正需要面对的，不只是这只十尾是否强大，而是：当越来越多人的知识、判断和劳动方式被写入系统，这些能力最终会沉淀在哪里？它们会成为劳动者可以携带的生产资料，还是主要成为少数组织拥有的资本？ 这把我们带回马克思关于机器、劳动与资本关系的分析，并由此引出本文的两个问题。需要说明的是，下面两个问法并不是马克思原文中的固定表述，而是我依据他的机器分析所作的当代转写。 一、机器替代部分劳动以后，原来支付工资的资本去了哪里？ 在马克思的分析中，资本并不只是静止的金钱，而是进入循环并追求增殖的价值。本文进一步关心的是：谁控制生产条件，谁又能够对未来产出提出索取。后者是我在 AI 时代对资本关系的延伸理解，并不是马克思对资本的直接定义。4 马克思把生产资本区分为不变资本与可变资本。这里的“不变”和“可变”，不是现代财务会计中的固定成本与变动成本。 不变资本是转化为原料、辅助材料、机器、工具和厂房等生产资料的资本。在马克思的价值理论中，这些生产资料在特定生产过程中把既有价值转移到产品中，却不会凭自身创造超过原有价值的新价值。可变资本则是用于购买劳动力的资本，通常表现为工资支出。它之所以“可变”，是因为劳动力在生产中的使用能够再生产自身价值的等价物，并在马克思的理论中创造超过它的剩余价值。4 因此，在马克思讨论的机器化场景中，值得注意的不只是岗位减少，还有一部分资本形态的转化： 部分可变资本 v → 不变资本 c 马克思在《资本论》第一卷第十三章第六节，用一家假设的壁纸工场说明所谓“补偿论”的问题。工场原有 6,000 英镑资本，其中 3,000 英镑购买原材料，另有 3,000 英镑雇用 100 名工人，每人年工资 30 英镑。引入价值 1,500 英镑的机器后，工场只保留 50 名工人。总资本仍是 6,000 英镑，但工资支出从 3,000 英镑降到 1,500 英镑，机器与原材料所占资本则提高到 4,500 英镑。这个算例为说明理论而构造，也明确省略了厂房、煤等项目，不应被当作现代企业的完整会计模型。5 被解雇的 50 名工人并没有使对应资本自动成为重新雇用他们的基金。原本用于购买其劳动力的一部分资本，已经被固定在机器中： 1,500v → 1,500c 马克思并不否认机器可能在其他部门创造新工作；他否认的是，这种补偿会由原有资本自动、同时并且足额发生。新岗位不必在相同时间、相同地点，以相同技能要求和收入水平出现。即使更便宜的机器释放出一小部分资本，它也不足以自动重新雇用全部被替代者。 这里存在两种完全不同的“释放”。劳动者被从岗位中释放出来，意味着他失去了工资；资本被释放出来重新购买劳动，则未必发生。技术可以释放人的时间，但如果收入没有随着时间一起被释放，所谓闲暇就可能表现为失业、降薪或更激烈的岗位竞争。 把这一结构类比到 AI 时代，机器换了一种形态： 工资预算 → 模型、算力、软件、数据与自动化系统 这不是说模型 API、云服务和软件订阅在会计上都属于固定资产，也不是把每一笔软件费用机械地等同于马克思的不变资本。更准确的观察是：企业可能把一部分原来用于购买劳动时间的预算，转向购买或租用由外部组织控制的技术能力。生产资料不一定以厂房里一台归企业所有的机器出现，也可以成为按调用量、席位或订阅持续付费的“租赁型能力”。 假设一家企业原来需要 100 个人完成某类工作。部署模型、知识库与 Agent 后，60 个人便可能完成相同甚至更多的产出。减少的工资支出不会自动返还给另外 40 个人；它可能被投入模型调用、系统集成和数据治理，也可能变成利润、股息或下一轮资本开支。 ...