产品思维 + 复杂问题解决能力：程序员拉长职业生命周期的两条主线

AI 编程 Agent 的变化越来越明显。早期用 AI 编程，还得频繁确认命令、检查修改、拆分任务，本质上还是人在写代码，AI 在辅助。这个边界正在快速移动。Agent 开始能自己读项目、理解上下文、改多个文件、跑命令、检查结果，然后根据执行结果继续调整。多 Agent、并行任务、长时间自主执行也在逐渐成熟。这带来一个现实的变化：标准化、流程化的代码生产正在变便宜。很多程序员因此产生危机感——如果 AI 写代码足够快、足够便宜，程序员还能靠什么建立长期竞争力？

我的答案很简单：产品思维和复杂问题解决能力。这两项未必最容易量化，但很可能是 AI 时代程序员最值得长期积累的两条主线。

过去很长一段时间，程序员的大部分价值来自“实现”。需求来了——分析数据库怎么设计、接口怎么定义、代码怎么组织，然后开发、联调、测试、上线。这套能力依然重要。问题在于，实现本身正在快速变得廉价。CRUD、DTO 转换、通用工具函数、常规接口、单元测试、简单 Bug 修复，甚至中等复杂度的重构，AI 已经能完成得不错。过去一个需求可能是“产品给需求 → 开发理解 → 开发编码 → 开发调试 → 测试验证”，未来越来越可能变成“人定义目标和约束 → Agent 实现 → 自动测试 → 人审核和验收”。真正发生变化的不是“程序员还写不写代码”，而是代码在整个软件生产过程中的价值占比在下降。当代码生产能力不再稀缺，仅仅“能按照需求把功能写出来”很难继续构成足够强的竞争壁垒。

AI 目前有两个明显的问题。第一，它很难判断一件事值不值得做。第二，当问题本身定义不清楚、信息残缺、现实约束复杂时，它很难独立承担最终决策。这恰好对应了两种越来越重要的能力：产品思维，和复杂问题解决能力。

一提到产品思维，很多程序员会想到画原型、写 PRD、分析用户需求，觉得那是产品经理的事。其实不是。工程师需要的产品思维，本质上只有一句话：不要只关心“怎么实现”，还要知道“为什么实现”。比如业务提了一个需求：需要增加一张实时统计报表。没有产品思维时，工程师首先想到的可能是数据从哪里取、要不要建统计表、查询压力怎么样、是不是要加缓存。这些问题都对。但在此之前还有一个更重要的问题：为什么需要这张报表？继续追问可能会发现，运营真正需要的只是及时知道某个核心指标有没有异常。如果是这样，也许根本不需要花两周时间开发一套完整报表，一个已有数据看板、一条定时统计任务，甚至一个异常告警，就能解决 80% 的问题。这就是产品思维带来的变化——你能开始区分需求描述的解决方案和需求背后的真实目标。

实际工作中，大量需求并不是完全错误，而是投入产出比不合理。所以我越来越觉得，接需求时至少应该养成几个习惯：这个功能解决谁的问题？不做会怎样？有没有成本更低的办法？上线之后怎么判断它有没有价值？这些问题不会让程序员变成产品经理，但会明显改变参与项目的方式。以前你可能在等“需求定好了，你来开发”，后来会逐渐变成“这个问题我们怎么解决”——少了几个字，角色完全不同。产品思维还有一个容易被忽视的部分：完整的成本意识。技术人员很容易把成本等同于开发工期——几天还是五天。实际上真正的成本远不止这些，后续维护、服务器资源、运维复杂度、系统耦合、数据迁移、用户学习成本、未来修改的代价，都要算进去。成熟的技术方案通常不应该只有一个，面对同一个需求，可以同时有一周上线的轻量方案、相对完整方便持续迭代的方案、为未来规模增长预留空间的方案。工程师真正重要的能力，不是永远选择“技术上最好”的那个，而是知道当前阶段该选哪个。

如果说产品思维解决的是“我们应该解决什么问题”，那复杂问题解决能力解决的就是：面对一个没有标准答案的问题，怎么把它解决掉。大部分编码任务有一个共同特点：目标相对明确。实现一个登录接口、增加一个查询条件、写一个消息消费者——即使实现有差异，问题本身是清楚的。但真正困难的工程问题不是这样。线上偶发故障，没有稳定复现路径；一个运行多年的系统需要重构，但不能影响现有业务；多个业务线需求冲突，研发资源有限；系统出现性能瓶颈，数据库、缓存、网络、业务逻辑都可能是原因；旧系统逐步迁移到新架构，还要保证数据一致性和随时可回滚。这种问题最大的特点是，没有人能把完整需求文档交给你，甚至一开始连“真正的问题是什么”都不知道。你需要自己找信息、排除干扰、建立假设、验证假设，然后逼近根因。AI 在这里当然有价值——分析日志、阅读代码、搜索资料、生成验证脚本、提出可能的原因。但最后真正困难的部分往往是：哪些信息可信？哪个风险可以接受？哪个方案在当前环境里最合适？如果判断错了，怎么回滚？这些问题在 Stack Overflow 上没有可以直接复制的答案。

