企业官网建设流程全解析

标题这个话，我思考了挺长时间。过去一年多，我和身边不少人一样，深陷在“AI 什么都能写”的兴奋感里，GitHub 的提交频率确实上去了，几个晚上能赶出以前一周的活。但最近两三个月，体感在微妙地变。我担心的不是 AI 写不出代码，而是我们对它的依赖方式出了问题，那种“只要把需求敲进去，剩下的全能交出去”的状态，正在被现实一点点校正。这篇文章不是什么预言，就是一名普通开发者过去一年的复盘：AI 到底改变了我的哪些工作方式，哪些地方它其实一直在漏风，以及我准备怎么重新校准自己和它的关系。

1. 为什么我会说“蜜月期要结束了”：三个扎实验收时刻

1.1 蜜月期的画面：那段时间我确实像在开挂

先承认一个事实——2023 年底到 2024 年年中这段时间，我和绝大多数开发者一样，处于一个极其亢奋的状态。那时候我接了一个内部数据看板项目，需求是实时的，业务方今天提，明天就想要。换作以前，我光是把表结构理顺、把查询逻辑写完，就得熬到凌晨。但那时候我基本是照着一个大致思路，把需求分解成十几条描述，让 AI 去生成核心查询和接口代码，我再做参数调整和组装。项目提前一周上线，那种感觉就是“手底下凭空多了一支外包团队”。

这个阶段大家的普遍心态是：

• 需求描述得越细，出的代码越能直接跑，“提示词”简直像咒语。
• 重构老代码是重灾区，但看起来又极其解压——丢进对话框，替身帮你重写。
• 技术债、遗留系统、看不懂的代码段，再也不怕了，反正可以丢给 AI “翻译”。

1.2 转折点：从“疯狂生成”到“反复核验”

真正让我产生“不对劲”感受的，是三个非常具体的时刻。

第一件事发生在一个订单模块的改造里。AI 生成的代码看起来很完备，方法抽得很干净，常量也替换了魔法数。但合并前我照例跑了一遍测试，发现它把“满减活动”的边界条件搞错了。它不是不会写满减逻辑，而是在我描述里存在一句不够严谨的话，它过度理解了。如果不仔细测，这个 Bug 就会直接上生产，影响的是真实用户。

第二件事是同事的反馈：他在团队里做了一个统计，AI 辅助提交的代码，平均 review 轮次从之前的 1.2 轮提高到了 2.4 轮。代码表面上是“对”的，但总是缺上下文——缺业务约束、缺既有模块的约定、缺历史包袱带来的特殊处理。大家靠“它能写”省下来的时间，又花在了“我得把它改成符合我们现状”的返工上。

第三件事是行业讨论里出现的常态话题——AI 生成的代码让“代码量”看起来繁荣，但代码仓库里开始堆积大量“一次性正确后就没有后续维护价值”的代码。它确实能生成让人耳目一新的方案，但它不会告诉你，这个方案在三个月后是否还能继续演进。

1.3 蜜月期结束的本质：不是决策，是校正

我把这个阶段理解为“蜜月期的结束”，不是说 AI 没用了，而是那种“我只需要提需求”的幻觉在破裂。真实的工作流回归到一个更朴素的原则：AI 越快，验证的责任就越重。生成代码的边际成本趋近于零，但审查代码的成本没有归零，反而涨了。这才是让人开始“担心”的地方——因为大部分团队的管理者，如果只看代码量和交付速度，根本看不清背后的审查压力和隐患积累。

你如果现在还是用“提需求—收代码—直接合并”的模式，可能暂时能应付一些小项目，但在一段时间后，你会发现自己写的代码里，充满了你没完全看懂的“黑盒”，而你作为唯一的负责人，慌得不行。

所以我认为，蜜月期结束了，是件好事。它逼着你从“看它表演”回到“你来做导演”。但为什么说“我担心”？因为我看到不少同行在这个刚刚结束的蜜月期里，选错了下一个阶段的方向——反而把自己工具化的程度加深了。

2. AI 能力的真实边界：它能打的地方，和它反复翻车的场域

2.1 真能打的地方：样板、单点与解释

