二创仓库对上游 MCP/CLI 的版本耦合与升级风险

风险描述

把"平台操作"完全留给上游 MCP 或 CLI 后，二创仓库的所有能力都建立在"上游接口不变、上游能登录"的前提上。一旦上游发生以下变化，下游可能直接不可用或行为偏移：

• 上游仓库改版：接口路径、参数、返回结构改变
• 上游被平台风控升级波及：登录方式、Cookie 处理、User-Agent 校验变化
• 上游停止维护：issue 累积、安全更新缺失
• 上游分支策略变化：原本依赖的 tag 或分支被删除

在 SRC-DEV-008 中的具体表现

YYH211 的仓库在 README 中明确要求"先运行上游小红书 MCP 项目"，并将"记录上游版本与本项目改动"作为官方操作流程之一。这本身就是承认：上游版本变化会直接影响本项目。

检查点与缓解

• 在 README 与配置中固定上游版本（或上游 commit hash），不要默认跟踪 main 分支。
• 维护一份"上游版本 vs 本项目改动"对照表，每次升级上游都跑一遍端到端冒烟。
• 关键功能加监控：登录态失效、发布失败率上升、平台返回结构变化时立即报警。
• 在 Web 界面或日志中清晰显示"上游版本 / 上游健康状态"，便于人工判断。
• 预留"上游不可用时的降级方案"，例如暂停批量、人工接管。

与其他风险的关系

• 与 xiaohongshu-mcp 类工具的账号风控、Cookie 与凭证风险 互为表里：账号风控往往先在上游体现，再传导到下游。
• 与 在开源 MCP/命令行工具上做 GitHub 二创：复用上游 + 增加检索/生成/UI 互补：该方法本身已经包含"记录上游版本"的步骤，但真正落地时仍需具体执行。

适用对象

• 所有在已有 MCP/CLI 之上做二创的仓库。
• 把多个下游产品建立在同一个上游之上的生态维护者。