核心理念
场景驱动。
测试先行。
一个场景 ID 从第一条需求一路追溯到最后一行经过验证的代码。在写下任何一行代码之前，测试就已定义了"完成"。质量成为一个数字——而不是一种感觉。这就是 Harness Engineering 的评估与观测层——被量化落地。
场景之旅
一个 ID。三个阶段。完整可追溯。
跟随场景 S01，从一句话痛点走到自动化验收。
Phase 1 · WHY S01
"用户需要用邮箱注册"
痛点 P01：无法创建账户
验收 GIVEN 有效邮箱 WHEN 提交 THEN 账户创建成功
同一个 S01
Phase 2 · WHAT S01
页面 注册表单 → 成功页
字段 email（必填、格式校验）、password（最少 8 位）
状态 加载中、成功、错误（邮箱重复）
同一个 S01
Phase 3 · HOW S01
Step 1 时序图 → POST /auth/register
Step 2 OpenAPI YAML + users 表 DDL
Step 3 12 个测试用例：UT-S01-001 … ST-S01-012
Step 4 AI 生成业务代码 + 测试代码
Step 5 openlogos verify → Gate 3.5 PASS ✓
不需要追溯矩阵。 场景 ID 本身就是那条追溯线。改了 S01 的某条需求？你立刻就知道哪些 API、测试和代码会受影响。
测试先行方法论
在写代码之前先定义"完成"
这不是传统的 TDD。这是在任何实现之前，先设计整个测试体系。
传统 TDD
写一个测试
↓
写代码让它通过
↓
重构
↓
循环往复（代码级思维）
vs
OpenLogos 测试先行
先设计全部测试用例
↓
单元测试（函数正确性）
场景测试（跨模块流程）
API 编排测试（端到端）
↓
然后 AI 在完整上下文下生成代码
这对 AI 为什么重要？
当你告诉 AI"写一个注册功能"时，它只能猜测"完成"意味着什么。当你告诉 AI"写出能通过这 12 个测试用例（ID 从 UT-S01-001 到 ST-S01-012）的代码"时，它就有了一个精确、可验证的目标。两者的产出质量差距是惊人的。
自动化验证
质量是一个数字，而不是一种感觉
1
运行测试
npm test / pytest —— 任意框架、任意语言
2
捕获结果
OpenLogos reporter 将每条结果写入 test-results.jsonl
3
三层验证
openlogos verify 检查覆盖率、通过率和 AC 可追溯性
PASS
Gate 3.5 —— 验收报告
测试通过率76/76 (100%)
设计期覆盖25/25 断言 ✓
验收标准21/21 AC 已追溯 ✓