一. 什么是 Specs（需求规范）
在 Harness 体系中，Specs 是一份写给AI Agent 执行的“工程合同”。它严格遵循“意图与实现分离”的原则，只规定业务边界与验收标准，绝不干涉底层技术实现。
一份合格的 Specs 必须具备三大特征：：1.意图与实现分离：只描述“做什么（What）”，不规定“怎么做（How）”。2.强约束词汇：使用 SHALL（强制）、SHOULD（推荐）、MAY（可选）等严格词汇，并分配唯一编号（如 R-xxx），杜绝模糊表达。3.结构化场景（GWT 格式）：采用 Given-When-Then 格式定义验收场景，实现“需求即测试”，将自然语言零成本转化为 AI 可执行的自动化测试用例。
- 通俗一点的解释就是
AI 有时会混淆我们想要让它实现的功能，比如让它实现一个登录功能，它可能给你搞个“输密码登录”，也可能给你搞个“刷脸登录”，甚至可能把密码存成明文。而Specs 就是你写给他的“任务说明书”，它不教他怎么写代码（那是他的事），它只告诉他：
1.要干啥（比如：必须支持手机号登录）。
2.不能干啥（比如：密码绝对不能存明文）。
3.干成啥样算完（比如：输错5次必须锁号30分钟）。
一句话总结：Specs 就是给 AI 下的“死命令”和“验收标准”。
二. 在 Harness 创建 Specs 需求规范
将理论付诸实践，关键在于建立一个标准化的工作流。在实际工作中，你可以通过以下四个步骤，将 Harness 架构中的 Specs 理念落地。
这个流程的核心是：你负责定义“做什么”（What）和验收标准，AI 负责“怎么做”（How）和具体执行。
1.第一步：意图提出
这是流程的起点，作为业务专家，你的任务是用最清晰、简洁的语言，向 AI 描述你的业务需求。不必纠结于技术细节，专注于业务目标本身。
- 你的角色：产品经理 / 业务负责人，定义“做什么”（What）。
- 操作：向 AI 发送指令。
- 示例提示词：
“我需要验证 Android 手机‘多用户环境下的独立拨号功能’。
测试流程如下：
1.进入系统设置，打开‘多用户’功能。
2.成功创建一个新的用户，并切换到该新用户环境。
3.在新用户环境中，打开拨号盘并成功拨打一个测试号码。
测试验收标准：
这是一个强依赖的串行测试链路。在执行过程中，如果上述任何一个环节（如：无法进入设置、创建用户失败、切换失败、或新用户下无法拨号）出现异常，整个测试脚本必须立即判定为FAIL，并停止后续步骤。”
2.第二步：规格生成
现在，你需要引导 AI 将你模糊的测试想法，转化为一结构化的、机器可读的 Specs 文档。你可以直接让 AI 按照特定的格式来生成。
- 你的角色：指令发出者
- 操作：给 AI 下达更具体的指令，要求它生成 Specs。
- 示例提示词：
请根据如下需求，为我生成一份测试 Specs 文档：
1.使用 Markdown 格式。
2.包含 Requirements（需求）和 Scenarios（场景）两个部分。
3.需求使用 R-xxx 编号，并用 SHALL 等强约束词描述。
4.场景使用 Given-When-Then (GWT) 格式，覆盖正常和异常情况。”AI 会生成类似下面的文档：
### 多用户环境独立拨号功能测试 (Multi-User Dialer Test)#### Requirements-R-001:系统**SHALL**支持在系统设置中开启多用户功能并成功创建新用户。-R-002:系统**SHALL**支持从主用户无缝切换至新创建的用户环境。-R-003:系统**SHALL**支持在新用户环境下独立调用拨号盘并成功发起通话。-R-004:测试链路**SHALL**具备强依赖的串行执行机制（Fail-Fast）。若前置步骤失败，系统**SHALL**立即终止后续步骤并判定整体测试为 FAIL。#### Scenarios-S-001:完整链路成功-**Given**一台支持多用户功能的 Android 测试手机-**When**依次执行：进入设置开启多用户->创建新用户并切换->在新用户下拨打测试号码-**Then**所有步骤**SHALL**成功执行，通话正常接通，整体测试判定为 PASS。-S-002:前置环节失败触发快速终止-**Given**一台支持多用户功能的 Android 测试手机-**When**执行“创建新用户”步骤时发生异常（如创建失败或切换失败）-**Then**系统**SHALL**立即停止执行“拨打电话”步骤，整体测试判定为 FAIL，并记录失败节点。- Given: 初始状态
- When： 动作
- Then预期结构
第三步：规格审查
这是整个流程中最关键的一步，也是作为人类测试工程师的核心价值所在。你的任务不是写自动化脚本，而是像一个严格的法官一样审查 AI 生成的“测试合同”（Specs）。
- 你的角色：质量守门员
- 操作：仔细检查 Specs 文档，确认测试逻辑是否完整、边界条件是否清晰。
- 审查要点：
- 逻辑完整性校验：核对 AI 生成的文档是否准确捕捉了核心测试策略。例如，确认 AI 是否将提出的“任何环节失败即判定失败”的业务要求，精准转化为带有强约束词（SHALL）的“Fail-Fast（快速失败）”机制（如 R-004）。
- 边界与异常场景补全：识别 AI 容易遗漏的隐性需求或极端异常场景（如设备不支持该功能、缺少硬件依赖等），并要求 AI 补充相应的 GWT 测试场景（如新增 S-003 无 SIM 卡场景），确保测试覆盖无死角。
- 意图准确性对齐：严格审查 Given-When-Then 场景的描述，确保其逻辑走向与预期结果完全符合测试意图，避免 AI 产生理解偏差。
与AI交互举例
“S-002 场景很好。但请再补充一个 S-003 场景：当手机未插入 SIM 卡时，进入新用户拨打测试号码，系统应该提示‘无 SIM 卡’或拨号失败，此时测试应判定为 FAIL 并记录原因。”
经过几轮这样的审查和修正，你最终会得到一份你完全认可的、作为“最终合同”的 Specs 文档。
第四步：AI 执行与验证
Specs 一旦定稿，就成为了 AI 的行动纲领。现在，你可以命令 AI 开始编写自动化测试脚本。
你的角色：项目验收官
操作：将最终版的 Specs 文档交给 AI，并下达执行指令。
示例提示词：
Specs 已确认。请严格按照这份文档编写自动化测试脚本（如使用 Appium 或 Uiautomator2）。必须实现 R-004 的 Fail-Fast 机制。完成后，在测试机上运行脚本并向我报告执行结果。”
AI 会开始工作,结束后会生成测试报告，这时候就需要查看测试报告，确实自动化脚本是否符合预期