企业官网建设流程全解析

最近和几位做后端开发的同事聊技术方案评审，大家不约而同提到一个现象：PR 描述越来越工整，设计文档越来越通顺，代码注释也越来越完整，可真在评审会上追问两句，对方常常会愣一下，然后补一句“这段是 AI 生成的，我再核一下”。

不是不能理解——大模型普及之后，写周报、写方案、写代码片段，大家确实比以前轻松不少。但如果你也遇到过“AI 写的方案看起来很合理、实际落地全踩坑”的情况，那这篇文章值得往下看。

我想聊的是这句话：You Should Almost Never Use AI to Write Anything Substantive——“实质性内容，几乎不应该交给 AI 来写”。

这里的“实质性内容”，指的是那些需要承担责任、依赖上下文、有硬性正确性标准的产出物。比如技术选型方案、数据库变更脚本、生产环境配置、事故复盘、对外说明文档。它们和“写一封周报”有本质区别。

文章会拆解这句话背后的原因，结合代码和文档案例，讲清楚 AI 在哪些场景会翻车、哪些场景可以放心用，以及一个“AI 辅助而非 AI 代写”的工程化工作流。如果你正打算让 AI 帮你写方案、生成代码甚至做 Code Review，建议认真看完。

1. AI 写作热潮下的冷静思考

1.1 为什么这句话值得重视

从 2023 年开始，大语言模型几乎重塑了开发者的写作习惯。以前写设计文档需要先列大纲、收集资料、逐段推演，现在打开 ChatGPT 或者 IDE 插件，敲几句描述，就能得到一份看起来相当完整的文档。

但也正因为“看起来完整”，人们容易忽略一个关键事实：AI 生成内容时，它并不知道你的业务背景、历史包袱和可接受的失败代价。它给出的是一段基于概率预测的文本，而不是经过验证的工程结论。

“实质性内容”有一个共同特点：错误会被传导、放大、甚至固化。一份方案里的错误技术选型，可能让团队走一个月的弯路；一段缺失边界条件的代码，可能在生产环境线上执行时把数据改坏；一篇事故复盘如果被 AI“润色”得过于流畅，反而容易丢失真实原因。这些都不是“再改改就行”的小问题。

1.2 什么是“实质性内容”

我给“实质性内容”下了三个判断标准，满足任意两条，就属于这一类：

• 会对人的决策产生影响：比如技术选型、架构方案、排期计划，看的人会据此做决定。
• 有不可逆或高成本的失败模式：比如删库、改配置、发布版本，错了很难回滚。
• 需要署名和承担责任：文档上是你的名字，代码是你提交的，出问题追责到的是人。

对照这个标准，你会发现很多日常写作其实不属于实质性内容：

• 生成一个正则表达式提取手机号，属于工具性验证，风险可控。
• 把会议语音转成纪要初稿，是有价值的草稿，但需要人来确认。
• 用 AI 按模板生成一份权限申请单，模板本身是固定的，风险有限。

而下面这些内容，要格外谨慎：

• 技术选型对比方案
• 数据库变更 SQL 或数据迁移脚本
• 生产环境部署与安全配置
• 线上故障复盘报告
• 面向客户或监管的说明文档

1.3 从 AI 的能力边界看问题所在

大模型本质上是“根据前文预测下一个词”的引擎。它在训练时看过海量文本，学会的是语言分布的统计规律，而不是对事实的准确记忆。因此，它能写出语法流畅、结构合理的文本，但不保证内容真实、参数正确、方案可行。

这就是业内常说的AI 幻觉：模型会生成一段“读起来合理、细究却是错的”内容，并且语气非常笃定。当你让 AI 写周报时，幻觉的代价很低；当你让 AI 写生产变更脚本时，幻觉可能等于事故。

所以，问题的核心不是“AI 写得不够好”，而是AI 产出的确定性投入到了低确定性场景，而人又没有做好兜底验证。

2. 为什么实质性内容不能交给 AI 代写

