sk-api¶
文档历史说明
本文档最早位于 PumpkinJui/sk-api，于 sk-api@9b49714 添加。后因内容整合，于 sk-api@867eaeb 迁出。
迁出后，本文档进行了 MkDocs 适配，并进行了补充和完善。
通过调用大模型 API，在 Python 或 CLI 中进行 AI 对话补全。
一开始，是没有做 sk-api 的想法的。最早是意外注册了 DeepSeek 的开放平台账号，发现居然有 10 块钱，还一个月就到期。于是弄了一个 API KEY，把它挂上了沉浸式翻译。
然后在翻译的时候发现这玩意质量特别高：我原来用的是免费的智谱 GLM 翻译（glm-4-flash），在它没出时还用过微软翻译，有时还用腾讯交互翻译。后面这些服务在翻译 Harry Potter Wiki 时全部处于蒙圈状态：人名翻译准不准确要看心情和运气。
比如智谱，即使我专门配置了对 HPW 的提示词，还是对各位姓或名由 S 开头的分不清楚，斯拉格霍恩（Slughorn）和斯内普（Snape）全都变成了斯莱特林（Slytherin）；咒语更是基本没有翻译对的，只有阿瓦达索命、呼神护卫等知名咒语翻译是准的。而 DeepSeek 没有译错的人名，咒语也能译对很多。
正好吐槽通义不好好做对话，弄一堆舞王和活动什么的来彰显其「多模态」，还占我存储；就想着把手机里面的通义扔了换成 DeepSeek。但是发现当时它还没做 APP，而我浏览器从来只用隐私模式，自动清除历史记录和 cookies（用于记录登录状态），它还每次要我验证码，就很难办了。
最后我把通义换了 Kimi，但是还是想用 DeepSeek。刚好手机上一直在用 Termux，那就跟着 API 文档鼓捣呗。
一开始看见文档有 CURL，就想用 Linux Bash 实现；后来真靠着 AI（主要指 Kimi）做出来了非流式传输的多轮对话，文件名用的是 SK.bash，因为 DeepSeek API KEY 以「sk-」开头，并且我误以为是 deepSeeK 的缩写。
但毕竟是 AI 做的，而且 Termux 是模拟 Linux 环境，bug 很多。最严重的是不知道为什么一滚屏就不能多轮对话了，说我有控制字符。也不能多行输入，可能一部分原因也是我当时没考虑到做这个。
后来做流式传输时被多行输出卡住了。不管怎么改，都要么吞换行，要么显示成 n。于是索性掀桌不做了，不能归我控制的代码不值得写。
遂转战 Python，这是我的编程第一语言，相对比较熟练。
我目标最低兼容 Windows 7 32-bit，这样即使是学校机房也能跑；这也意味着我要用 Python 3.8。但我 Termux 用的是 Python 3.12。本来这不算大事，但版本太新就装不上 OpenAI 的第三方库了。而且它还没有可用的降级包！
Due to our infrastructure limits, we do not provide older versions of packages. If you accidentally upgraded to unsuitable Python version and do not have backups to rollback, do not complain!
显然，做一个我自己运行不了的程序是十分困难的，而且我的目标用户首先是我自己。于是改用 requests，至少我能装得上它。然后通过改文档中的示例代码，写出来了 sk-api 的初版。
除了在手机上的编辑（拿不上电脑导致的）以外，有相当一部分工作（包括 0.9 的打包）都是在学校南教 219 机房做的，因为上面提到过，那的电脑就是 Windows 7 32-bit。
这中间改了名字。sk.py 似乎有一种过于短的不安感，而且这个程序肯定要复用之前我在 PumpkinJui/sync 写过的配置模块。所以我把配置模块命名成 sk_conf，对话模块改成了 sk_chat。0.9 用的文件名，鉴于 chat 是主模块，程序也就默认用了 sk_chat.exe。
1.0 是人脑执行程序发现 bug 以后急急忙忙改的。夜自习科夫监，于是借科夫的 Windows 7 64-bit 电脑，现场装了个 32 位的 Python 3.8.10 打包。
这时觉得这个名字是不合适的，毕竟程序也用主模块的名字，显得 sk_conf 很尴尬。于是因为调用的是 API，就改成了 sk-api，下划线改成连字符则是觉得 sk_api 有些古怪，以及多少是对 GitHub 仓库名称的考量。
至此 1.0 版本完工，当然也有需要优化的代码和新增的功能，但可用性已经很强了，就把这玩意上了 GitHub。但在 GitHub 发布 1.0 版 5 天以后，01 月 15 日，DeepSeek 出了官方的 APP。
不过我说过我手机没地方。所以我不仅没弃坑，还做了更多大模型服务的适配，让我能在 Termux 这一个命令行框架里面就用上各家大模型服务，不用左装一个 DeepSeek，右装一个豆包，毕竟 APP 都是占地方的。
虽然也有必须得装的，比如 Kimi 的 API 限流太严重，联网还贵，k1.5 还不开放 API，就不如 APP 用着好。
除此以外，我还用 pylint 作了码风改进；配合 DeepSeek-R1 做了 CI，省着为了打个包老去找电脑；甚至又装了一个 gh，也就是 GitHub CLI，方便我下构件和发 releases。（现在再看原来的码风，简直是不堪回首……）
第二位版本号的每次跳动，都是至少一个新平台的适配。就在我写下这句话的前几天，sk-api 发布了 1.6.2 版本，适配了智谱和字节新发布的模型。现在，sk-api 已经成为了 919 + 557 行代码的项目（含文档、空行和调试代码），定义了 27 + 7 个函数，兼容了 8 个不同平台的 74 款模型，是我维护过的最大代码库（没错我其实还只是个不入流的开发者）。无疑，这个项目带给我的成长良多。
我常说问那么多意义既没有用还容易虚无主义，但人们就是这样，没有一个意义他们就不明白为什么要做这个东西。
所以，在一片欣欣向荣以后，考虑 sk-api 这个项目的意义。
我的回答是折腾的意义，让我不用验证码同时用上大模型的意义，少占手机存储的意义，多少学习一些 Bash 和 requests 的意义，甚至耍帅的意义。
在拿不上手机、一人付费大家共享、放在班里面大家公用一类的场景也可以用，虽然这个愿景因为班里面同学用 AI 的意愿不大，算是破灭了。
我重新造了一遍轮子，变相实现了 OpenAI 库的一些功能。我用 pylint 改进码风。为了第一时间接入最新模型，我也算是冲到了 AI 浪潮的前头，至少比那些 GPT-3 出来两年半、R1 出来几个月以后，还是只知道 DeepSeek 的人要强得多。
虽然项目对他人的不可替代性几乎没有，但它对我来说就是不可替代的、最趁手的工具。至少最初，写这个程序的目的就是「自用」，只要我自己用着好用就可以了；至于后期有没有「他人」用，有没有「他人」提建议和意见，说白了，都无关紧要。
这么看来，意义么，我想做就好了。「想」比任何意义都管用。
延伸閱讀：當代學生生存手冊（节选）
首先，最重要的一點是要卸下認知負擔：棄坑其實不是什麼「大事」。大多數棄坑都是因為天不時、地不利、人不和。
導致一個計劃被擱置的原因有很多，像是相同的領域已經有很多人在「卷」了，自己寫累了，或者是一起合作的人失去了繼續完成計劃的熱情。
這些都是可以被理解的。無論是現實層面的原因，還是心理層面的原因，只要這些後果是能夠被承受的，那麼這次「棄坑」就無可指責。
無論是計劃推進到了什麼樣的進度，在執行計劃過程當中積累下的經驗都是真實存在的，這部分經驗並不會因為計劃被放棄而消失。
價值評估
價值的起點是一個真實的問題。當我們看到一個值得解決的問題，並清晰地認識到其背後的價值時，就會產生繼續推進的動力。而脫離了「實際問題」這個根基，整個計劃的目標就變成了一個「空想」，因此其未來自然是不明朗的。
明確價值，實際上就是在回答這樣的一個問題：「完成這個計劃的過程和結果能給我們帶來什麼樣的好處？」這裡得到的理由越充分，把計劃執行完的可能性就越高。
……
除了對自身價值的評估之外，計劃本身的價值也需要被納入考量。對價值的評估始於明確的「問題」。尤其是針對「開發軟體」、「製作遊戲」或者「寫本小說」這種企劃，在給它們的價值做定性的時候，最先需要回答的問題便是「這個計劃究竟解決了什麼問題？」
一個軟體在解決的問題可能是「工作效率」，而一款遊戲在解決的問題可能是「表達一個觀念、保存一段文化、記錄一個故事」。明確了這個問題之後我們便可以藉由問題的價值來推估整個計劃價值的天花板。具體的做法有很多：比如，從「有多少人關注這個問題？」這樣的角度來進行推算。再比如，假設你希望藉由這個計劃獲取資金上的利益的話，不妨再來進一步評估一下：「人們願意為了這個問題付出多少錢？」藉著這些資訊我們可以通過一個粗糙的乘法得到大致的盈利空間。
與如夢似幻的想像不同，以上討論到的「具象化概念」可以幫助我們找到計劃的「不可替代性」，進而為計劃長期執行提供持續性動力，而非單純地依靠「開坑嗎啡」做「短程衝刺」。
堅守價值，保護自己
在向社群廣播計劃進度的時候，我們常常會收到非常多的建議。但這些建議並不都是有用的，甚至有一些看起來非常「老甲方」。它們可能過於武斷，缺乏對整個情境的深刻理解，同時還帶有強烈的主觀色彩。在這種情況下，明確計劃和自身的核心價值，並堅守它們顯得尤為重要。只有深入了解對計劃的期望和追求，我們才能夠有效地過濾掉周圍的干擾聲音。這也凸顯了「價值評估」的重要性。
實際上，我們身邊經常充斥著過於樂觀或不切實際的想法。出於禮貌原因，雖然我們可能得予以適當的尊重，但卻不一定要全盤接下。因為這些觀點往往與整個計劃的宏觀目標不相符，如果我們沿著這些模糊、不清晰的目標前進，很可能導致整個計劃偏離軌道。
從這個角度來看，清晰而明確的價值體系是非常重要的。因為一個明確的價值體系可以幫助我們對抗外部的各種發散性力量和質疑，進而形成對自己的保護。
無論這個計劃最終呈現出來的效果是怎樣的，它對於我們的價值都獨一無二，值得我們去呵護和堅守。