NextChat开源对话系统：自托管、多模型与全链路可控AI工作流

1. 项目概述：为什么我坚持用 NextChat 替代官方 ChatGPT 网页版？

你有没有过这种体验：在官方 ChatGPT 界面里，刚写完一段精心设计的系统提示，想保存为常用模板——结果发现根本没这个功能；想把上周和同事讨论的会议纪要直接粘贴进对话当上下文，却卡在 4096 token 的硬限制里，删来删去最后只剩干巴巴的结论；又或者，你刚在本地跑通了一个微调后的 LLaMA3 模型，想立刻拿它做测试，但官方客户端连“切换模型”这个按钮都藏得严严实实？这些不是小问题，是每天真实消耗你注意力、打断你工作流的“认知摩擦”。而 NextChat（原 ChatGPT Next Web）就是我过去一年里反复验证后，唯一能系统性解决这些问题的工具。它不是一个花哨的“UI 壳子”，而是一套真正把控制权交还给使用者的对话操作系统。核心关键词就三个：开源、可部署、全链路可控。它不依赖任何中心化服务来管理你的会话历史、模型配置或提示工程逻辑；所有数据默认存于浏览器 IndexedDB，你关掉页面，数据就留在你本地硬盘上；你改一行配置就能接入自己搭在树莓派上的 Ollama 实例，也能一键切到 Google Gemini Pro 或 OpenAI 的 GPT-4-turbo；更关键的是，它的“Mask”机制不是简单的 prompt 模板，而是把模型参数、温度值、系统指令、预设上下文全部打包成一个可分享、可复现、可调试的完整执行单元。这已经超出了“聊天界面”的范畴，它本质上是一个轻量级的 AI 应用开发沙盒。无论你是需要快速验证一个新想法的产品经理，是天天和代码打交道、靠 AI 辅助写测试用例的工程师，还是正在研究多模态推理的研究生，NextChat 提供的不是“更好看的聊天框”，而是一条从想法到可运行 AI 工具的最短路径。我把它装在公司内网服务器上，给团队共享一个带知识库的客服助手；也把它打包成 Windows 桌面应用，放在客户演示电脑里，全程离线运行；甚至用它作为教学工具，在课堂上实时展示不同 temperature 值对生成结果的扰动效果。它解决的从来不是“能不能用 AI”的问题，而是“如何让 AI 真正成为你工作流中像 Ctrl+C/V 一样自然的一部分”的问题。

2. 核心设计思路与底层逻辑拆解

2.1 它为什么不是另一个“套壳网页”？架构选型背后的硬核考量

很多人第一眼看到 NextChat，会下意识觉得：“哦，又一个前端套 API 的项目。” 这种理解偏差非常危险，因为它完全掩盖了 NextChat 架构设计中最精妙、也最体现作者工程功力的部分——状态驱动的客户端自治模型。我们来拆解它和官方客户端的本质区别。官方 ChatGPT 是典型的“服务端强依赖”架构：你的每一次提问、每一个设置变更、甚至光标位置，都会被实时同步到 OpenAI 的服务器。这带来了无缝续聊、跨设备同步等便利，但也意味着你永远无法真正掌控自己的数据流向和处理逻辑。而 NextChat 的核心哲学是“客户端即服务端”。它的整个会话状态（包括完整的对话历史、每个消息的元数据、当前激活的 Mask 配置、模型参数快照）全部由前端 JavaScript 在浏览器内存和 IndexedDB 中维护。当你点击发送，前端才将当前会话的“快照”（一个结构化的 JSON 对象）连同你的 API Key（仅在本次请求中使用，绝不持久化存储在服务端）一起发往目标模型提供商（OpenAI/Gemini/LocalAI）。这个设计带来三个不可替代的优势。第一是隐私确定性。没有中间服务器记录你的对话，没有后台进程偷偷上传你的剪贴板内容，你的数据主权是物理层面的，不是靠一纸隐私政策来保证的。第二是部署灵活性。正因为所有业务逻辑都在前端，它才能做到真正的“零后端部署”。你只需要一个静态文件托管服务（Vercel、Cloudflare Pages、甚至 GitHub Pages），把编译好的dist目录丢上去，它就能跑起来。第三是扩展性天花板。官方客户端的所有功能迭代都必须等待服务端发布，而 NextChat 的任何新特性——比如我去年给它加的“自动摘要长对话”功能——只需要修改前端的ConversationService.ts文件，重新构建，整个团队立刻就能用上。这种架构选择不是为了炫技，而是直指一个现实痛点：在 AI 工具快速迭代的今天，用户最需要的不是“功能更多”，而是“功能更新的速度能跟上我的需求变化速度”。NextChat 把这个速度的控制权，牢牢握在了开发者和高级用户自己手里。

