企业官网建设流程全解析

上周我删掉了自己写的一千行报表代码，让 AI 重新生成，然后用一个下午逐行审查，最终保留的不超过三成。放在半年前，我绝对不敢这么干——不是不相信 AI，而是不相信自己的判断力。但这件事做完之后，我反而对“工程师会被取代”这个论调彻底免疫了。

生成式AI重构软件工程的速度，比大多数人想象得快，也比大多数人想象得浅。说它快，是因为常规编码、测试生成、文档整理这些环节正在被大幅压缩；说它浅，是因为到了需求定义、架构取舍、质量判定这些核心地带，AI 几乎没有真正深入。把这两个观察叠加在一起，就会得到本文想聊的结论：工程师没有死，死的是只把自己当成“代码生产者”的旧角色，重生的是拥有判断力、领域知识和系统思维的工程人。

这篇文章是我最近用 AI 做完一个真实迭代后的复盘，也包含我对软件工程整条价值链的重新理解。如果你正在写代码、带项目，或者正准备软件工程的课设和毕业设计，里面有些思路可以直接拿来用。

1. 打开编辑器之后，AI最先毁灭的是“旧习惯”

1.1 曾经的三千行“熟练工代码”，现在只是AI的第一版草稿

我早期工作的很长一段时间，衡量自己有没有进步的标准很朴素：今天写了几行代码、重构了几个模块、熟不熟悉公司内部的框架套路。这套标准在信息不对称的年代是成立的，因为能写代码的人始终是少数，企业愿意为“能交付功能”这件事付费。

但现在情况变了。生成式AI把“从需求到代码”的门槛压到极低，一个业务模块的 CRUD、一个后台管理页面、一套标准接口文档，它生成的速度比我手写快五倍以上。我见过不少开发者在惶恐中把同样的需求丢给 AI，然后不可思议地看着它输出一份“比自己多年经验写得更规范”的初稿。

这里有个很扎心的真相：过去三年攒下的“熟练工代码能力”，在 AI 面前只是第一版草稿。如果你引以为傲的是“我熟悉 Spring Boot 的写法”“我熟悉 Vue 的组件套路”，那这种优势正在快速蒸发。代码生成不再稀缺，稀缺的是知道这些代码要在什么约束下运行、要为什么样的业务目标负责的人。

1.2 真正先承压的岗位链路：接需求、写码、交差，中间没有任何个人附加值

不是所有工程师都会先感受到压力。我观察到一个规律：工作链路越短的人，被 AI 覆盖得越快。所谓链路短，就是“接到需求、写完代码、交付上线”三步走完，中间没有业务博弈、没有方案取舍、没有对历史包袱的判断、没有对未来的预留设计。

这类岗位的特点很典型：需求是产品经理拆好的，接口是后端定义好的，任务是排期表上的，验收标准是现成的。人在这个链条里的角色只是一个“编码执行器”，而编码执行恰好是 AI 最擅长模仿的部分。

反过来，链路长的人反而不慌。他们要么在需求阶段就和业务方反复拉扯，要么在设计阶段做了关键技术决策，要么在测试阶段定义了什么才是“正确”。这些环节没法直接被 AI 替换，因为业务语义藏在人的经验里，技术取舍嵌入在团队的现实条件里。AI 面前没有不可替代的岗位，只有不可替代的环节和不可替代的人。

1.3 我和同事两周实测：编码时间减半，审查时间翻倍

为了不让自己停留在空想，我和一个同事做了一次为期两周的对照记录。我们选了一个常规业务迭代，包含两个新功能、一次数据库表结构调整和一个旧接口改造。

结果非常直观：过去我一天大概有 5 到 6 个小时在敲代码，剩余时间开会、看需求、改 bug；引入 AI 辅助后，敲代码的时间被压缩到 1 到 2 小时，省下来的时间几乎全部流向了代码审查、边界确认和与业务方对齐口径。我同事更夸张——他用 AI 处理数据迁移脚本，原来一整天的工作变成两小时，然后把多出来的时间全拿去和运营讨论字段口径，结果发现一个隐藏了半年的数据统计错误，线上几十张报表都被影响了。

这两周的数据给了我一个强烈的信号：工序在变短，节奏在变快，但人对判断力的要求变高了。那个隐藏半年的错误一直存在，只是因为以前“大家都在写代码”，没人愿意停下来多想一步。现在 AI 把“写”的负担卸掉，人的精力终于可以回到“想”和“判断”上。这就是价值重生的起点。

