在IT编程与信息化项目里存在一种典型的“灯下黑”团队看得见代码量、接口报错、部署日志和迭代速度却常常忽略真正决定系统成败的复杂度。软件工程经典著作《人月神话》和《没有银弹》中Fred Brooks 将这种复杂度拆成两类本质复杂度essential complexity与偶然复杂度accidental complexity。本质复杂度来自问题本身是业务规则、边界条件、数据一致性等内在难度偶然复杂度来自我们使用的工具、语言、框架、配置是技术选型带来的额外负担。AI编程工具例如 Cursor、GitHub Copilot、通义灵码确实大幅降低了偶然复杂度比如生成样板代码、补全接口、编写配置文件。但为什么AI没有代替传统岗位因为信息化项目里真正消耗时间的并不是代码生成而是理解需求、拆解业务、权衡架构、保证结果可靠。这跟代码行数和编程速度无关甚至跟是否使用AI无关。这篇文章从两类复杂度出发用一个信息系统中常见的“每日积分结算”需求逐步拆解 AI 编程能完成什么、不能完成什么并讨论传统岗位在 AI 时代为什么仍然不可替代。内容适合正在使用 AI 辅助开发的程序员、准备引入 AI 编程工具的团队以及想理解“AI 替代论”边界的产品和技术负责人。1. 先区分本质复杂度和偶然复杂度那段被忽略的“灯下黑”1.1 用一条积分规则说明复杂度并不在代码表面一个看起来简单的需求“每日统计用户积分并按积分段发放优惠券重复提交不重复发放。”这句话里的每个词都需要继续细化。每日是指自然日还是财务日积分来自订单、评价还是签到统计的积分快照是什么时间点的优惠券发放的阈值是累计积分还是当日积分重复提交的判断依据是同一个用户、同一个批次还是同一个请求这些都不是语法问题而是业务规则和系统边界问题。在信息化项目中这类模糊需求非常常见。用户说“看到本月待办事项”研发需要考虑待办的定义、已办与办结的区别、权限范围、延迟显示、分页和归档。代码量可能不大但沟通和判断量很大。代码生成之前大量工作已经决定成败。如果只盯着“能不能用 AI 把接口写出来”反而会漏掉真正需要花时间的部分。1.2 本质复杂度问题域自带的复杂度本质复杂度是人类要解决问题的内在难度。它不因为换编程语言、换框架、换 AI 工具而消失。例如财务对账系统必须保证每一笔分录借贷平衡库存系统必须防止超卖核心交易系统必须支持事务和幂等医疗系统药品配伍禁忌需要完整的领域知识。这些复杂度来自业务本身的约束和不确定性。系统越贴近真实业务本质复杂度往往越高。定义上本质复杂度是问题域内包含的逻辑、约束和不确定性。它无法被删除只能被理解、拆分、建模和验证。如果需求本身就是复杂的任何技术手段都不能让复杂度消失只能把复杂度从一个地方搬到另一个地方。比如把业务规则做进数据库存储过程规则仍在把规则做成配置中心规则仍在把规则交给 AI 生成代码AI 只是把规则翻译成代码规则本身并不会因为 AI 参与而消失。1.3 偶然复杂度手段带来的复杂度偶然复杂度来自实现技术方案的附加成本。它和业务无关只和“怎么实现”有关。例如为了跑一个 Python 项目需要安装依赖、配置虚拟环境、处理 Python 版本与包版本冲突为了在 Spring Boot 中接入 MySQL需要配置数据源、写 Mapper、处理连接池参数为了在 K8s 中发布服务需要编写 Dockerfile、Service、Deployment 和 ConfigMap。这些工作很有价值但本质上不是业务规则的组成部分。它们是技术选型、平台限制和工程规范带来的额外工作。AI 非常擅长处理这一类复杂度。它能根据提示词生成依赖文件、常见配置、CRUD 接口和单元测试骨架能快速把“不知道这个框架怎么写”变成“差不多能跑”。这也是很多开发者在接触 AI 编程后第一感受是“效率提升明显”的原因。但效率提升主要发生在偶然复杂度层面而不是本质复杂度层面。1.4 两种复杂度的核心对比维度本质复杂度偶然复杂度来源问题域、业务规则、不确定性实现工具、平台、语法、配置典型例子权限模型、财务记账规则、并发一致性框架配置、依赖版本、接口样板代码能否消除不能消除只能理解、拆分、建模可以降低通过封装、工具、AI辅助主要承担者需求分析师、架构师、领域专家、资深工程师普通开发者、AI工具、代码生成器失败表现上线后业务规则不对、数据不一致编译报错、启动失败、依赖冲突关键动作澄清需求、验证边界、设计模型生成代码、查文档、调参数实际项目里这两类复杂度不是边界清晰的两个盒子。同一个问题可能会同时包含两类复杂度甚至在项目不同阶段相互转化。但先把这个模型建立起来再讨论 AI 的能力边界就会清晰很多。2. AI编程工具真正擅长消除的是哪一层复杂度2.1 Cursor、Copilot这类工具的工作方式AI 编程工具的共同点是基于大语言模型根据用户输入的提示词、当前文件上下文和项目结构生成候选代码。它们擅长补全常见模式、生成重复性代码、转换数据格式、解释某个 API 的用法以及把自然语言描述翻译成一段看起来合理的实现。但工具的工作方式决定了它需要足够的上下文。提示词如果只写“生成一个用户注册接口”没有说明字段、校验规则、密码存储方式、是否支持手机号登录、是否需要图形验证码AI 输出的只能是通用模板。真正的变化发生在开发者把业务约束输入进去之后。实际使用中可以把 AI 编程工具理解成一位非常熟悉语法、但没有业务经验的“结对程序员”。它可以快速写出 FastAPI、Spring Boot、Vue 组件、SQL 查询但它并不清楚你所在公司对“用户”“订单”“结算”的定义。代码能跑不代表代码是对的。2.2 AI对样板代码和语法细节的处理效果用一个非常小的接口示例说明。提示词可以这样写请用 Python FastAPI 编写一个用户积分查询接口。 要求 1. 输入参数userId 2. 返回用户ID、总积分、昨日积分、积分等级 3. 使用 Pydantic 做参数校验 4. 错误时返回统一 JSON 格式AI 生成的代码大致如下from fastapi import FastAPI, HTTPException from pydantic import BaseModel app FastAPI() class UserScoreResponse(BaseModel): user_id: int total_score: int yesterday_score: int level: str app.get(/users/{user_id}/score, response_modelUserScoreResponse) async def get_user_score(user_id: int): # 此处需要对接数据库与积分计算逻辑 raise HTTPException(status_code501, detailnot implemented)这段代码结构完整能帮助开发者快速理解 FastAPI 的接口写法但它没有实现真正的业务。关键点在于AI 帮你省掉的是 FastAPI 路由写法、Pydantic 模型定义、异常返回格式这类偶然复杂度。积分等级怎么算、昨日积分从哪里查、用户不存在返回什么AI 并不知道只能留出占位。这正是 AI 编程工具在真实项目中的常态它能生成模板但你必须知道模板里应该填什么业务。2.3 异步编程和 CompletableFuture 中的AI局限热门话题里经常出现“异步编程”和“CompletableFuture 异步编程异常处理”。用异步批量处理任务举例AI 可以快速生成一个教科书写法ExecutorService executor Executors.newFixedThreadPool(10); for (Task task : tasks) { executor.submit(() - process(task)); }这段代码在小型学习项目中可以跑通但放到生产环境会带来一串问题线程池队列有没有上限任务执行失败后是否记录日志应用重启后未完成的任务怎么办多个应用实例同时执行同一个任务会不会重复处理任务超时如何中断AI 不会主动问你“corePoolSize 设置为多少合适任务失败要不要重试重试会不会影响上游系统”。它只会根据常见模式继续生成。对 AI 来说异步编程的语法是确定的但异步系统的异常处理、幂等控制、资源隔离和取消机制是业务层面的取舍。这些取舍必须由工程师判断而不是由代码生成器决定。2.4 从复杂度模型看 AI 的能力边界操作类型AI 当前角色人类决策责任代码补全生成候选代码判断是否满足业务语义样板配置生成模板判断环境与版本匹配单元测试生成基础用例覆盖需求边界与异常场景架构设计只给出通用方案结合团队、规模、成本做取舍需求澄清无法替代访谈与确认必须由人主导故障定位辅助分析日志理解全链路与业务影响可以得出结论AI 解决的是“已经知道要做什么但不知道高效写出来”的偶然复杂度它对“不知道要做什么”的本质复杂度没有判断能力。接下来进入信息化项目的真实场景看看这个边界如何体现。3. 在信息化项目中为什么AI没有替代传统岗位3.1 信息化系统的UE设计原则背后是业务沟通现代信息化项目强调用户体验设计但 UEUser Experience不只是在界面上调整按钮位置。设计一个审批系统的“待办列表”需要判断审批角色、权限范围、会签还是或签、超时是否自动通过、意见是否必须填写、列表如何排序。这些规则来自组织流程而不是来自设计规范。AI 可以帮助生成前端的列表组件、状态标签、分页交互但无法替代产品经理和业务方逐条确认“超时自动通过”是否符合管理制度。信息化系统的 UE 设计原则本质上是对业务逻辑的表达方式。一个用户看不到的字段可能决定了整个流程是否合规。这也是为什么“AI 生成页面”只能作为原型不能直接成为生产系统的原因。3.2 软件开发流程里的“编码”只占一段一个信息化项目的生命周期通常包括需求调研、范围确认、方案设计、资源预算、开发、测试、部署、培训、运维。代码编写在其中只是其中一段远不是项目全貌。更常见的是大量时间花在核对需求文档、评审接口设计、准备环境、处理联调问题、迁移数据、培训用户、响应线上故障。AI Agent 可以自动提交代码、生成发布说明、整理周报但无法替代项目负责人去协调多个部门的数据口径无法替代测试人员去设计边界用例也无法替代运维人员判断回滚条件。传统岗位不只是写代码还承担流程推进、责任归属和多方沟通。AI 可以把“编码”这个环节进一步压缩但压缩不了业务确认和系统稳定性的时间。3.3 传统岗位的本质不是写代码而是做决策当需求出现冲突时比如财务部门要求数据实时准确运营部门希望批量导入后立即可用AI 无法判断哪个部门优先级更高。当技术方案出现分歧时比如用单张宽表还是多张业务表AI 无法知道团队维护能力和未来扩展方向。这个决策过程依赖领域知识、权衡意识和风险判断。程序员写的每一行代码都在固化业务规则。规则一旦理解错误后续所有自动化工具都会放大错误。AI 可以快速生成“看起来正确”的代码但“正确”的标准来自业务约束和验收标准。传统岗位的价值恰恰体现在定义这些约束上能问出“结算日期按自然日还是财务日”的工程师比能写一万行代码但从不追问细节的人更难被替代。3.4 信息化项目服务的真实场景判断、责任与回滚生产环境出现故障时AI 可以辅助分析日志但“是否回滚”“先恢复服务还是先保留现场”“通知哪些业务方”是需要人来拍板的。上线前也要有人确认配置文件、权限账号、备份策略。这个责任边界很难由代码生成工具承接。AI 可以解释某个报错的可能原因比如“连接池满可能是因为连接未释放”但它无法承担系统故障的责任也无法在事故复盘时向业务方解释为什么做出这个决策。信息化项目最终影响的是真实业务流程一旦出错需要有人负责也需要有人给出恢复方案。这种责任机制决定了传统岗位不会因为代码生成能力提升而消失。3.5 岗位职责与AI能力对照表岗位角色日常职责AI 可协助AI 无法替代需求分析师澄清需求、输出规则整理文档、生成模板与业务方访谈和确认架构师技术选型、拆分模块对比方案、生成架构草图结合团队和成本做决策开发工程师编码、自测、代码审查生成代码、补测试判断业务正确性、修复深层问题测试工程师设计用例、发现缺陷生成基础用例判断用户真实使用场景运维工程师部署、监控、故障应急生成巡检脚本、解读日志掌握回滚与应急决策项目经理排期、协调、风险管理生成周报、整理会议纪要跨团队沟通与资源协调与传统印象不同AI 不是把岗位变少而是把岗位中最模板化、最可描述的部分提速。剩余部分更多是判断、协商和承担责任这部分恰恰是传统岗位竞争力的核心。4. 用一个最小业务案例验证AI编程的边界4.1 需求描述每日积分结算案例背景是一个电商系统的“用户积分结算”功能。需求是每天凌晨计算前一天的用户积分。按积分区间发放优惠券。一个人一天只结算一次不能重复发放。支持失败后重跑但重跑不能产生重复数据。这个需求很适合用来验证 AI 编程边界因为它需要业务规则、定时任务、并发控制和幂等控制。它不像“生成一个用户注册接口”那样可以直接抄模板而是需要先定义结算口径和处理边界。4.2 人类工程师要关心的关键点写代码前工程师要确认至少五个问题结算口径基于前一天的订单还是当前积分快照退货订单是否参与积分来源下单积分、评价积分、签到积分是否都计算在内重复处理同一批数据被重复执行时如何保证不重复发放并发场景定时任务多实例部署时会不会同时执行同一个用户失败补偿处理到一半任务失败如何重跑且不产生重复数据为了支撑这些规则需要一张结算记录表CREATE TABLE user_settlement ( id BIGINT PRIMARY KEY AUTO_INCREMENT, user_id BIGINT NOT NULL, settle_date DATE NOT NULL, total_score INT NOT NULL, coupon_id BIGINT, status TINYINT NOT NULL DEFAULT 0, created_at DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP, UNIQUE KEY uk_user_date (user_id, settle_date) );唯一键uk_user_date是幂等控制的基础。不管定时任务被调度多少次同一天同一个用户只能插入一条记录。核心处理逻辑可以这样理解public void settle(String settleDate) { // 1. 检查是否已经存在结算批次避免重复执行 // 2. 查询当日需结算的用户列表 // 3. 对每个用户先尝试插入 user_settlement // 4. insert 成功才计算积分并发券 // 5. update 状态为成功 // 6. 捕获唯一键冲突跳过已结算用户 }这里还需要明确事务边界计算积分和发券不能放在同一个长事务里否则大批量用户时会造成锁竞争插入记录与后续发券必须独立发券失败要能重试。这些都不是语法问题而是对业务一致性的理解。4.3 AI生成的“伪完整”代码如果直接让 AI“写一个每日积分结算的 Java 方法”生成结果往往长这样public void settleDailyScore() { ListUser users userRepository.findAll(); for (User user : users) { int score scoreService.calculate(user); Settlement settlement new Settlement(); settlement.setUserId(user.getId()); settlement.setScore(score); settlementRepository.save(settlement); if (score 1000) { couponService.issue(user.getId(), COUPON_1000); } } }这段代码确实完成了“遍历用户、计算积分、保存记录、发券”的流程但缺少查询范围没有按日期过滤会把所有用户全部结算一遍。幂等控制没有检查唯一键重复执行会再次插入记录。异常处理发券失败不会影响后续用户也可能导致状态不一致。批量处理百万用户全部加载到内存可能导致内存溢出。事务边界一个用户失败可能导致全部回滚或部分成功。如果把它直接部署到生产环境第二天会出现大量重复发券和数据错误。AI 在答案形式上完整但在约束理解上缺失。它生成的是“从常见代码中拼接出来的样子”而不是“当前系统真正需要的实现”。4.4 验证与排查链路按“输入、处理、输出、异常”的顺序检查这个功能输入结算日期是否正确传入跨天时有没有时区问题。处理同一用户重复执行时插入是否被唯一键拦截。输出结算记录中的积分与订单明细金额是否一致。异常发券接口超时后结算状态是否还是成功重试后是否发两次。排查时查看数据库记录SELECT user_id, settle_date, status, coupon_id FROM user_settlement WHERE settle_date 2025-01-01 ORDER BY user_id;如果coupon_id为空但status为成功说明发券步骤没有补偿如果同一个user_id出现两条记录说明唯一键没有生效。同时也可以检查定时任务日志# 检查定时任务调度日志 grep settle /app/logs/schedule.log # 查看数据库是否有锁等待 show processlist;生产环境还需要增加分布式锁例如使用 Redis 锁或数据库锁表避免多个应用实例同时执行同一个任务。这些额外的保障AI 不会主动提醒需要由熟悉系统整体架构的工程师补上。5. AI编程时代的常见误区和排错思路5.1 误区一AI能生成代码就说明程序员不重要现象团队在接入 Cursor 后要求研发快速堆功能同时把代码评审和单元测试减到最少。结果AI 生成的代码在简单场景没有问题一旦遇到数据一致性、权限校验、安全防护就出现线上故障。原因AI 生成的代码是“平均概率”下的模式不是针对当前系统的确定性实现。它没有经过业务验证也没有经过测试用例覆盖。排错方式保留代码评审、单元测试、联调验证。把 AI 生成的代码当成“新同事提交的初稿”谁提交谁负责。5.2 误区二提示词写得越多需求就越清晰现象很多人以为把提示词写得很长AI 就能理解业务。实际上提示词再长也只能描述表象不能替代需求确认。正确做法先写用户故事和验收标准再让 AI 生成代码。验收示例如下Given 用户 2025-01-01 已结算 When 再次执行结算任务 Then 系统不重复发放优惠券把验收标准交给 AI输出会更接近需求。如果直接让 AI“补全功能”它只会生成看起来合理但缺少约束的代码。5.3 误区三让AI自动修复bug等于拥有一条安全链路现象把报错日志贴给 AIAI 给出修改建议研发直接复制。但报错有时只是表象真正原因在更上层。例如“数据库连接池满”可能来自慢查询而不是连接池配置。处理顺序先确认输入数据再确认文件路径和权限再看依赖版本再看配置是否生效最后看业务逻辑。AI 是辅助排错工具必须由人来判断“这个因果关系是否成立”。不能让 AI 的修改建议跳过人工验证。5.4 使用AI代码的排查顺序AI 生成的代码如果出现问题建议按以下顺序排查确认需求输入参数、状态、日期是否正确。检查数据库约束唯一键、外键、索引是否按设计创建。检查事务边界是否有全量回滚或部分提交。检查并发控制多实例是否同时执行幂等键是否生效。检查异常处理是否吞掉异常重试是否造成重复副作用。检查日志是否打印了足够上下文。5.5 常见问题速查表问题现象常见原因检查方式处理建议AI 生成的代码无法编译缺少依赖或版本不匹配查看 pom.xml / requirements.txt核对依赖版本替换为项目一致版本功能能跑但结果不对AI 未理解业务规则对照需求文档和验收标准补全业务规则后再生成或修改数据重复执行缺少幂等控制查看表结构和任务日志增加唯一键或分布式锁发券失败但状态成功异常处理不完整查看发券记录与结算状态增加补偿任务和失败重试定时任务未执行调度配置错误或时区问题检查调度平台日志统一使用服务器时区和测试任务6. 传统岗位如何借助AI继续保持竞争力6.1 用AI处理偶然复杂度把时间留给本质复杂度建议团队建立“AI 辅助但不替代”的工作流。AI 负责生成项目脚手架、单元测试骨架、常用 SQL、文档初稿开发人员负责补充业务规则、边界条件、安全校验和异常处理。这样能把时间从“背 API、查框架语法”转向“理解业务、设计模型”。学习环境可以快速用 AI 生成 demo测试各种想法。生产环境一定要人工审查和测试。一个可落地的策略是在提交代码前增加 AI 生成的代码质量抽查检查是否有硬编码、是否缺幂等、是否缺少输入校验。6.2 程序员应该重点训练的判断力与抽象能力AI 越强人类越需要训练 AI 不擅长的能力需求拆解把一个模糊目标拆成可验证的功能点。领域建模把业务规则映射成数据结构、状态机和表关系。一致性设计理解事务、幂等、并发、补偿。取舍判断知道什么时候用简单方案什么时候引入复杂框架。沟通确认能问出“结算日期按自然日还是财务日”这类关键问题。这些能力需要在实际项目中反复验证不是看几集教程就能获得。AI 生成代码的速度越快对这些能力的检验就越明显一个能澄清需求的人会让 AI 产出可直接使用的代码一个只会堆需求的人只会得到一堆需要返工的空壳。6.3 可复用的AI辅助开发检查清单在把 AI 生成的代码合入主分支前可以逐项检查是否明确输入、输出和错误返回。是否补齐了权限、校验和敏感字段处理。是否包含幂等和重复执行保护。是否定义异常处理路径而不是吞异常。是否考虑了批量数据量级和性能。是否包含单元测试或本地调试验证。是否与现有数据库表结构和命名规范一致。是否经过代码评审。将这个清单作为团队 PR 模板可以显著减少 AI 代码引入的生产问题。它不是一个摆设而是把“人工判断”落到流程里的具体方式。6.4 扩展方向从AI辅助编码走向AI Agent与领域建模下一步不是继续在“让 AI 写更多代码”上竞争而是把 AI Agent 用于自动化测试、代码审查、日志分析和知识库检索。例如使用 Spring AI 接入企业内部文档构建“项目规则问答机器人”让新人在提问时先获得业务规则说明。再例如使用 AI Agent 自动生成定时任务巡检报告把异常数据提取出来给人工确认。这些建设的前提都是人先定义好业务边界和数据模型。本质复杂度不会消失但 AI 可以让人把更多精力放到它上面减少偶然复杂度带来的疲劳。这才是传统岗位与 AI 工具共存的方向。回到文章开头说的“灯下黑”。程序员最容易忽视的不是代码怎么写而是代码背后的复杂度在哪里。AI 把代码生成变得更容易反而把人的判断力推到更关键的位置。真正不可替代的是对业务规则的理解、对数据一致性的敬畏、对系统故障的责任感。与其担心 AI 取代岗位不如把 AI 当作一面镜子它让偶然复杂度不再占用你的时间也同时提醒你本质复杂度永远需要人面对。
AI编程的边界：本质复杂度与偶然复杂度下的程序员价值
在IT编程与信息化项目里存在一种典型的“灯下黑”团队看得见代码量、接口报错、部署日志和迭代速度却常常忽略真正决定系统成败的复杂度。软件工程经典著作《人月神话》和《没有银弹》中Fred Brooks 将这种复杂度拆成两类本质复杂度essential complexity与偶然复杂度accidental complexity。本质复杂度来自问题本身是业务规则、边界条件、数据一致性等内在难度偶然复杂度来自我们使用的工具、语言、框架、配置是技术选型带来的额外负担。AI编程工具例如 Cursor、GitHub Copilot、通义灵码确实大幅降低了偶然复杂度比如生成样板代码、补全接口、编写配置文件。但为什么AI没有代替传统岗位因为信息化项目里真正消耗时间的并不是代码生成而是理解需求、拆解业务、权衡架构、保证结果可靠。这跟代码行数和编程速度无关甚至跟是否使用AI无关。这篇文章从两类复杂度出发用一个信息系统中常见的“每日积分结算”需求逐步拆解 AI 编程能完成什么、不能完成什么并讨论传统岗位在 AI 时代为什么仍然不可替代。内容适合正在使用 AI 辅助开发的程序员、准备引入 AI 编程工具的团队以及想理解“AI 替代论”边界的产品和技术负责人。1. 先区分本质复杂度和偶然复杂度那段被忽略的“灯下黑”1.1 用一条积分规则说明复杂度并不在代码表面一个看起来简单的需求“每日统计用户积分并按积分段发放优惠券重复提交不重复发放。”这句话里的每个词都需要继续细化。每日是指自然日还是财务日积分来自订单、评价还是签到统计的积分快照是什么时间点的优惠券发放的阈值是累计积分还是当日积分重复提交的判断依据是同一个用户、同一个批次还是同一个请求这些都不是语法问题而是业务规则和系统边界问题。在信息化项目中这类模糊需求非常常见。用户说“看到本月待办事项”研发需要考虑待办的定义、已办与办结的区别、权限范围、延迟显示、分页和归档。代码量可能不大但沟通和判断量很大。代码生成之前大量工作已经决定成败。如果只盯着“能不能用 AI 把接口写出来”反而会漏掉真正需要花时间的部分。1.2 本质复杂度问题域自带的复杂度本质复杂度是人类要解决问题的内在难度。它不因为换编程语言、换框架、换 AI 工具而消失。例如财务对账系统必须保证每一笔分录借贷平衡库存系统必须防止超卖核心交易系统必须支持事务和幂等医疗系统药品配伍禁忌需要完整的领域知识。这些复杂度来自业务本身的约束和不确定性。系统越贴近真实业务本质复杂度往往越高。定义上本质复杂度是问题域内包含的逻辑、约束和不确定性。它无法被删除只能被理解、拆分、建模和验证。如果需求本身就是复杂的任何技术手段都不能让复杂度消失只能把复杂度从一个地方搬到另一个地方。比如把业务规则做进数据库存储过程规则仍在把规则做成配置中心规则仍在把规则交给 AI 生成代码AI 只是把规则翻译成代码规则本身并不会因为 AI 参与而消失。1.3 偶然复杂度手段带来的复杂度偶然复杂度来自实现技术方案的附加成本。它和业务无关只和“怎么实现”有关。例如为了跑一个 Python 项目需要安装依赖、配置虚拟环境、处理 Python 版本与包版本冲突为了在 Spring Boot 中接入 MySQL需要配置数据源、写 Mapper、处理连接池参数为了在 K8s 中发布服务需要编写 Dockerfile、Service、Deployment 和 ConfigMap。这些工作很有价值但本质上不是业务规则的组成部分。它们是技术选型、平台限制和工程规范带来的额外工作。AI 非常擅长处理这一类复杂度。它能根据提示词生成依赖文件、常见配置、CRUD 接口和单元测试骨架能快速把“不知道这个框架怎么写”变成“差不多能跑”。这也是很多开发者在接触 AI 编程后第一感受是“效率提升明显”的原因。但效率提升主要发生在偶然复杂度层面而不是本质复杂度层面。1.4 两种复杂度的核心对比维度本质复杂度偶然复杂度来源问题域、业务规则、不确定性实现工具、平台、语法、配置典型例子权限模型、财务记账规则、并发一致性框架配置、依赖版本、接口样板代码能否消除不能消除只能理解、拆分、建模可以降低通过封装、工具、AI辅助主要承担者需求分析师、架构师、领域专家、资深工程师普通开发者、AI工具、代码生成器失败表现上线后业务规则不对、数据不一致编译报错、启动失败、依赖冲突关键动作澄清需求、验证边界、设计模型生成代码、查文档、调参数实际项目里这两类复杂度不是边界清晰的两个盒子。同一个问题可能会同时包含两类复杂度甚至在项目不同阶段相互转化。但先把这个模型建立起来再讨论 AI 的能力边界就会清晰很多。2. AI编程工具真正擅长消除的是哪一层复杂度2.1 Cursor、Copilot这类工具的工作方式AI 编程工具的共同点是基于大语言模型根据用户输入的提示词、当前文件上下文和项目结构生成候选代码。它们擅长补全常见模式、生成重复性代码、转换数据格式、解释某个 API 的用法以及把自然语言描述翻译成一段看起来合理的实现。但工具的工作方式决定了它需要足够的上下文。提示词如果只写“生成一个用户注册接口”没有说明字段、校验规则、密码存储方式、是否支持手机号登录、是否需要图形验证码AI 输出的只能是通用模板。真正的变化发生在开发者把业务约束输入进去之后。实际使用中可以把 AI 编程工具理解成一位非常熟悉语法、但没有业务经验的“结对程序员”。它可以快速写出 FastAPI、Spring Boot、Vue 组件、SQL 查询但它并不清楚你所在公司对“用户”“订单”“结算”的定义。代码能跑不代表代码是对的。2.2 AI对样板代码和语法细节的处理效果用一个非常小的接口示例说明。提示词可以这样写请用 Python FastAPI 编写一个用户积分查询接口。 要求 1. 输入参数userId 2. 返回用户ID、总积分、昨日积分、积分等级 3. 使用 Pydantic 做参数校验 4. 错误时返回统一 JSON 格式AI 生成的代码大致如下from fastapi import FastAPI, HTTPException from pydantic import BaseModel app FastAPI() class UserScoreResponse(BaseModel): user_id: int total_score: int yesterday_score: int level: str app.get(/users/{user_id}/score, response_modelUserScoreResponse) async def get_user_score(user_id: int): # 此处需要对接数据库与积分计算逻辑 raise HTTPException(status_code501, detailnot implemented)这段代码结构完整能帮助开发者快速理解 FastAPI 的接口写法但它没有实现真正的业务。关键点在于AI 帮你省掉的是 FastAPI 路由写法、Pydantic 模型定义、异常返回格式这类偶然复杂度。积分等级怎么算、昨日积分从哪里查、用户不存在返回什么AI 并不知道只能留出占位。这正是 AI 编程工具在真实项目中的常态它能生成模板但你必须知道模板里应该填什么业务。2.3 异步编程和 CompletableFuture 中的AI局限热门话题里经常出现“异步编程”和“CompletableFuture 异步编程异常处理”。用异步批量处理任务举例AI 可以快速生成一个教科书写法ExecutorService executor Executors.newFixedThreadPool(10); for (Task task : tasks) { executor.submit(() - process(task)); }这段代码在小型学习项目中可以跑通但放到生产环境会带来一串问题线程池队列有没有上限任务执行失败后是否记录日志应用重启后未完成的任务怎么办多个应用实例同时执行同一个任务会不会重复处理任务超时如何中断AI 不会主动问你“corePoolSize 设置为多少合适任务失败要不要重试重试会不会影响上游系统”。它只会根据常见模式继续生成。对 AI 来说异步编程的语法是确定的但异步系统的异常处理、幂等控制、资源隔离和取消机制是业务层面的取舍。这些取舍必须由工程师判断而不是由代码生成器决定。2.4 从复杂度模型看 AI 的能力边界操作类型AI 当前角色人类决策责任代码补全生成候选代码判断是否满足业务语义样板配置生成模板判断环境与版本匹配单元测试生成基础用例覆盖需求边界与异常场景架构设计只给出通用方案结合团队、规模、成本做取舍需求澄清无法替代访谈与确认必须由人主导故障定位辅助分析日志理解全链路与业务影响可以得出结论AI 解决的是“已经知道要做什么但不知道高效写出来”的偶然复杂度它对“不知道要做什么”的本质复杂度没有判断能力。接下来进入信息化项目的真实场景看看这个边界如何体现。3. 在信息化项目中为什么AI没有替代传统岗位3.1 信息化系统的UE设计原则背后是业务沟通现代信息化项目强调用户体验设计但 UEUser Experience不只是在界面上调整按钮位置。设计一个审批系统的“待办列表”需要判断审批角色、权限范围、会签还是或签、超时是否自动通过、意见是否必须填写、列表如何排序。这些规则来自组织流程而不是来自设计规范。AI 可以帮助生成前端的列表组件、状态标签、分页交互但无法替代产品经理和业务方逐条确认“超时自动通过”是否符合管理制度。信息化系统的 UE 设计原则本质上是对业务逻辑的表达方式。一个用户看不到的字段可能决定了整个流程是否合规。这也是为什么“AI 生成页面”只能作为原型不能直接成为生产系统的原因。3.2 软件开发流程里的“编码”只占一段一个信息化项目的生命周期通常包括需求调研、范围确认、方案设计、资源预算、开发、测试、部署、培训、运维。代码编写在其中只是其中一段远不是项目全貌。更常见的是大量时间花在核对需求文档、评审接口设计、准备环境、处理联调问题、迁移数据、培训用户、响应线上故障。AI Agent 可以自动提交代码、生成发布说明、整理周报但无法替代项目负责人去协调多个部门的数据口径无法替代测试人员去设计边界用例也无法替代运维人员判断回滚条件。传统岗位不只是写代码还承担流程推进、责任归属和多方沟通。AI 可以把“编码”这个环节进一步压缩但压缩不了业务确认和系统稳定性的时间。3.3 传统岗位的本质不是写代码而是做决策当需求出现冲突时比如财务部门要求数据实时准确运营部门希望批量导入后立即可用AI 无法判断哪个部门优先级更高。当技术方案出现分歧时比如用单张宽表还是多张业务表AI 无法知道团队维护能力和未来扩展方向。这个决策过程依赖领域知识、权衡意识和风险判断。程序员写的每一行代码都在固化业务规则。规则一旦理解错误后续所有自动化工具都会放大错误。AI 可以快速生成“看起来正确”的代码但“正确”的标准来自业务约束和验收标准。传统岗位的价值恰恰体现在定义这些约束上能问出“结算日期按自然日还是财务日”的工程师比能写一万行代码但从不追问细节的人更难被替代。3.4 信息化项目服务的真实场景判断、责任与回滚生产环境出现故障时AI 可以辅助分析日志但“是否回滚”“先恢复服务还是先保留现场”“通知哪些业务方”是需要人来拍板的。上线前也要有人确认配置文件、权限账号、备份策略。这个责任边界很难由代码生成工具承接。AI 可以解释某个报错的可能原因比如“连接池满可能是因为连接未释放”但它无法承担系统故障的责任也无法在事故复盘时向业务方解释为什么做出这个决策。信息化项目最终影响的是真实业务流程一旦出错需要有人负责也需要有人给出恢复方案。这种责任机制决定了传统岗位不会因为代码生成能力提升而消失。3.5 岗位职责与AI能力对照表岗位角色日常职责AI 可协助AI 无法替代需求分析师澄清需求、输出规则整理文档、生成模板与业务方访谈和确认架构师技术选型、拆分模块对比方案、生成架构草图结合团队和成本做决策开发工程师编码、自测、代码审查生成代码、补测试判断业务正确性、修复深层问题测试工程师设计用例、发现缺陷生成基础用例判断用户真实使用场景运维工程师部署、监控、故障应急生成巡检脚本、解读日志掌握回滚与应急决策项目经理排期、协调、风险管理生成周报、整理会议纪要跨团队沟通与资源协调与传统印象不同AI 不是把岗位变少而是把岗位中最模板化、最可描述的部分提速。剩余部分更多是判断、协商和承担责任这部分恰恰是传统岗位竞争力的核心。4. 用一个最小业务案例验证AI编程的边界4.1 需求描述每日积分结算案例背景是一个电商系统的“用户积分结算”功能。需求是每天凌晨计算前一天的用户积分。按积分区间发放优惠券。一个人一天只结算一次不能重复发放。支持失败后重跑但重跑不能产生重复数据。这个需求很适合用来验证 AI 编程边界因为它需要业务规则、定时任务、并发控制和幂等控制。它不像“生成一个用户注册接口”那样可以直接抄模板而是需要先定义结算口径和处理边界。4.2 人类工程师要关心的关键点写代码前工程师要确认至少五个问题结算口径基于前一天的订单还是当前积分快照退货订单是否参与积分来源下单积分、评价积分、签到积分是否都计算在内重复处理同一批数据被重复执行时如何保证不重复发放并发场景定时任务多实例部署时会不会同时执行同一个用户失败补偿处理到一半任务失败如何重跑且不产生重复数据为了支撑这些规则需要一张结算记录表CREATE TABLE user_settlement ( id BIGINT PRIMARY KEY AUTO_INCREMENT, user_id BIGINT NOT NULL, settle_date DATE NOT NULL, total_score INT NOT NULL, coupon_id BIGINT, status TINYINT NOT NULL DEFAULT 0, created_at DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP, UNIQUE KEY uk_user_date (user_id, settle_date) );唯一键uk_user_date是幂等控制的基础。不管定时任务被调度多少次同一天同一个用户只能插入一条记录。核心处理逻辑可以这样理解public void settle(String settleDate) { // 1. 检查是否已经存在结算批次避免重复执行 // 2. 查询当日需结算的用户列表 // 3. 对每个用户先尝试插入 user_settlement // 4. insert 成功才计算积分并发券 // 5. update 状态为成功 // 6. 捕获唯一键冲突跳过已结算用户 }这里还需要明确事务边界计算积分和发券不能放在同一个长事务里否则大批量用户时会造成锁竞争插入记录与后续发券必须独立发券失败要能重试。这些都不是语法问题而是对业务一致性的理解。4.3 AI生成的“伪完整”代码如果直接让 AI“写一个每日积分结算的 Java 方法”生成结果往往长这样public void settleDailyScore() { ListUser users userRepository.findAll(); for (User user : users) { int score scoreService.calculate(user); Settlement settlement new Settlement(); settlement.setUserId(user.getId()); settlement.setScore(score); settlementRepository.save(settlement); if (score 1000) { couponService.issue(user.getId(), COUPON_1000); } } }这段代码确实完成了“遍历用户、计算积分、保存记录、发券”的流程但缺少查询范围没有按日期过滤会把所有用户全部结算一遍。幂等控制没有检查唯一键重复执行会再次插入记录。异常处理发券失败不会影响后续用户也可能导致状态不一致。批量处理百万用户全部加载到内存可能导致内存溢出。事务边界一个用户失败可能导致全部回滚或部分成功。如果把它直接部署到生产环境第二天会出现大量重复发券和数据错误。AI 在答案形式上完整但在约束理解上缺失。它生成的是“从常见代码中拼接出来的样子”而不是“当前系统真正需要的实现”。4.4 验证与排查链路按“输入、处理、输出、异常”的顺序检查这个功能输入结算日期是否正确传入跨天时有没有时区问题。处理同一用户重复执行时插入是否被唯一键拦截。输出结算记录中的积分与订单明细金额是否一致。异常发券接口超时后结算状态是否还是成功重试后是否发两次。排查时查看数据库记录SELECT user_id, settle_date, status, coupon_id FROM user_settlement WHERE settle_date 2025-01-01 ORDER BY user_id;如果coupon_id为空但status为成功说明发券步骤没有补偿如果同一个user_id出现两条记录说明唯一键没有生效。同时也可以检查定时任务日志# 检查定时任务调度日志 grep settle /app/logs/schedule.log # 查看数据库是否有锁等待 show processlist;生产环境还需要增加分布式锁例如使用 Redis 锁或数据库锁表避免多个应用实例同时执行同一个任务。这些额外的保障AI 不会主动提醒需要由熟悉系统整体架构的工程师补上。5. AI编程时代的常见误区和排错思路5.1 误区一AI能生成代码就说明程序员不重要现象团队在接入 Cursor 后要求研发快速堆功能同时把代码评审和单元测试减到最少。结果AI 生成的代码在简单场景没有问题一旦遇到数据一致性、权限校验、安全防护就出现线上故障。原因AI 生成的代码是“平均概率”下的模式不是针对当前系统的确定性实现。它没有经过业务验证也没有经过测试用例覆盖。排错方式保留代码评审、单元测试、联调验证。把 AI 生成的代码当成“新同事提交的初稿”谁提交谁负责。5.2 误区二提示词写得越多需求就越清晰现象很多人以为把提示词写得很长AI 就能理解业务。实际上提示词再长也只能描述表象不能替代需求确认。正确做法先写用户故事和验收标准再让 AI 生成代码。验收示例如下Given 用户 2025-01-01 已结算 When 再次执行结算任务 Then 系统不重复发放优惠券把验收标准交给 AI输出会更接近需求。如果直接让 AI“补全功能”它只会生成看起来合理但缺少约束的代码。5.3 误区三让AI自动修复bug等于拥有一条安全链路现象把报错日志贴给 AIAI 给出修改建议研发直接复制。但报错有时只是表象真正原因在更上层。例如“数据库连接池满”可能来自慢查询而不是连接池配置。处理顺序先确认输入数据再确认文件路径和权限再看依赖版本再看配置是否生效最后看业务逻辑。AI 是辅助排错工具必须由人来判断“这个因果关系是否成立”。不能让 AI 的修改建议跳过人工验证。5.4 使用AI代码的排查顺序AI 生成的代码如果出现问题建议按以下顺序排查确认需求输入参数、状态、日期是否正确。检查数据库约束唯一键、外键、索引是否按设计创建。检查事务边界是否有全量回滚或部分提交。检查并发控制多实例是否同时执行幂等键是否生效。检查异常处理是否吞掉异常重试是否造成重复副作用。检查日志是否打印了足够上下文。5.5 常见问题速查表问题现象常见原因检查方式处理建议AI 生成的代码无法编译缺少依赖或版本不匹配查看 pom.xml / requirements.txt核对依赖版本替换为项目一致版本功能能跑但结果不对AI 未理解业务规则对照需求文档和验收标准补全业务规则后再生成或修改数据重复执行缺少幂等控制查看表结构和任务日志增加唯一键或分布式锁发券失败但状态成功异常处理不完整查看发券记录与结算状态增加补偿任务和失败重试定时任务未执行调度配置错误或时区问题检查调度平台日志统一使用服务器时区和测试任务6. 传统岗位如何借助AI继续保持竞争力6.1 用AI处理偶然复杂度把时间留给本质复杂度建议团队建立“AI 辅助但不替代”的工作流。AI 负责生成项目脚手架、单元测试骨架、常用 SQL、文档初稿开发人员负责补充业务规则、边界条件、安全校验和异常处理。这样能把时间从“背 API、查框架语法”转向“理解业务、设计模型”。学习环境可以快速用 AI 生成 demo测试各种想法。生产环境一定要人工审查和测试。一个可落地的策略是在提交代码前增加 AI 生成的代码质量抽查检查是否有硬编码、是否缺幂等、是否缺少输入校验。6.2 程序员应该重点训练的判断力与抽象能力AI 越强人类越需要训练 AI 不擅长的能力需求拆解把一个模糊目标拆成可验证的功能点。领域建模把业务规则映射成数据结构、状态机和表关系。一致性设计理解事务、幂等、并发、补偿。取舍判断知道什么时候用简单方案什么时候引入复杂框架。沟通确认能问出“结算日期按自然日还是财务日”这类关键问题。这些能力需要在实际项目中反复验证不是看几集教程就能获得。AI 生成代码的速度越快对这些能力的检验就越明显一个能澄清需求的人会让 AI 产出可直接使用的代码一个只会堆需求的人只会得到一堆需要返工的空壳。6.3 可复用的AI辅助开发检查清单在把 AI 生成的代码合入主分支前可以逐项检查是否明确输入、输出和错误返回。是否补齐了权限、校验和敏感字段处理。是否包含幂等和重复执行保护。是否定义异常处理路径而不是吞异常。是否考虑了批量数据量级和性能。是否包含单元测试或本地调试验证。是否与现有数据库表结构和命名规范一致。是否经过代码评审。将这个清单作为团队 PR 模板可以显著减少 AI 代码引入的生产问题。它不是一个摆设而是把“人工判断”落到流程里的具体方式。6.4 扩展方向从AI辅助编码走向AI Agent与领域建模下一步不是继续在“让 AI 写更多代码”上竞争而是把 AI Agent 用于自动化测试、代码审查、日志分析和知识库检索。例如使用 Spring AI 接入企业内部文档构建“项目规则问答机器人”让新人在提问时先获得业务规则说明。再例如使用 AI Agent 自动生成定时任务巡检报告把异常数据提取出来给人工确认。这些建设的前提都是人先定义好业务边界和数据模型。本质复杂度不会消失但 AI 可以让人把更多精力放到它上面减少偶然复杂度带来的疲劳。这才是传统岗位与 AI 工具共存的方向。回到文章开头说的“灯下黑”。程序员最容易忽视的不是代码怎么写而是代码背后的复杂度在哪里。AI 把代码生成变得更容易反而把人的判断力推到更关键的位置。真正不可替代的是对业务规则的理解、对数据一致性的敬畏、对系统故障的责任感。与其担心 AI 取代岗位不如把 AI 当作一面镜子它让偶然复杂度不再占用你的时间也同时提醒你本质复杂度永远需要人面对。
