从「写代码的人」到「定义问题的人」

首发地址 csdn 青山师 ： https://blog.csdn.net/zixiao217
转载请注明出处！

2025 年秋天，我参加了一个技术大会的圆桌讨论。台上坐着一个在硅谷做了十五年工程 VP 的人，主持人问他：“你现在招人最看重什么？”

他的回答不到十秒：“我不需要能写代码的人。我需要能告诉我该写什么代码的人。”

台下愣了一下，然后是一阵那种半信半疑的窃窃私语。我当时也在下面坐着，心想这话说得有点极端，但回头琢磨了几个月，发现他说的比我最初理解的更接近真相。

代码正在从「资产」变成「中间产物」

我们先说一个很多人还没意识到的事：代码，作为工程师的核心产出物，正在经历一次地位降级。

在 AI 辅助编程工具普及之前，代码就是工程交付的终点。你写了一段程序，这段程序就是你的价值载体。功能上线了、bug 修好了、性能优化了——这些都是以「写出来的代码」为标志的。

但现在这个逻辑链断了。当 AI 可以在几秒内生成你原本要写一整天的代码时，「写代码」这件事本身的技术壁垒在快速溶解。不是因为你的技术不够好，是因为在这个具体动作上，AI 的边际成本是你的千分之一。

这里有一个 2024 年的数字值得放在心里：GitHub 在 2024 年 7 月公布的 Copilot Workspace 技术预览中，展示了「从 issue 到 PR」的全流程自动化——你给一个 GitHub issue，它可以自动生成技术方案、修改代码、创建 PR。虽然这个产品还在早期，但方向已经很明确了：代码正在从一种需要人工逐行构建的资产，变成一种可以由 AI 根据需求描述批量生成的中间产物。

这意味着什么？如果你职业生涯的核心竞争力是「我能熟练地用某种语言写出某种模式的代码」，你正在一个被技术浪潮淹没的赛道里。

什么才是「定义问题」

回到那场圆桌讨论。那个 VP 说的「能告诉我该写什么代码的人」，到底指什么？

我后来跟几个在不同规模公司做技术负责人的朋友聊了这个问题，答案惊人地一致。他们说的不是那种「来，我告诉你用什么设计模式」的人。他们说的是能在以下场景里做对事情的人：

场景一：产品经理说我想加一个推荐功能。 初级反应是去调研推荐算法。中级反应是问"推荐什么内容、基于什么数据、在哪个页面"。而「定义问题」的反应是：“你说的推荐功能，核心是提高用户留存还是提高客单价？如果是留存，推荐应该出现在用户即将流失的节点而不是首页；如果是客单价，它应该和购物车联动而不是在内容流里。这两个方向的系统设计完全不同，我们先确定你要解决什么问题。”

场景二：线上出现了一个性能瓶颈。 初级反应是去加缓存、优化查询。中级反应是去 profiling、找热点、分析读写比。而「定义问题」的反应是：“这个接口的延迟从 200ms 变到 2s，是在上周五的产品上线之后。那批改动加了三个字段但那三个字段的数据来源表没有索引。不是性能出了问题，是性能约束在某个环节被破坏了。我们应该先修数据层，再考虑要不要加缓存。”

你注意到没有，这两个场景里有一个共同模式：在别人看到「解决方案」的地方，他们看到了「问题本身」。 把模糊的、未经定义的需求翻译成清晰的、技术上可操作的问题陈述——这个能力，是 AI 目前完全做不到的。

原因很简单。AI 需要一个 prompt 才能工作。如果你的 prompt 是「帮我写个推荐系统」，AI 会给你一个推荐系统。但没有人能帮你判断你真正需要的是不是推荐系统，以及「推荐系统」这个词在你的业务上下文里到底意味着什么。这个判断只能由人来完成。

为什么这个能力在被低估

我们这行有一个根深蒂固的偏见：代码写得好的人比需求理解得好的人更「硬核」。你去看看技术社区的讨论，一个能徒手写红黑树的人更容易被崇拜，而一个能把混乱的业务需求梳理成清晰的模块边界的人，你可能根本不知道他是谁。

这个偏见是危险的。因为在 AI 时代，前者的价值在被快速稀释，而后者的价值在被剧烈放大。

最直观的证据来自薪酬数据。Levels.fyi 的 2025 年数据显示，同级别的工程师，那些 job description 里包含"system design"、“cross-functional collaboration”、"technical strategy"等关键词的岗位，总包普遍比纯 IC coding 方向的岗位高出 20% 到 35%。而且这个差距在 2025-2026 年间明显拉大了。市场在用真金白银告诉你，什么能力在涨价。

