reviewing-test-plan

reviewing-test-plan — SKILL.md

**变体：**标准 · **适用场景：**将已完成（或修订过）的 QA/验证测试计划作为验收门槛进行评审——检查测试人员能否执行该计划、每项上游行为是否都有可追溯的用例、用例目录是否按风险确定而非组合穷举，以及有充分理由开展的非功能测试是否带有数值目标，随后输出 VERDICT: approve|revise 和可执行的发现。

概述

此技能是测试计划编写/评审配对流程中的评审部分。评审人员加载此技能时，手头有一份已完成的 QA/验证测试计划——这份文档说明要测试什么、在哪个级别测试、在什么环境中测试、使用什么数据、以什么完成标准判定，以及要运行的用例目录。此技能围绕一个问题评判该文档：测试人员能否无需提问就执行此计划，提交的上游材料中的每项行为是否至少有一个可追溯的测试用例，以及用例目录的规模是否按风险确定（既非所有输入排列组合的笛卡尔积，也非内容单薄）？它采用固定的 10 项覆盖率与可测试性检查清单——与测试计划作者遵循的标准相同（authoring-test-plan 第 7 步），确保产出标准与评审标准不偏离——然后输出一项可由机器解析的判定，以及作者可在一轮修订中处理的发现。这是一道验收门槛：它不会编写、修复或改写计划，而是对计划作出评判并返回发现，由编写者进行修订。

影响最大的检查项是覆盖完整性（枚举所有上游行为/操作/错误，并确认每项至少有 1 个可追溯的用例——没有对应用例的行为是影响最大的缺陷）和用例目录规模（按风险确定，既不过度膨胀为组合穷举，也不单薄或刻意填充）。即使计划看起来很全面，这两项也很容易被漏掉。

何时启用

• 已完成的 QA/验证测试计划需要在测试开始前，或在其作为发布运行手册退出标准的一部分之前，作出接受/修订的决定。
• 你是测试计划的独立评审人员/把关人，编写者刚完成计划，且你拥有可用于核对覆盖情况的上游材料（功能规格/API 规格/PRD）。
• 在先前判定为 revise 后重新评审修订后的测试计划，或评审一项修订（针对已批准计划提交的变更请求——按差异范围评判，第 10 项条件）。

请勿在以下情形启用：

• 编写或修复测试计划 → 使用 authoring-test-plan（它会遵循此技能所要求的同一标准）。此技能绝不会编写文档。
• 评审发布/部署运行手册——即上线流程（部署步骤、验证、回滚）→ 使用发布运行手册评审技能。运行手册会复用此计划的退出标准；两者的标准不同（可执行性/回滚与覆盖率/可测试性）。
• 评审工程设计文档——规格说明、计划、设计文档、RFC 或 ADR → 使用设计评审技能，核实设计主张是否符合代码库。该技能把关设计；此技能把关由设计下游推导出的验证计划。
• 评判或运行可执行测试脚本（pytest / Playwright / 等）——这些属于实现，位于此计划的下游。此门槛评审的是计划文档，而非自动化代码或测试运行结果。
• 检查模板/章节是否符合要求 → 这是模板方面的问题。此技能评判的是质量是否达到标准，而非是否包含每个标题。

工作流程

步骤 1：以全新的视角通读整个计划，并调取上游文档

从头到尾阅读测试计划，假设自己是明天就要执行它的测试人员，不带入作者的解读框架。你应当把自己定位为这位测试人员的把关人：只有当某项发现表明测试人员无法执行某个用例、无法判断是否满足完成标准，或发现某种行为没有对应的用例时，它才有分量。确定该计划所针对的项目类型（轻量 CLI 还是大型 UI 产品）——步骤 2 的比例校准取决于此。务必加载提交的上游文档（功能规格 / API 规格 / PRD / NFR——以项目实际产出的文档为准）：它们是你的覆盖检查清单。逐一列出每项行为 / 验收标准（功能规格）、每项操作及错误情形（API 规格），或者——如果没有产出前两类文档——每项需求（PRD）；并记录需要进行非功能测试的 NFR。绝不要假定输入固定：应根据实际提交的上游文档逐项列出。如果没有提交某份上游文档，现在就记录下来——在步骤 4 中将其标记为假设，并根据现有材料评判覆盖情况；绝不要臆造项目并未产出的文档要求，也绝不要因为无法完整执行检查清单就默认批准。如果提交的是针对现有计划的变更请求，则这是一次修订——按条件 10 执行限定于差异的检查（步骤 2）。

