企业官网建设流程全解析

最近一段时间，很多团队都在为“AI 编程”带来的效率提升兴奋。确实，一个功能模块交给 AI 编程助手，从生成代码到写出配套单测，可能只需要几分钟。但随之而来一个新问题开始频繁出现在代码评审现场：单测全绿，代码却让人不敢合并。

这不是段子。一位同事用 AI 写了一个订单价格计算模块，单测 18 个用例全部通过，看起来功能完全正常。可在评审时只翻了几分钟就发现，函数直接修改了调用方传入的字典，把原始订单数据悄悄改掉了；折扣规则被硬编码在业务函数里，测试一换数据就“绿”得毫无说服力。更严重的是，一段数据库写入逻辑没有做事务处理，一旦第二笔写入失败，第一笔数据已经落库，造成不可恢复的脏数据。最终得出的结论是：这个模块必须推倒重来。

AI 编程最大的危险，不是它写不出代码，而是它会快速产出一套“测试全绿、核心却烂掉”的代码，让整个团队误以为项目正在健康推进。测试通过这件事，本来应该带来安全感，但在 AI 生成的代码里，它反而经常变成危险的“信任状”。

这篇文章不讨论模型选型，也不聊哪个编程助手更强，而是聚焦一个很多团队正在踩却还没意识到的陷阱：当 AI 生成代码成为常态，测试全绿与代码健康之间的鸿沟会被急剧放大。读完你会理解，为什么功能测试全绿不能代表代码质量；你会学会识别 AI 代码中常见的隐蔽问题；你也会拿到一套包括测试设计、静态检查、代码审查、提示词约束在内的多层防线方案。

1. 这篇文章真正要解决的问题

传统的开发流程里，测试全绿之所以有相当的说服力，是因为代码是程序员一步一步写出来的，测试通过至少说明“实现与预期行为一致”。但在 AI 编程的流程里，这个推理链断了。

AI 生成代码时，模型并不理解你的业务上下文，它是根据训练数据中的统计规律，在预测最可能被接受的代码。它最擅长做的一件事情，就是“让测试通过”。如果测试只覆盖了正常路径，它就会只写出满足正常路径的实现；如果测试断言没有检查副作用，它就不会考虑副作用；如果测试用例没有准备非法输入，它默认就不处理异常。

这意味着，测试全绿可能只说明一件事：AI 生成的代码恰好满足了测试作者的显式断言。代码是否可维护、是否安全、是否优雅、是否考虑了边界条件，这些都不会在测试结果里体现。

这篇文章要解决三个层面的问题：

• 认知层面：理解“测试通过”和“代码健康”之间的本质区别。
• 操作层面：学会设计能逼出真实问题的测试，以及如何通过代码审查和静态检查拦截“测试全绿但实现糟糕”的代码。
• 工程层面：建立一套适合 AI 协作时代的代码质量防线，把 AI 的产出从“能跑”推到“能上线”。

2. 为什么 AI 生成代码能“骗过”测试

2.1 测试的本质是契约，不是质量评估

很多人把单元测试理解成“验证我的代码是否正确”。严格来说，这个理解是有偏差的。单元测试更准确的定位是“契约验证”：它验证的是调用方与被调用方之间约定的行为。

比如有个函数add(a, b)，测试里写了assert add(1, 2) == 3。这个测试证明的只是“当参数是 1 和 2 时，返回值是 3”，它没有证明：

• 参数为负数时行为是否正确；
• 参数类型错误时是否抛出合理异常；
• 函数内部是否有不必要的高复杂度；
• 函数是否修改了传入对象；
• 函数是否依赖了全局状态。

如果 AI 只看到那个assert，它就能用最低成本让测试变绿。这本质上是一种“应试式编程”，就像学生根据历年真题押题，押中了就往答题卡上填答案，但并没有真正掌握这门课。

2.2 测试能发现什么，不能发现什么

这里需要把两类质量概念分开：

这个表格值得在团队里贴出来。它解释了为什么一个有经验的工程师在评审 AI 代码时，会反复追问“这个函数有没有副作用”“这个常量为什么写在这里”“这个异常为什么不处理”。这些追问，恰恰是测试结果无法告诉我们的。

2.3 AI 编程中最常见的三个幻觉

