我最近在一个技术群里看到两种截然相反的情绪。一边的人说AI 写代码已经明显比我快了接口、工具类、配置脚本回车一敲就能生成我再手写这些东西到底还有什么意义另一边的人很不屑真放到生产环境业务规则一复杂、边界条件一多AI 根本接不住最后一样得靠人。两边都觉得自己很有道理但多数时候根本讨论不到一块去。原因在于他们把两种复杂度混在了一起。我习惯把软件研发和信息化建设里的问题拆成两层来理解一层叫本质复杂度一层叫偶然复杂度。这两个概念并不是什么新词早年间 Brooks 在讨论软件工程时就已经做过很经典的分析。但放在今天 AI 编程被大量讨论的背景下它特别适合用来回答一个让大家困惑了很久的问题AI 明明已经能写大量代码为什么传统岗位没有被成批代替我的核心判断是AI 真正大幅降低的是偶然复杂度也就是那些由工具、写法、配置和环境带来的额外成本而大多数传统岗位的核心价值越来越集中在本质复杂度上也就是那些即使代码生成速度提升十倍也依然存在的判断、责任和取舍。传统岗位没有被代替不是 AI 不够强而是因为多数岗位里最难的部分从来不是“把代码写出来”而是“搞明白到底应该写什么、有哪些约束、如何定义验证标准”。下面展开讲讲我对这两层复杂度的理解以及一位长期在这个行业里工作的人在这种变化下应该怎样调整自己的重心。1. 先搞清楚问题的边界本质复杂度和偶然复杂度1.1 什么是本质复杂度本质复杂度是问题本身固有的复杂度。它不是由你选了哪门语言、用了哪个框架、搭了哪种环境带来的而是这件事如果要做对就必须面对的那些不确定性、约束冲突和取舍。举一个很常见的例子假设你要给订单系统新增一个“库存扣减”功能。表面看需求就一句话下单后扣减库存。但等你真正落地时要回答的问题往往是这一串扣减发生在订单创建、支付成功还是发货前超卖怎么处理并发请求过来了库存竞争怎么解决扣减失败要不要回滚订单取消或者退款之后要不要恢复库存多个仓库都有货优先扣哪一个商品拆单之后库存怎么分配这些问题不会因为你用了最新的 AI 编程工具就自动消失它们来自真实业务场景本身。无论你用 Java、Go 还是 Python无论有没有 AI都必须有人去把这些问题搞清楚、定下来。本质上AI 能降低写代码的成本但降低不了做决策的成本。这类问题就是本质复杂度。它像一座山你绕不开它只能选择造桥、挖隧道或者爬过去但无论选择哪条路径都要为“翻过这座山”付出成本。1.2 什么是偶然复杂度偶然复杂度是手段带来的额外成本。它和问题本身的难度无关只是因为技术方案、工程环境、历史包袱和周边摩擦产生的。再举几个日常场景旧项目还在用老版本构建工具新同事光安装依赖、统一环境就花了一个下午某个内部 SDK 文档写得不清楚调用方只能反复试参数框架升级后一组 API 被废弃迁移工作占了整整一个迭代为了一个简单的列表页你要同时理解前后端、权限系统、基础组件的调用方式CI 脚本里的环境变量配置经常出问题每次发布都有人要现场排查几十分钟。这些都是偶然复杂度。它们的共同点是如果换一套更顺手的工具或者有一个更合理的工程基础设施这些成本可以被压缩甚至被消除。它们不来自问题本身而来自“当前做事的方式”。用大白话讲本质复杂度是“这件事本身有多难”偶然复杂度是“做这件事时被额外消耗掉了多少精力”。前者绕不开后者可以优化。1.3 现实工作里这两层复杂度往往是叠在一起的真正在项目里做事时这两层复杂度很少泾渭分明。项目启动初期团队经常要花不少时间处理依赖安装、网关配置、模型接入、目录结构。这些偏向偶然复杂度。但等项目进入业务规则讨论阶段产品、研发、测试、运营反复拉扯此时处理的又主要是本质复杂度。一个模块能不能按期交付往往取决于这两种复杂度叠加后的总成本。这正好解释了为什么很多关于 AI 的讨论最后变得鸡同鸭讲。你说“AI 已经很厉害了”你举的例子往往是什么表结构生成、接口实现、重复代码补全这些更多属于偶然复杂度对方说“AI 根本不靠谱”他举的例子往往是需求有歧义、跨模块影响不明确、上线后出现故障这些更多属于本质复杂度。两边都没有说错只是讨论的不是同一层。2. AI 真正降低的是哪一类复杂度2.1 AI 编程工具到底做了什么目前被讨论最多的 AI 编程工具核心能力大致可以分成几类代码补全、代码生成、代码解释、测试用例生成、重构建议、文档补全。在日常工程里这些能力最直接的影响是把“已经知道怎么写但还一个字一个字敲出来”的成本压得很低。比如你很清楚一个标准的 CRUD 接口需要哪些部分但原来要完整写出 Controller、Service、Mapper 和一堆校验逻辑比较费时间。现在 AI 可以根据表结构、模型定义和上下文生成大部分骨架你只需要在关键节点做调整。这个环节节省的是实现摩擦而不是“要不要这样设计”的判断。还有一个很明显的变化在脚手架和配置场景。以前接手一个新项目初始化目录、配置数据库连接、写 CI 脚本先花半天时间很常见。现在很多 AI 工具能根据描述生成示例结构你负责确认和修改。这类工作本来就是典型的偶然复杂度AI 在这里的体验感最强。说到这类工具目前大家接触比较多的 AI 编程助手基本都有类似补全、解释、生成测试的能力。有些人还会把 Cursor 这类编辑器形态的工具当成主战场也有团队更倾向于把 AI 能力嵌入现有 IDE。工具的形态以后可能还会变但本质逻辑一样让“从想法到代码”这段路的门槛变低。2.2 效率提升并不等于岗位替代很多人看到这里会忍不住做一个线性推理既然 AI 把“写代码”这件事的成本降到接近零那程序员岗位也应该趋向于零。这个推理的漏洞在于一个岗位的价值从来不是“写代码”这个动作本身的价值。在真实研发流程里编码通常只占一部分时间。更多时间花在理解需求、拆解任务、确认依赖、处理异常、评审方案、制定验收标准、压测验证、排查线上问题、评估风险回滚方案。这些环节的成本受偶然复杂度影响但更受本质复杂度制约。AI 能把“生成候选代码”这个动作变快但不能帮团队判断“该选哪个方案”。比如某个新功能是直接改老服务还是拆一个新服务老方案复用性高但引入额外耦合新方案边界清晰但要增加一套运维链路。这个决定需要看团队规模、数据量、未来演进方向、现有基础设施能力甚至还要考虑几个月后谁来做维护。AI 可以帮你把这个方案写出来但大多数时候它不会替你回答“我们该不该走这条路”。用一个容易理解的类比导航软件能帮你把“从 A 到 B 的路线计算”做得非常快但前提是你得知道目的地是哪里。路上遇到临时封路需要有人判断是绕行还是调整目的地。代码生成工具就像导航路径规划很强但“要去哪里”和“这段路是否值得走”这种判断还是得有人负责。2.3 偶然复杂度下降后本质复杂度反而会变得更显眼这里有一个反直觉的效应。过去偶然复杂度多少掩盖住了一部分关键问题。团队把大量时间耗在环境配置、依赖调整和写法统一上反而没有足够精力去认真讨论需求里的模糊点。现在 AI 把实现速度提上来之后瓶颈会越来越快地暴露在需求分析、系统设计、风险判断这些环节上。换句话说以前一个项目落地慢可能并不是因为业务多复杂而是因为搭建环境、写框架代码、改配置太慢。现在这些成本被压缩之后如果项目还是延期原因大概率就集中在需求不清、边界不明、验收标准缺失、跨团队协同不畅这些本质复杂度上。我倾向于把这种变化理解为AI 不是在替你解决问题而是在把真正需要人来解决的问题从噪声里暴露出来。这对愿意解决难题的人其实是好事但对只靠“熟能生巧”积累经验的岗位压力会越来越大。3. 为什么传统岗位没有被代替3.1 岗位核心正在从“把需求做成代码”转向“确保做成的东西是对的”传统岗位尤其是研发和信息化相关岗位过去很容易被理解成一种“翻译”工作把产品需求翻译成技术方案再把技术方案翻译成代码。如果这种流程只是单纯翻译AI 确实有机会替代。但真实世界根本不是这样运转的。真实世界里需求经常是不完整的、矛盾的、动态变化的。拿“采购管理系统的价格修改功能”来说到底谁能改能改到多少历史价格是否保留修改是否需要审批不同部门给出的答案很可能不一样。采购部希望操作简单财务部希望留痕管理层希望有权限限制。最终的规则不是靠什么机器自动推理出来的而是需要项目相关方一次次对齐、确认最后沉淀成可执行的方案。AI 生成代码时通常只能基于已经明确的输入而明确输入这件事恰恰是传统岗位里更有价值的部分。所以我的看法是岗位没有消失但岗位的重心发生了转移。过去你可能每天花两小时写代码、一小时看方案、半小时想需求未来可能变成一小时写代码、两小时审查和确认生成结果、一小时整理关键决策半小时推动跨团队对齐。同样是信息技术类岗位产出不再是“代码行数”而是“可靠的交付”。3.2 模糊信息、隐性约束和人机协作的权衡除了需求模糊系统里还藏着大量隐性约束。某个接口要求响应时间低于 200 毫秒库存服务每秒最多只能承接多少调用数据库主从同步通常有延迟某些场景是否可以容忍老系统里某些接口不能随便加日志否则会影响性能。这些约束往往不在文档里而在长期维护系统的少数人员脑中。AI 看不到这些约束除非有人把它翻译成提示词、检查项和验证用例并且保证它是真的。这对使用者提出了一个很高的要求你必须有足够的能力判断一段由 AI 生成的代码在当前业务环境下是否正确。这就回到了本质复杂度上。责任边界也是一个大问题。代码由 AI 生成但出了线上故障跟着排查和承担责任的永远是人和团队。因此负责任的团队不会因为代码由 AI 生成就降低审查标准反而会更强调有人对代码、方案和后续影响做最终理解。这里的“人”就是传统岗位里不可替代的一环。3.3 适合 AI 的任务与不适合 AI 的任务结合这些年接触项目的经验我习惯用下面这个二分法来判断工作是否容易被替代。它不一定绝对但可以帮助你建立体感。适合交给 AI 的任务不适合完全交给 AI 的任务明确的单一功能实现需求不完整且各方诉求不同的设计重复性的 CRUD 代码编写多个约束条件之间的权衡测试用例初稿生成判断测试覆盖是否满足业务风险代码解释和文档补全跨团队梳理流程和权责边界重构候选方案生成最后拍板要不要承担技术债配置示例和脚手架生成灰度发布失败时的应急决策这张表的核心思想不是把 AI 说得一无是处而是在“最后判断”这个环节AI 很难完全承担起责任。所谓不适合不是它不能提供建议而是没有人能代替你做最终确认。4. 当 AI 生成结果不对时先查哪一层4.1 先看现象实际使用 AI 编程工具时我们经常遇到四类现象生成结果完全不是自己想要的代码能运行但边界条件不对结果看上去合理放到复杂工程里却出现隐性问题反复调整提示词后依然生成类似错误。很多人的第一反应是马上换提示词、调参数、重新提问。这不是不对而是顺序容易错。更好的做法是先弄清楚问题出在哪一层再去动相应的地方。4.2 再看输入最常见的错误源头其实不是 AI而是输入。这里说的输入包括自然语言描述、上下文代码、技术约束、验收标准。你只写一句“写一个导出功能”AI 就只按最传统的理解生成当然会少很多细节。正确的改进方向不是让 AI “更聪明地猜”而是先把输入补完整导出字段有哪些、用户权限怎么校验、文件大小上限、超时时间、失败提示、数据源来自哪个表、是否需要异步处理。你是不是把这些约束写得越清楚AI 生成的结果越接近可用。所以当你觉得 AI 生成的内容很傻时先问一下自己我有没有把本质复杂度里最关键的问题告诉它如果连人都没有把需求说清楚指望 AI 自动补全显然不现实。4.3 再看环境排除输入问题之后第二步看环境。AI 生成的代码依赖什么版本项目里是否已经存在同名类数据库连接方式是否一致CI 脚本里的变量能不能正常传递很多时候生成结果放到项目里编译不过不是 AI 能力不够而是它默认的依赖、目录结构或运行时环境和当前项目不一致。这种问题更接近偶然复杂度解决方式也很直接把项目里已有的依赖清单、目录结构、相关代码片段作为上下文放进提问里。4.4 再看参数再往下才是参数。对 AI 对话类工具来说参数指提示词结构、上下文长度、温度、示例数量等。对更复杂的 AI Agent 应用来说还要看任务分解方式、允许调用的工具范围、重试策略和日志输出。建议先用一个两个小任务做参数验证再逐步放开。不要一上来把一个庞大任务丢给 AI也不要让它在缺少约束的情况下自由发挥。给 AI 的上下文不是越多越好核心是要覆盖到它做出关键决定时所需要的信息。4.5 最后看工具边界最后一个要排查的是工具边界。每个 AI 工具的能力范围都有限制有的擅长代码生成但不擅长处理超长上下文有的对特定框架支持较好有的工具无法真正理解项目的全局关系。如果你已经调整了输入、环境、参数问题还是存在那就需要考虑换工具、换模型或调整方案。平时大家说得比较多的“AI 编程提示词”“AI Agent”“Spring AI”这类方向本质上都是在讨论如何更好地适应工具边界。熟悉这些方向本身没有错但要记住一件事工具边界会随着版本迭代不断变化真正不变的是分析问题的顺序。这套排查链路看起来很简单但如果完整走一遍会比你盲目换提示词高效得多。它也能帮你过滤掉很多情绪不要把“我不会描述”误判成“AI 不行”也不要把“工具边界限制”误判成“我提示词水平不够”。5. 不要只学会用工具要学会重新设计工作方式5.1 一个可复用的框架定义目标 — 划定边界 — 建立验证我很早就意识到AI 编程这类工具用得越多越需要一套稳定的协作框架。否则AI 效率越高越容易把半成品快速推向生产。我推荐的是三条流程定义目标、划定边界、建立验证。步骤看起来不复杂关键是要真正做到。第一步定义目标。不要只写“实现登录”要明确登录方式支持哪些是否需要第三方登录错误提示怎么处理连续失败锁定策略是什么这些信息不只是给 AI 看的也是给你的产品和技术团队看的。它们代表了问题里本质复杂度的一部分。第二步划定边界。不要期待 AI 自动理解所有限制。把它不允许修改的文件、不允许影响的模块、不能接受的性能下降都写清楚。如果任务规模较大就让 AI 先给方案经人确认后再进入实现阶段。这样 AI 越强你越能控制风险。第三步建立验证。不要因为生成结果看起来差不多就把它合入仓库。至少要跑一遍功能自测、边界条件用例、异常流程查看代码差异和潜在影响范围。有条件的话再补上测试覆盖率和静态检查。这套框架的核心价值不是“提高 AI 生成准确率”而是保留你对问题定义和验收标准的控制权。过去你花两小时写代码现在可能只花二十分钟让 AI 生成剩下的时间用来思考边界条件以及排查问题这是值得的。5.2 对从业者而言真正需要补齐的能力技术人最担心的问题往往是如果以后代码都由 AI 完成我的核心竞争力还剩什么我的答案比较直接核心竞争力会向以下几个方向移动。需求澄清能力。能在一个模糊的需求里找出一长串需要确认的问题能问出关键疑问让原本模糊的规则变得明确。系统拆解能力。能根据业务场景把一个复杂目标拆成若干可以独立验证的小任务再决定哪些交给 AI哪些必须人工介入。验收设计能力。能提前列出边界条件、异常场景和风险点让 AI 生成的代码不只是在“正常路径”上可用而是在完整场景中可靠。异常判断能力。能通过日志、指标和用户行为判断问题是输入、环境还是代码逻辑导致的不至于被 AI 生成的“无毒但错误”的代码带偏。沟通协调能力。能把技术方案中的取舍说明白让非技术角色也能理解风险和前提。这一点在信息化建设里本来就很关键只是过去被低估了。这些能力有一个共同点它们大多发生在代码生成之前或之后而不是在具体生成过程中。换句话说AI 让每个人都有一个速度很快的“代码助手”但“如何定义任务、如何识别风险、如何保证结果可用”仍然需要你来完成。5.3 哪些岗位更有冲击哪些岗位更安全根据上面的判断我们可以做一个大致分类。一个岗位如果主要以“执行明确任务”为主比如只做标准化接口开发、写固定模板、完成定义清晰的配置变更那么 AI 的影响会很大。因为这类工作大部分落在偶然复杂度里AI 很容易上手。如果一个岗位的日常大量涉及“定义任务、权衡约束、处理不确定性”比如架构设计、业务方案、技术评审、复杂质量保障、系统运维应急那么即使 AI 使用程度很高岗位也依然需要人来承担。这不是说初级岗位会全部消失。初级岗位里“纯执行的偶然复杂度”比例的确会下降但如果新人能提前掌握“如何定义问题、如何验证问题、如何应对不确定性”这些能力依然有很强的竞争力。相反如果只停留在“我会调某个框架、我会写某种代码”的层面AI 持续进化后的替代压力会明显变大。6. 岗位不会消失但岗位内容一定会改变6.1 从“写代码的”走向“定义问题的”最近几年一些岗位描述和招聘期待已经开始变化。大家不再只看“会什么框架、有多少年工作经验”而是问“能不能把一个模糊问题梳理清楚、能不能设计出一套可验证的方案、能不能在关键节点提出风险判断”。这两者的差别正好对应这篇文章的核心逻辑。代码本身的重要性会继续下降但问题定义、方案权衡和风险控制的重要性会继续上升。这可能会让一部分人觉得不安因为“写代码”是很多人已经比较熟悉的确定性技能而“定义问题”听起来很虚。但从实际情况来看AI 越是擅长生成代码问题定义能力就越会成为稀缺品。6.2 一个现实的持续性判断AI 可以每天生成成千上万行代码但一个项目并不能每天上线成千上万行代码。系统最终要可维护、可观测、可回滚必须有人考虑数据一致性、模块依赖、安全策略、用户体验、性能峰值和运营流程。这些判断并不只是一次提示词调用就能完成的它们背后是组织、流程、规则和长期认知积累的结合。所以我更愿意把当前阶段理解为AI 提高了“产出动作”的速度但没有完全提高“交付动作”的可靠度。可靠的交付依然依赖那些属于本质复杂度的工作。无论是几个人还是一个很大的团队想靠 AI 把代码量堆上去比较容易想靠 AI 替代“对结果负责的人”还很遥远。6.3 现在最应该做的事是什么如果只给一个建议我会说别急着追求复杂提示词技巧先练习拆解问题。拿到一个需求先不要问“这个功能 AI 能不能写”而是先分析这个任务里哪些是本质复杂度哪些是偶然复杂度。哪些判断必须由人来完成哪些生成工作可以交给 AI。把任务按这个维度拆完之后AI 怎么用提示词怎么组织自然就清楚了。AI 是否能代替传统岗位本质上可能是个错题。真正的题眼是我们愿不愿意从习惯了很多年的执行层迁到决策和判断层。这也是“灯下黑”给人的启示大家总是盯着 AI 的光芒觉得它什么都能写、什么都会干却忽略了那些必须由人来点亮的地方。代码生成、文档补全、异常分析都是光但光源背后的人才决定这条路要怎么走。