AI编码助手提速背后：代码正确性验证的工程实践

在编辑器里调出 Sonnet 5.5，提示词还没敲完一行，从数据库查询到 DTO 转换再到 controller 层的完整代码块已经躺在屏幕上了。速度确实快，快到有欺骗性。我盯着这段代码看了几秒，脑子里冒出来的问题不是“它怎么写这么快”，而是“它怎么知道这是对的”。

这个问题其实才是关键。程序员的产出从来不是代码本身，而是“能在真实环境里正确运行的代码”。生成速度只是前半场，验证正确性才是后半场，而后半场恰恰最难自动化，也最容易被忽略。今天这篇想聊的就是这个：当 AI 编码助手把写代码这件事从“小时级”压到“分钟级”，我们拿什么去确认它没写错，以及“确认”这件事本身能不能也跟上提速的节奏。

这篇文章不是某个工具的评测，也不是教你如何写提示词。我会把它当成一个真实的工程问题来拆：验证的层次、验证的流程、常见翻车点，以及实际用下来比较管用的排查技巧。适合正在把 AI 编码助手当主力生产力的人，也适合做代码评审和测试的同学——毕竟工具提速以后，压力会直接转移到你们身上。

1. AI 提速与正确性之间的断层

1.1 快的是生成，不是交付

先说一个容易被速度冲昏头的误区。Sonnet 5.5 这类模型带来的提升，严格来说是“候选代码的生成速度”，而不是“项目的交付速度”。交付速度是什么？是从需求确认到代码上线这一整条链路的时间。链路里除了生成代码，还包括理解需求、验证行为、修复问题、评审、部署、回归。

我自己的实际体验很典型。让 Sonnet 5.5 写一个订单导出的接口，补全带优化，从生成到落盘可能只需要三分钟。但接下来发生的事才是常态：跑单元测试发现日期格式化没考虑时区；联调时发现它用的分页参数和项目现有规范不一致；评审时发现异常处理只 catch 了顶层 Exception，具体错误信息全被吞掉了。这一轮下来，一个半小时没了。生成快了二十五倍，交付并没有快二十五倍，因为正确性验证的环节被原封不动地保留了下来。

这就是断层所在。生成环节的边际成本被大模型压到了几乎为零，验证环节的成本却几乎没有变化。如果一个团队把“生成变快”直接等同于“效率变高”，就会在项目里埋下大量“看起来能跑，仔细看全错”的代码。

1.2 “写对了”到底由谁来定义

想解决验证问题，先得把“写对了”拆清楚。做开发这么多年，我认为“写对了”至少要分三个层次，每一层的判断标准和负责人都完全不同。

第一个层次是“语法与运行对”。代码能编译通过，进程能启动，接口能返回结果。负责这个层次的确认者是编译器、解释器和运行时的报错信息，这是机器天然就能告诉你的事情。

第二个层次是“行为与需求对”。代码实现了产品需求里描述的功能，边界情况处理合理，异常路径没有致命隐患。负责这个层次的是测试用例，尤其是从需求推导出来的用例，而不是从实现反推出来的用例。

第三个层次是“工程与长期对”。代码符合团队的编码规范，依赖选择合理，性能可接受，安全上没有明显的口子，后续维护的人能看懂。负责这个层次的确认者是代码评审人，以及运行一段时间后的线上监控和告警。

这三个层次对应三种不同的“确认者”，不能混为一谈。经常出现的问题是，有人看到语法对、测试过，就认为需求一定对；有人看到评审意见，就认为行为一定没问题。实际上，每个层次都会漏，真正可靠的确认体系必须把三层都覆盖到。

2. 确认正确性的整个链条

2.1 机器先兜底：编译、类型与静态分析

每次让 AI 生成完一段代码，我做的第一件事不是看 diff，而是让机器先跑一遍基础检查。这一步太容易被人跳过了，因为 AI 生成的代码往往“看起来太正经了”，缩进整齐、命名规范、注释到位，看着就不像有低级错误。但恰恰是这种伪装配，最容易把问题藏在视线死角里。

最基本的兜底有三层。第一层是编译/解释确认，Java 就跑编译，Python 就跑 import 和语法检查，前端就跑 type-check。第二层是类型检查，比如在 Python 里跑 mypy，在前端跑 TypeScript 的严格模式。第三层是静态分析与 lint，ESLint、SonarQube、Pylint 都算这一类。

