飞书长回复阈值验证

• HTML: https://decision.ht1072.top/2026-05-24-feishu-long-reply-guard-test.html
• Local HTML: [已移除本地路径]
• Generated: 2026-05-24T18:47:17+08:00

结论：飞书长回复不应该继续直接承载完整分析。当前采用“短飞书入口 + rich HTML + wiki Markdown + Hindsight retain pointer”的四层策略，并设置 700 中文字 / 约 1200 字符的飞书回复阈值。

结论

推荐继续使用 skill 阈值规则作为第一阶段控制，不立即修改 gateway。原因是 gateway 是所有飞书回复出口，直接改动会影响普通聊天、工具回执和 cron delivery；而 skill 阈值 + publisher 工具链已经能覆盖决策型长内容的主要场景。

推荐方案

• 飞书内只放短结论、路径和链接。
• 超过 700 中文字或约 1200 字符时，必须改走 HTML + wiki + retain。
• 决策型内容默认调用 decision_trace_publish.py --retain。
• 普通完成回执控制在 3-5 行。
• 如果后续仍出现 1-2 次截断，再把规则升级到 gateway guard。

证据 / 验证

• 飞书此前多次出现长 Markdown 回复后半截不可见。
• rich HTML 页面已验证 HTTP 200，并包含 topnav、关键洞察、方案对比、证据时间线、行动清单、风险矩阵等结构。
• Hindsight retain pointer 已验证能通过“共享记忆方案”“不要同步 state.db”等关键词召回。
• skill 和 wiki 都已写入阈值规则，后续可追溯。

下一步

1. 继续观察 3-5 次实际决策型回复。
2. 若短入口 + HTML 链接稳定，就保持 skill 层控制。
3. 若仍有截断，则设计 gateway guard 开关。
4. gateway guard 必须支持 fallback，不能阻断普通飞书回复。

风险 / 边界

• 不应把所有稍长回复都自动 HTML 化，否则会让普通对话变重。
• 不应把整篇 HTML/CSS retain 到 Hindsight，只 retain pointer 和摘要。
• 不应在未验证稳定前修改 gateway 主链路。
• 工具失败时，必须短消息说明失败原因，而不是继续长发。