不想订阅几十美元？用开源项目做一个只服务自己的 AI 小工具

你有没有经历过这种时刻？

打开一个工具，发现它正好能解决你的问题。点进价格页，月付 20 美元、39 美元，甚至更高。你心里一算：我一个月可能只用 5 次，凭什么交全年会员？

如果它是 Claude、Codex 这类底层能力很强的产品，花钱确实省心。可很多所谓“AI 工具”，本质上只是把几段流程、几个接口和一个漂亮页面装进盒子里。

这类需求，完全可以自己做。

目标也别定得太大。不是去挑战一个 SaaS 团队，而是做一个刚好够你用的小工具：每天帮你整理会议纪要、批量改商品标题、把 PDF 变成知识卡片，或者一键生成固定格式的周报。

能让你少点十次鼠标，早点下班半小时，它就值回票价了。💰

一个关键思路：别造轮子，改轮子

自己做工具，最容易踩的坑就是一上头：

“我要从零写一个完整产品。”
“我要自己训练模型。”
“这个界面得像商业软件一样精致。”
“顺手加个账号系统、支付系统、多端同步。”

然后项目死在第一个周末。

更靠谱的路线很朴素：

找到 80% 符合需求的开源项目，只改剩下的 20%。

开源世界里，已经有人写好了大量基础能力：文件上传、文本切分、模型调用、工作流编排、数据库存储、网页界面、Docker 部署。

你要做的，是把这些零件接起来，删掉没用的按钮，把流程改成自己的习惯。

别看不起“拼装”。真正能持续使用的个人工具，大多就是这么长出来的。

开工前，先把需求砍到只剩一件事

很多人说“我要做一个 AI 助手”，这句话等于没说。

你得把需求描述成一个具体场景。越具体，越容易找到现成项目。

比如下面这些描述，完全不一样：

| 模糊想法 | 可以直接动手的需求 | | --- | --- | | 做一个写作工具 | 粘贴一篇口语化文案，自动输出适合公众号发布的标题、摘要和 Markdown 正文 | | 做一个知识库 | 把公司的 PDF 和 Word 丢进去，员工可以问“报销上限是多少” | | 做一个图片工具 | 上传商品白底图，自动生成适合小红书封面的 3 张场景图 | | 做一个数据助手 | 每天把 Excel 销售表上传，自动标出销量跌幅超过 20% 的商品 |

给你的需求加上这四个限制：

输入是什么：一段文字、一个文件夹、Excel、网页链接，还是图片？
输出是什么：表格、Markdown、邮件、图片，还是一份 PDF？
使用频率多高：一天 20 次，还是一个月 2 次？
谁来用：只有你自己，还是团队里 10 个人？

写完后，试着压缩成一句话：

上传会议录音，自动转文字，并按“结论、待办、负责人、截止时间”输出纪要。

这句话就是你找开源项目时的搜索词，也是你后面防止需求膨胀的护身符。

怎么找能用的开源项目？别只看 GitHub 星标

GitHub 搜索时，直接用“功能 + 技术栈”组合搜。

例如：

AI meeting summary self hosted
PDF RAG local deployment
image generation webui docker
Excel AI analysis Python

中文搜不到时，换英文。开源项目的文档、Issue 和示例通常都在英文环境里。

挑项目时，别被几万 Star 迷住。你更该检查这几件事：

1. 有没有清晰的安装文档

如果 README 只有一句“clone 后运行”，你大概率要开始考古。

优先选带这些内容的项目：

docker compose up 一类的部署命令
环境变量说明
示例截图或演示地址
常见报错处理
模型或 API 配置说明

2. 最近有没有人在维护

看一下最近一次提交、Issue 回复速度和版本发布记录。

一个两年前就停更、Issue 堆成山的项目，可能能跑，但你改到一半就会掉进坑里。

3. 能不能先跑起来

别一上来读源码。

先把项目跑起来，点一遍页面，确认它已经覆盖你的核心流程。能跑通，才值得改。

4. 许可证能不能接受

个人自用通常问题不大。要给公司、客户或公开用户使用时，必须看 LICENSE。

常见情况：

MIT / Apache-2.0：限制相对少，商用也常见。
GPL / AGPL：分发、部署和修改时可能有源码公开义务。
非商业许可证：别拿去收费，也别硬塞进公司产品。

这一步有点枯燥，却能避免后面“工具做完了才发现不能用”的尴尬。

一套适合个人的最小技术方案

你不需要搭建庞大架构。对大多数个人 AI 工具，这套组合已经够用：

网页界面：Streamlit / Gradio
业务逻辑：Python
模型能力：OpenAI 兼容 API、Claude API 或本地模型
数据存储：SQLite / 本地文件
部署方式：Docker Compose

它的好处很直接：

页面不用从零写前端。
Python 处理文本、表格和文件特别顺手。
SQLite 不用部署数据库服务。
Docker 能把“我电脑能跑”变成“换台电脑也能跑”。

一个典型例子：把文本处理流程做成网页工具

假设你经常需要把长文整理成固定格式的内容。

原来的流程可能是：打开聊天工具 → 粘贴内容 → 输入提示词 → 复制结果 → 再排版。

一天做几次还行。连续做一个月，鼠标都要冒烟。

你可以做一个极简页面：

粘贴原始内容。
选择输出风格。
点击“生成”。
自动得到标题、摘要、标签和 Markdown 正文。
点击复制或下载文件。

