场景驱动 + 测试先行
场景驱动 + 测试先行是 OpenLogos 中最关键的原则。它通过结合两种互补的策略来保证准确性、可靠性和可维护性：
- 场景驱动：每个功能都被拆解为离散的场景（
S01、S02…），从需求经设计一路追溯到实现。 - 测试先行：针对每个场景，在编写代码之前就设计出完整的测试套件，为 AI 提供「完成」的精确定义。
单个场景 ID（S01）贯穿全部三个阶段 —— 无需追溯矩阵，因为这个 ID 本身就是那条追溯链：
| 阶段 | S01 在此获得什么 |
|---|---|
| Phase 1 · WHY | 痛点、验收标准（GIVEN/WHEN/THEN） |
| Phase 2 · WHAT | 交互规格、页面流程、原型 |
| Phase 3 · HOW | 时序图 → API → 测试用例（UT-S01-001 …）→ 经过验证的代码 |
要改动 S01 的某条需求？你能精确知道哪些 API、测试和代码会受到影响。
面向 AI 的测试先行
Section titled “面向 AI 的测试先行”这不是传统的 TDD（写一个测试 → 写代码 → 重构）。OpenLogos 是先设计整个测试系统：
| 层次 | 范围 | 示例 |
|---|---|---|
| 单元测试（UT） | 函数正确性 | UT-S01-001：用户名至少 2 个字符 |
| 场景测试（ST） | 跨模块集成 | ST-S01-001：完整的注册 → 任务查看 |
| 编排测试（OT） | 端到端 API 流程 | OT-S01-001：注册 → 登录 → 创建任务 |
然后 AI 在一个精确、可验证的目标下生成代码 —— 是「通过这 12 个带特定 ID 的测试用例」，而非含糊的「构建一个登录功能」。
为什么这很重要
Section titled “为什么这很重要”当你告诉 AI「写一个注册功能」时，它只能猜测「完成」意味着什么。当你告诉 AI「写出能通过 UT-S01-001 到 ST-S01-012 的代码」时，它就有了一个精确、可验证的目标。两者的输出质量差异非常显著。
openlogos verify三层验证检查：
| 检查项 | 描述 |
|---|---|
| 通过率 | 全部测试通过 |
| 设计时覆盖率 | 每个已定义的测试用例都被执行 |
| AC 可追溯性 | 需求 → 测试用例 → 结果相互关联 |
最终产出是一份 Gate 3.5 验收报告 —— 质量是一个数字，而非一种感觉。
测试 ID 命名约定
Section titled “测试 ID 命名约定”{type}-S{scenario}-{number}- Type（类型）：
UT（单元）、ST（场景）、OT（编排） - Scenario（场景）：两位数字的场景编号（
S01、S02…） - Number（序号）：场景内的顺序编号（
001、002…）
所有测试结果均以 JSONL 格式上报。规格详见 测试结果格式。