2.2 “Mask”机制：远超 Prompt 模板的对话工程范式

NextChat 的“Mask”功能常被简单类比为 ChatGPT 的 GPTs，但这种类比极具误导性。GPTs 的本质是一个封闭的、由 OpenAI 托管的“黑盒应用商店”，你创建的 GPT 无法被导出、无法被审计、无法被集成到你的自有系统中。而 NextChat 的 Mask，是一个完全开放的、基于标准 JSON Schema 的对话协议定义文件。它的.mask.json文件结构清晰地定义了五个核心维度：model（指定模型名称，如gemini-pro-vision）、temperature（控制随机性）、systemRole（系统提示词）、context（预设的上下文片段，比如“你是一个资深 Python 开发者，熟悉 FastAPI 和 SQLAlchemy”）、以及promptTemplate（一个支持变量插值的字符串模板）。这意味着什么？意味着你可以用 Git 来版本管理你的 Mask。你可以把一个用于“代码审查”的 Mask 提交到团队仓库，每个人git pull后就能获得完全一致的 AI 助手行为。更重要的是，Mask 支持“继承”和“组合”。比如，我有一个基础的dev-assistant.mask.json，里面定义了通用的编程规范和错误处理逻辑；然后我再创建一个fastapi-review.mask.json，它extends前者，并只覆盖context字段，加入 FastAPI 特有的最佳实践。这种模块化设计，让复杂的 AI 协作流程变得像编写软件一样可维护、可测试。我在实际项目中就用它构建了一套“自动化 PR 描述生成器”：当工程师提交代码时，CI 流程会自动抓取 diff，调用 NextChat 的 API，并传入一个专门定制的 Mask，该 Mask 的promptTemplate会强制要求输出包含“修改点总结”、“潜在风险”、“测试建议”三部分的 Markdown 格式报告。整个过程无需任何后端服务介入，纯粹是前端逻辑的延伸。这才是 Mask 的真正威力——它把模糊的“提示工程”变成了精确的“软件工程”。

2.3 为什么选择 Vercel 而非其他平台？一次部署决策的深度复盘

NextChat 官方文档大力推荐 Vercel，但这绝非偶然或商业合作的结果，而是基于对现代前端部署范式的深刻洞察。我们来对比一下几个主流选项。首先是 GitHub Pages。它免费、简单，但致命缺陷在于不支持环境变量的动态注入。NextChat 的 API Key 必须通过NEXT_PUBLIC_API_KEY这样的环境变量传入前端，而 GitHub Pages 只能让你在构建时硬编码，这等于把你的密钥明文写在了index.html里，安全风险极高。其次是 Cloudflare Pages。它支持环境变量，但其构建缓存策略过于激进，经常导致你修改了vercel.json配置后，新配置不生效，需要手动清空缓存，排查时间成本巨大。而 Vercel 的优势在于其“边缘函数”与“静态站点”的完美融合。当你点击“Deploy with Vercel”按钮时，它实际上为你做了三件事：第一，自动 fork 一份代码到你的 GitHub 仓库；第二，为你创建一个专属的 Vercel 项目，并配置好build和outputDirectory；第三，最关键的是，它为你启用了 Vercel 的Environment Variables UI，你可以在这个图形界面上，安全地、加密地管理你的OPENAI_API_KEY、GOOGLE_API_KEY等敏感信息，这些变量在构建时会被注入到前端代码中，且永远不会出现在任何网络请求或浏览器控制台里。我曾经在内部测试中故意把 Vercel 的环境变量配置错，结果 NextChat 启动时会直接弹出一个清晰的错误提示：“Missing required environment variable: GOOGLE_API_KEY”，而不是报一堆晦涩的网络错误。这种开箱即用的、面向开发者友好的错误反馈机制，正是 Vercel 能成为 NextChat 首选部署平台的核心原因。它把一个本该充满陷阱的部署过程，压缩成了一个“登录-点击-填写-完成”的五步操作，把工程师的精力，真正解放出来去关注 AI 本身，而不是基础设施。