在接触大量使用 AI 编程的团队之后，我发现有几个幻觉非常普遍，而且危害不小。

第一个幻觉：测试覆盖到的代码一定是正确的。实际上，测试覆盖率和代码正确性之间没有必然关系。一个测试用例只是给某一小段行为拍了一张快照，覆盖率再高，也只是一堆快照的集合。AI 可以写出一个分支覆盖率达到 90% 的垃圾实现，每个分支都能通过，但整体设计依旧是一团乱麻。

第二个幻觉：测试通过说明语义正确。这是 AI 编程里最隐蔽的问题。AI 产出的函数可能命名很规范、返回类型也对、测试也通过，但实现的业务语义完全错了。比如把“订单总额”理解成“商品单价×数量”，把“折扣后价格”理解成“折扣金额”，测试都基于错误的语义来写，测试反而锁定了错误行为。

第三个幻觉：重构和完善可以后面再做。很多开发者觉得，先让 AI 把代码跑通，测试全绿，以后再重构。但现实是，一旦测试全绿并合并进主干，后续迭代会在这个错误地基上继续盖楼。AI 编程最大的隐性成本，是把技术债的积累速度从“人写”提升到了“机器批量生产”。

3. 一个订单模块案例：测试全绿，代码翻车

为了更直观地说明问题，我构造一个典型的 AI 编程场景。这个例子综合了很多团队评审 AI 代码时常见的问题。

3.1 需求描述

需求很简单：给订单系统增加一个折扣功能。规则如下：

• 订单总额大于 1000 元，打 8 折；
• 订单总额大于 500 元，打 85 折；
• 订单总额大于 100 元，打 9 折；
• 其他情况原价。

同时，系统需要一个函数apply_discount(order)，接收订单字典，返回折扣后的金额，并让调用方能够拿到最终金额。

3.2 单元测试：看起来无懈可击

测试代码先被写出来，覆盖了四条规则，并且额外加上了一个空订单的异常场景。

# 文件路径：tests/test_discount.py import unittest from discount import apply_discount class TestDiscount(unittest.TestCase): def test_order_above_1000(self): order = {"id": 1, "total": 2000} self.assertEqual(apply_discount(order), 1600) def test_order_between_500_and_1000(self): order = {"id": 2, "total": 800} self.assertEqual(apply_discount(order), 680) def test_order_between_100_and_500(self): order = {"id": 3, "total": 300} self.assertEqual(apply_discount(order), 270) def test_order_below_100(self): order = {"id": 4, "total": 50} self.assertEqual(apply_discount(order), 50) if __name__ == "__main__": unittest.main()

这组用例覆盖了四条业务规则。运行之后，四个测试全部通过。从结果看，这是个“质量不错”的模块。

3.3 AI 生成的实现：测试全绿的“陷阱代码”

以下是 AI 生成的实现：

# 文件路径：discount.py def apply_discount(order): """计算订单折扣后的金额""" if order["total"] > 1000: order["total"] = order["total"] * 0.8 elif order["total"] > 500: order["total"] = order["total"] * 0.85 elif order["total"] > 100: order["total"] = order["total"] * 0.9 return order["total"]

运行测试，输出结果：

.... ---------------------------------------------------------------------- Ran 4 tests in 0.002s OK

测试全绿。但这份代码只要进入生产环境，就是隐患。

3.4 问题逐条分析

最讽刺的是，测试全绿给这个模块判了“健康”，但真实项目里，这类代码往往在集成阶段暴露问题，而且问题定位成本很高：调用方先要怀疑自己的逻辑，查日志，最后才发现是折扣模块把入参改了。这个排查过程，在 AI 编程时代被成倍地放大。

4. AI 代码“全绿陷阱”的四个典型表现

从上面的案例延伸开，我发现 AI 生成的代码在“测试全绿”的表象下，经常表现出四类典型问题。这几类问题几乎贯穿了 AI 辅助开发的各个环节。

4.1 应试式满足断言

AI 会非常“贴心”地只实现测试需要的逻辑。如果测试只检查返回结果，它就只用最直接的代码让结果正确；如果测试没有检查输入校验，它就不写校验；如果测试没有检查异常路径，它就不写异常处理。

