AI 编程工具铺天盖地Cursor 写 CRUD 像打字Copilot 能补完半个函数各种 Agent 号称能自动修 Bug。但一个很尴尬的现象是传统 IT 岗位并没有消失甚至招聘要求不降反升。很多团队买了 AI 编程工具季度末一算交付速度确实快了但程序员数量没减反而新增了“AI 代码审查”“提示词工程规范”这种职责。问题出在哪先把视角拉回到 1987 年。Fred Brooks 在《人月神话》里提过一个经典划分本质复杂度Essential Complexity和偶然复杂度Accidental Complexity。这两个词当年是用来解释软件工程困境的放到今天正好能解释“为什么 AI 没有代替传统岗位”。这篇文章就用这个框架拆一遍。核心观点是AI 编程工具主要消灭的是偶然复杂度而传统岗位真正值钱的部分——需求确认、业务建模、跨系统集成、合规审计、组织协调——全部落在本质复杂度里。后者不是靠更多代码就能解决的也不存在“生成一个接口”这种操作就能绕过。1. 先搞清楚概念本质复杂度是“问题本身”偶然复杂度是“实现方式”1.1 本质复杂度业务和问题域自带的难度本质复杂度是问题本身固有的和用什么语言、什么框架没关系。举个例子银行要算一笔贷款的逾期利息规则是“按日计息复利按月滚入本金节假日顺延提前还款按实际天数重算”。这套逻辑无论用 Java、Python 还是 COBOL 写难度都在需求本身的语义里。一个 ERP 系统要处理“采购订单、入库单、发票”三单匹配不同供应商的匹配规则不一致部分发票允许部分匹配。这个复杂度来源于业务流程而不是代码量。一个审批流要支持“会签、或签、依次审批、条件分支”还要留痕、可追溯、可回退。状态机本身就不容易设计跟开发工具无关。本质复杂度的特点是它不会因为你换了个更先进的工具而消失。你从 Spring Boot 换成 Spring AI从 RestAPI 换成 GraphQL业务规则的复杂程度原封不动。你从人工编程换成 AI 编程这套规则还是得有人去梳理、确认、建模、验证。1.2 偶然复杂度技术实现带来的额外成本偶然复杂度是技术选型和环境带来的理论上可以通过更好的工具消除。典型例子配置 Maven 依赖、处理 jar 包冲突。写 Dockerfile、编排 docker-compose、调试端口映射。封装 HttpClient、处理超时重试、解析 JSON 响应。适配不同数据库方言、处理编码问题、配置 ORM 映射。搭 CI/CD 流水线、写 YAML 配置文件。这些工作不是业务逻辑本身而是“技术基建”带来的成本。过去十年程序员大量时间花在这个层面。AI 编程工具最擅长的恰恰就是这一层生成模板代码、补全配置、写常见脚本、翻译旧语言。所以很多开发者的体感是“AI 确实帮我省了很多事”但省下来的基本是偶然复杂度。1.3 灯下黑大家都盯着代码生成忘了背后还有一张更大的复杂度地图“灯下黑”指的是技术人习惯盯着编辑器里的代码觉得代码写完了项目就完成了。但一个真实的信息化项目里代码只是最亮的那一块——周边全是暗区需求文档是否一致、干系人的目标是否对齐、验收标准是否可量化、数据迁移是否干净、权限边界是否合规、故障责任如何界定。AI 编程工具照亮的是代码生成这个点但项目交付需要的是整条链路。这就是为什么 AI 很能写代码却撑不起一个项目。2. 为什么 AI 编程工具的强项恰好是偶然复杂度2.1 AI 最擅长“有确定答案”的任务AI 编程工具在大规模语料上训练对常见编程模式非常熟悉。比如“写一个 Spring Boot 的分页查询接口”“用 Python 读取 Excel 并做数据清洗”“写一个 GitLab CI 的缓存配置”这些任务有大量公开样本结果相对确定AI 生成的代码质量已经接近普通工程师的初稿。这类任务的共同点是方案唯一、上下文短、验证成本低。写错了一眼能看出来编译不过、单元测试红、接口返回不对都能快速反馈。AI 在这种场景下非常可靠。2.2 偶然复杂度的模型化非常适合 AI 训练偶然复杂度有很多公开语料比如 GitHub 上的代码库、Stack Overflow 上的问答、官方文档的示例。AI 训练时见得多生成时自然“手感好”。这解释了为什么 Cursor、Copilot 在生成 CRUD、脚本、算法片段时体验很好。2.3 但偶然复杂度只是项目里的一小部分可以做一个粗略的拆解一个典型的信息化项目里编码可能只占 30% 到 40% 的工作量。即便如此编码中的重复劳动力DTO 转换、Mapper、Controller 层也只占编码工作量的一部分。换句话说AI 优化的是“工作中占比不大的环节”而不是整个项目的生产力瓶颈。3. 本质复杂度为什么难以自动化四个绕不过去的现实3.1 业务需求往往是模糊、矛盾、不完整的AI 生成代码的前提是“输入足够清晰”。但真实业务需求很少满足这个前提。举一个典型场景业务方说“我们要做一个在线报表系统”但是“报表给谁看”“数据从哪来”“刷新频率多少”“哪些字段需要权限控制”“历史数据要不要保留”全都没说。AI 无法生成一个“不知道需求”的系统它只能基于用户已经写下的提示词生成一个假设性方案。更麻烦的是需求之间可能互相矛盾。财务部门要“实时库存”仓储部门说“实际库存和系统库存本来就是有差异的实时会引发更多对账问题”。这个时候需要的是业务梳理和干系人协调不是更多代码。3.2 系统集成和状态一致性复杂度在系统之外很多 IT 项目并不是从零开发而是把多个已有系统串起来ERP、OA、MES、SRM、财务系统、第三方支付、短信网关。每个系统有自己的一套数据模型和接口语义。A 系统里的“客户”和 B 系统里的“客户”是不是同一个实体接口超时之后重试会不会造成重复订单消息丢失怎么补齐数据这类问题没有标准答案它取决于企业实际的组织架构、历史数据和容错要求。AI 可以帮你生成一个 Feign Client但它无法判断“调用失败了到底是改接口还是做补偿事务”。3.3 合规、审计、权限代码写得对只是最底线政务信息化、金融、医疗等行业系统的上线前提不是“功能能跑”而是“流程合规”。要过等保测评、数据安全评估、软件测评、密码应用安全性评估要准备立项材料、招投标文件、需求规格说明书、设计文档、测试报告、验收报告。这些文档和流程不是 AI 写一个 README 能替代的。系统上线之后出了问题追责要追溯到“谁决策的、谁评审的、谁验收的”这个责任链条里必须有具体的人。AI 可以当副驾驶但没法当责任人。3.4 组织协同的成本无法靠代码优化一个信息化项目真正推进慢的地方往往是跨部门协调业务口径不一致、数据标准不统一、系统归属权不清晰、预算审批流程复杂。这些问题的本质是“组织复杂度”不写在代码里也不会因为有一个 AI Agent 自动生成代码而消失。4. 用项目全生命周期看 AI 的真实边界4.1 需求调研与立项环节AI 目前能做的整理会议纪要草稿。根据关键词生成需求问卷模板。辅助分析历史项目文档提取术语口径。但 AI 还做不了的判断业务方说的“我要”和“我需要”之间的差距。在多个业务部门观点冲突的时候找到达成一致的路径。制定合理的项目范围和验收标准。4.2 概要设计与详细设计AI 目前能做的根据需求描述生成实体关系图草稿。生成接口定义和数据库表结构的初稿。生成部署架构图的文字描述。但 AI 还做不了的决策“自研还是买现成产品”。评估新系统与旧系统之间的数据迁移策略。结合团队技术栈和人才储备做技术选型。在设计阶段就预估未来运维和扩展成本。4.3 编码实现这是 AI 目前渗透率最高的环节但这恰恰是传统岗位里最容易被替代的部分。AI 能写 Controller、Service、Mapper能生成前端页面框架能补测试用例模块。问题是这个环节的效率提升不等于项目周期缩短因为项目周期取决于前面的环节是否稳定后面的验证是否有效率。4.4 测试、部署上线与运维AI 可以生成单元测试和集成测试的模板但测试数据怎么造、缺陷怎么分类、哪些缺陷阻断上线仍然需要人来决策。部署阶段AI 可以写 CI/CD 脚本但压测方案、容量规划、回滚策略、监控告警阈值都得靠有经验的工程师来定。运维更是一个无法“生成”的领域。一个系统跑在生产环境出了故障AI 可以汇总日志、给可能原因但最终判断“先恢复服务还是先保护现场”“需要通知哪些业务部门”“变更回退窗口要多久”这些决策涉及业务连续性和责任界定很难由模型独立完成。5. 从信息化行业现实看资质、预算、流程都不是代码问题观察国内这几年信息化项目的推进会发现一个现象真正卡住项目进度的往往不是技术而是流程和制度成本。项目管理中常见的预算编制、招投标资质要求、监理验收流程这些环节的复杂度用 AI 写多少代码都无法消除。以政务信息化项目为例预算编制有《省级政务信息化服务预算编制标准试行》这一类的规范投标单位需要具备相应的企业资质项目过程需要监理、测评、验收等多轮评估。这些约束的存在意味着信息化的“本质复杂度”不仅包含业务逻辑还包含政策合规和公共资金使用的程序性要求。AI 能帮你生成技术方案文档的初稿但无法替你完成资质申报和预算论证。企业信息化也存在类似情况。跨部门的数据权责划分、IT 部门和业务部门的关系、外包团队和内部团队的职责边界这些组织层面的复杂度代码层面不可能解决。很多时候一个需求拖了两个月不是因为写代码慢而是因为“谁能拍板”这个问题没有答案。AI 写的代码再快也加速不了决策链条。这也是“为什么 AI 没有代替传统岗位”的一个重要解释传统岗位承担的复杂度往往不在“代码实现”这个层次而在“让项目被合规地立项、落地并被验收”这个层次。6. AI 编程的实践边界生成快、验证慢、责任难6.1 生成快不等于交付快AI 代码生成速度快但代码一旦被合并进系统它就变成了长期的资产。代码的可读性、健壮性、安全性、可维护性都需要人工评审。一个 AI 生成的接口看起来没问题但可能存在并发安全、事务边界、权限校验缺失等问题。这些问题的验证成本远大于生成成本。一个有经验的工程师看到一个 AI 生成的方法时第一反应通常不是“好快”而是“它没考虑异常分支”。AI 生成的代码越流畅越容易让人放松警惕最后在极端条件下暴露出问题。6.2 上下文理解的深度不足导致系统性风险AI 编程模型虽然有长上下文窗口但实际的代码生成仍然是“基于上下文片段的预测”而不是“基于系统全貌的工程设计”。当一个人在维护一个 10 年的老系统里面有各种历史包袱和隐性约定时AI 很难理解这些约束。它生成的代码可能更“漂亮”但与现有系统的实际行为不一致。6.3 责任归属问题限制了 AI 在关键环节的使用在金融、医疗、政务这类行业系统故障的责任认定非常严格。AI 模型不是责任人无法承担法律和合规层面的责任。所以即使技术上 AI 可以独立完成一个模块组织流程仍然要求有具体的工程师负责。这就导致 AI 永远只能作为辅助工具存在而不是替代者。7. 传统岗位没有消失职责正在重构7.1 从“写代码的人”变成“定义问题的人”AI 把写代码的门槛降低之后岗位的核心价值开始上移。现在更稀缺的能力是把模糊业务表述翻译成精确需求、拆解问题边界、设计数据模型和接口契约、判断技术方案的取舍。这些能力本质上都是“定义问题”的能力而不是“实现方案”的能力。7.2 从“编码交付”变成“质量与效益负责”以前程序员对交付的定义是“代码写好测试通过”。现在 AI 辅助下代码生成已经不是瓶颈但“这个功能真的解决业务问题了吗”“上线后有没有带来新的运维负担”“用户体验是否有提升”这些问题变得更重要。岗位职责从“产出代码”转向“对业务结果负责”。7.3 从“单点实现”变成“系统集成与大局观”AI 可以缩小应用代码的书写成本但跨系统集成时涉及的数据格式、协议语义、事务一致性、权限模型仍然需要人来判断。系统越大系统间的“偶然复杂度”越突出反而更依赖一个有全局视角的工程师。这也是为什么很多团队的 AI 落地经验里第一步不是换工具而是先做架构梳理。8. 给程序员和信息化从业者的行动建议8.1 学会识别本质复杂度把精力留给它写代码之前先花时间把业务逻辑拆透。多问几个为什么这个需求的目标是什么数据从哪里来到哪里去边界条件是什么异常情况怎么处理把本质复杂度梳理清楚AI 才能更好地帮你实现偶然复杂度部分。8.2 用 AI 处理偶然复杂度但不要过度依赖AI 最适合处理的是配置、模板、样板代码和常见脚本。遇到这些任务可以大胆用但要建立质量门禁必须跑过单元测试必须看完整段代码逻辑涉密数据和敏感信息不要粘贴到第三方工具上。就算是用企业内部私有化部署的模型也建议做代码审查。8.3 主动参与业务活动积累领域知识现在越来越多技术岗位要求“理解业务”这不只是口号。多参加需求评审、多和业务方沟通、多写技术方案、多参与验收过程这些经历积累的领域判断力才是 AI 难以替代的部分。传统岗位不会消失但“只懂技术的人”在组织里的价值会下降因为 AI 能承担更多纯技术执行。8.4 构建自己的“问题题库”和“决策记录”在 AI 时代知识点的记忆变得不那么重要但“遇到类似问题如何决策”的经验非常值钱。建议给自己维护一份问题与决策记录遇到过什么坑、当时怎么判断的、结果如何、如果重来会怎么改。这份记录既是个人成长档案也是未来做架构决策时的第一手参考。8.5 关注业务链路和系统生命周期成本当一个信息化系统从立项走到运维真正的成本大头是长期维护和变更。AI 能写新代码但改老代码、调历史数据、重跑批处理、排查线上问题这些仍然是高成本活动。设计和编码的时候多考虑未来的维护成本减少“一次性代码”和“临时方案”。9. 总结与下一次的切入点回到最初的问题AI 为什么没有代替传统岗位答案不是 AI 不够强而是它强的地方恰好不是行业最贵的地方。AI 编程工具真正解决的是偶然复杂度这是好消息因为它让开发者的效率上了一个台阶但传统岗位的价值核心在于本质复杂度——业务建模、系统设计、组织协调、合规责任这些不会因为代码生成速度变快而消失。反过来看“灯下黑”这个概念对技术人也是一种提醒不要只盯着编辑器里的光看不到需求、流程、人和系统之间暗处的复杂度。AI 时代真正值得投入的不是和 AI 比写代码的速度而是把 AI 能力用到极致的“问题定义、方案决策和质量保障”能力。下一步可以继续深入的话题是如何把 AI 编程工具真正嵌入到“需求 → 设计 → 编码 → 测试 → 运维”的全链路中以及如何为团队建立一套适合 AI 协作的代码规范和评审机制。这些实操内容后面可以单独拆开写。