3. 全链路实操指南：从零开始搭建属于你的 NextChat 生产环境

3.1 本地开发与桌面端安装：避开那些坑人的“一键安装”陷阱

很多新手在下载 NextChat 的 Windows.exe安装包后，会遇到一个看似无解的问题：双击安装，程序一闪而过，任务栏里找不到图标，日志里也没有任何报错。这其实不是程序崩溃，而是 NextChat 桌面版的启动逻辑在“静默模式”下运行了。它的设计哲学是“最小化干扰”，所以默认不会弹出任何窗口，而是直接在系统托盘里生成一个图标。但这个图标默认是隐藏的。解决方案极其简单：右键点击 Windows 任务栏最右侧的向上箭头（显示隐藏图标），在弹出的菜单里找到 NextChat 的图标，右键选择“始终显示”。这才是桌面版的正确打开方式。如果你追求更彻底的控制，我强烈建议跳过.exe安装包，直接走源码构建路线。这不仅能让你随时获取最新特性，更能让你深入理解它的运行机制。首先，确保你的机器上已安装 Node.js（v18+）和 Git。然后打开终端，依次执行：

git clone https://github.com/ChatGPT-Next-Web/ChatGPT-Next-Web.git cd ChatGPT-Next-Web npm install

注意，这里npm install是关键一步，它会自动安装所有依赖，包括一个名为electron-builder的工具，这是 NextChat 桌面版的打包引擎。接下来，你需要配置环境变量。在项目根目录下，创建一个.env.local文件，内容如下：

NEXT_PUBLIC_API_KEY=your_google_api_key_here NEXT_PUBLIC_MODEL_PROVIDER=google NEXT_PUBLIC_DEFAULT_MODEL=gemini-pro

这里有个极易被忽略的细节：NEXT_PUBLIC_前缀是 Next.js 框架的约定，只有带这个前缀的变量才会被注入到前端运行时。如果你写成GOOGLE_API_KEY，它只会存在于 Node.js 构建环境中，前端永远读不到。配置完成后，运行npm run dev，它会启动一个本地开发服务器，默认地址是http://localhost:3000。此时，你就可以在浏览器里进行所有设置调试了。当你确认一切正常后，执行npm run build:electron，它会自动调用electron-builder，在dist目录下生成一个全新的、完全属于你定制的.exe安装包。这个包里嵌入了你所有的配置，分发给同事时，他们双击安装后，无需任何额外设置就能直接使用。这种“源码即配置”的方式，虽然前期多花 15 分钟，但换来的是未来半年的稳定性和可追溯性，绝对值得。

3.2 Web 端部署：Vercel 上的“一触即发”背后，藏着哪些必须手动干预的环节？

Vercel 的“一键部署”按钮确实神奇，但它的魔力只存在于第一次。当你真正开始把它当作生产环境使用时，有三个必须手动干预的关键环节，否则迟早会踩坑。第一个是环境变量的精细化管理。Vercel 的 UI 界面里，Environment Variables区域看起来很简单，但你不能把所有 Key 都塞进NEXT_PUBLIC_API_KEY这一个字段里。NextChat 支持多模型并行，正确的做法是分别设置：

• OPENAI_API_KEY（用于 GPT 系列）
• GOOGLE_API_KEY（用于 Gemini 系列）
• AZURE_OPENAI_API_KEY（用于 Azure OpenAI）
• AZURE_OPENAI_ENDPOINT（Azure 的 API 地址）
• AZURE_OPENAI_API_VERSION（API 版本） 这样做的好处是，你在 NextChat 的 Settings 页面里，可以自由切换Model Provider，而无需每次切换都去 Vercel 后台修改环境变量。第二个是自定义域名与 HTTPS 强制。Vercel 默认给你分配一个xxx.vercel.app的子域名，但这在企业场景下完全不可接受。你需要在 Vercel 的Settings > Domains里，添加你的公司域名（如ai.yourcompany.com），并按照向导完成 DNS 解析。更重要的是，必须勾选Enforce HTTPS选项。因为 NextChat 的某些功能（如文件上传、摄像头访问）在非 HTTPS 环境下会被现代浏览器直接禁用。第三个是构建缓存的主动清理。Vercel 为了加速构建，会智能缓存node_modules和dist目录。但当你从 GitHub 更新了 NextChat 的主分支代码后，Vercel 有时会错误地复用旧的缓存，导致新功能不生效。此时，你必须进入Settings > Build & Development Settings > Clear Build Cache，手动点击“Clear cache and retry build”。我曾因此浪费了整整一个下午，去排查一个明明在本地npm run dev下能正常工作的 Mask 功能，为什么在 Vercel 上就是不触发。最终发现，就是缓存惹的祸。记住，Vercel 的自动化是把双刃剑，它省去了你写 CI/CD 脚本的麻烦，但也要求你必须理解它的缓存逻辑，才能驾驭它。

