Data Query Integrity

数据查询完整性强制检查。API查询/汇总/统计任务必执行。校验has_more、分页完整性、禁止脑补。

数据查询完整性强制检查

触发条件

当任务涉及以下任一场景时，必须执行本 Skill 的全部流程：

• 调用飞书日历、文档、多维表格等 API 查询数据
• 对查询结果进行汇总、统计、分类
• 向用户输出基于 API 返回的数据列表

强制流程（不可跳过）

Step 1: 查询前 — 拆分范围

• 日历查询超过 3 天：按天分段，每天独立查询
• 列表类查询预估可能超上限：主动分页
• 记录计划查询的时间段和分段策略

Step 2: 查询后 — 完整性校验（每次查询后立即执行）

逐条检查以下项目，全部通过才能使用数据：

1. has_more 检查

   • has_more: false → ✅ 数据完整
   • has_more: true → ❌ 必须用 page_token 继续分页，直到 has_more: false
   • 响应中无 has_more 字段 → ⚠️ 数据可能被截断，缩小范围重查

2. error 检查

   • 响应包含 error 字段 → ❌ 查询失败，告知用户并重试
   • 超时/网关错误 → 缩小范围重试，不得用部分数据凑数

3. 数据量合理性检查

   • 返回条数为 0 → 确认查询条件是否正确
   • 返回条数异常少（相比预期）→ 标记"数据可能不完整"

Step 3: 输出前 — 逐条溯源

对将要输出的每一条记录：

• 确认该记录的每个关键字段（人名、职位、时间等）能在原始 API 返回中找到精确匹配
• 找不到 → 不输出该条，不得推测补全
• 如果任何字段是推断/补全的 → 标记为"[数据缺失]"

Step 4: 输出时 — 声明数据来源

在汇总结果开头或结尾，必须包含：

• 执行了几次 API 查询
• 每次查询的 has_more 状态
• 如有任何数据不完整，明确告知用户"以下数据可能不完整"及缺失范围

Step 5: 数据转换 — 工具验证（不可心算）

当输出涉及以下转换时，必须用工具验证，禁止心算/推算：

• 日期 → 星期几：用 date -d "YYYY-MM-DD" +%A 或等效方式确认
• 时区转换：用工具计算，不手动换算
• 时间戳 → 可读时间：用工具转换，不凭记忆推算

验证方式：在输出前用 exec 执行日期命令确认，或将原始日期值原样输出并标注格式。

真实教训：API 返回 2026-06-15T14:30:00+08:00，心算得出"周日"，实际是周一。数据有来源，但转换出错。

绝对禁止

• ❌ 在 API 返回中找不到的人名/职位/数据，不得出现在输出中
• ❌ 不得因为"看起来应该有"而补全数据
• ❌ 不得用推测填充截断后的数据空白
• ❌ 不得在 has_more: true 时停止分页就直接输出
• ❌ 不得心算日期→星期、时区转换等计算，必须用工具验证

违规自检

输出前问自己：

"这条记录的每个字段，我都能在 API 返回的 JSON 中找到原文吗？"

如果有任何一条回答"不能" → 删除该条，不得输出。