步骤 2：运行覆盖率与可测试性检查清单——逐项评判条件

针对以下每项条件，判定为通过或存在缺口。只有存在真实且明确指出的缺陷时，条件才算未通过——“如果是我，会用不同顺序安排用例”不算缺口。对于每项缺口，记录准确位置和缺失内容（步骤 4 会将其转化为可执行的发现）。这十项条件构成单一事实来源的评判标准（即 authoring-test-plan 步骤 7 所遵循的同一套条件）；不要添加私有条件。深度说明及通过 / 缺口示例：references/coverage-testability-bar.md。

1. 完整覆盖。 提交的功能规格中的每项行为／验收标准，以及提交的 API 规格中的每项操作和错误情况（否则为 PRD 中的每项要求），都必须至少有 1 个可追溯的测试用例。如果某项上游列明的行为／操作／错误没有任何用例指向它，即为缺口——这是影响最大的缺陷类别。（适用于任何规模。）
2. 功能测试级别适当。 所选功能测试级别和类型应符合项目情况——按系统需要覆盖单元／集成／端到端／验收测试；按需覆盖回归／冒烟测试；任何省略都应说明理由，不能默默省略。如果系统显然需要某个测试级别，却没有该级别且未说明理由（例如，多服务系统没有集成测试用例），即为缺口。（非功能测试属于条件 9，不在此处。）**比例原则：**精简项目可以合并不需要的测试级别。
3. 入场／退出标准可测试。 入场和退出（“完成”）标准应可观察、可衡量——读者能够通过机械方式判断每项标准是否满足（例如，“所有高优先级用例均通过；每项行为都有一个通过且可追溯的用例；没有未解决的严重／高优先级缺陷”）。退出标准应关联覆盖率下限和未解决缺陷阈值；覆盖率应针对需求／风险表述，而不是只给出一个代码覆盖率百分比。如果标准含糊不清（例如“测试情况良好”），以致两位读者可能得出不同结论，即为缺口。**比例原则：**精简计划可以只有简短的标准列表，但每项标准仍须可判定。
4. 明确环境和测试数据。 每个测试级别都应说明测试在哪里运行、所需的数据／测试固件，以及如何提供／重置数据，还有如何处理敏感数据（PII／PHI）。如果某个测试级别未指定环境，或用例假设存在计划中从未说明的测试固件，即为缺口。**比例原则：**精简计划只需一个环境和简单的测试固件。
5. 每个目录用例都可执行且可追溯。 每个用例都必须包含前置条件、单一操作步骤、可观察的预期结果（负向用例应给出确切消息／错误；ML／概率型用例应给出针对指定数据集的指标阈值或变形关系——“模型准确”／“结果相关”属于不可执行的结果，需予以排除），以及追溯到。如果用例缺少前置条件、步骤含糊或包含多个操作、预期结果不可观察，或没有追溯到的对象，即为缺口。（适用于任何规模——这是最低可执行性要求。）
6. 按风险确定优先级并分配测试权重。 计划应依据可能性 × 影响确定优先级，目录中的测试深度应随风险而定——高风险领域应有更多用例（边界、等价类划分、决策表／状态转换／成对选择、负向路径），琐碎领域则应减少用例——而不是覆盖所有输入排列的笛卡尔积。如果出现以下三种情况之一，即为缺口：覆盖不足（相对于风险，用例过少）；组合爆炸（测试每种排列，例如对一个含 10 个开关的模块测试全部 1,024 种组合，而不是按风险和成对组合选择）；或凑数／内容单薄的目录（用例没有增加覆盖，或高风险领域只有一个正常流程用例）。用例设计技术是辅助作者的手段——应评判结果，而不是要求“绘制决策表”。
7. 不得捏造。 每个用例都必须追溯到真实的上游依据；任何覆盖缺口（不可测试的需求、缺失的 NFR）都应作为明确假设指出，绝不能用臆造的行为填补。如果用例测试的行为没有任何上游依据，即为缺口。应抽查部分用例，将其追溯对象与实际的上游依据核对。（适用于任何规模。）
8. 与项目类型相称。 目录和测试级别应根据项目规模确定——精简的 CLI 只需少量用例，也可以合并非功能测试；大型 UI 产品则需要很多用例。只有当计划对于其项目类型而言过于简略或组合过于繁复（条件 6）时，才属于缺口。规模适配不构成缺口。
9. 非功能测试（适用的类型须包含数值目标）。 应包含NFR／项目类型所要求的每种非功能测试，并提供可核验的方法和数值／标准目标：性能（负载配置＋p95／吞吐量）、安全（由威胁分析推导出的测试集）、无障碍（WCAG 2.2 AA）、可用性、兼容性（矩阵）、国际化／本地化。如果某项适用的测试类型虽已列出，却没有方法／目标（例如只说“我们会测试性能”，却没有负载配置／目标），或存在 NFR 却没有任何非功能测试覆盖该要求，即为缺口。比例原则（至关重要）：没有任何 NFR 要求非功能测试的精简项目，其不包含任何非功能测试类型都不构成缺口；绝不能强求项目类型不需要的非功能测试，也绝不能捏造目标。（本条件负责非功能测试方面的评估；条件 2 仅涉及功能测试——缺少适用的性能测试级别只算本条件下的一项问题，不重复计算。）
10. 按变更范围修订（仅适用于提交了变更请求的情况）。 如果输入包含针对现有计划的变更请求／增量，则应按变更范围评估：增量应在范围内，且只修改、不重绘计划；覆盖映射应已重新追溯（重新映射变更的行为、退役已移除的行为，且不遗漏任何没有用例覆盖的行为）；应依据影响＋风险选择回归测试集（不能全选，也不能全不选）；发现缺陷后修订计划时，应增加一个可追溯的回归用例；计划应包含自身的版本号和变更日志，并标记已被取代的用例；受影响的用例仍须满足条件 5–6——不对未变更的计划进行全面复审。如果增量悄然重绘计划、变更的行为缺少重新追溯的用例、回归测试选择不足／过度，或缺少版本号／变更日志，即为缺口。比例原则：从零开始首次构建（没有变更请求）时，本条件不适用，绝不构成缺口。 适度原则。“测试人员能否执行，以及是否覆盖了每种行为”应根据项目规模而定。精简项目的计划可以合理地省略不需要的内容——没有非功能需求（NFR）时无需进行非功能测试（条件 9 不适用）；没有集成边界时无需设置集成测试层级；行为较少时，目录可以较短；全新项目无需设置修订章节（条件 10 不适用）。这是恰当的规模控制，不是缺漏。评估时应关注测试人员能否执行，以及所列行为是否得到覆盖，而不是用例数量。满足所有适用条件的精简完整计划即可通过；不要因篇幅简短就凭空认定存在缺漏。（无论规模如何，条件 1、5、7 仍然适用。）

