NextAI Translator 仓库开发指南从目录结构到构建、测试与提交规范【免费下载链接】nextai-translator基于 ChatGPT API 的划词翻译浏览器插件和跨平台桌面端应用 - Browser extension and cross-platform desktop application for translation based on ChatGPT API.项目地址: https://gitcode.com/GitHub_Trending/op/nextai-translator本篇指南以仓库根目录的 AGENTS.md 为骨架面向准备为 NextAI Translator 贡献代码或深入阅读源码的开发者系统讲解该基于 ChatGPT API 的划词翻译浏览器插件与跨平台桌面端应用的仓库组织方式、常用开发/构建/测试命令、编码风格、测试规范、提交与 PR 要求以及涉及 API Key 等敏感信息的安全配置要点。读完你可以快速上手pnpm dev-chromium/pnpm dev-tauri双端开发流程理解浏览器扩展与 Tauri 桌面端如何共享一套src/common逻辑并按照仓库既有的约定提交合规的 Pull Request。项目结构一份面向贡献者的顶层地图AGENTS.md 用短短几行勾勒了整个仓库的模块划分结合目录树可以验证其准确性。仓库采用「多目标共享核心」的布局src/browser-extension/浏览器扩展的对外表面popup、options、background以及 manifest 工具链。其中 manifest.ts 通过getManifest(chromium | firefox)生成 Manifest V3 配置并在 Firefox 分支下注入browser_specific_settingsGecko ID和background.scripts数组写法Chrome 则使用service_worker这是双浏览器差异的集中处理点background/index.ts 负责创建右键菜单contextMenus并把流式请求通过 port 转发。src/tauri/桌面端窗口的 React 渲染层windows/ 下按窗口拆分子应用TranslatorWindow、QuickTranslatorWindow、SettingsWindow、HistoryWindow、InlineLookupWindow、ScreenshotWindow、ThumbWindow、UpdaterWindow、WritingIndicatorWindow、ActionManagerWindow配合 Window.tsx 统一承载。src/common/两个目标浏览器扩展与 Tauri 桌面端共用的 hooks、store 与翻译逻辑是「write once, run on both targets」的关键。翻译引擎全部集中在 engines/OpenAI、Claude、Gemini、DeepSeek、Kimi、ChatGLM、Groq、Cohere、Moonshot、Ollama、Azure、LiteLLM 等共享的表单组件在 components/Form/i18n 语言包位于 i18n/locales/en/ja/ko/th/tr/zh-Hans/zh-Hant 共 7 个语言。src-tauri/Rust/Tauri 后端承载原生命令、更新与打包逻辑平台资源位于src-tauri/resources与 src-tauri/icons。支撑性内容public/静态资源、scripts/构建辅助脚本、docs/各模型提供商接入指南、e2e/Playwright 端到端用例、clip-extensions/PopClip / SnipDo 划词扩展。产物目录构建输出落在dist/长期保留的安装包放在release/。AGENTS.md 中提到的dist/与release/均属于构建产物目录本身不进入版本库scripts/下的 release.py 展示了发布流程从 git tag 读取当前版本、按fix/feat/docs/refactor/optimize/enhance/openai前缀过滤git log生成 release note再打新的 annotated tag。环境准备包管理器与依赖安装AGENTS.md 明确要求使用pnpm且包管理器版本被固化在 package.json 的packageManager字段pnpm9.1.3。安装依赖只需pnpm install安装完成后prepare脚本会自动执行pnpm exec simple-git-hooks注册 pre-commit 钩子钩子内部通过lint-staged对暂存文件运行 ESLint 与 Prettier详见 package.json 中simple-git-hooks与lint-staged配置。这意味着从第一次pnpm install起提交时就会被强制约束代码格式。开发调试Chromium 扩展与 Tauri 桌面端AGENTS.md 给出两条开发路径对应的脚本在 package.json 中均有定义命令作用底层实现pnpm dev-chromium以 Vite HMR 启动浏览器扩展开发vite -c vite.config.chromium.tspnpm dev-firefox监听式构建 Firefox 版本扩展NODE_ENVdevelopment vite build -c vite.config.firefox.ts --watchpnpm dev-tauri启动 Tauri 桌面外壳tauri dev渲染层由dev-tauri-renderervite -c vite.config.tauri.ts --force驱动值得注意的实现细节vite.config.chromium.ts 使用samrum/vite-plugin-web-extension插件传入getManifest(chromium)开发模式下关闭 minify、开启 sourcemap产物输出到dist/browser-extension/chromiumFirefox 版本vite.config.firefox.ts额外把静态资源内联阈值提高到 1MBassetsInlineLimit: 1024 * 1024。vite.config.tauri.ts 为 Tauri 定制固定端口3333且strictPort: true端口被占用会直接失败而非自动换端口clearScreen: false避免遮挡 Rust 侧编译错误构建目标[es2020, chrome87, safari14]TAURI_DEBUG环境变量控制是否压缩与生成 sourcemap。三个 Vite 配置都注册了别名指向src/源码内统一用/common/...这类导入路径例如 background/index.ts 中的/common/engines/chatgpt。构建产物浏览器扩展、桌面端与用户脚本AGENTS.md 列出的构建命令同样与 package.json 一一对应实际构建逻辑沉淀在 Makefile 中命令产物pnpm build-browser-extension依次执行tsc类型检查与make build-browser-extensionMakefile 先通过sed把版本号同步进 package.json再用 chromium/firefox 两份 Vite 配置构建最后各自打成dist/browser-extension/chromium.zip与dist/browser-extension/firefox.zippnpm build-taurinpm run build-tauri-renderertsc vite build -c vite.config.tauri.ts后执行tauri build产出桌面安装包pnpm build-userscriptmake build-userscript基于vite.config.userscript.ts与vite-plugin-monkey产出用户脚本pnpm cleanmake clean即rm -rf dist在打包前重置产物目录Makefile 中还包含两个未在 AGENTS.md 提及、但同样有价值的扩展打包目标build-popclip-extension把 clip-extensions/popclip/ 打包为.popclipextz供 macOS PopClip 调用与build-snipdo-extension把 clip-extensions/snipdo/ 打包为.pbar供 SnipDo 使用。如果你要发布到这些划词工具生态可以手动执行make build-popclip-extension/make build-snipdo-extension。版本号统一通过 Makefile 的VERSION变量默认0.1.0配合change-version/change-package-version目标维护与 scripts/release.py 的 tag 驱动版本策略衔接。测试Vitest 单元测试与 Playwright 端到端AGENTS.md 对测试的约定可以拆成三层均有仓库证据支撑1. 单元测试Vitest命令pnpm test→vitest test测试基础设施见 vite.config.ts启用globals: true、environment: jsdom、root: src因此测试代码里可以直接使用全局 describe/it/expect。约定单测与源码同目录命名采用__tests__/foo.test.ts或foo.spec.ts。仓库现有样例包括 translate.test.ts、abstract-openai.spec.ts、litellm.spec.ts、local-tts.spec.ts、speech-segments.spec.ts、wordLookup.spec.ts、openai-api-path.spec.ts、Markdown.spec.tsx 等。纪律Mock 远程 API、保持快照确定性——尤其是翻译结果类测试不能因为远端模型输出波动导致用例不稳定。2. 端到端测试Playwright命令pnpm test:e2e→playwright testplaywright.config.ts 指定testDir: ./e2e并设置retries: 2。现有用例e2e/下包含 index.spec.ts、hotkey.spec.ts、titlebar.spec.ts配套的 common.ts 提供getOptionsPageUrl(extensionId)、getPopupPageUrl(extensionId)等辅助函数以及selectExampleText(page)模拟鼠标框选测试文本的交互fixtures.ts 与 test.html 提供测试页面与数据。约定UI 流程发生变化时同步更新e2e/*.spec.ts并在提审前跑通pnpm test与pnpm test:e2e。3. 静态检查pnpm linteslint src/**/*.{ts,tsx} --cache与pnpm lint:fix负责 ESLint 检查/自动修复pnpm format用 Prettier 统一格式化src/**/*.{js,jsx,ts,tsx,css,md,json}。编码风格与命名约定AGENTS.md 对代码风格的规定非常具体核心几条如下技术栈TypeScript React 18样式方案采用 Styletronstyletron-engine-atomicstyletron-react见 package.json 依赖从依赖清单看还大量使用 baseui-sd 组件库、jotai/zustand 状态管理、i18next 国际化。格式4 空格缩进、单引号、尾逗号——这些由 Prettier 强制Push 前必须格式化。命名组件用PascalCase如 QuickTranslator.tsx、TranslationHistory.tsxhooks 与工具函数用camelCase如 useSettings.ts、usePinned.ts常量用SCREAMING_SNAKE_CASE如 constants.ts 中的chatgptArkoseReqParams相关常量。复用原则优先复用src/common中的既有助手函数不要重复造轮子src/common是整个项目的逻辑枢纽跨端能力翻译、查词、历史、生词本、TTS、代理测试、动作管理几乎都从这里导出。提交约束pre-commit 钩子要求暂存文件保持 lint 干净lint-staged 配置见上文。提交信息与 Pull Request 规范仓库采用轻量级 Conventional Commits 风格历史中的典型前缀包括fix:、feat:、chore:要求使用简洁的祈使句摘要可附带 scope例如fix: handle streaming fallback需要时可引用 issue 编号(#1234)。这一约定与 scripts/release.py 的发布逻辑相互印证——后者正是从git log中按fix、feat、docs、refactor、optimize、enhance、openai等前缀过滤提交信息来生成 release note因此提交前缀写得越规范自动化发版时的变更说明就越准确。PR 层面AGENTS.md 要求清晰描述变更内容UI 相关的改动附上截图或 GIF列出验证命令如pnpm test、pnpm test:e2e、pnpm lint说明平台覆盖范围Chrome、Firefox、Tauri 桌面端三端——这与仓库多目标架构直接相关改动src/common时三端都要回归改动 manifest 时需分别验证两个浏览器。安全与配置API Key 与敏感默认值AGENTS.md 最后一段强调了安全红线这也是接入新模型提供商时的必经流程绝不提交 API Key 或用户数据运行时配置优先走应用内设置src/common/store/setting.ts是设置中心选项页与桌面端设置窗口都由此驱动或本地.env文件已被 gitignore新增提供商时必须把所需的环境变量键文档化到docs/下——仓库现有 chatgpt.md、kimi.md、chatglm.md 等提供商接入指南正是这一约定的落地产物敏感默认值要放在src/common中由开关toggle控制避免默认开启暴露凭据的能力。浏览器扩展侧的权限边界同样值得留意manifest.ts 只申请了storage、contextMenus、webRequest三个权限host_permissions则按提供商域名精确列出openai.com、azure、moonshot.cn、chatglm.cn、cohere.ai、deepseek.com、dictionaryapi.dev 等新接入引擎时需同步评估是否要追加 host 权限。小结AGENTS.md 虽然篇幅简短却是理解这个仓库的「第一入口文档」它把多目标架构浏览器扩展 / Tauri 桌面端 / 用户脚本 / 划词工具扩展、以src/common为核心的代码复用策略、pnpm Vite Vitest Playwright 的工具链、以及提交发布的安全纪律浓缩成了可执行的开发规范。对照 package.json、Makefile、vite.config.*.ts 与 scripts/release.py 逐条验证后可以发现文档中的每一条命令与约定都能在仓库中找到真实落点——按这份指南动手即可无缝接入 NextAI Translator 的开发与发布流程。【免费下载链接】nextai-translator基于 ChatGPT API 的划词翻译浏览器插件和跨平台桌面端应用 - Browser extension and cross-platform desktop application for translation based on ChatGPT API.项目地址: https://gitcode.com/GitHub_Trending/op/nextai-translator创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 NextAI Translator 仓库开发指南：从目录结构到构建、测试与提交规范
NextAI Translator 仓库开发指南从目录结构到构建、测试与提交规范【免费下载链接】nextai-translator基于 ChatGPT API 的划词翻译浏览器插件和跨平台桌面端应用 - Browser extension and cross-platform desktop application for translation based on ChatGPT API.项目地址: https://gitcode.com/GitHub_Trending/op/nextai-translator本篇指南以仓库根目录的 AGENTS.md 为骨架面向准备为 NextAI Translator 贡献代码或深入阅读源码的开发者系统讲解该基于 ChatGPT API 的划词翻译浏览器插件与跨平台桌面端应用的仓库组织方式、常用开发/构建/测试命令、编码风格、测试规范、提交与 PR 要求以及涉及 API Key 等敏感信息的安全配置要点。读完你可以快速上手pnpm dev-chromium/pnpm dev-tauri双端开发流程理解浏览器扩展与 Tauri 桌面端如何共享一套src/common逻辑并按照仓库既有的约定提交合规的 Pull Request。项目结构一份面向贡献者的顶层地图AGENTS.md 用短短几行勾勒了整个仓库的模块划分结合目录树可以验证其准确性。仓库采用「多目标共享核心」的布局src/browser-extension/浏览器扩展的对外表面popup、options、background以及 manifest 工具链。其中 manifest.ts 通过getManifest(chromium | firefox)生成 Manifest V3 配置并在 Firefox 分支下注入browser_specific_settingsGecko ID和background.scripts数组写法Chrome 则使用service_worker这是双浏览器差异的集中处理点background/index.ts 负责创建右键菜单contextMenus并把流式请求通过 port 转发。src/tauri/桌面端窗口的 React 渲染层windows/ 下按窗口拆分子应用TranslatorWindow、QuickTranslatorWindow、SettingsWindow、HistoryWindow、InlineLookupWindow、ScreenshotWindow、ThumbWindow、UpdaterWindow、WritingIndicatorWindow、ActionManagerWindow配合 Window.tsx 统一承载。src/common/两个目标浏览器扩展与 Tauri 桌面端共用的 hooks、store 与翻译逻辑是「write once, run on both targets」的关键。翻译引擎全部集中在 engines/OpenAI、Claude、Gemini、DeepSeek、Kimi、ChatGLM、Groq、Cohere、Moonshot、Ollama、Azure、LiteLLM 等共享的表单组件在 components/Form/i18n 语言包位于 i18n/locales/en/ja/ko/th/tr/zh-Hans/zh-Hant 共 7 个语言。src-tauri/Rust/Tauri 后端承载原生命令、更新与打包逻辑平台资源位于src-tauri/resources与 src-tauri/icons。支撑性内容public/静态资源、scripts/构建辅助脚本、docs/各模型提供商接入指南、e2e/Playwright 端到端用例、clip-extensions/PopClip / SnipDo 划词扩展。产物目录构建输出落在dist/长期保留的安装包放在release/。AGENTS.md 中提到的dist/与release/均属于构建产物目录本身不进入版本库scripts/下的 release.py 展示了发布流程从 git tag 读取当前版本、按fix/feat/docs/refactor/optimize/enhance/openai前缀过滤git log生成 release note再打新的 annotated tag。环境准备包管理器与依赖安装AGENTS.md 明确要求使用pnpm且包管理器版本被固化在 package.json 的packageManager字段pnpm9.1.3。安装依赖只需pnpm install安装完成后prepare脚本会自动执行pnpm exec simple-git-hooks注册 pre-commit 钩子钩子内部通过lint-staged对暂存文件运行 ESLint 与 Prettier详见 package.json 中simple-git-hooks与lint-staged配置。这意味着从第一次pnpm install起提交时就会被强制约束代码格式。开发调试Chromium 扩展与 Tauri 桌面端AGENTS.md 给出两条开发路径对应的脚本在 package.json 中均有定义命令作用底层实现pnpm dev-chromium以 Vite HMR 启动浏览器扩展开发vite -c vite.config.chromium.tspnpm dev-firefox监听式构建 Firefox 版本扩展NODE_ENVdevelopment vite build -c vite.config.firefox.ts --watchpnpm dev-tauri启动 Tauri 桌面外壳tauri dev渲染层由dev-tauri-renderervite -c vite.config.tauri.ts --force驱动值得注意的实现细节vite.config.chromium.ts 使用samrum/vite-plugin-web-extension插件传入getManifest(chromium)开发模式下关闭 minify、开启 sourcemap产物输出到dist/browser-extension/chromiumFirefox 版本vite.config.firefox.ts额外把静态资源内联阈值提高到 1MBassetsInlineLimit: 1024 * 1024。vite.config.tauri.ts 为 Tauri 定制固定端口3333且strictPort: true端口被占用会直接失败而非自动换端口clearScreen: false避免遮挡 Rust 侧编译错误构建目标[es2020, chrome87, safari14]TAURI_DEBUG环境变量控制是否压缩与生成 sourcemap。三个 Vite 配置都注册了别名指向src/源码内统一用/common/...这类导入路径例如 background/index.ts 中的/common/engines/chatgpt。构建产物浏览器扩展、桌面端与用户脚本AGENTS.md 列出的构建命令同样与 package.json 一一对应实际构建逻辑沉淀在 Makefile 中命令产物pnpm build-browser-extension依次执行tsc类型检查与make build-browser-extensionMakefile 先通过sed把版本号同步进 package.json再用 chromium/firefox 两份 Vite 配置构建最后各自打成dist/browser-extension/chromium.zip与dist/browser-extension/firefox.zippnpm build-taurinpm run build-tauri-renderertsc vite build -c vite.config.tauri.ts后执行tauri build产出桌面安装包pnpm build-userscriptmake build-userscript基于vite.config.userscript.ts与vite-plugin-monkey产出用户脚本pnpm cleanmake clean即rm -rf dist在打包前重置产物目录Makefile 中还包含两个未在 AGENTS.md 提及、但同样有价值的扩展打包目标build-popclip-extension把 clip-extensions/popclip/ 打包为.popclipextz供 macOS PopClip 调用与build-snipdo-extension把 clip-extensions/snipdo/ 打包为.pbar供 SnipDo 使用。如果你要发布到这些划词工具生态可以手动执行make build-popclip-extension/make build-snipdo-extension。版本号统一通过 Makefile 的VERSION变量默认0.1.0配合change-version/change-package-version目标维护与 scripts/release.py 的 tag 驱动版本策略衔接。测试Vitest 单元测试与 Playwright 端到端AGENTS.md 对测试的约定可以拆成三层均有仓库证据支撑1. 单元测试Vitest命令pnpm test→vitest test测试基础设施见 vite.config.ts启用globals: true、environment: jsdom、root: src因此测试代码里可以直接使用全局 describe/it/expect。约定单测与源码同目录命名采用__tests__/foo.test.ts或foo.spec.ts。仓库现有样例包括 translate.test.ts、abstract-openai.spec.ts、litellm.spec.ts、local-tts.spec.ts、speech-segments.spec.ts、wordLookup.spec.ts、openai-api-path.spec.ts、Markdown.spec.tsx 等。纪律Mock 远程 API、保持快照确定性——尤其是翻译结果类测试不能因为远端模型输出波动导致用例不稳定。2. 端到端测试Playwright命令pnpm test:e2e→playwright testplaywright.config.ts 指定testDir: ./e2e并设置retries: 2。现有用例e2e/下包含 index.spec.ts、hotkey.spec.ts、titlebar.spec.ts配套的 common.ts 提供getOptionsPageUrl(extensionId)、getPopupPageUrl(extensionId)等辅助函数以及selectExampleText(page)模拟鼠标框选测试文本的交互fixtures.ts 与 test.html 提供测试页面与数据。约定UI 流程发生变化时同步更新e2e/*.spec.ts并在提审前跑通pnpm test与pnpm test:e2e。3. 静态检查pnpm linteslint src/**/*.{ts,tsx} --cache与pnpm lint:fix负责 ESLint 检查/自动修复pnpm format用 Prettier 统一格式化src/**/*.{js,jsx,ts,tsx,css,md,json}。编码风格与命名约定AGENTS.md 对代码风格的规定非常具体核心几条如下技术栈TypeScript React 18样式方案采用 Styletronstyletron-engine-atomicstyletron-react见 package.json 依赖从依赖清单看还大量使用 baseui-sd 组件库、jotai/zustand 状态管理、i18next 国际化。格式4 空格缩进、单引号、尾逗号——这些由 Prettier 强制Push 前必须格式化。命名组件用PascalCase如 QuickTranslator.tsx、TranslationHistory.tsxhooks 与工具函数用camelCase如 useSettings.ts、usePinned.ts常量用SCREAMING_SNAKE_CASE如 constants.ts 中的chatgptArkoseReqParams相关常量。复用原则优先复用src/common中的既有助手函数不要重复造轮子src/common是整个项目的逻辑枢纽跨端能力翻译、查词、历史、生词本、TTS、代理测试、动作管理几乎都从这里导出。提交约束pre-commit 钩子要求暂存文件保持 lint 干净lint-staged 配置见上文。提交信息与 Pull Request 规范仓库采用轻量级 Conventional Commits 风格历史中的典型前缀包括fix:、feat:、chore:要求使用简洁的祈使句摘要可附带 scope例如fix: handle streaming fallback需要时可引用 issue 编号(#1234)。这一约定与 scripts/release.py 的发布逻辑相互印证——后者正是从git log中按fix、feat、docs、refactor、optimize、enhance、openai等前缀过滤提交信息来生成 release note因此提交前缀写得越规范自动化发版时的变更说明就越准确。PR 层面AGENTS.md 要求清晰描述变更内容UI 相关的改动附上截图或 GIF列出验证命令如pnpm test、pnpm test:e2e、pnpm lint说明平台覆盖范围Chrome、Firefox、Tauri 桌面端三端——这与仓库多目标架构直接相关改动src/common时三端都要回归改动 manifest 时需分别验证两个浏览器。安全与配置API Key 与敏感默认值AGENTS.md 最后一段强调了安全红线这也是接入新模型提供商时的必经流程绝不提交 API Key 或用户数据运行时配置优先走应用内设置src/common/store/setting.ts是设置中心选项页与桌面端设置窗口都由此驱动或本地.env文件已被 gitignore新增提供商时必须把所需的环境变量键文档化到docs/下——仓库现有 chatgpt.md、kimi.md、chatglm.md 等提供商接入指南正是这一约定的落地产物敏感默认值要放在src/common中由开关toggle控制避免默认开启暴露凭据的能力。浏览器扩展侧的权限边界同样值得留意manifest.ts 只申请了storage、contextMenus、webRequest三个权限host_permissions则按提供商域名精确列出openai.com、azure、moonshot.cn、chatglm.cn、cohere.ai、deepseek.com、dictionaryapi.dev 等新接入引擎时需同步评估是否要追加 host 权限。小结AGENTS.md 虽然篇幅简短却是理解这个仓库的「第一入口文档」它把多目标架构浏览器扩展 / Tauri 桌面端 / 用户脚本 / 划词工具扩展、以src/common为核心的代码复用策略、pnpm Vite Vitest Playwright 的工具链、以及提交发布的安全纪律浓缩成了可执行的开发规范。对照 package.json、Makefile、vite.config.*.ts 与 scripts/release.py 逐条验证后可以发现文档中的每一条命令与约定都能在仓库中找到真实落点——按这份指南动手即可无缝接入 NextAI Translator 的开发与发布流程。【免费下载链接】nextai-translator基于 ChatGPT API 的划词翻译浏览器插件和跨平台桌面端应用 - Browser extension and cross-platform desktop application for translation based on ChatGPT API.项目地址: https://gitcode.com/GitHub_Trending/op/nextai-translator创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考