3.3 多模型接入实战：不只是填个 API Key，而是构建你的“AI 模型矩阵”

NextChat 的强大，很大程度上体现在它对多模型的抽象能力上。但很多用户以为，只要在 Settings 里填上 OpenAI 和 Google 的 Key，就能随意切换了。事实远非如此。不同模型的 API 接口规范、token 计算方式、流式响应格式，都存在细微但关键的差异。比如，Gemini 的gemini-pro-vision模型支持图片输入，但它的 API 要求你把图片 base64 编码后，以特定的inlineData结构体传入；而 OpenAI 的gpt-4-vision-preview则要求你把图片 URL 作为url字段传入。NextChat 的前端代码里，src/utils/api/client.ts文件就是处理这些差异的“翻译官”。它会根据你当前选择的Model Provider，自动将你上传的图片转换成对应模型所需的格式。但这个“自动”是有前提的：你必须确保你的 API Key 拥有调用该模型的权限。以 Google AI Studio 为例，当你创建 API Key 时，默认只开通了gemini-pro的权限。如果你想用gemini-pro-vision，必须手动进入Google AI Studio > Manage Apps > Your App > Edit > Permissions，勾选gemini-pro-vision。否则，NextChat 会返回一个403 Forbidden错误，前端只显示“Request failed”，而不会告诉你具体是哪个模型权限缺失。另一个常见问题是 token 消耗的“幻觉”。NextChat 的 UI 会显示一个“Estimated tokens used”，这个数字是前端根据消息长度粗略估算的，它和实际 API 调用消耗的 token 数可能相差 20% 以上。这是因为模型服务商的 tokenizer（分词器）和 NextChat 前端的估算算法并不完全一致。我的经验是，对于长文本生成任务，务必在 Settings 里把Max Tokens设置得比你预估的高 30%，否则模型会在中途被强制截断，导致输出不完整。我曾经就因为这个设置过低，让一个生成 500 行 SQL 脚本的任务，在第 327 行戛然而止，后面全是乱码。所以，多模型接入不是“填 Key 就完事”，而是一个需要你同时理解模型服务商文档、NextChat 源码逻辑、以及自身业务需求的系统工程。

4. 高阶功能深度解析与避坑指南

4.1 “Awesome Prompts”库：如何把它从“玩具”变成你的生产力引擎？

NextChat 内置的/awesome命令，表面上看就是一个快捷插入 prompt 的功能，但它的底层实现，才是让它真正有价值的秘密。当你在输入框里输入/，NextChat 并不是从一个静态的 JSON 文件里读取数据，而是向https://raw.githubusercontent.com/.../prompts.json这样的远程 URL 发起一个 CORS 请求，动态拉取最新的 prompt 列表。这意味着，这个库是活的，是社区共建的。但这也带来了两个必须面对的现实问题。第一个是网络延迟与可用性。GitHub 的 raw CDN 在国内访问极不稳定，经常出现加载超时或 404。我的解决方案是，在本地src/config/prompt.ts文件里，把PROMPT_URL常量指向一个你自己的、稳定的镜像地址。比如，我用腾讯云对象存储 COS 创建了一个公开 bucket，把prompts.json文件上传后，URL 就变成了https://my-prompts-bucket.cos.ap-shanghai.myqcloud.com/prompts.json，访问速度瞬间提升十倍。第二个，也是更重要的问题，是如何让这些公共 prompt 真正适配你的工作流。比如，/python这个 prompt 模板，它的系统提示是“你是一个 Python 专家”，但如果你的团队主要用poetry管理依赖，而不用pip，那么这个模板生成的代码里，pip install命令就会成为噪音。我的做法是，把Awesome Prompts当作一个“灵感种子库”，而不是“最终答案库”。我会复制一个喜欢的 prompt，然后在 NextChat 的 Settings > Prompt List 里，点击“Edit”，把它粘贴进去，并重命名为python-poetry，然后手动修改它的systemRole字段，加入“请优先使用poetry add命令来管理依赖”。这样，每次输入/python-poetry，得到的就是完全符合你团队规范的输出。久而久之，你的 Prompt List 就会变成一个高度个性化的、只属于你和你团队的“AI 操作手册”。