2. 软件工程价值链的六个环节，重构顺序完全不同等

要理解生成式AI重构软件工程，不能停在“AI 会写代码”这个表面结论，得把软件工程的完整链条拆开看。我习惯把工程过程分成六段：需求分析、系统设计、编码实现、测试验证、部署运维、文档维护。AI 在每个环节的侵入程度和替代难度完全不同。

2.1 需求分析最先被重构：AI把我从“转译器”变成“追问者”

需求分析是重构最早、也最容易被低估的一环。过去产品经理丢过来一段自然语言描述，工程师要在脑子里转好几道弯，才能把它翻译成表结构、接口参数和状态流转。现在把那段话丢给 AI，它几分钟就能拆出用户故事、边界条件、验收标准，甚至会主动列出风险点。

我实测过的做法是：把一段 200 字的需求描述交给 AI，让它输出需求条目清单，包括功能点拆解、前置条件、异常分支、非功能需求。产出的质量已经接近一个初级需求分析师的水平。

但这只是表面。真正让我改变工作方式的，是我发现自己开始把更多时间花在“追问”上——追问 AI 草案里的假设只能在什么条件下成立，追问业务方更倾向哪条路径。AI 生成的草案里藏着大量看似合理但从未被业务验证的假设。比如它会把一个线下审批流程自动理解成线上审批，把固定定价理解成动态定价。工程师如果照单全收，系统从源头就错了。所以这个环节被重构的本质不是“AI 代替人做需求”，而是“AI 打掉低级的整理成本，逼人把精力投向业务定义和歧义消除”。

2.2 系统设计最难被替代：AI擅长模式罗列，不擅长环境约束

到了系统设计阶段，AI 依然有用，但作用方式完全不同。它最大的价值是模式联想：你告诉它“我要做一个高并发下的订单状态机，还要支持回滚”，它能迅速给出状态模式、事件溯源、分布式事务等多种成熟方案的对比。

但架构设计的真正难点从来不是“知道有哪些模式”，而是“在约束下做取舍”。业务处于什么阶段，团队熟悉什么技术栈，系统背负了多少历史包袱，未来半年可能迎来什么变化——这些因素共同决定同一个模式在此处是良药还是毒药。AI 看不见你代码库里的那段遗留逻辑，不知道你们的发布节奏，更无法理解客户对稳定性的真实容忍程度。

我的经验是：可以让 AI 做方案对比表，让它在延迟、一致性、复杂度、运维成本几个维度铺开信息，但最后的选型决策必须由人来拍板。AI 把架构设计的起点抬高了不少，却并没有降低终点的门槛。恰恰相反，因为起点变高，决策者需要输出的判断质量也更高了。

2.3 编码实现贬值最快，代码审查升值最快

编码是所有人第一眼看到的变化。我负责任地说，常规业务的编码实现，AI 已经能承担 50% 甚至更高的产出比例。样板代码、数据访问层、接口定义、前端页面骨架，这类工作 AI 完成的质量相当稳定。

但这里有一个反直觉的结论：恰恰因为 AI 能高效生成代码，代码审查变得比写代码更重要。

以前自己写的代码，思路在脑子里，写岔了还能兜回来。现在 AI 生成的代码，逻辑不一定和你想的完全一致，里面可能存在边界遗漏、隐藏依赖、过度设计甚至幻觉函数。我曾经让 AI 给支付模块生成自动重试逻辑，它产出的代码看起来很完善，但没有考虑幂等键，一旦重试就可能造成重复扣款。这个问题只有在人工审查时才能真正暴露。

所以编码环节的变化本质上是执行密度下降、审查密度上升。不会审查的人，看 AI 写的什么都觉得对；会审查的人，才知道 AI 生成的代码里藏了多少需要二次确认的地方。代码审查能力，正在从“加分项”变成“生存项”。

2.4 测试运维走向“主动防御”：从劳动密集场景变成审查密集场景

测试和运维环节也躲不开这次重构。过去测试用例很多靠人肉补，尤其边界值和异常场景的用例，写起来枯燥又容易漏。AI 在这块是天然的边界发现器，我让它根据接口参数约束生成边界值用例，它的组合覆盖度比我手写还全。

