Hacker News 上有一个讨论，提问是：What paid tools have you now replaced with personalized AI-coded tools？直白说就是，你用什么自写的、AI 辅助编码的工具，替换掉了原来花钱买的付费工具。这种问题每隔一阵就会火一次，但真正有价值的不是“省了多少钱”，而是“哪些工具值得替换，哪些替换完会后悔”。
我的基本判断是：值得用 AI 自写工具替换的，大多是高频、规则明确、数据掌握在自己手里的中间工具；不值得替换的，是那些与系统生态、编译链、协作机制深度绑定的基础软件。后面会拆开讲，也会给一条从选场景到上线维护的落地路径。
这个主题适合有基础开发能力、订阅过不少 SaaS、愿意花时间维护小工具的人。如果你完全不想写代码，那思路要反过来：直接付费买稳定工具，可能更划算。
1. 为什么“自写工具 + AI”会动付费软件的蛋糕
1.1 付费工具的真实成本是订阅叠加和切换成本
很多人算账的时候只算“一个月几十块”，但把五六个订阅叠在一起，一年下来并不少。更麻烦的是，大多数付费工具你只用了其中一小部分功能：
- 在线 PDF 工具，你只需要合并和压缩，但必须按整个套餐付费。
- 报表工具，你只用模板生成每周数据，却要维护账号、权限和团队席位。
- 图片处理小软件，你只是批量改尺寸，但安装包自带一堆更新提醒和附加功能。
这是订阅制的通病：功能打包，不能按需付费。于是，越来越多人开始想，能不能用 AI 辅助编码写一个小工具，只解决自己的那一个需求。
AI 编码工具改变了什么？它把“写一个能用的工具”这件事的启动成本大幅拉低了。以前你要找人做，或者自己花周末时间写一个半成品；现在你可以让 AI 先生成骨架，自己再改改参数，补上边界处理。对于有基础开发经验的人来说，这条路确实走得通。
但要注意，这不是“免费替代付费”的万能公式。省下的订阅费，很可能变成你的时间成本。真正值得替换的，往往不是最贵的工具，而是最占用你重复劳动的工具。
1.2 AI 编码不是“免写代码”，而是“把精力挪到需求和验证”
不少人对 AI 编码有个误解，以为输入一句话，就能拿到一个长期可用的工具。实际上，AI 更适合扮演“快速实现者”的角色，而真正决定工具好不好用的，是你对需求的理解。
举个例子。你想写一个批量重命名文件的工具。这句话谁都能说，但“按创建时间排序”“过滤掉备份文件”“遇到同名文件怎么处理”“是否需要日志”这些规则，都需要人来定义。AI 能很快生成一个可以跑的版本，但边界情况靠的不是模型，而是你给出的约束。
所以，我更愿意把这种开发方式理解为：让 AI 完成代码的生成和调整，你把精力放在需求拆解、结果验证和维护上。
这也会牵扯到一个常见问题：有人纠结 skills 和 agent tools 在概念上的区别，但对个人小工具来说，先别急着引入这一套。先把一个确定性脚本跑通，再考虑要不要编排成 agent。概念是后面的事，让工具先跑起来才是正事。
1.3 被替换的工具往往具备三个共同点
我观察到的成功替换案例，通常都具备下面三个特征：
- 高频使用：每周至少用几次，频率低的东西不值得开发。
- 规则可描述：输入什么、输出什么、按什么规则处理，能说清楚。
- 数据归属自己：数据在本地，或者能从原工具完整导出。
文档生成、报表整理、CSV 清洗、格式转换、内部小后台，这些场景都符合。反过来，虚拟机增强组件、编译工具链、办公套件、专业设计软件，通常不适合自研。
所以有些人把 VMware Tools、Visual Studio Build Tools、Office Tools 这类东西也放进替换清单，我一般不太赞同。它们有的是免费组件，有的是生态型产品，核心价值不是单一功能，而是和宿主系统、编译器、协作体系的兼容性。用 AI 重写表层，意味着你要接住兼容性、更新和安全维护的整套责任。
2. 先判断“值不值得替换”，别把自研当成省钱捷径
2.1 适合替换的三类付费工具
第一类是高频重复型。你每天都在做同一个操作，流程固定，比如把网页内容转成 Markdown、把一批图片压缩到指定尺寸、把聊天记录里的消息快速转成会议纪要。这类工具逻辑不复杂，但是手动做很烦，用脚本替代非常合适。
第二类是规则明确型。输入输出边界都很清楚，比如把多张 Excel 表合并成一张总表，把 CSV 按某个字段拆分，把日志按错误级别分类。规则越明确，AI 生成的代码就越容易符合预期。
第三类是数据自主型。数据存在你本地电脑或者公司内网里，不依赖某个供应商的云服务。只要导得出数据，迁移到自研脚本就不会被生态绑定。
| 类型 | 典型例子 | 为什么适合替换 |
|---|---|---|
| 高频重复 | 文档格式转换、图片批量压缩、日志整理 | 使用频率高，操作固定，容易脚本化 |
| 规则明确 | 报表生成、CSV 清洗、模板化内容 | 输入输出可描述，AI 容易落地 |
| 数据自主 | 内部工单、个人记账、本地知识库 | 数据在自己手里，不受供应商限制 |
2.2 不建议替换的工具：生态绑定比功能更值钱
很多工具看起来“只是一个小功能”，但背后是长时间积累的兼容性。自己重写一个代码量不大，真正麻烦的是后续的各种边缘情况。
以 VMware Tools 为例，它解决的问题是虚拟机与宿主机之间的剪贴板、拖拽、显示适配和驱动协同。这类工具的价值不在“能复制文件”，而在于和虚拟化平台深度绑定。用 AI 去写一个类似的东西，完全没有意义，因为你没办法持续跟进每一个新版本的系统。
Visual Studio Build Tools 也一样。表面看是一个编译器加命令行工具，实际上它关系到整个 MSBuild 生态、SDK、依赖链和项目格式。你不需要“替代”它，而是要直接使用它。Office Tools 这类办公工具更明显，文档格式兼容性是靠长期迭代堆出来的，不是几天能重写的。
所以，判断是否替换不要只看“能不能写出来”，还要看“以后谁维护兼容性”。生态绑定越强，越不适合自研。
2.3 用一张清单做替换决策
动手之前，先回答几个问题：
- 这个工具我一个月能用几次？一个月不到三次，先不要替换。
- 数据能不能方便导出？不能导出，自研也难以替代。
- 失败影响是否可控？如果影响到几百人的日常操作，建议谨慎。
- 是不是需要多人协作？涉及团队习惯和权限管理，成本会高很多。
- 我有时间持续维护吗？如果每天都要花时间修，不如继续付费。
注意：如果一件事只是“一年省几百元”，但你要每周投入一小时去维护，那大概率不划算。替换的收益不只看价格，还要看时间。
我会先做一次小范围试用：选一个每天都要用的小工具，从在线格式转换换成本地脚本，先跑一周。如果这一周里，你修脚本的时间不超过你以前手动操作的时间，就可以继续；如果每天都在改，说明这个任务的边界还没想清楚。
3. 从一个小场景跑通第一条“AI 编码工具”流水线
3.1 选场景：从一个你愿意手动做一遍的任务开始
很多人一上来就选一个很复杂的目标，比如“替代整个项目管理软件”，或者“做一个完整的客户管理系统”。这通常会失败。复杂系统牵扯到数据库设计、权限体系、多人协作、前端交互，不是一个人靠提示词能快速搞定的。
正确做法是选一个你手动做一遍只需要 5 到 10 分钟的任务。这类任务价值不高不低，但你每天或每周都会遇到。比如：
- 把散落在一个目录里的多个 Markdown 文件合并成一篇带标题的文档。
- 把一段会议记录整理成待办事项和决策结论。
- 把某个 CSV 里的数据按日期拆分成多个文件。
选择小任务的核心原因，是失败成本低。就算写出来的东西不能直接用，你也不会失去关键数据，更不会影响团队生产。
3.2 先定义输入输出，再写代码
拿到一个场景后，不要立刻打开 AI 对话框说“帮我做一个工具”。先把输入输出写清楚。
比如合并 Markdown 文件这个例子，可以这样定义：
- 输入：一个目录路径，里面有几个
.md文件。 - 输出：一个合并后的
.md文件。 - 规则：按文件名排序，每个文件的内容前用文件名作为二级标题。
- 边界：忽略隐藏文件和非
.md文件。
第一版可以写死路径，不用做配置文件和图形界面。直接用一个函数，传入目录路径和输出路径，跑通之后再抽象成命令行参数。这样做的原因是减少变量，让 AI 生成的代码更容易一次跑通。
3.3 用 AI 辅助生成第一个版本
如果你选的是 Python，提示词可以这样写：
“我熟悉 Python，需要写一个脚本：输入一个目录路径，读取该目录下所有 .md 文件，按文件名排序后合并成一个 .md 文件，每个文件内容前用文件名作为二级标题。请使用 pathlib 实现，并给出运行命令。”
这样写的好处是角色、背景、输入、输出、规则都交代清楚了。AI 生成的第一版大概率是可运行代码。
以文件合并为例，一个简单的实现思路如下：
from pathlib import Path def merge_markdown(input_dir: str, output_file: str) -> None: files = sorted(Path(input_dir).glob("*.md")) merged = [] for file in files: merged.append(f"## {file.stem}\n") merged.append(file.read_text(encoding="utf-8")) merged.append("\n") Path(output_file).write_text("\n".join(merged), encoding="utf-8") if __name__ == "__main__": merge_markdown("./notes", "./merged.md")运行命令可以写成：
python merge_md.py ./notes ./merged.md这里的关键不是代码本身，而是你有能力判断它是否满足需求。如果 AI 生成的第一版不符合预期，你要能指出具体问题，比如“标题应该用一级标题”“目录里还有子目录需要递归读取”“输出文件要强制覆盖”。这种迭代对话，才是 AI 编码工具最有价值的使用方式。
3.4 验证、修错、固化
脚本跑起来之后，不要急着加到工作流里。先做一轮验证：
- 准备 3 个测试文件，内容不要一样。
- 运行脚本。
- 人工检查输出文件的顺序、标题格式、内容完整性。
这个过程会暴露很多问题。最常见的是路径不对、文件编码不是 UTF-8、Windows 和 Linux 换行差异、文件名排序不符合预期。
如果你是 Node 项目，还可能卡在依赖安装上。遇到 npm install 类报错，先确认 Node 版本和依赖包版本是否匹配，再重新安装，不要反复重下安装包。
验证通过后，把脚本放到固定目录，用命令行或定时任务固化下来。最好在输出里加一行日志，比如“处理了 5 个文件，成功 5 个，耗时几秒”。这样以后出了问题，你能知道是脚本没跑，还是输入数据不对。
4. 三个成功率比较高的替换方向
4.1 文档生成与批量格式化
这是最稳妥的切入点。很多人每天都在整理周报、写会议纪要、把草稿改成 Markdown 发布到内部知识库。这类任务的共同点是：模板固定，内容变化，手动操作重复。
你可以让 AI 生成一个脚本，读取你的原始记录，再调用大模型接口做一下语言整理，最后输出成规范文档。整个流程里，人工要做的是检查和修改。
有一个经验：先不追求生成完全准确，先让脚本输出一个“可用初稿”。人工确认初稿质量可以接受后，再把更多步骤自动化。
验证时重点关注：有没有漏掉关键结论、待办事项是否完整、时间节点是否准确。内容类工具不像代码，格式对不代表信息对。
4.2 数据清洗与报表整理
CSV 合并、Excel 多表汇总、日志去重、按条件拆分数据，这些都属于规则明确的数据处理场景。
AI 很擅长生成这类处理逻辑。比如“读取 A 列和 B 列，按日期过滤最近 30 天，输出到一个新 CSV”，这种需求描述清楚后，代码生成速度很快。
但在涉及金额、人员、合同信息时，一定要抽样核对。AI 生成的代码可能逻辑正确，但边界条件没处理，比如空值、重复值、时间格式不一致。我一般会先用一批小数据跑通，再对完整数据做抽样比对，不能直接拿结果发布。
4.3 内部小后台与自动化任务
当你有多个脚本和定时任务之后，自然会想做一个简单页面来查看状态。比如：
- 团队内部的服务申请登记。
- 多个定时任务跑完后的通知聚合。
- 外部链接是否失效的周期检查。
这类工具不需要复杂前端，一个表单加一个列表页，数据存在 SQLite 或 JSON 文件里，就能解决很多问题。
边界一定要控制好。如果多人使用，至少要考虑登录、权限和数据备份。不要以为“内网工具”就不需要安全设计。权限缺失的小后台，往往比没有后台更危险。
这类工具替换的通常是轻量级协作软件或内部管理工具，但要注意，它不一定能替代成熟的团队协作流程。如果团队已经有固定习惯，自研工具的迁移成本可能超出预期。
5. 环境、成本和技术选型：自研不是零成本
5.1 用 API 还是本地模型
做 AI 编码工具，要考虑运行时的模型选型。目前常见两条路：
| 维度 | API 模式 | 本地模型 |
|---|---|---|
| 上手速度 | 快，接口调用简单 | 慢，需要配置环境 |
| 数据隐私 | 看数据是否允许出本机 | 数据不出内网，隐私更可控 |
| 成本 | 按调用量计费，小规模可控 | 硬件成本高，离线可用 |
| 稳定性 | 依赖网络和服务状态 | 依赖本机资源和模型质量 |
个人小工具，如果没有特殊隐私要求，API 模式通常更省心。你不需要维护模型部署，也不需要处理显存占用。只要注意请求频率和单次任务的请求量，成本通常可控。
如果处理的是客户信息、内部财务数据、源码片段，那就要重新想一下数据是否允许发送到外部接口。不能发送的情况下，本地模型是更稳妥的选择，但要提前确认本机硬件能不能跑得动。
5.2 成本估算：别只看订阅费
我见过一些人做替换的时候，只对比“付费工具一年多少钱”和“API 调用一个月多少钱”，忽略了开发时间。
粗略的估算公式是：
自研成本 ≈ 开发时间 × 你的时间成本 + 运行成本 + 维护成本
订阅成本 ≈ 一年订阅费 + 数据迁移成本
如果自研工具全年省下几百元，但前期开发花掉 20 个小时，后面每个月还要花几个小时修脚本，那这笔账不一定划算。
所以最合理的路径是：先做小工具，跑通了，再逐步扩大范围。不要一上来就设计一个“大而全”的系统。
5.3 密钥、数据安全和权限
自研工具的代码通常会放在本地或仓库里。最需要警惕的是密钥泄露：
- API Key 放到环境变量里，不要硬编码在代码中。
- 不要把密钥提交到公开仓库。
- 处理个人信息之前先脱敏，或者换成本地模型。
面向团队的小工具，哪怕只是内部使用，也要有基本的日志和备份。至少做到：出问题时知道去找哪个日志，数据丢了能恢复，权限上不该看到的人看不到。
注意：数据在第三方模型侧流转，是最容易被忽略的风险点。如果业务场景不允许数据出内网，就不要强行接在线 API。
5.4 技术栈选择：选你熟悉、AI 也熟悉的组合
Python 是当前 AI 编码工具最容易生成的语言，适合数据处理、脚本、简单 Web 后端。Node.js 和 TypeScript 适合需要前端展示的工具，比如内部小后台。Shell 适合把多个脚本串起来做定时任务。
不要追新框架。对个人工具来说，稳定比先进更重要。选择一个你熟悉、AI 也擅长生成的组合，遇到问题时你能更快排查。
依赖管理是常见麻烦点。Python 的虚拟环境和 Node 的依赖版本都可能造成“本地跑不通”。如果 AI 生成的项目卡在依赖安装阶段，先不要改业务代码，优先确认运行版本和依赖版本。
6. 替换过程中最常见的坑和排查顺序
6.1 AI 生成的代码启动失败
遇到启动失败，不要急着让 AI 重新生成一版，先按顺序排查：
- 看完整报错信息，不要只看第一行。
- 检查运行目录、输入路径、依赖版本。
- 用最小样例复现，再决定是改代码还是改环境。
- 如果项目是 Node 的，先确认 Node 版本和依赖包版本是否匹配。
很多启动失败不是“AI 不会写”，而是本机环境与生成时的假设不一致。比如 Windows 路径分隔符、Python 版本差异、某个包没有安装。
6.2 输出不稳定或格式不对
当你的工具开始处理多类输入，或者调用大模型接口生成内容时，输出不稳定会经常出现。
一个更稳妥的做法是：让大模型只生成结构化数据，比如 JSON，再写一个独立的渲染层把数据转成最终格式。这样即使模型输出变了，渲染层可以继续兼容。
对关键字段要加校验。比如：
- 必填字段是否为空。
- 日期格式是否符合预期。
- 结果数量是否在合理范围内。
对于失败任务，要能自动记录日志并重新运行，不要靠人工逐个修改。
6.3 替换后发现比原工具更麻烦
出现这种情况，先别怀疑自己能力。很可能是因为这个工具不适合自研。
评估标准不只是“能不能做”，还包括：
- 维护时间：每天要不要处理报错。
- 出错概率：因为一点边界情况导致结果错误。
- 协作成本：其他人是否愿意用你维护的工具。
- 生态加成：原工具有没有团队都在用、格式兼容、插件生态这些隐性价值。
如果替换失败，切回原工具不是失败，是你判断了边界。以后再遇到类似需求，你能更清楚哪些做自研，哪些直接付费。
6.4 退回去不是失败，是边界判断
踩过几次坑之后，我最大的感受是：很多问题不是工具能力不够，而是前置环境和输入材料没有处理干净。AI 编码工具适合解决“规则清楚、数据可控、失败影响有限”的问题，不适合解决“生态复杂、兼容性重、协作面广”的问题。
对我自己来说，替换工具的乐趣不在省多少钱，而在给自己节省重复操作的时间。前提是别让维护本身变成新的重复劳动。先把一个高频小工具跑稳，再慢慢扩大范围，这条路最值得走。
