我是怎么从施工员转到开发的

只看我现在在做的事情，可能会觉得这条线还算正常：做过 AI 生图相关项目，后面写 Python，转到 .NET 做后端，也碰过 Vue、Python 后台和智能体。

但把时间往前拉一点，这条线其实没那么“标准”。

我正式入职开发是在 2023 年。在这之前，我做的是工地施工员。

所以这篇文章想写的，不是励志故事，也不是转行经验帖，更不是想把自己包装成一个很会规划的人。它更像是一篇起点说明：我原来是从哪里出发的，后来为什么会走到开发这条路上，以及我最早接触的开发工作到底是什么。

转行之前，我在工地上班

我以前的工作是施工员。那段经历和现在坐在电脑前写代码，表面上看差得很远。

工地上的工作节奏很直接，很多事情都围着现场转。你每天接触到的，基本都是进度、协调、落地、返工、沟通这些特别具体的东西。很多问题不是放在那里让你慢慢思考的，而是已经摆在眼前了，你得先把它接住。

现在回头看，那段经历虽然跟开发不是一条路，但也不是完全没有留下东西。

至少有两点我觉得是带过来了的。

第一点是，我对“问题到底卡在哪”这件事会比较敏感。工地上很多事情不能只看表面，表面看起来是材料没到、流程卡了，实际可能是前面某个环节就没对齐。后来写代码也是一样，很多 bug 最后都不是出在报错那一行，而是更前面的设计、状态或者数据流转出了问题。

第二点是，我不太习惯只停在“差不多能用”这一步。因为现场的很多东西一旦含糊，后面就会不断返工。这个习惯带到开发里以后，我会比较自然地去想：这个功能后面还能不能继续改，这个流程出问题了以后好不好排查，这段逻辑如果业务再复杂一点会不会开始失控。

当然，这些都是后话了。当时的我其实也没有那么多总结。那时候更真实的状态是：我慢慢感觉自己想换一个能长期积累的方向。

我为什么会转到开发

说实话，我不是那种很早就知道自己以后一定要做技术的人。

转到开发，也不是因为某一天突然热血上头，下定决心改变人生。真要说得现实一点，更像是后来我才意识到，自己还是想做一件能持续往下走、而且做久了会越来越有积累的事情。

我后来会愿意留在开发这一行，一个很重要的原因就是：它的很多东西是可以沉淀下来的。

你今天解决过一个问题，明天再碰到类似的问题，处理速度就会不一样。你这次做过一个接口，下次再做业务链路的时候，对数据、状态、异常这些东西的敏感度也会不一样。很多经验不会立刻变成什么了不起的成果，但它会一点点留在你后面的判断里。

我比较喜欢这种感觉。

它不是那种立刻给你答案的行业，很多时候反而要靠不断补课、不断试错、不断复盘，才能慢慢把一件事做顺。但也正因为这样，它对我来说有长期投入的意义。

所以 2023 年，我正式开始入职做开发。

刚入行时，我接触到的第一个项目不是管理系统，而是 AI 生图

现在再回头看，我第一份开发工作接触到的方向其实挺特别的。

不是常见的后台管理系统，也不是传统企业站，而是 SD / ComfyUI 生图相关业务。

刚进去的时候，我对这块的理解其实很浅。那时候我会下意识觉得，这类项目的重点应该在模型、提示词、出图效果这些地方。毕竟从外面看，最直观的东西就是这些：图能不能出，效果好不好，风格稳不稳定，提示词怎么调。

但真开始做以后，我才慢慢发现，真实业务里的重点根本不止这些。

出图只是最表面的一层。真把这类能力接到项目里之后，后面马上就会跟出一堆问题：

• 用户发起任务之后，系统怎么接住
• 多个任务同时跑的时候，状态怎么管理
• 某个环节失败了，要不要重试，怎么重试
• 任务取消了以后，前后状态怎么收回来
• 模型和工作流不稳定的时候，业务怎么往下走
• 用户看到的不是“节点运行中”，而是一个完整功能，那中间这条链路到底要怎么补齐

这些问题一层一层冒出来以后，我对“开发”这件事的理解开始有了变化。

后来我才意识到，麻烦的地方，往往不是某个模型会不会调用，也不是某个参数怎么配，而是你怎么把这些能力接进一条能跑、能查、能补、能维护的业务链路里。

所以我后来再看 AI、生图、工作流这些东西时，关注点越来越不只是效果本身。我会更在意流程、任务、状态、异常和实际落地。

后面如果继续写这部分内容，我会单独把那段项目经历拆开讲。因为它确实是我整个技术路线里很重要的一个起点。

我的技术线，不是一开始规划好的，是工作里一点点长出来的

如果现在回头看，我后来接触的这些东西——Python、ComfyUI 插件、.NET、Vue、Python 后台、智能体——其实不是一开始就规划好的路线。

更像是工作往前推，问题一个个冒出来，我再顺着这些问题去补。

最开始是先接触 SD / ComfyUI 生图业务。再往后，因为工作里确实需要，我开始慢慢碰 Python，也写过一些 ComfyUI 相关的插件和流程工具。再后来接触到 .NET，才开始真正往后端这条主线上走，而且走着走着，.NET 也慢慢变成了我现在最主要的开发语言。

后面接触 Vue、用 Python 写一点后台、再到后来开始认真看智能体，也都是类似的节奏。不是先把一张技术路线图画好，然后一项项去完成；而是我先在项目里碰到事情，再决定哪些能力值得继续往下补。

我自己反而比较认同这种路径。

因为它没那么整齐，但比较真实。很多理解不是从教程里直接长出来的，而是从具体工作里、一点点补问题的过程中长出来的。这样走得慢一点，但很多东西会更扎实，也更容易知道自己到底为什么要学它。

为什么我想把这些过程写下来

我现在开始写博客，某种程度上也是想把这条线重新整理一遍。

一方面，这两年接触过的东西其实不少，但很多内容都散在项目里、对话里、临时处理的问题里。如果不专门停下来写一写，时间一长，很容易只记得结果，不记得自己当时是怎么理解、怎么踩坑、怎么慢慢走过来的。

另一方面，我也不太想把这些文章写成单纯的“技术展示”。

我当然知道这个博客多少会承担一点职业表达的作用，尤其是别人可能会从简历、项目链接或者面试场景里点进来。但比起把自己包装成一个什么都会的人，我更想把做事情的路径写清楚一点。

比如一个项目最开始是什么样，我当时以为问题在哪，后来发现难的地方在哪，我补过哪些东西，哪些判断是后来才慢慢有的——这些内容在我看来，比一串技能词更能说明问题。

所以这篇文章就当作一个开头。

后面我会继续按时间线，把自己这几年做过的一些项目和问题慢慢写出来。里面会有 AI 生图、ComfyUI、Python、.NET、后端工程、支付状态、日志、异常处理，也会写到后来为什么开始重新看智能体。

如果有人刚好顺着这些文章一路看下去，大概也能比较自然地看见：我不是一开始就很清楚自己会走到哪一步，很多东西都是做着做着、补着补着，才慢慢连成了现在这条线。