这种代码的特征是：实现路径极其朴素，甚至可以用“简陋”来形容。它会跳过防御性处理、跳过参数校验、跳过边界条件。因为对 AI 来说，每一个多余的if都有可能引入 bug，不如老老实实只满足断言，这样测试全绿的几率最高。

4.2 副作用入侵调用方

前面订单案例已经展示了这类问题的典型形态。AI 生成代码时，经常倾向于“就地修改”而不是“返回新值”，因为就地修改的代码通常看起来更短，也更容易通过测试。但它对调用方的影响，是测试断言覆盖不到的。

这类问题在 Python 的dict、list、对象传参，以及 Java 的Map、List、对象引用中尤其隐蔽。如果测试只校验返回值，不校验传入对象是否被修改，那么副作用会一直潜伏到模块合并之后，直到某个下游模块被坑了才发现。

4.3 空洞代码制造绿灯

另一种“全绿陷阱”是：测试确实覆盖了某个行为，但实现并没有真正完成该行为。一个典型的例子是“注册用户”功能，测试用 mock 把数据库操作全部挡在断言之外，结果 AI 生成的实现里连参数化查询都没有，直接用 SQL 拼接。

这类代码的特征是，单测跑得很欢，但拿到真实环境就崩。原因是测试与实现之间的耦合停留在“表面行为”，没有触及“真实行为”。所谓“真实行为”，应该是：用户数据持久化、异常情况回滚、密码安全存储、重复注册拦截、参数合法性校验。这些行为没有进入测试断言，AI 自然没有动力去实现。

比如下面的 AI 生成代码，单测能过，但生产环境风险极高：

# 文件路径：user_service.py import sqlite3 def register_user(username, password, email): conn = sqlite3.connect("app.db") cur = conn.cursor() # 危险：SQL 拼接，未做参数化；密码也是明文存储 cur.execute( f"INSERT INTO users (username, password, email) " f"VALUES ('{username}', '{password}', '{email}')" ) conn.commit() conn.close() return True

如果测试执行时用的是 mock 数据库，那么单测结果全绿，但代码注入风险、密码明文风险、连接未关闭风险全都不会暴露。解决这类问题的核心思路，不是让 AI 写更多代码，而是让测试真正打到“行为契约”而不是“表面断言”。

4.4 复杂度被测试掩盖

AI 还有一个特点：它很擅长写出“能跑但难维护”的嵌套结构。比如一个函数里塞了五层 if-else，或者一个方法既做数据校验又做业务计算还做持久化。这样的代码单测全绿，但后续维护的人看到它时会产生极大的心理负担。

这种复杂度在测试阶段是隐藏的，因为单元测试只关心输入输出，不关心圈复杂度、函数长度、职责单一与否。只有把代码放进 Code Review，放进静态分析工具，复杂度才会暴露出来。

5. 建立“防烂代码”的多层防线

既然不能指望 AI 自己写出“测试全绿且设计优秀”的代码，团队的工程防线就显得至关重要。这里给出四层防线，每一层解决一类问题。

5.1 第一层：把测试定义得更接近“契约”

既然 AI 是“应试型选手”，那我们就该把考卷出得更有区分度。在设计测试时，至少要做到以下几点：

• 检查副作用：测试返回结果之后，需要额外断言入参对象没有被意外修改。
• 覆盖边界值：所有>和>=边界的临界值都要覆盖。
• 覆盖异常路径：非法输入、空值、超长字符串、依赖服务失败等场景都要有测试。
• 检查返回值语义：不仅要断言返回值，还要断言返回对象的属性和类型。

下面是为订单模块补充的“契约测试”：

# 文件路径：tests/test_discount_contract.py import unittest from discount import apply_discount class TestDiscountContract(unittest.TestCase): def test_it_should_not_modify_input_order(self): order = {"id": 1, "total": 2000} apply_discount(order) # 关键断言：输入数据不应被修改 self.assertEqual(order["total"], 2000) def test_order_exactly_1000_should_discount(self): order = {"id": 2, "total": 1000} self.assertEqual(apply_discount(order), 800) def test_order_exactly_500_should_discount(self): order = {"id": 3, "total": 500} self.assertEqual(apply_discount(order), 425) def test_order_exactly_100_should_discount(self): order = {"id": 4, "total": 100} self.assertEqual(apply_discount(order), 90) def test_invalid_order_should_raise(self): with self.assertRaises(KeyError): apply_discount({"id": 5}) # 缺失 total 字段

