加载失败
一位作者检查了 Claude Code（Anthropic 推出的本地客户端/工具）的本地二进制文件，发现代码中存在用于在不同用户或模式中切换行为的静默 A/B 测试机制（例如注入不同 prompt 或改变功能表现）。讨论围绕两大焦点展开：其一是这种在输出层或核心功能上做实验对专业可重复性和交付可靠性的影响；其二是厂商条款（ToS）与反向工程限制对透明度与治理的作用。评论者在是否可接受、是否能通过工程手段缓解、以及是否应转向更开放/自托管方案上分歧明显；同时有人提醒这是 SaaS 常见的商业实践，但也有呼吁明确的部署 hooks 和更高透明度。相关参照还包括 opencode（更开放的替代品）和 Copilot（GitHub/Microsoft 的开发者助理）等用户迁移或比较案例。
部分评论者强调专业工具应当产生可靠且可复现的结果，认为 LLM 输出的随机性与静默 A/B 测试直接侵蚀了这一前提。评论中区分了界面级的 A/B 实验与在模型输出层做变体的严重性，后者会在相同输入下产生不同的“最终文件”，有人以 Photoshop 在文件里悄悄改变颜色作为类比来说明问题的严重性。有人因此不愿把 LLM 输出直接当作关键业务交付物，但也有评论指出可以通过评估套件与严格的 prompt control 把可复现性逼近确定性。还有观点提醒：任何会自动更新的工具行为都会变化，专业人士需理解并管理工具的变动性，否则不应盲目依赖生成结果。
有人把焦点放在服务条款和透明度上，指出条款第6.b节允许厂商随时更改订阅内容，第3.3节则禁止对服务进行反编译或逆向工程，这被用来解释厂商有权在不同用户或分段上调整功能。对此有人担忧这类条款会阻碍对软件行为的监督与治理，并质疑平台在大规模处理用户内容时的道德与透明度问题。也有评论澄清这次发现来自本地磁盘上的二进制文件，而非直接对线上服务的逆向工程，提醒法律适用取决于“服务”如何被定义。部分用户因此呼吁更透明的部署模型（比如支持 hooks）或自托管选项，以避免被动接受厂商单方面的静默改变。
[来源1] [来源2] [来源3] [来源4] [来源5] [来源6]
另一类评论认为在 SaaS 与互联网产品中对用户做分组实验本就是常态，对厂商在产品中做 A/B 测试并不感到惊讶。支持者指出早在 LLM 广泛使用前，界面、引导流程和定价的 A/B 实验就很普遍，甚至游戏会针对新手做强弱调整以提高留存。从这个视角看，关键不是是否做实验，而是实验是否合规且有透明度；商业现实也意味着高价订阅并不必然能阻止厂商做变动或寻求成本优化。有人同时提出商业动机问题（例如高价订阅可能并不盈利），提醒用户“你是产品”的风险。
评论中有明确的技术区分：一方面存在模型本身的非确定性（nondeterminism），另一方面还有厂商有意部署的 A/B 实验，两者需分开讨论。有人指出可复现性是一个光谱，通过构建评估套件（eval harnessing）与严格的提示控制可以显著降低输出波动，在许多业务场景可达到足够稳定的结果。也有观点把 LLM 类比为更像人的助手而非传统确定性机器，认为不可预期性部分是本质属性但应在关键任务上慎重对待。总体上评论提出既要识别两类问题的不同根源，也要讨论可行的工程和流程性缓解手段。
一些用户基于可控性与透明度的考虑选择离开 Claude Code，转向更开放或可控的替代品，理由包括对“vibes”或默认行为不满以及不能控制诸如 web search 去向等细节。评论中有人直言希望软件实现一组固定功能、不随意改变且收费透明，因此更倾向于开源或自托管方案。也有简短的共识式表述：你租用 AI 而不是拥有它，这意味着厂商更新与实验可能会影响付费用户的体验。因此，用户层面的回应既表现为抱怨，也有明确的迁移与功能请求（如 hooks）以争取更大控制权。
A/B testing（A/B 测试）: 同时向不同用户展示不同版本以评估效果的实验方法；讨论中强调区别界面层的 A/B 测试与在模型输出层做变体，后者会改变相同输入的最终结果。
Terms of Service (ToS)（服务条款）: 软件或服务的法律协议，常包含保留修改功能与禁止逆向工程的条款；在本讨论中被引用来说明厂商可更改订阅内容并限制对软件的审查。
reverse engineering / decompile（反向工程 / 反编译）: 把二进制或封装程序还原为可读代码的技术行为；厂商常在条款中禁止，但是否违法或可被执行取决于具体情形与‘服务’的法律定义。
nondeterminism（非确定性）: 模型在相同输入下可能产生不同输出的性质；这是 LLM 的固有特征之一，但可通过评估套件与提示控制减少对生产环境的影响。