从执行到定义的三个转变

所以具体怎么做？我不是要给你一个「21 天成为定义问题的高手」的课程。但有几个转变是切实可操作的。

第一个转变：把「怎么做」的肌肉记忆换成「为什么做」的条件反射。

这个习惯的建立比你想象的要难。很多工程师在接到任务时的第一个念头是「我该怎么实现」。这不是你的错，是你过去五到十年被训练出来的本能。但试着在每次接到需求时，先花五分钟不要想技术方案，只问自己三个问题：这个需求要解决谁的问题？如果没有这个功能，现在他们是怎么凑合着过的？这个需求的成功标准是什么——上线就算成功，还是用户行为改变才算？

这三个问题的答案通常会暴露出一件事：你最初理解的需求和你最终应该解决的问题之间，有一条不小的缝。跨过这条缝的能力，就是「定义问题」的第一个层次。

第二个转变：把技术方案从「单一选择」变成「多选项对比」。

很多人在做方案设计的时候，心里其实只有一个方案，然后花大量时间为这个方案辩护。换个方式：同时准备至少两个可行方案，把它们的 tradeoff 说清楚——方案 A 两周上线但三个月后需要重构，方案 B 四周上线但维护成本低，方案 C 直接复用现有模块但功能上要妥协。然后把选择权交还给产品和业务方。

这个动作有两个效果。第一，它强迫你思考「为什么选 A 而不是 B」，你的技术判断力在对抗中变强。第二，它让你从一个「执行命令的人」变成一个「提供决策支持的人」。后者离替代更远。

第三个转变：用业务语言解释技术决策。

这不是什么新鲜的大道理。但我是认真的。AI 能生成代码，但 AI 生成不了「用 CFO 能听懂的语言解释为什么这个技术选型会影响下一季度的成本结构」的能力。当你能够跨越技术语言和业务语言之间的鸿沟时，你就不再是一个「写代码的」了——你是一个「用技术解决业务问题的人」。这两者在组织里的位置完全不同。

举个我亲眼见过的例子

一家做跨境电商的 SaaS 公司，CTO 在 2025 年初做了一个很多人不理解的决定：他把团队里三个资深后端开发的 OKR，从「完成 X 个 feature 开发」改成了「参与 Y 次客户需求访谈并产出一份技术可行性评估」。

头两个月这三位工程师非常不适应。你让写 Java 的人去跟客户聊需求？他们觉得自己在被降级。但到 Q3 的时候，变化开始显现了。因为跟客户直接沟通过，其中一个工程师在做一个库存管理模块时，直接推翻了产品经理提了三个月的方案。他说：「客户说的不是要一个更好的库存查询工具，他们是想知道什么时候该补货。你给我的 PRD 解决的是『查得快』，但客户的问题不是速度，是时机。我们应该做的是补货预测，不是库存查询。」

这个模块上线后，客户的续约率在那个季度提升了 8%。而那个「被降级」的工程师，年底晋升为技术总监。

他的技术能力在这几个月里并没有显著提升。提升的是他「定义问题」的能力。而他之所以能获得这个能力，不是因为他刷了更多的题或者学了更多框架，是因为他从「只和代码对话」变成了「和问题本身对话」。

这不是「软技能」

关于「定义问题」，还有一个常见的误解必须澄清。很多人把它归类为「沟通能力」「软技能」。不对。这是一个硬得不能再硬的技术能力。定义问题需要你对系统有足够深的理解，你才知道什么可实现什么不可实现。需要你对业务有足够的理解，你才能把模糊的用户表达转化成精确的工程约束。需要你有足够的架构经验，你才能在听到一个需求的前三十秒判断出这个需求会导致多大的连锁改动。

这不是那种「学个新框架」就能获得的能力。它需要时间、需要踩坑、需要你跨出纯技术的舒适区。但正是因为难以速成，它才构成了真正的护城河。

怎么开始练

如果你觉得上面说的都对但你不知道从哪下手，我给你一个非常具体的建议：从下一次需求评审会开始，不要上来就想方案，先问为什么。就这一个动作。坚持一个月，你回头看一个月前的自己，会发现那个只知道埋头写代码的人，和现在的你之间，隔着一道职业天花板。

这道天花板翻过去之后，你就不再是「写代码的人」了。你是「定义问题的人」。而在 AI 时代，这可能是你能为你职业生涯做的最保值的投资。