第一次主动离职纪念

意想不到，我又一次失业了，不过这一次是我主动退出。

这一年发生了很多。真正开始回忆的时候，我发现脑子里留下来的并不是一条完整的故事，而是很多零散的场景、情绪和当时没有来得及整理的想法。如果说去年这个时候的我有多期待，那么现在回头看，就有多感慨。

今天是离职后第一周的第一天。趁着很多记忆还没有完全褪色，我想把这一年重新捡起来看看：我当时为什么来到这里，经历了什么，又为什么最终选择离开。

Welcome to the Jungle

Into the Physical World

进入的是一家具身公司，我现在还记得当时入职的场景，2周内完成了三轮面试，现场见识了机械臂外骨骼的运作和公司的一些demo场景，相比上一份工作的数据、接口和云服务，这些真正会运动、会和现实世界发生作用的机器，对当时的我有很强的新鲜感。我确实相信，自己可能正在进入一个新的技术周期。

我觉得这里就是我新的起点，一段新的征程。

和之前半居家、偏远程的工作模式不同，机器人行业天然需要面对硬件，因此大部分时候都需要到公司出勤。公司离家大概五十公里，于是和很多来到大城市工作的人一样，我也在城市另一边租了一个房子。

有点不同的是，我本来就是本地人。在这之前，我从来没有真正长期一个人生活过。

所以对当时的我来说，这不仅是一份新工作，也是一种新的生活。我从一个极其虚拟的行业——区块链——进入了一个极其物理的领域。过去几年，我的工作大多发生在屏幕里面：数据库、云服务、任务调度、API、日志和数据。而现在我要面对的是机器人、机械臂、Orin、传感器，以及一个软件无法独立定义结果的物理世界。

一切都很新鲜。

某种程度上，那种感觉甚至有点像重新毕业，又一次找到自己的第一份工作。我不知道接下来会发生什么，但至少在当时，我是期待的。

Bizarre Onboarding

我还记得第一天入职。

和上一家公司不同，这里几乎没有所谓的 onboarding。给你几个文档链接，告诉你几个项目和技术框架，然后就让你自己研究。

现在回头看，对于一家规模不大、仍然处于早期阶段的公司来说，没有一套特别完整的 onboarding 其实算不上什么严重的问题。真正让我后来在意的是，我逐渐发现，这种“没有人能够完整告诉你这个系统究竟如何运作”的状态，并不只存在于新人入职阶段。

和之前 all in cloud 的环境不同，这家公司大部分基础设施都倾向于 self-hosted。代码仓库、产物仓库以及一部分身份认证服务，都运行在自己的物理机器和 Docker 容器上。公司没有一个Infra 团队，基本上是开发自己搭建使用，各个系统的账号和身份认证基本各管各的，所以刚入职时，光记录各种服务的账号密码就是一件不小的事情。

没有正式的同事介绍，也没有真正意义上的项目介绍。

前两周，我基本只和直属领导沟通。我不知道坐在周围的人具体负责什么，也不知道自己之后究竟要做什么，只能对着公司的 codebase 漫无目的地翻，在 commit message 和不知道什么时候写下、早已部分过时的 README 里拼凑整个系统之间的关系。

对于习惯了上一家公司那些条条框框的我来说，这里有一种很奇怪的野蛮和自由。

但当时的我还没有觉得这是坏事。

新鲜感依然压过了不适。我只是期待着真正的工作开始。

The Mysterious Spell

我第一个被要求熟悉的仓库，是公司的“机器人大脑”。

听说这是整个公司最核心的部分。

诚实地说，第一次打开这个仓库的时候，我的感官很差。

它是一个巨大的 monorepo，过去做过的多个场景被不断堆积在里面；存在一些连原作者自己都说不清楚依赖关系的 submodule；软件代码和算法代码大量混杂；有很多为了 Demo 临时写下、后来却一直保留下来的逻辑；还有一个大到能让我的 LSP 分析直接爆栈的单体文件。

Type hint、模块边界、常量管理这些东西就更不用谈了。

