vibe-coding-production

上线准备：从 demo 到正式系统

这是 vibe-coding-kit 里负责"上线"的 Skill。只想验证想法的人用不到它——决定把项目做成能长期运行、给别人用的正式系统时，再来。

前置：先用 vibe-coding-requirements 说清需求、vibe-coding-architecture 选好技术。开发全程配合 vibe-coding-survival 避坑。

每个环节都配了直接发给 AI 的话术和你用来验收的标准——你不需要会写代码，只需会问、会检查。

---

准入检查（开始本阶段前必做）

本 skill 是流程第三阶段 S3·上线准备。开始前：

1. 读 docs/进度账本.md。 确认 S2 架构选型出口门已过（技术栈已选定），且用户明确确认"要做成正式系统、给别人用"。只想跑 demo 的人不进 S3。
2. 任一条不满足就别开始：需求/选型没定完，先回 S1/S2；用户只想验证想法，就停在 demo，别硬上线。
3. 本阶段步骤对应账本：S3.1 开发规范 → S3.2 安全基线 → S3.3 部署 → S3.4 测试验收 →（可选）S3.5 文档。每过一步回写账本。

---

一、开发规范（对应 S3.1）

把下面四段整理成一份"规范说明"，每次让 AI 写代码时贴上，确保风格一致、日后好维护。

1.1 Git 分支策略（最简版）

main 分支          ← 永远是能稳定部署的版本
  └── dev 分支     ← 日常开发，AI 写的代码先合到这
        └── feat/xxx 分支  ← 每个新功能开一个，做完合回 dev

"每次写新功能时，顺便告诉我：① 该建什么分支名 ② commit message 写什么。"

（完全不用 git 也没关系，但至少要做 vibe-coding-survival 里的"保住能用的版本"——那是 git 的朴素替代。）

1.2 日志规范

"所有关键操作必须打日志，格式统一为 [时间] [级别] [模块] 内容。级别分三级：INFO（正常流程）、WARN（异常但能自动恢复）、ERROR（需我人工处理）。至少记录：请求进入、鉴权结果、数据库操作、外部调用、返回结果。卡密、密码等敏感信息脱敏，只显示前 4 位和后 4 位，中间用 *** 代替。"

1.3 错误处理规范

"所有可能出错的地方都要显式处理。错误信息必须含三要素：① 哪里出错（模块/函数名）② 为什么出错（具体原因）③ 建议怎么解决。绝不要把错误悄悄吞掉（catch 了却什么都不做）。"

1.4 代码风格

"代码注释用中文。每个函数上方注释说明：这函数做什么、输入什么、输出什么。变量名和函数名用英文，但要见名知意。"

---

二、安全基线（对应 S3.2）

▸ 过门：8 条逐条确认（标"已做"或"不适用"）→ 账本 S3.2 标 ✅。涉及钱/别人隐私的，触发 survival 红线、提示找真人。

逐条把要求提给 AI，再逐条确认它做没做到。

#	安全要求	对 AI 说的话
1	鉴权	"所有接口都要验证身份，没通过的直接拒绝，返回 401。"
2	防暴力破解	"同一 IP 连续失败 N 次后，锁定 M 分钟。"
3	输入校验	"所有用户输入都要校验和清理，防止注入攻击。"
4	HTTPS	"生产环境必须用 HTTPS。"
5	敏感信息保护	"密钥、密码用环境变量或配置文件读取，绝不写死在代码里。"
6	日志脱敏	"敏感数据在日志里脱敏。"
7	最小权限	"数据库连接用最小必要权限，不要用 root。"
8	错误信息	"对外返回的错误信息不要暴露内部实现细节。"

开源专属提醒： 把代码公开（push 到 GitHub 等）之前，务必再确认一遍：代码里、配置里、提交历史里，没有任何密钥、密码、token。一旦推到公开仓库，就当全世界都看到了——即使事后删除也来不及，必须立刻作废并更换那个密钥。最稳妥的做法是把密钥放进一个单独的配置文件，并让 AI 帮你把它加进 .gitignore（让 git 永远忽略它）。

注意红线： 涉及真实收付款、存别人的个人信息等，别独自硬上——见 vibe-coding-survival 的「红线」。