企业官网建设流程全解析

很多人现在都在问同一个问题：AI 都能写代码了，Cursor 一开，AI Agent 自动补全函数、修 bug，甚至能一口气生成整个 CRUD 模块，为什么公司里那些传统 IT 岗位不但没被干趴下，反而越来越难招？

如果你自己就在用 AI 编程，同时又在困惑“它为什么没有彻底改变行业”，那这篇文章想跟你聊清楚一个底层原因：本质复杂度和偶然复杂度。

这个概念来自《人月神话》作者 Fred Brooks 的经典文章《没有银弹》。它解释了软件开发的困难到底来自哪里。今天重新拿出来看，正好能回答一个更现实的问题：AI 已经这么强了，为什么没有代替传统 IT 岗位？

我会先讲清楚这两个复杂度分别是什么，然后结合信息化项目的真实场景，拆解 AI 编程的边界，最后聊聊传统岗位的工程师接下来应该怎么调整自己的定位。

1. 核心复杂度概念速览

在进入长篇分析之前，先把两个核心概念放在一张表里，后面所有讨论都围绕这张表展开。

简单说：偶然复杂度是“怎么实现”的代价，本质复杂度是“到底要做什么”的代价。

AI 编程工具目前最强的地方，恰好集中在偶然复杂度。而传统 IT 岗位每天最头疼的，恰恰是本质复杂度。这两者没有对齐，所以“AI 替代传统岗位”这件事，远没有想象中那么快。

2. 为什么 AI 编程先干掉的是“偶然复杂度”

先看一个现象：AI 编程工具最擅长做什么？

代码补全、生成样板代码、翻译旧语言、写单元测试、解释报错信息、生成 DTO/VO、搭 Spring Boot 项目、写 CRUD 接口、格式化代码、补注释。这些任务有一个共同点：它们都有相对明确的输入输出模式，有大量历史代码可以学习，而且失败的成本较低——代码不对，编译器会告诉你，测试会告诉你，AI 再改一版就行。

这些任务几乎全部属于偶然复杂度。

举个例子，使用 Cursor AI 编程时，最流畅的场景往往是这样的：

# 用户输入的自然语言需求 生成一个 Spring Boot 的 UserController， 包含分页查询、新增、修改、删除接口， 使用 MyBatis-Plus，返回统一 Result 结构。

AI 几秒钟就能输出一个可以运行的 Controller 层代码，包含注解、参数校验、异常处理。这在十年前需要熟练工写半小时，现在确实只需要“复制粘贴 + 微调”。

但要注意，这里 AI 解决的是：框架怎么用、注解怎么写、方法怎么组织。这些是典型的技术实现细节。

如果把需求换成这样：

我们是一个多法人集团，下面有多个事业部， 每个事业部的成本中心不同，但部分公共费用需要按人头比例分摊到各事业部。 月底结账时，需要按事业部维度生成分摊凭证， 并且分摊逻辑要支持冲销和追溯。 请设计数据库表和分摊算法，并考虑一个月内多次分摊的数据版本管理。

AI 依然能给出一个看似合理的方案，但真正要落地，你还需要回答几十个问题：分摊比例按编制人数还是实际人数？社保公积金算不算人头？月内离职的人怎么处理？已经结账的月份如果调整人数，是追溯还是只影响当月？

这些问题的答案不在任何代码仓库里，而在财务制度、管理流程和历史习惯里。这就是本质复杂度。

所以结论很清晰：AI 编程工具先替代的是“怎么实现”的体力活，而不是“要做什么”的脑力活。而且它替代得越彻底，反而越把人的注意力逼向本质复杂度。

2.1 从提示词看 AI 的边界

很多人觉得“我只要会写提示词，就能让 AI 写整个系统”。这句话一半对，一半不对。

对的部分在于：AI 确实能把“从文字到代码”的翻译成本降到极低。不对的部分在于：“从模糊业务到清晰需求”这一层，AI 目前没有能力帮你完成。它只能基于你给的上下文做推测，而推测永远不等于确认。

看一下常见 AI 编程提示词和真实开发任务之间的差距：

越靠上，AI 的替代率越低；越靠下，AI 的替代率越高。而传统 IT 岗位真正值钱的，恰恰是上面那些不能被替代的部分。

3. 信息化项目的复杂度来源：本质复杂度的真实分布

聊完概念，再回到信息化项目本身。

为什么说信息化项目是本质复杂度的重灾区？因为信息化项目的核心不是“写一套软件”，而是“把现实世界的业务规则转译成系统规则”。现实世界的东西一旦进入系统，所有模糊地带都需要被强制收敛。

一个传统信息化项目里，复杂度通常是这么分布的：

注意看：信息化项目里最难啃的骨头，几乎全是本质复杂度。