这三层能抓什么？能抓变量名拼错、类型不匹配、未定义变量、导入路径错误、明显的空指针风险。我遇到过最典型的案例是 Sonnet 5.5 生成了一段数据迁移脚本，里面引用了两个不存在的 SQL 函数，编译层根本发现不了，直到在测试库上执行才报错。如果当时先用静态检查扫一遍，至少能提前两轮发现问题。

但也要说清楚，静态分析的边界很明显。它只能抓“代码自身的逻辑一致性问题”，抓不了“代码和业务需求不一致”的问题。代码写得再干净，如果整体业务逻辑就是错的，机器不会替你发现。

2.2 测试才是真正的裁判

如果静态检测是守门员，那测试就是主裁判。AI 生成的代码，是否满足需求，最终要看测试用例能不能通过，而且得看测试用例本身的质量。

这里有一个特别大的坑，我必须重点强调：用 AI 生成实现，再让 AI 顺手生成配套的单元测试，这种做法非常危险。模型在生成实现时，脑子里已经形成了一套“它认为正确”的逻辑；让它再生成测试，它自然会围绕这套逻辑去构造用例。结果就是实现错了，测试也跟着错，最后测试全绿，上线直接报警。

正确的姿势是，测试用例由需求来定义，而不是由实现来定义。需求说“输入负数时返回错误提示”，那测试就写负数的用例；需求说“超过 1000 条要分页”，那测试就造 1001 条数据去看行为。至于是人写还是让 AI 基于需求文档写，都不重要，重要的是测试的来源是需求，而不是那份待验证的实现代码。

测试也有层次之分。单元测试盯函数和类，集成测试盯模块之间和外部依赖的协作，端到端测试盯整个业务链路。AI 生成代码时，单元测试最容易显得“全都通过”，因为模型很擅长构造自洽的小场景；而集成测试和端到端测试往往能暴露真实问题，比如数据库事务没提交、消息队列参数格式不一致、第三方接口鉴权失效。我的习惯是，让 AI 生成代码之后，人工至少补两个集成测试场景，这个成本省不得。

2.3 代码评审：最后的人类防线

测试把行为问题兜住了，但工程问题、安全问题、长期维护问题，还是得靠人来评。AI 编码助手把写代码的门槛降低了，但评审的权重反而更高了。因为代码量大了，检查面广了，人不可能一行行精读，必须带着目标去看。

我给自己定了一个四步评审法，专门用来应对 AI 生成的代码。第一步，看需求覆盖：这段代码有没有漏掉需求里的任何一条明确描述。第二步，看边界处理：空值、超长值、并发、超时、异常分支，这五个点至少过一遍。第三步，看依赖和配置：AI 特别喜欢引入新依赖或写死配置，要确认依赖是必要的、版本是兼容的、配置应该进环境变量而不是硬编码。第四步，看安全面：输入校验有没有做，访问控制有没有漏，日志有没有打印敏感信息。

评审还有一个视角经常被忽略——负数 diff。看评审时不要只看新增的代码，要看 AI 顺手删掉或改动的旧代码。大模型有一个特性，它会为了“让新代码和上下文更一致”而主动改动相邻代码，有时候这些改动是无意的，甚至是有害的。我遇到过模型把一根正常的分页逻辑偷偷改成了全量查询，理由是“避免重复代码”，理由合理化，行为却是灾难性的。

3. 可落地的验证流程：我从 Sonnet 5.5 拿到代码后做了什么

3.1 我的五层验证流程

理论讲再多，不如给一套能直接抄的流程。我现在的团队用 Sonnet 5.5 辅助开发，所有 AI 生成的代码，都要过下面五层验证，没有例外。

第一层，机器基础检查。编译、类型检查、lint、静态分析，跑完看有没有 error。这一层目标是过滤掉所有低级错误。

第二层，单元测试。执行已有的测试集，如果这个模块没有测试，就先补测试再跑。目的是确认函数级行为符合预期，特别是边界值。

第三层，集成验证。把代码跑在真实的本地环境里，连着测试库、消息队列、缓存这些依赖，看模块间交互是否正确。这一步能抓大量单测抓不到的问题。

第四层，端到端冒烟。对关键业务路径，从入口出发，完整走一遍流程，模拟真实用户操作。AI 代码经常在“数据流跨模块”时出错，这一层就是为此设的。