步骤 3：确定结论

• approve — 所有适用条件均通过。测试人员可以按计划执行，每项上游列出的行为都有可追溯的用例，目录按风险加权，适用的非功能测试设定了目标，且没有编造内容。即使你能想到风格上的改进，也应批准；评判标准是覆盖率和可测试性，而非完美无缺，更非面面俱到。
• revise — 一个或多个适用条件存在明确缺漏。

不要为了体现工作量或索要锦上添花的内容而要求修订。条件要么满足，要么不满足。

步骤 4：输出结论和可执行的发现

将结论作为单独一行输出——原文必须为 VERDICT: approve 或 VERDICT: revise，独占一行，不要添加代码围栏、引号或额外文字（此处的围栏仅作示例）：

VERDICT: approve

然后在接下来的行中列出发现。结论为 revise 时，每条发现都必须可执行——指出未通过的条件、具体位置，以及修复方法。结论为 approve 时，可以选择列出非阻断性备注；不要让这些备注暗示必须修订。

如果未提供上游材料，请明确说明这是一个假设（例如：“未提供 api-spec — 仅根据 feature-spec 判断操作/错误覆盖情况（条件 1）”），并依据现有材料评估其他条件。不要对无法执行的检查默不作声，也不要默认批准。

好的发现会明确指出缺漏和修复方法：

revise — 覆盖完整性（条件 1）：feature-spec 中的行为“用户可以通过电子邮件链接重置密码”没有对应的可追溯用例。修复方法：添加一个用例（成功路径 + 链接过期/无效时的负向测试），并添加回溯到该行为的 traces-to。

