针对同一份登录需求，测试人员可以直接提问、套用 Prompt，或调用 Skill。哪种方式更适合，不能只看几段输出。模型版本、需求材料、对话历史和运行设置都会影响结果；条件不一致时，无法单独比较使用方式的效果。
为避免概念重叠，本文把“直接提问”定义为临时自然语言请求，把“Prompt”定义为可重复使用的结构化模板，把“Skill”定义为由指定宿主工具加载的一组可复用指令、步骤及配套资料。不同工具中的 Skill 能力和可调用资源可能不同。
下面列出三种方式的示意输出，说明评审重点。真实效果要用同一组样本运行后判断。
新手入门：第一次比较可以这样做
第一次可以只选一条需求。先准备三组共同输入和评审者专用的参照清单，再按以下步骤比较：
- 固定目标和需求版本。 说清楚三种方式都要完成同一件事，例如“生成关键测试场景，并指出未说明的行为”。
- 各跑一份干净会话。 不让任一方式继承其他方式的对话历史；记录工具、模型、参数和版本。
- 保存全部输出。 包括追问、人工补充、修改时间和最终结果，不只保存最好看的那次。
- 按同一清单评审。 由评审者先隐藏输出来源，再检查需求依据、风险遗漏、无依据结论和可执行性。
- 按任务决定是否复用。 一次性探索可能直接对话就够；重复任务才值得考虑维护 Prompt 或 Skill。
先准备共同输入和评审参照
对比手机号验证码登录需求时，先区分两类材料。共同输入包括三种方式都能看到的需求正文、已确认规则、必要上下文和输出要求；评审参照由熟悉业务的人预先整理，只供评审者使用，列出有依据的关键风险、待确认行为和判分规则。若目标是比较模型能否发现缺口，就不要把评审参照中的待确认项提供给模型；若要比较模型能否按已知清单执行，应另行说明任务目标。
评审参照要在查看三种方式的输出之前定稿，避免把模型提出的内容事后误当成“标准答案”。它只需列出本次任务中重要且有依据的条件，不必覆盖所有可能。
如果需求材料包含真实手机号、令牌或其他敏感信息，先脱敏，再用于三组对比。
本篇后续示例统一使用下面这份练习需求。它只用于演示评审方法，不代表线上产品规则或完整的登录测试范围。表中“已给定的练习规则”是三组共同输入；“仍需确认的问题”只供评审者建立参照，不提供给模型：
| 编号 | 已给定的练习规则（共同输入） | 仍需确认的问题（评审参照，不输入模型） |
|---|---|---|
| R-01 | 短信验证码有效期为 5 分钟 | 恰好 300 秒时是否仍有效？ |
| R-02 | 连续输错 5 次后，手机号锁定 15 分钟 | 第 5 次后的响应、锁定解除边界和计数重置方式是什么？ |
| R-03 | 首次成功验证后创建账号 | 失败路径是否可能留下账号或会话状态？ |
提供给三组的需求、上下文和输出要求要保持一致。运行中新提出的疑点先记为本轮发现；下一轮若要更新模型输入，三组都使用同一版；若要更新评审参照，所有评审者都使用同一版。
控制输入，只改变使用方式
准备三组：
- 直接对话：用简短自然语言提出相同的测试任务；
- Prompt：使用前一篇“用 Prompt 做软件测试：让 AI 输出更符合测试需求”中的结构化模板。文章地址：https://inaodeng.com/zh-cn/blog/ai-testing/ai-testing-getting-started/ai-testing-prompt-test-design/。
- Skill：调用一份经过检查的需求分析或测试设计 Skill，并记录其名称、来源、版本、依赖资料与可用工具。
三组都使用同一份需求和上下文资料、同一模型版本与参数，并尽量使用同一个宿主工具及相同工具设置；组间只改变直接对话、Prompt 或 Skill 的指令方式。若工具或设置无法保持一致，应在报告中说明，此时比较的是整套工具配置，不能把差异单独归因于 Prompt 或 Skill。每次从干净会话开始，避免某组继承前一轮的提示。
记录工具、模型、Prompt 或 Skill 的名称与版本、模型参数，以及从任务输入到结果可交付的时间。建议每种方式至少重复运行三次，观察结果是否稳定，而不是只挑最好的一次展示。三次只是初步观察，不能证明统计显著，也不能代表其他需求；如果预算或时间不允许，也要在报告中说明运行次数和限制。
把一次性准备与维护时间、每次运行等待时间，以及人工追问、复核和修改的时间分开记录。若要估算长期复用的收益，还应说明按多少次任务摊分准备和维护成本。
把任务目标和需求材料固定，只改变使用方式。例如三组都要求“列出关键测试场景，标注需求来源、前置条件、预期结果和待确认问题”，但分别用自然语言临时提问、可复用 Prompt 模板，以及一份包含固定工作步骤和输出约定的 Skill 来完成。
同一需求下的输出对照示例
下表是为演示评审重点而编写的示意片段，不是三次真实模型运行结果，不能据此判断哪种方式得分更高：
| 方式 | 示意输出 | 评审时要继续检查什么 |
|---|---|---|
| 直接提问 | “测试验证码有效、过期、连续输错 5 次后的锁定，以及首次成功后的账号创建。” | 检查它是否关联 R-01 至 R-03，区分第 4 次和第 5 次，说明如何准备状态，并标出待确认规则。 |
| Prompt | “R-01：覆盖有效期内和过期输入；恰好 300 秒时是否有效仍需确认。R-02：区分第 4 次和第 5 次错误；第 5 次后的响应、15 分钟锁定的解除时点仍需确认。” | 结构和追溯更明确；仍需核对计数重置、失败副作用、字段是否完整，并确认实际输出是否遵守模板。 |
| Skill | “输入审计：锁定响应与计数重置规则缺失。建议使用可重置的合成手机号，分别验证第 4 次和连续第 5 次错误；保留来源、状态证据和待确认问题。” | 把固定审查步骤、缺失项和证据交接组合起来；要确认 Skill 是否真的按约定调用参考资料、输出可复核字段，并且没有过度限制任务。 |
这些片段展示了三种方式可能呈现的信息：直接提问准备成本低，Prompt 可以固定输出结构，Skill 可以承载重复步骤和边界规则。
不按用例数量给分
| 观察项 | 怎么记录 |
|---|---|
| 关键缺口发现 | 识别出多少条预先标注的重要未知项 |
| 无依据结论 | 把多少未确认规则写成确定事实 |
| 风险覆盖 | 是否触及重要状态、边界、失败路径和副作用 |
| 可执行性 | 前置条件、步骤、结果是否能在项目中落实 |
| 格式合规 | 是否满足约定的输出字段和追溯要求 |
| 结果稳定性 | 多次运行是否反复发现相似的问题，评分波动多大 |
| 人工成本 | 补充对话、审查和修订分别花了多久 |
如果团队想计算比例，要先说明分母是什么。例如“关键缺口召回率”可以按发现的已标注关键缺口除以参考清单中的关键缺口计算。它只衡量这份清单中的内容，不代表所有未知风险都已经被找出。
如果要把完整度也纳入评分，可以先约定每项的判定依据，再让评审者独立打分。例如 0 表示未发现，1 表示提到了但缺少来源或行动条件，2 表示引用依据并说明下一步。无依据结论应单独计数，不能被其他项目的高分抵消。这个刻度只是实验团队可调整的示例，正式运行前要写入评审规则。
最佳实践：让对比结果可复核
- 在查看模型输出前，分别固定三组共同输入和评审者专用的参照清单，记录需求来源、已确认规则与待确认项；不要事后回改评审标准。
- 固定共同任务、输入材料、输出字段和模型设置；保存三种方式实际使用的完整指令、Prompt 模板和 Skill 来源与版本。工具无法统一时，明确结论只能比较整套配置。
- 保存所有运行，包括失败和不完整结果；不要挑选最好的一次代表一种方法。
- 把无依据结论单独计数，不能被格式分或用例数量抵消。
- 评审者先独立打分，再处理分歧；重大分歧未解决时标记未达成一致，不先取平均数。
- 把准备、追问、复核、修订都计入人工成本，并记录版本和运行次数。
- 小样本结果只用于当前任务决策；不要直接推广成“某种方式普遍更好”的结论。
结果需要结合任务解释
如果直接对话很快找到关键问题，而 Prompt 和 Skill 主要改善了格式，简单任务可能不值得承担模板维护成本。若 Skill 减少遗漏和返工，还要计入它依赖的资料和维护成本。三种方式的分数接近时，可以选团队更容易持续使用的方案。
比较时还要留意评审偏差。可以先隐藏结果来源，由两名评审者按同一标准打分，再讨论分歧。把“看起来专业”与“有证据、能执行”分开，避免熟悉某种工具的人天然给它更高评价。
有分歧时，先回到需求和参考清单，记录双方引用的证据，再决定是否补充评分规则。关键缺口的定义仍不一致时，修订清单或标记为未达成一致，不计算平均分。
示例对照：三段示意文本的字段盘点
下表只盘点上文三段由作者编写的示意文本明确包含的内容，不评价三种方法的真实表现。
评审基准中的五个待确认点是：R-01 恰好 300 秒时的处理；R-02 第 5 次输错后的响应、15 分钟锁定的解除时点、错误计数重置方式；R-03 失败路径是否留下账号或会话状态。只有片段明确把未定行为列为待确认，才把它记在对应项下；只提到相关测试场景不算。无依据结论指把未确认行为写成既定规则。表中还记录四个输出字段是否有明确内容：需求来源、前置条件、预期结果、待确认问题。
| 方法 | 片段明确提出的待确认点 | 无依据结论 | 片段提供的字段 | 片段还缺少什么 |
|---|---|---|---|---|
| 直接对话 | 未明确提出 | 未见 | 未提供 | 只列场景名称，没有给出需求来源、前置条件、预期结果或待确认问题。 |
| Prompt | R-01：恰好 300 秒时的处理；R-02：第 5 次后的响应、锁定解除时点 | 未见 | 需求来源（R-01、R-02）；待确认问题 | 没有给出前置条件和预期结果，也没有提到计数重置或失败路径副作用。 |
| Skill | R-02：第 5 次后的锁定响应、计数重置方式 | 未见 | 前置条件（可重置的合成手机号）；待确认问题 | 没有标注需求编号或预期结果，也没有提到 300 秒边界、锁定解除时点和失败路径副作用。 |
不能根据片段提到的缺口数量判断方法优劣：Prompt 示例侧重列出待确认行为，Skill 示例则侧重前置条件、审查步骤和证据留存。稳定性和人工修订成本要通过多轮真实运行记录；这些片段无法提供这两项数据。
重点：把三种方式放进质量循环
每轮对比都要留下可复核的改进动作：
- 固定基线： 保存需求版本、三组共同输入、仅供评审者使用的参照清单、评分规则和模型配置；把已知规则与关键未知项分开记录。
- 独立运行： 直接提问、Prompt 和 Skill 使用同一任务与材料，分别从干净会话开始，保留每次原始输出。
- 盲审输出： 隐去方法名称，按同一标准检查来源追溯、遗漏、无依据结论、可执行性和人工修订时间。
- 归类问题： 判断问题来自需求本身、输入上下文、Prompt/Skill 指令、模型波动还是评审标准；没有证据时先列为待确认。
- 只改一个可解释因素： 例如补一条边界检查、澄清输出字段或更新参考资料，同时记录变更版本和理由。
- 用原样本回归： 对旧样本重新运行，确认已知问题消失且没有新增误报；再加一份未参与调优的新样本，检查是否过拟合。
每轮都保留“输入版本、方法版本、模型/工具、原始输出、人工修订、发现和复核结论”。方法、模型或业务条件变化时，重新建立适用性判断；旧结果只说明它在当时那组条件下的表现。
FAQ：常见问题
Prompt 或 Skill 一定比直接提问好吗？
不一定。重复任务可能更需要结构一致和过程可追溯；一次性、低风险探索可能用直接提问更省成本。要用任务样本判断，不从方法名称推断质量。
一定要每种方式运行三次吗？
三次可以作为初步观察稳定性的起点，但不是通用统计标准。记录实际运行次数，并把结论范围限制在样本、模型和配置所支持的范围内。
评分接近时怎么选？
看任务频率、漏项风险、人工复核成本和维护能力。若质量差异不明确，选择团队能持续使用且维护负担更低的方式，并继续记录质量循环中的失败样本。