写这篇文章之前，我一直在纠结，要不要等 ShipArt 这个产品完善之后再写。但是思来想去，完成比完美更重要。从立项到 MVP 上线，前后大约两周半，这个过程中的一些思考和收获，值得记录一下。

一句话介绍下 ShipArt（访问入口：shipart.app）：

ShipArt 是一个帮助用户进行图片创作的 SaaS 网站，集成了多种强大的 AI 图片生成模型，只需要简单的描述，即可生成精美的图片。

说人话就是图片工具站。

为什么要做 ShipArt？

做 ShipArt 的决策其实并没有经过充分的市场调研和需求分析。

如果是 24 年，做 AI 图片站出海是个很好的选择，那个时候的 AI 生图还没那么普及，需求又很旺盛，哪怕只提供基本的生图的能力，也能有很好的流量和收入。

在 26 年，如果还做图片工具站的话，竞争十分激烈。

但是，经过了一些思考和讨论之后，我觉得这个方向的产品还是值得做的。

第一，图片和视频生成的需求仍然很大。 一个证据来自我另一个项目的部分用户，跟他们沟通的过程中，他们反复提到图片生成的需求，用 GPT 这些产品，目的只有一个，就是图片生成。另一个证据是跟一个朋友聊天，她的一个亲戚是做电商的，有很强烈的商品图生成的需求。当时两个人稍微一聊，就觉得这是一个很大的需求，并且电商场景的用户付费意愿都比较高。这位朋友后来直接成了 ShipArt 的开发成员之一。

第二，现在入场也不晚。 之前在哥飞北京年中交流会上，蓝星空大哥提到，图片站任何时候开始做都不晚。他是 4 月份开始做的，很快就有了成果，这也给了我很大的信心。

开发 ShipArt 过程中的一些收获

开发 ShipArt 的过程，带给我的收获比想象中的多不少。

之前的项目，要么是门户网站，要么就是拿开源项目直接改的，对 vibe coding 要求并不高，更看重渠道和推广。

所以这个项目从一开始就在有意识地思考如何与 Agent 协作，工作流如何沉淀等等。

如何与 Agent 协作

ShipArt 是一个从 0 开始开发的项目，完整地经历了需求讨论、详细设计、开发实施、测试迭代等软件开发过程中的各个环节。开发工具主要是 Codex，部分需求讨论和方案设计用的 Claude Code。

我自己体会比较深的是，和 Agent 的协作其实是一个“梭子型”的过程。之所以叫梭子型，是因为人和 Agent 的参与就像梭子的形状：两头尖的部分是需求分析和验收上线，工作量不大，但必须由人主导；中间粗的部分是设计、开发、测试这些占绝大部分工作量的环节，则交给 Agent 来实施。

需求分析就是那个 1，没有这个 1，后面再多的 0 都没有用。验收上线也一样，产品最终是给人用的，真实的人验收这一步少不了。

中间的大头交给 Agent 之后，效率提升非常明显：方案设计阶段人还需要不断介入，把资源约束、阶段预期这些现实考量喂给 Agent；到了实施计划阶段就几乎完全交给 Agent 了，一个比较有效的方式是用两个 Agent，一个编写实施计划一个评审，超过三五轮再由人介入；开发阶段 Agent 可以连续执行长程任务，这个项目中我最长的一个任务跑了 40 多个小时；测试阶段 Codex 对浏览器的控制十分丝滑，单元测试、集成测试、页面交互验证都可以让它来完成。

关于梭子型协作更详细的拆解，后面会单独写一篇来展开。

核心产品决策必须重度参与

在 ShipArt 开发过程中，另一个体会就是核心产品决策必须重度参与。一个典型的场景就是订阅支付方案。

一开始我没意识到这里的复杂性，以为只需要说一下简单思路，Agent 那边就可以完成设计和开发。毕竟众多 SaaS 模板都宣称自己集成了支付功能、订阅套餐，只需要简单的配置即可上线使用。