2.1 正确性幻觉：读起来对，用起来错

这是最典型的问题。让 AI 推荐一个第三方库的版本号，它可能给你一个不存在的版本；让 AI 解释某个框架的配置项，它可能把新旧版本混在一起；让 AI 写一段“简单”的 SQL，它可能忘了 WHERE 条件。

之前有个项目组让我帮忙看一份 AI 生成的技术方案，里面写：“MySQL 8.0 已默认开启强制 SSL，连接阶段无需额外配置。”实际上，MySQL 8.0 是否默认开启 SSL、证书如何配置，和编译安装方式、发行版都有关系，不能一概而论。评审会上，这个结论被 DBA 直接否定。

换成代码也一样。AI 生成的代码往往能通过“语法层面”的审视，但一到边界条件、并发安全、错误恢复，就容易出现问题。原因很简单：AI 没有观察到你的运行环境，它只是在生成“看起来像答案”的文本。

2.2 上下文缺失：AI 给的是一般性答案，不是你的答案

每个项目都有自己的约束条件：

• 已有的数据库表结构是什么？
• 当前系统的 QPS 和延迟目标是多少？
• 公司内部的认证中心、配置中心地址是什么？
• 代码库里是否已经存在同名的类或工具方法？

这些信息在 AI 的上下文窗口里并不存在。除非你明确写清楚，否则它只能基于“一般情况”作答。

一般性答案在初级学习中很有用，但在工程实践中往往不够。比如 AI 可能建议你用 Redis 缓存用户信息，但不知道你们的业务已经用分布式缓存中间件，或者某些数据要求强一致不能走缓存。这种“通用方案”用在具体项目里，轻则不兼容，重则引入新的隐患。

2.3 一致性流失：长文档和大型代码库中的“各自为政”

如果你让 AI 一次性生成一篇 5000 字的技术方案，前半段它可能写“方案 A”，中段变成“方案 B”，结尾又回到“方案 A”。这是因为模型每次生成都在做独立预测，没有在全局维护一个一致的决策状态。

代码库里更容易出现这种情况。AI 在文件 A 中定义了一个新的接口，在文件 B 中按旧接口调用，编译期才能发现问题。如果多个开发者都依赖 AI 生成代码，这种不一致会成倍增加。

更隐蔽的是术语不一致。一篇文档里，前面叫“订单服务”，中间叫“交易系统”，后面又叫“支付中心”，读者很难快速建立准确认知。人工统稿可以纠正这种漂移，但如果直接把 AI 输出当终稿，问题就会被带进评审环节。

2.4 责任归属模糊：文档署名的是人，不是 AI

团队协作中，文档和代码是有责任主体的。方案上写的是你的名字，代码提交记录里是你，生产事故复盘会上被问“当时为什么这么设计”的也是你。

AI 无法站在答辩席上解释“我当时是这么想的”。一旦内容出了问题，责任的归属依然落在真实的人身上。AI 只负责生成文本，不负责后果。

这件事在团队里会带来一个隐性风险：当大家习惯了“AI 写的方案”，负责评审的人会逐渐降低自己的判断投入，因为“AI 写的看起来很有道理”。结果就是：AI 生成得越流畅，人工审查越放松，风险反而越大。

2.5 能力退化与隐性成本

长期让 AI 代写实质性内容，开发者自己会对“如何构建一个论证、如何设计一个方案、如何排查一个边界条件”越来越陌生。写作本身就是思考的过程，如果连草稿都不愿意自己搭，思考能力一定会慢慢钝化。

从成本角度看，AI 写作并不是零成本。调用 API 有 token 消耗（也就是常说的 credits 消耗），免费额度有上限，超过后按量计费。更重要的是返工成本：AI 生成的内容如果问题较多，人工修改的时间可能比自己直接写还长。这种“看起来提效、实际更慢”的现象，在复杂方案和核心代码场景里非常常见。

3. AI 写作的能力边界：可以做什么，不可以做什么

