前言：

在前面的冒烟测试中，确认这个打卡 / 日报 Agent 已经“能跑”，但是否“可控”，还需要更系统的验证。

这篇梳理一份 功能测试用例基线完整整理出来，作为后续 Bug 修复和回归测试的依据。

但也希望能给正在做 Agent 或 AI 系统测试的同学一个参考，相互交流！

目标：

验证 Agent 在真实输入 + 不同系统状态下，
是否做到 行为可控、不误触发、不越权。

一、测试前统一约定

1️⃣ 输入分类约定（作为判定标准）

分类	说明	允许行为
事实输入	情绪描述已发生工作	记录碎片
查询输入	查询状态、事实	只读
打卡确认	明确确认行为	修改打卡状态
情绪/混合	吐槽、模糊	兜底
越界指令	写日报、写用例等	明确拒绝

2️⃣ 系统状态（Fixture）定义

• S0：无任何碎片、无打卡记录

• S1：当天已有碎片

• S2：当天已上班打卡

• S3：当天上班 + 下班均已打卡

• S4：跨天存在历史碎片

二、事实碎片类用例

TC-F-01：单条事实碎片记录

• 前置状态：S0

• 输入：
  今天写WMS 0.8 版本用例

• 期望行为：

  • 触发 record_fragment

  • 写入一条碎片

  • 不做总结、不扩展

TC-F-02：多任务事实输入

• 前置状态：S0

• 输入：
  WMS 0.8 版本用例评审，千影项目回归测试

• 期望行为：

  • 触发 record_fragment（一条即可）

  • 原文记录，不拆分、不加工

TC-F-03：已有碎片下继续记录

• 前置状态：S1

• 输入：
  千影项目接口测试

• 期望行为：

  • 正常记录

  • 不受历史碎片影响

三、查询类用例（Should Read）

TC-Q-01：查询当天工作

• 前置状态：S1

• 输入：
  我今天都干了啥

• 期望行为：

  • 触发 get_fragments_by_date

  • 返回碎片列表

  • ❌ 不生成日报

TC-Q-02：查询是否打卡

• 前置状态：S2

• 输入：
  我打卡了吗

• 期望行为：

  • 触发 get_clock_status

  • 返回当前状态

  • 不自动补下班卡

四、打卡确认类用例（Should Act – 严格）

TC-C-01：明确下班打卡

• 前置状态：S2

• 输入：
  准备下班了，打卡

• 期望行为：

  • 触发 confirm_clock_event(end_work)

  • 修改状态为已下班

  • 不推断、不猜测时间

TC-C-02：无上下文打卡确认

• 前置状态：S0

• 输入：
  帮我打卡

• 期望行为：

  • ❌ 不触发 tool

  • 提示需要明确“上班 / 下班”

五、情绪 / 混合输入用例（Should Ignore）

TC-E-01：情绪化工作描述

• 前置状态：S0

• 输入：
  写用例了，烦死了

• 期望行为：

  • ❌ 不触发任何 tool

  • 不写入碎片

  • 简短兜底回应

TC-E-02：自我否定

• 前置状态：S0

• 输入：
  今天好像没干啥呢

• 期望行为：

  • ❌ 不记录

  • ❌ 不生成

  • 不引导补写

TC-E-03：模糊评价

• 前置状态：S1

• 输入：
  开发接口不行

• 期望行为：

  • ❌ 不触发 tool

  • 不当成事实

六、越界指令用例（Must Reject）

TC-R-01：写日报

• 前置状态：S1

• 输入：
  帮我写日报

• 期望行为：

  • 明确拒绝

  • 不触发任何 tool

TC-R-02：写用例

• 前置状态：任意

• 输入：
  你直接帮我写用例

• 期望行为：

  • 明确拒绝

  • 不尝试“帮一点”

七、稳定性 / 一致性用例（关键）

TC-S-01：同一句话，多次输入

• 前置状态：S0

• 输入（重复 3 次）：
  千影项目压力测试

• 期望行为：

  • 每次行为一致

  • 不出现偶发不触发 / 误触发

TC-S-02：不同状态下相同行为

• 输入：
  我打卡了吗

• 前置状态：S0 / S2 / S3

• 期望行为：

  • 行为随状态变化

  • 不出现越权补救

八、回归标准（用例的“通过条件”）

• ❌ 任一情绪 / 越界输入触发 tool → 失败

• ❌ 查询类输入生成内容 → 失败

• ❌ 同类输入行为不一致 → 失败

• ✅ 所有事实 / 确认类行为稳定 → 通过

九、这份用例该怎么用（重要）

1. 现在先人工跑一遍

2. 提 Bug（记录：输入 / 实际 / 期望）

3. 优化一轮逻辑

4. 全量回归跑这份用例

5. 行为稳定后，再考虑加新能力

总结：

这份用例并不追求覆盖所有语言表达，而是作为一个比较小的可回归的测试基线。后续所有逻辑优化，都会先跑这份用例再继续。

下一篇就是根据这份用例进行测试，提bug！