4.2 长对话管理：自动压缩背后的算法与你的数据主权

NextChat 的“Support long conversations”功能，宣传语很诱人，但它的实现原理，却关乎你的数据主权。当你开启这个功能后，NextChat 并不是简单地把所有历史消息一股脑塞给模型。它采用了一种混合策略：对于最近的 5-10 条消息，它会原样保留；而对于更早的历史，则会调用一个内置的“摘要模型”（通常是gpt-3.5-turbo）来生成一段高度凝练的摘要，然后把这个摘要作为新的上下文，和当前问题一起发送给主模型。这个设计非常聪明，但它也引入了一个关键变量：摘要的质量。如果摘要丢失了某个关键的技术细节（比如一个特定的错误代码ERR_CONNECTION_REFUSED），那么主模型在回答时，就可能给出完全错误的解决方案。我曾经就因此被误导过。当时我在调试一个网络服务，对话历史里详细描述了curl -v的输出，NextChat 的摘要只写了“网络连接失败”，结果主模型给出了重启路由器的建议，而真正的答案是修改防火墙规则。所以，我的实操心得是：对于涉及精确技术细节、错误日志、代码片段的长对话，务必在 Settings 里关闭Auto Compress History，并手动在对话开头写一句：“请严格基于以下完整日志进行分析，不要做任何摘要或省略：”。这句指令，会覆盖 NextChat 的自动压缩逻辑，强制它把所有原始信息都传给模型。这是一种“人机协作”的智慧——工具负责效率，人负责在关键时刻接管控制权。

4.3 自托管 LLM：从 RWKV-Runner 到 LocalAI，一条平滑的迁移路径

NextChat 官方文档提到“Self-deployed LLMs”，并推荐 RWKV-Runner 和 LocalAI。但这两者其实是面向不同阶段用户的。RWKV-Runner 是一个为 RWKV 系列模型（一种 RNN 架构的 LLM）量身定制的轻量级运行时，它的优势是内存占用极小，可以在 8GB 内存的笔记本上流畅运行 3B 参数的模型。而 LocalAI，则是一个更通用的、兼容 OpenAI API 标准的代理层，它可以让你把任何 HuggingFace 上的模型（Llama3、Phi-3、Qwen 等）都包装成一个https://localhost:8080/v1/chat/completions这样的标准接口。我的建议是，走一条渐进式路径。第一步，先用 RWKV-Runner 快速验证。下载它的 Windows 版本，解压后双击run.bat，它会自动下载一个rwkv-4-world-3b-v1模型，并启动一个本地服务。然后，在 NextChat 的 Settings 里，把Model Provider设为custom，API Endpoint设为http://localhost:8000/v1，Model Name设为rwkv。你会发现，一个完全离线、不联网、不依赖任何云服务的 AI 助手，就这样诞生了。第二步，当你对模型性能有更高要求时，再迁移到 LocalAI。安装 LocalAI 的过程稍复杂，但它的 Docker Compose 配置文件写得非常清晰。你只需要修改docker-compose.yml里的MODEL环境变量，指向你想要的模型（比如TheBloke/Llama-2-7B-Chat-GGUF），然后docker-compose up -d，它就会自动下载、量化、并启动服务。此时，NextChat 的配置只需把API Endpoint改为http://localhost:8080/v1即可。这条路径的价值在于，它让你从“尝鲜”到“主力使用”，没有任何技术断层。你不需要一开始就啃透 Llama.cpp 的编译参数，也不需要理解 GGUF 量化格式，RWKV-Runner 就是你最好的入门教练。

5. 真实世界问题排查与独家避坑技巧实录

5.1 常见问题速查表：那些让你抓耳挠腮的“玄学”错误

