如何取消sk-前缀检测？

[huaxianhu]

当我修改第2136行默认的自定义第三方 apiURL: "http://xxx.cn:3000/v1/chat/completions"
设置API key 为 123 验证成功 但发送消息会弹框报错：

notif_noKey_cn = '当前接口地址仅支持 OpenAI 官方Key，已为您自动更换 [Key模式] 为: ' + keyModeText + '\r\n\r\n但是当前没有可用的 OpenAI 官方Key，请求已被中止，请添加 OpenAI API Key。如果您要使用第三方专用Key，请更改 [接口网址] 为第三方接口。' ;

如果把 设置API key 为 sk-123 验证成功 发送消息不会报错

我现在想应该修改哪行代码才能让它不检测key前缀是否为sk-

尝试把第2154行的 isThirdPartyAPIKeyEnabled: false, 改成 true 无效

话说能不能在第2136行的apiURL下载增加一行默认：apikey: "xxx" 当设置了此值优先使用此key
这样我就能直接在后台设置默认官方或第三方apiURL和apikey 共享给用户直接使用，而无需用户手动设置，当然如果我未设置默认apikey或无效才会提示用户手动设置 实现：新用户一打开网页就能直接发送消息使用

[lin2025]

我快4周没碰代码，可能需要重新熟悉下，我现在边写边回想，自我理清下😅，看看能不能解决这个问题：

当使用第三方apiURL时，API-Key可能会出现三种情况：
A) 第三方专用Key - 非"sk-"开头的任何样式的字符串。例如：abc123
B) 第三方专用Key - 仿OpenAI官方Key，以"sk-"开头的第三方生成的字符串，长度可能与官方一致，也可能不一致，例如：sk-abc123
C) OpenAI官方Key - 第三方API仅是简单中转，所以仍使用以"sk-"开头的总长51位的官方Key。

因为存在以上三种情况，所以我写了不少代码去尝试自动解决或提醒用户做出正确的分类，目的是尽可能减少报错，让新用户也能上手。

针对你的目的/诉求：
1、我发现我确实没有考虑过"在代码中默认写入第三方API URL"的情况，我只考虑过默认填写OpenAI官方Key的情况（*官方Key可以填写在 default_apiKeyArray_WrittenInTheCode 或 default_apiKeyArray_WrittenInTheCode_Encrypted_Base64 这两个数组变量中），默认在代码中写入任意数量的OpenAI官方Key，体验很好，无需验证，用户打开就可以上手用。
2、原先我觉得大多数情况都会是自己使用，不动代码的话，也就第一次使用时麻烦点，需要手动新增各种官方Key、第三方Key，之后就使用本地存储空间。换设备、换浏览器，则通过导出导入功能共享所有Key。
3...所以，现在看看行不行实现你需要的功能：默认写入第三方API URL和第三方Key，用户首次打开无需点击验证Key，直接使用。

稍等下，我想想 报错原因 、有没有替代方案 ...
...

[huaxianhu]

其实吧 我就觉得压根没必要写那么多判断是否第三方key代码！！！ 因为第三方的url和key格式都不是固定的，就算是固定的，正如你上面说的3总情况，你也没办法细分谁是谁。。。 除了中前缀sk-去判断 而且还不准，特别是你这样分开只有官方接口才能轮训key 而偏偏国内网络是打不开的，那为啥别的gpt项目没这些问题？就算第三方key也能轮训？那是因为人家没把问题想复杂，人家压根没第三方模式也没去判断url和key是不是固定格式的官方open 人家只有一个url输入框 和key多个换行输入框 就没其它的了，也不需要去验证key 为啥？因为如果url或者key不对 那请求自然会报错，压根就不需要去判断提示用户你输入的不是官方key 前端用户也能自定义任何url和key 说实话自定义key输入框本身就包含了官方key和第三方，你这写法到是让我感觉有点像同时使用多个url服务商或者多个服务商切换账号: 比如使用官方key请求失败，后替换第三方a的url与key请求 还失败就又切换第三方b的url与key请求，你的这个key验证的复杂写法也就轮训切换多方url服务商才会用得到！因为最简单的写法就是 一个url输入框可以输入任意url 然后其对应的key也是任意多个，然后一对一轮训压根不管key是否为官方，因为不匹配验证请求key时本身就会报错，毕竟如果用户填入的url是官方的自然会去粘贴官方的key 而url填入的是第三方a的url自然就会去第三方a后台复制其key 这时候如果再加判断key是否为官方的sk-就有点多余了

