当 AI 写完 99% 的代码，开发人员还剩下什么价值？
最近这一年，我一直在重新审视对技术团队的判断标准。
这个变化不是来自某篇文章，也不是来自某份行业报告，而是来自我们团队自己的实践——AI 编程工具越来越强之后，很多岗位的价值边界正在被重新定义。
最开始，我也只是把 AI 当辅助工具：让它帮忙写代码、查资料、整理文档、解释报错。那个阶段，它更像一个更聪明的搜索引擎。
但从 Cursor 的 Agent 模式开始，我明显感觉到事情不一样了。
从 Ask 到 Agent，变化的不只是效率
大概在 2025 年 4 月，我正式订阅了 Cursor。在这之前我也一直在用 AI 工具，但更多是免费试用和零散尝试，主要解决具体问题。从来没有想过，写代码会成为 AI 接近完美解决的第一个成功案例。
真正让我意识到变化加速的，是 Agent 模式出现之后。
从 Ask 模式，到 Agent 模式，再到未来可能连 Ask 都不需要——人只需要给目标、给约束、给判断，AI 自己去读代码、改代码、跑测试、修错误。
这对软件行业不是一个简单的效率提升，而是在改变技术人员在开发链条里所处的位置。
最先变化的，是设计和前端
在我们团队里，最早被冲击的是设计和前端。
过去做一个页面，需要设计师先出图，前端再实现，然后来回调整。但当 AI 工具能够快速生成页面原型、布局和风格之后，这条链路就开始松动了。
去年我们尝试让设计师转型，希望他能适应新的工作方式。最终没有成功。今年初，我们直接调整掉了这个岗位。
比较有意思的是，岗位调整之后，并没有出现我们担心的设计断层。反而是其他岗位的同事开始主动用 AI 工具做页面、调样式、改交互——而且效果并不差。
这件事对我触动挺大。
它说明一个问题：当工具能力足够强之后，一个岗位如果只是依赖"会使用某个专业工具"，价值会下降得很快。真正留下来的，是审美判断、产品理解和结果把控能力。
设计之后，下一个被明显冲击的就是前端。
现在后台页面、表单、表格、详情页、配置页这些标准化页面，AI 已经可以生成得很快。前端如果只是接 API、写页面、调样式，可替代性会越来越强。
所以我们最近也在尝试让前端同事往更完整的产品开发链路上走，不只是做页面，而是参与需求理解、产品设计、数据建模、流程梳理和测试风险评估。
但这个过程中，我们发现了两个明显的问题。
前端的两个结构性短板
第一个问题，是很多前端同事对数据结构和建模比较薄弱。
这并不奇怪。前端长期面对的是后端已经设计好的 API，看到的是接口返回什么、页面展示什么、用户点击之后调用哪个接口。
但一个系统真正难的地方，往往不是页面怎么画，而是：
- 业务对象是什么；
- 对象之间是什么关系；
- 状态如何变化；
- 哪些数据需要保留历史；
- 哪些操作需要审计；
- 哪些异常必须处理；
- 哪些流程不能简单覆盖。
这些东西不是 UI 层能自动补齐的。
第二个问题，是很多前端同事对业务的理解很弱，甚至没有主动理解业务的习惯。
这点更让我警惕。
前端做的是"看得见的东西"，理论上应该离用户和产品最近。但实际情况是，很多人只是把页面做出来，并没有真正理解页面背后的业务逻辑。
比如我们做的是云迁移和灾备软件。当我们希望前端同事参与一个新的灾备方向时，我发现他们对现有产品的理解并不充分。他们知道页面上有什么按钮，知道接口返回什么字段，但未必理解：
- 客户为什么需要迁移，为什么需要灾备；
- 灾备和备份有什么本质区别；
- 演练、接管、回切分别解决什么问题；
- RPO、RTO 对客户意味着什么；
- 哪些动作对客户来说是高风险操作。
也就是说，他们每天在做看得见的页面，但并没有真正理解这些页面为什么存在。
我们也尝试让他们去研究竞品，理解别人的产品怎么做、页面怎么组织、业务怎么表达。但这件事对他们来说同样困难——一方面是底层技术背景不足，另一方面是主动意愿不足。
很多人习惯了等需求、等设计、等接口，然后把页面实现出来。让他主动研究竞品、理解业务、拆解产品逻辑、反推数据结构，会非常不适应。
这就是 AI 时代前端转型最大的结构性短板。
过去前端的优势是"离用户最近"。但如果一个前端只是离页面近，而不是离业务近，那么在 AI 出现之后，这个优势会很快消失。
面试方式也必须跟着变
这些变化直接影响了我们最近的招聘方式。
以前我们会让候选人做开发题：现场写代码，看能不能跑起来。但现在我越来越觉得，这种方式的区分度在下降——写代码这件事越来越容易被 AI 辅助完成，一个候选人可以一路 AI 到能跑，但这不代表他真的理解了系统。
所以我们把面试题改成了系统设计题。
题目本身不复杂，通常是一个有真实业务复杂度的场景，比如价格来源不统一、规则可配置、历史数据需要追溯的结算系统。候选人不需要现场实现，只需要输出三件事：
- 数据结构
- 核心流程或时序图
- 关键测试点
我们真正想考察的，是以下几种能力：
业务拆解能力：能不能快速识别业务中的核心对象和它们之间的关系？有没有能力把模糊的业务描述，转化成清晰的数据边界？很多候选人拿到题目之后，会直接跳进表结构设计，而不是先搞清楚概念之间的区别。
建模判断能力：数据结构的设计决策，往往体现出一个人的工程深度。哪些字段需要历史版本？哪些状态需要审计？哪些关系会随时间变化？这些判断不需要写代码，但需要真正理解系统会在什么情况下出问题。
异常与边界意识：一个有经验的工程师，在设计阶段就会主动想到：外部依赖失败时怎么降级？规则变更后历史数据如何追溯？异常数据该不该直接进入正式流程？这些问题是 AI 能生成代码、但不会替你承担判断的地方。
测试优先级感知：关键测试点的质量，往往比测试用例的数量更能说明问题。候选人有没有能力从一堆可能的场景里，识别出哪些是必须覆盖的核心风险路径？
设计题没有标准答案。我们真正在看的，是候选人的思考方式：有没有先定义问题再展开设计？数据结构有没有反映出对业务的理解？提出的测试点有没有抓住真正的风险？
这些能力，AI 无法替代，也无法包装。
一个让我印象深刻的候选人
上周有个工作两三年的候选人，面试过程中有点困惑。他觉得我们问的内容不太像在面试开发，更像在面试产品经理。
这个反馈其实很典型。
很多开发习惯了一种分工：产品经理负责需求，后端负责接口，前端负责页面，测试负责验证。每个人在自己的格子里完成任务。AI 出现之后，这个格子正在被打破。
那个候选人自己也说，他现在 99% 的 coding 工作都是 AI 完成的。
于是我反问他：
既然 99% 的 coding 都被 AI 做了，那你还能做什么？
这个问题有点尖锐，但我认为这是每个技术人员都必须正面回答的问题。
如果你的价值只是 coding，而 coding 已经大部分被 AI 完成，那你剩下的价值是什么？
是理解需求？是设计数据结构？是判断流程风险？是识别测试重点？是排查线上问题？是把 AI 生成的东西变成可靠的工程结果？
如果这些都不是你的能力，那你确实会很危险。
AI 不会平均提升所有人
这一年实践下来，我越来越确定一个判断：
AI 不会平均提升所有人。AI 会放大强者，也会包装弱者。
我大概把技术人员分成三类。
第一类：AI 包装型
这类人本来不会分析、不会设计、不会测试，只是让 AI 生成内容，自己也判断不出好坏。
用了 AI 之后，他们的表面产出变多了，但风险也变大了。以前他做不出来，问题暴露得早。现在他可以借助 AI 做出一个看起来完整、能跑的东西，问题反而会延后到 Review、测试、上线，甚至客户现场才暴露。
所以这种人不是被 AI 放大了，而是被 AI 包装了。
更糟糕的是，有些人会出现责任主体的错位——做决策时把 AI 当权威，出了问题时把 AI 当背锅对象：
“AI 是这么生成的。” “我问过 AI，它说可以。” “这个测试用例是 AI 生成的，所以没覆盖到。”
但在工程组织里，这种说法是不成立的。AI 可以参与生产过程，但不能成为责任主体。最终采用方案、提交代码、合入分支、上线系统的人，必须对结果负责。这和以前复制 Stack Overflow 代码一样：代码可以不是你原创的，但采用它的人必须负责。
第二类：AI 工具型
这类人会用 AI，也确实能提升效率——写代码、查资料、生成脚本、写测试、整理文档都没问题。
这类人不是没有价值，但我认为他们会逐渐变成平庸执行层。AI 对他们的提升，主要是让他们更快完成原本就应该完成的工作，并没有明显提升判断质量。
可以用，但不能重用。可以交任务，但不能交判断。
第三类：AI 放大型
这类人本来就有结构化思维、工程判断和风险意识，AI 只是帮他们更快地展开、补充、验证和表达。
他们会先定义问题，再使用 AI：给 AI 明确的上下文，让 AI 生成多个方案并比较，主动质疑 AI 的结论，把 AI 输出转化成自己的判断，知道哪些地方必须人工确认，把结果落到数据结构、流程、测试、日志、异常处理和上线风险。
这种人用了 AI 之后，效率提升，质量也提升。因为 AI 放大的不是他们的手速，而是他们的判断系统。
技术人员的价值，正在从实现迁移到判断
过去，技术人员的核心价值是实现能力：会写代码、会写接口、会写页面、会调 Bug、会完成任务。这些能力仍然重要，但已经不够了。
AI 时代，更重要的是判断能力：能定义问题、能设计数据结构、能梳理关键流程、能判断异常边界、能识别测试风险、能判断 AI 输出是否可靠、能对最终结果负责。
这也是为什么我越来越重视一件很难量化的东西——工程美感。
但我说的工程美感，本质上是品味。
品味不是审美偏好，不是某种个人风格，而是一种判断力：通过第一性原理，理解客户真正需要什么，然后用美的方式表达出来——而且这种美，能被大多数人接受。
品味的第一层，是看穿真正的需求。
客户说"我需要这个按钮"，但真正的问题是：他为什么需要它？他在什么处境下会用它？用完之后他期待什么发生？如果失败了，他接下来该怎么办？
一个有品味的工程师，不会只满足表面需求。他会从用户的处境出发往回推：这个系统应该在什么情况下帮用户做判断，在什么情况下给用户足够的信息让他自己判断，在什么情况下必须阻止用户犯错。
品味的第二层，是美的表达。
但这种美不是视觉上的装饰，而是系统呈现出来的专业感：错误提示能让用户明白发生了什么，而不是"系统异常，请联系管理员"；空状态、加载状态、失败状态都有完整的处理，而不是白屏；用户操作失败后，知道下一步该怎么办，而不是陷入困惑；后端日志能帮助排障，出了问题有 trace_id 能追溯。
这些不是细节的堆砌，是品味的物化。
品味的第三层，也是最难的一层，是被大多数人接受。
一个只有工程师能欣赏的设计，不是品味，是自嗨。真正的品味，是把内行的判断力，转化成外行能感受到的信任感——让普通用户看一眼，就觉得"这个东西靠谱"。
AI 很容易生成主流程，但几乎无法复制品味。因为品味不是规则，是判断。它要求工程师真正站在用户的处境里，理解他们真正需要什么，然后做出那个最合适的选择。
而这，正是成熟工程师和普通执行者之间真正的差距。
最后
我现在面试技术人员，已经不太问"你会不会用 AI？"——这个问题意义不大。
真正应该问的是：
AI 介入之后，你的判断力有没有被放大？
如果 AI 只是帮你更快完成本来就应该完成的工作，那你只是更快地停留在原地。
如果 AI 放大了你的业务理解、结构化思维、工程判断、测试意识和风险控制能力，那你才真正具备 AI 原生组织里的持续价值。
所以我现在更想问的是：
当 AI 把代码写完之后，你还能为这个系统负责什么？