Best Minds Board · Private Review
Snapshot · 2026-03-11
OpenClaw · Feishu · UX Governance
OpenClaw × Feishu 403 体验治理复盘：
从“丢响应”到“按群柔性降级”
这轮修复真正改变的不是某个模型能不能跑，而是整条链路的成功定义：从“AI 成功才算成功”，切换成“链接先入账、群内体验先收敛、AI 结果可延后补跑”。
截至 2026 年 3 月 11 日，统一主表、历史补齐、无 AI 保底入账、信息获取群软化回执、以及跨群 403 降级文案都已落地；剩余的关键动作只剩一轮真实 Feishu 群 smoke test。
Project MINE/openclaw-feishu-ux-retro
Category workflow
Tags OpenClaw · Feishu · 403 · UX · 飞书表格
Summary 链接先保底入账，错误按群柔性降级
Original Goals
5
统一主表、历史回填、无 AI 保底、柔和回执、减少原始错误外露。
Root Causes
4
表结构混乱、ACK 通路失效、主链路错误透传、缺少按群降级策略。
Patched Layers
5
配置、回填脚本、message-log hook、可读表结构、OpenClaw reply pipeline。
Remaining Gate
1
还差一轮真实 Feishu 群端到端验收，确认群内最终文案与表格状态一致。
Best Minds
这次最值得听的不是“谁最懂 OpenClaw”，而是谁最懂“故障时的用户体验”和“系统退化策略”。
Don Norman
系统不该把内部故障直接甩给用户。用户真正关心的是：我的内容有没有被接住？下一步要不要我处理？
Charity Majors
原始 provider 报错应该进入日志、指标和运维面；业务群里应该展示的是业务状态，而不是底层错误原文。
Steve Krug
群消息必须“一眼就懂”。最好的提示只回答三件事：收到了没、现在做到哪、我要不要动作。
所以这轮最关键的设计决策是：把成功标准从“AI 一次性完成”改成“先留痕，再补处理”。这就是为什么表格保底、友好 ACK、以及按群文案分层，比单纯修模型更重要。
What Changed
最初目标与当前状态对照
最初目标
- 信息获取群里，用户发了链接，系统要自动处理或至少自动记录。
- 即使模型欠费或额度不足，每条链接也必须先进同一张总表。
- 历史刚发的几条以及后续新增内容，要补回统一账本。
- 群里不要再回生硬的 403 / 欠费 / 购买链接。
- 表格要人能看懂，能按日期、状态、备注判断发生了什么。
当前状态
- 已完成 统一主表已固定，不再漂移到语义误判的其它表。
- 已完成 历史记录已重建为可读 schema，日期与状态可直接查看。
- 已完成 无 AI 保底写表已落地，欠费时会写“待补提取”备注。
- 已完成 信息获取群主链路 403 已改为静默，由柔和 ACK 承担用户可见反馈。
- 待验收 跨群软化文案已打到 reply pipeline，但还差真实群消息 smoke test。
Principles
这轮治理真正成立，靠的是四个清晰原则，而不是一堆零散 patch。
要点 1 · 先留痕，再谈 AI
先保证链接、消息 ID、时间、来源群进账本；AI 摘要和相关链接只是后续 enrichment。
要点 2 · 用户看业务状态，不看 provider 错误
群里展示“已入账 / 待补提取”，日志里保留真正的 403 / billing / rate-limit 原文。
要点 3 · 同一件事，只允许一个主账本
这轮不是“再造一张表”，而是明确：这个群的所有记录都应该被 pin 到同一张全局主表。
要点 4 · 体验分层必须按群来做
同样的底层错误，在信息获取群、自媒体群、运维私聊里应该是三种完全不同的用户体验。
Visual Diagnostics
把这轮治理拆成五张诊断小图：状态、拥塞、剩余工作、反馈回路与验收路径。
症状 → 治理 → 验收
不同群，对错误的耐受度不同
入账、回执、历史、降级、验收
每层各做一件事
最后一环：真实群验收
Timeline
从 2026-03-06 到 2026-03-11 的关键推进节点
2026-03-06
开始出现“看不到今天记录”和“跑去别的表”
日志显示同一个群的 URL 写入曾被语义复用到另一张表；同时表内存在 7 列可读区 + 25 列账本尾区混排，导致“其实写进去了，但肉眼看不到”。
2026-03-09
用户反馈升级：没回复、没日期、不是那张表
问题从“单次写表异常”升级成“系统成功定义错误”：只要 AI 失败，用户主观感受就是整件事失败。
2026-03-10 上午
统一主表 + 可读回填完成
主表被固定到同一 URL，回填脚本重写为人类可读 schema，并把历史记录重建进统一账本。
2026-03-10 下午
信息获取群无 AI 保底 + 柔和 ACK 完成
message-log hook 改成直接用 Feishu API 回 ACK；额度不足时写“已入账｜待 AI 补提取”，而不是原始 provider 文案。
2026-03-11
跨群 403 文案分层治理完成
把 OpenClaw reply pipeline 本身也补上“按群降级”逻辑：业务群隐藏 403、协作群降级说明、DM 保留结构化 FAILED。
Root Causes
不是一个 bug，而是四层设计同时漏水。
1. 表格层
症状：用户说“没有今天的日期”。
真实原因：同一张表里混了可读行与 25 列 canonical ledger 尾区，后者视觉上像“消失了”。
2. 选表层
症状：有时会写到另一张相似语义的表。
真实原因：早期依赖语义复用候选，未对这个群显式 pin 到同一张总表。
3. ACK 通路层
症状：用户发链接后“像是没反应”。
真实原因：旧 ACK 走 openclaw message send，但配置校验导致发送失败，用户看不到“已入账”的反馈。
4. Reply Pipeline 层
症状：群里直接冒出生硬 403 / 欠费文案。
真实原因：OpenClaw 主链路会把 assistant billing / rate-limit error 直接格式化成用户可见回复，没有业务群分层策略。
System Shift
真正的架构变化：从“AI-first”切到“ledger-first”。
这就是本次复盘最重要的结构变化：任何链接先入账，再决定 AI 是否同步完成。
What We Patched
配置层、日志层、表格层、回复层同时补齐。
配置层
把信息获取群默认主表固定到同一张总账本，关闭 mention 依赖，并把 ACK 前缀统一成“已入全局账本”。
回填脚本层
把历史重建脚本改为人类可读 schema：平台 / 原文链接 / 预览相关链接 / 标题主题 / 摘要 / 关键词 / 状态 / 可信度 / 采集时间 / 备注 / 消息 ID / 来源群 / 发送者。
message-log hook 层
修 URL 提取、用 Feishu Open API 直接发 ACK、欠费时落“待 AI 补提取”状态和备注。
表格层
重建统一主表，清理掉混在尾部的难读 canonical row，让用户按日期和状态就能看懂。
reply pipeline 层
把 OpenClaw 主链路原本直接对用户显示的 403 / billing / rate-limit 错误，改成按群分层的柔性文案，并加入 6 小时去重。
Per Group UX
同样是“模型有问题”，但不同群应该看见完全不同的话。
| 群/场景 |
之前 |
现在 |
设计原则 |
信息获取群
业务群 / 链接处理 |
可能看到原始 403，或像“没有回复”。 |
主错误静默 + ACK 显示“已入全局账本 / 待补提取”。 |
用户只需知道：链接已接住。 |
actions tips
协作群 / 动作建议 |
原始 403 打断讨论节奏。 |
软化为“本次先保留上下文，AI 总结待补”。 |
给状态，但不把 provider 细节抛给群友。 |
自媒体
内容工作台 |
失败文案像“系统崩了”。 |
软化为“选题与来源已保留，标题/正文待补生成”。 |
围绕“今天能不能发”来讲状态。 |
🎶 新专辑
创作群 |
技术错误直喷，体验很硬。 |
软化为“灵感已记录，歌词/风格建议待补生成”。 |
先保护创作节奏，再谈系统状态。 |
| 私聊 / 运维 |
原始 403 或笼统失败。 |
保留 FAILED，但改成结构化人话：影响 / 下一步。 |
这里只有运维才需要更透明的失败说明。 |
Scoreboard
“实现了多少”需要拆成两个维度：工程落地度 和 真实验收度。
这 88% 不是“代码写了 88%”，而是“系统行为在真实用户体验上闭环了 88%”。剩下的 12% 主要不是改代码，而是做一次真实群验收，确认群里看到的最后一句话与你想要的完全一致。
Risks
还没完全收口的地方，主要集中在“验证”而不是“设计”。
Risk 1 · Live 验收缺口
中风险
按群软化 403 已进入 reply pipeline，但尚未针对每个目标群各发 1 条真实消息完成 smoke test。
Risk 2 · Dist Patch 可升级性
中风险
本轮对 OpenClaw 已安装 dist 做了手术式 patch；未来升级 OpenClaw 后，需把这套策略迁回正式源码或重新补丁。
Risk 3 · Quota 检测仍偏启发式
中风险
message-log hook 的“额度不足”判断仍主要依赖近期日志特征，还不是 per-message 强绑定。
Files
这轮真正改变行为的关键文件
- ~/.openclaw/openclaw.json：主表固定、ACK 前缀、目标群无需 mention。
- ~/.openclaw/hooks/message-log/handler.js：URL 提取、可读写表、Feishu API ACK、待补提取备注。
- scripts/openclaw/feishu-url-ledger-backfill.mjs：历史账本重建为人类可读结构。
- /opt/homebrew/lib/node_modules/openclaw/dist/subagent-registry-*.js：主 reply pipeline 新增按群软化错误逻辑。
- /opt/homebrew/lib/node_modules/openclaw/dist/reply-*.js：并行构建产物同步 patch，避免入口不一致。
- tmp/_codex/openclaw/url-ledger-backfill/runs/2026-03-10T03-54-59-123Z.json：历史回填执行记录。