本文不涉及代码，只涉及编排，本质上是提示词工程，十分简单。
Table of contents
Open Table of contents
vibe coding简介
Vibe Coding 不是把开发工作全部交给 AI，而是让人从写代码的人，变成设计系统、描述需求、检查结果的人。AI 可以负责大量具体实现，但产品应该做什么、系统应该怎么设计、什么结果才算正确，依然需要人来决定。
提示词工程（局部）
先从最简单的开始，提示词工程。
可以按以下结构来写提示词
背景 —— 任务 —— 限制 —— 输出方式 —— 参考案例
比如：
“这是一个 Next.js + TypeScript 项目。请创建用户资料页面，需要支持加载状态、错误处理和无障碍访问；组件分别放在独立文件中，代码风格参考项目现有的 Button 组件。”写完提示词之后要进行评审，比如
ADD THIS AFTER
"Now review the code you just generated. Check for:
- Security issues (especially password/session handling)
- Edge cases that are not handled
- Types that could be tighter
- Anything that would fail in production
What would you change?"检查修复后可以问:
“这段代码里，还有哪一点是你没有把握的？”这句话通常能挖出真正的薄弱环节。
在体量较大的功能提示词末尾加上下面这句话，你会得到原本忘了写进需求里的无障碍适配、加载状态和边界防护逻辑。默认情况下，大模型会尽量缩小实现范围。这句话明确允许它增加有用的额外实现 —— 键盘支持、防抖提交、频率限制等，无需再单独写一段提示词。
你可以自行增加任何你认为对该功能必要或有价值的逻辑，请自行判断取舍。我将其该概括为“一词三追问”，也就是按结构写完所有提示词后，可以进行三轮追问。但不是每次提示词后都要追问这三点。也不是三条全要追问，根据情况选择。
ARC方法（整体）
如果我们要做一个稍微复杂的项目，我们就不能仅仅依赖提示词工程。要分开来处理，不然每一处效果很差。这里推荐使用ARC方法（Architect —— Refine —— Check）。
ARC方法：使用强推理模型先思考，先让它理解需求、分析项目、设计架构，把问题拆开。之后拿编码模型来实现代码，把整块的任务拆成多个小任务，每次解决一个明确的问题。最后最好用其他厂商模型检测代码漏洞，没有的话就新开一个对话检查。
context files
对于复杂项目，我们还需要上下文文件来帮助模型理解项目。不然一段时间后模型就会忘记项目规范。所以要写上下文文件，记录项目规范。大致分为以下三种。
agents.md/claude.md
有时候ai的变量常量等命名方式不易读，写代码采用风格不统一，会出现bug不易发现，并且代码可读性很差的现象。针对这个可以写一个agent.md放到根目录让ai自动读取（如果是用到claudecode就写claude.md,内容可能有略微差异），里面记录技术栈、代码规范、目录结构、命名方式、允许 AI 做什么、禁止 AI 做什么。整个项目都要按照这个规范来，这样项目就变的清晰。
The Contract File System
如果采用多ai工具开发，前后端用不同的ai，会遇到信息不同步，于是ai会自行脑补接口，产生 bug。可以用契约文件来约束：（API_CONTRACT.md、TYPES_CONTRACT.md、STATE_CONTRACT.md）
| 文件 | 定义内容 |
|---|---|
| API_CONTRACT.md | 所有接口：请求方法、接口路径、请求参数结构、响应数据结构、错误码 |
| TYPES_CONTRACT.md | 前后端栈两边共用的 TypeScript 类型与接口 |
| STATE_CONTRACT.md | 全局状态结构、存储结构，前端可预期存在的数据 |
所有契约文件都放在项目根目录，和上下文文件同级。用Git版本管理，修改契约可通过git diff审计。每次新增或者修改内容，一方ai都要同步更新契约文件，另一方ai要先获得更新后的契约文件再进行修改。
只要开发涉及 API 相关内容，第一件事永远是粘贴契约文件。任何工具都不允许自行揣测另一端的数据结构。不在契约里定义的内容，就视为不存在。
prompts.md
改完以后再看忘了为什么当初这样修改？为什么没有选择另种修改方式？因为另一种修改方式有问题。如果以后再遇到类似的修改怎么办？prompts.md主要写为什么不能这么做，当初这样做遇到了什么问题。记录的是当时为什么这么设计，以及 AI 是怎么被要求做的。建议把它放在 repo 根目录，只记录会影响架构、安全或重要 trade-off 的 prompt，不要什么小修改都记。
项目目录
project-root/
├── CLAUDE.md ← Project rules + stack (Claude Code reads this)
├── AGENTS.md ← Agent workflow rules
├── API_CONTRACT.md ← Endpoint specs (Claude Code writes, Cursor reads)
├── TYPES_CONTRACT.md ← Shared types (both tools read and write)
├── STATE_CONTRACT.md ← Store shape (Claude Code writes, Cursor reads)
├── PROMPTS.md ← Architecture decisions log
└── src/
├── app/ ← Frontend (Cursor)
└── api/ ← Backend (Claude Code)需要知道的信息
什么是git，github，vercel
- git：电脑本地的版本控制工具，给代码做存档，可随时回退版本。
- GitHub：存放 Git 代码仓库的云端平台，用来备份、分享、团队协作代码；
- Vercel：前端网站自动部署平台，连上 GitHub 仓库，代码更新就自动构建上线网站。
vibe coding常见命令
常见终端命令：
- cd 切换目录
- ls 列出目录内容
- npm install 安装依赖
常见git命令：
- git add . 添加所有文件到暂存区
- git commit -m “提交信息” 提交暂存区的文件到本地仓库
- git push 推送本地仓库的代码到远程仓库
部署
The Golden Workflow:
1. Push your code to GitHub.
2. Connect complete repo to Vercel.
3. Vercel detects Next.js/Vite automatically.
4. Click "Deploy".
5. Receive a live URL (app.vercel.app).vibe wall
vibe wall是随着项目复杂度增加，已经超过了ai当前的有效理解范围。
比如说刚开始用 AI 做产品的时候，速度非常快，页面出来了，登录做完了，数据库也接好了。再增加几个新功能，突然发现：改一个地方，另外两个地方坏掉，AI 开始重复创建已经存在的组件，同一次对话里给出互相矛盾的建议。越来越乱，最后甚至说不清整个项目是怎么工作的。
只凭感觉，用自然语言让ai写代码，项目到中等复杂度就会碰到这面墙，并且无法避免。遇到了应该如何处理？
- 1.首先停止生成，用git回到最近的正常版本。
- 2.新开一个对话，让ai先分析整个/src，列出每个模块、组件的作用、依赖关系等。
- 3.及时更新项目上下文文件。把实际架构重新写进：AGENTS.md，API_CONTRACT.md，STATE_CONTRACT.md等。
- 4.后续拆成小步骤进行，一次只改一个功能。
其他
经常重复的提示词建议做成skill。