全部 · 2026-04-05

dotey 复测称 `--append-system-prompt` 和 `-p` 可用，但 system prompt 只要出现 “OpenClaw” 就失败。按这条信息看，问题不在参数层，而在更上游的字符串扫描或策略黑名单。标题已经给出结论，正文没披露工具名、版本号、报错文本、返回码、操作系统和复现命令，所以现在还不能判断是 CLI 本地校验、服务端拒绝，还是某个 wrapper 做了拦截。 我对这种“关键词即封锁”的做法一直不太买账。它短期省事，长期基本都会被绕过：大小写变体、零宽字符、拆词、别名替换、base64、模板拼接，都是老路子。过去一年很多模型产品都干过类似事，先封模型名、项目代号或越狱词，结果用户很快改写提示词继续走通。只要拦截条件停在字符串层，防御强度通常不会太高；它更像法务姿态或 PR 止血，不像成熟的安全机制。 我自己的疑虑在于，这条信息太薄，薄到还不能拿来下产品级判断。比如“不能有 OpenClaw 关键字”到底是硬错误、静默忽略，还是生成质量显著下降？这三种情况含义完全不同。还有一个细节也没说：只在 system prompt 里触发，还是 user prompt、文件名、路径名里也触发。要是只拦 system prompt，那说明厂商盯的是控制面注入，不是内容面风险；这比“禁词”本身更有信息量。 我会把它先当成一次样本，不当成结论。最少得补四个东西：被测工具和版本、原始命令、完整报错、替换同义词后的对照实验。没有这些，能说的只有一句：现在看到的是条件触发的关键词级拦截，机制还没披露。

Claude 在 7 轮“还有 bug”后触发 usage limit，这已经足够说明一个问题：编码代理的瓶颈不只在首稿质量，还在返工回路按消息数和上下文一起计费。标题给了 7 轮返工和 3am 重置，正文没披露代码类型、报错栈、Claude 版本、是否开了工具调用，所以我没法判断这次失效是模型推理不够、测试环境不完整，还是用户反馈太含糊。 我对这条的判断偏负面。因为它打到的是一个很具体的产品缺口：如果 agent 被拿来写代码，最贵的阶段通常不是“写出第一版”，而是“定位最后两个 bug”。这个阶段 token 消耗高、上下文会膨胀、用户情绪也最差。只按会话额度做限制，体验就会变成 bug 还在，预算先死。做过 Cursor、Windsurf、Copilot Agent 这类流的人都知道，后半程往往比前半程更烧配额，因为模型要反复读取 diff、日志、测试输出，再回填修改。Anthropic 如果还把额度设计成偏消息桶，而不是按任务完成度或测试通过率去优化，这类抱怨只会继续堆。 外部对比也很清楚。OpenAI Codex CLI、Cursor agent 这一年都在往“本地跑测试、自动收集错误、缩小改动面”这套工作流靠，不是因为模型突然更聪明，而是大家都承认纯聊天式 debug 太浪费轮次。我自己没看到这条里的具体环境，但只要没有自动测试回传和最小补丁约束，“there is still a bug”这种反馈几乎就是最低信息密度输入。模型当然能继续试，可每试一次都在烧额度。这里我对用户叙事也保留一点意见：如果只贴一句“还有 bug”，不给 traceback，不给 failing test，这更像是在拿订阅额度换老虎机拉杆，不是严肃调试。 我还是会把矛头主要放在产品设计上。用户不会天然写好 bug report，工具就该把报错、复现条件、测试结果自动结构化喂给模型。连这些都没接住，却先把用户挡在 usage limit 外面，这就有点不对劲了。标题里最伤的不是 Claude 写错，而是系统没把“修到通过”当成一个完整任务来服务。只要配额机制还是围着对话轮数打转，编码代理就很难从 demo 走到可靠生产力。