灌水 "让业务自己改代码"是笑话吗?

Fun_Fox · 2026年11月11日 · 最后由 华全 回复于 2026年11月11日 · 131 次阅读

"让业务自己改代码"是笑话吗?

先说答案:是,也不是。

取决于你说的"改代码"是哪一件事。


一、如果你说的是"让业务去学编程",那确实是笑话

教一个业务同学写 for 循环,语法一周就能学会。

但改坏一个系统,只要一分钟。

这件事的问题不在于学不会,而在于——学了一点,比完全不会更危险。

他知道怎么写一行代码,但不知道这行代码在哪个环境跑、被谁调用、改完会不会让另一个页面空掉。这种"半懂",会让他在评审时说不出"我不确定",在出事后说不出"我当时以为"。

把业务培养成半吊子程序员,不是让他参与开发,是给他发了一张危险驾驶证。

大多数人嘲笑"让业务改代码",脑子里想的就是这件事。

这个嘲笑是对的。


二、但如果你说的是"让业务的判断直接落到系统里",那不是笑话,那是本来该有的样子

业务每天都在改系统。

只是他要经过这样一条路:

他发现问题 → 写在微信群里 → 产品转述 → 排期 → 一周后
→ 做出来了 → 他说"不是这个意思" → 再排一轮

这条路上,他做了全部的业务判断,但一个字的代码都没碰。 他承担的沟通损耗,比他直接改要大得多。

所谓"让业务改代码",本质是把这条链路上的人肉搬运去掉,不是把他变成工程师。

判断权本来就在他手上。变的只是:判断能不能在一分钟内看到结果。


三、真正拦住业务的不是语法,是一张没人画出来的地图

编程语言是显性知识,公开、可搜索、两天能上手。

真正稀缺的是隐性知识:

  • 这张表还有谁在读?
  • 这个字段改成 null 会不会让排行榜崩?
  • 这个接口是不是还有另一个端在用?
  • 这个数值是 MySQL 算的,还是 TDengine 里查的?

这些东西不在任何文档里,只在一个人的脑子里。

所以"让业务改代码"的实质不是降低语法门槛,是把这张隐性地图显性化。

程序员真正的价值不是写代码。是持有这张地图。

地图画出来了,业务才敢走路。地图不画,给他再好的编辑器,他也只敢看不敢动。


四、比"不会写"更硬的墙,是"看不到"

一个人要判断自己改得对不对,只有一种方式:看到结果。

在传统系统里,"看到结果"的成本是这样的:

环节 成本
搭一套能跑的环境 一到两天
改一行,编译 几分钟到十几分钟
部署到能看到的地方 半小时,还要找人
找到能复现这个场景的数据 半天,可能找不到

综合下来:反馈周期两到三天。

两天一轮,业务一年最多试二十次。试到第五次,他自己就放弃了。

三十秒一轮,他一天能试四十次。

这不是意愿问题,是物理问题。

所以"这是笑话"这个判断,八成是在一个没有环境的地方得出的结论。

结论没错,但归因错了——不是业务的能力不够,是系统没给他留门。


五、最容易被忽略的一层:AI 降的不是门槛,是成本

以前业务提一个改动,成本是"一个程序员两天"。

这个成本有一个隐形的好处:它会自动过滤掉那些没想清楚的需求。

"这个需求不划算"、"优先级不够"、"再等等看"——排期本身就是一道筛子。很多半成品的想法,在这道筛子前面自然消失了。

现在成本变成"AI 一分钟 + 一次 review",这道筛子突然被拿掉了。

于是会暴露一件很尴尬的事:

大多数"我想改这个",其实连提需求的人自己都还没想清楚要什么。

以前这个问题被排期掩盖了。现在没有了排期,它会直接摊在桌面上。

所以真正的瓶颈,会从"能不能改"转移到"想清楚没有"。

这是好事。但会很痛。大多数组织没准备好面对这个。


六、什么时候是笑话,什么时候是杠杆

三个条件,缺一不可。

第一,环境。
一条命令起得来,三十秒能看到页面变化,改坏了能一键还原,试错不会碰到生产数据。没有这条,后面两条都是空话。

第二,边界。
明确写下来三张清单:

  • 这些你可以自己改(文案、格式、列顺序、默认筛选)
  • 这些你定规则、我来落代码(排序权重、聚合口径)
  • 这些碰都不能碰(取数来源、数据结构、权限接口)