先从正面盘点。经历过一年多的实际项目打磨，我依然认为 AI 在下面这些场景里，属于“换了一个人帮你干活”的级别。

第一个是样板代码生成。接口层的 CRUD、出入参 DTO 转换、几个固定分页实现，这些代码都有极度相似的模板结构。我自己的日常是：表结构设计完，让 AI 扫一眼建表语句，直接把对应的实体、Mapper 和基础 Service 骨架生成出来。我只需要做命名审查和字段核对。这部分效率提升是实打实的，大概能节省 60%-70% 的时间。它不是写出什么了不起的架构，而是把最枯燥的部分吃掉了。

第二个是“命令行 / 脚本 / 配置”类问题。比如写一段 Shell 脚本处理日志压缩、写一段正则提取特定的字符串、写一个 Python 脚本批量重命名文件。AI 在这方面极其稳定，它见过的样本太多了，只要描述得够具体，基本拿来就能改改跑。

第三个是“代码解释和语言迁移”。让我读懂一段远古 Java 代码它到底在干嘛，或者把一段 Python 高效算法翻译成 Go 实现，这是 AI 最舒服的场景。因为这类任务本质是“压缩和转述”，AI 的归纳能力有天然优势。我自己在接手历史系统时，会让 AI 先把核心流程的时序解释一遍，再逐模块确认，比人肉啃快得多。

第四个还没被充分挖掘的：测试数据的构造和错误案例生成。你给它一个函数的入参逻辑，让它生成边界值列表、异常场景列表，它给出来的比大多数开发临时想的全面。

2.2 反复翻车的地方：重构、并发与隐性知识

接下来必须说反面的，不然你会被错觉坑惨。

大范围系统性重构，AI 目前没法独立完成。我曾经尝试让 AI 把一个老单体服务的鉴权逻辑从“Session 内嵌变量”改成“统一的上下文过滤器”。它给出的第一步总是正确的：新建过滤器、定义上下文结构体。但从第二步开始就飘了：它不知道老代码里有多少地方是直接从 Controller 里取变量的，也不知道哪些接口是给内部系统调用的、做的事情和外部接口不一样。这不是提示词写得好不好的问题，是整个系统里蕴含的“历史决策信息”太密集，AI 的上下文根本装不下。

并发、性能调优和分布式问题，AI 经常“自信地犯错”。它在回答“这个并发插入场景会不会出问题”时，会给你一套看起来严丝合缝的理论答案——有锁、有事务、有幂等。但在实际环境里，真正卡住的是数据库隔离级别、连接池大小、缓存穿透、部分失败的回滚机制。AI 容易把复杂问题的局部答案，误当成全局答案。你一旦照搬，故障复盘时痛苦的还是你自己。

隐性的业务约束，AI 几乎无法自己“悟”出来。比如同一个“用户状态”字段，在 A 模块里 0 代表启用，在 B 模块里 0 代表注销；再比如某些数据删除必须走软删除加审计流水，某些模块可以直接物理删。这些规则往往不在需求文档里，只在资深开发的脑子里。你如果不把这些约束逐条在提示词里写死，AI 生成的代码就是“干净的错误代码”。

2.3 边界之所以存在：三个底层原因

说到底，这不是 AI 不够聪明，而是机制决定的：

• 预测式生成，不是验证式执行。AI 在生成代码时，并没有真的把这份代码跑起来，也没有在跑起来后根据报错调整。它是在“模拟一份看起来正确的代码”。对于它见过无数遍的模板，这个模拟很准；对于它没见过的全局交互，它就只能基于概率补全。
• 上下文窗口是有限的经济学。一个中大型项目的核心约束，往往散落在几十个文件、几份历史文档、若干次代码评审记录里。你没法把它们全部塞进对话，塞进去了也迅速稀释掉重点。模型只能在给定上下文里做局部最优，局部最优叠起来，经常等于全局混乱。
• 它缺乏“运行时反馈闭环”。人类开发在写完代码后，会经历编译、测试、灰度、监控、报警这样的反馈链条。AI 现在的工作方式，大体上是“提交代码就走人”。虽然出现了智能体编程、多步骤 Agent 这类东西，但我实际测试下来，它们在小任务里还行，一旦进入需要和既有系统深度交互的长链路，依旧不稳定。

