企业官网建设流程全解析

WorkBuddy2API 是把腾讯 WorkBuddy 账号变成 OpenAI 兼容 API 的多账号网关。它的系统提示词体系是解决上游"内容误报"的关键：custom模式在出站前用网关自有提示词替换客户端 system/developer 消息，从源头消灭误报；passthrough模式遇到拦截时，则自动执行"拆句 → 搬家 → 中性替换"三层降级重试，以最小代价把请求救活。

为什么会出现"误报"：上游审核是逐字匹配，不是语义

上游内容审核对指纹模板句做逐字精确匹配，而非语义审核。Claude Code、Codex 等 AI CLI 工具会在 system prompt 里注入固定模板句（如You are Claude Code, ...、DeepSeek Harness身份段等）。这些句子原样发到上游，合法请求会被直接拦截：

• 错误码11128/11-128（HTTP 400），文案含blocked by security policy、unapproved channel等；
• 同一句话改一个字就放行——这就是"误报"的本质：不是账号问题，而是模板指纹问题。

网关因此分两层处理：系统提示词体系负责 system 来源的指纹，指纹脱敏层负责 user/assistant/tool_calls 里漏出的指纹。拦截判定见 client.go，脱敏规则清单见 sanitize.go。

三种提示词模式：一个配置决定"替换还是透传"

配置文件中的prompt块控制模式与自定义提示词文件：

{ "prompt": { "mode": "passthrough", "file": "" }

• 模式校验与文本加载：normalizePrompt（非法值会直接报prompt.mode: "..." 不是合法值）
• 替换与追加的核心实现：prompt.Rewrite、prompt.Append
• Web 面板配置页可在线修改（键prompt_mode/prompt_file），保存后热生效：app.js

三层降级重试：从"改动最小"到"改动最大"

在passthrough/append模式下，请求被上游内容策略拦截（ErrContentBlocked）时，网关不罚账号、不轮转账号——换任何账号都会撞同一堵墙。它按顺序做三层抢救，且每层在单请求内各用一次，不会无限重试：

1. 拆句（SplitSystemMessages）：把最长的那条 system 按句界拆成多条 system 消息。文本一字不改、承载通道仍是 system——上游按"连续原文"匹配指纹，句界一断就失配；
2. 搬家（MoveSystemToUser）：拆不动（单句 system）时，把 system 原文搬进首条 user 消息前部，system 换成中性提示词。文本零丢失，只是换了承载通道；
3. 中性替换（Rewrite + Degraded）：整体替换成一句极简中性提示词 "You are a helpful assistant..."，保证不再命中。

三层都被拦，说明用户内容本身触发审核——此时立即把上游原文错误透传回客户端并终止，不再浪费一次健康账号。完整阶梯见 handler.go。

降级期：不再先撞 400，次日 00:00 自动恢复

被拦截抢救过一次后，网关会触发降级状态机：降级期内，该形态的新请求直接按"拆分/搬家/替换"后的形态出站，不再先撞一次 400 再抢救，每请求省一次上游调用；状态在次日 00:00（Asia/Shanghai）自动重置，无需人工干预。实现见 degrade.go。

避坑指南：首条消息必须是 system

还有一个容易踩的隐藏校验：上游要求messages[0]必须是system——首条是user会 40011-128 "first message is not system prompt"，首条是developer会报 "unapproved channel"。真机三组对照实验记录在 system_first_test.go。网关因此统一在出站前兜底补一条 system（已有则零改动）：EnsureSystemFirst。

⚠️ 这条兜底还解释了一个经典故障：passthrough 模式下大量 SDK/手搓 curl 请求不带 system，导致"国际版账号全被禁用、但网页还能聊"（issue #231）——其实只是首条角色不合规，而非账号被封。

相关模块速查 📦

一句话总结：custom替换是"釜底抽薪"，三层降级重试是"最小代价抢救"，两者与指纹脱敏层叠加，构成 WorkBuddy2API 对内容误报的完整防御。