一个普通人如何利用AI建立自己的生产力系统？

我见过很多人建"生产力系统"的方式：订阅三四个 AI 工具，收藏一堆提示词模板，然后每天在这些工具之间复制粘贴。用了半年，效率没变，工具账单倒是稳定支出。

问题出在系统被定义错了。它的单位不是"我用了哪些工具"，而是**“我有哪些动作被固化下来了”**。一个动作只要你重复做过三次，它就值得变成一个脚本、一个小页面、或者一条命令——而不是每次都重新跟 AI 描述一遍。

先记账，再动手

我做过一件很笨但很有用的事：连续两周，每天下班前花五分钟记下当天哪些动作是重复的。

记完发现重复的动作高度集中在几类：把一堆文本按某种规则整理成表格、给一批文件批量改名、把客户发来的数据从一种格式转成另一种、给同一类文档生成同一结构的摘要。这些事单次不超过十分钟，但每周都在做，一年下来是几十个小时。

而且它们的共同点很明确：规则是固定的，变的只是输入。 这类事情天然适合被固化，也天然适合让 AI 帮你写固化的那个工具——不是让 AI 每次帮你做，而是让它一次性帮你做出"以后不用再做"的东西。

固化成什么形态

优先级从低到高排，我一般按这个顺序选：

命令行脚本最轻。一个 Node 脚本读目录、转换、写回，几十行，用完就放着。适合只有你自己用、不需要界面的场景。

内部小网页居中。有界面、能给别人用、能在手机上打开。在线工具 这个形态被低估了——它不需要登录、不需要状态，用户打开就能用，你也不需要维护任何用户数据。

做成能公开访问的工具站最重。要做 SEO、要管性能、要处理滥用。除非你已经确认这件事有对外价值，否则别一上来就选这个。

判断标准只有一条：这个动作会不会有人需要第二次。只你一个人需要，脚本就够；团队都要用，做个页面；陌生人也在搜这个词，才值得做成公开页面。

10015.io 给的两个具体启发

10015.io 是个可以拆解的样本：Next.js 加 styled-components，50 多个工具，几乎所有工具都在客户端运行，极少请求服务端。

10015.io 首页配图是插画风格：一个人在电脑前干活，脚边趴着一只猫。

第一个启发是**"客户端优先"这个技术选择**。图片压缩、文本转换、格式互转、编码解码这些操作，放在浏览器里做，服务器只负责发静态文件。这样做的好处是成本结构极简单——没有队列、没有临时文件清理、没有并发限制，流量涨十倍服务器账单也不动。重计算的部分用 WebAssembly 跑编解码，性能也够用。

第二个启发是技术栈保持一致带来的复利。50 多个工具共用同一套 Next.js 骨架和同一套样式方案，意味着第 51 个工具的边际成本极低——布局、导航、错误处理、埋点都是现成的。这也是它能撑起 50+ 数量的原因。如果你要做一堆小工具，先把第一个做扎实，把公共部分抽干净，后面的会越来越快。

它的变现数据并不惊人：AdSense 月收入大约 300 美元。这个数字提醒的是另一件事——这类系统的回报主要体现为你自己省下的时间，而不是广告收入。把期望放在这里，投入产出才算得清楚。

顺带一提，"客户端运行"这个选择还有个容易被忽略的附带好处：用户的文件不用上传，也就不用解释你会怎么处理这些数据、什么时候删。很多工具站要专门写一段隐私说明来回答这些问题，而纯客户端的方案里这些问题根本不存在。

AI 在系统里放在哪

我的用法是分工明确的：AI 负责把我描述的规则变成第一版实现，我负责定义规则本身和验收。

写脚本时，我会先把输入输出的具体例子写下来——三五个真实的样本，包括异常样本——再让 AI 写实现，然后用这些样本去跑。样本比描述管用得多，因为描述里你说"处理一下异常情况"，它不知道你说的异常是空文件还是超长内容；你给它一个 900KB 的文件当样本，它就知道要考虑什么。

JavaScript 的运行时和异步处理是这类脚本最容易出错的地方，尤其是要批量处理文件时——并发数不控制会把机器卡死，错误没捕获会导致前功尽弃。JavaScript 教程 里的异步并发控制和错误处理部分，写这类脚本前值得过一遍。

系统怎么才算建成了

判断标准很朴素：某天你发现自己三个月前写的那个脚本又用上了，而且不需要改。

这说明两件事——当初那个动作确实值得固化，而且固化的粒度选对了。如果每次用都要改一遍，说明固化的东西太具体，应该再往上抽一层；如果半年没用过，说明当初记的那个"重复"是错觉。

我现在的系统里常驻的东西不多：十来个脚本，三个内部小页面，一个能批量跑的命令行入口。加起来不到三千行代码，但每周稳定省下几个小时，而且越用越顺手。它不华丽，也不依赖任何一家 AI 公司的产品活着——这一点我觉得比什么都重要。

10015.io 的技术栈与工具数量引自其公开说明，AdSense 收入为其作者自述数据。