企业官网建设流程全解析

本方案最终要实现三个效果：

• **可复用：**将 Agent 边界、风险分级、测试用例、评分规则和执行记录沉淀为版本化资产，供后续发布与同类能力复用。
• **可量化：**通过可核验的成功标准、逐次运行证据、分级缺陷和报告指标判断质量，并说明样本量与覆盖范围。
• **可迭代：**先按产品需求建立初始测试集，再持续收集线上失败案例并转成回归用例，用后续运行检验修复效果和能力退化。

0. 完整测试流程

1. **产品定义 Agent 边界和风险等级。**产品提供 PRD 能力卡，说明目标任务、输入输出、允许和禁止的行为、可核验的成功标准、关键风险及 P0／P1／P2 判定依据；开发和测试共同确认。示例见第 1 节。
2. **测试和开发分别编写测试集。**双方依据产品提供的需求 ID、边界和成功标准，自行建立开发集与独立测试集，覆盖正常、边界、应拒绝或追问、工具或数据异常。示例和持续完善办法见第 2 节。
3. **测试在本地执行并输出报告。**对固定化、可确定性核验的数据集和 LLM 评分数据集，按冻结版本运行流程化测试；需要领域判断、真实体验或争议裁定的内容由测试人员人工执行或复核。保存逐次运行与评分证据，处理缺陷，完成发布前回归并出具报告，详见第 3—7 节。
4. **上线后开展线上回归。**观察线上运行、真实业务状态和用户反馈，核实失败并按风险定级；将可复现的失败案例脱敏后补入固定回归集，在修复与后续发布时重跑，详见第 8 节。

**适用范围：**新 Agent 上线，以及代码、提示词、模型、工具或关键数据契约变更后的发布。执行顺序固定为：

PRD 定义能力 → 开发与测试独立建集 → 运行三类测试 → 处理缺陷 → 发布前完整回归 → 归档 → 上线观察。

1. PRD：先确定测什么

每项能力分配唯一需求 ID。产品、开发、测试在开发前确认一张能力卡：

例如，“查询订单状态”的成功标准要同时写明：回答与真实订单一致；订单无法唯一定位时先追问；不得修改订单；不得在未查到记录时编造状态。不能只检查回答文字，还要核对真实数据和操作结果。

产品提供的 PRD 能力卡示例（示意）

以下内容展示产品应交付给开发和测试的文档形式。业务字段、权限规则及指标上限应以实际产品 PRD 为准。

2. 测评数据集：开发与测试独立建立

双方共享 PRD 的需求 ID 和成功标准，不共享具体用例、测试数据、预期答案和评分配置。

独立测试集须覆盖100% 的 PRD 需求 ID，至少有30 个不同场景；每项核心能力至少10 个场景，包含正常、边界、应拒绝或追问、工具或数据异常。每个场景从复位状态独立运行3 次。这些是本流程的默认最低规模；提高规模可以，降低规模必须在首次测试前经 PRD 评审确认。

数据集文档格式

每个 Agent 保存一份《测评数据集说明》，记录 Agent ID、PRD 版本、数据集版本、负责人、用例数量、需求覆盖表、数据来源、环境与复位办法、评分器版本、访问权限和变更记录。每条用例至少包含：

case_id:ORDER-QA-001requirement_id:ORDER-01initial_state:"订单与权限数据的快照 ID"input:"提供给 Agent 的完整输入"expected_outcome:"可核验的正确输出和最终业务状态"forbidden_outcome:"不可接受的输出或操作"test_methods:[deterministic,llm,human]required_evidence:["工具返回","最终回答","订单真实状态"]reset_rule:"每次运行前如何恢复初始状态"

泄露给开发的独立测试用例转入固定回归集；测试人员补充新的隔离用例。线上故障经脱敏、补充预期结果和复位办法后，也按此方式入库。

测试集示例（对应ORDER-01）

下表仅示范如何把产品边界转成测试场景，不替代前述覆盖数量和执行要求。开发和测试可使用相同场景类别，但独立测试集的具体输入、数据和答案由测试保管。

例如，ORDER-01-R01的用例记录还需填写给 Agent 的完整输入、测试账号与订单快照、可核验的禁止结果、所需证据、评分规则和每次运行前的复位办法；表格中的简写不能直接当作可执行数据集。

数据集如何持续完善

