笔记
0工具
0此页用于记录用户反馈问题后的每一次改进
关于
“写笔记”支持四种格式——Word 文档、Excel 表格、Markdown、纯文本，起稿或二次编辑时都能随时切换，同一篇笔记想用哪种形态来记，都由你说了算。
md、txt、csv、json 这类纯文本则原样载入，不做多余加工。拿一张现成的表倒进来、改几笔、再导出去，等于白用一台免费的格式转换器。
要带走就在右上角点“下载”，可导出 PDF、Word、Markdown、Excel、TXT 等格式；列表卡片“⋯”菜单里，也有同样的下载入口。
在“工具”页点“＋ 上传工具”即可发布：填好名称与链接，再用 Markdown 把使用方法写清楚——能解决什么问题、怎么装、怎么用，比堆介绍实在。
要分发安装包就一并上传压缩包（ZIP、RAR、7Z、TAR.GZ，最大 35MB），别人在详情页一键下载；只放链接不带附件也可以。
工具按大家的收藏热度排序，好用的自然会被顶上来。发布后可在详情页或卡片菜单里编辑、下架。
写笔记时勾上“隐藏”，这篇就只存在于你自己的账号里：不进列表、不进搜索、不上首页精选，也不会出现在任何公开的页面，链接发给别人同样打不开。
适合放密码、草稿、日记这类只给自己看的内容；想公开，去“发布”打开它，把“隐藏”的勾去掉再保存，之后编辑会默认保持原状态，不会悄悄变回公开。
不想公开、只想临时给人看：点“分享”生成一条带密码和有效期的链接，到期自动失效，你也能随时撤销。
你的内容会同时保存在多个副本上，系统定期做备份与完整性校验，再配合异地容灾机制：就算某台机器出问题，数据也不会丢，可以长期放心存放；特别重要的资料，仍建议你另外再留一份备份。
全站跑在容器化、模块化的现代架构上，更新、部署、回滚都很快，扩展性和稳定性都按长期运营的标准来设计（Built for reliability, designed to scale）。
这个网站最早只是一个人的笔记仓库，后来慢慢长成现在的知识中枢。设计上很克制——没有广告、没有追踪、没有推荐算法，只是干干净净地存放一些东西；既然做好了，就公开出来，万一有人用得上呢。
不做大而全，不做平台梦，保持简单、保持克制、保持好奇。所有内容都由用户贡献、由用户维护：不会突然冒出付费墙，不会在角落塞广告位，也不会把你的数据卖给第三方。
产品会持续迭代，站内日志页记录着每一次改动，改了什么都有迹可循；想了解这个站是怎么一步步走到今天的，翻翻日志就能看到来龙去脉。
如果在这里看到涉嫌违规的内容，点对应卡片右侧的“举报”按钮就能提交，我们会尽快核实处理；也谢谢你花一点时间，一起把这里维护干净。
趋势
构建一个真正能交付的AI副业项目——从交付3个MVP中学到的经验
最近两年我数不清自己开了多少个AI副业项目的坑，然后又弃了多少个。模式永远一样：一时兴起兴奋两周，疯狂写代码，然后慢慢淡出，最后变成GitHub上又一个落灰的半成品仓库。
但过去两个月，情况变了。我成功交付了三个AI驱动的MVP，并且有真实用户在用。它们不是每个都赚钱，但每一个都让我学到了从“酷炫想法”到“能用的产品”到底需要什么。下面就是我的全部心得。
AI副业项目的残酷真相
今年二月我开始第一个正经的AI项目时，野心可大了。我想做一个内容摘要工具，能从任何URL拉取文章、做情感分析、还能自动生成Twitter话题串。我花了三周时间琢磨提示工程，用Docker容器化整个堆栈，还用LangChain和Pinecone搭了一套复杂的管道。
然后我拿给一个朋友看。
她问：“我能直接粘贴链接吗？”
我搭了一整套编排层，但输入框藏在两个认证页面后面。那个项目在那个周末就死了。
我反复发现一个道理：AI副业项目失败，不是因为技术不行，而是因为我们还没用户就开始过度工程化。
三个真正交付的MVP
那次失败之后，我改变了策略。我决定每两周交付一个东西——不管多丑，不管多不完整。目标就是有一个URL，别人能点开用。
MVP #1：一个极其简单的博客标题生成器
这个我一下午就搞定了。整个前端就是一个文本框加一个按钮。后端？就是一个Node.js端点，调一下OpenAI的API，提示词是：“生成5个关于[主题]的吸引人的博客标题。”
下面是驱动它的代码（我简化了，但核心就这样）：
import express from 'express';
import OpenAI from 'openai';
const app = express();
const openai = new OpenAI({ apiKey: process.env.OPENAI_API_KEY });
app.post('/generate', async (req, res) => {
const { topic } = req.body;
const completion = await openai.chat.completions.create({
model: 'gpt-3.5-turbo',
messages: [{
role: 'user',
content: `Generate 5 blog title ideas about ${topic}. Return them as a JSON array.`
}]
});
const titles = JSON.parse(completion.choices[0].message.content);
res.json(titles);
});
app.listen(3000);
就这些。没有数据库，没有认证，没有向量嵌入。我把它部署到Railway的免费层，在Reddit上分享了链接，第一天就来了47个独立访客。设计丑得不行——我用了默认的Bootstrap，零定制。但有人用。
教训： 从最薄的LLM包装层开始。其他一切都可以等。
MVP #2：一个真正能用的邮件摘要
第二个项目野心更大：一个AI驱动的新闻通讯，每天早上总结Hacker News的故事。我想根据用户的兴趣做个性化。
这里我犯了一个严重的错误。我没有直接发原始摘要，而是试图搭建一个推荐引擎，包含用户画像、历史交互数据库和反馈回路。两周过去了，我有了一个漂亮的数据库模式，但一封邮件都没发出去。
我果断转向。我把数据库全删了。取而代之的是，我创建了一个Google表单，用户提交邮箱和三个关键词。每天早上，GitHub Actions上的一个定时任务抓取Hacker News前30条故事，用简单的字符串匹配（不是AI！）按关键词过滤，然后通过SendGrid发送纯文本邮件。
AI部分呢？只有摘要生成。我用GPT-4把每个匹配的故事改写成两句话的摘要。通过剥离所有复杂性，我三天就交付了。
教训： 只在AI能创造明确价值的地方用它。其他所有地方，用你能想到的最笨的办法。
MVP #3：个人笔记的聊天界面
这个技术上最有趣。我想能对自己的写作内容提问——博客文章、日记、会议记录。直观的做法是RAG（检索增强生成），用嵌入和向量数据库。
但我没耐心去配置Pinecone或Weaviate。相反，我做了件极其简单的事：所有笔记都存成纯文本文件放在一个文件夹里。用户提问时，应用读取每个文件，分块，然后用简单的TF-IDF相似度搜索（通过natural npm库）找到相关块。然后把那些块作为上下文喂给GPT。
快吗？不快。对于50个文件的语料库，每次查询大约需要4秒。但能用。我一个晚上就搞定了能用的笔记聊天界面。后来我加了缓存，迁移到了真正的向量搜索，但那是在确认了人们确实想用之后。
教训： 用暴力方式做原型。只有在有证据表明性能重要时才做优化。
基础设施的现实检查
交付这三个MVP的过程中，我烧掉了大约80美元的API额度。OpenAI的API在实验阶段不便宜，每个失败的提示和每次测试我都在按token付费。
我也意识到我不想自己管理模型。在VPS上托管Llama 2变体？摩擦太大。运行本地嵌入模型？对副业项目来说不值得折腾DevOps。
我需要的是一个按需付费的解决方案，让我能用任何模型而不用操心基础设施。就在那时，我发现了一个改变我工作流程的东西：一个API聚合器，通过一个端点就能访问几十个模型——GPT-4、Claude、Mistral，以及一堆开源模型。不需要单独的账户，不需要管理GPU实例。只需要一个API密钥和一个信用余额，需要时充值就行。
我最近两个项目一直在用tai.shadie-oneapi.com。这不是赞助推广——我就是在搜索“一个API统治所有AI模型”时找到它的。定价透明（按token付费，没有月费），而且它让我不必在还不知道想法能不能行之前就做基础设施决策。
对于副业项目，能不用改代码就切换模型太重要了。我可以用GPT-3.5-turbo做原型来降低成本，然后切换到GPT-4或Claude 3.5 Sonnet做最终版本，代码零改动。API兼容OpenAI，所以现有代码直接就能用。
下次我会怎么做
交付三个MVP之后，这是我下次的作战手册：
- 一天内交付。 如果不能在睡前做出能用的原型，说明想法太复杂。缩小范围。
- 前三天不要数据库。 所有东西都可以存在内存或JSON文件里。
- 每个用户操作只调一次API。 不要把五个LLM调用串起来。那样你早饭前就能烧掉50美元。
- 手动流程完全可以接受。 如果不到100个用户，我可以手动筛选、手动审核、手动发邮件。等到痛了再自动化。
- 从第一天就用模型聚合器。 我浪费了很多时间为OpenAI、Anthropic和Replicate分别设置账户。一个密钥就够了。
我心态上最大的转变是意识到：AI副业项目不是要构建最技术上令人印象深刻的系统。而是要找到一个人们有问题的地方，用最少的代码去回答它。AI只是一个工具——虽然很强大——但它不是产品本身。
我的博客标题生成器第一天有47个用户。三周后，0个。但这没关系。我从那次失败中学到的东西，比那些花了几周构建却从未交付的项目要多得多。