代码、测试用例和研发文档都要用正确性、完整性、可维护性、安全性、可执行性、可追溯性和一致性来衡量，但三者的权重和判定证据差别明显：代码靠运行结果和评审判断可执行与可维护，测试用例靠执行和覆盖检查判断有效性与可重复性，研发文档靠引用来源和交叉核对判断正确与一致。本文只讨论AI输出本身的质量维度，不涉及研发效能指标和模型基准测试。
要点总览（TL;DR）
- 研发场景的AI输出质量由正确性、完整性、可维护性、安全性、可执行性、可追溯性和一致性七个维度构成，每个维度对应可观察的证据。
- 代码输出权重最高的是可执行性、可维护性和安全性，正确性靠运行结果和代码评审验证。
- 测试用例输出权重最高的是可执行性和覆盖完整性，需要额外检查断言有效性和可重复运行。
- 研发文档输出权重最高的是正确性、一致性和可追溯性，可执行性明显弱化，流畅度不能代替事实核对。
- 评估时先定通用维度和权重，再按输出类型调整通过线，评估记录与证据一并留存以便追溯。
AI输出质量维度在研发场景指什么
研发场景里的AI输出质量，指的是一份由AI生成的代码、测试用例或研发文档，在被人使用、运行、维护和引用时，能否满足预期用途。它由一组通用维度构成，每个维度都对应可观察的证据，而不是凭主观印象打分。
正确性衡量输出内容与需求、事实或技术规则是否相符。代码的正确性看运行结果和边界条件处理，测试用例的正确性看断言是否指向真实预期，文档的正确性看描述与系统实际行为是否一致。典型证据包括测试运行记录、评审意见和与需求原文的比对。
完整性衡量输出是否覆盖了应当覆盖的内容。代码看分支和异常路径是否处理，测试用例看需求点和风险场景是否都有对应用例，文档看关键流程、前置条件和限制说明是否齐全。证据形式通常是需求条目与输出内容的逐项对照表。
可维护性衡量后续修改和理解的成本。代码看命名、结构、注释和耦合程度，测试用例看用例组织、数据构造方式和复用性，文档看结构层次和更新是否方便。证据来自代码评审、静态检查和后续修改的实际工作量。
安全性衡量输出是否引入风险。代码关注输入校验、权限判断、敏感信息处理；测试用例关注测试数据是否含真实敏感信息；文档关注是否泄露内部凭据或未公开信息。证据形式包括静态扫描结果和安全评审意见。
可执行性衡量输出能否直接投入使用。代码要能编译运行，测试用例要能被执行并稳定复现结果，文档的可执行性较弱，通常体现为步骤能否被他人照着操作。证据是实际运行记录和复现结果。
可追溯性与一致性是补充维度。可追溯性衡量输出能否回溯到需求、设计或来源，证据是引用链接和编号对应关系；一致性衡量同一批输出之间、输出与既有规范之间是否口径统一，证据是交叉比对和术语检查。
这些维度之间存在冲突。追求完整性会拉长输出、增加维护负担；追求可执行性可能牺牲通用性和可维护性。评估时需要按输出用途确定优先级，而不是要求每个维度都拿满分。
| 维度 | 含义 | 典型证据 |
|---|---|---|
| 正确性 | 内容与需求、事实、技术规则相符 | 运行结果、需求比对、评审意见 |
| 完整性 | 应覆盖的内容没有遗漏 | 需求条目对照表、覆盖清单 |
| 可维护性 | 后续修改和理解的成本可控 | 代码评审、静态检查、修改工作量 |
| 安全性 | 不引入数据、权限和泄露风险 | 静态扫描、安全评审 |
| 可执行性 | 能直接运行或照着操作 | 运行记录、复现结果 |
| 可追溯性 | 能回溯到需求、设计或来源 | 引用链接、编号对应 |
| 一致性 | 输出之间及与规范口径统一 | 交叉比对、术语检查 |
质量维度的边界：哪些不属于本文讨论
本文的讨论对象是AI产出的代码、测试用例和研发文档这三类具体产物，关注它们作为交付物本身的质量。判断依据来自产物内容、运行结果和评审记录，不涉及产出这些内容的模型本身有多强。
以下内容不在本文范围内：
- 研发效能类指标，如交付周期、吞吐量、缺陷密度趋势、需求交付率等，这些衡量团队和流程的整体表现，归研发效能管理主题讨论。
- 模型能力基准测试和榜单评分，如代码生成基准的通过率排名，这类结果衡量模型在标准题目上的表现，与具体项目中的输出质量不是一回事。
- 具体AI工具或产品的功能对比、选型推荐，以及价格、版本和认证信息。
- 工具采购决策。维度评估回答“这份输出能不能用、哪里要改”，采购决策还要考虑集成方式、成本和合规要求，属于另一个问题。
划清边界的作用是避免用模型榜单分数代替对实际输出的检查，也避免把团队交付节奏的快慢混入对单份输出质量的判断。
三类输出共用的评估机制如何运转
三类输出可以共用一套评估流程，差异体现在权重和通过线上，而不是各建一套体系。流程大致分为五步。
第一步，确定维度与权重。评估前先明确本次评估覆盖哪些维度，并按输出类型分配权重。权重调整就发生在这一步，后续抽样、检查和记录都沿用这套权重。
第二步，抽样。按批次或按需求抽取输出样本，抽样比例根据输出风险和批量大小设定。高风险模块可以提高抽样比例，批量生成的文档可以按章节抽取。
第三步，自动检查与人工复核分工。格式规范、静态扫描、用例能否执行、引用链接是否有效这类可机械判断的项目交给自动检查；正确性、可维护性、表述一致性这类需要理解上下文的部分交给人工复核。
第四步，按输出类型设定通过线。每个维度给出评分或通过与否的判断，再按权重汇总。代码和测试用例通常要求可执行性必须通过，文档则允许在可执行性上放宽，但正确性和一致性不能低于底线。
第五步，记录与反馈。评估结果连同证据一起记录，形成可查的评估记录，并把反复出现的问题反馈到提示词、模板或生成流程中。
角色分工上，抽样和自动检查可由发起评估的研发人员或质量人员执行，人工复核由熟悉该模块的工程师或文档负责人承担，评估结论由一人汇总确认，避免多人各记一套。评估记录需要保留样本、维度评分、证据和结论，便于后续对比。
当评估记录需要长期留存并与需求、任务对应时，可以借助 ONES 的文档与工作项管理能力承载：ONES Wiki 支持记录页面版本并随时查看与回滚，页面组可关联项目，使需求与文档互相对应；ONES Assistant 可将结果保存为工作项、Wiki 页面等内容。这样评估样本、复核意见和结论能留在同一处，减少页面切换和重复录入。
代码、测试用例、研发文档的维度差异对照
三类输出的维度差异，根源在于它们被消费的方式不同：代码被运行和维护，测试用例被执行和回归，文档被阅读和引用。消费方式决定了哪些维度权重更高、用什么证据判定。
代码输出中，可执行性、可维护性和安全性权重最高。正确性主要通过运行结果和代码评审验证，边界条件和异常路径需要单独检查。可维护性看结构、命名和耦合，证据来自评审意见和静态检查。安全性关注输入校验和权限处理，证据是扫描结果。
测试用例输出中，可执行性和覆盖完整性权重最高。除了用例能否运行，还要检查断言是否有效——断言写错会让用例通过却测不出问题；同时要确认用例可重复运行，不依赖执行顺序或外部状态。覆盖完整性靠需求点与用例的对照来判断。
研发文档输出中，正确性、一致性和可追溯性权重最高，可执行性明显弱化。文档的正确性靠与系统实际行为比对，一致性靠术语和口径的交叉检查，可追溯性靠引用来源和编号对应。文档写得通顺不等于这些维度合格。
| 维度 | 代码 | 测试用例 | 研发文档 |
|---|---|---|---|
| 正确性 | 权重高，靠运行与评审验证 | 权重高，靠断言有效性与预期比对 | 权重高，靠与系统行为比对 |
| 完整性 | 权重中，看分支与异常路径 | 权重高，看需求点覆盖 | 权重中，看关键流程与限制说明 |
| 可维护性 | 权重高，看结构、命名、耦合 | 权重中，看用例组织与复用 | 权重中，看结构与更新成本 |
| 安全性 | 权重高，看输入校验与权限 | 权重中，看测试数据是否含敏感信息 | 权重中，看是否泄露内部信息 |
| 可执行性 | 权重高，必须能编译运行 | 权重高，必须能稳定复现 | 权重低，看步骤能否照做 |
| 可追溯性 | 权重中，看与需求、设计的对应 | 权重高，看用例与需求点对应 | 权重高，看引用来源 |
| 一致性 | 权重中，看与既有规范统一 | 权重中，看命名与数据口径统一 | 权重高，看术语与口径统一 |
同一维度在三类输出中的判定证据也不同。以完整性为例，代码看分支覆盖，测试用例看需求点覆盖，文档看章节和关键说明是否齐全。评估时不能拿一套证据标准套用三类输出。
容易混淆的相邻概念与常见误解
评估AI输出质量时，有几组概念容易被混为一谈，导致判断偏差。
输出质量与模型能力、生成速度是不同层面的问题。模型能力指模型在各类任务上的整体水平，生成速度指产出效率，二者都不能直接说明某份输出是否满足当前需求。一份快速生成的代码可能完全可用，一份慢速生成的文档也可能存在事实错误。
通过率或采纳率不等于质量达标。采纳率高可能因为评审标准宽松，通过率高可能因为检查项太少。判断质量要看具体维度的证据，而不是只看一个比例数字。
文档写得流畅不代表正确性与一致性合格。语言通顺的文档可能描述了错误的流程，也可能与既有规范术语不一致。正确判断方式是拿文档与系统实际行为和规范原文逐项比对。
测试用例数量多不代表覆盖完整。大量用例可能集中在同一类场景，风险高的边界场景反而缺失。正确判断方式是按需求点和风险清单核对覆盖情况，并检查断言是否有效。
代码能跑通不代表可维护与安全。能通过基本运行测试的代码可能存在结构混乱、缺少输入校验的问题。正确判断方式是补充代码评审和静态检查，把可维护性和安全性单独评估。
- 看模型榜单分数代替看实际输出：应回到具体样本和证据。
- 用采纳率作为唯一结论：应结合维度评分和复核意见。
- 以流畅度判断文档质量：应检查事实正确性和口径一致性。
- 以数量判断测试覆盖：应按需求点和风险清单核对。
- 以运行通过判断代码质量：应补充评审和静态检查。
一个具体例子：同一需求下的三类输出如何分别评估
假设一个需求是“用户登录失败超过五次后锁定账号十分钟”。团队让AI分别生成实现代码、测试用例和接口说明文档，下面演示三类输出如何按各自权重评估。以下为演示情景，用于说明评估动作和证据形式。
代码输出的评估动作：运行登录失败计数和锁定逻辑，检查第五次失败后的锁定行为、十分钟后自动解锁、并发请求下的计数准确性。证据包括运行记录、边界条件测试结果和代码评审意见。评估结论按可执行性、可维护性、安全性权重汇总，若并发计数存在竞态问题，正确性和安全性两项均需扣分。
测试用例输出的评估动作：核对用例是否覆盖五次失败、锁定期间登录、解锁后登录、并发失败等场景，检查每条用例的断言是否指向锁定状态和剩余时间，确认用例可重复运行且不依赖执行顺序。证据包括用例与需求点的对照表、实际执行结果。若用例只覆盖顺序失败而缺少并发场景，覆盖完整性判定为不完整。
研发文档输出的评估动作：将接口说明与代码实际行为比对，检查锁定阈值、时长、错误码描述是否一致，核对文档中的术语与团队规范是否统一，确认引用的需求编号可回溯。证据包括比对记录和引用链接检查结果。文档语言通顺但把锁定时间写成五分钟，正确性判定为不合格。
三类结果汇总成一份评估记录，包含需求编号、输出类型、各维度评分、证据位置和结论。记录中代码和测试用例的可执行性作为必须通过项，文档则以正确性和一致性作为底线。汇总后把反复出现的问题，如并发场景遗漏、时长描述不一致，反馈到生成提示词和评审清单中，下一轮评估时重点检查。
这类评估记录需要与需求、任务保持对应关系，便于后续追溯和对比。ONES Wiki 的页面组可关联项目，需求与文档互相对应，文档版本可查看和回滚；ONES Assistant 可将结果保存为工作项或 Wiki 页面，使评估样本、复核意见和结论在同一处留痕。评估维度本身仍由团队按输出类型确定，工具承担的是记录与协作载体。
常见问题
三类输出能否共用同一套质量维度和评分表？
可以共用维度名称和评估流程，但权重和通过线需要按输出类型调整。代码和测试用例通常把可执行性设为必须通过项，文档则把正确性和一致性设为底线，可执行性允许放宽。评分表可以保留同一组维度列，在权重栏和证据栏按输出类型分别填写，避免各建一套体系导致结果无法横向比较。
评估AI输出质量时，抽样比例和复核人怎么定比较合理？
抽样比例按输出风险和批量大小设定：高风险模块可以提高比例，批量生成的文档可按章节抽取。复核人应熟悉对应模块，代码由工程师复核，测试用例由测试负责人复核，文档由文档负责人或需求负责人复核。评估结论由一人汇总确认，避免多人各记一套。抽样比例和复核角色建议在评估前写入评估说明，后续轮次沿用并可按发现的问题调整。
AI生成的测试用例全部执行通过，是否说明覆盖完整性合格？
不能说明。执行通过只反映用例本身能运行、断言当前能通过，覆盖完整性需要按需求点和风险清单逐项核对。常见问题是大量用例集中在同一类场景，高风险边界场景缺失；或者断言写错导致用例通过却测不出问题。判断覆盖完整性应查看用例与需求点的对照表，并抽查断言是否指向真实预期。
评估记录需要保留哪些内容，后续怎么用？
评估记录建议包含需求编号、输出类型、各维度评分或结论、证据位置和复核意见。后续用途主要有两个：一是与需求、任务保持对应，便于追溯和对比不同轮次的结果；二是把反复出现的问题反馈到生成提示词、模板或评审清单中。记录需要长期留存时，可以借助 ONES Wiki 的页面版本管理和页面组关联项目能力承载，ONES Assistant 可将结果保存为工作项或 Wiki 页面，使样本、意见和结论留在同一处。
模型榜单分数高，是否意味着项目中的AI输出质量就好？
不能直接等同。榜单分数衡量模型在标准题目上的表现，项目中的输出质量取决于具体需求、上下文和评审标准。一份榜单分数高的模型生成的代码，仍可能在当前项目的并发场景或权限处理上存在问题。判断输出质量应回到具体样本，按维度检查运行结果、覆盖对照和评审意见，而不是用榜单分数代替实际检查。