这些问题单独拿出来其实都不致命。真正让我不安的是，我很难分辨这里面什么是长期维护的产品能力，什么是一次性的 Demo，什么又只是没人敢动的历史遗留。各种东西似乎只是不断叠加，然后继续往前跑。

后来我才知道，这个仓库就是公司融资 PPT 里那个听起来非常高科技的“智能 XXX”。

当时心里的憧憬一下凉了一半。

不过工作还是得继续。

我的第一个正式 PR 其实很简单：给一类机器人增加关节 TCP 的新接口参数适配，再写一个构建时自动下载缺失 URDF 的脚本。

代码本身也许两个小时就能写完。

真正的问题，是怎么让它跑起来。

机器人的算法程序运行在 NVIDIA Orin 上，也就是 ARM 架构。这个仓库几乎默认开发环境永远就是 ARM，所以使用 AMD 机器开发的我没法在本地真正启动它。

与此同时，机器人大脑把 Docker 更像是当成了一个 runtime，而不是严格意义上的构建产物。算法代码不断变化，但多个 commit 长期共用一个固定的大镜像；多个不同项目和场景的依赖继续叠加进去，最后镜像已经膨胀到十几个 GB。

而最痛苦的部分，还是环境本身。

没有完整的 setup 文档，没有真正可用的仿真环境，很多环境配置只存在于少数同事的脑子里。想调试，就必须使用真机；要使用真机，就得和算法同事协调机器人的使用时间。

我很清楚地记得，有一天为了启动这个程序，我从中午开始部署，一直到晚上才真正跑起来，前后花了将近八个小时。

这八个小时里真正和我的功能有关的问题其实很少。

更多时候是：

这个错误要问 A，A 告诉我这里是 B 配的；找到 B，B 又说这个东西可能只有 C 知道；某个 .so 找不到，要确认是不是机器出厂时某个 SOP 没执行；机械臂运动不对，到底是运动规划、视觉识别、硬件控制，还是机器本身的问题，又得重新找人。

在上一家公司，有 DevOps 和比较成熟的工程体系参与，我很少需要直接 SSH 到某台机器上，自己从头排查这种问题。

在这里却完全不同。

很多事情你必须亲历亲为。

小功能的代码改造可能只需要两小时，而搞清楚“这东西究竟为什么跑不起来”，反而花掉两天。

一个本应按步骤执行的 setup 指南，在这里变成了一场需要多个部门参与、但没人真正知道全貌的神秘仪式。传说只有待得足够久的 senior 算法工程师才知道如何从零把它设置起来。

我感觉自己进入了一片原始人的丛林，but with embodied intelligence。

后来回头看，我这一年里反复遇到的很多问题——文档缺失、知识依附于个人、环境不可复现、职责边界模糊、软件和算法纠缠——其实在第一个月就已经全部出现了。

只不过当时的我，还把这些理解成一家早期机器人公司的“野蛮和自由”。

Into the Fire

The Glue

入职后的两个月里，我做了一些 Demo、业务支持和零碎需求，也逐渐对公司的机器人解决方案有了一个大致认知。

简单来说，公司卖的是一套以机器人算法为核心的解决方案。

机器人本体来自外部供应商，再由硬件部门完成组装和改造；运动规划、视觉模型和感知模型主要由算法团队提供，也就是所谓的“机器人大脑”；软件部门则负责连接算法能力与真实业务，包括外部系统接入、Web 控制界面、机器人状态管理、业务数据流转，以及最终如何把这些数据和指令交给算法执行。

我的入职 Title 是 Backend，但很快我就发现，这里的“后端”和我过去理解的后端并不完全一样。

我既需要和前端联调 UI 业务，也需要和硬件沟通，因为有些场景需要从 Web 直接控制硬件；还要和算法一起调试，理解他们提供的能力边界，再想办法把业务数据转换成算法能够使用的形式。

与此同时，我既要在 Cloud 上开发，也要在 Orin 这样的 Edge 设备上开发和调试。

后来我越来越觉得，与其说自己是 Backend，不如说更像一个集成工程师。

我是胶水，是代理，也是几个系统之间的集成点。

Deep into the Jungle

十月份，公司和一家药商签订了试运营合同。我们要做的是一个机器人自动抓取药品、打包并扫码的场景。

