lel020

没有这个需求，我是单独一个 skill 放个脚本让 ai 创建带日期的临时目录，然后任何大段内容包括临时代码脚本文档讨论解释，所有都必须写到这个目录里，在 vscode 看，

和中转站有什么本质区别？是想把责任抛出去吗？对上下游来说，你这个平台有什么比中转站好的吗？

你该想想，如果 CC Switch 能保证安全，那 Sub2API 为什么不直接参考 CC Switch 做完全一样的请求？ 实际上就是没谁能保证稳妥。风控规则又不是透明的。过去安全也不等于未来安全。

哎，AI 时代的经验有明显偏科啊, 以前一直用按次计费的时候，压根不用考虑 token 消耗问题, 现在就很容易焦虑这方面

@bwnjnOEI 我也是这么想的，但是刚刚粗看了一下调试信息，发现压缩上下文这个请求开头没有携带 skill 列表, 这应该就是重要的分歧了。这之前的系统指令依然走了缓存，这之后的所有内容就和普通的请求对不上了 @106npo 输出并不多，压缩非常狠，有用没用的都丢了，几百 K 可能压缩到 1…

是的，不要怀疑， 新代码的 AI 参与率要无限逼近 100%是最优解， 人的任何需求，包括架构/注释/测试/风格所有一切都可以让 AI 处理， 包括自己也讲不明白的需求也可以交给 AI 分析清楚先， 哪怕自己和 AI 都不懂的也可以让 AI 上网调研清楚形成文档再参考着做， 甚至是确实困…

字面意思应该是你的组织限制的，

完全不理解这个封号逻辑，给人感觉就是怀疑就先封了再说。也不考虑后果和影响

github ai 可以用 api 访问，不确定情况如何， 如果能用的话走 api 而不是 oauth 应该没有风险， https://docs.github.com/zh/github-models/quickstart

明明知道真实路径却不使用，非要自己猜，好傻，加了几句全局指令好像好了，

• 只能通过当前环境已明确提供的 skill 文件路径加载 skill 。
• 禁止根据目录结构、命名模式或历史经验猜测 skill 路径。
• 如果已知路径读取失败，立刻反馈让用户提供正确路径。

但实际用起来没跑两…