但必须警惕另一个问题：AI 生成的测试用例容易陷入“为覆盖而覆盖”的自我满足。它可能把主流程拆成 30 个用例，而真正决定业务成败的规则却一个都没测到。工程师在这个环节的任务不是“执行用例”，而是“判断哪些用例保住了业务价值”。

性能测试是测试里最容易被忽视的细分方向。国内其实已经有一套规范化的方法论可以参考，就是 GB/T 39788-2021《系统与软件工程 性能测试方法》。这套标准把性能测试拆成需求分析、指标设计、场景设计、执行、结果分析五个阶段，本质上是在告诉团队：性能压测不是随口说“压一下接口”，而是要先明确业务负载模型和目标指标。AI 能帮你更快地编写压测脚本、制造模拟数据，但如何把性能问题与系统设计建立关联，如何从结果反推出瓶颈位置，仍然需要人来完成。标准提供的是问题定义框架，真正落地性能评估闭环的，依然是工程师本人。

运维也类似：告警分析、日志归因、故障排查，AI 能把关联信息一次拉齐，但最终的止损决策和恢复方案，得有一个人来权衡风险。越靠近底层执行，AI 越强；越靠近责任边界，人越重要。

3. 一个真实迭代的AI辅助全程复盘：从需求拆分到数据迁移

概念说再多，不如一个完整的实操记录。我拿刚做完的一个迭代来复盘：改造系统里的订单查询接口，响应时间从 2 秒降到 300 毫秒以内，底层表结构从单表拆成主子表，还要完成存量数据迁移。整个过程全程用 AI 辅助，但每一步关键决策都由人拍板。

这个案例的步骤、卡点、踩过的坑，下面都说清楚。

3.1 第一步：让AI拆需求，但业务假设必须逐条人工确认

我把需求描述整理成一段结构化输入，包含接口来源、调用方、峰值流量、可用性要求、失败率容忍度，然后交给 AI 输出需求拆分清单。AI 的产出很漂亮：功能需求、性能需求、迁移需求、兼容性需求，每条都带验收标准。

但当我逐条审视时，发现它默认把“查询失败返回空列表”写进了行为预期。我们的业务流程完全不是这样，查询失败时应该返回明确错误码并触发告警，而不是静默地给前端一个空数组。这种业务规则 AI 无法感知，如果我直接采纳，整个告警链路就断了。

这一步最重要的教训是：把 AI 输出的验收标准当成一份待审文档，而不是参考答案。我花了一个多小时逐条核对，把 AI 假设但业务不允许的地方全部标红。人在这里的价值不是“写文档”，而是“识别 AI 看不见的业务红线”。

3.2 第二步：方案对比表AI出，选型结论必须人来定

接着我让 AI 给出三种改造方案：索引优化、缓存方案、表结构拆分，每个方案附带性能预估、实施成本和风险说明。AI 半小时内给出一张对比表，列得相当专业，甚至考虑到冷缓存启动的影响。

但最后我没有选它自动推荐的“缓存优先”。原因是我们的业务场景里，缓存一旦失效会瞬间打满数据库，而运维组当前没有完善的缓存预热机制。与其引入一个新的不稳定因素，我选择了先做索引和查询逻辑优化，结果响应时间从 2 秒降到 400 毫秒，已经满足目标。

这个案例很简单，但我每次都会讲给团队听：AI 的方案建议基于一般性规律，而真正的工程决策基于你和团队独特的历史条件。方案对比可以交给 AI，选型责任必须留给自己。

3.3 第三步：AI生成的迁移脚本，我只信任审查后的那一个

表结构拆分涉及存量数据迁移，这是整个迭代里风险最高的一步。AI 生成的迁移脚本很快，但越快到手里，我越要放慢审查节奏，因为脚本一旦出错，影响的是线上真实数据。

我的审查顺序是固定的：先看脚本的幂等性，确认它能被重复执行而不出错；再看事务边界，保证迁移中断时能够回滚；接着核对查询代码在拆分后是否保持原有语义；最后看接口返回结构对调用方有没有隐形影响。

这个固定顺序不是凭空来的，是我早年吃过亏换来的。果然在这次审查中，我发现 AI 生成的临时表没有在同一批次数据内做字段拆分，一旦迁移中途执行中断，重新执行会产生脏数据。这类问题真人手写时大概率不会犯，但 AI 就是会这样“看起来合理”地错。所以我立了一条不可商量的纪律：AI 生成的迁移脚本，未经人工审查绝对不许上生产环境。