如果项目顺利，公司希望进一步拿下更多门店，通过真实业务证明整个方案的落地能力，也完成内部常说的所谓“真实数据飞轮”。

整个公司对这个项目都很重视。

当时整个软件部门加起来只有七个人。在还要支撑其他项目的情况下，我和另外一个同事作为主要软件人力投入到了这个项目中。

从那之后，一直到我离职，它几乎贯穿了我的整个工作经历。

所以如果真要给这一年的工作找一条“主线”，应该就是它了。

项目刚开始的时候，方向其实非常模糊。

我们知道需要一个云端服务对接客户系统，再通过某种通信方式将任务发送到机器人端；端侧拆分任务、调用算法动作，最终再把执行结果同步回云端。

大的框架谁都知道。

但具体需要哪些组件、使用什么通信协议、设备如何初始化、云边状态如何同步，在项目初期并没有真正明确的方案。

这也是我第一次觉得有点不对劲的地方。

母公司进入机器人行业已经很多年，我们又是从母公司里孵化出来的子公司。于是我曾经问过：以前有没有类似的方案或者架构可以参考？

答案是：没有。

领导给了几个大的技术方向，剩下的大量工作——服务怎么拆、组件之间怎么通信、架构图怎么画——基本都由我和另外一个同事自己往下设计。

这和我以前的工作方式非常不一样。

过去，一个项目往往会有 Tech Director 或架构师真正负责项目骨架和关键边界。到了这里，很多原本我认为应该由技术负责人明确的东西，都落到了执行的人身上。

我的直属领导更多负责给方向、提风险点和跟进进度，但很少真正进入关键技术决策以及后续结果的承担。

当时我第一次意识到，“很多事情都可以自己决定”听起来很自由，但自由的另一面，是很多本该有人负责的问题也会落到你手里。

经过大概一个 Sprint 的 R&D，我们最终确定，我主要负责端侧，另外一个同事负责云端。

端侧对我来说完全是一个新领域。

和可水平扩展的云端应用不一样，我的程序和算法共享同一块物理硬件。算法天然希望拿到尽可能多的计算资源，所以我的服务需要尽量小、尽量稳定，只完成自己真正需要完成的事情。

除此之外，还有很多以前从来没有认真面对过的问题。

当一台物理机器人可能被客户、现场人员甚至第三方接触时，机器上的身份信息和凭证该怎么保护？

弱网甚至断网情况下，机器人本地执行状态和云端业务状态怎么保证最终同步？

任务重复下发怎么办？

状态机怎么划分？

程序重启后怎么恢复？

这些都是当时真正让我 struggle 的东西。

Full commit

项目交付时间非常紧。

我们一边生产一个新的机器人型号，一边完成软件和算法开发。国庆回来后基本框架确定，十一月份就进入了持续不断的开发和调试。

从十一月到十二月中旬，如果我的记忆没有错，我和另外一个同事连续四十多天没有真正休息过。

到了十二月底，我的调休已经积累了将近十五天。

那段时间的生活非常简单。

起床，上班，回家，睡觉。

第二天重新开始。

四十多天的高压工作当然很累，但现在回头看，我又没有办法简单地说自己当时只有痛苦。

因为这是我进入公司以后，第一个真正从零参与搭起来的项目。

我想看见它落地。

我想知道，我们画在架构图里的那些东西，最后能不能真的变成一台在现场完成工作的机器人。

所以那时候的我确实是愿意投入的。

与此同时，这几个月也不只有这一件事。之前项目的现场问题、硬件控制 SDK 升级、配套遥操软件、SKU 采集工具、给测试使用的模拟订单软件，都在并行推进。

我当然疲倦。

但那时还没有认真想那么多。

我只是开始隐隐约约感觉到，有一些地方似乎不太对。

This Is Not OK

十二月到一月之间，一个之前搁置的韩国客户项目突然重新插了进来。

当时药商项目下个月就要交付，但几乎没有多少预先沟通，我又临时被拉去支援另一个项目。

那是我第一次比较明确地意识到，这里的软件开发缺乏真正意义上的计划。

交付目标是一个按摩机械臂。

现在回头看，整个过程都让我觉得非常奇怪。