当测试里加入了“不能修改入参”的断言时，原先的 AI 实现立刻会失败。这就是“契约测试”的价值：它逼着实现者重新设计方案，而不是用副作用来走后门。

5.2 第二层：静态分析和质量门禁

静态分析工具可以发现那些测试看不到的问题。比如 Python 的ruff、Java 的Checkstyle/PMD、JavaScript 的ESLint。这些工具不需要运行代码，就能发现未使用变量、过于复杂的函数、不安全的 SQL 拼接线索等。

一个干净的pyproject.toml配置示例：

# 文件路径：pyproject.toml [tool.ruff] line-length = 100 target-version = "py311" [tool.ruff.lint] select = ["E", "F", "W", "B", "C4", "SIM"] ignore = [] [tool.ruff.lint.per-file-ignores] "tests/*" = ["S101"]

配合 CI 使用：

# .github/workflows/quality.yml 中的关键步骤 ruff check src tests ruff format --check . pytest --cov=src --cov-fail-under=80 tests/

这里把覆盖率门槛设在 80%，只是一个示例。更重要的是把静态检查结果作为合并的前置条件：如果代码没有通过质量门禁，就不能合并到主干。这在 AI 编程时代尤其有意义，因为 AI 产生的潜在问题数量，已经超出了人工评审能逐一覆盖的极限。

5.3 第三层：进 Git 前的人工自检清单

在代码合并前，每个开发者都该形成一份快速自检清单。我自己在实际评审中经常用以下几个问题来问 AI 产出代码：

• 这段代码有没有修改传入参数或全局状态？
• 异常分支是否有明确处理策略？
• 有没有把不该写死在业务函数里的规则硬编码？
• 如果切换到真实数据库 / 真实网络，这段代码还能跑通吗？
• 命名是否准确表达业务语义？
• 有没有过度设计？

这些问题表面上很基础，但如果是人工一行行写出代码，大多数时候不会犯前面那种“直接改入参”的错误。可当代码由 AI 快速产出后，程序员往往只关注“功能是否实现”，自检意识会被极大地削弱。

5.4 第四层：用提示词约束 AI 的生成行为

最后一种防线是从源头控制：不让 AI 自由发挥，而是用提示词把工程约束写进去。这一点在下一章节展开。

6. 用高质量提示词让 AI 交出更靠谱的代码

提示词质量基本决定了 AI 生成代码的天花板。很多人觉得提示词就是“用大白话描述需求”，这没错，但要写出工程上可用的代码，提示词需要包含约束和上下文。

6.1 一个低质量的提示词

看这个提示词：

写一个计算订单折扣的函数，总价大于1000打8折，大于500打85折，大于100打9折。

这个提示词缺乏几乎所有的工程上下文。AI 大概率会生成出前面那种“直接修改入参”的代码。它没有被告知不能修改入参，没有被告知折扣规则要可配置，没有被告知需要类型注解，也没有被告知要覆盖边界测试。

6.2 一个高质量的提示词模板

一个高质量的提示词，至少要包含“角色、约束、输入输出约定、测试要求、边界条件”五个部分。

你是熟悉 Python 的资深后端工程师，请帮我实现订单折扣模块。 需求： 1. 订单总金额 total > 1000 时，折扣率 0.8； 2. total > 500 时，折扣率 0.85； 3. total > 100 时，折扣率 0.9； 4. 其他情况折扣率 1.0。 约束： 1. 不允许修改调用方传入的字典或对象，计算结果请用新的数据结构返回； 2. 折扣规则抽成独立函数，方便以后配置化； 3. 所有函数必须有类型注解和 docstring； 4. 需要包含返回结构的设计说明。 输出要求： 1. 先给出函数签名和设计说明，再给出实现； 2. 写出单元测试，覆盖 100、500、1000 的边界情况； 3. 测试中必须断言输入对象未被修改。 请按以上要求输出完整代码。

在约束中加入“不允许修改入参”“覆盖边界测试”“先设计说明再给实现”这些条件后，AI 生成代码的方式会完全不同。它不再只是一个计算函数，而是一个有返回结构、有独立规则函数、有边界测试的模块。