3.4 第四步：AI负责边界覆盖，我负责业务规则用例

迁移完成后，我让 AI 生成了一组接口测试和迁移数据校验脚本，它的边界值覆盖确实不错。但我补了 5 个 AI 想不到的手工用例：

• 迁移后历史订单与用户账单的对账异常分支；
• 主子表关联时的孤儿数据检测；
• 接口在业务高峰期触发降级时的返回逻辑；
• 旧版本调用方传参非预期类型的情况；
• 数据迁移过程中新写入订单的追加逻辑。

这 5 个用例里，有两个在实际执行中真正暴露了问题。一个是孤儿数据检测没通过，另一个是降级返回逻辑没有覆盖到超时场景。

这件事让我形成了一套分工认知：AI 负责广撒网，人负责画靶心。AI 的边界发现能力很强，但业务规则必须由人来讲述和确认。

3.5 这次迭代省了多少时间，又花在了哪里

最后看结果：总工时比过去省了接近一半，代码生成和基础测试环节节省最明显。但我必须诚实地说，没有一个环节可以完全交给 AI。迁移脚本审查、业务用例补齐、上线前性能基线确认这三件事，我花的时间比“写代码”更多。

这也解释了我写这篇文章的初衷：生成式AI重构了软件工程的工序比例，但没有重构掉工程师的判断责任。所谓价值重生，本质是工作从“生产”转移到“审查和决策”，这一步对工程师能力考核的难度，比之前更高了。

4. 工程师价值重生的四个支点：判断、全局、领域、提问

把实操案例摊开之后，我越来越确信“价值重生”可以被拆成具体能力点。这里聊聊我最近反复思考的四个方向，每个方向都对应一条具体动作。

4.1 判断力：在AI“自信地犯错”时踩刹车

AI 生成内容有一个隐蔽危险是“自信地犯错”。它给出的方案、代码、文档通常逻辑通顺，但细节处漏洞百出。要在这种输出里挑错，靠的是判断力。

判断力不是玄学，是一种基于明确原则的检查习惯。我要求自己每次审查 AI 输出时，完成三个反问：核心假设在当前业务里是否成立？输入输出的边界有没有被忽略？如果某个中间步骤失败了，整个流程能不能恢复？把这三个反问变成肌肉记忆，审查速度和准确率都会明显提升。AI 会变得越来越强，但它“自信地犯错”的特性不会消失，能识别这种错误的工程师，就是团队里最稀缺的人。

4.2 全局化：学会给AI的活动空间设围墙

第二个能力转移，是从局部思维走向全局思维。过去工程师的任务边界往往是一个功能模块，现在 AI 可以快速生成某个功能，工程师就需要为整个系统负责：定义什么可以做、什么不能做、资源边界在哪里。

我举个例子。以前做接口设计，可能很快就去写 Controller 和 Service；现在我会先定义接口的容量上限、超时策略、降级表现，以及这些策略和下游其他接口的关系。全局化的本质，是给 AI 的活动空间设围墙——围墙内 AI 可以肆意发挥，围墙怎么立，必须人说了算。

系统约束定义得越清楚，AI 越能高效；定义得越模糊，AI 生成的东西就越容易失控。很多团队抱怨 AI 生成的代码没法用，问题不在 AI，在于约束条件压根没写明白。

4.3 领域知识：AI看不见业务语义，也负不了客户责任

第三个能力是领域知识，这也是最容易被低估的部分。AI 可以从代码库里学到语法模式和设计套路，但它学不到公司审批流程里为什么一定要保留人工节点，学不到客户对“订单取消”和“订单作废”的细微语义差异。

我见过一个典型的反面案例：有人让 AI 生成订单作废接口，AI 直接把状态置为“取消”。业务同事看到后脸色大变，因为这两个状态在财务结算里完全不同，一旦挪用，月结报表全部错乱。如果工程师没有领域知识，AI 的代码就是完美的错误。

价值重生的一个重要含义，就是愿意走进业务场景，理解结算逻辑、用户习惯和组织协同，成为那个把技术语言翻译成业务语言的人。这个身份在任何时代都有价值，而在 AI 时代，它的稀缺性正在被无限放大。

4.4 问题定义：AI负责回答时代，人负责问出对的问题

