AI 原生产品发布工作流：从想法到上线

念头进 git 之前先写 150-300 字的产品 spec：解决谁的什么问题、用户旅程一句话（"用户打开页面 → 输入 X → 看到 Y → 可以下载/分享"）、最小可用版本不做什么。同时画一张最简单的状态图（手画拍照即可）：核心数据流、需要的存储、对外接口。

这一步 agent 不能替你做。spec 是产品判断本身——交给 agent 你就再也分不清哪部分是你想要的、哪部分是它"觉得不错"塞进来的。spec 写不出 150 字，说明产品念头还不够清晰，先放一放。

把 spec 交给 planner agent（推荐 Claude Code 的 plan mode），让它输出仓库骨架方案：路由结构、数据模型、对外接口、部署形态。我们的默认栈是：

Next.js 15 App Router + Tailwind + shadcn/ui
Prisma + Postgres（或 SQLite for 本地原型）
Vercel / Caddy + VPS（视产品定位选）

planner 要回答的关键问题：能否用纯静态？需不需要后端？数据模型多简单？登录是否必须？默认答案是越简单越好——v1 不做账号、不做支付、不做多语言；这些放到产品被验证之后再加。

planner 出 plan.md 之后，把"按照 plan.md 实现 v1"交给 coder agent，让它从仓库骨架开始把核心流程跑通。给 coder 的硬约束：先做端到端最薄一片（首页 → 输入框 → 调接口 → 显示结果），不要先做精细 UI、不要先写测试、不要先做错误处理——把"用户能用"做出来再说。

我们的经验是这一步通常一次给到 80%：剩下 20% 是 coder 不知道的产品判断（"这个错误提示是不是太冷漠"、"这个 CTA 文案应该更直接"），由作者亲自改。不要试图通过更长的 prompt 让 coder 一次到位——这部分 prompt 越长，agent 越容易过度设计。

产品要发出去给真实用户用，需要一个能让人 5 秒看懂"这是什么、为什么我要点进来用"的 landing page。把产品 spec + 用户画像交给 writer agent，让它产出三个版本的标题与子标题，然后作者从中选一个、改成自己的口吻。

视觉资产用 /image-gen skill 生成：1 张 1200×630 的 OG 卡（社交分享预览图）+ 1 张产品截图风格的 hero 图。不要用大模型生成 logo——logo 是品牌资产，应当独立设计或用文字 mark 兜底。

产品代码跑通后，把"部署到 <your-vps>，挂在 <subdomain>.example.com"交给 deployer agent。deployer 干三件事：rsync 代码到服务器、配 reverse proxy（Caddy 或 OpenResty）、申 HTTPS 证书。

域名 DNS 这一步必须作者本人在 registrar 控制台操作——不要把 API token 给 agent，这是无法回滚的安全边界。

我们对所有 VPS 写了 SSH skill（/guangzhou-vps、/x4090 等）：包好端口转发、Docker 镜像加速、常用 daemon 管理。一条命令能把一个产品从本地推到生产，比反复 ssh 靠谱。

上线第一天就要有数据看板——否则你不知道用户进来后实际做了什么、在哪一步流失。最小可行配置：

• 一个轻量的访问统计（Plausible / Umami / 自建 PV+UV）。
• 一段 核心转化埋点：用户从打开到完成核心动作（提交表单 / 下载 / 复制结果）的转化漏斗。
• 一张每天自动生成的小报告（cron + 邮件 / 微信通知）：昨日 PV、UV、转化数、Top 来源。

不要一上来就接 GA4 / Mixpanel——埋点配置时间会比产品本身长。先看到真实流量再说，被看到的不爽再升级。

发布渠道按"高信任 → 低信任"顺序：

1. 小群定向发：跟你领域最相关的 5-10 个朋友，1-1 发链接 + 一句话说明。听他们用完后的反应，比公开发任何渠道都有信号。
2. 公众号 / Newsletter：写一篇 2000 字的发布文，讲产品解决什么问题、为什么做、怎么用——这一步可以和公众号文章工作流联动。
3. 社区与社交：知乎、即刻、Twitter、相关 Discord——按你目标用户的栖息地选 1-2 个，不要广撒网。

发布后的第一周每天看一次数据，遇到任何"为什么没人来 / 来了不点 / 点了不留"的现象，先想 spec 哪里没说清楚、再想代码哪里有 bug——大部分早期产品问题是产品判断错了，而不是代码错了。