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(encodingutf-8)) merged.append(\n) Path(output_file).write_text(\n.join(merged), encodingutf-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 编码工具适合解决“规则清楚、数据可控、失败影响有限”的问题不适合解决“生态复杂、兼容性重、协作面广”的问题。对我自己来说替换工具的乐趣不在省多少钱而在给自己节省重复操作的时间。前提是别让维护本身变成新的重复劳动。先把一个高频小工具跑稳再慢慢扩大范围这条路最值得走。