业务人员用 AI 搞软件开发，比 IT 写代码更有杀伤力？

最近在自媒体上看到有不少所谓的业务专家在炫技：自带多年业务经验，加上用各种 AI 搓出来的小工具，小而专、贴场景，甚至扬言说可以取代信息部门了。也有人说，现在有了WorkBuddy之类的AI工具，技术已经平权，最有价值的是业务经验。

那么在现实中确实如此吗？

老杨认为：业务人员加 AI 工具搞软件开发确实有杀伤力，但杀伤力不在"替代 IT 写代码"，而在"绕过 IT 的需求翻译链和交付排队"。真正的问题也不只是 CI/CD，而是企业突然多了一大批"没有工程化意识的开发者"，他们的工具会像野草一样长出来，短期有效，长期可能变成治理灾难。

一、业务专家 + AI Coding 的真实优势：不只是"快"

"最有价值的是业务经验，技术已经平权"，这句话乍一看是那么一回事。业务用 AI 工具搞软件开发，具有如下优势：

1.需求翻译损耗几乎为零。

传统链路是业务提需求、理解、分析、开发实现、测试验收，每多一层翻译就多一层失真。业务自己干，他清楚自己要什么、异常在哪、什么结果算对，AI 只是把他的话变成代码。中间少一层，交付准确率就高一大截。

2.长尾需求被激活。

通常情况下业务部门想做一些个性化的系统功能开发都会去找信息部门，而信息部门永远在排核心系统、监管项目、平台建设，一线大量"小而专"的需求，比如某张报表的自动清洗、某个审批流的自动判断、某个数据的批量处理等等，所以有时候一些业务需求根本排不上。现在业务人员用WorkBuddy可能一个下午就能搓出来，这是产能瓶颈下的有效补充，不是替代。

3.隐性知识显性化。

业务人员脑子里的规则、经验、判断逻辑，以前很难落到系统里，现在通过WorkBuddy之类的AI工具用脚本、小工具就能固化。哪怕工具粗糙，至少知识被记录、可复用，对组织是资产。

4.倒逼业务理解数据和流程。

业务自己做工具，才会第一次发现：原来数据口径这么乱、主数据这么脏、流程有这么多分支。这种"被数据教育"的过程，比 IT 讲十次数据治理都管用。

5.试错成本极低。

业务可以用小工具验证一个想法，不用立项、不用预算、不用等三个月。跑通了再谈工程化，跑不通就扔掉，是典型的敏捷探索。

所以从以上五点就可以看出，业务人员用AI工具搞系统开发优势不在代码质量，而在"领域判断力加快速验证"。WorkBuddy、ChatGPT 生成的代码可能不差，但知道"生成的东西对不对、该不该用、用在哪个场景"，才是业务人员的护城河。

二、比 CI/CD 更深的坑

很多人一谈到业务人员用AI工具搞开发，就会想到 CI/CD ，但老杨认为这些只是表象，更严重的是这些业务自建工具一旦进入生产环境，就变成了"影子 IT"，破坏力远不止迭代困难。具体有如下问题：

第一，安全与合规失控。

业务人员其实根本不懂最小权限、数据脱敏、PII 保护、等保要求。他可能把生产数据拉到个人电脑用 Python 处理，把数据库账号密码硬编码进脚本，把客户信息上传到公共 AI 平台，绕过审批直连核心系统 API。一个业务工具泄露的数据，可能抵过 IT 系统一年的合规努力，所造成的损失甚至比买一套标准软件还是贵。

第二，数据孤岛和口径分裂加速恶化。

这是最不愿意看到但又不得不面对的问题，为了达到各自部门的应用效果，业务人员会各自拉数据、各自算指标。同一个"活跃客户数"，A 部门算 10 万，B 部门算 8 万，C 部门用 AI 生成一段 SQL 又算 12 万。以前孤岛至少还在 IT 可控的数据库里，现在散落在个人电脑、临时脚本、共享网盘、在线 Notebook，什么数据治理在此时全部失效。

第三，技术债务指数级堆积。

AI 生成的代码常常没有测试、没有文档、没有版本管理，路径参数环境全硬编码，依赖某个特定库版本。这些业务人员是根本不懂的，更麻烦的是业务今天跑通了，明天改需求他不会改；人一离职，工具就挂了；环境一升级，工具就崩了。这不是技术债，是技术垃圾场。

第四，责任边界模糊。