举一个很常见的场景：一个 ERP 实施项目中，物料主数据的编码规则看起来是个纯技术问题——只要写一段生成编码的代码就行。但现实里，编码规则可能牵扯到采购部、仓储部、财务部、生产部。每个部门对“同一个物料”的分类口径都不一样。编码规则一旦定错，后面所有库存、成本、采购单据全部会对不上。

AI 能根据你的描述生成编码算法，但它不知道财务部要求“原材料”和“辅助材料”必须在编码上体现区别，也不知道仓储部认为“同一个物料从不同供应商采购要建两个编码”这个规则合理还是不合理。这些知识散落在业务人员的脑子里、旧 Excel 表里、甚至一次会议纪要里。

这就是本质复杂度：它不会因为你用了更好的 AI 工具而消失。

4. 为什么 AI 没有代替传统岗位：五个现实原因

如果把“为什么 AI 没有代替传统岗位”这个问题拆开，至少有五个层面的原因。

4.1 原因一：AI 降低的是“写代码”的成本，不是“知道写什么”的成本

代码是软件的最终形态，但代码不是软件的成本中心。真正的成本中心是“定义软件的边界”。

传统岗位每天在做的事，大量是：

• 跟业务方开会确认“这个按钮要不要出现”
• 理解为什么这个数据不能删
• 判断一个需求改动会影响哪几个下游系统
• 在性能、成本、维护性之间做取舍

这些事不产生代码，但决定代码长什么样。AI 降低了“翻译需求为代码”的成本，反而让“需求本身是否正确”变得更加重要——因为 AI 会非常高效地把错误需求变成正确实现的错误系统。

4.2 原因二：传统岗位的价值不只是编码

“程序员”这三个字容易让人以为价值就是写代码。但在信息化领域，一个成熟工程师的价值通常包含编码之外的多层能力：

• 需求分析：能从模糊描述中提炼出明确规则
• 架构设计：知道什么场景用消息队列，什么场景必须强一致
• 风险控制：知道哪些技术选型在长期运维里会出问题
• 沟通协调：能把业务语言翻译成技术语言，再把技术方案翻译回业务语言
• 运维保障：线上出问题时能快速定位

AI 可以辅助其中每一项，但每一项都需要一个“人来兜底”。AI 生成的架构方案可能看起来专业，但真正出了问题，要背责任、要通宵排查、要跟客户解释的，还是人。

4.3 原因三：本质复杂度来自业务世界本身，无法被消除

Brooks 在《没有银弹》里说：没有任何单一技术突破能带来软件生产率数量级的提升，因为本质复杂度是不可消除的。

业务世界的复杂度是真实存在的。一个集团公司的组织架构、一个行业的监管要求、一个工厂的生产节拍，这些东西不会因为你用 AI 写代码就变得简单。AI 能做的，是降低“把你已经理解的东西变成代码”的摩擦。

换句话说：AI 让“实现”变得便宜，但没有让“理解”变得便宜。

4.4 原因四：AI 的产出需要人确认，责任归属没有消失

AI 编程工具生成代码的速度越快，引入问题的速度也可能越快。一段由 AI 生成的代码，如果没有经过严格的 review，谁为它的 bug 负责？在传统公司里，答案永远是“写这段代码的人和它的负责人”——不管代码是谁生成的。

这意味着：即使 AI 能生成 90% 的代码，剩下 10% 的确认、修改、把关工作依然需要人。而恰好是这部分工作，对人的要求比单纯写代码更高。你不但要会写，还要能判断别人（或 AI）写得对不对。

4.5 原因五：存量系统和技术债，AI 无法一键重构

传统岗位大量时间花在维护老系统上。这些系统可能用了十几年的技术栈，没有测试，没有文档，业务逻辑和 UI 代码揉在一起。

AI 工具面对这种代码库，表现往往远不如面对一个干净的新项目。AI 需要理解上下文，但老系统最缺的就是可理解的上下文。它不像新项目那样有清晰的分层和命名，也没有完整测试来约束 AI 的生成结果。

所以现实是：老系统的技术债，依然要人一行一行地梳理、一个接口一个接口地迁移。AI 可以辅助生成迁移代码，但“决定先迁哪块、怎么验证、怎么回滚”依然依赖人的判断。

5. AI 时代的编程范式变化：从手写到审阅编排

虽然 AI 没有代替传统岗位，但它确实在改变传统岗位的工作方式。最明显的变化是：从“写代码”到“审阅代码”，再到“编排 AI”。

5.1 从 Writer 到 Reviewer

以前一个初级开发者的核心能力是“写出能跑的代码”。现在 AI 能快速生成大量“看起来能跑”的代码，初级开发者的一部分价值被压缩了。