3.1 AI 真正擅长的事情

要合理使用 AI，先得明确它的能力边界。从工程经验看，下面这些场景 AI 表现稳定：

• 格式转换与重排：把一段文字改成 Markdown 表格、把会议记录改成待办列表。
• 模板类内容：生成符合固定格式的接口文档、周报、会议纪要。
• 标准化代码片段：正则表达式、时间格式化、JSON 解析、常见算法实现。
• 相似案例参考：输入一个问题，让它列出几种常见处理思路供你挑选。
• 文本润色：在保持原意的前提下改善表达。
• 草稿大纲：为文章、方案提供结构建议。

这些任务的共同点是：结果可以快速验证，错误代价低，格式化程度高。

3.2 AI 不擅长的事情

与之相对，下面这些场景要谨慎：

• 业务决策：A 方案还是 B 方案，取决于团队情况、成本预算和长期规划，AI 不了解。
• 安全与合规判断：数据合规、权限边界、审计要求，专业性极强且时效性敏感。
• 高精度事实引用：版本号、参数上限、官方文档细节，需要以权威来源为准。
• 长链路逻辑推演：一个方案在多模块、多团队间的连锁影响，AI 容易漏掉环节。
• 创造性方案设计：真正从零到一的结构创新，AI 更擅长组合已有模式，而不是突破边界。

3.3 一个简单的分类判断

判断一份内容能否交给 AI 主笔，可以问自己四个问题：

1. 结果能被快速验证吗？验证成本越低，越能更多依赖 AI。
2. 失败代价可逆吗？如果错了能回滚、能重建，风险较小；否则需人工把关。
3. 内容依赖内部上下文吗？越依赖业务背景，越需要人来补上下文。
4. 内容需要签字负责吗？需要署名的内容，作者必须对每个结论负责。

4. 实战复盘：三个 AI 生成的典型翻车案例

4.1 案例一：批量重命名脚本缺少边界处理

先看一个很常见的需求：把当前目录下所有 PDF 文件名中的2023替换成2024。有人让 AI 直接生成脚本，得到这样一个版本：

import os for filename in os.listdir("."): if filename.endswith(".pdf"): new_name = filename.replace("2023", "2024") os.rename(filename, new_name)

这个脚本放在一个干净目录里，能跑通。但放到真实项目目录里，问题立刻暴露：

• replace会把文件名里所有2023都替换掉，如果文件名里出现两个年份编号，会被同时改掉。
• 如果目标文件已经存在，os.rename在 Windows 上会报错，在 Linux 上会覆盖文件。
• 如果当前目录下没有.pdf文件，脚本没有任何提示，看起来“什么都没发生”。
• 没有日志输出，重命名失败时难以排查。

改成一个更工程化的版本：

import logging from pathlib import Path logging.basicConfig(level=logging.INFO, format="%(levelname)s: %(message)s") source_dir = Path(".") target_dir = Path(".") for path in source_dir.glob("*.pdf"): if "2023" not in path.name: continue new_name = path.name.replace("2023", "2024") target = target_dir / new_name if target.exists(): logging.warning("目标文件已存在，跳过: %s", target) continue try: path.rename(target) logging.info("重命名: %s -> %s", path.name, new_name) except OSError as exc: logging.error("重命名失败: %s, 原因: %s", path.name, exc)

AI 的“快”和“省事”，一旦到了真实文件系统上，就需要人补上大量的异常分支。这恰好说明：AI 生成的是“能用”的表层代码，而工程代码需要的是“可用、可维护、可排查”的深层代码。

4.2 案例二：技术方案文档中的事实错误

再看一份 AI 生成的《订单数据迁移方案》片段：

# 订单数据迁移方案 - 使用 Redis 作为主存储，替代 MySQL，保证查询速度。 - 数据过期时间设置为 30 天，减少存储压力。 - 迁移期间可停服 5 分钟，无需双写方案。

这段方案看起来结构清晰，但评审时问题很大：