revise — 非功能测试（条件 9）：NFR-PERF 要求 p95 <= 200ms，但计划中的性能测试行没有说明负载配置或目标。修复方法：添加负载配置（并发数/持续时间）、p95 目标和工具，或者将该 NFR 标记为无法验证。

revise — 仅针对变更范围的修订（条件 10）：变更请求修改了“结账时应用优惠券”的行为，但目录尚未重新追溯，也未选择回归测试集。修复方法：重新映射优惠券覆盖行，添加/调整其用例，并选择基于影响和风险的回归测试集（依赖优惠券的购物车和定价用例）。

不好的发现含糊不清，也无法据此采取行动：

覆盖还可以更全面一些。（具体是哪个行为？哪个用例？该如何修复？）

规则

硬性规则（绝不可违反）：

• 只输出一行判定：VERDICT: approve 或 VERDICT: revise——必须是该字面标记，独占一行，行内不含其他内容。下游工具会解析此行。不得使用其他判定词。
• 评审，不代写。 返回问题；不要重写、修正或补全计划。由作者负责修订。
• 统一评审标准。 按照第 2 步的十项条件进行评审——这与作者依照 authoring-test-plan 第 7 步编写时使用的标准相同。不要另行发明条件，也不要擅自采用更严格的标准。
• 覆盖完整性至关重要。 列举所有已提交上游材料中的行为／操作／错误，并确认每项都有至少一个可追溯的测试用例（条件 1）。根据实际提交的上游材料列举——绝不要假设输入内容固定。
• 按风险加权，不穷举组合，也不做得过于单薄。 覆盖缺口、对所有输入排列进行完整笛卡尔积组合，以及目录内容注水／过于单薄，任一情况都会导致 revise（条件 6）。测试用例设计技巧是作者的辅助方法，评审看结果——绝不要强求使用某个指定技巧。
• 非功能测试应有针对性且与风险相称。 对于原型确实需要的非功能类型，如果没有测试方法／目标，就存在缺口（条件 9）；原型不需要的非功能类型则不要求，也绝不应凭空编造目标。条件 9 负责非功能维度；条件 2 仅评估功能维度——不要对缺少性能级别重复扣分。
• ML 测试用例应采用指标阈值，而非固定预期结果。 ML／概率性测试用例的预期结果应是在指定数据集上达到某个指标阈值（或满足某种蜕变关系）；“模型准确”不是可运行的结果，条件 5 会据此判定不合格——应识别出这类概率性测试，而不是额外设定标准。
• 变更仅按差异范围评审（条件 10），由输入信号决定。 只有在提交了变更请求时才执行条件 10；全新项目则标记为不适用。评估变更内容、覆盖／追溯完整性以及回归测试选择，不评审未变更的计划部分。
• 不得臆造。 测试某项上游材料未声明行为的测试用例属于缺陷（条件 7）——应将真正的缺口标记为假设。抽查 traces-to，并与实际的上游材料核对。
• 不得误判为 revise。 只要计划满足所有适用条件，即应批准，即使计划内容较少也不例外。只要仍覆盖了所有列出的行为，按比例确定规模就不构成缺陷。只有存在真实且明确的问题时才判为 revise。
• 不得误判为 approve。 绝不要为了迎合而无视真实缺口。阻塞性缺口应判为 revise。
• 不可测试的完成标准属于缺口。 两位读者可能产生分歧的退出标准不符合条件 3——完成标准必须可机械判定（覆盖率下限 + 未解决缺陷阈值）。
• 上游材料缺失时应明确指出，不可默默放行。 将其明确列为假设；根据现有材料评审其余内容。绝不要默认批准。
• 依据文档收到的上游材料进行评审。 未提供的上游材料绝不构成判定为 revise 的理由。但计划若忽略了已提供的上游材料（例如已提交的功能规格中描述的行为没有对应测试用例），则是合理的问题。
• 每条 revise 评审意见都必须可执行——指出不符合的条件、具体位置和明确的修复方法。不得给出含糊的意见。

偏好（可调整）：

• 按严重程度排列评审意见——先列覆盖缺口和臆造内容，再列目录规模和非功能问题，然后是变更评审，最后是次要问题。
• 在每条评审意见中注明条件编号／名称，方便作者对应评审标准。
• 批准说明应尽量精简，并明确标注为非阻塞。