但反过来说，审阅代码的能力变得更重要。你要能看出 AI 生成的代码里有哪些隐患：事务边界对不对、并发控制有没有问题、异常路径有没有被吞掉、SQL 会不会全表扫描、权限校验有没有漏。

这个能力比“写出代码”更难培养。因为它要求你同时具备业务理解、系统设计和代码细节的全局视野。

5.2 从 Coding 到 Orchestration

AI 编程的进阶用法不是让 AI 写一个函数，而是设计一整条流水线。举例来说，使用 AI Agent 的时候，你要规划：

1. 让 AI 分析需求文档，提取实体和关系 2. 根据实体关系生成数据库表结构 3. 基于表结构生成后端 CRUD 接口 4. 自动生成前端页面和 API 调用 5. 编写单元测试和接口测试 6. 最后人工 review 并修复问题

这个流程里，人已经从“写代码的人”变成了“定义流程的人”。你需要决定每一步怎么拆分、什么结果算合格、如何验证、失败怎么办。这种编排能力，本质上还是在面对本质复杂度——你要理解整个系统应该长什么样，才能告诉 AI 每一步做什么。

5.3 异步编程和 AI Agent 的结合

最近讨论比较多的方向是 AI Agent 和异步编程的结合。一个典型场景是：AI 任务不是同步等结果的，而是异步跑任务、回调通知结果。比如批量生成 1000 张报表、批量处理 Excel、自动修复代码规范问题。

这类任务背后都会涉及异步编程、任务队列、失败重试、幂等控制。AI 可以生成这些代码，但你要能设计出稳定可靠的任务系统。这里又回到了传统后端工程师的核心能力：并发、队列、分布式事务、异常处理。

AI 并没有消灭这些知识，反而因为 AI 让更多人能写出“第一版代码”，导致具备这些深度的工程师变得更稀缺。

6. 传统岗位的真正护城河：处理本质复杂度的能力

聊到这里，结论已经很清楚了。传统 IT 岗位的护城河不是编程语言，不是框架熟练度，而是处理本质复杂度的能力。

这个概念可以拆成几个具体技能：

这些技能有一个共同点：它们都需要“语境”。而 AI 最缺的就是语境。

AI 可以在你明确输入上下文之后给出很好用的答案，但它不会主动去了解你所在公司的组织架构、你负责系统的历史包袱、你的业务方真正在意什么。这些语境只有在长期工作、持续互动中才能积累。

所以，传统岗位真正要担心的不是“被 AI 替代”，而是“只掌握偶然复杂度层面的技能、完全依赖 AI、却无法处理本质复杂度”。

7. 实际操作：用 AI 编程工具降低偶然复杂度

道理讲完，给一个可落地的操作思路。虽然本文不是工具教程，但可以用一个真实感很强的场景，说明 AI 编程工具到底应该怎么用。

7.1 场景：快速搭建一个订单查询接口

假设需求是：开发一个订单查询接口，支持按订单号、客户名称、时间范围查询，返回分页结果。

在传统工作流里，你可能要写 Controller、Service、Mapper、DTO、XML 一堆文件。现在用 AI 编程工具，提示词可以这么写：

我现在有一个 Spring Boot 3 + MyBatis-Plus 项目。 请帮我生成一个订单查询接口，要求： 1. Controller 路径为 /api/orders/page 2. 入参包含 orderNo（可选）、customerName（可选，模糊匹配）、startTime（可选）、endTime（可选） 3. 出参使用 PageResult<T> 包装 4. 查询逻辑放在 OrderQueryService 中 5. 日期范围使用 create_time 字段 6. 生成的代码要包含参数校验 请先输出目录结构，再按文件逐一生成代码。

AI 会生成一套可运行的代码。这套代码解决了什么？解决的是 Spring MVC、MyBatis-Plus、分页插件、参数校验这些偶然复杂度。

但真正设计这个接口时，你还要回答：

• 订单是只查主表，还是要联查明细？
• 客户名称是匹配当前系统的客户，还是历史快照？
• 查询超时了怎么处理？
• 是否需要限制最大查询时间跨度？
• 这个接口会被哪个前端调用，需要哪些字段？

这些问题 AI 不会主动问，但它能根据你的回答快速调整代码。这就是人和 AI 的正确协作方式：人负责本质复杂度，AI 负责偶然复杂度。

7.2 场景：用 AI 批量生成单元测试

另一个典型场景是补测试。老项目没有测试代码，要让 AI 帮忙生成。

一个建议的提示词框架：

请为 [类名] 生成单元测试。 要求： 1. 使用 JUnit 5 + Mockito 2. 覆盖正常路径、边界条件、异常路径 3. 对于外部依赖全部使用 mock 4. 测试方法命名遵循 given_when_then 风格 5. 不要修改被测类的源代码 被测类的路径是：[粘贴路径]

