给 AiNiee-CLI 搓了个 Web 端监控面板，看 RPM 曲线飙升终于舒服了喵

大佬厉害w

厉害了佬。

厉害了w

太强了佬

大佬好厉害

不错呀！

太厉害了，顶一下

hi, 看到你的翻译项目， ainiee-next, 大佬真厉害，感谢无私贡献。我最近在用 GitHub - BigDawnGhost/wenyi: 将被语言阻隔的作品，带到读者的语言中。Bringing literature into your language. · GitHub 这个项目翻译电子书。

优点：翻译流水线 电子书预处理、电子书分析、术语提取、初翻译、润色、审校，按批次动态术语更新和注入，和格式对齐。

缺点：只能串行翻译。按批次动态术语更新和注入，和格式对齐 反复调用 大模型多次请求慢到怀疑人生，token消耗非常多。(Issue · GitHub)

我看到你的 ainiee-next 项目多是技术方面的介绍， 能否详细介绍一下在翻译 学术著作、技术书籍、文学作品方面的 流程、特色、优点呢？支持指定某个章节重新翻译吗？

我感觉可以参考一下 wenyi 的项目，他这个流水线设计挺好，但是 格式对齐和术语更新注入方面 我觉得需要优化， 但人家说设计就这样。

横向对比一下 另外的产品：沉浸式翻译插件。

首先我使用参考 意译大师（两阶段翻译 初翻译和润色）、paper、github、tech等AI专家自己手搓了一个，

接着每次往提示词里头加上 书籍特定的补充提示词内容。

目前翻译质量从自用的效果看还不错，就是手工成分比较多。

我还想问一下个问题， 你这烧的token 亿级别的烧，是企业订阅吗？还是薅羊毛？如果是后者的话，我也想搞个试试，自己目前翻译用的 qwen3.5-plus（性价比高）

首先，我的项目也是支持大批量的流水线翻译，具体可以看我README

其次小说这块存在Ai自动分析术语表的，你直接请求一次全文 /比例分析就是

学术著作没进行测试过，但大概率术语表依旧适用，技术书籍如果可以，也尽可能用术语表，某一章重新翻译这个技术上很难做到（虽然我Web端允许仅重译选中行），EPUB等格式它不是很规范，很多人做EPUB都是乱的，虽然有标准，但它的兼容性让很多人没有太注重标准

我这个对于单本也是类似于串行，只是可以开高并发降低消耗时间，虽然有打算让自动化流水线允许在翻译时多开多本翻译（得益于增量术语表，它在同一个系列的情况下，会在原有的术语表内追加，且带有版本控制，具体可以看看这个文章 [(轻小说机翻机器人)）

如果你是需要问其他的，欢迎继续回复

或者你所说的串行是指的是如果翻译中断，则必须走一遍这种流程，我这边中断你可以直接重新翻译，会接着翻译后续内容，之前的不变

我最近用你的项目来翻译，在控制方面非常精细，泛化能力很强。

我有个反馈和疑问:

反馈：每次翻译要用到的术语 是按照 子字符串匹配过滤， 对于日文 acg 内容没问题，但是英文的话，单词的语法变化(单复数、时态、大小写) 没法匹配，只能建立更多个 中英术语对

疑问：我打开“允许局域网远程访问”后，访问时，项目配置、提示词和术语表 等多个 api 都显示403 forbidden, 而我尝试了 nginx 反代(加ssl、代理到本机访问ainiee，访问网址是主机名的域名)、ssh 代理(代理到服务器本机访问 ainiee，使用ip访问)、浏览器无痕模式尝试，都没有用. 不知道是我的姿势问题还是怎么样。对这方面不是很熟悉，尝试了很久。将 ainiee 打印出来的日志、还有 nginx 的 access log 以及 浏览器的网络请求抓包扔给 deepseek，最后也没法解决

了解，感谢您的反馈，我回去查一下原因，顺便优化一下匹配

还有在翻译实验过程中，在润色阶段加上思考链(low 推理强度)后，对原文意思的把握（一些微妙的表达）、重逻辑的长难句拆解、人话流畅性表达，比关闭思考链，明显要更好。

不过这样的话，就需要先手动翻译，然后改动一下 llm api 配置，然后再进行润色. 如果能加个模型精细控制就更好，或许可以通过 skill 让 ai 来搞（暂时没有玩过 mcp这些）？

我补充一下：这个术语匹配具体算法，其实我也没看 ^-^，我让 gemini 看了，他是这样说。

有SKILL，你可以看看README

什么问题，可以提一下，我这两天看看