易忽略之处

• 因内容完整而非可执行性而批准。 每个部分都可能齐全，但计划仍无法执行（例如，没有前置条件、步骤含糊、预期结果不可观测或没有追溯关系）。判断测试人员能否执行并追溯，而不是模板是否填满。
• 有行为却没有用例。 计划看起来可能很全面——目录很长、覆盖矩阵齐全——却悄然漏掉了一个上游行为的用例。唯一的办法是列出上游行为并逐项勾选（条件 1）。目录再长也不能证明覆盖充分。
• 看似严谨的组合爆炸。 列出所有排列组合的目录看似全面，却难以维护，也忽视了风险权重——一个包含 10 个开关的模块有 1,024 个用例，这本身就是缺陷（条件 6）。检查高风险区域是否有足够的深度，低风险区域是否只需覆盖基本成功路径。
• 过于单薄或填充凑数的目录。 用例彼此重复（凑数），或高风险区域只有一个基本成功路径用例（过于单薄）。即使数量看起来合理，这两种情况都不符合条件 6。应根据风险判断测试深度。
• 无法测试的退出标准。 “覆盖情况良好时测试完成”无法通过机械方式判定（条件 3）。真正的退出标准应与通过的用例和未关闭缺陷的阈值挂钩。
• 将“模型准确”作为 ML 预期结果。 非确定性系统没有固定的判定依据——无法执行确定性的通过／失败判断（条件 5）。接受基于指定数据集的指标阈值或蜕变关系；不要在条件 5 之外另设门槛。
• 非功能项重复计数或要求过高。 不要同时根据条件 2 和条件 9 标记缺少性能等级——这属于条件 9 的范畴。也不要要求精简项目的类型特征并不需要的非功能测试（条件 9 要求按比例衡量；没有 NFR 时标为不适用）。
• 凭空编造的用例。 用例可能测试的是某种看似合理、但没有上游声明的行为（条件 7）。抽查追溯关系；没有真实上游依据的用例是缺陷，而不是覆盖。
• 将修订请求当作完整评审。 收到变更请求时，应评审变更内容，以及覆盖／追溯完整性和回归测试的选择（条件 10），而不是重新完整评审未变更的计划；反过来，如果修订没有重新追溯覆盖情况或选择回归测试集，也不能直接放行。
• 系统性过度标记（误判为需修订）。 评审者受命寻找问题时可能矫枉过正，将合理的计划判为有缺陷。把握好标准：只有明确指出真实存在的缺陷，条件才算有缺口；不能仅因用例顺序或等级选择与你的做法不同，就认定有问题。
• 对按比例缩减的计划误判为需修订。 精简项目的计划规模合理地较小——用例只有几个、没有 NFR 时不做非功能测试、没有接口边界时不设集成测试层级。这是合理的规模调整（条件 1、5、7 仍然适用）。
• 与发布运行手册评审或设计评审门槛混淆。 此处评审的是 QA／验证计划。发布运行手册评审关注的是复用该计划退出标准的操作流程；设计评审门槛则是依据代码库评审工程设计文档。
• 判定标记格式漂移。 “Approved”“LGTM”“needs work”，或藏在段落中间的判定结果都无法解析。请单独一行输出字面内容 VERDICT: approve|revise。

反模式

• 盖章式批准。 扫一眼目录的篇幅就批准——设置这道关卡，是为了发现测试人员无法执行或遗漏某种行为的计划。
• 跳过上游枚举。 “目录很长，所以覆盖肯定没问题”——如果不枚举上游行为并逐项核对，就会漏掉影响最大的缺陷类别（条件 1）。
• 只数用例，不按风险加权。 目录越大不代表越好。标准是按风险加权的覆盖率（条件 6）。
• 凭空添加条件。 加入标准中并未要求的私有要求（“应该包含可追溯性工具导出 / 特定测试管理格式 / 字面意义上的决策表 / 探索性测试层级”）。只评判这十项条件——用例设计技巧、探索性测试 / SBTM 和蜕变测试都是作者的辅助方法，只按结果评判，绝不可强制要求。这是新辅助方法的关键防护措施。
• 过度追求完备。 对不需要非功能类型、集成测试层级或更全面目录的精简项目提出这些要求（条件 9 讲究适度）。
• 因琐事要求修改。 因用例排序偏好或伪装成缺口的锦上添花要求而阻止通过。只有真正阻碍覆盖或可执行性的问题才应要求修改。
• 暗中重写。 在评审过程中代为编写，会打破产出与评判之间的分工。
• 含糊的判定。 “基本批准，但是……”或两行判定。必须只有一个决定，并且恰好使用一个判定词。