有些工程师处理复杂问题很强，看起来是经验丰富、直觉准确。但这种能力可以训练。我倾向于把复杂问题拆成这样一个过程：现象 → 目标 → 约束 → 假设 → 验证 → 方案 → 风险 → 兜底。先别急着解决问题，而是确认现象——哪些事确定发生了？哪些只是推测？预期状态是什么？然后梳理约束——时间有多少？能不能停机？历史数据能不能改？涉及几个系统？有没有兼容要求？失败了能不能回滚？接下来才提出多个假设和方案。很多问题越处理越乱，不是技术能力不够，而是太早进入了“写代码解决”的状态。看到数据库慢就加索引，看到接口超时就调线程池，看到内存上涨就加 JVM 参数。这些动作可能都没错，但如果问题定义错了，越努力离根因越远。复杂问题解决能力的核心恰恰是：在信息不足的情况下，仍然能建立一套逐步缩小问题范围的方法。这项能力很难被某一种具体技术淘汰。今天可能是 Java 服务的问题，明天是数据库，后天是 AI Agent，技术栈一直在变。工具会变，但解决问题的方法不会那么快过时。

产品思维和复杂问题解决能力，单独看都重要，组合起来价值更大。产品思维帮你选对问题，复杂问题解决能力帮你把真正重要的问题解决掉。只有后者，容易变成“技术能力很强，但一直在解决不重要的问题”。一个需求技术挑战很大，花了两个月做了一套漂亮的架构，最后发现用户根本不需要。反过来也一样。只有产品思维，能分析价值、讨论方向，但碰到线上故障、系统瓶颈、历史技术债时无法推进，最后只能停留在方案层面。所以我更愿意把程序员未来的核心能力理解成三个层次：看懂问题 → 定义问题 → 解决问题。写代码会越来越像其中的一种执行手段。

很多人担心 AI Agent 会让程序员价值下降。换个角度看，它其实是在重新分配价值。以前工程师大量时间花在写代码、查 API、改参数、补测试、样板工作上，真正分析问题和设计方案的时间反而有限。AI Agent 普及之后，这个比例会变。未来一种常见的开发方式可能是：人定义目标和边界 → AI 完成标准化实现 → 人检查关键决策和风险 → AI 根据反馈继续执行 → 人负责最终结果。这时候，“会不会写某段代码”的价值下降了，但另外几个问题的重要性上升了：你能给 AI 一个正确的问题吗？你能定义清楚验收标准吗？你能发现 AI 没有意识到的风险吗？AI 给出三个方案，你能判断该选哪个吗？所以我越来越觉得，未来真正会使用 AI 的工程师，不一定是 Prompt 写得最好的，而是最知道“应该让 AI 做什么，以及怎么判断它做得对不对”的人。而这背后，本质上还是产品思维和复杂问题解决能力。

这些能力不需要等到成为架构师或技术负责人再开始训练，很多都可以直接发生在日常工作中。接需求时多问一步，以前是“这个接口需要加三个字段”，现在可以继续问——为什么需要这三个字段？前端具体用来解决什么问题？不是为了质疑需求，而是建立完整上下文，很多时候理解了目标，实现方案反而更简单。遇到稍微复杂的问题，刻意要求自己至少考虑两个方案，然后比较开发成本、维护成本、风险、扩展性、上线周期。时间久了，训练出来的就不只是编码能力，而是技术决策能力。主动处理那些“不好写成需求”的事，真正能提升复杂问题解决能力的，往往不是普通 CRUD，而是大家都觉得麻烦的问题——线上偶发故障、性能问题、遗留系统改造、复杂数据迁移、跨系统问题。这些事折磨人，但也是很好的训练场，它们逼着你从“别人告诉我怎么做”逐渐变成“我自己判断应该怎么做”。做完之后复盘，最开始的判断哪里错了？真正有价值的信息是什么？哪些排查步骤可以省略？下次遇到类似问题怎么更快定位？这种复盘积累几年，会变成一种很难通过教程获得的工程直觉。

如果继续走技术路线，未来架构师、TL、技术负责人的价值，可能越来越少体现在“比团队所有人都更会写代码”，而更多体现在理解业务目标、设计整体方案、拆分复杂任务、识别关键风险，让人和 AI 一起把事情做成。另一条路线是向业务复合型角色发展，比如业务架构、解决方案、技术产品。这条路线不一定要放弃技术，而是把技术从“主要产出”逐渐变成“解决业务问题的工具”。当 AI 把实现成本进一步压低，真正理解一个行业、理解用户、理解业务流程，同时又具备技术判断能力的人，价值可能会进一步上升。我并不认为程序员现在应该急着“逃离编码”，恰恰相反，代码能力依然是非常重要的底层能力，只是不能再把全部筹码都押在“我比别人更会写代码”这件事上。

AI 不会让软件工程消失，但会重新定义软件工程师的工作。过去大量时间用于生产代码，未来我们可能把越来越多时间花在定义问题、设计方案、制定约束、验证结果和承担决策上。这也是为什么，相比追逐某一种编程语言、框架甚至某款 AI 工具，我更愿意长期投资两种能力：产品思维和复杂问题解决能力。产品思维让你知道什么值得做，复杂问题解决能力让你面对没有标准答案的问题时，依然能把事情推进下去。代码、框架、IDE、AI Agent 都会继续变，今天是 Claude Code、Codex，明天会有新工具，今天流行的技术栈，几年后可能不再热门。但只要软件仍然是为了现实世界中的人和业务解决问题，那么发现真正有价值的问题，并在复杂约束下把它解决掉——这两件事就很难过时。这或许才是程序员真正能拉长职业生命周期的护城河。