你已经看到，像 Cursor、Cline、Copilot 与 Windsurf 这样的 AI 编码助手如何改变了软件构建方式，承担了大量的繁琐工作与样板代码——大约 70% 的工作量。[1] 但把“玩具级方案”与“可用于生产的系统”区分开来的那“最后 30%”怎么办？这道鸿沟包含最难的部分：理解复杂需求、设计可维护的系统、处理边界情况，以及确保代码正确性。换句话说，AI 能生成代码，但它常常在工程化层面乏力。
回顾数十年技术变迁，Tim O’Reilly 提醒我们：每一次自动化飞跃都会改变我们如何编程，但不会改变我们为何需要熟练的程序员。我们面临的不是“编程的终结”，而是“我们今天所知的编程的终结”——开发者的角色在演化，而非消失。
当下工程师的挑战，是拥抱 AI 最擅长的那 70%，同时把更多精力投入到完成剩余 30% 所需的耐久型技能与洞见。本文汇集专家见解，明确哪些人类技能仍然关键：资深与中级开发者应继续发挥的优势，以及初级开发者要如何投资自己，才能与 AI 并肩成长。
本章的目标，是为如何最大化那不可替代的 30% 提供务实指引，为各层级工程师给出可操作的要点。
资深工程师与开发者：借助 AI 放大你的经验
如果你是资深工程师，应把 AI 编码工具视为放大影响力的机会——前提是用对方式。资深开发者通常拥有深厚的领域知识、对风险的直觉，以及做出高层技术决策的能力。
这些优势恰恰属于 AI 无法独立胜任的那 30%。本节将说明资深开发者如何把自己的价值发挥到最大。
既当架构师，也当“总编辑”
让 AI 处理代码首稿，而你专注于方案架构与对 AI 输出的精修。在许多组织中，Steve Yegge 预见到一种转变：团队也许“只需要资深成员”，他们“（a）描述要完成的任务，即编写提示，（b）审查产出以确保准确与正确”。拥抱这种模式。作为资深开发者，你可以把复杂需求转译为有效的提示或规格交给 AI 助手，然后用你的挑剔目光审阅每一行产出。实质上，你在与 AI 结对编程——它是打字飞快的那位，但你是大脑。
在评审中保持高标准：确保代码满足组织对质量、安全与性能的基线。通过扮演架构师与“总编辑”的双重角色，你可以避免“评审负担过高”。（提醒：如果初级同事只是把未经验证的 AI 产出“甩”给你评审，要及时制止——建立流程，要求他们先自查与验证 AI 生成的工作，避免你成为唯一的“安全网”。）
把 AI 当作推进大型项目的倍增器
资深工程师往往牵头大型项目，或处理初级难以独立应对的棘手重构。在你的指引下，AI 能承担大量机械性改动，或帮助探索多种替代方案。Yegge 把这种工作方式称为面向对话的编程（CHOP） ——“通过迭代打磨提示来编码”，把 AI 当作协作伙伴。借助 CHOP，你可以更有雄心地选择要攻克的目标。
AI 的协助降低了投入某个项目的门槛——过去要花几天的工作，现在可能几个小时就能完成。因此，资深开发者可以尝试那些曾经“要是能做到就好了”的项目。
关键在于：你必须保持“掌舵者”的角色——决定采用哪些工具与路径，并把各个部分整合为一致的整体。你的经验让你能筛选 AI 的建议：合适的采纳，不合适的果断舍弃。
指导并树立标准
资深工程师的另一项关键责任，是指导经验不足的成员如何有效使用 AI，以及如何坚持永不过时的最佳实践。你大概率拥有许多“用血换来的”知识点——比如内存泄漏、边界错位（off-by-one）、并发陷阱等。
在初级同事可能借由 AI 生成代码的今天，务必教会他们如何自我审查与测试这些代码。以身作则，展示如何全面测试 AI 的贡献，并倡导“质疑与验证机器输出”的文化。一些组织（甚至包括律所）已经制定规则：凡使用 AI 生成代码或文本者，都必须披露，并自行验证结果——而不是默认由资深同事兜底。
作为资深工程师，你应在团队内推动这类规范：欢迎 AI，但必须勤勉。通过这样的指导，你既分担了监督压力，也能更快地帮助初级成员成长为具备“30% 能力”的工程师。
持续培养领域掌握力与前瞻性
你的广博经验与上下文比以往更重要。资深开发者往往知道公司里某些东西“为何是这样建的”，或行业“是如何运作的”。这种领域掌握力让你能捕捉新人和 AI 容易忽略的失误。
持续投资对问题域的深入理解：紧跟业务需求、用户反馈，和会影响软件的新法规。除非你明确告知，AI 不会自动把这些纳入考虑。把你的领域洞察与 AI 的速度结合，才能获得最佳结果。
同时，用你的前瞻性来引导 AI。比如，当你知道“权宜之计”会在将来带来维护痛点时，就指示 AI 实施更可持续的方案。相信你多年磨炼的直觉——如果一段代码看起来“不太对”或“好得不像真的”，就深入检查。十有八九，你的直觉捕捉到了 AI 没考虑到的问题。能预见代码的二阶、三阶影响，是资深工程师的标志；别让 AI 的便利钝化了这种习惯，应该把它用到 AI 的一切产出上。
打磨软技能与领导力
当 AI 分担部分编码后，资深开发者可以把更多精力投入工程的“人”这一侧：与干系人沟通、主持设计讨论、做出与业务战略一致的判断。Tim O’Reilly 等人指出，随着机械式编码变得更简单，价值正在转移到“决定做什么”和“如何编排复杂系统”。
资深工程师往往是那个“编排者、看全局的人”。主动承担这个角色：撰写架构路线图、评估应当采用哪些工具（包含或不包含 AI）、制定你所在组织的 AI 编码指南。这些都是 AI 做不了的工作——它们需要经验、人类裁度，以及跨团队的共识构建。通过强化你的领导力，你就不会只是一个“代码生产者”（很容易被别的工具替代），而会成为引领团队的不可或缺的技术领导者。
简而言之，继续做资深开发者最擅长的事：见森林，也见树木。AI 能帮你砍下更多树，但仍需要有人决定砍哪棵、如何用这些木材搭一栋结实的房子。你的判断、策略思维与指导能力如今更加关键。善用 AI 的资深开发者，生产力会远超不用的人——而真正出类拔萃的人，是那些用人类优势去放大 AI 产出、而不是任其“野生生长”的人。
正如一位 Reddit 用户所言， “AI 是编程的倍增器” ，它“大幅提升资深程序员的生产力”。倍增效应确实存在，但被放大的，是你的专业能力。让这份专业始终锋利，并置于开发流程的核心。
中级工程师：适应与专精（Midlevel Engineers: Adapt and Specialize）
中级工程师或许正面临最大的进化压力。许多传统上占据你时间的工作——实现功能、编写测试、排查直截了当的问题——正越来越容易被自动化。
这并不意味着被淘汰，而是意味着升级。重心将从“写代码”转向构建更为专门化的知识，下文将逐一展开。
学会管理系统集成与边界（Systems Integration and Boundaries）
随着系统变得更复杂，理解并管理各组件之间的边界愈发关键。这包括 API 设计、事件模式（event schema）与数据模型——都需要审慎权衡业务需求与未来的灵活性。加深你的计算机科学基本功，深入理解如下学科方向：
- 数据结构与算法
- 分布式系统原理
- 数据库内部机制与查询优化
- 网络协议与安全
这些知识将帮助你理解 AI 生成代码的影响，并做出更优的架构决策。
同时也要学会处理边界情况与不确定性。真实世界的软件充满古怪场景与不断变化的需求。AI 往往默认只解决“普遍情形”。由开发者来追问：“如果……会怎样？”并主动寻找薄弱点。
这里的耐久型技能是批判性思维与前瞻性——枚举边界条件、预判故障，并在代码或设计中加以应对。这可能意味着要考虑空输入、网络中断、非常规用户操作，或与其他系统的集成。
打造你的领域专长（Build Your Domain Expertise）
理解业务语境或用户所处环境，能暴露出通用型 AI 根本不了解的边界情况。经验丰富的工程师习惯性地考虑这些情景。练习系统地测试边界并质疑假设。在需要人类理解不可或缺的复杂领域中专精。通用的例子包括：
- 受监管要求约束的金融系统
- 注重隐私的医疗系统
- 对实时性/性能有严格要求的系统
- 机器学习基础设施
软件工程特定的领域还包括前端与后端工程、移动开发、DevOps 与安全工程等。领域专长提供了当前 AI 工具所欠缺的上下文，帮助你更好地决定何时、如何应用它们。
精通性能优化与 DevOps（Master Performance Optimization and DevOps）
尽管大语言模型（LLM）能给出基本优化建议，但识别并解决系统级性能问题，离不开对整个栈的深刻理解——从数据库查询模式到前端渲染策略。随着代码生成更自动化，理解系统在生产环境中的运行方式变得更有价值。
把重心放在如下领域：
- 监控与可观测性
- 性能剖析（profiling）与优化
- 安全实践与合规
- 成本管理与优化
关注代码评审与质量保证（Code Review and QA）
当 AI 写下大量代码时，严谨地评审与测试这些代码就更为关键。Yegge 强调，“每个人都需要更认真地测试与评审代码”。把 AI 生成代码当作初级开发者的产出对待：你是负责抓出缺陷、安全漏洞或粗糙实现的评审者。这意味着要强化单元测试、集成测试与调试能力。
编写高质量测试是一项耐久技能，它迫使你理解规格并验证正确性。明智的做法是：在被证实之前，默认一切都不工作。AI 往往会给出功能上可用但未优化的代码，直到你通过迭代引导它改进。这可能源于训练数据未能完备覆盖最佳实践等原因。
培养测试心态：验证每条关键逻辑路径，使用静态分析或 linters，如果 AI 给出的代码达不到你的质量标准，不要犹豫去重写。即便你采用上一章讨论的“AI 作为验证者”模式，质量保证也不能简单外包给 AI——这正是人类细致审慎大放异彩的地方。当软件表现不如预期时，你需要真正的问题求解能力来定位与修复。AI 可以辅助调试（例如给出可能原因），但它缺乏你应用运行特定上下文的真实理解。人类测试者拥有领域知识与对用户期望的把握，这对评估潜在问题的相关性与影响至关重要。诊断复杂缺陷常常需要创造性思维与考虑更广因素的能力——这些本质上是人类的长处。评估软件行为的伦理影响（如公平性与可访问性），同样需要人类的敏感度与判断。
能够推演复杂缺陷——复现、隔离原因、理解底层系统（操作系统、数据库、库）——是一项永恒的工程技能。这通常需要扎实的基本功（内存与状态如何运作、并发等），而初级开发者必须通过实践习得。把 AI 当作助手（它可以解释错误信息或给出修复建议），但不要盲目依赖。有条不紊地排障、以第一性原理调试的能力，是优秀开发者的分水岭。这也是一个反馈回路：调试 AI 写的代码会教会你下次如何更好地提示，或避免某些模式。
学习“系统思维”（Learn Systems Thinking）
软件项目并非孤立的编码任务；它们存在于更大的语境中：用户需求、时间线、遗留代码与团队流程。AI 并没有天然的“大局观”——比如你项目的历史或某些决策的缘由（除非你把这些全部明确输入提示里，而这常常不现实）。这些上下文需要人来承载。
这里的耐久技能是系统思维——理解系统某一处的变化如何影响另一处、软件如何服务业务目标，以及所有活动部件如何彼此关联。[2] 这种整体视角能让你恰当地使用 AI 的产出。比如，如果 AI 提议的“巧妙捷径”违背了监管要求或公司约定，你会因为知道上下文而把它拦下。刻意去了解项目背景、阅读设计文档，培养你对“什么适配、什么不适配”的判断。
保持适应力——永不停止学习（Be Adaptable—and Never Stop Learning）
最后是一项元技能：学习新工具、适应变化。AI 辅助开发正迅速演进。保持开放心态并学会有效使用新特性的人，将始终走在前面——Tim O’Reilly 认为“渴望学习新技能”的开发者将从 AI 获得最大的生产力提升。投资于夯实基础与保持好奇。这组组合能让你把 AI 当作工具，而不至于对其形成依赖。
这是一种平衡：用 AI 加速成长，但也要间歇性地不借助 AI 练习，以确保你没有跳过核心学习（一些开发者会定期做一次“AI detox”来保持原生编码能力的锋利）。简言之，做那个持续学习的工程师——在任何时代，这都是抗周期的职业力。
练好跨职能沟通（Get Good at Cross-Functional Communication）
随着实现时间缩短，能在业务需求与技术方案之间顺畅翻译的能力更显珍贵。能与产品经理、设计师与其他干系人有效沟通的工程师，会越来越有价值。重点关注：
- 需求收集与分析
- 技术写作与文档
- 项目规划与估算
- 团队领导与指导
学习系统设计与架构（Learn System Design and Architecture）
与其花上数天实现一个新功能，中级工程师不如把时间用来设计能优雅应对规模与故障模式的系统。这需要深刻理解分布式系统原理、数据库内部机制与云基础设施——这些领域目前 LLM 的价值有限。
练习设计能在现实规模下解决问题的系统。这些技能无论代码如何生成都很有价值，因为它们要求你理解业务需求与工程权衡。
设计一个内在一致的系统，需要理解权衡、约束，以及超越“写几个函数”的大局观。AI 能生成代码，但它不会自动为复杂问题选择最佳架构。
总体设计——组件如何交互、数据如何流动、如何确保可扩展性与安全性——属于那需要人类洞察的“30%”。其中包括：
- 负载均衡与缓存策略
- 数据分片与复制
- 故障模式与恢复流程
- 成本优化与资源管理
资深开发者长期在磨砺这项能力，而中级与初级开发者应主动培养它。用模式与原则（如关注点分离与模块化）来思考，它们能引导 AI 生成的方案走向可维护。记住：扎实的架构不会偶然出现；它需要经验丰富的人来把舵。
善用 AI！ （Use AI!）
记住，AI 应该是你工作流的内建部分——不是要去抗拒的东西。将 AI 融入日常工作的实用方式包括：
- 搭建初始代码骨架（scaffolding）
- 快速原型与概念验证（POC）
- 结对编程以加速调试与问题求解
- 提出优化与替代方案的建议
- 处理重复性代码模式，让你把精力放在架构与设计决策上
涉足 UI 与 UX 设计（Venture into UI and UX Design）
一种声音愈发响亮：中级软件工程师该“直接转行”——纯工程技能会随着 AI 处理实现细节而过时。这个结论言过其实，但关于**工程之外技能（如设计）**重要性的讨论，值得关注。2024 年 12 月在 X 上的一次代表性讨论中，@fchollet 写道：
我们很快将进入一个可以把测试时的算力转化为能力的世界——在软件历史上，这是第一次边际成本会变得至关重要。
@garrytan 回应：
接下来这个阶段，用户体验（UX）、设计，以及对工艺的真正投入将走到舞台中央。
要真正去做人们想要的东西。软件与编码不会再是门槛。成为通才、在多个领域聪明而高效，才是创造伟大软件的关键。
成功的软件从来不只靠技术卓越。正在发生的改变不是工程的消亡，而是纯实现层面门槛的降低。这实际上让工程判断与设计思维更重要，而非更不重要。
想想为何 Figma、Notion 或 VSCode 这样的应用能成功。靠的不仅是技术，还有对用户需求、工作流与痛点的深入理解。这来自于：
- 用户体验设计思维
- 深厚的领域知识
- 对人类心理与行为的理解
- 兼顾性能、可靠性、可扩展性的系统设计
- 与商业模式的契合
最优秀的工程师从来不仅是“写代码的人”。他们是理解技术约束与人类需求的问题解决者。随着 AI 工具降低实现摩擦，这种全局理解更显珍贵。
这并不意味着每位工程师都要成为 UX 设计师。它意味着要增强产品思维与与设计/产品更高效协作的能力。意味着更多地思考用户，理解他们的心理与行为模式，并学会做出支持用户体验目标的技术决策。你已接近技术优雅的彼岸：现在用对务实的用户需求来平衡它。
Tan 随后又发文强调：
接下来这个阶段，UX、设计，以及对工艺的真正投入将走到舞台中央。
要真正做出人们想要的东西。软件与编码不会是瓶颈。成为通才、在多个领域聪明而高效，才会创造出伟大的软件。
未来属于能弥合“人类需求”与“技术方案”鸿沟的工程师——无论是通过培养更好的设计敏感度，还是通过与专职设计师更高效的协作。
初级开发者：与 AI 并肩成长（Junior Developers: Thrive Alongside AI）
如果你是初级或经验尚浅的开发者，面对此刻的 AI，可能既兴奋又焦虑。AI 助手能写出你自己或许还不会写的代码，潜在上能加速你的学习；与此同时，“初级开发者之死”的标题也此起彼伏，暗示入门岗位面临风险。与流行的臆测相反，尽管 AI 正在显著改变职场早期的体验，初级开发者并未过时。
你需要主动培养那些能让你提供超出 AI 产出之上的价值的技能。传统的学习路径——通过实现基础 CRUD 应用与简单功能来成长——会随着这些任务日益自动化而演变。
想想一个典型的初级任务：按照现有模式实现一个新的 API 端点。过去，这可能要花上一天编码与测试。有了 AI 帮助，实现时间也许缩短到一小时，但关键技能变为：
- 足够理解现有系统架构，以便正确明确需求
- 审查生成代码的安全影响与边界情况
- 确保实现与既有模式保持一致
- 编写覆盖业务逻辑的全面测试
这些技能并不能仅凭跟着教程或写提示就学会——它们需要在生产系统中的实操与资深工程师的指导。
这种演变为职场新人带来挑战也带来机遇。入门岗位的门槛可能提高，需要更扎实的基础来有效审阅与验证 AI 生成的代码；但这也意味着初级工程师更早有机会处理更有意思的问题。
下面是如何投资自己，去有效拿下那“30% 差距”。
夯实基础——别跳过“为什么”（Learn the Fundamentals—Don’t Skip the “Why”）
把每个问题都交给 AI（“我在 Python 里怎么做 X？”）很诱人，但别因此错过底层概念。把 AI 当作导师，而不是“答案贩卖机”。例如，当 AI 给出一段代码时，追问为何采用这种做法，或者让它逐行解释。
务必在不总是依赖 AI的前提下，理解数据结构、算法、内存管理与并发等概念。理由很简单：当 AI 的输出错误或不完整时，你需要自己的心智模型来识别并修复。如果你不积极理解 AI 为什么这么写，实际上学到的会更少、成长更慢。抽时间读文档、从零写小程序、打牢核心知识。这些耐久型基础将伴你穿越工具更迭。
在没有 AI 安全网时练习解题与调试（Practice Problem Solving and Debugging Without the AI Safety Net）
要建立真正的自信，有时必须独立飞行。许多开发者主张定期来个“无 AI 日”或阶段性限制 AI 的介入。这能防止技能退化，并迫使你真正理清问题逻辑——这反过来会让你更会用 AI（因为你能更聪明地引导它）。
此外，每当遇到 AI 生成代码里的 bug 或报错，先自己上手调试，再考虑请 AI 修复。通过单步调试或打印日志看清发生了什么，你会学到更多。
把 AI 的建议当作提示，而非最终答案。随着时间推移，亲手啃下任务中最棘手的部分，会恰好锻炼 AI 不擅长的领域——这正是你能提供的独特价值。
专注测试与验证（Focus on Testing and Verification）
作为初级开发者，最好的习惯之一就是为自己的代码写测试。当你使用 AI 生成代码时，这条更是双倍重要。
当你从 LLM 获得一段代码，不要假定它正确——质疑它。写单元测试（或手工测试）验证它是否真满足需求并处理边界情况。这既能捕获 AI 的问题，也训练你在信任实现之前先思考“期望行为”。
你可以请 AI 帮忙生成测试，但由你来定义测什么。Yegge 关于“把测试与评审当回事”的建议适用于所有层级。若你养成严格验证（无论是否 AI 辅助）的名声，资深同事会更信任你，也能避免他们觉得你在“甩”存疑代码。
务实层面，把测试当作开发的一等公民：学习测试框架、探索式手测、系统化复现缺陷。这些技能既能让你胜任那“30% 的工作”，也会加速你对代码真正工作原理的理解。记住：当你抓到 AI 引入的 bug，你就在做 AI 做不到的事——这就是增量价值。
培养“可维护性”的眼力（Build an Eye for Maintainability）
初级开发者常把重心放在“先跑起来”。在 AI 时代，让东西“能跑”很容易——AI 就能做到。更难、也更值得你关注的是：写出可读、可维护、干净的代码。
培养对良好结构与风格的鉴别力。拿 AI 的输出和最佳实践对照；若代码臃肿或过度复杂，主动重构。比如，LLM 给了个 50 行、职责混杂的函数——把它拆解成更小的函数；若变量名模糊——重命名。
把 AI 的代码当“同事的提交”来评审并改进。这能帮助你内化良好设计原则。久而久之，你会在提示里明确风格要求，从源头得到更干净的输出。维护者（往往是数月或数年后的你/他人）会感谢你，而你也证明了自己想的不止是“跑起来”，而是在像工程师那样思考。让代码可维护，正是那人主导的 30% ，从职业起点就把它当回事。
明智地提升提示与工具技能（Develop Your Prompting and Tooling Skills, Wisely）
“提示工程”确实有用。作为新人，你应该学习如何向 AI 提问、提供上下文、迭代提示以改进输出（可参考本书第 2 章）。这些新技能能让你脱颖而出（许多有经验的开发者也还在摸索）。但要记住：提示写得好，往往意味着对问题理解得好。如果总是达不到想要的结果，可能意味着你需要先澄清自己的理解——把这当成信号。
一个策略是：先用自然语言自己写出解法大纲，再让 AI 实现。也可以多试试不同的 AI 工具（Copilot、Claude 等），了解各自长短。你越熟练，效率越高——但永远别把输出当权威。把 AI 看作“超强版 Stack Overflow”：辅助，不是裁判。
你也可以用 AI 做些小型个人项目来突破边界（“我能在 AI 的帮助下做个简单 Web 应用吗？”）。这会教你如何把 AI 融入开发工作流，是很好的团队技能。只是要与无 AI 练习穿插进行，如前所述。
寻求反馈与导师指导（Seek Feedback and Mentorship）
最后，一项能加速你成长的耐久技能是主动寻求反馈、向他人学习。AI 不会介意你无视它的建议，但人类队友与导师对你的成长无价——尤其在软技能、领导力、沟通与团队协作方面。
别犹豫向资深同事请教为什么他们偏好某解法，尤其当它与 AI 的建议不同。与更有经验的同事讨论设计决策与权衡——这能让你窥见他们如何思考，对你而言弥足珍贵。在代码评审中，尤其虚心看待对你AI 产出的意见。若评审指出“这个函数不线程安全”或“这个做法会有扩展性问题”，花时间理解根因。这些恰恰是 AI 容易遗漏、而你要学会捕捉的地方。久而久之，你会形成自己的心智清单。
此外，争取结对编程的机会（即便是远程）。也许你能和一位使用 AI 工作流的资深者“结对”——你会观察他们如何提示 AI、如何修正它，更重要的是如何沟通、主持讨论、处理团队动态。开放求教、主动问路，会帮助你从“做 AI 也能做的事”转向“做只有人能做的高价值工作”。某种意义上，你在尽可能高效地获取通常需要时间积累的“经验之智”。这会让你不只是“房间里又一个写代码的人”，而是团队愿意长期留用与提拔的那类工程师。
沟通与协作（Communicate and Collaborate）
做软件是团队运动。AI 不会上会（谢天谢地）——仍需要人和人澄清需求、讨论取舍、协调工作。强沟通依旧稀缺而宝贵。练习提出好问题、清晰描述问题（对同事与对 AI 都是）。
有趣的是，向 AI 提示本身就是一种沟通；它要求你精确表达需求。这与工程核心技能需求分析高度重叠。[3] 如果你能写出清晰的提示或规格，说明你已经把问题想清楚了。
此外，分享知识、写文档、评审他人代码是 AI 无法替代的协作技能。未来，当开发者“与 AI 共事”时，团队内的人—人协作——确保在解决正确的问题——依旧关键。一个新趋势是，开发者会更多参与高层设计讨论（AI 可能也在场），并承担任务编排，某种意义上更像指挥。在这个位置上，沟通与领导力大有可为。
心态转变：从“拿来用”到“创造理解”（Shift Your Mindset: From Consuming to Creating）
在 AI 时代，初级开发者需要完成一个心态转变：从只消费解决方案到创造理解。过去你也许要啃文档才能写出一个功能；如今 AI 能把答案端来。若你只是复制粘贴然后继续，并没有真正成长。
把每个 AI 给出的方案当作学习样本：解剖它、试验它、思考如果不靠 AI 你会如何推导出来。把 AI 的输出当作互动式学习材料而非终极答案，你——这个人——才会持续升级。这样，AI 不会替代你的成长，反而会加速它。
许多专家认为，尽管 AI 可能减少庞大“初级码农”队伍的需求，它也抬高了初级开发者的定义。角色正转变为能高效与 AI 协作并迅速攀升价值链的人。若你采纳本节的习惯，你将不再只是带来“AI 能带来的东西”（任何公司都能买个订阅），而是带来洞见、可靠与持续改进——这是未来资深开发者的特质。
摘要与下一步（Summary and Next Steps）
要在 AI 赋能的开发世界中茁壮成长，各个层级的工程师都应加倍投入那些 AI 目前（尚）无法复制的长期型技能与实践。无论工具多么先进，这些能力都将持续重要。尤其应关注以下领域：
- 夯实系统设计与架构专长
- 练习系统思维并保持对大局的情境化理解
- 打磨批判性思维、问题求解与前瞻性
- 在专业细分领域建立深厚积累
- 代码评审、测试、调试与质量保证
- 提升沟通与协作能力
- 适应变化
- 持续学习：在巩固基础的同时获取新技能、更新知识
- 善用 AI
这些技能构成了软件工程中的人类优势。它们之所以“耐久”，是因为不会随着下一个框架或工具更替而过期；事实上，AI 的崛起只会让它们更显突出。Simon Willison 指出，AI 辅助实际上让扎实的编程能力更有价值，因为有经验的人能够把这些工具发挥到更大的效果。
强大的机器落在缺乏技能的人手里要么危险、要么浪费；而在能手手中，它才具变革性。在 AI 时代，经验丰富的工程师就像拥有先进副驾驶的老练飞行员：旅程可以更快更远，但仍需要驾驶员穿越风暴并确保安全落地。
软件工程一直都是一个持续变革的领域——从汇编到高级语言，从本地机房到云端，如今再到 AI 辅助开发。每一次飞跃都自动化了编程的某个面向，但每一次开发者都适应并找到了更多可做之事。回应 Tim O’Reilly 的一条评论时，有位 HN 网友指出，过去的创新“几乎总是带来更多工作、更多增长、更多机会”。AI 的兴起也不例外。它并未让开发者变得无关紧要，而是重塑了成功所需的技能组合。编码中“枯燥的 70%”在变得更容易；而那“富有挑战的 30%”则成为我们价值中更大的一部分。
为了最大化这“人类的 30%”，请专注于恒久的工程技能：深入理解问题、设计简洁方案、以质量标准审视代码，并把用户与上下文纳入考量。有经验的程序员之所以能从 AI 获得更多，是因为他们知道如何引导它、以及当它失手时该怎么做。把这些技能与 AI 工具结合的人，表现将胜过只拥有其一的人。事实上，专家们正逐渐形成共识：AI 是为熟手而生的工具——“LLM 是给高级用户用的电动工具”。这意味着责任在我们每个人：把自己打磨成那个“高级用户”，培养能有效驾驭新工具的专业能力。
归根结底，软件工程的工艺不止是写“能跑”的代码，而是写在真实环境、经受时间与需求演变也能跑得好的代码。今天的 AI 可以协助写代码，但还不能保证它在上述所有维度都表现良好。这仍然是开发者的职责。
在实际操作层面，无论你是在与一位“积极热情的初级生”式 AI 结对写函数，还是在审阅一份充满 AI 生成改动的 diff，都别忘了套上你独有的人类镜头：这是否解决了正确的问题？别人是否能理解并维护？有哪些风险与边界情况？这些问题由你来负责。编程的未来确实会少一些逐字符的手敲，多一些指挥与策展——但依然需要掌舵的开发者具备把事情做对的智慧。
最终，优秀的软件工程始终关乎问题求解，而非单纯的“码字”。AI 并未改变这一点：它只是敦促我们把问题求解提升到新的层次。拥抱这一挑战，你就能在行业的新篇章中蓬勃发展。
——
注释
1 本章基于我先前在 Substack 上发表的两篇文章：Addy Osmani，“Beyond the 70%: Maximizing the Human 30% of AI-Assisted Coding”，Elevate with Addy Osmani，2025 年 3 月 13 日；以及 Addy Osmani，“Future-Proofing Your Software Engineering Career”，Elevate with Addy Osmani，2024 年 12 月 23 日。
2 如需进一步了解系统思维，可参考：Donella H. Meadows，《Thinking in Systems: A Primer》，第 2 版（Rizzoli，2008）；Peter M. Senge，《The Fifth Discipline: The Art and Practice of the Learning Organization》（Crown，2010）。
3 更多相关内容参见：Mark Richards 与 Neal Ford，《Fundamentals of Software Architecture》，第 2 版（O’Reilly，2025）；以及 Mark Richards、Neal Ford、Raju Gandhi，《Head First Software Architecture》（O’Reilly，2024）。