没有边界的自由,不叫自由,叫事故预告。

第三,责任人。
谁签字,谁背锅。

AI 不会因为线上事故被问责,业务不会因为技术债被问责,只有程序员会。

责任在哪里,决定权就必须在哪里。所以最后那一次"这个改动可以合进去",必须由程序员说。


三个都有 → 这是杠杆。
少任何一个 → 这是笑话,而且会以事故的形式收场。


七、最后说句不客气的

说"这是笑话"的人,通常是在保护自己的稀缺性。

这可以理解。但不成立。

因为稀缺性不该建立在"别人看不到"上,应该建立在"别人做不到"上。

锁住编辑器、把知识留在脑子里、让所有改动都必须经过自己——这不是不可替代,这是把不可替代性建在了信息不对称上。信息不对称是最容易被技术抹平的东西,现在正在被抹平。

写代码这件事,正在从"做不到"变成"看得到就能做到"。

程序员不会因此失业。会因此从翻译器变成建筑师——从"帮别人把话译成代码",变成"设计这个系统允许被怎么改"。

反过来,一个连自己系统都讲不清楚的程序员,才是真正危险的那个。因为 AI 需要地图,而他手里没有。


"让业务自己改代码"是笑话吗?

如果你只给了他一个编辑器,是。

如果你给了他一个能三十秒看到结果的环境、一份写清楚边界的说明书、和一个愿意把地图摊开讲的程序员——

那就不是笑话。

那是把一个只会执行的组织,变成一个会自我修正的组织。

共收到 2 条回复 时间 点赞

最大的逻辑问题,是把「AI 降低了代码修改门槛」等同于「业务人员具备了软件工程能力」。

我不反对让业务人员参与代码修改,但反对把这件事描述成程序员的价值正在从编码转向架构设计。

有几个问题值得重新思考。

第一,看到结果不等于知道结果正确。

页面正常不代表业务逻辑正确,功能跑通不代表没有破坏其他功能。

修改一个退款规则,可能影响订单状态、财务对账、报表统计和下游接口。业务人员看到当前页面正常,并不能证明整个系统正常。

软件工程解决的从来不只是代码能不能运行,而是如何证明系统在各种场景下都符合预期。

第二,系统知识显性化,不代表系统复杂性消失。

把文档补齐,把调用关系画出来,确实能降低理解成本。

但分布式事务、并发控制、数据一致性、缓存失效、接口兼容、故障恢复,这些不是画一张架构图就能掌握的。

知识可以共享,专业能力不能通过共享文档自动复制。

第三,业务决策权不等于技术实现权。

业务决定退款规则,不代表业务知道如何保证退款幂等。

业务决定排行榜权重,不代表业务知道如何避免全量计算导致数据库崩溃。

业务应该决定系统做什么,研发负责确保系统能够正确、稳定、安全地做到。

这不是信息壁垒,而是专业分工。

第四,AI 降低的是编码成本,不是系统风险。

以前修改一个功能需要两天,现在可能只需要一分钟。

但如果一天产生了 100 个改动,谁来保证它们之间没有冲突?谁来保证测试覆盖?谁来处理版本兼容?谁来负责线上事故?

单次修改成本下降,可能带来整体变更数量和系统治理成本的上升。

第五,文章对程序员的价值理解过于狭窄。

程序员的价值从来不只是掌握系统地图。

更重要的是建立抽象、控制复杂度、管理依赖、识别风险,以及让系统能够持续演进。

AI 能生成代码,不代表它天然理解整个系统的约束,更不代表提出需求的人能够判断生成代码的长期影响。

我真正想反驳的是:

不要把「业务人员可以通过 AI 修改代码」包装成「业务人员已经具备独立修改系统的能力」。

这两者之间还有很长的距离。

让业务人员直接修改低风险配置、页面展示和简单规则,是生产力进步。

让业务人员通过 AI 直接修改核心业务逻辑,却没有相应的测试、审查和责任机制,是把研发成本转化成了系统风险。

AI 时代,程序员确实不应该再把自己定位成代码搬运工。但也不能因为 AI 会写代码,就低估软件工程本身的复杂性。

代码越来越容易生成,真正稀缺的反而是判断一段代码能不能进入一个真实运行的复杂系统。

需要我帮你改得更口语化一点吗?

这种就是公说公有理婆说婆有理。😂

需要 登录 后方可回复, 如果你还没有账号请点击这里 注册。