大模型是放大器，放大优点，也会放大缺点

最近有很多自媒体都在宣传大模型的能力越来越强了，可以大规模替代程序员了。还有的观点甚至认为现在以GUI交互为主的软件都将被淘汰，被无界面的智能体所取代。真应该给这些自媒体颁发个天天向上的学习奖和信口开河概不负责奖。

先说我的观点：大模型肯定是可以提升工作效率的，但前提是了解它的应用场景，知道谁来用它、怎么用它。大模型是个放大器，会放大企业现有的一切，优点会被放大，缺点也会被放大。

如果一个团队有比较清晰的研发流程，每个角色的人员能力都在岗在线，极限编程里的实践比较充分，有完备的工具层面的支持，这样的团队使用大模型肯定可以带来更好的效果。

相反如果一个团队现在流程混乱，角色职责不清晰，能力参差不齐，工程侧的意识和能力比较薄弱，这样的团队使用AI编程，带来的只能是更多的混乱。

大模型出来后，反而对使用它的人的能力要求更高了。所以，在过去几十年里，整个软件行业所做的提升软件研发效率和质量的所有努力和尝试，依然是有价值的。

这个价值就像是一个数字前面的1，有了这个1，才有大模型作为后面的0，可以形成倍增的效果。如果没有这个1，或者这个价值是负数，那就是完全相反的结果。

所以，但凡做过系统软件研发的人都清楚，代码真的不是越多越好。只要写入代码仓库里，就有维护的成本。并不是说软件写出来放在那儿就能一直稳定地运行。

需求的变动咱们就不讲了，外部的环境也在时刻变化过程中，比如外部接口发生变化、操作系统升级、安全策略调整、第三方应用冲突等等，这些因素都会导致软件无法正常运行。

这就要投入精力去维护，代码层面的维护、运维层面的维护。代码量越多，维护成本越高。所以，AI写入代码仓库的大部分情况下是负债，不是资产。

所以，咱们软件行业的从业的同行们，保持定力，扎扎实实做好咱们碳基人类的工作，然后再有设计、有规划的逐步推进大模型的融入，是比较稳妥的做法。

而要实现这一点，离不开成熟、可落地的管理体系做支撑——禅道产品研发融合管理模型。

该管理模型融合了IPD、Scrum、瀑布、看板、CMMI、SAFe、DevOps、国军标、ASPICE这九大主流管理模型框架和方法，以“双模驱动、三层融合、实践演进”为核心思想：

• 双模驱动：稳态与敏态并存，既保障核心业务的稳健，也支持创新业务的敏捷；
• 三层融合：战略层、协同层、执行层贯通，实现从商业目标到技术落地的无缝对接；
• 实践演进：框架本身具备演进性，支持企业从单一方法到混合模式，再到全系统融合的渐进式提升。

这种“有机融合，动态适配”的思路，赋予了组织一种管理韧性，使其在面对外部环境的不确定性时，能够迅速调整内部协作机制，而非陷入非此即彼的管理方法论之间的取舍，帮助企业构建动态适配的研发管理体系。

在此基础上，禅道AI进一步升级为禅道智能体，为研发管理注入活力，提供了需求润色、一件拆用例、任务润色等项目核心流程场景，让大模型能力与研发流程深度融合、安全可控，真正做到增效不降质。

大家可联系我们了解详情

随着大模型全面渗透研发流程，产品研发的传统形态正被逐渐打破。我们该构建怎样的产品研发形态，才能适配技术变革、提升研发效能？欢迎参加我们禅道中国行3月14日的深圳站和3月15日的广州站。