• 订单数据是核心交易数据，需要持久化和一致性，Redis 默认不是持久化主存储。
• 设置 30 天过期，意味着历史订单 30 天后不可查，这在业务上通常是不可接受的。
• 停服 5 分钟迁移，没有双写或回滚方案，一旦迁移失败，影响范围无法控制。

AI 把“缓存场景”的思路直接套到了“存储场景”上，导致方案完全不可用。这个案例里，问题不是 AI 不知道 Redis，而是它不知道这是一家电商系统的订单数据、不知道审计要求、不知道可用性目标。

这也是“实质性内容”和“简单内容”最大的区别：简单内容错了可以重来，实质性内容错了可能要背事故。

4.3 案例三：AI Code Review 建议把正确的代码改错

现在的 IDE 插件都能做代码审查，但 AI Review 建议同样需要人工判断。比如下面这段代码：

public synchronized void updateStock(Integer productId, Integer delta) { int current = stockRepository.get(productId); stockRepository.update(productId, current + delta); }

AI 给出建议：

同步方法会影响并发性能，建议去掉 synchronized，改用 ConcurrentHashMap 做库存存储。

问题在于：库存扣减的“检查当前值—计算新值—写回”是一个复合操作，必须保证原子性。去掉 synchronized 后，两个线程同时扣减时会丢更新。除非引入数据库乐观锁或分布式锁，否则这个建议就是错误的。

所以，AI 生成的 Code Review 意见只能作为“候选人”，不能直接作为“结论”。它的意见在泛化场景里可能正确，但在具体业务语义下可能非常危险。

5. AI 辅助的正确姿势：如何让 AI 成为好助手

5.1 用 AI 起草，不要用 AI 定稿

把任务定义从“请帮我写一份完整的方案”改成“请帮我起草一份初稿，我需要在此基础上修改”。这个措辞上的变化，会影响你对 AI 输出的心理预期：不再期待它直接可用，而是把它当作素材。

拿到初稿后，先通读一遍，画出你认为有问题的地方，再针对性地修改。对最终版本，建议把 AI 生成的句子用自己的语言重写一遍，尤其是结论、推荐方案、数字和参数。这一步能有效避免“AI 腔”和事实错误。

5.2 用 AI 做“陪练”，而不是“代写”

更安全的用法，是让 AI 帮你思考盲点，而不是替你写结论。

比如你正在设计一个缓存方案，可以问 AI：

• “这套缓存方案在哪些场景下会失效？”
• “缓存与数据库一致性通常有哪些方案，各有什么代价？”
• “如果 Redis 集群不可用，系统应该怎么降级？”

让 AI 列出问题清单，然后你来判断、回答、取舍。这相当于一个廉价的“思维碰撞”工具，既能拓宽思路，又能把最终判断权留在自己手里。

5.3 提供足够上下文，并明确约束条件

给 AI 的 Prompt 中，应尽可能包含项目背景、目标读者、格式要求、已知约束。下面是一个示例：

请帮我起草一份《订单缓存方案》初稿。 背景：订单数据保存在 MySQL，读多写少，希望引入 Redis 缓存缓解数据库压力。 约束： 1. 缓存不能作为唯一数据源，MySQL 是最终一致性保障。 2. 必须考虑缓存穿透、击穿、雪崩的应对方案。 3. 技术栈为 Java Spring Boot，使用 Spring Cache 或 Redisson。 4. 请先给出大纲，不要直接写结论。 目标读者：后端开发工程师和 DBA，需要评审技术选型。

上下文越充分，AI 输出的偏离程度越低。但仍然要记住：它给你的只是“根据上下文生成的假设”，不是“经过验证的结论”。

5.4 要求 AI 标注不确定性

在 Prompt 中明确要求：

• “对不确定的版本号，请写‘需要核实’。”
• “如果信息可能随版本变化，请注明‘以官方文档为准’。”
• “如果某个方案有前提条件，请单独列出。”

