不是所有消息都需要智能#

群聊机器人接到的请求大致可以分成两类。

第一类是确定性查询：

• 查文件索引。
• 查最近记忆。
• 查知识库摘要。
• 查任务清单。
• 查工作区信息。
• 查健康检查结果。

第二类才是开放任务：

• 帮我整理这段材料。
• 帮我判断这个方案。
• 根据上下文写一份回复。
• 分析一个失败原因。

这两类请求不该共用同一个入口。第一类请求通常知道该去哪查、该回什么格式、哪些内容不能碰。直接丢给模型，反而多了一层猜测。

只读命令层的价值#

只读命令层听起来不如模型推理酷，但它解决的是群聊工具的基本可靠性。

比如 /files find 只需要查本地索引，返回路径、标题和摘要。/knowledge summary 只需要读取工作区里的知识文档。/tasks list 只需要列出已记录的任务。/health-codex-feishu 只需要调用一组健康检查脚本并汇总结果。

这些命令答得对不对，主要看它有没有查到当前状态，不看它会不会组织语言。

如果模型参与太早，它可能会把不存在的文件说得像真的，把过期记忆说成当前事实，或者用一段漂亮解释掩盖索引根本没刷新。只读脚本不会让答案变得更聪明，但会让答案更可核对。

命令返回要短#

群聊不是终端窗口，返回内容必须短。

codex-feishu 的命令层会限制输出长度，只展示前几条结果，并把摘要压到能在聊天窗口里读完的范围。这一点比功能完整更重要。

如果一次 /files find 返回几百行，用户不会觉得机器人强大，只会觉得它把群聊刷屏了。更好的做法是返回少量高相关条目，让用户继续追问或切到更适合的界面。

我现在写聊天命令时，会默认问三个问题：

1. 这个命令是否可以在 1 到 2 屏内读完。
2. 每一条结果能否追溯到真实文件或状态。
3. 失败时是否能说清楚是索引缺失、输入为空，还是脚本执行失败。

这三个问题比“要不要加更多字段”更实际。

先做禁止项#

只读命令层还有一个好处：安全范围更容易写死。

例如命令参数里不允许覆盖工作区根目录，不允许把 --root 之类的选项从聊天里传进脚本。写命令解析时，先处理禁止项，比后面靠模型判断“这是不是危险请求”可靠得多。

我更愿意把聊天命令分成三档：

• 只读查询：可以直接执行。
• 低风险结构化写入：需要明确字段，缺字段就追问。
• 文件、脚本、部署、删除这类高风险动作：别在轻量命令层直接执行。

这个分层不复杂，但能避免群聊机器人变成一个谁都能随手触发的远程 shell。

健康检查也应该是命令#

很多机器人系统出问题时，用户只会看到“没回复”或“答得不对”。这太晚了。

我更喜欢把健康检查做成可以从群聊触发的只读命令。它不需要解释所有内部细节，只需要告诉用户几个关键模块是不是正常：

• manifest 是否可读。
• help 文档是否存在。
• 文件索引是否健康。
• 记忆目录是否健康。
• 运行日志是否通过脱敏检查。

这种健康命令主要给维护者做第一层体检，不是给最终用户看的华丽面板。它能快速判断问题在入口、索引、记忆、文件还是日志。

运行记录要脱敏#

只读命令虽然不改文件、不改任务，但每次调用还是会留下日志。记录命令名、耗时、结果数量是值得记的；记录原始私聊内容、真实标识和密钥就很危险。

所以命令层应该只留下足够排查问题的信息，例如：

• 命令类型。
• 查询文本的长度和短哈希。
• 是否成功。
• 返回数量。
• 执行耗时。

这样维护时能看到“最近是不是有大量查询失败”，但不会把用户消息原文复制到日志里。

模型应该站在命令之后#

有了只读命令层，并不意味着模型不重要。

相反，模型应该站在更适合它的位置：处理开放问题、跨材料归纳、生成文本、做复杂判断。它可以读取只读命令返回的事实，也可以在事实不足时要求用户补充，但它不该替代每一个状态查询。

一个更稳的群聊助手链路应该是：

1
消息 -> 命令解析 -> 只读查询 / 低风险结构化动作 -> 开放任务再交给模型

这样模型拿到的是已经查过一轮的结果，不用自己去猜本地到底有什么。

能查清楚的先查清楚#

群聊机器人不需要每件事都显得很智能。

文件、记忆、知识库、任务和健康检查这些问题，先做成只读命令，实际跑起来会省很多麻烦：回复快，花费低，出问题也容易查。

对我来说，codex-feishu 的命令层最重要的经验就是：能查清楚的事，先查清楚；只有查不清、需要判断和表达的部分，才交给模型。