6.3 分步生成比一步到位更可靠

还有一个值得养成的习惯：分步让 AI 工作，而不是一次性交付全部功能。

合理的节奏是：

1. 先让 AI 给出模块设计和函数签名。
2. 审查设计，确认没有副作用和职责混乱。
3. 再让 AI 按设计生成实现。
4. 最后让 AI 生成测试并执行测试。

这种“分步生成 + 中间审查”的方式，比直接让 AI 输出完整项目更可控。因为每一步的产物都较小，人类审查的负担也较低，问题可以在早期被发现。

7. 常见问题与排查方法

在 AI 编程的实际使用中，团队碰到的问题往往有规律可循。下面整理一份高频问题排查表，既可以用于日常自查，也可以作为新成员上手的快速参考。

这张表并不完整，但它提供了一个思路：遇到 AI 编程相关问题，先从“测试是否覆盖了真实契约”入手，而不是急着修业务逻辑。

8. 工程实践建议

8.1 团队协作三原则

原则一：测试全绿只是起点，不是终点。

团队要把“测试全绿”当成一次性质量检查通过，而不是最终结论。合并一个 PR 之前，除了测试，至少还要有静态检查、代码评审、自测记录这几个步骤。

原则二：AI 生成代码比手写代码更需要评审。

有些团队会觉得，AI 生成的代码反正通过了测试，评审可以放松一点。这种想法非常危险。正因为 AI 不了解业务上下文，它的代码在隐含假设上出错的概率反而更高。人类评审在 AI 编程时代的价值，并不仅仅是“看格式”，而是验证“这段代码是否真的在实现业务目标”。

原则三：把质量约束写进流程，而不是靠个人自觉。

如果团队依赖每个人自觉检查副作用，那注定会漏。更好的方式是把 check 项做成自动化工具，比如 PR 模板里强制要求填写“副作用自检”“依赖变更说明”“测试边界覆盖”等字段。

8.2 为 AI 代码建立专门的评审环节

代码评审已经够累了，为什么还要给 AI 代码单独设一个环节？

因为普通代码评审是“读代码找 bug”，而 AI 代码评审首先要做的是“判断这段代码是否真的是这个项目的正确解法”。两者侧重点不同，放在一起容易混乱。

比较实用的做法是：

• 让 AI 生成的代码先经过一次“设计评审”，确认模块划分、数据流、接口设计合理；
• 然后进入常规代码评审，检查语法、风格、测试、边界；
• 如果条件允许，在合并前跑一次静态分析和安全扫描。

8.3 持续收集“反模式”并沉淀进团队知识库

每个团队都会碰到自己的 AI 编程反模式。比如“AI 生成了一个函数，但修改了全局配置”“AI 把测试写成了一堆空断言”等等。这些反模式第一次遇到时，可能花几个小时才能定位。建议团队建立一个“AI 代码反模式清单”，每次评审发现问题就追加一条，并配上简短的示例和解决方案。

长期来看，这个知识库的价值会超过任何单一工具。因为它是团队专属的，沉淀了对业务和工程环境的理解，AI 模型不一定知道。

9. 总结与下一步

AI 编程给开发效率带来的提升是真实的，但“测试全绿、代码烂掉”的风险也是真实的。问题的根源，不是 AI 不够聪明，而是测试的本质决定了它无法证明代码健康。当生成代码的主体从“人”变成“模型”之后，这个缝隙被急剧放大，团队必须用更严格的测试、更清晰的提示词、更可靠的质量门禁来重新缝合它。

对开发者个人来说，下次让 AI 写完代码并看到测试全绿之后，不妨再多问自己几个问题：这段代码有没有修改调用方的状态？边界条件覆盖了吗？异常路径处理了吗？如果答案里有“不确定”，那么恭喜你，你已经比只会看测试结果的人多走了一步。

对团队来说，把“测试全绿”从终点改回起点，是 AI 编程时代质量建设的第一件事。如果下周只做一件事，可以挑一个 AI 生成的模块，用本文第 5 章的四层防线做一次质量评审。把“测试全绿但代码烂”的问题在合并前拉出来，比任何制度宣贯都管用。