看到一个付费工具，很容易冒出这样的念头：这个功能也不复杂，让 AI 帮我写一个不就行了？
有时候确实可以。但“能做出来”只回答了开始的那一段，后面还有运行、维护、升级和出问题时由谁处理。
比如一个发通知邮件的功能。演示时成功发出一封，看起来就完工了。真正用于产品，还会遇到地址错误、重复发送、失败重试和送达状态。用户多了以后，这些细节才陆续从角落里冒出来。
这就是自建与购买的区别之一。购买让一部分工作由服务方承担，自建则把更多控制权和责任留给自己。两边都有成本，不能只比订阅价格与第一晚的编码时间。
英国政府的技术采购指导把完整成本、自身能力、升级与退出都放进判断范围，也允许自建和购买组合使用。这里借鉴的是比较思路，不是套用政府采购流程。资料：GOV.UK
设想一个面向维修店的报价产品。客户看重的，是故障、工时和配件能否组合成可信报价。发送通知只是配套能力。经营者把几个晚上都花在邮件细节上，可能学到了不少技术，但报价规则本身没有进步。
如果现成工具确实无法表达某个行业的特殊报价方式，自建这部分就有更清楚的理由。它与客户选择产品的原因紧密相关，也更可能形成自己的能力。
当然，购买不等于不用操心。使用量增加后怎么计费，资料能否导出，服务停了怎么办，都还在经营范围里。现成服务也需要接入、观察和管理。把它当成完全没有风险的黑箱，同样不准确。
做 AI 应用和自动化工作流时，我觉得最容易被低估的是注意力。软件可以复制，人每天能认真处理的事情却有限。一个看似省掉月费的小功能，可能长期占住某个晚上，甚至打断真正有价值的工作。
自建也不必从头到尾都自建。产品先用成熟能力服务客户，需求稳定后再替换一部分，是一种路径；自己掌握核心规则，其他环节购买，也是一种路径。选择还会随着规模和能力变化。
这笔账里，钱比较容易看见，维护责任比较容易被漏掉。真正值得比较的，是买下或写下这个功能以后，未来还有多少工作会继续找上门。