[lin2025]

代码没有直接通过sk-去判断，而是通过url、key、第三方api库、报错代码识别以自动区分。
你可以试试看，以个人身份去使用，不改动代码，直接使用原版，应该不会出现你说的问题。

支持第三方API是后期才加的，之前都是OpenAI Key为主，使用官方Key，翻墙或者使用 openai-proxy.com / nextweb.fun 等免魔法代理，如果有两三个免费的官方Key，轮询体验会比简单的轮询方案好点，主要体现在快速聊天的时候。很多功能都是围绕提升免费官方Key的使用体验而设计的，也基本都会复杂化 ，且很多功能是联动的，错误代码识别、自动重发、自动修正max_tokens等，当准备新增像"支持第三方付费API"这样的功能时，没办法新增几行就搞定（新手项目，代码比较乱），且各平台错误代码等不兼容，其他项目好像也都有手动适配常用的第三方api，不然有些可能不支持。

每个人需求不同吧，如果你大部分需求只是使用第三方API的话，那确实，现在任何一家第三方平台都很流畅，我自己也在用，对于第三方付费API，本身就不需要轮询，错误代码识别功能也是完全多余的，也基本不需要自动重问，类似用不上的功能太多...
功能都砍掉，那差不多就回归成一个简易DEMO了...

[lin2025]

发送时，报错：“当前接口地址仅支持 OpenAI 官方Key～～～”

反推：check_KeyMode_Sending() 中：

1. this.check_KeyMode_byURL_ChangeKey() 返回了false，表示[Key模式]刚刚被自动修改过。
2. 当前 this.isThirdPartyAPIKeyEnabled 值为false，表示当前的[Key模式]为"OpenAI官方Key模式"
   即，刚刚点发送后，[Key模式]发送了变动，被自动识别为"OpenAI官方Key模式"。

以下两个地方，之前有添加过关键词吗？没有的话，可以添加试试：

1. v8.28 第1804行 list_OnlyUseThirdPartyKey_DomainKeyword 中加入你域名的关键词

2. 如果你准备把Key设计成"sk-"开头，则还需要多执行一个步骤：
   v8.28 第1790行 excludeList_ThirdPartyKeyStartWithSK_DomainKeyword 中也加入你域名的关键词

可以先使用原版代码，修改以上两处代码后，看看能否解决问题。

[huaxianhu]

话说 新会话默认记忆无限 我应该该哪行代码让它默认10条，我发现如果无限的话 累计几万token后 不管是消耗的token还是处理时间都会很长。 我感觉待开发的那个 只记忆最新xxx条挺不错的

[lin2025]

”待开发的只记忆最新xxx条“ 这个功能，会影响到"导出聊天记录"等多个功能，都要改（挺无奈的），不改的话，BUG会很多，虽然用户没多少，但我还是偏向于尽可能全面地测试、修复Bug后再发布。想到这些，头就有点大，摆烂了一个月没写...这几天可能会开始写。

[lin2025]

“新会话默认记忆无限 我应该该哪行代码让它默认10条”

“记忆模式”这个属于Chat数据，和每个会话的聊天记录一样，属于单个会话的数据。每个会话的记忆模式都是独立的。新建会话时，会初始化默认的Chat数据。

会话 初始化默认数据/设置 对应的变量： v8.28 第2161行 chatVariables_default
修改其中 settingsContextualMode 的值，即可修改“记忆模式”的默认值（第2163行）

数值对应 settingsContextualModeOptions_cn 和 settingsContextualModeOptions_en 中存在的值，偶数

修改后只会影响新会话，之前已经存在的会话的“记忆模式”不会受到影响，已有的会话需要手动修改。