我尝试翻译一下楼主的帖子：

楼主是说，你在用打开开发者调试的方式来通过 ADB 远程控制手机。
然后有些 APP 会检查是否打开的开发者模式，并告警。
楼主不希望那些 APP 告警，是这个意思吗？

@wsseo 模型设置，添加模型，多了一个选项 custom endpoint

终于开放了，作为一个被 Github Copilot 频繁改政策逼走的年费用户，可以说百感交集。

测试了一下。启动的上下文有点大（问一个你是谁直接 50K ）
暂时用几天看看和 Claude Code Desktop 相比的体验如何。

门槛最低的选择：TraeCN + deepseek 官方充值，TraeCN 不需要买会员，直接配置第三方 API

旗舰：Claude 订阅，使用 Opus 模型


剩下的就都是 Coding 工具和模型 API 之间的排列组合了。

你要分清，什么是 LLM ，什么是订阅套餐，什么是 Agent 。

楼主指的是各自官网的 chat 工具吗？

chatGPT 本身是一个包装过的商业产品，是有付费点的。
deepseek 的 chat ，本质上就是个收集用户数据的入口而已。

skills 和 MCP 肯定是用到再装。盲目安装对上下文污染造成的负面效果大于正面效果。

很多 skills 和 MCP 你不在提示词里明确指定，LLM 也不会去用的。

这种东西不开源没人敢用的

@FabricPath 你理解错了，是上海地库的事故之后，所有 Model s 的单节电压都下调了 0.1v

@FabricPath 特斯拉是锁过的，因为上海那起地库 model s 事故，直接砍单节电压。
车企都是这样的，为了自己的口碑与未来销量，可以牺牲消费者的利益，美其名曰共创。
传统车企这也是基操，比如借着保养偷偷给你刷行车电脑。

不过动力电池参数动态调整这个事儿，其实确实是模糊地带。
动力电池本来就是在一直衰减老化的，一定要有程序配套控制。
到底什么是控制，什么是锁电，什么是安全冗余。其实是很模糊的概念。

我认为把对汽车底层软件的修订做成类似召回的模式（走法律程序，但形式可以 OTA ，就像特斯拉的“召回”改默认动能回收低、缓行），应该是个不错的方案。

换电模式是典型的“看上去很美”的场景。

1 、蔚来的车普遍电耗高。即便是 100 度电池，实际续航也不超过 450 。通过这个你可以推测他的换电频率和换电费用。
2 、蔚来换电站的点不够密集。你开来，开去。再加上蔚来为了控制电池的损耗不会充满，最终可能你只能 90%容量可用，甚至更低。
3 、蔚来的电池目前有碎片化的趋势，各种不能兼容。换电站并不能做到当初吹嘘的无等待自循环（做不到换完最后一块，第一块已经充满）。

最后就变成，你充电要等，换电也要等。剩下的全是换电的缺点。

翻拍并不是一个合理的解决方案（在画质你能接受的前提下）。

5 年前苹果想强推，但最终收回的那个儿童色情图片识别，就是可以做到 iphone 本地算力的前提下，抗翻转、涂抹、翻拍来揪出相同特征的图片的。

我给楼主泼盆冷水。
其实这种分享的信息量和受众极其有限。

1 、太多 AI 生成的内容了。导致信息密度太低。
2 、你很难证明你的使用方式是“正确且高效”的。
3 、你更难证明你的方式是“普适”的。

正向编程，AI 生成的方案你都过一遍，不是自己熟悉或者预期的技术选型，就都否决让他去改。或者你给个建议。

btw：其实目前 Agent 的模式很类似团队管理。要用管理的思维去驱动 Agent 。

如果想完全一致，混合应用是最方便的。顺带还解决了热更的问题。代价就是小程序这侧不太支持（ API 缺失严重）

如果想体验最好，各自平台一份原生是最理想方案，你维护一份功能定义和产品设计文档，然后各自实现。

跨平台语言框架在现今来看，性价比不高。
1 、各自平台还是要各自匹配特性。只有逻辑和 UI 代码可以共用。
2 、性能不强。
3 、如果考虑跨到小程序，好像只有 uniapp 能符合吧？

要用第三方供应商吗？如果要用，唯一的选择就是 vscode 插件了。但是 vscode 插件有 bug ，有时候会变得特别慢，且上下文暴涨。

claude code 对于第三方供应商的要求就是 API 要支持 Anthropic 格式。

所以要看你的中转站是否支持对应格式的接口。

qwen 最厉害的是开源小模型，
qwen3.6-27B 的 Agent 能力不输 deepseek-v4-flash
qwen3.6-35B-A3B ，用 3B 的运行参数，就能实现二线模型的能力

那你这个“据我了解”有点过于片面了。

举个不太恰当的例子，你记得回家的路吗？那我问你，到你家路上的最后一个十字路口的斑马线有几条白线？

同理，对于 Coding 这个场景而言，模型不需要对于你的项目“全知全能”，就可以做到改代码。他只要知道代码在哪，以及如何搜索需要的内容即可。

“上下文太短，以至于无法装载整个项目，导致没办法产出合理的程序设计，LLM 对于 Coding 还只能是输出代码块”，这是 24 年中旬的论调。

脱离楼主本身来讲。

目前缺的就是工具，而不是模型。头部的模型 Agent 能力已经基本过线了，只要提供合理的工具和技能，模型都能正确的调度和梳理。

模型能力能替代生成和统计，但无法替代“眼睛和手脚”。拿不到上下文，LLM 即便是神仙也没办法。
所以方案 B 一定是未来的方向。


但是，在 LLM 时代，抓包工具“凭什么”必须用楼主的呢？这才是最大的问题。

我观察到的趋势，LLM 的工具越来越封闭化。大模型公司逐渐的会把自己的工具生态封闭起来，因为 LLM 本身无状态，不会有迁移成本。所以通过闭源工具自身构成上下文壁垒，形成所谓的“数据飞轮”，才是 LLM 服务的核心壁垒。

之前 LLM 公司不重视工具，是因为模型公司之前基本上是再打融资战，要的是投资人能看到效果和感动世界。
现在则是实际的刺刀见红。在争夺实际的 C 端客户。