业务工具算错数导致决策失误，谁负责？业务说代码是 AI 生成的，IT 说这工具不是我建的，AI 厂商说输出仅供参考。到头来谁都没责任，只有企业自己承担。

第五、架构一致性被打破。

以后信息部门需要面对的可能是一个更乱的技术架构，比如开发部门统一用 Java 加 Spring Cloud 加 K8s，而业务部门可能会用 Python、Node.js、Excel 宏、低代码、RPA。这样做的结果就是：每种工具都是孤岛，运维不知道它存在，安全不知道它跑在哪，架构委员会管不到它。岂是一个“乱”字能说清。

第六、供应链与 AI 幻觉风险。

基于专业性的差距，业务让 AI 引入的开源库，可能有漏洞、有恶意代码、许可证不合规等问题，但这一切对于业务部门来说基本是没有意识与概念的，只有出了问题才知道。而信息部门有软件供应链管理，业务没有。业务也可能过度信任 AI 输出，AI 生成的 SQL 语法正确但逻辑错，业务看不懂执行计划，以为跑出结果就是对的；模型版本一更新、prompt 一微调，那可能的结果就是：今天对明天错，永远在处理错误的路上。

三、不是"业务替代 IT"，而是分工重构

不难看出业务人员用AI工具搞软件开发的杀伤力，不在于写出比 IT 更好的代码，而在于绕过 IT 的管理体系快速产生业务价值。

信息部门此时需要面对现实：IT 的角色必须从"所有软件的建造者"转变为"平台和治理的提供者"。过去 IT 的价值在"实现"，现在实现被 AI 平权了，IT 的价值必须上移到平台工程、数据治理、安全合规、架构标准、可观测性、资产生命周期管理。如果信息部门还是沿用传统的思维来做事，最终的结果可能就是被边缘化，因为那个引以为傲的技术壁垒已经被AI打破了。

四、如何破局？

老杨认为企业当前需要的一套"全民开发"治理框架体系。

1.分级设护栏。

按风险对业务工具分类：

低风险：只读、不碰生产、不对外、不影响核心流程，可以自助；

中风险：读写非核心、内部使用、有一定影响，需 IT 审核；

高风险：涉及核心系统、敏感数据、对外服务、资金合规，必须 IT 主导或深度介入。

2.给业务一个受控沙箱。

信息部门需提供统一的数据平台、API 网关、开发环境，内置身份认证、权限控制、数据脱敏、审计日志、代码扫描、版本管理、监控告警。让业务在沙箱里折腾，而不是直接连生产库。

3.把 CI/CD 封装成一键发布。

业务人员不需要懂 GitLab CI、Jenkins、K8s。信息部门提供模板化流程：上传代码、自动测试、自动扫描、部署到指定环境。让 CI/CD 变成平台能力，而不是业务的负担。

4.建资产注册和指标字典。

业务工具必须注册，数据源、指标定义、负责人、使用范围都要登记。企业建统一指标字典和认证数据源，业务优先用认证源，避免口径分裂。

5.开孵化到转正通道。

业务工具跑通有价值，不能永远散养。IT 评估后"转正"：纳入正式代码库、补测试、做监控、接 CI/CD、进资产清单。业务负责创新，IT 负责工程化收编。

6.培训业务"轻工程化"能力。

不需要业务人员成为程序员，但他们要懂版本管理基本概念、数据隐私合规红线、怎么写简单测试、怎么记录工具逻辑和依赖。这比教他们写 Java 有用。

7.责任共担、成本可控。

业务负责业务逻辑正确性和使用场景合理，IT 负责平台安全、基础设施、运维基线，出问题先看逻辑错还是平台错。AI 调用费、云资源费、存储费归属到业务部门，防止无节制跑大模型、建表、存数据导致成本爆炸。

五、最后总结

业务人员用 AI 工具搞开发，短期看是生产力释放，长期是治理挑战。杀伤力在于"快、准、贴业务"，但如果不加治理，企业最后会收获一堆数据孤岛、安全漏洞、技术垃圾和模糊的责任。

真正要解决的，不是"要不要让他们做"，而是"怎么让他们在受控平台上做"。业务在"点"上创新，IT 在"面"上兜底，双轨接得好才不翻车。

老杨认为未来的数字化组织，大概率双轨制：业务专家造工具，解决最后一公里、快速试错；IT 建平台和治理，提供安全、数据、CI/CD、监控、资产管理的底座。但走这条路需要的是时间的考验。

本文来自微信公众号“湘江数评”（ID：benpaoshuzi），作者：老杨，36氪经授权发布。