新項目請求，內含參考代碼 about chatgpt-toolbox HOT 7 CLOSED

您好，感謝關注。

關於您提到的404故障。

VM647:16 GET https://cdn.jsdelivr.net/gh/bigemon/ChatGPT-ToolBox/toolbox.js net::ERR_ABORTED 404

我留意到您的腳本裡指向的是倉庫裡該檔案的舊名稱。
在約2個月前，這個檔案已經被更改為 toolbox-chrome-bookmark.js 和 toolbox-raw.js。
分別用於儲存壓縮後可用於Chrome的小書籤的腳本，以及ChatGPT生成的原始輸出。

所以，請將連結修改為https://cdn.jsdelivr.net/gh/bigemon/ChatGPT-ToolBox/toolbox-chrome-bookmark.js 即可。
至於為何在之前您仍然可以正常訪問，這可能是由於CDN快取策略或是瀏覽器的暫存所導致的。

關於第二個問題：

如果沒有理解錯誤，您的這段程式碼似乎試圖引入GPT3的計費API。透過將會話中的請求轉發給GPT-3模型，從而實現較低的審查水平的文本生成。
這在理論上確實可以規避目前的會話審查，也是一種常見的生成敏感文本的方式（因為GPT3 API目前沒有引入任何的外部審查）。
但這種做法可能會帶來以下問題：

1. GPT3的相關模型API在免費額度使用完畢後，需要進行計費。
2. 這種方式本質上是調用OpenAi的上一代GPT3 API進行一次性對話，所以會出現上下文環境割裂的情形。
3. 這本質上與其他開源專案直接調用GPT3 API進行問答並沒有區別。因而在重新載入當前會話後，會話上下文無法被ChatGPT記錄，也無法對返回的結果進行進一步的互動擴展（畢竟是轉發給其它API）。

基於以上原因，我認為如果確實要添加該功能，我們可能還需要實現一些額外的工作：

1. 可能需要以某種方式引入當前ChatGPT的上文，例如使用localstorage一段會話上下文，或是使用JS列舉頁面上的前文，在轉發時一併提供。這或許可以緩解上下文割裂。
2. 使用不違反用戶準則的方式，將生成的內容提交到當前會話上下文，以便當前會話下的ChatGPT可以了解外部GPT3 API生成的內容。

總體來說，如果希望將這種方式較為完美的融入ChatGPT的會話環境，還需要考慮一些其他的機制。

當然，如果完全不在乎這些限制，只是希望提供一個快捷發送給GPT3 API獲取結果的功能的話。這些缺陷應該不是問題。
但無論如何，用戶應該得到提醒這不是在進行CGPT對話。

如果有更多想法，歡迎進行討論。

from chatgpt-toolbox.

一個好消息是：OpenAI已在近日發佈了最新的GPT3.5 API 。
經過測試，在附加上下文的條件下，基本已可以實現預期目的。

接下來的問題，就只剩下如何把3.5的API縫合到免費對話上下文。

from chatgpt-toolbox.

大大您好，實不相瞞，我也正在關注GPT3.5 API，相信其發佈可能使預期的功能效果得以實行之外，本地客戶端的單鍵也不再是遙不可及的夢想。在下剛好發現以LINE搭建本地客戶端的教學，若按照該網址提供的構建流程，可能可以使該API在微信，QQ搭建本地客戶端，不知能否與您參考。以下是在下找到的連結：
https://memochou1993.github.io/gpt-ai-assistant-docs/getting-started.html

希望上述連結的方法能給您參考並提供幫助。謝謝您的閱讀。

from chatgpt-toolbox.

此外，若要將GPT3.5 API搭建在本地客戶端，則可能會產生風險
本地API對用戶的威脅可能包括以下幾點：
隱私風險：由於API可以訪問用戶的個人資料，如果API的安全措施不夠強大，就可能導致用戶的個人資料外洩，進而引發隱私問題。
安全漏洞：如果API存在安全漏洞，攻擊者可能利用這些漏洞進行攻擊，例如通過API進行DDoS攻擊、注入攻擊、資料竊取等。
資源浪費：如果API被惡意使用，例如刷取數據等，就可能導致系統資源過度消耗，從而影響系統的正常運行。
不當使用：有些應用程式可能不當使用API，例如透過API自動發送垃圾郵件、濫用API獲取大量數據等，這些行為可能對用戶造成不必要的困擾和風險。
因此，開發人員在設計和實現API時，應該重視安全性和可靠性，並遵循相關的法規和標準，以確保用戶的資料和權益得到保護。同時，用戶也需要關注自己的隱私和安全，避免在使用API時遭受威脅和風險。

from chatgpt-toolbox.

此外，若要將GPT3.5 API搭建在本地客戶端，則可能會產生風險 本地API對用戶的威脅可能包括以下幾點： 隱私風險：由於API可以訪問用戶的個人資料，如果API的安全措施不夠強大，就可能導致用戶的個人資料外洩，進而引發隱私問題。 安全漏洞：如果API存在安全漏洞，攻擊者可能利用這些漏洞進行攻擊，例如通過API進行DDoS攻擊、注入攻擊、資料竊取等。 資源浪費：如果API被惡意使用，例如刷取數據等，就可能導致系統資源過度消耗，從而影響系統的正常運行。 不當使用：有些應用程式可能不當使用API，例如透過API自動發送垃圾郵件、濫用API獲取大量數據等，這些行為可能對用戶造成不必要的困擾和風險。 因此，開發人員在設計和實現API時，應該重視安全性和可靠性，並遵循相關的法規和標準，以確保用戶的資料和權益得到保護。同時，用戶也需要關注自己的隱私和安全，避免在使用API時遭受威脅和風險。

這個是CGPT自己回答的吧 :)
關於這些提到的問題，由於目前的計劃是只使用JS實現插件主體。
所以應該是不要緊，因為瀏覽器沙箱自己就有對這類執行權限進行限制。

以下是近日進行改寫的測試版NSFW 解限GUI.（基於原repo川虎Chatbot的開源專案）
作為驗證，我認為可以通過類似的方法實現插件的改造（不過最近真的好忙，可能要等有空）。
https://github.com/bigemon/ChuanhuChatGPT

from chatgpt-toolbox.

更新：抽了6个小时生成了一版新的，已接入

GPT3.5混合接入(beta)

• 使用 /api 聊天数据 可在编辑、发送时调用GPT3.5 API
• 自动引入网页上文数据 (当前设置为3000字节)
• 可选的引导语句参数 (用于句首引导/句末自动确认)
• API回执自动转发至网页

需要注意的是，目前沒有找到好辦法將API回執數據插入會話上下文。
暫時使用的是把結果以“聊天記錄”的形式騙它看完。
因此這個版本目前並不適合進行沉浸式對話（也就是所謂的催眠啦）。

from chatgpt-toolbox.

若有更多想要討論的內容請再次打開此issues即可。

from chatgpt-toolbox.