在编辑器里调出 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 的严格模式。第三层是静态分析与 lintESLint、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, default20, typeint) 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试了两个请求一个正常一个传了limit101响应正常返回了 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 代码出问题与其从头读一遍不如用症状定位原因。下面这个速查表是从实践中整理出来的按最常见的症状来查效率高很多。表现症状概率最高的原因优先排查手段import 或 require 报错幻觉依赖、版本不匹配pip index versions 包名核对看版本变更时间运行时不报错但结果不对边界条件遗漏往后读逻辑被跳过补充需求推导的边界测试用例偶发超时、死锁连接池没用对、锁粒度太大检查数据库连接和事务边界返回值时区偏移8小时时间未按 UTC 存储或未转本地时区打印原始 datetime确认时区类型接口无响应递归或死循环多半是生成了自引用逻辑用 timeout 工具抓栈pystack或/usr/bin/timeout并发写入丢数据缺少幂等处理或乐观锁检查唯一索引和 update 条件越权访问鉴权中间件被跳过或数据过滤缺失检查路由前置钩子验证身份后是否全局过滤这个表不能覆盖所有场景但给了大概率的排查方向。真遇到复杂的我的建议是先补日志再复现现场别去分析 AI 的生成意图。模型生成代码时的内部逻辑你猜不出也不该猜用观测数据说话。4.3 我在验证过程中积累的几条硬经验第一建立一份“黄金回归集”。把过去半年线上出现过的问题浓缩成十几个测试用例每次 AI 生成代码跑测试时把这一组也带上。一开始会经常红次数多了AI 的代码质量会肉眼可见地变好。其实底层逻辑很简单——模型对常见坑的规避能力是靠验证反馈训练出来的你给它反馈它就更少踩同一个坑。第二批量生成要克制。很多人喜欢让 AI 一口气把三五个模块全部生成然后一次性验证。我试过几次翻车概率极高。原因是多条生成之间没有上下文校验模块间的接口约定常常不一致。现在的做法是一次只让 AI 做一件事验证通过之后再进行下一件。速度会慢一点但省了联调时查不一致的功夫总体算下来反而快。第三别只看 diff 的新增行也看被删掉的行。AI 为了“让代码更一致”会动相邻逻辑其中有一些是无意的破坏。所以评审时我会专门把旧文件调出来对照一下非需求相关的部分有没有被偷改。这一招帮我避免过至少三次线上事故。第四让 AI 用大白话解释它自己的代码。模型能生成一段代码但不代表它“理解”这段代码。我把关键模块扔回给 AI让它用中文讲一遍逻辑讲不通的地方往往就是有问题的点。这个方法看起来有点像绕圈实际上效果极好因为它会强迫模型把潜在矛盾暴露在描述里。说到这儿基本把我对“谁来确认写对了”这个问题的答案讲完了。答案不是某一个人也不是某一种工具而是一套组合拳机器先兜底过滤低级错误测试用例从需求出发校准行为代码评审兜住工程和安全隐患再加上验证者的经验和流程。Sonnet 5.5 确实把代码写得快了但写得更快这件事只有配上一套不被提速裹挟的验证体系才能真正变成交付效率。最后再分享一个个人习惯我每次让 AI 生成代码之前会先把验收条件写在提示词第一行。比如“这段代码的验收标准是A 场景返回 200B 场景返回 400C 场景数据库不新增脏数据”。模型看到验收标准再写代码正确率和我事后拼命修完全不是一个量级。毕竟提问的方式决定了回答的质量。
在编辑器里调出 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 的严格模式。第三层是静态分析与 lintESLint、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, default20, typeint) 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试了两个请求一个正常一个传了limit101响应正常返回了 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 代码出问题与其从头读一遍不如用症状定位原因。下面这个速查表是从实践中整理出来的按最常见的症状来查效率高很多。表现症状概率最高的原因优先排查手段import 或 require 报错幻觉依赖、版本不匹配pip index versions 包名核对看版本变更时间运行时不报错但结果不对边界条件遗漏往后读逻辑被跳过补充需求推导的边界测试用例偶发超时、死锁连接池没用对、锁粒度太大检查数据库连接和事务边界返回值时区偏移8小时时间未按 UTC 存储或未转本地时区打印原始 datetime确认时区类型接口无响应递归或死循环多半是生成了自引用逻辑用 timeout 工具抓栈pystack或/usr/bin/timeout并发写入丢数据缺少幂等处理或乐观锁检查唯一索引和 update 条件越权访问鉴权中间件被跳过或数据过滤缺失检查路由前置钩子验证身份后是否全局过滤这个表不能覆盖所有场景但给了大概率的排查方向。真遇到复杂的我的建议是先补日志再复现现场别去分析 AI 的生成意图。模型生成代码时的内部逻辑你猜不出也不该猜用观测数据说话。4.3 我在验证过程中积累的几条硬经验第一建立一份“黄金回归集”。把过去半年线上出现过的问题浓缩成十几个测试用例每次 AI 生成代码跑测试时把这一组也带上。一开始会经常红次数多了AI 的代码质量会肉眼可见地变好。其实底层逻辑很简单——模型对常见坑的规避能力是靠验证反馈训练出来的你给它反馈它就更少踩同一个坑。第二批量生成要克制。很多人喜欢让 AI 一口气把三五个模块全部生成然后一次性验证。我试过几次翻车概率极高。原因是多条生成之间没有上下文校验模块间的接口约定常常不一致。现在的做法是一次只让 AI 做一件事验证通过之后再进行下一件。速度会慢一点但省了联调时查不一致的功夫总体算下来反而快。第三别只看 diff 的新增行也看被删掉的行。AI 为了“让代码更一致”会动相邻逻辑其中有一些是无意的破坏。所以评审时我会专门把旧文件调出来对照一下非需求相关的部分有没有被偷改。这一招帮我避免过至少三次线上事故。第四让 AI 用大白话解释它自己的代码。模型能生成一段代码但不代表它“理解”这段代码。我把关键模块扔回给 AI让它用中文讲一遍逻辑讲不通的地方往往就是有问题的点。这个方法看起来有点像绕圈实际上效果极好因为它会强迫模型把潜在矛盾暴露在描述里。说到这儿基本把我对“谁来确认写对了”这个问题的答案讲完了。答案不是某一个人也不是某一种工具而是一套组合拳机器先兜底过滤低级错误测试用例从需求出发校准行为代码评审兜住工程和安全隐患再加上验证者的经验和流程。Sonnet 5.5 确实把代码写得快了但写得更快这件事只有配上一套不被提速裹挟的验证体系才能真正变成交付效率。最后再分享一个个人习惯我每次让 AI 生成代码之前会先把验收条件写在提示词第一行。比如“这段代码的验收标准是A 场景返回 200B 场景返回 400C 场景数据库不新增脏数据”。模型看到验收标准再写代码正确率和我事后拼命修完全不是一个量级。毕竟提问的方式决定了回答的质量。
