TinyKit：一个工具站的决策链

TinyKit 是个英文微型工具站，目标是广告变现。它不是一次规划出来的，而是一条决策链：先验证痛点真实存在，再做工具；工具被反复复用，抽象成 API；API 的逻辑能被 AI 直接调用，包成 MCP。每一步都是前一步的自然延伸。

第一步：先找痛点，不先做工具

2026-10-01 做了两路痛点调研：一路是小红书 16 篇高赞笔记的评论区，另一路是 V2EX、知乎、Reddit 等公开来源。10 个候选痛点里，需求信号最强的是"AI 味改写"（已经有完整付费赛道，用户在为降 AI 率付费）和"跨 AI 上下文交接"（新鲜、高共鸣、零成本可做）。

决策：先上"去 AI 味"工具。但有两个约束：一是高质量改写需要大模型，纯前端规则改写的上限明显，所以先上规则版，诚实标注局限，看流量信号再决定要不要做 BYOK（用户自备 key）真改写；二是主力场景之一是"论文过查重"，属学术诚信灰色地带，定位必须避开"论文降重"口径，只做自媒体文案去 AI 味、防平台限流。

不追热度，追"已经有人付费"的证据；不碰灰色地带，哪怕它是需求最强的场景。

第二步：工具站 27 → 31

痛点调研直接长出 4 个新工具：token 估算、结构化 prompt 生成、对话转 Markdown、去 AI 味改写，工具总数从 27 到 31。同时补了中英双语基础设施：语言切换、浏览器语言自动检测、记忆用户选择。

这里的取舍是：新工具全部围绕 AI 助手用户，不发散。工具站最忌"什么都有一点"，31 个工具里每一个都能说出它对应哪个痛点，说不出的不做。

第三步：工具逻辑复用多了，抽象成 API

工具的前端逻辑被复用多次之后，抽象成 API 是自然的一步：24 个端点，每个 IP 每天 1000 次限流，预留了 API key 的付费升级位。部署上取了巧：API 直接跑在 Pages 的 _worker.js 里，/api/* 走函数，其他走静态资源，一次部署同时上线网站和接口。

定价先定后验证：免费额度先行，有真实用量再开付费墙。没用量的时候谈价格是空想。

第四步：API 逻辑包成 MCP

MCP server 没有重写逻辑：Node + MCP SDK，stdio 传输，直接 import API 的纯函数，23 个工具一次暴露。后来 API 加到 24 个端点，MCP 跟着到 24 个工具，冒烟测试全过。

没发布到任何 registry——发布需要用户账号授权，这条线停在"代码就绪"。能做的都做了，做不了的不硬做。

变现线：域名与 AdSense 的两次折返

AdSense 不接受子域名，tinykit.rotor1996.top 的申请路走不通。决策：注册顶级域 gettinykit.top，原域名保留做备用。AdSense 已提交审核，审核通过前不展示广告——没通过就挂广告位，是拿账号开玩笑。

小结

这条决策链的方法只有一句话：每一步只解决上一步已经证明存在的问题。痛点调研证明需求，工具证明形态，API 证明复用，MCP 证明可组合。没被证明的下一步，不提前做。