当工程师不再只写代码，我应该往哪里走？
AI 时代不会奖励那些只会守住旧技能的人。它会奖励那些愿意重新定义自己的人。
最近读到一篇关于 Claude Code 之父 Boris Cherny 的访谈，里面有一句话让我停了很久：很多人以为“品味”是 AI 时代人类最后的护城河，但他认为，品味也会被模型慢慢学会。
Claude Code之父：「品味」不是人类护城河；当工程师不再写代码，招聘看什么？
这句话真正刺痛我的地方不在于“AI 会不会写代码”，而在于它把一个更深的问题摆到了我面前：
如果 AI 不只是会写代码，还会逐渐学会判断什么代码更好、什么产品更合理、什么方案更值得做，那编程工程师未来到底还剩下什么？
我过去习惯把自己定义为“写代码的人”。会不会某种语言，懂不懂某个框架，能不能快速修 bug，能不能独立完成一个模块，这些都是工程师的价值标签。但现在我越来越觉得，这套标签正在变窄。不是说代码不重要了，而是“只会写代码”这件事的价值正在被压缩。
未来的工程师，不是不写代码，而是不再把“亲手写代码”当作自己的核心身份。
一、我对“工程师”的理解变了：从写代码的人，到构建系统的人
过去我理解的工程师，是把需求翻译成代码的人。
产品经理说要一个功能，设计师给出页面，后端定义接口，前端实现交互，测试验证质量。工程师在这个流程里最核心的动作，就是把想法变成代码。
但 AI 编程工具出现之后，这个流程开始变形。
当 Claude Code、Cursor、Copilot 这类工具越来越强，很多具体实现工作会被模型接管。写 CRUD、补测试、改样式、查文档、重构小模块、生成脚手架、解释报错，这些过去需要工程师花大量时间完成的工作，现在越来越像可以被自动化的“执行层”。
这时工程师的价值就被迫往上移。
我不能再只问：“这段代码怎么写？”
我更应该问：
这个需求是否值得做？
这个方案会不会引入长期复杂度？
这个系统的边界在哪里？
这个功能上线之后，谁会受益，谁会受损？
这个 AI 生成的实现，有没有安全、性能、可维护性问题？
如果让多个 Agent 并行工作，我该如何拆任务、验结果、控风险？
这意味着，工程师的核心角色正在从“代码生产者”转向“系统编排者”。
过去我是在键盘上写代码。未来我更像是在指挥一组 AI 工程师工作。我需要定义目标、拆解任务、设计约束、检查结果、修正方向，并把这些流程沉淀成可复用的自动化系统。
Boris 说自己的工作已经变成了写 loops，我理解这句话的意思是：真正高级的工程师，不只是会 prompt AI，而是会设计一个能持续调用 AI、验证 AI、纠正 AI、迭代 AI 的工作循环。
这才是新的工程能力。
二、AI 没有消灭工程师，而是消灭“低抽象层级的舒适区”
我不认为 AI 会简单地让工程师消失。更准确地说，AI 会消灭一部分工程师过去赖以生存的舒适区。
以前，一个人只要熟练掌握某个框架，就能在相当长时间里保持竞争力。比如会 Spring Boot、会 Vue、会 React、会 Kubernetes、会某种数据库优化，这些技能都很有价值。
但问题是，这些技能里有很大一部分正在被模型吸收。
AI 最擅长的，就是把已经存在于互联网上的大量知识重新组合出来。语法、API、框架模板、常见 bug、标准架构、最佳实践，这些东西越标准化，越容易被模型掌握。
所以我必须接受一个现实：
越是“可描述、可重复、可验证”的编码工作，越容易被 AI 自动化。
这不是坏事。真正的问题是，我能不能主动把自己从这些重复性劳动里解放出来。
如果我还把价值建立在“我比别人更熟某个框架”上，那优势会越来越薄。因为 AI 可以同时熟悉无数框架，而且更新速度比我快。
但如果我把价值建立在“我能判断什么问题值得解决，我能组织 AI 把复杂问题解决掉，我能对结果负责”，那我的位置就会更稳。
未来不是不需要工程师，而是更需要那些能够提升抽象层级的工程师。
三、未来工程师最重要的能力，不是 prompt，而是判断
很多人一提到 AI 编程，就会说工程师要学 prompt engineering。这个观点没错，但我觉得还不够。
Prompt 只是表层技能。真正底层的能力是判断。
因为 AI 可以生成很多东西，但它不天然知道什么是“对公司最有价值的东西”。它可以给出十个方案，但不一定知道哪个方案最适合当前团队、当前业务、当前资源和当前风险边界。
所以未来工程师最重要的能力，可能包括这几类。
第一，是问题定义能力。
能不能把模糊需求拆成清晰问题，能不能识别真正的瓶颈，能不能分辨“用户说想要的”和“用户真正需要的”。
第二，是架构判断能力。
AI 可以写代码，但系统长期演化的复杂度，需要人来把关。哪些地方应该抽象，哪些地方不该过早抽象；哪些服务应该拆，哪些服务不该拆；哪些技术债可以忍，哪些技术债会毁掉未来。
第三，是验证能力。
AI 生成的代码不是天然可信的。工程师要会设计测试、构建评估指标、做安全审查、看日志、定位边界问题。未来的工程师不只是“写实现”，更像是“建验证系统”。
第四，是上下文管理能力。
AI 的能力很大程度取决于上下文。给它什么信息、隐藏什么信息、如何压缩信息、如何分阶段提供信息、如何让多个 Agent 不互相污染上下文，这些都会变成新的工程基本功。
第五，是价值判断能力。
当“品味”也可能被模型学习，人类更重要的东西不是我觉得这个设计好不好看，而是我到底相信什么：什么是好的产品，什么是好的组织，什么是对用户负责，什么是不能为了效率牺牲的底线。
所以我越来越觉得，未来优秀工程师不是“最会写代码的人”，而是“最能对复杂系统做判断的人”。
四、我应该往哪个方向发展？
如果站在个人职业发展的角度，我会把未来工程师的发展方向分成五条路。
1. AI 原生全栈 Builder
这是我认为最适合大多数普通工程师转型的方向。
过去的全栈工程师，是前端、后端、数据库、部署都能做。未来的 AI 原生全栈 Builder，不只是会这些技术栈，还要能借助 AI 快速完成从想法到产品的闭环。
他懂一点产品，懂一点设计，懂一点数据分析，懂一点商业逻辑，也能用 AI 快速补齐自己不熟悉的部分。
这种人的优势不是每个领域都最深，而是能独立把事情推进起来。
未来很多公司会更喜欢这种人。因为 AI 降低了跨领域协作成本，一个能主动发现问题、定义方案、调用 AI、交付结果的人，比一个只等需求、只写模块的人更有价值。
2. Agent 工作流架构师
如果说现在大家还在学习怎么使用 AI 工具，那么下一阶段的重点就是：如何把 AI 工具变成稳定的工作流。
这类工程师要懂自动化、任务拆解、工具调用、权限控制、上下文管理、结果评估和人机协作。
比如一个需求来了，不是人工一步步问 Claude，而是系统自动完成：
读取需求文档；
拆解任务；
创建分支；
分配给不同 Agent；
生成代码；
运行测试；
发现失败后自动回滚或重试；
生成人类可读的审查报告；
最后等待工程师审批合并。
这类人未来会非常重要。因为企业真正需要的不是“一个会聊天的 AI”，而是“一个可控、可审计、可复用、可规模化的 AI 工程系统”。
3. 业务型技术负责人
AI 越强，技术和业务之间的边界越模糊。
过去工程师可能只负责实现，产品和业务判断由别人完成。但未来，如果 AI 能大幅降低实现成本，那么真正稀缺的就是“知道该实现什么”的人。
这类工程师需要深入业务现场，理解客户、流程、成本、收入、风险和组织约束。他不是简单地问“需求是什么”，而是能判断“这个需求是否值得做”。
在 AI 时代，技术负责人不能只懂技术。他还要懂业务模型，懂用户场景，懂组织运转。因为当执行成本下降，方向错误的代价会被放大。AI 可以让你更快地做对事，也可以让你更快地做错事。
4. AI 安全与质量工程师
AI 写代码越多，代码质量、安全和合规问题就越重要。
未来会有大量企业面临一个问题：AI 生成的代码到底能不能进生产？有没有安全漏洞？有没有许可证风险？有没有数据泄露风险？有没有隐藏的逻辑错误？出了问题责任怎么算？
所以安全、测试、质量、合规方向会变得更重要，而不是更不重要。
只不过这些岗位也会升级。未来的测试工程师不是手工点页面，而是设计自动化验证体系；安全工程师不是只扫漏洞，而是研究 AI 生成代码的风险模式；质量工程师不是只卡流程，而是建立 AI 产出的评估标准。
这是一条偏专业深度的路线。
5. 复杂系统架构师
AI 能写很多代码，但复杂系统的长期演进仍然需要人类负责。
大型系统里最难的不是某一段代码，而是复杂性本身。服务边界、数据一致性、性能瓶颈、故障隔离、成本控制、团队协作、历史包袱，这些问题不是靠生成代码就能解决的。
未来真正资深的工程师，会越来越像系统医生。他能看懂系统的病灶，知道什么时候该动刀，什么时候该保守治疗，什么时候该重构，什么时候该忍受不完美。
AI 可以辅助分析，但最终的权衡需要人来做。
五、怎么结合 AI 的优势，避开自己的劣势？
我觉得最重要的一点是：不要和 AI 比短板。
人类的短板很明显。我们记忆有限，速度有限，精力有限，不可能同时熟悉所有框架，也不可能一天 24 小时持续写代码。
AI 的优势正好在这些地方。它可以快速生成、快速搜索、快速改写、快速尝试、快速总结。那我就不应该再把时间浪费在和 AI 比速度上。
我应该把 AI 当成自己的能力放大器，而不是竞争对手。
具体来说，我会这样调整自己的工作方式。
第一，凡是重复三次以上的工作，就尝试交给 AI 或自动化流程。
写模板、查文档、生成测试、整理日志、总结会议、改格式、生成脚手架，这些都不应该长期靠手工完成。
第二，凡是我不熟悉的新领域，先让 AI 帮我建立地图。
以前学习一个新框架，可能要看很多文档。现在可以先让 AI 解释核心概念、生成最小 demo、列出常见坑，再自己验证。这样学习速度会快很多。
第三，凡是重要代码，都不能盲信 AI。
AI 可以写第一版，但我必须审查。尤其是安全、权限、数据一致性、异常处理、性能边界这些地方，必须建立自己的检查清单。
第四，凡是复杂问题，都让 AI 给多个方案，而不是只要一个答案。
我不应该问：“帮我写这个功能。”
我应该问：“给我三个实现方案，分别说明成本、风险、扩展性和适用场景。”
这样 AI 才能帮助我提升判断，而不是替我偷懒。
第五，把 prompt 沉淀成流程，把流程沉淀成工具。
临时问 AI 是低阶用法。真正高级的用法，是把自己反复使用的提示词、检查清单、代码规范、测试流程、发布流程沉淀下来，变成团队可复用的 AI 工作流。
这才是复利。
六、我最需要避免的三个陷阱
第一个陷阱，是把 AI 当搜索引擎。
如果只是问问语法、查查报错，那只是用到了 AI 的表层能力。真正有价值的是让 AI 参与任务拆解、方案比较、代码审查、测试生成和系统设计。
第二个陷阱，是把 AI 当权威。
AI 很会用自信的语气说错话。工程师不能因为 AI 说得流畅，就放弃验证。未来越依赖 AI，越要强化自己的工程怀疑精神。
第三个陷阱，是用 AI 逃避思考。
这是最危险的。AI 可以帮我写代码，但不能替我承担责任。如果我不知道自己要什么，只是让 AI 不断生成，那我会变成一个“复制粘贴型工程师”。这种人不仅不会变强，反而会越来越弱。
AI 应该让我思考得更深，而不是思考得更少。
七、未来招聘到底看什么？
如果我是招聘方，在 AI 时代我不会只看候选人会不会写某种语言。我会更看这几件事。
他能不能快速理解一个陌生系统？
他能不能清楚定义问题？
他能不能把复杂任务拆成可执行步骤？
他会不会用 AI 提高自己的产出？
他能不能审查 AI 的结果？
他有没有产品意识和用户意识？
他能不能跨团队沟通？
他是否对技术决策有判断力？
他能不能对结果负责？
换句话说，未来招聘看的不是“你能不能写代码”，而是“你能不能借助 AI 把事情做成”。
这对工程师既是压力，也是机会。压力在于，单纯的编码熟练度会贬值。机会在于，一个有主动性、有判断力、有系统思维的人，会被 AI 放大很多倍。
八、我的结论：工程师要从“代码工人”升级为“AI 时代的建设者”
读完 Boris 的访谈，我最大的感受不是恐慌，而是清醒。
AI 确实会拿走很多过去属于工程师的工作。它会写更多代码，修更多 bug，生成更多测试，完成更多重复性任务。甚至有一天，它可能在很多局部判断上也比我更强。
但这并不意味着工程师没有未来。
真正没有未来的，是把自己锁死在低抽象层级的人。
只会等需求的人，会危险。
只会写实现的人，会危险。
只会维护单一技术栈的人，会危险。
拒绝使用 AI 的人，会危险。
用 AI 逃避思考的人，也会危险。
而那些愿意升级自己的人，会进入一个更大的空间。
未来的工程师，应该是 Builder。
他既懂技术，也懂业务。
既能写代码，也能指挥 AI 写代码。
既能使用工具，也能构建工具。
既能追求效率，也能守住质量和价值观。
既能快速试错，也能对长期复杂度保持敬畏。
我不再把自己的目标设定为“成为一个更快的程序员”。因为在速度上，我很难赢过 AI。
我更想成为一个“更会构建系统的人”。
让 AI 帮我写代码，帮我探索未知，帮我放大能力，帮我节省时间。而我自己，则把精力放在更高层的问题上：判断方向、设计系统、理解用户、管理复杂度、承担责任。
这也许就是编程工程师未来最重要的转型：
不是从工程师变成非工程师，
而是从写代码的工程师，变成驾驭 AI 的工程师；
从执行者，变成编排者；
从工具使用者，变成系统建设者；
从“我会写什么”，变成“我能做成什么”。
近期访谈报道中提到 Boris Cherny 对软件工程角色转变、招聘标准和 Claude Code 使用方式的判断；另有研究分析 Claude Code 这类 Agentic coding 工具的核心是“模型—工具—反馈”的循环系统，而真正复杂的是权限、安全、上下文、子代理和可扩展机制等工程系统；也有近期研究观察到 Claude Code 采用后，开发者参与的语言和仓库范围扩大，说明 AI 正在降低跨技术栈迁移成本。(The Times of India)