一. 什么是 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 会开始工作,结束后会生成测试报告这时候就需要查看测试报告确实自动化脚本是否符合预期