这篇不是产品介绍，而是纯 VIBE CODING 复盘：我怎么和 AI（Claude Code / GPT 等）协作，把项目快速做出来，同时尽量保持代码质量、结构清晰、后期能维护。
一句话：我只死磕“核心价值”，其余尽量交给 AI，但用流程把质量兜住。
对我来说，VIBE CODING 不是“让 AI 随便写”，而是：
- 你负责：目标、边界、取舍、验收标准、最终决定权
- AI 负责：具体实现、重复劳动、样板代码、迁移/改造、补齐边角
- 流程兜底：小步提交、持续
format/lint/typecheck、随时可回滚
我会先在仓库根目录写一份“项目说明/约束”，比如 PROJECT.md，然后在 CLAUDE.md 里明确：
- 项目目标（要解决什么问题）
- 范围边界（不做什么）
- 技术栈与约束（比如全 TypeScript / monorepo / 代码规范）
- 目录结构约定（代码放哪、怎么命名）
- 每个任务的验收标准（跑哪些命令、有哪些 UI 行为）
原因很简单：方向错了，AI 写得越快，返工越多。
我的经验是：VIBE CODING 最怕“冷门/小众/文档少”的组合。
- 语言：脚本语言（TS / Python）通常更适合 AI 辅助快速迭代
- 框架：尽量主流（Next.js / Expo / Vite 等），AI 命中率更高
- 依赖：在引入新库前，让 AI 做对比（维护性、生态、坑、替代方案）
你真正要做的是：把“能跑通”变成“可持续迭代”。
我拆任务会遵循三个原则：
- 一次只做一件事（可验证）
- 输入给 AI 的上下文要足够（文件路径、约束、要改哪里）
- 输出必须有验收（命令 + 预期效果）
目标
- 做什么：……
- 不做什么：……
范围
- 只改这些文件：……
- 不要新增依赖（除非我确认）：是/否
验收标准
pnpm format通过pnpm check通过- 页面/功能行为：……
我强烈建议你在一开始就把这些命令跑通，并要求 AI 每次改完必须过：
formatlinttypecheck/check
这会显著减少“看起来能跑、实际上到处是小问题”的情况。
另外，建议把规则写进 CLAUDE.md，让 AI 知道你的底线：不准跳过检查。
如果你要做 Web + Mobile + Extension：
- 先把 Web 做成“可验证的参考实现”（功能、交互、接口）
- 再让 AI 参考 Web 去做 Mobile / Extension
这样做的好处：
- 需求更明确（照着抄，而不是凭空想）
- 调试更方便（Web 的反馈速度更快）
- 复用更高（接口、类型、数据结构都能复用）
我的目标是让 AI“拿到足够上下文”，而不是瞎猜。
grep/rg：快速定位用法与调用链exa：查外部资料/文档（需要时）playweight：需要页面交互验证时用- skills：把常用提示词沉淀成“技能”，减少重复沟通成本
- 方向先对：核心价值、竞品对比、技术路线，先想清楚再开写
- 拆小任务：AI 喜欢“小而清晰”的问题，越大越容易跑偏
- 用检查兜底：format/lint/typecheck 是 VIBE CODING 的安全带
建议你从这三个动作开始：
- 写一份
PROJECT.md：目标/边界/里程碑 - 写一份
CLAUDE.md：规则/约束/验收 - 把
format + check跑通：每次改动都过关
只要流程搭好，AI 的“爆炸产能”就会变成你的优势，而不是债务。