2026 年 5 月，硬件创业公司 TRMNL 的创始人 Ryan Kulp 写了一篇复盘。内容是他如何在 30 天里用 Claude 加 Superpowers ，把公司每年 2 万美元的仓储物流 SaaS 替换成了自建系统。

文章在 Hacker News 上只拿了 33 分。但它回答了一个比大多数热门帖子更具体的问题：什么条件下自建替代购买是理性选择，以及怎么避免翻车。

开发其实是被逼上梁山

TRMNL 用了一年 ShipHero，体验一直不好——工单不回、界面难看、两个域名间 SSO 反复出问题。即便如此，公司里也没人敢轻言自建一套系统。

然而， 3 月 31 日柏林仓库系统崩了，供应商失联数周，而合同 5 月 1 日就要自动续约，他们这才被逼到墙角。

正常的"make or buy"评估会算出人力成本远超 SaaS 年费，然后继续忍受。危机出现后就不一样了，现有方案的成本不再是年费，而是仓库停摆造成的实际业务损失。

自建成了唯一选项

但凡现有方案还能勉强用，自建大概率不会启动，也不需要启动。因为这类项目的决策从来不是技术热情驱动，而是损失驱动。没有迫切的损失就很难发起。

在损失出现之前，他们仔细研究正在用的 SaaS，标记出真正依赖的功能子集。TRMNL 只需要订单备注和打包发货两件事，ShipHero 90% 的功能没碰过。

大部分企业在大部分 SaaS 上的使用深度可能都不是特别深。知道这个数字本身，是很重要的决策准备。一旦出事，需要在两天内而不是两周内做出判断。

Superpowers 发挥了巨大作用

TRMNL 用的就是著名的 Jesse Vincent 开发的 Superpowers skill。

Superpowers 的核心机制是苏格拉底式追问。它不接"给我写个物流系统"这种 prompt。它会一轮一轮澄清：要订单筛选还是订单合并、先做打包还是先做运费计算、后端用什么语言、数据库呢——直到模糊需求被拆成可执行步骤。

Kulp 提到： "真正闪光的地方是架构设计"。Superpowers 不是在帮你设计架构，是在倒逼你确认自己已经想清楚了。AI 编程工具共同的短板是处理模糊性，Superpowers 用持续追问把模糊消解在动手之前——这和传统开发里靠开会和文档评审做需求澄清是同一件事，只不过换了执行者。

另外，Superpowers 在生成代码的同时生成测试，并且要求代码标记为完成之前所有测试通过。Kulp 把这个经验总结为："AI 生成的代码 80% 的安全性来自测试"。

AI 辅助编程里跳过测试太容易了，因为代码看起来已经很像样。TRMNL 在这一点上的教训是反向的：没跑过测试的代码，"像样"和"能用"之间的距离比想象中大。

物流平台的 CRUD 功能——订单列表、状态筛选、打包确认——手动写也不难，AI 使其更加快捷。但快递 API 的集成，工作量是另一个量级了。不同快递商的认证机制、请求字段命名、错误码体系各不相通。TRMNL 的产品属于危险品分类、发往几十个国家，单条发货请求的 JSON payload 超过 1000 行，每一项合规声明都需要在请求体里精确声明。

Kulp 对这一步的评价：如果手写这些集成，再付一年 ShipHero 的糟糕服务可能更划算。需要按照外部系统的固定格式拼装大量字段、文档分散且写法不一致、正确性要求高但逻辑本身不复杂。而这类任务是 LLM 加速最显著的区域，把时间和 token 预算优先分配给它收益最明显。

但是, 有些工作 LLM 帮不上太多忙。多仓库架构怎么设计、哪些数据对象需要支持 null 外键——这些判断依赖对业务上下文的深入理解，LLM 可以给建议但做不了决策。识别加速区和非加速区，直接决定项目的时间分配。

这个 AI 项目能够在短期内成功，一个重要经验是锁定需求范围，避免蔓延。

当一群人每天依赖的工具被换掉，第一反应是需求轰炸——能不能顺便加个功能、支持那家快递公司、格式化报表。

Kulp 的应对：只有两三个人有权限提交代码或建 ticket。其他人提需求走 GitHub Issues 异步提交。在 4 月 30 日的硬截止面前，任何不直接影响第二天仓库能发货的需求都必须挡在门外。

另一个成功经验是，事先锁定了 UI 。

十几个仓库员工有 ShipHero 的肌肉记忆。Kulp 采取了一种非常实用的做法，把旧系统截图喂给 Claude Design 做高保真 mockup，然后刻意保持交互流程不动。他把这称为 "惯性友好"。

要知道，如果用户必须在学新界面和完成手头工作之间二选一，他们会选一边工作，一边抱怨。切换当天不出问题的前提是，用户不需要重新学习。

这两个很有价值的经验都和代码无关，但对交付成败的影响超过代码质量。

算算经济账

TRMNL 在使用 ShipHero 期间 3 万多件包裹，平台费用均摊到每件约 0.76 美元。自建后 Kulp 预期综合维护成本能把单件成本再降 2-3 倍。

下降来自一个结构性变化：不再为 SaaS 的定价体系和合同条款付费。SaaS 模式里，费用包含代码维护，也包含供应商的运营成本、销售团队和利润。自建把后几层一次性去掉了。

前提是 80-100 小时的人力投入，加上一整周驻场部署和现场调试。但要注意，团队里如果没有人能在几天内搞定四大快递 API 集成，100 小时会膨胀到几百小时，自建就不划算了。

AI 压缩了开发时间，原本够不到经济线的项目现在可能够到。但能不能兑现这个压缩，取决于有没有把 LLM 的加速用在自己最不擅长的部分。

最终的实战总结

要替代它之前，对你用的 SaaS 做一次功能审计，标出真正在用的部分。很有可能只用到了 10%，知道这个数字本身，就是重要的决策准备。

找一个 Superpowers 这样能强制做需求澄清的工具或方法来帮助开发。"先想清再写"虽然耳熟能详，但靠自律坚持不了太久。

识别项目里"正确但无聊"的工作，例如 LLM 擅长的格式拼装和文档对接，出错代价高不能马虎。把 token 预算优先分给这部分。

需求管理上，找一个人专门负责说"不"。唯一职责是确保截止日期之前只有必须交付的东西进入代码库。

----

https://trmnl.com/blog/vibe-coding-shiphero