产品开发完成后如何生成面向非技术创始人的上线清单

当产品已基本开发完成、需要从「本机能跑」推进到「客户可用」时，审计代码库并产出一份分步上线指南。

适用场景

解决思路

1. 先彻底阅读代码库再动笔，弄清：产品是什么、运行在哪里（Web/移动/桌面）、框架、后端、数据库、认证与支付服务商——能从代码和依赖里看出来的就不要问用户。
2. 盘点配置状态：代码里用到的环境变量 vs 已文档化的（如 .env.example）、必须转为密钥的硬编码值、需要换成正式版的测试/沙箱密钥。
3. 列出所有第三方服务，以及每个服务在生产环境需要什么（正式 API key、webhook 端点、启用计费）。
4. 检查部署就绪度：现有部署配置（如 vercel.json、Dockerfile、eas.json）、构建脚本、生产构建当前是否能成功、测试状态。
5. 找出上线缺口：面向客户的产品可能缺少的错误追踪、分析、法律页面（隐私政策、服务条款）、自定义域名、数据库备份、移动端应用商店素材。
6. 用一条简短消息与用户确认整体判断（产品类型、技术栈、发现的服务），并只问代码无法回答的问题，例如是否拥有域名、是否已注册检测到的服务账号、是否有上线截止日期。
7. 把指南写到 docs/launch-checklist.md（目录不存在就创建）。
8. 文件头部写明：产品名、用一句大白话描述检测到的技术栈、预计总耗时，以及图例：🧑 你自己（需要你的身份、账号、支付信息或决策）、🤖 智能体（把给定提示词粘进编码智能体即可完成）、🤝 一起（智能体准备，你点最后一下按钮或粘贴值）。
9. 按阶段组织，每步带复选框，并根据审计结果调整，典型结构为：1) 账号与前置条件——注册托管平台和每个生产服务，选够用的最便宜档位并注明月费；2) 密钥与配置——创建正式 API key、在托管平台设置环境变量、移除测试密钥，并明确说明绝不要把密钥粘进聊天或提交到代码；3) 生产服务——数据库切生产模式、认证配置为真实域名、支付从测试切到正式（含 webhook 和一次真实测试购买）、邮件/AI/存储服务换正式凭据；4) 部署应用——为检测到的技术栈选阻力最小的路径，移动端则包括开发者账号、商店列表、构建提交，并诚实说明商店审核要几天且可能需返工；5) 域名——购买/连接域名、配置 DNS、确认 HTTPS；6) 上线前验证——写成用户旅程的冒烟测试：以真实客户身份注册、走完核心流程、做一次真实支付再退款、在手机上检查；7) 上线之后——错误追踪、分析、数据库备份，以及出问题时去哪里看。
10. 每个步骤都必须包含：复选框、🧑/🤖/🤝 标记、时间估计。
11. 每个步骤都用大白话写，首次出现的每个技术术语就地解释，例如 DNS（把你的域名指向应用服务器的地址簿）、环境变量（存在代码之外、用于 API key 等密钥的设置）、webhook（一个服务在事件发生时自动通知另一个服务的方式，比如支付成功）。
12. 🤖 步骤要提供可直接粘贴给编码智能体的提示词，放在引用块里。
13. 🧑 步骤要写清具体去哪里点/去哪里、会被要求提供什么、以及任何费用。
14. 每步都加一句「你会知道它成功了，当……」，让创始人不用猜就能验证。
15. 不要只丢文件，要在对话里给出简短总结：共多少步、必须由本人完成的少数 🧑 事项、每月总预估费用、建议的第一步，并主动提出现在就执行第一个 🤖 步骤。
16. 对费用、时间和风险保持诚实——商店审核延迟、DNS 传播（「最多可能要一天」）、支付服务商验证。
17. 只推荐一条路径，不要给菜单。审计已选定技术栈，指南就承诺匹配的部署路线。
18. 绝不指示用户在聊天中分享密钥；密钥直接填入托管平台的设置里。
19. 如果审计发现阻塞项（构建失败、硬编码密钥、缺少支付 webhook），指南的 Phase 0 就是修复它们，每项作为带提示词的 🤖 步骤。
20. 只有冒烟测试以真实客户身份通过，产品才算「已部署」。

适用边界 · 注意事项

• 产品尚未开发完成、代码库还无法运行或构建时。
• 用户只是想要技术架构建议或功能规划，而不是从现有代码到上线的落地路径时。
• 用户没有代码库访问权限、无法进行代码审计时。