如何约束并验证 AI 生成代码的质量？

核心回答

约束并验证 AI 生成代码，关键是建立生成前有约束、生成中控范围、生成后有独立验收、失败后能反馈修正的闭环，不能只靠一句“请保证代码质量”。

1. 先明确任务和项目约束：给出输入输出、接口契约、边界条件、依赖版本及相关实现，写清哪些文件能改、什么行为必须保留。
2. 让 AI 小步修改：优先复用现有组件和方法，一次解决明确的问题，检查 diff 是否混入无关重构、依赖变化或测试删除。
3. 用工具和业务用例验证：按改动运行相关测试及必要的构建、类型或 lint 检查；涉及接口、权限和数据等行为时，再补充相应的集成、安全、性能或端到端验证。验收标准来自需求和业务规则，不能只使用 AI 按自己实现写出的测试。
4. 按风险审查并修正：人工重点看业务逻辑、权限、数据一致性和架构影响；将失败用例与日志反馈给 AI，修复后回归，保留可追溯的改动和检查结果。

例如生成订单查询接口，返回正确 JSON 还不够，还要验证用户只能读取有权访问的订单。类型检查能发现字段错误，权限用例和接口测试才能发现“换一个订单 ID 就能查到别人的数据”这类问题。

展开说明

生成前：把模糊要求变成能判断对错的约定

“写一个订单查询接口”缺少很多信息：订单不存在怎么办，谁能查询，敏感字段是否返回，以及已有项目如何处理错误。

可以先提供相关接口、数据模型、权限检查方式和既有测试，并把验收条件明确为：

• 查询有权限的订单时，返回约定字段。
• 查询无权限的订单时，按项目约定拒绝访问，不泄露敏感内容。
• 订单不存在、参数非法、数据库异常时，使用已有的响应与错误处理方式。
• 继续复用项目现有的鉴权和查询逻辑，不新增一套相似实现。

重复适用的命名、目录、错误处理和测试命令，可以放在项目规则中；当前任务的行为与边界放在任务说明里。复杂需求可以先写接口契约和方案，局部小改则把必要条件说清楚即可，不必额外制作完整设计文档。

涉及具体依赖时，还要检查实际安装版本与官方接口，防止生成不存在的方法、过时调用或多余依赖。

生成中：缩小修改范围，也限制执行权限

要求小步输出可审查的改动，能够更快发现方向偏差。修改完成后，应对照任务检查新增、修改和删除的文件，特别留意无关格式化、整文件重写、重复实现和锁文件变化。

提示词可以说明允许修改哪些文件；需要强约束时，还要由执行环境限制可写目录、网络和凭据访问。代码在隔离环境中运行，使用测试数据和必要权限，避免生成过程直接影响正式数据。

如果 AI 要修改公共接口、数据库结构或核心依赖，应先检查调用方和兼容性。一次局部修复不应顺带扩大成没有验收条件的重构。

生成后：不同检查负责发现不同问题

构建、类型检查和 lint 适合发现语法、类型、未使用变量及明确的规范问题，但无法证明业务做对了。格式化工具保证排版一致，也无法判断一段权限判断是否正确。

单元测试 检查局部逻辑、边界和异常分支；集成测试 检查接口、数据库、事务等真实协作；端到端测试 检查用户能否完成完整操作。订单查询中，如果鉴权被全部 mock 掉，单元测试通过也可能遗漏真实接口上的越权问题。

检查范围跟风险匹配：改一个纯函数，重点跑对应边界与调用方测试；涉及公共接口、权限或数据写入，则扩大回归，并检查真实状态是否符合预期。前端交互还要实际操作关键路径，按需要检查响应式、兼容性和可访问性；高频接口则依据性能要求检查数据量、查询计划和延迟。

安全与依赖扫描适合补充已知漏洞、危险调用和密钥泄露检查；业务权限、事务边界和重复请求语义仍需要专项用例及审查。

为什么 AI 自己写的测试还不够

代码和测试可能共享同一个错误假设。例如 AI 误以为“知道订单 ID 就能查询”，随后只测试订单存在与否，即使全部通过，也没有验证真正的访问规则。

提高可信度要让验收依据尽量独立：

• 从需求和业务规则推导预期结果，再检查实现。
• 保留现有回归测试，补充跨用户访问、空值、边界和故障等反例。
• 检查断言是否真的验证结果，是否过度 mock，或只判断函数“没有抛异常”。
• 对重要逻辑，可临时引入一个明确错误，确认关键测试确实会失败；测试仍通过，说明它没有有效覆盖该行为。

换一个模型做审查可以增加发现问题的机会，但不同模型仍可能共享错误假设。模型意见应落实到具体位置、失败场景和可验证证据，而不是用“两个模型都说没问题”作为验收结论。

失败后：根据证据修正，再防止同类回归

把失败输入、预期与实际结果、错误堆栈和相关 diff 一起反馈给 AI，让它解释原因并做针对性修复。修复后先重跑失败用例，再检查受影响的已有行为。

不能为了让检查变绿而删除测试、跳过断言或放宽验收条件。如果测试本身与需求冲突，应先确认正确的业务规则，再有依据地调整测试。

连续修改仍失败时，回到可复现的最小场景检查假设、依赖和环境，必要时由熟悉该模块的人接手。确认的缺陷转成回归用例，重复出现的规范问题转成 lint、结构检查或项目规则，减少后续生成同类问题。

递进追问

所有 AI 生成代码都需要逐行人工 Review 吗？