AI 生成的测试能帮你快速提高覆盖率。但关键的业务断言需要人来补充——比如“超过库存不能下单”“报销金额不能超过预算余额”这类规则，AI 不知道你的业务期望值是多少。

7.3 给 AI 输入上下文的最佳实践

AI 编程工具的效果好坏，很大程度上取决于你怎么给它上下文。分享几个实践经验：

• 给出项目技术栈和版本，减少 AI 乱猜
• 给出具体文件路径，而不是只贴代码片段
• 给出失败案例，让 AI 知道什么做法不可行
• 大任务拆小步执行，每步验证后再让 AI 继续
• 让 AI 先输出方案，再写代码，不要一上来就生成

这些实践的核心，本质上还是在补齐 AI 缺失的“语境”。

8. 常见认知误区与提醒

关于 AI 与传统岗位的关系，网上有很多说法。下面这几个误区值得单独拿出来说。

8.1 “AI 能替代所有初级程序员”

不准确。AI 能替代“只会写简单 CRUD 的初级程序员”，但替代不了“愿意深入业务的初级程序员”。

初级工程师的成长路径也在变化。以前靠大量写代码积累经验，现在可以靠“审阅 AI 代码 + 补充业务知识”更快成长。那些只会让 AI 生成、自己不思考的人，才会真正被替代。

8.2 “AI 生成的代码可以直接上线”

强烈不建议。AI 生成的代码必须经过人工 review、测试和压测。尤其在涉及资金、个人信息、权限控制的场景，AI 生成的代码里可能存在安全漏洞或逻辑缺陷。

一个典型例子：AI 生成的删除接口可能没做权限校验， 或者生成的分页查询没有处理超大页码，导致数据库压力过大。

这些问题在 AI 生成代码里很常见，因为 AI 只知道“一般怎么写”，不知道你的安全规范和业务约束。

8.3 “提示词写得越复杂越好”

不一定。提示词要提供充分上下文，但不需要写成一本小说。冗余的提示词反而可能引入噪音，让 AI 抓不住重点。

更好的做法是：先给核心需求，生成初稿，再通过多轮对话调整。比如先让 AI 生成一个基础版本，再要求“加一个限流注解”“改成读从库”“加上操作日志”，逐步逼近最终目标。

8.4 “AI 编程工具能自动处理所有遗留系统”

目前做不到。遗留系统的最大问题是上下文缺失：没有文档、没有测试、命名混乱。AI 面对这种代码库时，表现远远不如处理结构清晰的新项目。想用 AI 重构老系统，你需要先把关键路径的上下文梳理清楚，才能让 AI 发挥作用。

9. 未来三到五年：IT 岗位的技能结构变化

最后聊一下接下来的趋势。

三到五年前，一个后端工程师的核心技能可以概括为：Java 语法、Spring 框架、MySQL、Redis、消息队列、Linux。现在这些依然是基础，但它们正在从“核心竞争力”变成“基本盘”。

未来的技能结构会越来越像这样：

对传统 IT 从业者来说，最值得投入的方向不是“学更多框架”，而是“进入一个领域的深处”。你懂财务，懂 ERP，懂供应链，懂出版流程，懂医院的业务流程——这些领域知识叠加 AI 工具能力，才是未来最稀缺的组合。

反过来，如果只停留在“我会用 Cursor 生成代码”这个层次，面对 AI 的冲击会非常脆弱，因为这只是偶然复杂度层面的技能。

10. 总结与下一步

最后把核心观点收一下。

AI 之所以没有代替传统岗位，不是因为 AI 不够强，而是因为传统岗位的价值很大一部分在本质复杂度上。AI 编程工具强在降低偶然复杂度：快速生成代码、翻译接口、补测试、写文档。但业务规则的理解、需求边界的确认、系统架构的取舍、责任和风险的承担，目前仍然需要人来完成。

如果你是正在焦虑的传统 IT 从业者，建议按这个顺序做三件事：

第一，把 AI 编程工具用熟。Cursor、Copilot、通义灵码都可以，关键是形成自己的提示词和 review 习惯，把这些工具变成日常工作的加速器。

第二，刻意练习本质复杂度的处理能力。多参与需求评审，多了解业务方的真实痛点，不要只盯着技术细节。

第三，选择一个业务领域深耕。信息化项目里，行业知识就是最大的护城河。一个既懂 AI 编程又懂业务规则的工程师，在市场上会比纯技术岗位更有价值。

AI 不会简单粗暴地“替代传统岗位”，它会重新划分工作：把偶然复杂度交给机器，把本质复杂度留给更少但更关键的人。你想站在哪一边，取决于现在开始往哪个方向积累。