推广披露：本文含我的 ShipAny 邀请入口与优惠码。若你通过它购买，我可能获得平台联盟奖励；这不会改变本文对适用场景、成本和风险的判断。
活动说明：写作时，我的邀请链接仅用于记录邀请；结账页需手动输入优惠码。当前账户页显示，优惠码
ANY1TAN可用于购买 ShipAny Premium，买家立减 30 美元。我获得的奖励分配、优惠金额、适用地区和期限都可能调整，请以结账页实时展示为准。
很多人卡在做产品的第一步，不是不会写业务代码，而是把登录、支付、后台、邮件、多语言和部署这些基础设施，一起当成了第一个版本的任务。
结果就是，产品还没验证，项目目录已经像一间装修到一半的房子。
ShipAny 适合用来跳过这段重复劳动。它不是帮你决定做什么的魔法棒，也不能替你找到用户；它更像是一套已经接好常用管线的 AI SaaS 起步架。你把有限的时间留给产品页面、关键体验和真实用户反馈，而不是从零拼装登录页。
这篇 ShipAny 使用教程按真正的顺序走一遍：先决定值不值得开工，再选模板、拿到代码、用 Agent 改出第一版，最后部署和做上线前检查。所有涉及权益、模板版本和配置路径的地方，都以 ShipAny 官方文档 的最新页面为准。
开始前，先把产品缩到一句话
别急着选模板。
先写下这一句：谁，在什么场景下，愿意为了什么结果，完成一个什么动作。
例如，不要写「我要做一个 AI 平台」。写成「独立站卖家上传一张商品图，得到三套可直接测试的英文标题和五点描述」。前者会把你带向无穷功能，后者至少知道首页要放上传入口、结果页和保存记录。
第一版只需要完成一个闭环：用户进来，理解价值，完成一次核心动作，看到结果。登录、支付、订阅、积分和后台都很重要，但没有真实需求时，越早接得很全，越容易把自己困住。
如果你只是在验证一个静态落地页，或者产品定位还没想清楚，甚至可以先不用数据库和鉴权。ShipAny 的价值是减少该有的工程重复，不是鼓励把不需要的能力也全部打开。
选哪个模板，不是看名字酷不酷
官方当前把模板分成几条路线，选型主要看部署目标和你想不想从现成 UI 开始。
| 你的情况 | 更适合的路线 |
|---|---|
| 想走常规 Next.js、Vercel 或 Node 部署 | ShipAny Next |
| 想要 Cloudflare Workers + Next.js 的部署形态 | ShipAny vinext |
| 更偏好 Vite / TanStack，并计划部署到 Workers | ShipAny TanStack |
| 希望一开始就有较完整的落地页、用户中心和后台界面 | ShipAny Two |
ShipAny Next、TanStack 和 vinext 更偏向无头引擎，业务能力预置、界面可以按产品重做；Two 更适合希望先拿到一套完整 UI 再做改造的人。官方文档也提醒，旧视频中的模板版本和代码路径不一定与现在相同，所以视频可以用来理解流程，具体命令与目录还是要对照你实际拿到的模板文档。
我自己的建议很简单：不确定时，先选你最容易部署和排错的路线。对大多数熟悉 Next.js 的人，Next 会更顺手；对只想快速做出一套可用界面的人，Two 的启动阻力更低。不要为了所谓最先进的技术栈，在第一个版本给自己增加迁移成本。
购买、激活和邀请码，放在真正需要时再用
确定要购买 ShipAny Premium 时，可以从我的专属入口进入：
这个链接的作用是记录邀请，不会自动代入优惠。到结账页面后，手动输入优惠码：
ANY1TAN
当前显示为 Premium 会员可减 30 美元。没有看到折扣、折扣不符合预期，或者订单页的规则变了，就以订单页为准，不必为了优惠勉强下单。
支付后不要马上去找代码下载页。官方流程是先到订单中心激活订单，填写自己的 GitHub 用户名，接受 GitHub 通知里的仓库邀请，然后才克隆对应模板。GitHub 用户名填错是很常见的小坑，遇到权限问题先检查订单激活状态和邀请通知，不要到处复制报错信息或把账号交给别人处理。
把项目跑起来，先看见页面再谈功能
拿到仓库权限后，先克隆你获授权的模板，安装依赖并启动本地预览。不同模板仓库名和命令可能不同，最稳妥的做法是以模板内的 README 和官方快速开始为准。典型流程大致是：
git clone <你获授权的模板仓库> my-product
cd my-product
pnpm install
pnpm dev第一次跑起来后，先只做三件小事：改应用名称、改本地访问地址、在浏览器打开预览页。官方 Two 的快速开始把这些基础项放在环境变量中；如果之后需要用户登录、管理后台或支付，再补数据库连接和鉴权密钥。
不要把 .env 文件提交进 Git，也不要把数据库地址、鉴权密钥或第三方 API 密钥发进截图、群聊或工单。环境变量只保存在本地和部署平台的加密配置中。你在本地看到页面，和你已经拥有一套可安全上线的产品，中间还隔着不少检查。
用 Agent 改第一版，给它一份能执行的说明书
ShipAny 把 Agent Skills 作为主要开发入口之一。这个方式真正好用的前提，不是丢一句「帮我做个产品」，而是把需求写得足够具体。
我会先在项目根目录写一段非常朴素的说明，然后再让 Agent 动手：
产品：面向独立站卖家的商品图文案生成器
核心动作：上传商品图，得到三套英文标题与五点描述
第一版页面：首页、生成页、结果页、隐私页
暂不做：支付、团队协作、复杂权限
验收：手机宽度可正常使用；生成失败有明确提示；不记录上传图片这段话比「做一个好看的 AI 网站」有用得多。它给了 Agent 边界，也给了你验收标准。
接下来我通常先让 Agent 处理品牌名、导航、首页文案和核心页面，再做一次本地检查。确认用户路径没有跑偏后，才开始接 AI 能力、存储或数据库。项目里已有的 /quick-start、/new-page、/new-module 等 Skills 可以让 Agent 遵循模板自身的约定，但每执行完一轮都应该看一下改动和页面，不要把「Agent 能跑」误当成「用户会用」。
功能不是越早打开越好，按依赖顺序接
ShipAny 已经预置了数据库、登录鉴权、支付、存储、邮件、分析、CMS、RBAC 等常用能力。我的顺序是反过来用：先从用户真正碰得到的部分开始，再接支撑它的服务。
如果第一版的核心动作不需要账号，那就先不要求登录。如果用户还不会付费，就先别接支付回调。如果上传图片是关键体验，先把存储的访问权限、过期策略和失败提示测通。只有当「用户做完核心动作后为什么要保存结果」这个问题有清晰答案时，数据库和账号体系才值得进入当前迭代。
这样做看起来慢一点，实际上更快。因为你不会为了一个尚未验证的想法，提前维护一堆回调、权限和账单问题。
部署上线前，先保住代码和密钥
准备上线时，先把项目推到自己的 私有 GitHub 仓库。官方 Vercel 部署文档也特别提醒，基于模板开发的项目代码不应直接公开。之后无论部署到 Vercel、Cloudflare Workers、Docker 或 Dokploy，环境变量都应在部署平台设置，而不是写进仓库。
一个可用的上线顺序是：
- 本地执行构建，先处理类型错误和缺失配置。
- 在部署平台配置生产域名、应用名称、数据库、鉴权和必要的第三方服务。
- 先用平台给的临时域名验证首页、核心动作、错误提示和移动端。
- 再绑定自己的域名，检查 HTTPS、SEO 标题、描述、分享图、robots 和 sitemap。
- 最后再开启支付、分析或广告等会影响真实用户与成本的能力。
这一步最容易被忽略的是「生产环境和本地不是一回事」。本地能跑，不代表生产的环境变量、回调地址、数据库权限和域名都正确。每接一项服务，都用一个真实但低风险的测试动作走完闭环。
上线后第一周，别盯着功能数量
产品上线后，第一周我只会关注三件事：有没有人理解首页在解决什么问题，有没有人完成核心动作，完成后有没有人愿意回来。
如果首页停留很短，先改一句话和首屏示例；如果很多人点了却没完成，先看表单、加载和失败提示；如果有人完成一次就走，才去问保存、登录或付费是否真的能增加价值。
SEO 也一样。先给每个公开页面写清楚独立标题、描述和一个真正回答问题的 H1，提供可索引的正文和内部链接，再通过 Search Console 看收录和搜索词。不要一上来堆关键词，更不要复制几十个换皮页面。搜索带来的第一批人，往往比后台面板里的功能数量诚实得多。
常见问题
不会写代码，也适合用 ShipAny 吗？
可以用，但不要把它当成完全不用判断的拖拽工具。Agent 能降低改代码的门槛，产品定位、账户权限、成本、密钥管理和上线后的验证仍需要你自己负责。先做一个功能单一的版本，学习曲线会平缓很多。
一开始必须配置数据库和登录吗？
不一定。静态落地页或一次性工具可以先不接。只有当功能真的需要保存用户数据、进入后台或处理付款时，再按官方文档配置数据库与鉴权。
为什么代码仓库一定要私有？
一方面是模板的授权和分发边界，另一方面是项目里可能包含配置文件、业务逻辑与部署信息。即使密钥没有提交，公开一个未整理的生产仓库也会增加风险。发布前再做一次 .env、日志和示例配置检查。
优惠码没有生效怎么办？
邀请码与优惠码是两件事。我的邀请入口用于记录邀请；结账时需要手动填写 ANY1TAN。若页面没有显示折扣或条款已变化，请以结账页和官方支持回复为准。
继续阅读
官方资料
最后核对日期：2026 年 7 月 15 日。模板、会员权益、活动、优惠和文档会持续更新，开始前请以官方最新页面为准。