vibe‑coding 九阳神功之收：上线不是终点，是另一个开始
vibe‑coding 九阳神功之收：上线不是终点，是另一个开始
系列顺序：夯（Git） → 抄 → 学 → 喂 → 规 → 验 → 测 → 扩 → 收 一句话：代码写完不叫交付，上线跑稳才叫交付。上线、监控、回滚、复盘——一个都不能少。
AI 编程现在最大的坑不是”不会写”，而是：
- 写得太快
- 改得太多
- 炸了没后路
- 炸完你甚至不知道它到底改了哪些文件
所以我准备写一套 vibe‑coding 九阳神功：核心不是提示词，而是把 AI 变成”可控交付的队友”。
这套”九阳神功”我先定了九个字诀：
- 夯：Git 生存技能（刹车 / 保险 / 录像）
- 抄：拆解
yfge/orion、ai-shifu/ai-shifu的优秀骨架，搭底盘 - 学：学习行业黑话，会组合技术栈、不懂原理也能不翻车
- 喂：把 API 文档 / 资料结构化成可执行知识
- 规：让 AI 出计划 +
tasks.md，按清单推进 - 验：多模型交叉验证，专治幻觉
- 测：自动测试，交付有证据
- 扩：扩展认知边界，但必须可验证
- 收：上线交付、监控回滚、复盘闭环
最后一式 收：上线交付、监控回滚、复盘闭环——把 vibe‑coding 的成果真正落地。
为什么”收”是最后一式？
因为前面八式都是在”做”，只有”收”是在”交”。
你可以代码写得很漂亮、测试全绿、方案被两个 AI 交叉验证过——但如果上线出了事回不了滚、监控不到异常、复盘没有沉淀，那前面的工作白做了一半。
“收”的核心：上线不是终点，是另一个开始。收 = 上线 + 监控 + 回滚 + 复盘。
1）上线 Checklist：AI 帮你列，你来过
让 AI 帮你生成上线检查清单，但你必须每项过一遍：
项目即将上线，请生成上线 checklist：
要求：
1) 按"上线前 / 上线中 / 上线后"三阶段列
2) 每项给具体的检查命令或操作步骤
3) 标注哪些是"阻断项"（不过就不能上线）
AI 生成的 checklist 示例：
## 上线 Checklist
### 上线前（阻断项标 🚫）
- [ ] 🚫 所有测试通过：`pytest tests/ -v` 全绿
- [ ] 🚫 冒烟测试通过：`bash scripts/smoke-test.sh`
- [ ] 🚫 数据库 migration 在测试环境验证过
- [ ] 🚫 环境变量配置完整（对照 .env.example）
- [ ] 代码已 review（至少一个人看过，AI 也算）
- [ ] 新功能有对应的监控指标
- [ ] 回滚方案已确认（写在下面）
### 上线中
- [ ] 备份当前数据库：`pg_dump -Fc production > backup-$(date +%Y%m%d).dump`
- [ ] 记录当前版本号：`git rev-parse HEAD > /tmp/last-version.txt`
- [ ] 执行部署：`git pull && docker compose up -d --build`
- [ ] 执行 migration：`alembic upgrade head`
- [ ] 冒烟测试：`curl -f https://yoursite.com/api/healthz`
### 上线后（30 分钟内）
- [ ] 检查错误日志：`docker compose logs api --since 30m | grep -i error`
- [ ] 检查核心指标：响应时间、错误率、请求量
- [ ] 手动走一遍核心流程（注册/登录/核心操作）
- [ ] 确认新功能正常工作
- [ ] 在群里通知"上线完成"
2）回滚方案：上线之前就写好
铁律：没有回滚方案，不许上线。
回滚方案不需要多复杂，但必须提前写好。让 AI 帮你：
请根据本次上线内容，写一个回滚方案 docs/rollback-plan.md：
1) 代码回滚步骤（git revert 还是切分支）
2) 数据库回滚步骤（如果有 migration）
3) 配置回滚步骤（如果改了环境变量）
4) 回滚后的验证步骤
5) 预估回滚耗时
AI 输出的回滚方案：
## 回滚方案：v1.3.0 → v1.2.0
### 触发条件
以下任一情况出现时执行回滚：
- 核心 API 错误率 > 5%（持续 5 分钟）
- 用户反馈无法登录/支付
- 数据库 CPU > 90%
### 代码回滚
```bash
# 记录当前版本
CURRENT=$(git rev-parse HEAD)
echo "回滚前版本: $CURRENT"
# 切到上一个稳定版本
git checkout v1.2.0
docker compose up -d --build
# 验证
curl -f https://yoursite.com/api/healthz
数据库回滚
# 如果 migration 有问题
alembic downgrade -1
# 如果数据被污染，用备份恢复
pg_restore -d production backup-20260221.dump
回滚后验证
curl https://yoursite.com/api/healthz返回 200- 手动登录一次
- 检查错误日志清零
- 在群里通知”已回滚到 v1.2.0”
预估耗时：5 分钟
---
## 3）监控：让 AI 帮你加"眼睛"
代码上线后，你需要知道它在"生产环境"跑得怎么样。
### 最小监控方案（适合个人项目/小团队）
```text
请给项目加最小监控方案：
1) 健康检查接口（/api/healthz）
2) 关键操作的日志（注册/登录/支付必须有日志）
3) 一个简单的监控脚本（定时检查，挂了就报警）
健康检查接口：
# 不是返回个 "ok" 就完了，要真的检查依赖
@app.get("/api/healthz")
async def healthz():
checks = {}
# 检查数据库
try:
await db.execute("SELECT 1")
checks["database"] = "ok"
except Exception as e:
checks["database"] = f"error: {e}"
# 检查 Redis
try:
await redis.ping()
checks["redis"] = "ok"
except Exception as e:
checks["redis"] = f"error: {e}"
all_ok = all(v == "ok" for v in checks.values())
return JSONResponse(
status_code=200 if all_ok else 503,
content={"status": "healthy" if all_ok else "unhealthy", "checks": checks}
)
简单监控脚本：
#!/bin/bash
# scripts/monitor.sh - 加到 crontab 里，每 5 分钟跑一次
URL="https://yoursite.com/api/healthz"
STATUS=$(curl -s -o /dev/null -w "%{http_code}" "$URL")
if [ "$STATUS" != "200" ]; then
# 发飞书/Slack/邮件报警
curl -X POST "https://open.feishu.cn/open-apis/bot/v2/hook/YOUR_WEBHOOK" \
-H 'Content-Type: application/json' \
-d "{\"msg_type\":\"text\",\"content\":{\"text\":\"🚨 服务异常！healthz 返回 $STATUS\"}}"
fi
# 加到 crontab
*/5 * * * * /path/to/scripts/monitor.sh
关键操作必须有日志
import logging
logger = logging.getLogger(__name__)
async def register_user(email: str, password: str):
logger.info(f"用户注册开始: email={email}")
try:
user = await create_user(email, password)
logger.info(f"用户注册成功: user_id={user.id}, email={email}")
return user
except DuplicateEmailError:
logger.warning(f"用户注册失败-邮箱重复: email={email}")
raise
except Exception as e:
logger.error(f"用户注册失败-未知错误: email={email}, error={e}")
raise
原则：关键操作（注册、登录、支付、数据变更）必须有 info 级别日志，异常必须有 error 级别日志。上线后出了问题，日志就是你的”黑匣子”。
4）复盘：让 AI 帮你写，但你自己过
每次上线后（不管成功还是翻车），花 15 分钟做复盘。
本次上线已完成，请帮我生成复盘模板 docs/retro/2026-02-21.md：
包含：
1) 本次上线了什么（功能列表）
2) 上线过程是否顺利（耗时、是否回滚过）
3) 发现的问题（即使没出事，也记录"差点出事"的）
4) 改进项（下次上线前要做的）
5) 更新到项目知识库的内容
复盘模板示例：
## 复盘：2026-02-21 上线飞书通知渠道
### 上线内容
- 新增飞书 Webhook 通知渠道
- 消息重试机制优化（指数退避）
### 过程
- 上线耗时：15 分钟
- 是否回滚：否
- 冒烟测试：通过
### 发现的问题
1. 飞书 Webhook 有频率限制（每分钟 100 次），差点触发
- 根因：重试机制没有做全局限流
- 修复：下个版本加 rate limiter
2. Migration 在生产环境比测试环境慢 10 倍
- 根因：生产数据量大，ALTER TABLE 要锁表
- 改进：大表 migration 以后用 pt-online-schema-change
### 改进项
- [ ] 加消息发送的全局限流
- [ ] 大表 migration 用在线 DDL 工具
- [ ] 上线 checklist 加一项"评估 migration 对生产数据量的影响"
### 沉淀到知识库
- docs/ops/migration-best-practices.md：新增"大表 migration 注意事项"
- docs/ops/feishu-webhook-limits.md：记录飞书 API 的频率限制
5）闭环：从”收”回到”夯”
九阳神功最妙的地方在于：它是个环。
- 复盘中发现的问题 → 变成下次的 tasks.md（规）
- 新学到的技术限制 → 更新到 docs/_feed/（喂）
- 上线后的踩坑 → 沉淀到知识库（扩）
- 而这一切都在 Git 里有迹可循（夯）
夯 → 抄 → 学 → 喂 → 规 → 验 → 测 → 扩 → 收
↑ |
└───────────── 复盘驱动下一轮 ──────────────┘
每上一次线，你的”知识底座”就厚一层。下次 AI 帮你干活，依据更充分、约束更明确、验收更严格。
实战：一个完整的”收”流程
以 ai-shifu 新版本上线为例，完整走一遍：
# 1. 上线前
git tag v1.3.0 # 打 tag
pytest tests/ -v # 跑测试
bash scripts/smoke-test.sh # 冒烟测试
cat docs/rollback-plan.md # 确认回滚方案
# 2. 上线中
pg_dump -Fc production > backup-$(date +%Y%m%d).dump # 备份
git pull origin master # 拉最新代码
docker compose up -d --build # 部署
alembic upgrade head # 跑 migration
curl -f https://ai-shifu.com/api/healthz # 冒烟
# 3. 上线后
docker compose logs api --since 30m | grep -i error # 查日志
# 手动走一遍核心流程
# 在群里通知"上线完成"
# 4. 复盘（30分钟后）
# 让 AI 根据以上过程生成复盘文档
# 把改进项加到 tasks.md
# 更新知识库
总结：九阳神功，九字收功
收的核心就一句话：上线不是终点，是另一个开始。
- 上线 checklist：AI 帮列，你来过，阻断项不过不上
- 回滚方案：上线前就写好，3-5 分钟能回滚
- 监控：至少有健康检查 + 关键日志 + 报警脚本
- 复盘：每次上线后 15 分钟，记录问题、沉淀知识
- 闭环：复盘结果驱动下一轮迭代
九阳神功全篇回顾
九个字，九式功法，一条主线——把 AI 从”会写代码”变成”能交付上线”：
| 字诀 | 核心 | 一句话 |
|---|---|---|
| 夯 | Git | 刹车、保险、录像——AI 炸了你还活着 |
| 抄 | 骨架 | 从好项目抄底盘，不要从零开始 |
| 学 | 黑话 | 你问得专业，AI 答得专业 |
| 喂 | 资料 | 喂确定性，砍掉 AI 的自由发挥空间 |
| 规 | 计划 | tasks.md 管住 AI，一步一验收 |
| 验 | 验证 | 多模型交叉验证，专治幻觉 |
| 测 | 测试 | 代码和证据一起交，测试全绿才算完 |
| 扩 | 边界 | AI 帮你学新东西，但必须能验证 |
| 收 | 闭环 | 上线、监控、回滚、复盘——完整闭环 |
记住：vibe‑coding 不是”让 AI 写代码”，是”带着 AI 把东西交付上线”。
九式练成，你不只是一个会用 AI 的人——你是一个能用 AI 持续交付的人。
这才是真正的 vibe‑coding。