AI 时代，程序员不能只等需求：从写代码走向发现问题
最近我越来越常想一个问题：当 AI 和 Agent 越来越擅长写代码时，程序员真正应该积累的能力到底是什么？
我经常和同学吐槽「完了跑路吧，转行吧，创业吧」。可我也刚入行不久，代码几乎都是 AI 在写。摸鱼的时候，我把想说的话、想的事写了下来——把这段时间做项目的经历，以及由此产生的一些思考整理出来。
一、从一个 AI 生图工作流开始
我最开始接到的任务，是做一个能串联多个 API 的工作流，让公司可以批量生成商品图片。
后来，系统逐渐增加了套图、商品详情页、标签等生图能力。为了让内部员工持续使用，我又补上了权限管理、管理员功能、图库、使用记录、费用记录，以及员工使用情况统计。再往后，我开始把智能体接入系统，尝试通过对话和多智能体协作，辅助运营人员讨论新品想法、生成商品素材；同时也要处理生图过程中的并发控制和稳定性问题。之后，系统又扩展了画布编辑和视频生成能力。
这已经不只是一个简单的生图工具，而是一套围绕电商素材生产流程不断扩展的内部 AI 应用系统。
但在这个过程中，我慢慢意识到一件事：功能做得越来越多，并不意味着我就真正理解了这个行业。
二、把需求做完，不等于知道问题在哪里
日常开发中，很容易形成一套固定的工作模式：
老板提出需求 → 开发分析并实现 → 员工开始使用 → 出现问题后继续修改。
这种模式本身没有错——任何系统都需要响应业务需求，也需要有人把功能真正做出来。
但如果我的工作始终停留在这个环节，那我觉得自己被 AI 优化是迟早的事。我今年刚毕业，再这样干几年到 30 岁，恐怕也会被裁掉，最后去参加「铁人三项」。后来我看这个系统每天都有人在使用，但给我的真实反馈却很少，我也很难了解到他们的主要问题和实际痛点。
比如，运营人员提出「希望 AI 生图更快」。如果只围绕这个要求开发，最后可能是提升生成速度、增加批量任务能力。但实际工作中，运营人员真正花时间的地方，也许不是等待图片生成，而是反复修改图片、筛选结果、重新提炼卖点，或者把生成的素材调整到符合业务要求。
这些只是可能出现的情况，并不代表每家电商公司都存在同样的问题。关键在于：提出的需求往往是用户对问题的一种解释，不一定就是问题本身。
如果只负责把功能实现出来，我可能解决了一个明确的需求，却错过了更值得研究的原因。
三、所以，我开始尝试让系统主动收集反馈
有了这个想法之后，我开始考虑：能不能让系统不仅用来完成工作，也能帮助我更直接地了解员工使用时遇到了什么？
于是我在系统里增加了对话和问题反馈功能——员工可以像用聊天工具一样，在系统内部向我提问、反馈问题。我用 WebSocket 实现实时通信，让反馈不必完全依赖层层转达。
我还加入了企业微信消息推送，通过 Webhook 把需要关注的信息推送给自己；同时增加定时检查，让系统能按计划检查运行状态，而不是所有问题都等员工发现后再通知我。
这些功能当然还不能让我直接了解整个电商行业，但至少为我建立了更接近一线使用者的渠道。
过去，我主要通过已经整理好的需求来了解业务；现在，我希望逐步看到：员工在什么环节遇到麻烦、哪些问题反复出现、哪些功能真正被使用，以及系统在哪些地方没有达到预期。
不过我也意识到，增加一个反馈入口，不等于真正完成了需求发现。 如果员工每天发来十个问题，而我只是逐条修复，那本质上仍然是在被动响应。
更有价值的做法，是从这些反馈里寻找重复出现的模式：是不是很多人遇到了同一个问题？问题来自某个功能，还是来自更上游的工作流程？解决它之后，究竟能减少多少时间、返工或沟通成本？
这意味着，收集反馈只是开始，归纳、验证和衡量同样重要。
四、AI 让「实现功能」更容易之后，我重新思考程序员的价值
现在，AI 编程工具和 Agent 已经能帮助开发者完成不少代码编写、调试和常规任务。对于一些边界清晰、实现路径成熟的需求，完成初步实现的成本正在下降。
这让我有些焦虑：如果我的主要价值只是把别人描述好的需求翻译成代码，那么当 AI 也能完成其中越来越多的工作时，我的优势在哪里？
尤其是刚毕业的人，项目经验、系统设计能力和行业认知都还在积累。如果又只习惯等需求、写代码、修问题，确实很容易陷入被动。
但我不认为因此就能得出「程序员没有价值了」的结论。真正的开发工作不仅是生成代码，还包括理解约束、判断方案是否合理、处理复杂系统中的异常、保障安全与稳定，并对交付结果负责。
我更愿意把问题理解为：如果只靠编码执行能力建立竞争优势，这种优势可能越来越难长期维持。
写代码仍然重要，但我希望自己逐渐具备更靠前的能力：理解业务是如何运转的，发现真正影响效率和结果的问题，判断这个问题值不值得解决，再用合适的技术把方案落地。
这不是从「技术」转向「空谈想法」，而是希望把技术用在更值得解决的问题上。
五、我想培养的，不只是开发能力，而是一套发现问题的方法
我现在越来越觉得，主动发现问题并不是凭感觉想创意，而是要接近真实的工作现场，持续验证自己的判断。
如果以后进入一个新的行业，我希望自己能先问几个问题：
- 完整的工作流程是什么？ 从任务开始到结果交付，中间经过哪些角色、环节和工具？
- 人们把时间花在哪里？ 哪些工作需要反复复制、整理、沟通、核对或返工？
- 问题出现在哪里，影响有多大？ 是偶尔发生的小麻烦，还是频繁发生、会影响成本、效率或业务结果的问题？
- 现在为什么没有被解决？ 是现有工具不好用、数据不连通、流程设计不合理，还是解决成本太高？
- 这是不是一类普遍问题？ 它只属于某个团队，还是其他岗位、其他公司也可能遇到？
- 怎样低成本验证？ 能不能先用访谈、数据观察、简单原型或小范围试用，确认方案确实有效，而不是一开始就开发一套完整系统？
这些问题不能让我立刻成为行业专家，但能帮助我避免刚进入一个行业就急着写系统。
同时我也要承认：理解行业不是看几篇文章、做几个功能就能完成的事。它需要持续接触真实业务、与从业者交流、观察实际流程，并用事实修正自己的判断。
写在最后
刚毕业的我，还有很多东西不懂。比如，我能把一个 AI 应用做出来，却未必能把系统设计中的每个技术选择都解释得足够深入；我能收集到员工的问题，却还需要学习怎样从中提炼出经过验证的产品机会。
但我觉得，意识到这些不足，比只关注自己完成了多少功能更重要。
AI 时代，我不想只做一个等待需求、负责实现的程序员。我希望自己既能写代码，也能理解业务；既能使用 AI，也能判断 AI 应该解决什么问题；既能交付功能，也能验证它是否真的创造了价值。
对我来说，下一步不是少写代码，而是不只盯着代码。
也想听听大家的看法：当 AI 越来越擅长实现功能时，你认为开发者最应该长期积累的能力是什么？是技术深度、行业理解、发现问题的能力，还是把问题真正解决并交付结果的能力？
（这篇是我和 GPT 对话之后整理的。我有时会焦虑——五年后我还在做这行吗？十年后我又在干什么？此篇我也放在 CSDN、知乎和博客上，希望五年后、十年后的我再次读到这篇文章时，还能记得当初的迷茫与期待。）
愿未来的我，依然保持好奇，持续成长，拥有选择自己人生的能力。
写于 2026 年 10 月 24 日
阅读原文：CSDN 版