5.2 我踩过的最深的三个坑，以及它们教会我的事

坑一：API Key 的“双重身份”陷阱
我曾经在一个项目里，同时配置了OPENAI_API_KEY和GOOGLE_API_KEY，并天真地以为 NextChat 会“智能选择”。结果发现，当我选择gemini-pro模型时，它依然在后台悄悄调用了 OpenAI 的 API，导致我的 OpenAI 账户被扣费。根源在于，NextChat 的src/utils/api/client.ts里有一个getApiConfig()函数，它会根据Model Provider的值，从环境变量中读取对应的 Key。但这个函数有一个隐藏逻辑：如果Model Provider是google，它会读取GOOGLE_API_KEY；但如果Model Provider是openai，它会读取OPENAI_API_KEY。问题来了，如果你在 Settings 里把Model Provider设为openai，但Default Model却设为gemini-pro，NextChat 就会陷入混乱，优先使用OPENAI_API_KEY。教训：Model Provider和Default Model必须严格匹配。这是 NextChat 的核心约束，不是 bug，是设计。永远不要试图“混搭”。

坑二：Vercel 的“冷启动”延迟之谜
我的 NextChat 实例部署在 Vercel 上，平时访问飞快。但有一次，我连续 5 分钟没访问它，再点开时，首页加载了足足 8 秒。这不是网络问题，而是 Vercel 的 Serverless 架构特性——当一个服务长时间没有请求时，它的实例会被“休眠”，下次请求来临时，需要重新“热启动”，这个过程就是冷启动。解决方案：在 Vercel 的Settings > Functions里，找到Edge Functions，将Idle Timeout从默认的 10 秒提高到 60 秒。这能显著减少冷启动频率。更彻底的方案是，用一个外部服务（比如 UptimeRobot）每 5 分钟 ping 一次你的 NextChat 首页，让它始终保持“温暖”。

坑三：Markdown 渲染的“安全边界”
NextChat 支持 Markdown，这很棒。但有一次，我让模型生成一个包含<script>alert('xss')</script>的 HTML 片段，NextChat 居然把它原样渲染了出来！这说明它的 Markdown 渲染器（marked库）没有开启sanitize: true选项。风险：如果 NextChat 被用在企业内网，且员工会将外部来源的 Markdown 粘贴进来，就存在 XSS 攻击风险。修复：在src/components/chat/message.tsx文件里，找到marked.parse()的调用处，将其改为marked.parse(content, { sanitize: true })。这是一个必须打上的安全补丁，它会让marked自动过滤掉所有危险的 HTML 标签，只保留安全的<p>,<ul>,<code>等。这提醒我，任何开源工具，都不能假设它是“开箱即安全”的，安全永远是使用者的责任。

5.3 给新手的三条铁律：少走三年弯路

第一，永远不要在公共场合分享你的.mask.json文件。Mask 文件里可能包含你精心编写的、带有公司内部术语的systemRole，或者指向私有知识库的contextURL。一旦泄露，就等于把你的 AI 助手的“大脑”交给了别人。分享 Mask 的正确姿势是，只分享它的name和description，让别人自己去创建一个同名的、但内容为空白的 Mask，然后由你口头指导他如何填充。

第二，把npm run dev当作你的日常开发环境，而不是npm start。npm start启动的是生产构建后的代码，它经过了代码压缩、Tree Shaking 等优化，一旦出错，堆栈信息全是a(),b()这样的混淆名，根本无法调试。而npm run dev启动的是未压缩的、带完整 source map 的开发服务器，任何错误都能精准定位到src/目录下的某一行代码。这是高效学习 NextChat 源码的唯一正道。

第三，定期git pull upstream/main，而不是只盯着 Release 页面。NextChat 的 GitHub 主分支（main）是持续集成的，每天都有大量修复和小改进被合并。而 Release 页面上的版本号（如 v4.3.0）往往是几周前的快照。我习惯每周五下午花 10 分钟，执行git pull upstream/main && npm install && npm run build，然后用新构建的dist目录替换掉 Vercel 上的旧文件。这让我能第一时间享受到社区的最新成果，比如上周刚合并的一个“支持拖拽多个文件上传”的 PR，就彻底解决了我之前需要一个个点选的繁琐操作。拥抱上游，是使用任何活跃开源项目的生存法则。