第五层，代码评审。前面说的四步评审法过一遍，重点看需求覆盖、安全、维护性和无意的连带改动。

这五层不是每次都要全套做。代码改动很小、影响面可控时，我会只做第一、二、五层；凡是涉及外部系统、数据迁移、接口变更的场景，我一定会把第三、四层加上。这个取舍不是偷懒，而是控制验证成本。

3.2 一个实例：让 AI 生成一个 Python API 服务

拿一个具体例子演示一下完整流程。某个内部工具需要提供一个“按用户查询最近订单列表”的接口，我用提示词让 Sonnet 5.5 生成 Flask 服务，包含简单的鉴权和数据库查询。

Sonnet 5.5 给出的实现大概长这样，这里截取关键部分：

from flask import Flask, request, jsonify from datetime import datetime, timezone app = Flask(__name__) def parse_user_token(token: str) -> int: # 简化演示，传一个静态值 return 1 def fetch_recent_orders(user_id: int, limit: int, after: str | None): conn = get_db_connection() try: cursor = conn.cursor() params = [user_id, limit] sql = """ SELECT id, total_amount, status, created_at FROM orders WHERE user_id = %s """ if after: after_time = datetime.fromisoformat(after.replace("Z", "+00:00")) sql += " AND created_at > %s" params.append(after_time) sql += " ORDER BY created_at DESC LIMIT %s" cursor.execute(sql, params) rows = cursor.fetchall() return [ { "id": row[0], "total_amount": float(row[1]), "status": row[2], "created_at": row[3].isoformat(), } for row in rows ] finally: conn.close() @app.route("/orders", methods=["GET"]) def list_orders(): token = request.headers.get("Authorization", "") user_id = parse_user_token(token) limit = request.args.get("limit", default=20, type=int) after = request.args.get("after") if limit > 100: return jsonify({"error": "limit too large"}), 400 orders = fetch_recent_orders(user_id, limit, after) return jsonify({"orders": orders})

这段代码第一眼很规范，有类型注解，有时间解析，有参数上限校验。但按我的五层流程走一遍，问题立刻出来。

第一层，mypy 和 lint 能过，编译没问题。第二层写单元测试时，发现parse_user_token是一个桩函数，没有真正解析逻辑，接口安全性完全没落地。第三层集成验证时，发现问题更明显：fetch_recent_orders里的get_db_connection()会为每次请求新建连接，性能在大流量下撑不住，起码要用连接池。第四层冒烟时，我用curl试了两个请求，一个正常，一个传了limit=101，响应正常返回了 400，这块没问题。

第五层评审时，我额外注意到两个毛病。一是created_at从数据库读出来直接转 isoformat，没有考虑数据库返回datetime类型时可能带时区信息，容易出现八小时的偏移。二是after参数解析用的是datetime.fromisoformat，这在 Python 3.11 以下对Z后缀支持不完整，部署环境如果版本旧一点，接口就直接崩。

这就是 AI 生成和真实交付之间的距离。代码在屏幕上是完整的，但在运行环境里是残缺的。

3.3 让 AI 主动交出验证线索

与其拿到代码后猜它的意图，不如让 AI 在生成时就交出验证需要的全部线索。我现在写提示词，末尾一定会加四句话：请列出你做了哪些假设；请给出测试设计；请说明依赖理由；请在代码中标注不确定的风险点。

这样做的原理很简单。模型在生成代码时，如果被要求说明假设，它就会在输出过程中多一层自检。比如“假设用户 token 解析结果固定为 1”这种话，一旦写在明面上，验证时就能直接对照。测试设计那段，哪怕写得不够充分，也能告诉你模型自己认为哪些行为是需要验证的，这本身就是线索。依赖理由会逼着它收敛到常用库，避开那些冷门到没几个人维护的包。风险点标注则是一种语言化的“诚实输出”，让模型把不自信的地方直接指出来。

我实测下来，这样改动提示词之后，五层验证过起来明显顺畅，尤其第二层和第五层的效率提升最大。因为你已经提前拿到了模型的“思维路径”，验证不再是盲猜，而是逐一对照它的假设去打勾。

4. 常见问题与排查技巧实录

4.1 AI 代码的典型翻车模式

用 Sonnet 5.5 写代码有一段时间了，踩过的坑不少，总结下来最典型的有六类，每一类都值得单独记一笔。

