AI 时代,工程师该把什么练得更扎实?

朋友给我出了个题，让我写一写“AI 时代工程师如何提升技能和生存”。

题目确实值得写，但也确实够大。软件、硬件、机械、工业设计，研发、安装、维修……工程师的类型和工作范围太广，有点写不起，无从下笔。

本想再拖一拖，但前阵子我安利了智谱的福利，他后来应该参加了。这羊毛推荐双方都能拿到赠送的 token，算起来，我也领了他的鸡蛋。“一代人有一代人要领的鸡蛋”，领完总得交点作业。

真要回答，我想先把“生存”这么大的词放一放，看看工程师每天到底在做什么。

先把手上的活拆开

做研发的人，要理解需求、设计方案、形成输入输出、做验证确认，还要处理设计变更和转产。做安装、维修和运维的人，更多时候要面对具体设备、故障现象和现场条件，沿着技术资料一步步排查。

这只是粗略的拆法。工程师既要查资料、想方案，也常要动手，最后还得让方案经得起实际条件的检验。我熟悉的是医疗器械研发，下面主要从这一侧谈自己的使用经验，不敢代表所有工程师。

如果只把工作拆成“查资料、设计方案、做测试、写报告”，很容易得出一个判断：这些 AI 都能帮忙，甚至能做得很快。

但再往下问一层：为什么要查这份资料？这个方案要解决谁的问题？哪些条件不能妥协？做到什么程度才算通过？

工程经验就在这些地方开始起作用了。

一份报告写得完整，和它足以支持设计决策，中间还有距离。一个零件能加工出来，和它在预期工况下可靠，也隔着不少工作。AI 可以把前面的动作加快，后面的判断仍然要有人作出，并拿证据来支撑。

所以，我想先捋清楚自己工作的核心价值，再找 AI 能帮忙的地方。否则，工具换了好几轮，手上可能只是多了几份漂亮却似是而非的文档。

我先把 AI 用在资料上

我现在用 AI，一个主要用途就是读文献、梳理材料。

之前Claude Science 用到第三天，我把一周额度烧完了里写过，我用科研工作台整理文献、做综述、搭模型，再根据结果回头修改，不用把每一步割开来做。

工程师要读的行业知识、标准、法规和论文，也可以先借助 AI 梳理，找到值得继续追的线索。

之前我把它说成“摆脱傻傻读文档”。细想一下，这话说得太满。

有些材料可以先看摘要，有些地方恰恰不能省。标准条款适用于什么范围，论文用了什么样的样本和试验条件，某个结论有没有前提，这些都可能决定一个方案能不能用。AI 帮我缩小阅读范围之后，关键处仍然得回到原文。

我通常会要求它把出处、适用条件和暂时无法确认的地方一起交出来。拿到总结之后，我才知道该往哪里核对。

另一块是自己的技术资料。

我一直有整理技术文档的习惯，以前更多是在保存文件。现在可以往前再走一步，把这些资料变成一个 Agent 能参与工作的知识库。这里说的智能体（Agent），就是能在授权范围内读取文件、调用工具、执行任务的 AI 助手。

我关心的也不只是“能不能搜到”。如果要复用一个旧方案，我还想知道：它当时解决什么问题，为什么这样选，后来改过哪里，哪些条件已经失效。

举个设想：翻出一份旧测试报告，AI 很快找到了一个参数。但这个参数来自早期样机，后续版本已经改过。只看搜索命中，它答对了；拿去指导今天的设计，却可能用错了。

所以，资料里得能分清当前条件和历史情况，保留修改原因，并把结论连回依据。

Git 这类版本控制工具可以管理适合文本化的技术笔记、脚本和方案说明。但只有实际提交、写清修改内容，变更才会留下；图纸、二进制文件和受控文档，仍须按各自要求管理，不能用 Git 代替文控流程。

AI 能查历史记录的前提，是这些历史真的被留下来了。

这件事想通以后，整理资料就有了更具体的目的：下次遇到相似问题，能少走一段已经走过的弯路。

一次提醒，能不能留下来

工程师的工作里，总有一些反复出现的需求。撰写报告、资料比对、数据分析、按模板形成初稿，这些都值得试着交给 AI 或脚本。

但“可以标准化”离“放心自动执行”，还有一段磨合。

从给 Agent 一台电脑开始里写过自己的体验：任务刚开始时，我经常说不清所有要求。第一版出来，才发现某份资料不该用于这次判断，某个步骤会破坏原来的工作方式，某种输出看起来完整，下次却接不上。

这时候，人和 Agent 一起做一遍，很有价值。它暴露了我原本没有说清楚的要求。

如果下次还得从头校准同一件事，这次经验就没有留下来。我更希望把反复出现的纠偏写进规则、模板、脚本或测试，让下一次执行能用得上。