审查深度应跟影响范围和风险对应。自动化检查先覆盖重复、明确的规则；局部低风险改动重点核对需求与 diff。权限、资金、数据库迁移、并发和公共接口等改动，则需要熟悉业务的人深入看实现、调用方和异常路径。高风险逻辑不宜仅靠模型互审。

测试覆盖率很高，能说明代码质量好吗？

覆盖率说明哪些代码被执行过，不代表断言正确，也不代表需求场景完整。只有正常路径、没有越权和异常用例，或者测试始终返回固定 mock 值，都可能取得很高覆盖率。应结合关键业务规则、分支与边界、历史缺陷的回归情况判断测试是否有效。

不熟悉后端或数据库时，怎样检查 AI 生成的实现？

先搞清接口契约、权限规则、数据约束和副作用，再沿请求到数据库的路径核对实现。在测试环境用代表性数据验证查询结果、事务行为与性能；关键疑点查官方资料，并请熟悉该模块的人审查。AI 可以解释和提出反例，但陌生领域的高风险代码需要可执行验证与领域判断共同支撑。

对应教程

参考资料

AI代码生成平台Java

基于 AI代码生成平台

核心回答

这个平台要把生成完成、构建成功、部署完成和需求满足分开判断。实际单体 App 链路中，模型流结束后可以发出 SSE done，但这不能证明文件、构建和业务功能都正确；Vue 应用的正式部署入口会重新构建，检查返回值和 dist，通过后才复制产物并更新部署信息。

构建能发现依赖、语法和打包问题，不能证明页面已满足用户需求。进一步完善时，应从需求提取可执行的页面验收条件，将构建和功能验证分别记录，失败后再反馈具体证据修正；这些验收能力需要另外接入。

为什么流结束不能当作质量通过

AppController 在内容流正常完成后追加 done 事件，它表达的是这次响应结束。Vue 生成分支在模型完成回调中调用 VueProjectBuilder.buildProject()，但没有检查其布尔返回值，随后便完成流。因此，即使构建器返回 false，前端仍可能收到正常结束事件。

HTML/MULTI_FILE 分支则在收集完整文本后解析、保存代码；保存异常目前只记录日志，也可能不改变流的正常结束状态。生成片段已经展示给用户，与文件已经成功保存，是两个不同结果。生成门面和响应结束事件可以对照这两层状态。

正式部署用哪些实际条件放行

deployApp() 先检查应用及归属、定位生成目录；Vue 类型调用构建器，成功后才使用构建产物发布：

1. VueProjectBuilder 检查项目目录和 package.json，依次执行 npm install、npm run build。命令超时、异常或非零退出码都会返回失败；最后检查 dist 存在且是目录。
2. 部署入口检查 buildSuccess，为 false 就抛出构建失败；随后再次检查 dist 是否存在，将复制来源切换为该目录。
3. 把产物复制到部署目录，更新 deployKey 和部署时间，再返回访问地址。HTML/MULTI_FILE 类型按已有静态文件部署，不经过 Vue 构建分支。

构建器判断命令与产物，部署服务决定失败是否阻断发布。相同的构建函数，在调用方忽略返回值与据此拒绝发布时，形成的交付保证不同。

这里还有产物与记录的一致性边界：构建器没有显式清理旧 dist 或校验产物的生成版本；复制文件与更新部署记录又是分步操作，记录更新失败不会自动撤回已复制的文件。进一步完善时，可以为构建产物增加版本标识，让发布目录切换与部署记录指向同一版本；不能只凭目录存在就确认这次发布内容正确。

模型质检和需求验收放在哪里

仓库另外提供 LangGraph4j 工作流实验，将生成、模型质检和项目构建组织成节点；它没有接入上述 App 聊天主路径。实验中的质检节点在调用异常时设置为通过，构建节点异常时会返回原代码目录，因此不能把节点名称当成主应用已有的质量门禁。

如果后续把模型质检接入正式链路，可以用它发现可能的问题，但仍由真实构建和独立用例确认结果。例如需求要求表单有姓名、邮箱校验及提交后的反馈，即使 npm run build 成功，缺少邮箱校验仍应判为需求未完成。可按这些条件操作页面、检查实际结果，并把失败步骤、预期和实际表现交给生成环节修正，再重跑失败用例及相关回归。

这类需求验收是进一步设计。发布判断应读取明确的构建和验收结果，避免用“模型已停止”“返回了一个目录”或“另一个模型说通过”替代它们。

参考资料

• 国内：zero2Agent：工程化实战——代码质量与测试：参考生成约束、独立检查和失败回归，解释构建可运行仍不足以证明业务需求满足。
• 国内：JavaGuide：单元测试到底是什么？应该怎么做？：采用局部测试、集成和端到端验证的分工，说明构建、代码测试与完整页面行为各能发现什么问题。
• 国内：AgentGuide：如何落地一个可写进简历的 Agent 项目：借鉴先定义成功标准、再记录预期和实际结果的做法，组织本文提出的页面需求验收。
• 国内：阿里云云效：Node.js 测试构建：参考代码扫描、单元测试与构建产物分别配置和报告的方式，解释质量检查不能合并为一个笼统的成功标志。
• 国外：GitHub：Review AI-generated code：采用功能检查、需求一致性和 AI 常见错误的审查方法，说明模型评价不能替代独立验证。
• 国外：Vite：Building for Production：依据生产构建生成可供静态托管的产物这一职责，区分打包、发布和业务验收；本项目实际命令与放行条件以构建器和部署服务为准。