1. **先按需求建集：**将每个需求 ID 映射到正常、边界、拒绝或追问、异常及高风险场景；检查每条用例能否执行、能否判定、能否复位。发布验收前冻结数据集和评分器版本。
2. **再收集线上失败：**从线上运行记录、用户反馈、人工抽查和缺陷单识别候选案例，保存必要上下文、实际结果和影响范围；先区分 Agent 缺陷、环境故障与评分器问题，敏感数据脱敏后再进入测试资产。
3. **转成回归用例：**测试与产品确认预期结果及其他可接受解法，补齐复现条件、证据和复位方式。能复现的失败加入固定回归集，修复前核实失败、修复后核实通过；暂不能复现的事件继续调查，不计作已验证用例。
4. **维护覆盖与隔离：**为新用例标注来源、需求 ID、风险级别和数据集版本；检查同类风险是否需要扩展独立测试集。已向开发公开的独立用例转入固定回归集，并补充新的隔离用例。比较版本时说明用例或评分规则的变化。

3. 三种测试方法如何使用

**按需求选择方法，一条用例可以同时使用三种。**评分先看最终结果；只有 PRD 明确要求的业务步骤，才检查执行路径。

使用 LLM 评分前，测试人员至少抽取30 条已有人工作出结论的运行记录进行校准；不足 30 条则全部校准。通过／失败判断与人工一致率须≥90%。未达标时，该维度的发布判定改由人工完成，修订 rubric 后再校准。

以订单查询为例：代码核对查询权限、真实订单状态和“未修改订单”；LLM 判断解释是否清楚、有无依据；人工复核歧义订单及自动评分争议。LLM 的高分不能覆盖代码发现的越权或错误写入。

4. 每次执行产生什么

**测评数据集是执行前冻结的输入资产。**执行一个用例一次，产生一条试验记录和一条评分记录：

• 试验记录：run_id、用例 ID、Agent／模型／提示词／工具版本、环境版本、输入、步骤、工具调用及脱敏返回、状态变化、最终输出、最终业务状态。
• **评分记录：**每项确定性断言、LLM 维度或人工判定的结果、依据、评分器版本和缺陷级别。

后台须允许授权测试人员按run_id查看这些中间过程和最终状态。工具或环境故障标为无效试验，修复后补跑，不计入 Agent 成功率；缺少必要运行证据的试验不能算通过。无需暴露模型内部思维内容。

一轮测评结束后，再生成按需求 ID 汇总的测评报告，而不是把运行结果写回原始数据集。

5. P0／P1／P2 定级及上线规则

按用户和业务影响定级；同一问题符合多个级别时取最高级。一次有效运行发现问题，不能因为重试成功就自动降级。

缺陷只有在修复完成、测试复测通过、补入回归集后才算关闭。允许带入上线的 P2 不得影响核心路径，须由测试负责人记录放行理由，并在下个版本前且最长 14 天内修复。

6. 发布前必须同时通过的门槛

P0/P1 的零容忍与质量合格率分别判断，不能用总体分数抵消严重缺陷。测试负责人出具通过／不通过结论；产品负责人确认 P2 放行清单。任何门槛未满足，候选版本不发布。

7. 每次发布前回归与存档

代码、提示词、模型、工具或关键数据契约发生变更时，执行同一流程：

1. 冻结候选版本及三套数据集版本。
2. 运行开发集，再由测试人员运行独立测试集及全部固定回归用例。
3. 对失败按 P0/P1/P2 分级；区分 Agent 缺陷、环境故障和评分器错误。
4. 修复后复测对应缺陷，并重新执行完整固定回归。
5. 对照第 6 节逐项判定，生成报告；批准后上线，线上以run_id观察真实故障。

每个候选版本建立不可覆盖的归档目录，保存 PRD 能力契约、数据集说明及版本校验值、用例和测试数据、rubric 与评分器版本、逐次运行及评分记录、缺陷与复测记录、发布报告和签署结论。独立测试集继续按测试权限保存；归档不意味着向开发开放隐藏答案。

最终，一个版本能否上线，由该版本冻结的数据集、逐次运行证据、P0/P1/P2 清单和上述门槛共同决定；下一次发布重新执行，不能沿用上次的通过结论。

8. 上线后线上回归与反馈闭环

1. **观察与发现：**按需求 ID 和风险等级查看线上运行记录、真实业务状态、用户反馈与人工抽查结果，识别错误结论、越权操作、应拒绝却执行、任务失败及质量退化。线上样本与离线用例分别报告，不将离线通过率当作线上成功率。
2. **核实与响应：**为失败事件关联run_id，核对必要的输入、工具调用、最终回答与真实状态，区分 Agent、工具、环境和评分问题；按第 5 节定级并记录影响范围。P0/P1 立即进入现有缺陷处置流程。
3. **回归与入库：**把确认的线上失败脱敏后，转成可复现的固定回归用例。在隔离或可复位环境中，使用对应版本配置复现，再以修复后的候选版本重跑；发送、支付、写入等带副作用的场景只在受控环境复现。
4. **复盘与更新：**记录修复、复测、遗漏原因和新增用例版本。必要时更新 PRD 边界、风险分级、评分规则和独立测试集；后续发布继续执行全部固定回归，并分别呈现线上反馈与离线测评变化。