先不谈临时赶工的软件。作为一个最终会直接作用在人身上的机械臂应用，我们没有进行完整的真人测试，只做了大概三天模拟测试，机器就被发到了海外。

当地的组装和调试交给了我们的测试同事，但他提前明确说过自己无法进行外语沟通。

最后现场沟通陷入尴尬，我实在看不下去，只能一起加入远程沟通和调试，再配合算法同事想办法让应用真正启动起来。

后面项目经理写的操作指南，对方也不能完全理解。

双方在一个周末做了一次简单交流以后，这件事情逐渐杳无音讯。

我在会议里能够明显感受到客户的尴尬和不满。

但事情就这么过去了。

前面很多问题，我其实一直都在给它们找解释。

Startup 就是这样。

机器人行业就是这样。

公司还小，流程不成熟很正常。

但到了这件事，我第一次发现，有些事情不能再简单用“创业公司比较乱”来解释。

一个混乱的软件开发过程，一套准备不足的交付和支持计划，以及在我看来非常值得质疑的安全边界。

那是我第一次对这家公司产生非常深的失望。

我甚至开始问自己：

为什么我要来到这里？

Stay Professional，Stay Proud

到了第二年一月，药商项目终于进入正式入场阶段。

负责云端的同事当时需要休陪产假，于是在几周时间里，我要临时接住几乎整条软件链路：开发、对接、部署、现场问题。

与此同时，客户又在临近入场时增加了溯源码回传需求，我还需要接着同事的代码把功能补进去。

那段时间同样非常煎熬。

但最后，我和算法同事完成了部署，也配合客户完成了现场调试。

那是我第一次真正一个人把整条链路从头到尾理清楚。

Cloud、Edge、任务下发、算法执行、状态同步、现场环境——所有这些东西不再只是架构图上的框，而变成了我真正理解并且能够排查的系统。

我扛住了。

也真的交付了。

当时的我甚至因此形成了一个有点倔强的想法：

项目可以混乱，管理可以不专业，但我要保持我的专业。

后来回头看，这句话可能就是我接下来几个月挣扎的开始。

Nothing Left to Give

Become the Consultant

经历了年前这一系列事情之后，春节期间以及年后的一段时间，我陷入了非常强烈的痛苦。

每天坐在办公室都有一种如坐针毡的感觉。

到了这个时候，我已经开始意识到，我和这里的价值观存在非常大的冲突。

混乱的管理和开发环境不是某一个项目偶然造成的，也不是公司忙完这一阵以后就会自然消失的东西。

它们本身就是这里运行方式的一部分。

Founder 在年会上讲的很多内容，对当时的我来说只剩下一种空洞感。当他说我们是一家“独角兽公司”的时候，我甚至忍不住觉得有点荒谬。

这就是所谓的独角兽公司吗？

更让我痛苦的是，我发现自己既无法控制这个环境，也几乎没有能力真正改善它。

靠人去填流程的坑，去做 Ticket 之外临时出现的事情，是这里再正常不过的工作方式。

经历了年前长期高压开发以后，我开始怀疑：我为什么还要继续这样投入？

我不认同这里。

我也不觉得自己属于这里。

那段时间我经常晚上和 AI 讨论这些问题。

后来我给自己找到了一种勉强能够继续工作的办法：

把自己在精神上异化成一个技术顾问。

我告诉自己，只输出自己认为专业的判断。

如果一个技术决策在我看来很差，我会表达意见；但如果领导或者其他人坚持另一种方案，我不再试图把所有事情都扛到自己身上。

建议给到。

决定不是我做的。

结果也不应该永远由我承担。

我需要主动放弃一部分对项目的心理所有权，换取一点精神上的平静。

否则我迟早要跳到办公桌上和所有人来一场拳击搏斗。

Something I Can Still Believe In

精神状态不好归不好，工作还是继续。

因为前期试运行取得了一定成果，三、四月份，我们又陆续和另外两家药商签下了合同。

接下来还有解决方案完善、SKU 数据管理、模型升级以及不同客户业务接入等工作。

考虑到自己的状态和个人偏好，我主动向领导申请，希望更多做偏技术的需求。

