AI 都能写软件了,我为什么还愿意付钱?

如果 AI 能帮我写个小工具，我还该不该为同类软件付钱？这个问题，比“程序员会不会失业”更早出现在付款页面上。

刚看到V2EX 上的一个帖子《AI 时代，软件已经不值钱了》，评论里有人谈复刻工具，有人谈企业服务，还有人追问清理软件会不会误删。争论背后，其实是两笔账：做出来要多少钱，放心用又要多少钱。

先降价的，是“我能做出来”

需求明确、依赖少、出错容易修的小工具，确实更容易被替代。普通展示页也一样：如果交付只是几屏图文，客户当然会重新算账。

但拿剪贴板工具来说，能保存复制记录之后，还有快捷键冲突、敏感内容排除、历史检索、系统升级兼容。这里是在列验收问题，不是在断言某款产品做得不好。

复刻一张功能清单，和长期替用户省事，是两种交付。

反过来也成立：只自用、能接受偶尔修补，就没必要照着商业产品的规格重做一遍。AI 帮人省下这笔钱，是好事。

清理软件最贵的功能：别删错

扫描目录、算出体积、加一个删除按钮，很容易让演示看起来完整。真正要问的是：凭什么判定它没用？

微软文档把 AppData\Local 定义为用户级应用数据目录，并单列了互联网缓存目录。应用数据目录不能整体视为缓存，更不能整体视为垃圾。

一般会这样验收清理工具：每项说明归属和清理依据；先预览再执行；不确定的默认跳过；能恢复的给出恢复路径，不能恢复的提前说明。测试时先用可丢弃的样本目录，别拿自己的工作资料试胆。

清掉多少 GB 很好展示。哪些文件明明很大，却被正确留下了，也该算成绩。

十万行代码，不是一张免死金牌

“商城很复杂”可以讨论，“行数很多所以安全”却靠不住。代码多，也可能只是历史包袱重。

看一个具体问题：支付平台把同一条成功通知发了两遍，系统会不会发两次货？

Stripe 官方说明，Webhook 可能重复送达，也不保证事件按生成顺序到达；建议记录已处理的事件 ID 来识别重复。

据此做验收，就该在测试环境重放通知、交换顺序，检查订单状态和库存。并发下不能只“先查再写”；去重记录与业务变更还要考虑事务边界。跨系统发货，也需要业务上的防重复和补偿。

AI 可以协助实现这些机制。难点是有人把它们纳入需求，并验证出了故障怎么办。有价值的积累，是业务规则和能反复运行的验收用例，不是仓库体积。

会做饭，也会下馆子

评论区的饭店比喻很贴切。买菜、做饭、洗碗都能自己来，但下班后的一小时也有价值。

软件也得比较总成本：购买价之外，有学习和迁移；自建之外，有验证、维护和故障处理。现成工具若能替许多人分摊这些成本，仍有收费空间。

这个比喻也有限度：用户本来就不需要的功能，包装成“服务”也卖不动。数据必须有合法来源和实际用途；软件加硬件，还得过供应、安装、售后这一关。多加一个盒子，不会自动长出护城河。

独立开发者，先换一张验收单

我建议先选一个小而明确的场景，用 AI 做出可试用的版本，再验证三件事：

•有人真需要吗？ 找目标用户看一次完整操作，记录卡在哪，别只收集“挺好的”。

•失败了怎么办？ 给关键路径补上重复请求、断网、权限不足的样本，检查结果能否解释、恢复。

•省下的麻烦够不够付费？ 记录使用频率、节省的时间和维护工时，再决定收费方式。

别用难导出、故意不兼容来制造黏性。让用户愿意留下，比让用户走不了更值得做。

刚入行的人会感到压力，老开发者也没有永久安全区。但没必要把岗位变化解释成谁“不够努力”。我们能做的，是把学会生成代码，继续推进到学会判断需求、验证结果、承担交付。

你最后一次给小软件付钱，买的是独特功能，还是“不想再折腾”？又有什么工具，你已经用 AI 自己做了？