> ## Content Index > Fetch the complete content index at: https://www.hubwiz.com/blog/llms.txt > Use this file to discover other available public pages before exploring further. # 为未来的技术变革做好职业规划 - URL: https://www.hubwiz.com/blog/future-proofing-my-career-for-the-next-decade-of-tech-shifts/ - Published: 2026-08-06T16:35:04.000Z - Updated: 2026-08-06T16:35:04.000Z - Description: 我用这些日常习惯、核心人类技能和技能提升策略来保持自己的竞争优势。 - Author: admin - Tags: JOB MARKET, #Import 2026-10-14 14:41 让我们坦诚相待：围绕 AI 取代技术职业的恐慌令人精疲力竭。每周都有新模型发布，有头条宣称软件开发的终结，或者有来自 Anthropic CEO 的帖子声称传统工程岗位将在明年灭绝。 如果你在观看一个自动化代理在几秒钟内生成一个可运行系统时，感受到那种隐隐的焦虑，你并不孤单。一个更清晰的事实已经浮现：我们工作的*性质*正在发生根本性变化。 几年前，工程师价值的一大部分与语法精通、熟记精确的库实现、编写无休止的样板代码，或手动优化常规流程相关。而今天？这些工作正在迅速变成商品。 你的公司很可能已经通过你的工具栈向你提供了 Claude Opus 或顶级 GPT 模型的使用权限，最可能是通过带有月度 [token](https://medium.com/data-and-beyond/what-are-tokens-and-why-is-it-costing-you-money-26e4bc9685dc?ref=hubwiz.com) 预算的 GitHub Copilot。他们为订阅付费。他们期望你使用它。而且，悄然地，他们中有些人开始质疑这是否真的是继续雇佣你的充分理由。 这并非意在制造恐惧。这只是工程组织内部此刻正在发生的对话。 我的策略不是试图在编码上胜过 LLM 或跑赢它。那是一场必输的游戏。相反，我未来十年保持相关性的计划归结为一个简单的转变：**在思考、架构设计和对齐真实人类问题方面超越机器。** 虽然本文以 AI 工程职业作为主线主题，但这适用于所有技术职业，如数据工程师、软件工程师等。 ## 1、实际正在发生什么？ 亚马逊建立了一个名为 **KiroRank** 的内部排行榜，用于追踪各工程团队的 AI 使用情况。尽管在员工通过让 AI 代理运行毫无意义的任务来虚增使用分数（员工称之为 tokenmaxxing）之后，它于 2026 年 5 月 29 日下线。 这不仅仅是一项生产力举措。这是一个排名系统。当裁员来临时，这些数据可供管理层使用。当进行人员编制决策时，排行榜底部的人很容易成为被指认的对象。 但这里有个让"多用 AI"叙事变得复杂的部分。Uber 在四月份就烧光了其 2026 年全年的 AI 编码预算。到三月份，**84% 的工程师采用了 Claude Code。** 大约 70% 的已提交代码来自 AI。而且 Uber 的 COO 公开表示，token 使用量与向用户交付的有用功能之间没有直接相关性。 Token 消耗量不是衡量标准。输出质量才是。 ![None](https://www.hubwiz.com/blog/content/images/2026/08/1-EbfoI5rLhaKAE-n4OdijTw.png) 一个运行**智能体检索工作流**、针对真实测试集评估其结果、捕捉到引用层中的幻觉模式、并交付一个在生成环境中真正经得起考验版本的 AI 工程师，正在做一件自主运行的模型尚无法端到端完成的事情。而一个烧掉同样的 token 生成样板代码却不经审查就提交的工程师，说实话，在大规模场景下是一种负担。 大多数人没有追踪到的替代模式比大规模裁员更为微妙。一位工程师描述了他们公司的招聘算法：过去是每 50,000 名用户配一名中级 AI 工程师。现在变成了每 150,000 名用户一名。收入上升。人员编制持平。那些没被录用的人从未被计算在内。这才是真正的转变。不是大规模解雇，而是招聘放缓，更小的团队做更多的事。在发出任何录用通知之前，门槛更高了。 ## 2、"证明你的价值"的对话已经到来 大多数人认为这场对话发生在招聘阶段。事实并非如此，至少现在不是。它发生在一对一面谈中。在架构评审中。在冲刺回顾会上，有人会问为什么 AI 生成的端点出现了没人发现的延迟回归。 在实践中，这意味着当你的团队决定是用 **LangGraph** 构建一个多智能体编排层，还是用纯 Python 编写一个更精简的自定义循环时，能够清楚说明这一权衡实际代价的工程师很难被取代。额外的抽象层带来的延迟开销。智能体调用子智能体时失去追踪线索的可观测性缺口。三步流水线在第二步失败且错误静默传播时的调试面积。以及对一个十八个月内变了三次的 API 的供应商依赖。 这种推理能力并非来自熟悉工具。它来自构建过足够多的系统，从而知道哪里会出问题以及问题出在哪里。 我想在这里稍微反驳一下。大多数 AI 工程日常工作并不是宏大的系统设计。更准确的描述是***问题定义者***：一个在让模型生成输出之前就知道正确输出应该是什么样子的人，并且即使输出看起来完全合理，也能判断出它何时是错误的。 ![None](https://www.hubwiz.com/blog/content/images/2026/08/1-b02pkLV8DD3yRGJAq1gzRQ.png) 最后这一点比听起来更难。LLM 非常擅长生成读起来自信且连贯的文本，你几乎无法区分。但一个**缺乏评估能力的工程师**，一个只是大致看看输出觉得没问题的人，恰恰就是那种在生成环境中被逮住的人——当检索系统开始返回无关的片段，而因为响应听起来仍然合理，三周都没人注意到。 ## 3、公司给你的工具及其真正传递的信号 中大型公司的大多数工程师现在都能通过雇主获得 GitHub Copilot Enterprise、Claude Opus 访问权限或直接 API 预算。GitHub Copilot Enterprise 让团队能够访问包括 Claude Opus 4.8 和 GPT-5.5 在内的前沿模型，用于真正的生产工作负载。 2026 年 2 月的一项调查发现，62% 的软件工程师在评估工作机会时将 AI 工具访问视为"必备项"。而前一年这一比例是 28%。公司内部进行的类比是十年前发放 MacBook 的做法。当一种工具对工作变得必不可少时，雇主就会承担成本。AI 算力已经跨过了这一门槛。 ![None](https://www.hubwiz.com/blog/content/images/2026/08/1-WBUaTcU8ryTHF6KZf11POQ.jpeg.png) 我仍在全球不同公司保持联系的朋友们每天都在使用这些工具。这种访问是真实的、普遍的，而且不会消失。 但"AI 作为福利"这种说法忽略了一个问题。黄仁勋曾公开建议，一位年薪 50 万美元的工程师每年至少应消耗 25 万美元的 AI token，并且 Nvidia 正致力于为其工程团队提供每年 20 亿美元的 token 预算。 > [*Token*](https://medium.com/data-and-beyond/what-are-tokens-and-why-is-it-costing-you-money-26e4bc9685dc?ref=hubwiz.com) *作为招聘福利，token 作为生产力信号。* 这对你意味着什么：工具的访问权限现在只是入场券。你用工具做什么，才是你积累优势或加速走向无关紧要的分水岭。 真正积累优势的工程师，是那些把这种访问用在真实问题上、批判性地评估返回结果、理解模型为什么出错、并把这种判断力带到下一个任务中的人。每一个这样的循环都是一次训练。而那些用 AI 生成自己并不完全理解的代码的人，是在把自己训练成依赖型，而不是能力型。 ## 4、我在日常习惯中实际改变了什么 ### 4.1 阅读事后复盘（案例研究）而不是教程 每天早晨，或者说实话每 2–3 天，我会阅读一篇工程事后复盘或架构决策记录。不是"2026 年十大 [向量数据库](https://satyamsahu671.medium.com/your-brain-is-a-vector-database-it-just-doesnt-call-itself-that-28a1bc68bee2?ref=hubwiz.com) 用于 [RAG](https://medium.com/data-and-beyond/rag-vs-mcp-what-every-ai-developer-actually-needs-to-know-3d8da413e61c?ref=hubwiz.com)"之类的文章。而是那些交付了 LLM 系统后诚实写出哪里出了问题团队的真实事后复盘。 原因很简单：教程教你的是顺利路径。而一篇来自某个团队的事后复盘——他们发现自己的 [提示缓存](https://pub.towardsai.net/prompt-caching-is-the-most-underrated-cost-optimization-in-llm-systems-53f6df9c76b8?ref=hubwiz.com) 策略在系统提示超过 2,000 token 时静默失效，导致评估分数以他们一个月都没察觉的方式下降——教会你在问题咬你之前该监控什么。 > [Anthropic 工程博客](https://www.anthropic.com/engineering?ref=hubwiz.com)、[Hamel Husain](https://hamel.dev/blog/posts/evals-faq/?ref=hubwiz.com) 关于 *LLM 评估的写作，以及* [Eugene Yan](https://applyingml.com/resources/?ref=hubwiz.com) *关于生产级 ML 系统的工作，是我最常查看的三个地方。这些不是泛泛的 AI 内容。它们是人们在记录什么东西坏了以及为什么坏。* ![None](https://www.hubwiz.com/blog/content/images/2026/08/1-dvwTZFqc-xreLNvjuQw-_w.png) ### 4.2 公开构建，即使产出并不完美 我发表的每一篇文章或参与的项目，都迫使我深入理解某个东西，直到能完全不用行话、以最简单的方式向一位中级工程师像喝咖啡闲聊那样解释清楚。这比单纯把它构建出来门槛更高。 如果我无法在不借助行话的情况下解释*为什么多智能体系统的故障模式与单智能体系统的故障模式根本不同*，那我就并不真正理解这种区别。把它写出来会暴露我自己推理中的漏洞。 > *还有一个被低估的次要好处：在一个变化如此之快的领域，一篇已发表且技术上准确的文章，其可信度信号比几乎所有其他东西都更持久。尽管互联网如今已充斥着 LLM 编造的、缺乏真实经验和视角的内容，而不是真实的人类写作，但我仍然努力留下我的足迹，以足够的可信度赢得读者的信任。* 六个月前一篇关于 RAG 评估模式的研究充分的文章，向招聘经理传达的关于你当前能力的信息，比同一时期的认证证书更多。 ![None](https://www.hubwiz.com/blog/content/images/2026/08/1-pohJXi0CMKi38RgRj8G1JA.png) ### 4.3 在真实问题上使用 AI 工具，而不是沙盒练习 我看到在提升 AI 工程判断力方面的工程师，不是在构建玩具演示，比如天气应用或井字棋游戏。他们在用 Claude Code 或 Cursor 处理有真实后果的真实功能，然后审视返回的结果。 > ***来自我自己工作的具体观察：*** AI 工具非常擅长生成 LLM 集成的初始脚手架。一个基础的检索链、一个路由器结构或一个工具调用骨架。而它们在以下方面持续不太可靠：在特定部署上下文中推理**提示注入**风险、为具有模糊真实性的检索流水线设计**评估策略**，以及在生产规模下为特定推理模式做出**成本与延迟的权衡**。 模型自信生成的内容与实际正确的内容之间的差距，正是你职业价值所在。知道何时推翻 AI 第一答案的工程师，才是交付更好系统的人。 ### 4.4 贴近评估，而不只是生成 这是大多数 AI 工程师没有尽早建立的习惯。生成 LLM 输出很容易。判断它们是否真的好，完全是另一项技能。 如果你能为一个 [RAG](https://medium.com/data-and-beyond/rag-vs-mcp-what-every-ai-developer-actually-needs-to-know-3d8da413e61c?ref=hubwiz.com) 流水线设计和运行严格的评估框架，并解读结果对生产就绪性的意义，你就在做自主 AI 代理尚无法可靠完成的事情。[评估不是感觉。](https://medium.com/data-science-collective/eval-driven-development-ai-evals-production-ai-systems-621c00cd2d31?ref=hubwiz.com) 它们是一个测试集、一个指标和一个阈值。如果你还没有为你拥有的系统构建过一个，那就是第一个值得培养的习惯。 ## 5、真正会复利积累的人类技能 我不愿称它们为软技能，因为这种说法低估了它们。它们很难，需要时间培养，它们是让架构决策得以落地、而不是每个季度都被重新争论的东西。 在动手架构之前问对问题的工程师，能避免昂贵的错误。这就是高级工程判断力。 ### 5.1 向非技术利益相关者翻译系统行为。 当一个智能体系统产生自信但事实上错误的输出时，必须有人向产品经理或客户解释为什么会发生、风险状况如何、以及实践中缓解措施是什么样子。如果你不能清晰做到这一点，只能抛出一句\*"模型幻觉了"\*，那么在任何面向客户的 AI 部署中，你都是一个负担。 ### 5.2 知道何时说"这个用例还不适合用 LLM"。 在 AI 组织中声誉最好的工程师，往往是那些曾反对某个 LLM 集成提议的人——因为数据质量不到位、延迟要求不切实际，或者没人定义过"好"是什么样子。这种判断力，这种出于正确理由放慢节奏的意愿，是真正无法替代的。 ## 6、值得投入的技能提升 vs. 伪装成焦虑 2026 年这个领域的大部分技能提升，都是伪装成职业战略的焦虑管理。每八周拿一个新认证并不会复利积累。它产生了进步的错觉，而底层判断力仍然肤浅。 对 AI 工程专业人士来说，真正合理的顺序路径是：从 LLM API 和提示工程开始，逐步进阶到 RAG 和向量数据库，然后是带编排框架的智能体系统，再然后是 MCP 和外部工具集成，最后是部署和 LLMOps。每个阶段都依赖前一个阶段。跳级会让后面的阶段更难推理，因为你缺少那些让抽象变清晰的思维模型。 你还需要真正的反馈回路。在自己的文档上运行一个 RAG 流水线然后断定它"感觉准确"，这不是评估。构建测试集、运行检索质量指标、并理解你的结果对你的生产用例实际意味着什么，这才是技能。 **关于认证的具体看法：** Gartner 预测，到 2027 年，75% 的招聘流程将纳入 AI 认证和技能测试。所以是的，它们会充当一个筛选器。通过筛选。但不要把通过筛选误认为拥有了技能。真正懂行的招聘经理会在技术对话的前二十分钟内看出差别。 **我诚实的看法：** 在 AI 技术栈的某一层深耕，胜过在五个层面浅尝辄止。选择评估框架、编排架构或 LLMOps。深入下去，直到你能在该领域做出真正的架构决策，而不仅仅是执行别人的决策。 ## 7、结束语 本文标题中的 "十年" 框架作为一种意图是诚实的，但作为预测可能过于自信。我能看清 3 年。再往后，我和其他人一样是在做有根据的猜测。 我确切知道的是，此刻保持冷静的工程师们共享一种特定品质。他们明白自己为工作带来了 IDE 中的模型所没有的东西。而且他们建立了每周都在不断磨砺这种理解的习惯，而不是等着行业稳定下来再行动。 职业不是由我们今天使用的具体工具定义的；它们是由我们在这些工具不可避免演化时适应得有多好来定义的。 AI 将继续降低基本执行的门槛。但对于那些培养深度领域意识、优先考虑系统可靠性、并保持持续学习习惯的专业人士来说，这些转变不是威胁，而是巨大的放大器。 不要担心跑赢技术。专注于与技术一起成长，承担复杂问题的责任，并交付真正的价值。这才是建立一份能挺过每一次技术变革周期的职业的方式。 --- 原文链接: [How I’m Future-Proofing My Career for the Next Decade of Tech Shifts](https://freedium-mirror.cfd/https://medium.com/data-science-collective/how-im-future-proofing-my-career-for-the-next-decade-of-tech-shifts-59872c4d10fa?ref=hubwiz.com) 汇智网翻译整理，转载请标明出处