所以，我对 AI 的定位目前是：一个极其高效的“协作者”，但它需要你清晰地定义边界、验收标准和风险兜底。再大的模型，也替代不了“我知道系统为什么会这样设计”的那层判断。

3. 行业里那些“嘴上不说，但正在发生”的变化

3.1 招聘要求的变化比想象中更快

蜜月期的结束，最先体现在招聘端。因为长期使用 AI 做辅助，不少团队发现“能快速产出代码”的候选人变多了，但“能说清楚为什么这么设计”的人，反而更难招了。

说一个我观察到的现象：某团队在招聘中级后端开发时，面试题倒没有太大变化，但面试官会额外追问一句：“你平时怎么用 AI 辅助开发？如果 AI 给出的方案和你的经验冲突，你怎么判断？”

这个变化背后是一个残酷的事实：初级岗位的产出优势，被 AI 抹平了。以前一个刚毕业的候选人和一个五年经验的候选人，写同一套 CRUD，前者可能慢一半，但 AI 直接把前者补到和后者差不多的“跑得快”水平。那团队为什么还要招初级？因为他需要的是“知道为什么这套 CRUD 要按某种规范写、哪里可能踩坑、怎么演进的人”

我甚至见过有些团队开始明确把 AI 工具的使用记录当作考察项，不是看谁用得多，而是看谁“用得能自我辩护”。你说让 AI 写了整个模块，那好，请解释每一个关键分支的取舍依据是什么。答不上来，这一个项目做得再像样，也只能当成是“有人帮你代笔但没有内化”。

3.2 团队内部出现新的两极化：AI 依赖者和 AI 怀疑者

我发现团队里开始慢慢分化成两拨人。

一拨是 AI 依赖者。他们写代码前先找 AI 要答案，拿到就复制改改，遇到问题第一反应是“我再把报错丢给它”，而不是自己读代码、查资料。这批人短期看产出很大，但长期看风险极高——他们对自己手上系统的掌控力，正在快速下降。有一次线上告警，一个小需求的改动引发了老缓存逻辑冲突，AI 依赖型的同事盯着报错日志看了很久，又去问 AI 是怎么回事，AI 给了一个看起来合理的解释，他差点就真信了。最后还是团队里的老手用 tracer 一步步定位到具体那次调用链，才发现是几年前的过期时间戳配置导致的。

另一拨是 AI 怀疑者。他们对 AI 生成的东西一概不信任，宁可自己慢慢写，也不肯把核心逻辑交给模型。这批人虽然稳定可靠，但效率确实在团队里开始显得偏慢。在现在这个节奏下，完全不用 AI 的开发者，在任务评估和承接量上会被动不少。

这两拨人之间，其实需要一个中间状态：把 AI 当成“加强版的搜索引擎和代码生成器”，但所有输出都要经过自己的头脑完成一次“残留知识的验证”。很遗憾，目前能做到这一点的，还是少数。

3.3 组织层面开始从“拼速度”转向“算总账”

前半年，很多技术管理者被 AI 带来的生产速度飙进迷惑了，认为“人效提了三倍，团队可以减员了”。但半年后，一批头脑清醒的管理者开始算总账：维护成本、返工成本、技术债利息。

• AI 生成的代码，测试覆盖率不一定高，补测还是得人来补。
• 大量一次性代码涌入主干，复用性差，三个月后没人敢动。
• 线上故障的原因里，开始出现“AI 生成代码的二义性实现”“逻辑看似正确但漏了临界判断”这类条目。

于是，团队规范开始回调：允许用 AI 生成，但必须经过更严格的代码评审、必须有补充测试、必须由负责人解释设计意图。这个“回调”在我看来，就是蜜月期结束在管理层面的直接映射。它不代表倒退，恰恰说明组织终于开始认真对待 AI 了。

3.4 对“纯 prompt 工程师”的证伪