所以后面的业务接入，我逐渐不再作为主要负责人，而是由其他同事沿着我们之前搭好的架子继续推进。

我的工作则更多转向机器人管理平台的端侧能力。

从最开始的明文密码，到后面的 mTLS 证书接入、MQTT 凭证轮转、KEK 加密后的凭证存储等等，我一路参与了端侧认证和凭证体系的迭代。

这可能也是后半段工作里少数还让我比较有掌控感的部分。

每一个版本，我都会写完整的架构设计和 SOP。

从 0.1 到 0.5，我把端侧架构每一次变化都完整记录了下来。

至少在这些事情上，我仍然希望自己留下的是一个以后别人能够理解、能够接手、能够继续维护的系统。

Fine, Whatever

但在这个过程中，我抱怨得越来越少了。

或者换一种更准确的说法：

我开始麻木了。

一个很大的 PRD，却没有具体 AC 的用户故事？

Fine.

每天明明更新了 Ticket，项目经理还是要单独抓着问一次进度？

Fine.

没有 CI 模板，没有 CD 支援，部署主要靠手工？

Fine.

现场支援依然高度依赖远程桌面？

Fine.

很多事情我已经不想再问“为什么”。

因为我逐渐明白了一件事：

在上一家公司里，我认为理所当然的很多制度和工程条件，并不是天然存在的。

好的工程环境、基础设施和工程文化，本身就是组织长期投入的结果。

以前的我只是坐在一艘成熟的船上，享受着其他人已经建好的甲板、发动机和航海规则。

现在我第一次坐在一条临时搭起来的木筏上。

很多以前认为理所当然的道理，在这里并不生效。

而当你和已经习惯坐木筏的人描述“船”是什么样子时，他们未必会觉得那是一种进步。

他们可能只会觉得：

太重了。

不够敏捷。

你是不是想得太复杂了？

也许这并不存在绝对的对错。

但我越来越确定，这不是我想长期工作的方式。

One Last Hope

中间公司经历过一次领导层调整。

那时候公司开始讨论更大规模的机器人交付，甚至是百台级别。

我当时其实重新产生过一点期待。

因为在我看来，一台机器人能够落地，只能说明技术可行。

一百台机器人能够稳定运行，则完全是另一个工程问题。

不可能每一台机器人旁边都站着一个软件工程师。

日志收集怎么办？

远程诊断怎么办？

OTA 怎么做？

部署、配置、身份、凭证、版本管理怎么办？

我想，既然真正要走向规模化交付，公司总该开始认真投入这些基础设施了吧。

这些东西确实被写进了日程。

但我始终没有看到真正的建设计划。

没有完整的架构设计，没有清晰的技术选型，也没有真正明确谁负责把它建设起来。

最后我看到的，只是一份极简的 Todo List。

那一刻，我对这里的工程建设基本死心了。

也许他们觉得这些事情现在不重要。

也许他们觉得现有方式已经足够。

也许在他们看来，我们真正应该做的只是不断完成功能。

无论是哪一种，我都突然觉得：

好像已经没有什么值得继续期待的了。

Hollow

最后两个月，我感觉自己进入了一种很奇怪的“空心”状态。

我依然每天上班。

依然参加会议。

依然完成任务。

但我已经不太关心会上究竟在讨论什么，也不再主动尝试理解每一个 User Story 的业务细节，更不会像以前一样在意同事 PR 里的每一个设计问题。

一月份的我会想：

我要把整条链路搞清楚。

最后两个月的我想的更多是：

把分给我的事情做完就行。

交付计划对真正执行的人来说，很多时候只有一个模糊的日期，没有明确的启动仪式，也没有清晰的结束点。

人就这样围着机器人轮班。

与此同时，每天还要应付另外一套项目管理 KPI。

开发已经在 ONES 这种类似 Jira 的系统里填写了任务和时间，项目经理却更习惯维护一张巨大到打开都困难的 Sheet，于是同样的信息还要再人工填写一遍。

每个人同时背着多个项目。

年后，公司也正式进入了所谓的 Agent 时代。

