Awesome 15docsVibe Coding 的个人实践
这里记录我在 Vibe Coding 模式下的个人实践要点。
这份手册综合了官方实践（Cursor 的 agent best practices、harness engineering 相关文章）、直播/教程里反复出现的方法，以及社区复盘里最稳定、最可复用的技巧，不走“纯玄学流”。 youtube
核心原则
Vibe coding 真正高效的前提，不是“把活全丢给 AI”，而是把开发变成“规格明确、小步推进、快速验证、随时回退”的闭环，这一点在 Cursor 官方指南、社区教程和经验复盘里高度一致。 martinfowler 你可以把 AI 当成一位速度很快但容易过度发挥的工程师：它适合在清晰目标和强反馈下工作，不适合在模糊目标、超长上下文和弱验收下自由发挥。 ignorance 因此整套手册只有一句总原则：先定义，再生成；先验证，再继续；先回退，再补救。 blog.langchain
开工前
每个需求都先产出一份轻量 spec，至少包含目标、技术栈、里程碑、约束、验收条件和“不做什么”，因为官方与社区都强调“先计划后编码”能显著提升 agent 成功率。 creatoreconomy 如果需求还不清楚，先让 AI 只做两件事：第一，提出澄清问题；第二，给出 2 到 4 个实现方案，并把最简单方案排在前面，不允许直接开始写代码。 creatoreconomy 项目层面再准备一份常驻规则文件，写清构建命令、测试命令、代码风格、目录约束、禁改区域和典型参考文件；规则要短、稳定、普适，不要把整本规范手册塞进去。 martinfowler
单次工作流
推荐你把每次开发都固定成 6 步：写计划、确认计划、只做一个最小改动、立刻测试、看 diff、再决定继续还是回退，这种“小步快跑”是教程、官方文档和社区指南里出现频率最高的模式。 nxcode 给 AI 的指令尽量使用同一种结构：任务目标、修改范围、约束、验收标准、禁止事项，例如“只改这 2 个文件”“不要修改测试”“先告诉我计划不要编码”“实现最简单可验证的一步”。 ignorance 遇到 bug 时，不要自己转述一大段，而是把报错、截图、复现步骤和期望行为直接交给 AI；Karpathy、Cursor 官方和多份教程都强调，原始错误信息和视觉上下文往往比抽象描述更有效。 x
上下文管理
上下文是 vibe coding 最容易失控的地方，多个来源都明确提到：对话一长、工具一多、无关文件一多，模型就会开始失焦、重复犯错，甚至进入“越聊越笨”的状态。 blog.langchain 实操上建议这样管：一个 chat 只做一个功能或一个 bug；一旦任务切换、AI 开始反复犯同样错误、或者上下文明显变脏，就立刻开新会话。 nxcode 不要把整个仓库和所有说明一次性塞进去，而是用“项目规则 + 当前任务 spec + 少量相关文件 + 必要截图/日志”的组合；如果需要更复杂的探索，把研究、实现、调试拆给不同子任务或子 agent，当作上下文隔离手段而不是角色扮演游戏。 martinfowler
质量门禁
Vibe coding 想从“好玩”变成“可靠”，关键不是更会说 prompt，而是让 AI 始终面对可验证目标；Cursor 官方和 harness 实践都把测试、类型检查、构建、lint 这些反馈机制当成最高杠杆项。 infoq 你们团队至少要固定 5 条门禁：每次改动后跑最小测试集、成功时静默失败时才回显错误、频繁 commit、保留 checkpoint/回滚点、关键配置文件和高风险代码必须人工 review。 ignorance 更进一步的成熟做法是加 hooks 和 reusable skills：例如在 agent 停止时自动触发 typecheck、自动拒绝危险命令、把“实现新接口”“补测试”“开 PR”做成固定工作流，而不是每次临场发挥。 martinfowler
团队版手册
如果是团队协作，我建议把 vibe coding 分成三层：第一层是仓库级规则，第二层是任务级 spec，第三层是个人提示习惯；前两层尽量标准化，最后一层允许个人风格存在。 nxcode 团队统一的最低配置可以非常小：一个 AGENTS.md 或 rules 目录、一套 build/test/lint 命令、一个 feature spec 模板、一个 bug 修复模板、一个提交前检查清单，这已经比“人人各自发挥”稳定得多。 blog.langchain 真正成熟的团队不会追求“一次生成全对”，而是优化迭代速度、回滚能力和错误暴露速度；HumanLayer 和 Cursor 的实践都明确指出，持续修正 harness 比盲目寄希望于下一个更强模型更有效。 ignorance
下面这份可以直接作为你们团队的日常口令模板使用： blog.langchain
- “先阅读相关代码，给我一个最小实现计划，不要开始编码。” ignorance
- “只修改这些文件：
A、B；不要改测试，不要改配置。” nxcode - “先实现最简单、可手工验证的一步，完成后告诉我如何测试。” youtube
- “现在运行类型检查和相关测试，只返回失败项，不要贴全部成功日志。” martinfowler
- “如果你不确定方案，先给我 3 个选项，从最简单开始。” blog.langchain
- “如果当前会话上下文已经变脏，请先总结现状，再建议是否新开 chat。” martinfowler
我建议你们先从“个人版轻量流程”落地一周：spec -> plan -> smallest step -> test -> diff review -> commit，跑顺之后再补 rules、hooks 和 skills，这样最符合官方和社区里验证过的渐进式做法。 nxcode 下一步我可以直接把这份手册改写成你们仓库可落地的 3 个文件：AGENTS.md、feature-spec-template.md、bugfix-playbook.md。
可以，下面我直接给你 3 份可落地的仓库文件骨架。AGENTS.md 的主流做法，本质上就是给 coding agent 一个稳定、可预测的位置来读取项目上下文、命令、边界和工作规则，而高质量模板通常都会包含项目结构、允许的命令、风险边界、示例和失败时的处理方式。 agents
放置方式
建议先放这 3 个文件：仓库根目录 AGENTS.md、目录 docs/feature-spec-template.md、目录 docs/bugfix-playbook.md。 github 这种拆法符合社区里常见的“项目级常驻规则 + 任务级文档模板”思路，能减少超长 prompt，把稳定规则和临时需求分开管理。 blundergoat
AGENTS.md
这个文件要尽量短、稳定、可执行，重点放“长期不变的规则”，不要把临时任务、一次性需求和太细碎的讨论塞进去。 builder
# AGENTS.md
## Purpose
This repository uses coding agents for implementation, refactoring, testing, and debugging.
Your goal is to make the smallest correct change that satisfies the requested outcome.
## Working style
- Prefer small diffs over broad rewrites.
- Read relevant files first, then propose a short plan before coding.
- When requirements are unclear, ask clarifying questions before implementation.
- Do not assume missing business logic.
- Do not silently change architecture, naming conventions, or persistence strategy.
## Project priorities
1. Correctness.
2. Safety.
3. Maintainability.
4. Small diffs.
5. Speed.
## Standard workflow
For any non-trivial task, follow this sequence:
1. Read the task and inspect only relevant files.
2. Summarize current behavior in 3-8 bullets.
3. Propose a minimal plan.
4. Implement one small step.
5. Run the narrowest relevant checks first.
6. Report what changed, risks, and next step.
## Scope control
- Only modify files directly related to the task.
- Do not rename or move files unless necessary.
- Do not introduce new dependencies without approval.
- Do not perform broad refactors while implementing a feature or bug fix.
- If you notice unrelated issues, mention them separately instead of fixing them silently.
## Architecture rules
- Follow the existing layering and module boundaries.
- Do not put business logic in controllers, routes, or UI components.
- Reuse existing services, repositories, helpers, and patterns before creating new ones.
- Prefer consistency with nearby code over personal preference.
- If an existing pattern looks wrong, flag it before changing it.
## Code style
- Use clear names and small functions.
- Avoid duplicate logic.
- Prefer explicit error handling.
- Keep public interfaces stable unless the task explicitly requires a change.
- Add comments only when intent is not obvious from code.
## Testing rules
- For new behavior, add or update tests when the codebase already has a test pattern.
- Run the smallest relevant checks first.
- Do not claim success without naming the checks you ran.
- If tests cannot be run, say so clearly and explain why.
## Commands
Replace the following with repo-specific commands.
### Install
- `make setup`
### Dev
- `make dev`
### Lint
- `make lint`
### Type check
- `make typecheck`
### Unit tests
- `make test`
### Targeted test example
- `make test TEST=path/to/file`
### Build
- `make build`
## Permissions
Allowed without asking:
- Read files.
- Search code.
- Run targeted lint/typecheck/test commands.
- Edit files directly related to the requested task.
Ask before:
- Adding dependencies.
- Deleting files.
- Renaming files or moving directories.
- Changing database schema.
- Changing CI/CD, infra, secrets, auth, billing, or permissions.
- Running full e2e suites or expensive builds.
- Performing destructive commands.
Never:
- Commit secrets or credentials.
- Modify production config without explicit approval.
- Fake test results.
- Mark a task done when checks are failing.
## Context files
Check these files when relevant:
- `README.md` — project overview
- `docs/feature-spec-template.md` — feature request template
- `docs/bugfix-playbook.md` — bug investigation workflow
- `docs/architecture.md` — architecture and boundaries
- `docs/domain-glossary.md` — business terms
- `docs/decisions/` — important design decisions
## Output format
For each task, respond with:
1. Plan
2. Changes made
3. Checks run
4. Risks / follow-ups
## When stuck
If blocked, do one of these:
- Ask 3-5 precise clarifying questions.
- Propose 2 implementation options with trade-offs.
- Produce a short investigation summary without coding.使用建议
落地时先不要追求“大而全”，第一周只要求团队做到 3 件事：所有任务先写 spec、所有修改先看 plan、所有完成都要报 checks run，这已经能明显减少 vibe coding 的失控率。 nxcode 等你们跑顺后，再补 repo-specific 内容，例如真实命令、目录边界、禁改模块、典型参考文件和审批规则；AGENTS.md 最终效果好不好，关键往往不在“写多”，而在“写得具体、稳定、可执行”。 github
通用规则块
先准备一个你可以反复复用的“前置规则块”，每次任务开头先贴这一段，能明显降低 agent 自由发挥过头的问题。 humanlayer
你是这个仓库里的代码代理，请严格遵守以下规则：
1. 先阅读相关代码，再输出简短计划，不要立刻开始编码。
2. 优先做最小可行改动，避免大范围重构。
3. 只修改和当前任务直接相关的文件。
4. 不要新增依赖、不要改 schema、不要改配置，除非我明确批准。
5. 如果需求不清楚，先提出澄清问题。
6. 完成后必须汇报：
- 改了哪些文件
- 为什么这样改
- 跑了哪些检查
- 还剩什么风险
7. 如果你不确定，请先给两个方案，并说明 trade-off。
8. 不要假装测试通过；如果没跑，就明确说没跑。这段适合作为所有提示词的统一前缀，相当于把“工作风格”和“风险边界”固定下来。 cursor
新功能模板
这个模板适合“实现一个小功能 / 新接口 / 新页面交互”，重点是让 agent 先收敛需求，再按最小步落地。 creatoreconomy
任务：实现一个新功能。
目标：
[在这里写业务目标]
范围：
- 只处理：[模块 / 页面 / 接口]
- 相关文件大概率在：[路径1] [路径2]
- 不要处理范围外问题
约束：
- 先阅读相关代码并总结当前实现方式
- 先输出一个最小实现计划，不要直接编码
- 优先复用现有模式、现有服务、现有组件
- 不要做顺手重构
- 不要新增依赖
- 不要修改无关文件
验收标准：
- [标准1]
- [标准2]
- [标准3]
执行要求：
1. 先列出你打算查看的文件
2. 用 3-7 条总结当前实现
3. 给出最小实现计划
4. 等我确认后再开始编码
5. 编码后运行最小相关检查
6. 最后输出 changed files / checks / risks如果你们需求还不稳定，可以在“验收标准”后面再加一句：“如果发现需求存在歧义，请先列出 3 个需要确认的问题。” 这种写法很适合业务系统。 humanlayer
Bug 修复模板
社区和官方实践里，bug 修复最怕的就是“一上来就改”，所以这个模板强制它先复现、先判断根因、再做最小修复。 x
任务：修复一个 bug。
问题描述：
[贴现象、报错、截图说明、复现步骤]
要求：
- 先不要改代码
- 先阅读相关代码并分析可能根因
- 先输出：
1. 复现路径
2. 可能根因（2-4 个）
3. 你认为最可能的根因
4. 最小修复方案
- 只改修复这个 bug 必需的文件
- 不要做顺手重构
- 如果无法稳定复现，要明确说明缺什么信息
验证要求：
- 尽量补一个能覆盖该问题的测试
- 至少运行和该问题最相关的检查
- 说明修复是否覆盖原始报错场景
最终输出格式：
- Root cause
- Files changed
- Checks run
- Residual risks如果你手里有日志或报错，最好原样粘进去，不要自己二次翻译，这样通常更有效。 x
重构模板
重构很容易失控，所以提示词里最重要的是先“限定不改什么”。 creatoreconomy
任务：对现有代码做小范围重构。
重构目标：
[例如：提取重复逻辑 / 改善可读性 / 减少某个函数复杂度]
明确边界：
- 不改变外部行为
- 不改变 API 契约
- 不改变数据库 schema
- 不新增依赖
- 不修改无关测试
- 不跨模块扩散
执行要求：
1. 先识别当前坏味道
2. 说明为什么值得重构
3. 给出最小重构方案
4. 分步骤实施，每一步尽量可单独验证
5. 如果发现需要扩大范围，先停下来说明原因，不要自行扩展
输出要求：
- Before/after 变化摘要
- 改动文件列表
- 行为不变的依据
- 跑过哪些检查这个模板适合“想让 AI 帮你整理代码，但又不想它把半个仓库都改了”的情况。 humanlayer
先出方案模板
当你自己也没想清楚怎么做时，不要让它直接实现，先让它当方案顾问。 youtube
先不要编码。
我想解决这个问题：
[问题描述]
请你先完成以下任务：
1. 阅读相关代码
2. 总结当前实现方式
3. 给出 3 个可行方案
4. 对每个方案说明：
- 改动范围
- 优点
- 风险
- 适合什么场景
5. 最后推荐一个“最简单、最稳妥”的方案
限制：
- 不要开始写代码
- 不要给过度理想化的大改方案
- 优先推荐和现有代码风格一致的做法这个模板特别适合业务系统里的“到底应该加字段、加状态、还是补一层 service”这类问题。 cursor
补测试模板
很多直播和复盘里都强调，测试是让 vibe coding 从“能跑”变成“可控”的关键环节，这个模板专门用来补测试。 youtube
任务：为现有功能补测试。
目标：
为 [功能/模块] 增加最有价值的一组测试，优先覆盖核心行为和容易回归的边界。
要求：
- 先阅读现有测试风格和测试工具用法
- 先总结当前测试缺口
- 优先补最关键的 happy path 和 2-3 个边界场景
- 不要为了追求覆盖率写价值很低的测试
- 如果现有代码难测，先说明最小侵入式改法
最终输出：
- 新增 / 修改了哪些测试文件
- 覆盖了哪些场景
- 还有哪些高风险场景未覆盖
- 跑了哪些测试如果你想更强一点，可以再加一句：“先列出测试清单，等我确认后再写。” 这样非常稳。 cursor
大仓库探索模板
大代码库最常见的问题是 agent 一上来就迷路，所以先让它做“代码侦察”比直接编码更值。 humanlayer
这是一个较大的代码库，请先做探索，不要编码。
任务：
帮我快速理解 [某个业务流程 / 某个模块 / 某个接口链路]。
请输出：
1. 相关入口文件
2. 关键调用链
3. 核心数据结构 / DTO / model
4. 业务规则出现在哪些位置
5. 你认为最值得注意的风险点
6. 如果后续要改这个功能，最可能需要改哪些文件
要求：
- 输出要尽量具体，引用文件路径
- 不要泛泛而谈
- 如果你不确定，明确标注推测这个模板很适合你在真正开始 vibe coding 前，先让 agent 帮你做一轮“上下文收集”。 cursor
PR / Diff 审查模板
不只是写代码，agent 也很适合帮你做第一轮代码审查，但提示词要明确优先级，不然它容易只挑格式问题。 humanlayer
请审查这次改动，按优先级输出问题。
审查重点顺序：
1. 逻辑正确性
2. 边界条件
3. 状态一致性 / 幂等性
4. 安全和权限
5. 可维护性
6. 风格问题（最后再说）
要求：
- 优先指出真正会导致 bug 的问题
- 每个问题说明：
- 严重级别
- 具体文件 / 位置
- 为什么有风险
- 建议如何修复
- 如果没有明显问题，也请说明你重点检查了哪些方面这个模板适合让 Cursor / Claude Code 作为“第一审查员”，尤其适合业务逻辑和接口改动。 cursor
脏上下文重置模板
当会话已经开始胡说、重复、跑偏时，不要继续硬聊，直接切换到这个模板。 creatoreconomy
先不要继续编码。
我怀疑当前上下文已经变脏了，请你只做整理：
1. 总结我们当前已经确认的事实
2. 总结你已经完成的改动
3. 总结还没解决的问题
4. 列出继续推进最需要的 3 条信息
5. 给出一个适合在新会话里继续的精简任务描述
要求：
- 不新增推测
- 不继续扩展实现
- 只做事实整理和任务压缩这类“会话压缩提示词”在长任务里非常有用，本质上是在手工做上下文管理。 humanlayer
你可以直接这样组合使用
一个很好用的日常组合是：
- 先贴“通用规则块”。 cursor
- 再贴“先出方案模板”或“新功能模板”。 creatoreconomy
- 编码完成后，再贴“PR / Diff 审查模板”做第二轮检查。 humanlayer
- 如果会话跑偏，就用“脏上下文重置模板”收束后新开会话。 creatoreconomy
最推荐的万能模板
如果你只想先用一条最通用的，我建议先从这条开始： creatoreconomy
你现在是这个仓库里的代码代理。
任务：
[写清楚目标]
范围：
- 只处理：[模块/文件/功能]
- 不处理：[明确排除项]
先不要编码，先做下面几步：
1. 阅读相关代码
2. 用 3-7 条总结当前实现
3. 给出最小实现计划
4. 标出你不确定的点
5. 等我确认后再开始修改
执行约束：
- 优先最小改动
- 不做顺手重构
- 不新增依赖
- 不修改配置 / schema / 权限逻辑，除非我明确批准
- 完成后必须说明 changed files / checks run / residual risks
- 如果没跑检查，不要假装跑过