这两年有个很热的岗位概念叫 Prompt 工程师，大意是“只要提示词写得好，不需要编程基础，也能让 AI 产出应用”。我身边也有人真的试过，让一个不懂代码的同事去搭一个小工具。

结果很有趣：初期 Demo 确实惊艳，十几分钟弄一个能跑的表单工具、静态网站颇像回事。但一进入真实业务环节就卡住了——需要接公司统一登录、需要从数据库里按复杂权限取数、需要和支付回调对账。这些事没法通过“描述需求”来解决，因为你根本没法对你不理解的系统做精确描述。这里的瓶颈不在 AI，在于“提问者缺乏对系统本身的建模能力”。

所以我坚定地认为，纯 Prompt 工程师在严肃工程领域是不成立的。它只能存在于玩具级项目里。如果程序员以为自己的护城河是“比产品经理更会提需求”，那才是真的危险。护城河永远是对系统本身的理解深度、对问题本质的判断力、对成败责任的承担能力。

4. 这轮调整期里，程序员怎么把自己摆在对的位置

4.1 最值钱的能力从“敲得多”变成“看得准”

回到最根本的问题：大环境变了，但开发者的核心价值有没有变？

我自己的答案是：没有变，只是被聚焦了。以前因为大家都能写代码，工程质量、代码风格、交付素养的差异被代码量稀释；而 AI 让代码本身的产出不那么稀缺了，于是判断力、取舍力、架构决策能力成了最稀缺的。

怎么理解这个“准”字？举一个具体分工的例子：现在让 AI 出方案并不难，难的是你在几个方案里做选择。比如它给了你两个实现方式：

• 方案 A：改动小，但需要依赖一个不太稳定的第三方库；
• 方案 B：改动大，但后续扩展性更强。

在没有 AI 的年代，写方案本身有成本，大家天然会珍惜；在 AI 时代，方案是白来的，但选择还是你的。你不能说“既然它推荐 A，我就用 A”，也不应该“因为 B 是它编的，我偏不用 B”。你要能解释清楚：这个场景下稳定性优先还是扩展性优先、第三方库在团队内有没有熟悉的人、后续迭代的频次会落在哪块。这事，和写代码无关，和工程素养有关。

4.2 我目前比较顺手的协作模式：帮自己装一个“复核层”

我把自己的开发流程改成“AI 前置、人后置、验证保底”：

• 需求拆解阶段：让 AI 帮我列出“实现这个功能要考虑的边界情况”，目的是提示遗漏，而不是让它直接给方案。
• 编码阶段：核心逻辑我尽量先自己构思一个粗糙框架，再让 AI 填充非关键的实现片段；对于完全没有经验的新技术栈，可以让 AI 生成一个可运行的最小 Demo，然后我拿着 Demo 去查官方文档核对它在关键 API 上的用法。
• 代码评审阶段：我会把 AI 生成的代码，再喂给另一个独立对话，要求它找出潜在问题。相当于让两个模型做交叉验证，虽然它不能替代人工 review，但确实能发现一些我习以为常的盲区。
• 测试阶段：不再把测试当收尾任务，而是用 AI 快速生成网格化的边界测试用例，再自己挑重点补充集成场景。

这个方法的核心是：AI 永远在前台，但你自己必须一直在后台跟着。你可以让它跑，但不能让它带着你跑。跟着跑的过程中，你会发现自己的盲区和薄弱点，这本身就是一种学习。

4.3 领域知识，比任何提示词技巧都保值

我现在对团队里的新人会反复强调一个观点：多花时间理解业务，不是“学点业务好跟产品沟通”，而是“这是你在 AI 时代唯一不可被替代的长期资产”。

为什么？因为 AI 对通用知识、通用代码的掌握，会越来越强；但一个特定行业里的历史包袱、用户习惯、数据规律、合规边界、不同模块之间的潜规则，这些知识在互联网上没有充分并且结构化的公开语料，AI 很难凭空学会。你如果只停留在“代码怎么写”的层面，被替代是必然的；但你如果还在持续积累“我们这个行业、这套系统、这些用户真正需要什么”，那 AI 对你来说，只是让表达和执行层面更顺滑的工具。