所有人都在说代码质量重要，但现实是大家已经没有足够时间认真做模块设计和实现，于是大量代码开始由 Agent 快速生成，然后再指望其他人 Review。

有时候我看到那些连生成出来的 Unit Test 都明显没有自己跑过的代码，会忍不住想：

哥们，你自己都没看，还指望我帮你看？

要不干脆 Agent Review Agent 算了。

整个仓库变成黑盒，说不定反而更符合这个工作方式。

当然，讽刺的是，最后两个月我自己也开始大量依赖 Agent 生成代码。

我当然还会人工 Review。

但相比以前，我已经很少再从头开始认真写一段东西。

所以后来我也意识到，这不是简单的“别人不认真”。

在一个所有人都不断被压缩时间、被多个项目同时拉扯的系统里，认真本身会变成一件越来越昂贵的事情。

而我最终也开始用和他们相似的方法工作。

没有了写代码本身的乐趣。

没有团队共同完成事情的成就感。

也没有归属感。

一月份交付成功时的满足早就已经淡去了。

到了那个时候，离开的理由其实已经积累得足够多。

七月中旬，家人的身体又出现了一些问题。

那不是我离职的全部原因。

更准确地说，它结束了我最后一点拖延。

每天忙于参与低效率的日会，应付不知道从哪里又要打来的电话让你远程处理的杂事，用agent生成着看上去似是而非的代码，我感觉自己已经游离在这个尘世之外，成为了孤魂野鬼，什么都感受不到，什么也不关心。

我突然觉得，我已经没有理由继续把自己的时间投入到一个自己不再认同、也已经不再期待的地方。

于是我决定离开。

回顾

现在回头看，如果只按照一年前给自己设定的职业目标来衡量，这一年很难算成功。

我进入了一个自己并不熟悉、也并不成熟的赛道，走进了一片荒野和丛林，在里面尝试了一年，然后选择离开。

但如果把时间尺度拉长一点，我又觉得这一年至少让我看清了一些以前没有真正想明白的事情。

相信自己的工程直觉

第一，我应该更加认真地对待自己的工程直觉。

这不是说以后看到一个 README 写得差，就应该马上判断一家公司不值得待。

真正让我意识到的是：如果一些工程问题持续让我感到不舒服，我不应该永远用“Startup 都这样”“行业特殊”“现在只是暂时的”去替它寻找解释。

有些问题确实只是暂时的不成熟。

但有些问题反映的是一个组织根本不认为它是问题。

这两者之间的区别，我以前没有真正体会过。

入职第一天感受到的那些诡异，后来其实都以不同形式重新出现了。

而一些当时让我觉得明显不合理的技术设计，后来也真的产生了我担心的问题。

以后我未必永远判断正确。

但至少我应该更认真地听自己的判断。

我要去一个工程能力本身有价值的地方

第二，我需要进入一个真正尊重工程文化，同时让工程能力和工程贡献能够成为核心资本的公司。

我和同事以前开玩笑说，在这种强算法、强科研背景的公司里，软件工程师像外包，又像二等公民。

融资 PPT 上的主角永远不会是我们。

这当然只是一句带情绪的玩笑。

但它背后真正让我在意的是，一个组织究竟把什么视为自己的核心能力。

在我看来，公司给软件和基础设施投入的资源，远远不足以支撑他们自己描述的规模化解决方案。

因为：

一台机器人落地，只能证明技术可行；一百台机器人落地，是一个完全不同的工程问题。

如果一个组织的核心叙事、资源分配和长期建设都不把工程能力视为重要资产，那么作为一个工程师，再努力也很难把自己的专业积累转化成真正长期的优势。

这不是我要长期待的地方。

这并不是说我要和算法同事产生什么对立。真正让我难受的是，我逐渐意识到，我们虽然在做同一个产品，却仿佛并不生活在同一个组织叙事里。算法是融资故事里的核心，而软件更多负责把这些能力串起来、接入客户、处理现场问题，最终让方案真的跑起来。但这些工作很难成为公司讲述自身价值时的主角。

更让我不舒服的是，我后来看到公司专门为外包人员开发的 Agent 监控系统，以及绩效稍有下降便出现的辞退警告。那一刻我很难不去想，在这种组织逻辑里，劳动者究竟被当成了什么。

