未来的软件开发,需要什么样的人?

前几天有个功能，需求文档我看过两遍，原型图也点过几下，按理说该清楚了。让 AI 拉了一版 demo 跑起来，才发现自己根本没想明白，加载状态怎么处理，权限不够时跳哪里，第一次进来空数据要不要引导，每一处文档里都没写。我和产品坐下来重新对，发现他也没想过这些。

那一刻我才意识到，团队推 AI coding 这阵子，工具反而不是最难的。真正难的是产品和技术之间那些一直存在、但过去被流程遮住的鸿沟。

我的判断是，未来软件开发最需要的人，不是单纯会写代码的人，也不是单纯会画原型、写需求的人，而是能把模糊想法翻译成真实体验的人。AI 会持续降低「做出来」的门槛，但它不会自动帮我们判断什么值得做、怎么做才算好、一个功能背后真正要解决的问题是什么。

过去的软件开发，更像一条分工明确的流水线。产品提出需求，设计画原型，前端还原页面，后端实现逻辑，测试负责兜底。这个体系当然有它的价值，尤其在复杂组织里，分工能让每个人守住自己的专业边界。但问题也在这里，很多真正重要的东西，并不会完整地出现在原型图和需求文档里。

原型图能画出一个按钮放在哪里，却画不出用户为什么会在这里犹豫。需求文档能写清楚字段和流程，却很难写出这个功能在真实业务里到底是不是关键动作。很多时候，产品觉得自己说清楚了，开发觉得自己按要求做了，最后上线之后才发现，双方理解的不是同一件事。

AI coding 出现以后，这条流水线正在被压缩。一个开发可以更快做出完整 demo，一个产品也可以借助 AI 把想法变成可点击的原型。以前一个想法要经过几轮排期才能验证，现在可能一天就能跑出一个版本。表面看，这是效率提升，往深处看，它其实是在逼每个人面对一个问题，执行变快以后，判断就更贵了。

这件事放到更长的历史里看，并不陌生。电力刚进工厂时，很多老板只是把蒸汽机换成电动机，机器还按原来的方式摆，流程还按原来的方式走，效率并没有立刻飞起来。真正吃到电力红利的，是重新理解了工厂组织方式的人。

AI coding 也是一样。只把它当成更快的程序员，当然也有价值，但价值有限。它真正改变的，是软件从想法到产品的整条路径。过去分散在产品、设计、开发、测试之间的很多判断，会越来越集中到一个人或一个小团队身上。

所以未来真正稀缺的人，不是简单的全栈工程师。全栈这个词更多强调技术覆盖面，前端会一点，后端会一点，部署会一点。但未来的软件开发，需要的是另一种能力结构，有主轴，懂判断，能动手，会协作。

有主轴，是指你必须有一项真正站得住的专业能力。你懂工程，就能判断 AI 写出来的代码是不是可靠；你懂产品，就能判断一个需求到底是不是伪需求；你懂设计，就能判断一个页面为什么让人不舒服。没有主轴，所谓复合能力很容易变成每件事都懂一点，但关键时候拿不住判断。

懂判断，是指你不能只等别人把问题喂到嘴边。你要能看出这个功能为什么要做，用户会不会真的用，复杂度会不会失控，当前版本做到什么程度就够了。能动手，是指你可以借助 AI 把想法先跑起来，不一定完美，但至少能让讨论从空中落到桌面。会协作，是指你知道什么时候该自己推进，什么时候该请更专业的人进来一起把东西做好。

如果这个人是开发出身，他不能只停留在「需求来了，我负责实现」。他要能理解需求为什么存在，能看出原型里没写出来的边界条件，能判断一个交互为什么别扭，也能用 AI 快速试出几个版本，再和产品一起讨论哪个更接近真实用户。这样的开发，不只是执行者，而是共创者。

如果这个人是产品出身，他也不能只停留在「我把原型画好了，剩下交给技术」。他要有基本的可实现感，知道一个需求背后大概牵扯哪些数据、状态、权限和异常。一个看起来很轻的按钮，背后可能是一整套流程；一句「智能推荐」，背后可能是规则、搜索、向量、模型，甚至只是人工运营。

对开发人员来说，第一件要补的不是学怎么当产品经理，而是训练产品判断。开需求会的时候，不要只听字段、接口和排期，要多问几句，这个功能解决谁的问题，用户现在不用它时怎么完成任务，不做会有什么损失，做了之后用什么证明它有效。这些问题不是抬杠，是让自己进入问题本身。需求会上多问一句，后面可能就少返工三天。

接下来是审美。这里的审美不是会做漂亮页面，而是能判断一个东西像不像成熟产品，按钮有没有主次，信息有没有层级，表单会不会让人烦，空状态是不是像临时补丁，错误提示是不是让用户更焦虑。开发以前可以把这些交给设计，但当 AI 能快速生成页面时，开发自己的审美就直接决定了 demo 的质感。

还有表达和拆解。AI coding 吃的不是愿望清单，而是清楚的上下文、约束和验收标准。能不能把大任务拆成小任务，能不能告诉 AI 哪些地方不能动，能不能描述什么叫完成，能不能发现结果哪里不对，这些过去叫沟通，现在会直接变成生产力。

对产品人员来说，最重要的是补技术理解和动手能力。这里不是要求产品转行写代码，也不是要求每个人都能独立上线系统，而是至少能用 AI 做出一个粗糙但真实的 demo。静态原型很容易藏问题，一个页面安静放在那里，总是显得合理；可一旦它真的能点，加载、失败、空数据、权限、返回状态，全都会冒出来。

举个很小的例子，一个产品说「支持撤回」。原型上可能只是多一个按钮，但真正跑起来，问题会马上变多，撤回后对方要不要收到通知，撤回记录要不要保留，已经被审批或引用的数据还能不能撤回，撤回失败怎么提示，后台要不要留下审计日志。这些不是技术在为难产品，而是一个需求进入真实系统后必然要面对的重量。

产品人员自己做过 demo 之后，和开发沟通的姿态会变。过去是「我画好了，你来实现」，以后更好的方式是「我先跑了一版，发现这里有几个问题，我们一起看怎么处理」。这个变化很小，但很关键，它会把产品和技术从交接关系，推向共创关系。

不管是开发还是产品，被推到这个位置上，第一反应往往是焦虑，是不是又要多学一堆东西，是不是要把自己训练成什么都会的六边形战士。我的看法相反。真正要紧的不是六边形，而是守住自己的主轴，再补上能跨过鸿沟的几种能力。开发守住工程能力，补产品判断和审美；产品守住需求洞察，补技术理解和 AI 动手能力。

这不是让每个人都变成一个小团队，也不是否定专业分工。复杂系统依然需要架构、稳定性、设计质量和长期维护，真正专业的人永远有价值。变化在于，软件开发的前半程会越来越轻，谁能把模糊需求先跑成一个可讨论、可验证、可迭代的东西，谁就更容易拿到主动权。

说到底，AI 让执行越来越快，也会让错误方向跑得越来越快。人真正要练的，是判断什么值得做，知道什么不该做，也知道一件事做到什么程度，才算真正做好。