AI浪潮下的双重困境
在生成式AI重塑产品开发范式的今天，CODER与产品经理正面临前所未有的挑战。
开发者发现，传统编码能力逐渐可以被AI工具协助甚至替代，比如现在比较火的Cursor、Trae、Copilot等，还有更多其他的AI编程助手如Devin、Windsur、Continue 以及 Cline，它们可生成40%～60%不等的基础代码，甚至都能够进行复杂算法的设计。
产品经理的困境同样显著：AI助手可快根据想法快速产出需求文档、UI原型、PRD。
这几年一度盛传AI会让程序员失业，让产品经理失业。但是我们都知道虽然2=1+1只有1个加法算式，但是100却可以有49种两位正整数加法算出来，而不加以限制的话，这个组合就几乎无穷无尽了。所以AI的出现，某种程度上来说让开发和产品拥有了一只画出无限可能的笔——我们达到相同目的的路子越来越多，如果我们不定下目的，那么我们能达到的目的也越来越多了。
AI赋能的矛盾性：突破与局限并存
回到现实，笔者作为coder这几年也是在不断尝试和体会AI，也进行了一些思考。
我发现了现阶段用AI参与现有业务逻辑所遇到的困境。
AI在改造存量系统时表现乏力。本来我们的存量系统是经过十多年的迭代，需求十分复杂，逻辑更别提了，想让AI来快速了解存量系统的需求，除非我们从开始到现在的十几年间我们的整个开发管理流程都做的十分规范，有文档，有图，有原型，然后我们才有可能让AI通过这些十分规范的输入来产出系统，但是这仅仅是有可能，因为在项目管理过程中，用户的需求往往不是固定的，易变更的，在时间的累积下，这些变更导致的结果往往不可控，而让不可控的AI来实现不可控，目前暂时做不到。至于敏捷编程实现的系统，就更不用提了。
但是，如果项目一开始就让AI参与，从需求文档到设计用例；从原型到设计；从coding到单测；从打包到部署；那么就实现了一种情况，AI做的东西AI自己改，也许是1条路子，至少要比当现有系统的bug修改师更靠谱。也要感谢前面十几年，技术架构这块的迅速发展，技术人员不断的造脚手架，框架，设立各种开发范式，低代码，无代码，以期让实际的开发变的更容易，更快。当然大家也做到了，几乎近几年不管是前端后端还是客户端运维，想要搭建1套自己的系统，不要太容易，github上代码一拉，命令1敲，分分钟的事。几乎卷无可卷。而这一切，仿佛冥冥中为AI时代打下基础。技术人员做一套系统也许要花点时间搜索整合，但用过Trae等AIEngineer的就会发现，这些基础的东西，只需发出一句自然语言的要求即可在数秒内做到。
所以，AI也许不能改变“过去”，但是也许它能帮我们实现“未来”。
AI重构协作范式 让产品更易实现
当CODER掌握产品思维，能精准定义AI需要解决的问题边界；当产品经理理解MCP协议下的API调用逻辑，可设计出更符合技术实现路径的方案。这种“T型能力”的结合，使AI从执行工具进化为创新加速器。但是我作为coder，个人感觉在和AI结合的路上开发人员是要优于产品的。一名合格的开发在几年的开发过程中，随着和产品经理的耳濡目染和激烈交锋，相信都能积累一定的做产品的经验。抓住重点，帮用户解决问题，让用户爽，那么做出的产品一定有人买单。
回到实际的产品开发过程中，让AI帮忙实现界面比较简单，但是实现创新的逻辑往往有一定难度，如果你和AI说我要实现1个俄罗斯方块游戏，easy，因为俄罗斯方块的代码实在太多了，随便AI就能给你整1个想要的语言过来。但是你和AI说，我们来实现1个新的游戏，游戏的规则是什么，1，2，3，4，5，6，7条列出来，帮我实现吧。AI一定是在loading,loading再loading。目前AI很难直接就把人的想法实现，而需要人把这些想法进行拆分，拆分出它可以理解的东西，它才能快速实现。而需求拆分，转化逻辑，可不是所谓“我不管，我只要结果”的产品经理所能擅长的。
因此可以肯定的是，未来能够吃到AI红利的只有两种，会产品的开发人员；和懂开发的产品经理。
AI的浪潮下，我们都需要自我救赎，不停歇的学习才是丈量脚下能走多远的利器，谨以此文与大家共勉。