核心代码甚至可以很短：

import streamlit as st
from openai import OpenAI

client = OpenAI(
    api_key=st.secrets["API_KEY"],
    base_url=st.secrets["BASE_URL"]
)

st.title("我的内容整理工具")
source_text = st.text_area("粘贴原文", height=300)

if st.button("生成") and source_text:
    prompt = f"""
你是一名内容编辑。请将下面内容整理成 JSON，字段包含：
标题、摘要、标签、Markdown 正文。

原文：
{source_text}
"""

    response = client.chat.completions.create(
        model="your-model-name",
        messages=[{"role": "user", "content": prompt}]
    )

    st.write(response.choices[0].message.content)

别嫌它简陋。先让它稳定完成任务，再考虑加历史记录、模板管理、批量处理这些功能。

改造开源项目时，只动“离你最近”的那层

很多人打开项目源码，看到几十个目录就慌了。其实个人改造通常只需要碰三类文件：

配置文件：模型地址、密钥、端口、默认参数。
提示词模板：输出格式、语气、字段规则。
界面文件：删掉你不用的功能，加一个按钮或输入框。

比如一个通用知识库工具有 15 个模型选项、8 种检索策略、4 套权限系统。你自己用时，完全可以：

默认锁定一个模型。
隐藏高级参数。
删除注册登录。
只保留“上传文件”和“开始提问”。

工具越贴合你的工作流，越不容易吃灰。

这里有个很实用的判断标准：

每增加一个功能，都问自己：未来 30 天，我会不会主动点它三次？

答案是否定的，直接砍掉。

API 费用和订阅费，别混着算

“不订阅”不等于“完全零成本”。

如果你的工具调用云端模型，还是会产生 API 费用。区别在于：订阅费像办健身卡，你去不去都扣钱；API 更像按次付费，用多少算多少。

举个场景：

你每周整理 3 篇文章。
每篇消耗的模型调用成本只有几毛钱。
一个月可能只花几元到十几元。

这时，按量付费通常比每月固定订阅更舒服。

如果你的任务涉及敏感文件，或者调用频率非常高，可以考虑本地模型。但要接受现实：本地部署需要显卡、内存、磁盘，还要花时间调参数。为了省 20 美元，折腾两天服务器，这笔账也得算。

钱可以省，时间也有价格。别把省钱做成高价爱好。😂

避坑清单：这几个坑真的很常见

1. 把 API Key 写进代码并上传 GitHub

这是新手最危险的失误之一。

密钥放到 .env 文件里，并把它加入 .gitignore：

.env
.env.local
secrets.toml

一旦密钥泄露，立刻去服务商后台废弃旧 Key，再创建新的。不要抱着“应该没人看到吧”的侥幸心理。

2. 一开始就部署到公网

你的工具还没跑稳，先别急着买服务器、配域名、开公网端口。

本地跑通后，再用 Docker 部署到服务器。需要远程访问时，至少加上登录验证，别把带有 API Key 的后台裸奔在公网。

3. 没有准备测试样本

做文本工具时，准备 5 到 10 份真实样本：短文本、超长文本、格式混乱的文本、空内容、带表格的内容。

别只拿一份完美素材测试。真实世界的数据，往往像从洗衣机里捞出来的耳机线一样乱。

4. 输出格式完全交给模型自由发挥

你想要 JSON，就明确要求 JSON；你要 Markdown，就给模板；你要表格，就写清列名。

更稳的提示词写法：

请严格按以下格式输出，不要添加解释：

# 标题

## 摘要

## 待办事项
- [ ] 任务：
  负责人：
  截止时间：

格式越明确，后续自动处理越省事。

5. 把“能跑”误认为“能长期用”

能跑只是开始。

你至少要补上这几个小动作：

给关键操作加错误提示。
保存常用配置。
导出结果时带日期。
定期备份数据目录。
记录每次模型调用的输入和报错信息。

不然过两周你自己都不知道哪里坏了。

一个 3 小时能完成的行动计划

别收藏，今晚就挑一个小需求开干。

第 1 小时：确定一个高频痛点

翻一下你最近一周的工作记录。

找那些重复出现、步骤固定、又让人烦躁的事情。比如：

每次都要把录音整理成会议纪要。
每天要把客服问题归类。
总要把一堆链接提炼成选题库。
经常要给产品图生成固定规格的文案。

只选一个。

第 2 小时：找项目并跑通

去 GitHub 搜英文关键词。

下载两个候选项目，优先跑 Docker 版本。哪个项目最接近你的目标，就留下哪个。

这一步的成果不是“读懂全部代码”，而是浏览器里真的能打开一个可用页面。

第 3 小时：完成一次最小改造

只做一件能明显改善使用感的事：

换掉默认提示词。
删除多余页面。
加一个固定输出模板。
把模型配置改成你自己的接口。
加一个“复制结果”按钮。

做完就用真实任务测试一次。

如果它替你省下了 10 分钟，那就已经赢了。

写在后面：自己做工具，不是为了证明技术多牛

真正的爽点，不是你写了多少代码。

是某个原本要反复订阅、反复点击、反复复制粘贴的流程，变成了你桌面上的一个小页面。打开，丢进去，拿结果，关掉。

没有复杂套餐，没有“高级版才支持导出”，也没有突然涨价后被迫续费。

你不需要造一个让所有人惊叹的产品。

做一个让自己用起来顺手、每周都愿意打开的小工具，就够了。