feat: 话题内智能响应判断 + thinking 泄漏修复 + 空输出静默

[lishuceo]

Summary

• 新增 Qwen 语义判断：话题内无 @bot 的消息由小模型判断是否跟 bot 对话，策略为"宁可不回"
• 修复 thinking 标签泄漏：executor resultMessage.result fallback 路径未剥离 + 未闭合标签处理
• direct 模式空输出静默跳过（模型 thinking 后决定不回复时不发"(无输出)"）
• 话题内跳过 quick-ack，避免隐式触发时抢答"收到"

Test plan

• npx vitest run 相关测试通过（thread-relevance 15 tests + executor 33 tests）
• 实际群聊测试：@人类用户时土豆儿不插嘴，闲聊/感叹/自言自语不响应
• 全量测试通过

🤖 Generated with Claude Code

[claude]

Claude finished @lishuceo's task in 3m 16s —— View job

---

PR Review: feat: 话题内智能响应判断 + thinking 泄漏修复 + 空输出静默

• Check previous review comments — no previous comments
• Read changed files and understand context
• Review code for bugs, security, and architecture issues
• Post findings

---

⚠️ Issues Found

Severity	File	Confidence	Description
🟡 warning	src/feishu/event-handler.ts:558	78	Comment says "没有 @任何 bot 或人类" but guard only checks bot IDs; human mentions are handled by Qwen check, not the guard condition

Overall Assessment

Solid PR with well-scoped changes. The four features work together coherently:

1. Thread relevance check (thread-relevance.ts): Clean implementation with proper timeout (2s), fail-safe defaults, and good separation between the API call layer ("宁可不回" on failure) and the parser layer ("宁可多回" on ambiguous responses). The two-tier fallback strategy is explicitly documented in JSDoc — intentional design.

2. Thinking tag leak fix (executor.ts): The two-pass regex approach (closed tags first, then unclosed) is correct and handles edge cases well. Applying the same fix to the resultMessage.result fallback path closes the remaining leak vector.

3. Empty output silent skip (event-handler.ts:sendDirectReply): Correctly catches success: true + empty output after thinking-only responses. The check aligns with executor return types (output: string, non-optional).

4. Thread quick-ack skip: Appropriate — avoids sending "收到" for implicitly triggered responses.

Tests cover parseRelevanceResponse thoroughly (9 cases) and checkThreadRelevance integration with mocked client (6 cases). Architecture follows existing patterns (ESM imports, singleton reuse via getClient(), Pino logging).

One minor inline comment posted about a misleading code comment.

[claude]

Claude finished @lishuceo's task in 1m 34s —— View job

---

PR Review: feat/thread-relevance (re-review after sync)

• Check and resolve previous review comments
• Read changed files and review current diff
• Post findings

---

✅ Approved

1 previous issue fixed — misleading comment about bot vs human @mention guard now accurately describes the logic.

No new issues found (confidence threshold ≥ 75).

Assessment

Clean, well-scoped PR. All four changes work together coherently:

1. Thread relevance (thread-relevance.ts): Proper two-tier default strategy — API-level failures return false (宁可不回), parse-level ambiguity returns true (宁可多回). 2s timeout with Promise.race is appropriate. Reuses getClient() from quick-ack cleanly.

2. Thinking tag leak fix (executor.ts:661-664): The resultMessage.result fallback path now applies the same two-pass regex (closed tags, then unclosed) as the streaming path. Correct.

3. Empty output silent skip (event-handler.ts:1751): result.success && !result.output correctly catches thinking-only responses where output is '' after tag stripping. Avoids sending "(无输出)" for implicit thread responses.

4. Thread quick-ack skip (event-handler.ts:1516): eventThreadId ? null : await generateQuickAck(rawPrompt) — simple and correct. Prevents premature "收到" for thread-bypass triggers.

Tests cover parseRelevanceResponse (9 cases) and checkThreadRelevance integration with mocked client (6 cases). Architecture follows existing patterns (ESM imports, singleton getClient() reuse, Pino logging).

Note: Unable to run npx vitest run or npm run typecheck due to sandbox permissions. Please verify CI passes.