拿排障作一个设想：先让 AI 根据当前有效的手册整理排查路径，列出还缺什么现场信息；工程师核实设备状态，再决定下一步。等输入、判断条件和异常处理都清楚了，才考虑把其中重复、低风险的部分自动化。涉及现场操作和安全的步骤，仍要按既有规程执行。

这也要求我把任务说清楚：给什么资料，做到哪一步，什么结果算可用，遇到什么情况必须停下来。

这有点像计划—执行—检查—改进（PDCA）：做一次，把修正留下来，下次再检验。AI 能加快循环，经验能否积累仍取决于自己怎样处理反馈。

活交出去了，判断力怎么练？

前面一直在说怎样把经验留下来。但如果经验还不够，拿什么去判断 AI 做得对不对？

麦肯锡的《AI 时代如何培养下一代专家》讨论了这个问题。查资料、写初稿、做初步分析，也曾是新人练习判断的机会。如果这些任务交给 AI 之后，没有安排新的练习与反馈，新人可能交出了成果，却没弄懂它为什么成立。

工作年限也不能保证我看得出问题；遇到不熟悉的领域，我同样是新人。

文章给出的“答案钥匙”模式，是员工先尝试，AI 再给这次尝试以反馈，随后由员工和经理一起讨论差异。这里不能省掉人的复核，更不能默认 AI 的答案就是对的。

我觉得可以先挑一小段需要练习的任务，比如对一份报告作初步判断：先写下自己的理由，再看 AI 提出了什么不同意见，带着分歧查依据，必要时请有经验的同事复核。不必把所有工作都重复做一遍，但得留一些自己先想、自己解释的机会。否则，工具用得越来越顺，离开它能判断多少，还是不知道。

不会编程的人，多了一种动手方式

还有一块变化，对我尤其直接：软件实现的门槛低了。

我做过多年医疗器械研发，但并不具备独立从头写软件的能力。过去，有些想法只能停在“要是有个小工具就好了”。现在可以先借助 AI 做出一版，再拿到实际使用中去改。

我之前用 Vibe Coding 做过一个 macOS 菜单栏小工具，叫 AIUsageBar，显示 Codex 和 Kimi Code 的剩余额度。

需求很小：准备干活的时候，别等调用失败了才发现额度不够，也别总为了查额度打断当前工作。

这个需求还有个细节。短时额度看着充足，周额度可能已经耗尽。如果只显示一个好看的百分比，照样会误判。于是，工具要在周额度成为瓶颈时，把它单独显示出来。

这些内容写在 AIUsageBar：给 Codex 和 Kimi 用户的极简额度看板里。它是我个人维护的免费小工具，不是商业产品。对我的意义更朴素：过去只能忍着的一个小麻烦，现在可以试着自己做工具解决。

AI 能帮我写代码，但要定义什么需求、屏幕上该显示什么、怎样才不误导使用者，得在使用中不断弄清楚。

对原本偏硬件的工程师来说，这确实多了一种动手方式。可以尝试给现有设备配一个数据处理脚本，做一个测试结果看板，或者把反复手工操作的步骤串起来。专业经验有机会更快地变成能运行的东西。

但我不想把它说成“现在人人都有软件能力，任何想法都能实现”。代码能跑之后，还要看它处理异常是否可靠、有没有权限和安全问题、能否继续维护。牵涉真实设备和安全的场景，更不能拿演示原型代替工程验证。

AI 降低了开始做的门槛，交付是否可靠，仍然需要一项项验出来。

这也让我重新理解最小可行产品（MVP）：原型能低成本试需求，但持续使用、付费和后续维护，都得另外验证。

回到朋友的题目，关于“生存”，我给不出一个答案。会用几个 AI 工具，也不足以推断一个岗位未来会怎样。

我最初想到的答案是：AI 能放大个人能力。但接着说“就怕自己没有想法、没有方法”，又太轻巧；一个人能做成什么，还受资源、组织和客户约束。

在80%的人说AI提效了，只有6%的公司赚到了钱那篇讨论 AI 提效与企业价值的文章里写过一组研究：个人做得更快，未必会让企业得到更多价值；重新设计工作流的组织，更多数获得了价值。这些是受访者自报的关联，不能证明因果，也不能拿来预测某位工程师的前途。

工作流、资料权限和结果验收，往往需要团队一起决定，不是用一个工具或技巧就能解决。

把目光收回到自己，我能先做的反而具体了：挑一个最近反复碰到的小麻烦，用 AI 一起做完，核对结果，再把有效的做法留下来。比起追逐日新月异迭代的模型与智能体，这更容易看见自己缺什么、该补什么。

AI 能帮工程师把想法做出来；把问题找准、把结果验清、把经验留下来，也值得花力气练。