讲一个我自己的例子：我们内部有个“积分结算”模块，打折规则和时效规则从早期就比较特殊，踩过不少坑才稳定下来。这些规则的一半，至今没有写进文档。最近一次功能迭代，我让 AI 生成了一版新逻辑，它做得非常工整，但结算顺序错了——它按通用电商逻辑先算券，再算满减；而我们的规则是满减发生后，剩余的优惠券只抵消新增部分。就这一点，只有经历过之前那个“事故修复”的人才可能知道。这个知识，永远在人的脑子里，不在公开资料里。

4.4 心态建设：别急着习惯“被喂答案”

在行业快速变化的阶段，焦虑的核心来源不是学不会，而是对“自己正在失去思考能力”的隐约察觉。我自己也有过那段时间：AI 一报错，我先复制给 AI 看，它说什么改什么，完全不看日志上下文。这样几次之后，再遇到一个 AI 回答不了的模块级问题时，我居然一时不知道该从哪里下手排查。那瞬间我是真有点慌的。

所以现在我在刻意练习一个习惯：AI 给答案之后，我至少花 10 分钟“人工复核它的推理路径”。它说哪里有问题，我就自己去代码里验证一遍；它说用什么 API，我至少要扫一眼官方文档。这个动作很费时间，但它能帮我维持“手感”和对系统的掌控力。就像开车一样，哪怕有自动驾驶，你也得保证自己随时能接管方向盘。

5. 另外几个值得注意的实践细节

5.1 给 AI 提供上下文的方式，决定了它是不是在“装懂”

经常用 AI 做开发的人会发现，同一个问题，你直接问质量和把相关上下文贴全再问，结果天差地别。我自己的做法是：把“相关代码段（尽量精简到 50-100 行）”“当前报错日志”“你希望它关注的具体疑点”三块信息组织好，一次性给出。不要发一句“帮我看看这个报错”就甩一整份日志，那样效果很差。

一个小技巧：当你自己都不知道要检查哪个文件时，先让 AI 根据报错日志帮你列出“可能与这个异常相关的模块清单”，然后你带着这个清单去翻代码，比让它直接改代码要稳妥得多。这能让 AI 当下游的分析助理，而不是替你做决定的上司。

5.2 让 AI “生成测试用例”往往比生成实现本身更有价值

在蜜月期里，大家关注的是让 AI 写功能代码，但我第二年更常用的场景是反过来：让 AI 先看我写好的核心函数，让它站在“恶意用户”和“边界狂魔”的角度列出它认为最容易出错的场景。这个用法相当惊喜——很多时候它列出的场景，恰好是我这周还没想到的。

当然它也会列出一些和我业务语义冲突的无用场景，但哪怕 10 个里有 3 个有价值，也值得了。相当于多了一个免费的结对测试搭档。

5.3 本地小模型 + 托管 API 的分层使用

还有一个实践心得：把简单任务（变量命名、解释一小段代码、生成单元测试骨架）交给本地小模型，响应快、还能断网环境用；把复杂任务（多模块方案设计、跨语言代码迁移、复杂调试）交给更大规模的托管模型。这样不仅省钱，还更高效。很多团队还停留在一股脑全用在线大模型，排队、费用、隐私都是问题。分层的思路，也是一个成熟工程师应该有的架构习惯。

最后，回到标题，说说我自己的答案

我确实担心程序员和 AI 的蜜月期会结束，但我担心的不是“结束”本身，而是很多人在结束之后，会把 AI 当成一个“不太听话的自动生成器”来用——继续复制粘贴，继续不问为什么，继续让代码里的隐患堆成山。

我更愿意把这轮转变看成一次涨潮之后必然的退潮。潮水褪去，那些“只会生成代码但不理解代码”的部分会被留在沙滩上，而真正有深度、有责任、有判断力的工程能力，反而因为对比更显眼了。

所以给你一个最朴素的建议：既然 AI 的蜜月期会结束，那就早点结束对它的“热恋错觉”，把它当成熟练的搭档，付出尊重、校对、测试的时间，让它帮你干活，但方向盘始终放在自己手里。技术永远在前进，而判断力、学习能力和责任感，才是这个行业里一直没变过的核心货币。