输出

针对一个测试计划，给出一份评审结果：

• 一行判定 — 原样输出 VERDICT: approve 或 VERDICT: revise，独占一行。
• 发现项 — 如果判定为 revise，每个阻碍性缺口列出一项可执行的发现（未通过的条件 + 位置 + 具体修复方法）；如果判定为 approve，可选择列出非阻碍性备注。

当前待评审的计划是文本形式——策略说明 + 覆盖矩阵 + 非功能矩阵 + 测试用例目录（通过本地文档后端提供的 Markdown）；评审的方法和标准与介质无关（未来导出到测试管理工具只会改变介质）。抽象使用方是负责协调产出->评审循环的任何主体：approve 表示接受计划以供执行（并允许发布运行手册复用其退出标准）；revise 则返回发现项，以便进行有范围限制的修订。

相关内容

• authoring-test-plan — 这对流程中的产出环节；它会按照本技能评判的同一覆盖率与可测试性标准编写计划（其 Step-7 = 这十项条件）。将两者配对可以让标准只有一个来源，避免产出和评审所依循的标准出现偏差。
• 上游的 feature-spec / api-spec / PRD / NFRs — 每个用例都从这些文档中推导而来；这道关卡会枚举其中的行为 / 操作 / 错误，并检查每项是否都有可追溯的用例（条件 1），还会检查是否覆盖了 NFR（条件 9）。这些文档在各自编写时通过关卡，而不是在这里。
• release-runbook-review 技能 — 用于评审复用本计划退出标准的生产发布操作运行手册。文档不同，标准也不同。
• design-review 技能 — 用于评审工程设计文档（规范、计划、RFC、ADR），并依据代码库核验其中的主张。关卡不同，产物也不同；它评审的不是验证计划。
• 测试计划模板 / 内容模板 工具 — 负责章节结构；本技能评判的是质量是否符合标准，而不是结构是否合规。

渐进式披露

• references/coverage-testability-bar.md — 逐项列出十项条件的通过 / 缺口信号及示例发现（尤其是深入阐述的条件 3 / 4 / 5，以及新增的条件 9 非功能要求 + 条件 10 修订），并说明如何避免误判为需修订，以及不凭空添加条件的原则。应用标准时如需深入指导，请加载此文件。
• references/sources.md — 评审方法的研究依据（单一来源的覆盖率与可测试性标准；ISTQB / ISO-IEC-IEEE 29119 / WCAG 2.2 / OWASP / NIST 方面的依据；避免误判为需修订原则所依据的评审者过度纠正研究）。仅在审查指导来源时加载。

正文预算

• description <= 1,024 个字符（agentskills.io 上限）。Claude 会在列表中将 description + when_to_use 的总长度截断至 1,536 个字符。
• 正文 <= 约 500 行 / 5,000 个令牌 — 每轮都会保留在上下文中。
• 每个参考文件：超过 10k 个令牌时发出警告，超过 25k 个令牌时出错。参考文件总计：超过 25k 个令牌时发出警告，超过 50k 个令牌时出错。

更新日志

• 1.1.0（2026-06-15）— 采用单一来源的重构，调整为与 authoring-test-plan 1.1.0 匹配的 10 项条件标准：条件 2 缩小至 FUNCTIONAL 级别；新增条件 9 非功能测试（适用的类型须设定数值目标 — 性能/安全/WCAG 2.2 AA/兼容性/i18n；纳入旧条件 2 中的非功能条款，不重复计数）以及条件 10 按变更范围修订；深化条件 3（覆盖率下限 + 未解决缺陷阈值）、条件 4（测试数据管理）、条件 5（对 ML 指标阈值的识别）；案例设计技术 + 探索式测试/SBTM + 基于蜕变的测试作为作者辅助内容，按结果评判（强化防止臆造条件的约束）。VERDICT 合约 + 输入合约保持不变。
• 1.0.0（2026-06-05）— 首个经审核的版本。