ARTICLE · 1300335
AI 改变软件生产之后:研发团队会缩小,还是去做更多事?
上一篇聊完软件行业的钱会流向谁，我又想到一个更贴身的问题。
当 AI 能帮我们更快地完成开发，公司会把省下来的时间拿去做新业务，还是把省下来的人力从预算里划掉？
这件事，对老板来说是经营选择，对程序员来说，可能就是下一年的收入和房贷。
我的判断是，两种情况都会发生，甚至会同时发生在一家公司里。有的项目减少用人，有的业务继续招人；团队总人数没变，每个人负责的范围却扩大了。
一个项目需要的人少了，一家公司做的软件可能更多了，留下来的程序员也可能更忙了。
这几件事，可以同时成立。
所以，我们需要看清楚的，是公司准备怎样使用 AI 带来的生产能力，以及自己会被放到什么位置。
01 一家公司，算的是几笔不同的账
最近的政策已经把这种变化摆到了台面上。
今年 9 月，工信部在《“人工智能+软件”专项行动实施方案》解读中专门谈到就业，提出从稳岗、扩岗、转岗三个方面推进。这说明，产业升级与就业调整需要一起考虑。政策提供方向和支持，具体到一家企业怎样招聘、怎样安排岗位，仍然取决于经营情况。
企业面前，实际有几笔不同的账。
如果客户数量没有增长，产品也进入维护期，公司眼下最紧张的是现金，那么 AI 提效之后，管理层更容易考虑压缩成本。变化未必立刻表现为裁员，也可能是停止补人、减少外包，或者把原来的项目合并。
如果公司有明确的市场机会，一些功能过去因为成本高、排期长，一直没有投入，那么开发成本下降，就可能让这些项目重新值得尝试。同样的团队，可以覆盖更多客户，验证更多产品想法。
还有一些企业，开发人员本来就长期耗在系统对接、历史问题和内部流程上。AI 省出来的时间，可能先用于补欠账。员工更忙了，短期收入却未必增加，因为新投入还没有变成客户愿意付的钱。
因此，判断一家公司会不会扩张，不能只看它买了多少 AI 工具。更值得看的是：有没有真实需求，新增业务能否赚钱，公司有没有能力把产品卖出去、长期维护好。
开发便宜了，确实可能让更多需求成为生意。但市场增加的需求，也可能被竞争对手拿走。
对一家外包公司尤其如此。如果客户按实际投入的人数采购，人员需求下降就可能直接压缩合同金额；如果公司能用更少投入交付明确成果，则可能改善利润。最后留下多少收益，还要看议价、返工和后续维护。
工具提高的是生产能力，企业如何使用这份能力，还要经过市场和管理的选择。
02 代码快了，组织为什么没同步变快
软件生产里并不只有写代码。
10 月 20 日，Atlassian 发布的研究解读提到，在其 2026 年开发者体验调查中，87% 的受访开发者认为 AI 帮助他们更快交付工作，但 72% 表示，工作流程中的阻碍与使用 AI 之前相同，或变得更多。
这是受访者的体验，不能直接推算中国研发团队的裁员比例。但它揭示了一种值得重视的情况：个人完成任务更快，整个组织未必同步变快。
设想一个退款功能。
AI 可以帮助生成页面、接口和测试。但订单已经部分履约时怎么退，优惠券怎样处理，财务按哪一种口径记账，谁有权限例外审批，这些规则仍然需要业务和技术共同确定。
规则没说清楚，代码越快生成，后面需要重新确认和修改的东西就可能越多。
当生成代码的速度提高，需求取舍、系统集成、质量验证和上线后的运行情况，就更可能成为限制交付的环节。
研发主管需要找到这些地方。只要求大家多开几个 AI 窗口、多提交一些代码，并不能自动缩短客户拿到可用功能的时间。
03 下一张研发组织图，会围绕责任重组
在这个基础上，我认为未来的研发分工，会更多围绕几类责任重新组合。以下是对组织变化的判断，并非已经统一形成的新岗位标准。
有人需要更深入地把问题定义清楚
客户说要一个智能助手，真正需要解决的可能是查询慢、规则分散，也可能是跨部门审批耗时。哪些可以通过软件改善，哪些需要调整流程，怎样判断做完有效，都要有人推动形成共识。
这部分工作可能由产品经理、业务专家和工程师共同承担。对程序员而言，能够理解问题、发现约束，会直接影响后续技术方案的质量。
有人需要把变化可靠地接进现有系统
很多企业已经有多年积累的订单、支付、库存和权限体系。新增功能需要和这些系统一起工作。接口怎么兼容，数据怎么迁移，故障怎样隔离，升级失败能不能恢复，都需要技术判断。
架构、数据库、网络、性能和排障能力，在这里仍然有明确用途。技术越深入，越有可能处理那些表面上只改一个功能、实际上牵动很多地方的问题。
有人需要让验证跟上生产速度
当代码更容易产生，团队需要知道哪些测试能覆盖真实风险，哪些变更必须仔细审查，哪些指标能尽早发现故障。如果产品本身使用 AI，还需要评估回答是否可靠、成本是否可控、模型更新后效果有没有退步。
测试、开发和运维之间的配合会更紧。判断质量的工作也可能进入更早的设计阶段，减少问题集中到上线前才暴露。
有人需要建设让整个团队更顺畅的公共能力
清晰的开发环境、可信的内部文档、可复用的组件、自动化验证和稳定的发布流程，都能让人和 AI 少走弯路。这类工作不一定每天产出客户看得见的新功能，却可能持续减少整个公司的重复劳动。
这些责任并不对应四个必须新设的部门。小公司可能由几个人共同承担，大公司可以保留专门团队。
一种可能的组织形态，是业务小组能够完成更完整的交付，同时由平台、安全和基础技术团队提供共享支持。减少等待和反复交接，才有机会把个人提效变成团队提效。
这也要求职责说清楚：谁作决定，谁提供专业判断，谁有权暂停一次风险过高的上线。把更多责任压给一个人，却不给资源和权限，只会增加新的问题。
管理岗位同样会被重新衡量。整理进度、汇总周报的工作可以得到工具帮助；业务发生冲突时怎样取舍，人员怎样培养，资源怎样分配，仍然需要管理者认真承担。
未来的组织图可能变化很大，但岗位名称改得再新，也要回答具体由谁把工作做好。
04 当简单任务交给 AI，新人从哪里成长
说到这里，还有一个很容易被忽略的问题：新人从哪里成长？
过去，很多程序员从小功能、简单接口和基础测试开始。任务本身不复杂，但人在这个过程中逐步理解系统，也学会处理错误。
如果这些任务越来越多地交给 AI，企业又只愿意招聘能独立解决复杂问题的人，那么人才培养中间就可能出现断层。
今天要求更多有经验的工程师，几年后这些经验从哪里来？
Anthropic 今年发布的一项研究，让 52 名以初级工程师为主的参与者学习一个不熟悉的 Python 库。研究观察到，使用 AI 的方式与学习表现有关：高度依赖代做的模式表现较弱，主动追问原理、理解生成内容的模式表现较好。
这个规模有限、任务特定的实验，不能代表所有工作场景，但提醒我们关注交付之外的学习过程。
对企业来说，培养新人需要重新设计。可以让新人借助 AI 做实现，同时要求他解释方案、找出边界情况、补充验证，并跟随有经验的同事观察上线和故障处理。
如果公司只检查任务有没有关掉，就很难判断员工是否真正掌握了系统。
对新人来说，使用 AI 之后仍然能够解释程序为何这样运行，出现错误时能够提出验证办法，是值得保留的成长目标。
有经验的人也不能只靠年限。熟悉某个系统的历史，只有在能够解释设计取舍、减少迁移风险、帮助别人解决问题时，才更容易成为组织认可的价值。
这轮变化也会影响我们怎样评价自己的工作。
以前，有人习惯用完成多少需求、写了多少代码说明贡献。以后，这些数字可能越来越难反映真实难度。
让一次发布少返工，让一个核心接口更稳定，让几个团队能够复用同一项能力，让客户的关键流程真正跑通，都需要被看见。评价这些成果时，也应记录团队协作和实际约束，避免把业务波动全部算到一个工程师头上。
同样，员工能够承担更完整的工作，公司也应该让权限、资源和回报跟得上。
技术进步怎样分配收益，需要制度和协商。个人学习再努力，也不能单独决定公司的预算和整个市场的需求。
我是房贷压不垮的码农。
我当然希望工具进步能让我们少熬夜，让软件更可靠，也让普通人有机会完成过去需要大团队才能做的事情。
但站在每个月要还房贷的位置上，我更关心一件具体的事：公司省下来的时间，最后用在了哪里？
如果它变成了更好的产品、更多愿意付费的客户，以及员工能够持续成长的空间，研发团队就有机会继续创造新的需求。
如果它只变成更高的任务量，而沟通、验证和维护的条件没有改善，那么人数即使没变，工作也可能越来越难。
所以，观察自己所在公司的下一步，可以先看它如何安排提效之后的投入：招聘哪些能力，解决哪些长期问题，愿不愿意培养新人，又怎样评价和回报员工。
这些具体选择，会逐步画出下一张研发组织图。
再往前一步，还有一个问题值得继续讨论：
当企业开始自己用 AI 做软件，外包和软件公司的生意，会被收回去，还是会出现新的分工？
当客户也有了更强的开发能力，下一份软件合同里，究竟还会购买什么？
判断公司下一步，先看提效后的投入。
它招聘什么能力、解决哪些长期问题、是否培养新人，又怎样评价和回报员工，会逐步画出下一张研发组织图。