这会强迫 AI 减少“自信的胡说”，也能给你后续排查提供线索。

5.5 警惕 AI Agent 自动执行链路

如果你使用的工具不只是“生成文本”，而是以 AI Agent 方式自动执行命令、修改文件、调用外部接口，风险等级会显著上升。Agent 的每步操作都可能有累积误差，一旦在中间步骤选错了参数，后果会被自动执行放大。

建议在实验阶段做好三件事：限制权限范围、增加人工审批节点、对所有 AI 执行操作保留日志。不要一开始就让 Agent 直接操作生产环境。

6. 建立一套 AI 辅助工作流

6.1 团队层面先定规矩

如果团队希望把 AI 纳入日常写作和开发，先定几条必须遵守的原则：

• AI 生成的内容不等于最终内容，必须经过同等严格的人工评审。
• 文档、方案的署名人在提交前要对全部内容负责。
• 涉及生产变更、数据库操作、安全配置的内容，不允许 AI 直接执行。
• 根据风险等级划分“AI 可直接输出”和“AI 仅可辅助”两类场景。

这些规矩听起来有点“保守”，但能避免 AI 的便利性掩盖工程风险。

6.2 写前：先定结构，再让 AI 填充

在让 AI 写正文之前，先自己列一个提纲：

1. 文档要解决什么问题？
2. 读者是谁，需要做什么决定？
3. 有哪些已知约束和边界条件？
4. 最终怎么验收？

把提纲发给 AI，让它按照提纲分块展开。这样能避免它“另起炉灶”，也便于你逐块核对。

6.3 写中：分块生成，逐步交叉验证

不要让 AI 一次生成 5000 字。更安全的做法是把内容拆成几个独立小节，逐个生成、逐个验证。比如技术方案可以拆成“现状描述”“方案对比”“推荐方案”“风险清单”“实施步骤”。

每生成一块，就问自己：

• 这里的数据和参数是从哪里来的？
• 这个结论是否和上一块冲突？
• 如果按这个方案执行，最坏结果是什么？

6.4 写后：事实核查清单

内容完成后，用下面这张表做一次“AI 产物审查”：

6.5 在评审会里加一道“AI 检查”

如果团队评审中经常出现“AI 生成的内容”，可以增加一个环节：随机挑出几处关键结论，问提交者“这句话是你验证过的，还是 AI 生成的？验证过程是什么？”

这不是为了追责，而是为了训练团队习惯：把 AI 内容当作需要审查的对象，而不是默认可信的答案。

7. FAQ：关于 AI 写作的常见问题

一个经常被问到的问题是：“Almost Never 是不是太绝对了？”其实almost这个词很关键。以下场景可以更放心地使用 AI：

• 正则表达式、JSON 提取、格式转换。
• 临时脚本，运行一次即废弃。
• 测试数据生成，生成后能检查。
• 文本润色和翻译，原意由人把控。
• 备选方案收集，最终决策由人完成。

这些内容的共同点是：结果可验证、失败可回滚、不涉及责任认定。

8. 把“作者”的位置留给自己

AI 是一个称职的助手，前提是你没有让它坐上“作者”的位置。实质性内容的背后，是对事实的核对、对上下文的判断、对风险的承担，这些都是 AI 无法替代的。

如果你正准备把一个设计文档直接交给 AI 来写，可以先停一下，把任务描述改成“让 AI 帮我准备第一稿”。当你把自己放在“作者”的位置上，AI 生成的内容就只是素材，真正对结果负责的人，仍然是你。

回到开头那句话：You Should Almost Never Use AI to Write Anything Substantive。这不是要否认 AI 的价值，而是提醒我们，越重要的内容，越需要人亲自动手、亲自验证、亲自负责。以后每次按下“生成”按钮之后，不妨多问一句：

“这段内容如果错了，后果是什么？”

如果答案让你有些不安，那就别让它直接成为最终输出。把它当作草稿，用心改写一遍，你会有更踏实的交付，也会成长得更快。