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