我第一次非常具体地感受到一种工具化和异化。
我甚至会忍不住想：如果有一天我不再好用，我和那些“耗材”究竟有什么本质区别？

保护自己的长期生产能力

第三，只是一味加班和努力，并不能让我得到自己想要的生活。

早上睁眼上班，晚上回家闭眼睡觉。

第二天重复。

如果只是短时间冲刺，我并不排斥这种状态。

但如果长期如此，它最终消耗掉的不只是体力。

还有好奇心、学习欲望、写代码的兴趣，以及一个人在工作之外继续成长的空间。

我需要自己的时间。

需要做一些真正属于自己的项目。

需要研究新的东西。

需要偶尔只是因为“我想知道它怎么工作”而折腾一个晚上，而不是因为第二天必须交付。

我的目标不是证明自己能够连续工作多少天。

而是希望自己还能在这个行业工作很多年。

所以我要保护的不是某一天的产出，而是自己的长期生产能力。

积累能够带走的东西

第四，我需要更加重视职业能力的可迁移性。

我并不后悔当时进入机器人行业的选择。

如果没有这一年，我不会知道自己是否喜欢它，也不会真正理解 Cloud、Edge、算法、硬件和现实业务结合以后是什么样子。

这本身就是一种经历。

但回过头看，在去年找工作时我担心的很多问题，到今天其实并没有真正解决。

我依然没有积累足够完整的全栈经验。

Agent 这一轮新的技术变化，因为长期工作压力，我也没有多少时间真正深入。

从职业市场的结果来看，我只是进入具身领域做了一年的尝试，并在一条相对更窄的道路上投入了一段时间。

以后我并不要求每一份工作都必须直接给下一份工作铺路。

但我希望几年之后回头看，自己积累的是能够带走的东西。

是换一个公司、换一个业务甚至换一个行业以后，依然能够继续产生价值的能力。

工作对我意味着什么

写到这里，我发现自己真正需要重新想的，也许已经不只是“下一份工作该找什么”。

而是：

工作对我到底意味着什么？

如果还是在计算机行业，但每天的工作已经让我失去对计算机本身的兴趣，那么继续做下去又有什么意义？

对我来说，工作当然首先是一种谋生方式。

我需要工资，需要维持自己的生活，也需要在现实社会中获得足够稳定的位置。

但它好像又从来不只是这些。

从小时候第一次接触电脑，到后来因为好奇开始折腾软件，再到最后真的靠它谋生，计算机这件事已经沿着我的成长一路延续到了现在。
在一开始的时候我甚至都没想那么多，我只是觉得我喜欢玩电脑，然后将来如果能通过电脑能赚钱就好。

兴趣变成技能。

技能又变成劳动。

而劳动反过来继续塑造我。

这一年让我知道，我可以在非常混乱的环境里工作。

我可以扛压力。

可以在没有人兜底的时候把一条链路真正做出来。

也可以学会接受那些我不喜欢、甚至不认同的事情。

但它也让我知道，我非常在意工程上的秩序和专业。

我需要一定程度的自主权。

我希望能够认同自己正在做的东西。

我不愿意长期把生活全部交给工作。

更不希望有一天，我只是机械地完成 Ticket，然后等工资到账。

所以对我来说，工作可能也是一种认识自己的方式。

我通过劳动确认自己能够做什么，也通过一次次不舒服、挣扎和选择，知道自己不愿意变成什么样的人。

也许这才是这一年真正留给我的东西。

结语

这一年的故事也算是结束了，短暂休息一段时间后也要继续考虑工作了，我感觉自己对这一个行业的热情并没有消失还，我还是希望能进入一个工程文化浓厚的环境进行进一步的学习和实践。 虽然对于公司本身已经没有任何留恋了，但是当时投入的心血，和部分同事的交集在我心里是真的留下来的闪光。

一年前，我带着期待走进了那片丛林。现在我从里面走出来，身上多少带着一点伤，也带走了一些真正属于自己的东西。下一站会是什么样，我仍然不知道。也许不会更好，也许找工作的过程仍然会很难。

但至少，我还没有失去期待。