人人都能用AI做软件了，公司该让谁来维护

员工说：“老板，这个功能不用买了，我用AI做一个。”

老板当然高兴。但还有一个问题值得接着问：

“半年以后，这个工具出了问题，找谁？”

9月25日，微软公布新版Copilot，其中的Code支持用自然语言创建内部应用、看板和工作流，并配套托管运行环境。按照公告，Code将分批开放，托管环境处于预览阶段。

员工自己开发工具的门槛，正在下降。

这件事有实际价值。一个简单的报价计算器、一张项目进度看板，以前要排研发、讲需求、等上线，现在有机会让最懂业务的人先做出来。

但站在企业交付的角度，我更关心它开始被大家使用之后的事。

想象一个场景：销售做了报价工具，财务做了回款看板，项目经理做了进度系统。每个都挺好用，却各自保存一份客户资料。

客户名称变了，三处谁来更新？折扣规则改了，旧公式谁来检查？原来的制作者调岗了，谁能接着改？

“生成时省下的时间，可能转成后续对账、排错和交接的成本。”

这也是“谁来维护”不能只回答“找IT”的原因。

业务部门要对规则和结果负责；IT或约定的技术服务方负责权限、接口、备份与运行维护；平台供应商承担的服务范围，要看具体产品和约定。有人提供运行环境，并不意味着有人替企业核对报价公式。

我的建议是，员工自建工具一旦准备给团队长期使用，就登记四件事：

负责人是谁。谁确认需求，谁验收结果，人员变动后交给谁。

数据从哪里来。哪份是正式数据，多久更新一次，能不能回写业务系统。

维护范围是什么。谁改业务规则，谁处理技术故障，持续费用由谁承担。

不用了怎么办。数据如何导出，旧入口如何关闭，原来的工作如何接续。

个人临时使用的小工具，可以轻量试验。涉及多人协作、客户资料、报价或付款的应用，则需要相应的审核和交接安排。

我鼓励员工用AI解决具体问题，也希望公司逐渐积累一批有人负责、能持续使用的工具。

“软件生成得越快，越要提前想清楚：谁陪它走过上线之后的日子。”