最近被问得最多的一个问题不是“某个功能怎么做”也不是“某个报错怎么排查”而是“AI 都能写代码了程序员是不是快被替代了”这个问题在 IT 圈子里讨论了很久。有人焦虑有人无所谓也有人已经在用 AI 编程工具提升效率。但真正落到开发实战里你会发现一个很有意思的现象AI 确实能帮你写出不少代码可系统上线前的需求确认、边界梳理、预算评审、运维保障依然离不开人。这篇文章我想换个角度来聊这件事。不从口号出发而是从两个经典概念出发本质复杂度Essential Complexity和偶然复杂度Accidental Complexity。把这两个概念理清楚你就知道 AI 为什么能帮你写代码却不能替你承担“信息化岗位”里的核心责任。1. 什么是本质复杂度与偶然复杂度1.1 经典来源Brooks 在《人月神话》中的划分本质复杂度和偶然复杂度这两个概念最早来自 Fred Brooks 的经典著作《人月神话》The Mythical Man-Month。Brooks 在书中讨论软件工程困境时提出了一个核心观点软件系统的难度由两部分组成一部分是问题本身固有的另一部分是解决方案引入的。本质复杂度由业务领域、需求规则、数据关系、用户场景等客观因素决定。这部分复杂度不会因为你换一种编程语言、换一个框架就消失。偶然复杂度由我们实现方案时引入的复杂度比如配置环境、处理语法、对接工具、解决版本冲突、编写样板代码等。这部分复杂度是人为附加的可以通过更好的工具、平台、语言特性来降低。举例来说你给一个电商系统做订单金额计算。订单涉及会员折扣、满减活动、优惠券叠加、税费计算、跨境汇率等规则这些规则本身是非常复杂的这就是本质复杂度。而为了把这个规则写成代码你需要学习 Java 或 Python 语法、配置数据库连接、处理 JSON 报文格式、管理 Maven 依赖这些是偶然复杂度。1.2 为什么 IT 从业者容易“灯下黑”“灯下黑”的本意是指灯本身照亮了周围但灯座底下反而没有光。IT 编程和信息化领域也有类似情况。我们每天和代码、系统、需求打交道反而很少停下来想自己日常工作里哪些部分真正困难哪些部分只是琐碎哪些是 AI 难以替代的哪些其实已经可以被自动化工具接管如果只看到“AI 会写函数、会生成接口、会修 bug”就容易把编程理解为“写代码”进而认为 AI 很快就能替代程序员。但真正做过信息化项目的人都知道代码只是最后一公里。前面的业务建模、规则确认、边界定义、异常场景梳理、利益相关方协调才是投入时间最多、也最影响项目成败的部分。1.3 这两个概念在信息化建设中的具体表现搞清楚这两个概念之后再来看信息化项目就会清晰很多。从上面的表格可以看出本质复杂度集中在“理解业务”和“定义规则”上偶然复杂度集中在“实现技术”和“运维操作”上。AI 在偶然复杂度上确实能帮上大忙但在本质复杂度上它只能辅助不能替代。这就是为什么你身边一定有这样的项目用了 AI 辅助编程代码生成得快可系统一上线就暴露业务规则漏洞需求变更接踵而至最后项目延期。2. 一个经典的代码示例帮你理解两种复杂度为了把概念讲得更具体下面用一个订单金额计算的示例来演示。2.1 需求背景假设我们需要实现一个订单金额计算功能规则如下普通用户不打折VIP 用户打 9 折。订单满 100 元减 10 元。满减活动在折扣之后计算。税费按折后价格加 6%。这个需求包含多条业务规则而且规则之间有先后顺序。这种“规则之间的顺序和交互”就是本质复杂度。2.2 忽略业务规则的简化代码如果用最简单的思维可能会写出下面这段代码public class OrderCalculator { public double calculate(double amount, boolean isVip) { // 第一步应用会员折扣 if (isVip) { amount amount * 0.9; } // 第二步满减 if (amount 100) { amount amount - 10; } // 第三步计算税费 amount amount * 1.06; return amount; } }这段代码确实能跑而且看起来逻辑完整。但如果你把它直接用到真实项目里很快就会发现几个问题如果满减活动有多个档位比如满 100 减 10满 200 减 30代码怎么扩展如果优惠券和满减不能同时使用这个逻辑该由谁来判断税费规则是不是按照商品类目区分的图书和数码产品的税率是否一样如果订单包含多个商品部分商品参与活动部分商品不参与金额怎么拆分这些问题都不是语法问题也不是技术框架问题而是业务规则本身没有定义清楚。你可以让 AI 生成十个版本的订单计算器但如果业务规则没说清楚AI 生成的代码永远无法真正满足需求。2.3 我见过的一次真实返工有一回做信息化项目业务方提的需求写得很简单订单导出功能。开发同事用 AI 辅助编程很快生成了导出代码实现了基本的 Excel 文件输出。看起来没问题测试的时候却发现数据对不上。仔细排查才发现业务方真正想要的不是“导出订单”而是“按部门、按时间、按状态汇总后的订单明细导出”并且合计行要按财务口径计算。原来的代码把订单状态过滤条件写死了根本不符合要求。这个问题的根因是什么是技术实现难吗不是。是 AI 生成的代码出错了吗也不是。真正的问题在于需求方和实施方都没有把“导出”背后的业务规则和统计口径搞清楚。这就是本质复杂度的真实体现。3. 信息化项目中复杂度主要体现在哪里3.1 系统架构中的数据流复杂度信息化系统通常不是单机软件而是多个系统相互协作。以常见的企业系统为例前端系统收集用户请求。后端服务处理业务逻辑。数据库存储结构化数据。消息队列传递异步任务。第三方接口对接外部服务。数据在系统之间流动时经常出现格式不一致、字段缺失、接口超时、幂等性问题。这种复杂度来自系统间交互而不是单个系统的算法。AI 可以帮你生成某个微服务的接口代码但无法帮你判断订单服务调用库存服务时如果库存扣减成功但订单创建失败用什么机制保证最终一致性这个问题属于分布式事务设计是典型的本质复杂度。3.2 需求变更与业务规则复杂度信息化项目的最大风险往往不是技术选型而是需求变更。业务方今天说“客户等级分为普通和 VIP”明天可能增加一个“黑金会员”今天说“满减和优惠券可以叠加”明天可能改成“二选一”。每次需求变化都会影响数据库表结构、接口参数、前端页面、测试用例。AI 编程工具面对这种变化时不能自动判断“这个字段的修改会影响哪些下游系统”。它只能按照你的指令修改代码片段。评估影响范围、制定变更方案、回归测试仍然需要人来完成。3.3 运维与运营的隐性复杂度信息化系统上线只是开始。后续的监控告警、日志排查、容量规划、数据备份、安全加固、用户反馈处理这些工作虽然不写业务代码但同样需要懂技术和业务的人来做。也许你会说现在有 DevOps 工具、有自动化运维平台很多操作已经不用人工了。没错工具确实降低了偶然复杂度但工具的选型、脚本的编写、告警阈值的定制、应急预案的制定依然需要人来决策。4. AI 编程工具到底改变了什么4.1 AI 编程工具的真实能力边界这里不讨论具体的某个产品而是从能力边界来看。AI 编程工具包括 Cursor 等 AI 辅助编程工具擅长的事情包括根据自然语言描述生成可运行代码。补全重复性的样板代码。生成单元测试框架。解释已有代码的逻辑。重构代码结构。搜索 API 使用方式。这些能力本质上是把“偶然复杂度”大幅降低了。过去你需要去查文档、记忆 API、手写重复的 CRUD 代码现在 AI 可以快速生成。但 AI 不擅长的事情也很明显准确理解模糊的业务需求。判断需求背后的真实动机。在多个约束条件之间做权衡。为系统设计兜底方案。承担责任。如果需求描述本身是含糊的、矛盾的和不完整的AI 生成的代码就是“看起来正确实际上错误”。这种现象在业内有一个通俗的说法叫“幻觉”模型会以非常自信的语气生成一段语法正确但逻辑错误或引用不存在 API 的代码。4.2 AI 编程对岗位分工的影响AI 编程对岗位的影响不是简单的“替代”而是“重组”。过去一个开发团队可能需要两个人专门写 CRUD 代码现在有了 AI 辅助一个人就能完成。但与此同时业务建模和评审的重要性反而提升了。系统复杂度和业务风险不会因为代码行数减少而消失只会被压缩到需求阶段和设计阶段。换句话说AI 让“把代码写出来”变得便宜了但“确定写什么”依然昂贵。4.3 越智能的工具越需要清醒的“把关人”有一句话说得挺好AI 编程工具像一个非常熟练但有时会一本正经胡说八道的实习生。实习生帮你干了很多活但你绝不能把需求文档直接丢给他就不管了。你需要 review 他写的每一段代码需要告诉他不理解的地方需要在关键时刻拿主意。在信息化项目建设中这个人就是传统岗位里的核心角色。他们懂一点业务懂一点技术能在业务方和技术团队之间做翻译能识别出“这段代码虽然能运行但接口设计有问题”能预判系统上线后的性能瓶颈和安全风险。5. 为什么 AI 没有代替传统信息化岗位5.1 业务责任无法自动化AI 可以生成代码但无法为代码的后果负责。传统信息化岗位不只是写程序更是整个业务链条中的一个责任节点。举个例子社保系统、财务系统、政务系统、医疗系统这类信息化系统一旦出错影响范围非常大。需求评审要签字上线方案要审批变更要有记录出了问题要有人承担责任。这些流程不是技术实现的一部分但它们是系统稳定运行的必要条件。AI 可以在这些流程中提供帮助但无法替代人来做决策和背书。5.2 隐性知识与上下文理解很多业务规则并不在需求文档里。它们存在于老员工的经验里、制度的背景里、历史的遗留逻辑里。你问业务方“这个字段为什么要这样设计”他可能也说不清楚只回答“以前就是这样定的”。这种情况下你需要通过访谈、观察、分析历史数据来还原背后的逻辑。这种“隐性知识”的获取和显性化是目前 AI 难以完成的工作。5.3 团队协作与利益平衡信息化项目不是一个人单打独斗。业务方有 KPI技术方有开发周期管理层有预算限制最终用户有使用习惯。这些角色之间的目标常常不一致。谁能推动各方达成共识谁能避免技术团队和业务团队互相甩锅谁能说出“这个需求可以做但成本很高是否确认要投入”这些协作层面的复杂度超出了单纯的技术范畴也远远超出了 AI 的能力边界。5.4 岗位的价值正在从“写代码”转向“做决策”传统 IT 编程和信息化岗位的边界正在发生转变。过去你是一个写代码的人现在的你是一个用代码解决业务问题的决策者。这种转变意味着你不需要成为语法百科全书但要能判断哪种技术方案更适合当前场景。你不一定要手写每一行代码但要能审视 AI 生成的代码质量。你不一定最了解最新的框架但要知道如何用最小的成本实现最稳定的系统。从这个角度看AI 编程不仅没有让信息化岗位失去价值反而让“懂业务、懂架构、懂协作”的从业者价值更高了。6. 信息化系统中 AI 编程的实战方式6.1 正确姿势一用 AI 生成脚手架代码而不是直接生成业务逻辑对于新项目可以让 AI 帮忙生成项目结构、基础配置、通用工具类。这样可以节省大量搭建时间。# 示例使用 Maven 快速生成项目骨架 mvn archetype:generate -DgroupIdcom.example -DartifactIddemo-project -DarchetypeArtifactIdmaven-archetype-quickstart然后再让 AI 在这个骨架基础上填充具体的业务代码但前提是业务规则已经明确。6.2 正确姿势二让 AI 生成单元测试和边界用例AI 在“已有明确输入输出”的场景下生成测试用例的准确率比较高。你可以让 AI 根据函数签名生成测试代码然后由人来补充边界场景。// 文件路径src/test/java/com/example/OrderCalculatorTest.java public class OrderCalculatorTest { Test public void testVipDiscountAndFullReduction() { OrderCalculator calculator new OrderCalculator(); double result calculator.calculate(200, true); // 200 * 0.9 180满足满减条件180 - 10 170再乘以 1.06 assertEquals(180.2, result, 0.01); } Test public void testNoDiscountUnderThreshold() { OrderCalculator calculator new OrderCalculator(); double result calculator.calculate(50, false); // 50 * 1.06 53 assertEquals(53.0, result, 0.01); } }注意测试代码里的数值是我随便举例推算的实际操作时要根据你的业务规则重新计算。这个例子想说明的是AI 可以帮助你生成测试用例的骨架但断言值是否正确必须由人来确认。6.3 正确姿势三让 AI 做代码解释和代码评审遇到一段别人写的复杂代码可以直接让 AI 解释逻辑。也可以让 AI 检查代码中可能存在的空指针、资源泄漏、并发问题。提示词示例 请检查以下 Java 方法的潜在问题涉及并发场景和异常处理 粘贴代码AI 给出的建议需要人工判断但往往能提供一些你容易遗漏的视角。7. 常见误区与排查思路7.1 误区一AI 生成的代码可以直接上生产这是最危险的误区。AI 生成的代码没有经过业务确认、代码评审、测试验证直接部署到生产环境风险极高。正确的做法是把 AI 生成代码当作“草稿”或“第一版实现”必须经过完整的代码评审和测试流程才能合并到主干。误区表现风险正确处理AI 生成的代码不 review 直接提交隐藏 bug、安全漏洞强制代码评审让 AI 直接改生产配置配置错误导致服务不可用修改前备份变更走审批依赖 AI 编写核心算法逻辑错误难发现核心逻辑人工复审不写测试就当完成回归风险高补测试用例再提交7.2 误区二认为 AI 理解了业务AI 并没有真正理解业务。它只是根据大量语料生成了“最符合你当前描述”的文本。如果需求描述是“按金额排序”AI 不知道你说的“金额”是含税价还是不含税价不知道升序还是降序不知道金额相同的订单按什么次级规则排序。这些都需要你来定义。7.3 误区三用 AI 替代需求分析需求分析是信息化项目中最难的环节。你需要和业务方反复沟通把模糊的“我想要一个报表”转化为明确的“我需要按部门、按时间、按指标统计并支持导出”。AI 可以帮你整理会议纪要、生成需求文档初稿但需求是否准确、是否完整必须由人来判断。7.4 排查思路清单如果你正在使用 AI 编程工具建议按下面的清单自检需求文档是否明确了业务规则和边界条件AI 生成的代码是否有人 review 过是否补充了单元测试和集成测试关键配置是否经过了人工确认上线前是否做了备份和回滚方案是否和生产环境做了权限隔离8. 传统岗位的工程实践与进阶方向8.1 需求分析阶段不要急着写代码。先画出业务流程图梳理明确的输入、输出、异常分支和权限边界。把需求文档里的名词定义清楚比如“有效订单”“VIP 用户”“满减活动”这些词在系统里到底对应什么状态。8.2 系统设计阶段优先考虑可维护性。系统不是为了今天的一次上线而是为了未来三年的演进。模块之间要解耦接口设计要稳定数据库表设计要考虑扩展性。8.3 编码实现阶段把 AI 当成一个高效的辅助工具来使用。先自己明确思路再让 AI 生成代码片段最后对代码做评审和测试。不要盲目接受 AI 的全部输出。8.4 测试与上线阶段上线前要确认三个问题数据是否备份变更是否可以回滚监控是否到位这三件事没有确认清楚不要动生产环境。8.5 学习路线建议如果你想把“传统岗位”这条路走得更稳可以按下面的方向持续投入深化业务领域知识成为“懂技术的业务专家”。学习系统设计和架构模式关注数据一致性、可用性、扩展性。掌握 AI 编程工具的使用边界把它变成生产力工具。锻炼沟通能力能够把复杂问题讲清楚推动多角色协作。培养风险意识对生产环境保持敬畏对变更流程保持严谨。9. 关于“灯下黑”的思考回到标题里“灯下黑”这个比喻。信息化的真正难点从来不是“怎么把功能做出来”而是“怎么把业务想清楚”。AI 可以帮你解决“怎么做”的大量重复工作但“做什么”和“为什么做”的问题依然需要人来回答。这种现象在从业者身上表现得尤为明显。我们忙于学习新技术、忙于使用新工具、忙于追赶新框架却很少停下来问手里的这个项目真正的复杂度在哪里AI 解决的是哪一部分剩下那部分靠什么来应对灯下黑不是因为你不够努力而是因为你离光源太近。当你退后一步看清本质复杂度和偶然复杂度的边界很多事情就会变得清晰起来。AI 没有代替传统信息化岗位是因为代码只是信息化的表象而理解业务、承担责任、平衡各方目标才是这个岗位真正的内核。下一次再听到“AI马上要替代程序员”的说法时不如试着问一句这段需求的本质复杂度你讲清楚了吗AI 能算出折扣可谁来为这个规则兜底答案其实就在你自己的岗位价值里。