最后一个能力是问题定义。AI 很擅长回答，但不擅长告诉你该问什么。当业务方说“这个报表速度太慢了”，只具备编码能力的人会想“怎么优化 SQL”，而具备问题定义能力的人会先问：这个报表给谁看？多长时间更新一次？是不是必须实时？能不能用更简单的统计口径替代？

问题定义一旦偏移，后续所有 AI 生成都会沿着错误方向滑行。所以我认为，未来的软件工程会越来越像“提问驱动的工程”：谁有能力定义出清晰、有边界、能验证的问题，谁就能调动 AI 产生真正的工程价值。

这四个支点不是我坐在书桌前想出来的，是在一次次把 AI 的犯错成本亲手扛下来之后，沉淀出来的体会。它也让我对“工程师能力模型”这件事有了更具体的理解。

5. 说给正在学软件工程的你：别让AI替你交差，要让AI替你放大训练

写到这里，我想专门跳出来和一类读者聊几句——正在学软件工程专业、正在为课程设计和毕业设计头疼的同学。从很多搜索行为里都能看出，大家正在大量使用 AI 来完成课设、画用例图、查标准、选论文题目。这些需求很真实，但我想给你提供一个不同的使用姿势。

5.1 课程设计还能不能靠AI？能，但要做三个“训练动作”

我理解课程设计时间紧，用 AI 生成代码和文档几乎是挡不住的趋势。但你要明白，如果 AI 只用来“交差”，那你的工程训练等于没做，毕业之后面对第一轮筛选就会露馅。

比较可取的做法是把 AI 当成“高速原型工具”：用 AI 生成课程设计的第一个版本，然后强迫自己完成三件事——向 AI 反向提出至少五个质疑问题；亲手修改代码中至少一个 AI 设计错误；写清楚如果业务需求变化 10%，这个方案里哪个部分最脆弱。

这三件事做下来，你就把一次普通作业变成了一次真正的系统设计训练。哪怕最后交付的代码里仍然有 AI 生成的痕迹，你自己的工程判断也已经渗透进去了。面试官问起来，你也真的能讲明白“为什么这么做”。

5.2 毕业设计和论文选题，如何避开“AI三分钟可答”的题目

很多同学纠结毕业设计选题，总觉得要选一个 AI 写不出来的题目。其实方向反了——不要去找“AI 随便能写出来”的题目，要去找“AI 需要大量人做判断”的题目。

举个例子。一个普通库存管理系统，AI 很容易完成，因为它只有几条增删改查；但一个“考虑供应链时效波动的最小库存建议系统”，就需要你定义指标、建模约束、采集数据、验证结论。AI 可以辅助生成代码和文档框架，但主要工程判断只能靠你自己。后一种题目才是毕业设计该有的样子，因为它在训练你“定义问题”和“论证取舍”。

论文选题同理。与其让 AI 生成一段综述，不如把综述当作搜索起点，去读原始文献，找其中互相矛盾的结论，然后围绕矛盾展开分析。软件工程从来不缺“包含新技术”的题目，缺的是有明确问题意识、能说清楚取舍理由的研究。

5.3 把标准规范当预习框架：从GB/T 39788-2021到你的第一个项目

如果你还在学软件工程导论，可能觉得标准规范枯燥无聊。但在 AI 重构工程的时代，规范反而是最值得花时间理解的部分。前面提到的 GB/T 39788-2021《系统与软件工程 性能测试方法》就是一个很好的例子。

这套标准把性能测试拆成需求分析、指标设计、场景设计、执行、结果分析五个环节。你完全可以拿它当框架，去拆解任何一个系统：这个系统到底关注什么指标？要模拟什么真实场景？结果怎样才算达到目标？在学校里建立这种“工程化思维框架”，远比掌握某个具体工具重要。等真正进入生产环境，AI 负责高效产出，你负责用框架去检验和组织它，确保方向不偏。到那时候，AI 就不再是和你抢工作的对手，而是你手里的杠杆。

我个人最近越来越喜欢用“框架优先、AI 填充”的方式来带项目和带新人，效果比一开始就闷头写代码好得多。这也是我在这个阶段最想分享的一条路径：让 AI 替代掉重复劳动，把你空出来的精力全部砸向判断、取舍和定义问题。这条路走通了，工程师的价值不但没有稀释，反而会比以前更清晰，也更值钱。