第一类，幻觉依赖。模型引用了一个看起来合理、实际上不存在或者不兼容的库/API。排查时最常见的就是 import 直接报错，或者运行时告诉你模块没有这个属性。解决办法是让 AI 写代码时必须带上版本依赖声明，同时养成安装依赖后立刻跑一遍pip check的习惯。

第二类，错误处理缺位。很多 AI 生成代码默认走 happy path，网络超时、文件不存在、数据库锁冲突、请求被断，这些分支要么没有 else，要么 catch 住 Exception 后全吞了。表现就是线上静默失败，用户看到白屏，日志里什么都没有。

第三类，忽略现实环境。写死配置、不设连接池、不考虑并发、不设超时，这些在本地单机场景全都不暴露，一上生产就卡死。翻车场景一般是把localhost写死在配置里，或者 Redis 连接不带超时参数。

第四类，安全隐患。SQL 拼接、路径穿越、越权、日志打印敏感字段，这些在 AI 生成的代码里出现频率比想象中高。尤其是“内网工具”场景，模型容易放松警惕，省略鉴权和输入校验。

第五类，边界条件遗漏。时区、夏令时、闰秒、空集合、超大整数、并发冲突，模型很少主动处理。我之前遇到过 AI 生成金额计算，直接用 float 做运算，线上出现 0.1 + 0.2 不等的经典问题。

第六类，过度设计。为了显得“专业”，模型会引入抽象层、设计模式、工具类，导致代码量翻一倍，但实际功能并不需要。这种问题不是 bug，是维护负担和信心负担——评审的人看到复杂结构，很难快速判断它对不对。

4.2 排查技巧速查表

面对 AI 代码出问题，与其从头读一遍，不如用症状定位原因。下面这个速查表是从实践中整理出来的，按最常见的症状来查，效率高很多。

这个表不能覆盖所有场景，但给了大概率的排查方向。真遇到复杂的，我的建议是：先补日志，再复现现场，别去分析 AI 的生成意图。模型生成代码时的内部逻辑，你猜不出，也不该猜，用观测数据说话。

4.3 我在验证过程中积累的几条硬经验

第一，建立一份“黄金回归集”。把过去半年线上出现过的问题浓缩成十几个测试用例，每次 AI 生成代码，跑测试时把这一组也带上。一开始会经常红，次数多了，AI 的代码质量会肉眼可见地变好。其实底层逻辑很简单——模型对常见坑的规避能力，是靠验证反馈训练出来的，你给它反馈，它就更少踩同一个坑。

第二，批量生成要克制。很多人喜欢让 AI 一口气把三五个模块全部生成，然后一次性验证。我试过几次，翻车概率极高。原因是多条生成之间没有上下文校验，模块间的接口约定常常不一致。现在的做法是一次只让 AI 做一件事，验证通过之后再进行下一件。速度会慢一点，但省了联调时查不一致的功夫，总体算下来反而快。

第三，别只看 diff 的新增行，也看被删掉的行。AI 为了“让代码更一致”会动相邻逻辑，其中有一些是无意的破坏。所以评审时我会专门把旧文件调出来，对照一下非需求相关的部分有没有被偷改。这一招帮我避免过至少三次线上事故。

第四，让 AI 用大白话解释它自己的代码。模型能生成一段代码，但不代表它“理解”这段代码。我把关键模块扔回给 AI，让它用中文讲一遍逻辑，讲不通的地方往往就是有问题的点。这个方法看起来有点像绕圈，实际上效果极好，因为它会强迫模型把潜在矛盾暴露在描述里。

说到这儿，基本把我对“谁来确认写对了”这个问题的答案讲完了。答案不是某一个人，也不是某一种工具，而是一套组合拳：机器先兜底过滤低级错误，测试用例从需求出发校准行为，代码评审兜住工程和安全隐患，再加上验证者的经验和流程。Sonnet 5.5 确实把代码写得快了，但写得更快这件事，只有配上一套不被提速裹挟的验证体系，才能真正变成交付效率。

最后再分享一个个人习惯：我每次让 AI 生成代码之前，会先把验收条件写在提示词第一行。比如“这段代码的验收标准是：A 场景返回 200，B 场景返回 400，C 场景数据库不新增脏数据”。模型看到验收标准再写代码，正确率和我事后拼命修，完全不是一个量级。毕竟提问的方式，决定了回答的质量。