但实际实施的时候，才发现完全不是这么回事儿。说几个简单的数字大家就知道了。整个订阅支付功能前前后后和 Claude 沟通的中间方案版本就有十来个，Agent 总运行耗时超过 80 小时，累计 Token 消耗粗略估计有 60 亿。

在 ShipArt 中，支付套餐包含首充包、积分包、月订阅套餐、年订阅套餐。看上去很普通是不是？但是有很多细节需要考虑，比如：

定价层面

1. 各套餐定价多少、积分多少？有效期多久？
2. 订阅情况下积分包加赠多少？
3. 积分包和订阅套餐中分别主推哪种套餐？
4. 年订阅套餐相比月订阅套餐折扣定多少？
5. 各支付渠道手续费固定费用分别是多少？
6. 上游渠道 API 成本是多少？如果上游渠道 API 成本发生变更，容错空间是多少？

等等。

支付层面

月订阅和年订阅之间不同档位的升档、降档、周期切换、退款政策、支付异常等等如何处理？

1. 同周期订阅升档生效时间点是多少？新周期如何计算？积分如何补偿？差价如何计算？
2. 同档位升周期生效时间点是多少？新周期如何计算？差价如何计算？
3. 跨周期或者跨档位升级，生效时间点是多少？新周期如何计算？差价如何计算?
4. 与此相对应的降档、降周期，跨周期降档生效时间点又是多少？退款还是下个周期再变更？
5. 用户升级档位或者升级周期，没有立刻支付，差价和积分补偿又该如何确定？
6. 一些支付渠道支持扣款失败后再一段时间内进行重试，那这段期间权益该如何计算？积分该如何发放？如果涉及套餐变更、周期切换，又该如何计算？
7. 如果发生退款，走人工还是走自动化？
8. 支付风控策略如何设置？拦截哪些支付？

等等。

上面的这些点在技术层面都不算复杂，但在产品层面尤其需要想清楚：不同的策略对产品的满意度、利润率、退款率或者争议率都有很大的影响。另外国际支付渠道方面，一旦出现争议，轻则按笔扣费（很贵），重则直接封号，并且很难沟通。

类似这种核心的产品决策，很难让人放心把它交给 Agent。

工作流逐渐成型

从这个项目一开始，我就在有意识地积累标准工作流，目前也有一些小的进展。

比如，在产品 Demo 上线环节，已经沉淀了一些工作流。目前已经做到只需要在云服务器厂商平台上完成支付购买，就可以依靠 Codex 自动化完成线上服务器环境准备、代码库准备、持续集成（CI）、持续部署（CD）等一整套的部署运行流程。

软件开发过程管理上，逐步形成了基于 GitHub Project 的开发过程管理，实现了需求/问题提出后，Agent 自主分析、记录、实现和上线的流程。

这套流程跑下来的效果：两周半，累计提交 300 多个 commit，最多的一天提交了 80 个，并且所有的开发过程、所有的提交都有详细的文档、详细的评审记录和时间线。

这种开发效率在传统软件开发中是完全不敢想象的。

在知识沉淀上，形成了日常想法到小龙虾再到本地知识库、Agent 任务总结到本地知识库、本地知识库再提炼到 wiki 和飞书的一套粗糙的流水线。

当然，这些工作流还有很多细节没打磨好。随着后面这些工作流的不断成型，我也会和大家及时分享最新进展，相互交流，相互促进。

最后

再给这个项目做一下宣传：如果你有图片生成相关的需求，欢迎使用我的新产品 ShipArt，目前已经接入 GPT-image-2；Nano Banana 2 等更多模型正在接入中。

罗马也不是一天建成的。ShipArt 目前还很简陋，但它一定会有自己的一席之地。

后续我会继续分享 ShipArt 的产品进展，以及 vibe coding 实践中的更多思考。感兴趣的话欢迎关注。