Python

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