从 0 到 1 可持续 Vibe Coding：我做了一个 harness 工程的开发工作流 Skill

大家好，我是不会喷火的小火龙。

过去大半年，“Vibe Coding”成了技术圈讨论最多的词。

几句自然语言 Prompt，十分钟就能让 AI 搓出一个界面漂亮、能跑能点的原型。那种即时出成果的快感，确实让人很难再适应纯手写代码的节奏。

但如果试着用这套方式，从零打磨一个跨多个业务模块、需要长期维护的真实项目，大概率很快就会遇到现实瓶颈：

• 代码行数超过两三千行，上下文窗口变大之后，AI 开始自相矛盾，甚至顺手把之前写好的核心逻辑当成废弃代码重构掉；
• 数据表结构全凭 AI 自由发挥，字段缺少约束，加个小功能发现表关联全是乱的，修一个 Bug 反而引爆三个新 Bug；
• 屏幕上“暂时能跑”看着很美，底层架构却脆弱，前期省下的编码时间，后期要加倍以排错和返工的形式还回去。

很多开发者折腾到最后忍不住觉得：“AI 只能写写玩具，一碰复杂工程就抓瞎。”

可持续的 Vibe Coding，关键在于分工：人负责规划、架构、约束与最终验收，AI 则在明确的工程化护栏内负责高效执行。标准流程可以参考鱼皮哥的文章 Vibe Coding 项目开发流程

为了解决 AI 容易偏离预期的问题，我结合自己的踩坑经验与工程实践，最近多次迭代并开源了一个开发流 skill：vibe-workflow。它把一套原本需要人肉反复提醒的开发纪律，沉淀成了 AI 可以遵守的规则。

这篇文章主要梳理从 0 到 1 推进一个 Vibe Coding 项目的具体心法，并介绍 vibe-workflow 是如何在关键节点起到护栏作用的，后面会在实践过程中持续更新迭代。

一、规划比写代码重要：别给 AI 一个模糊的大 Prompt

很多 Vibe Coding 出现偏差，往往在敲下第一句 Prompt 时就已经埋下了隐患。

比如直接对 AI 说：“帮我做一个类似 Notion 的记事本，要有分类、标签和搜索。”

这是一个典型的模糊大 Prompt。AI 收到之后会立刻开始写代码，但在它的逻辑里缺少阶段和优先级。它可能会直接引入三个重型第三方编辑器库，同时实现没有经过验证的复杂树形目录，最后连基础的文本保存都会报错。

模糊的指令很容易产生边界不清的复杂工程。

在让 AI 动代码之前，先把四件事明确下来很有必要：

1. 核心用户路径：用户进入产品后，最核心的一条闭环操作到底是什么；
2. 技术栈与架构选型：为什么选这个框架，状态怎么管理，前后端如何通信；
3. 不做清单（Out-of-scope）：第一版明确不做什么，比做什么更重要，砍掉不必要的衍生需求，只保留核心闭环；
4. 可测试的验收标准：怎样才算做完，比如“创建后刷新页面不丢失”、“空输入提交有明确拦截提示”。

在 vibe-workflow 的设计中，这一步被固定为 Thinking 与 Planning 流程。

当提出一个新想法时，工具会先拦截 AI 盲目写代码的冲动。如果需求模糊，它会主动通过提问梳理不做清单与边界条件；在方案没有经过结构化确认之前，在规则层面限制编码权限，避免前期沉没成本过大。

二、领域建模：先定数据骨架，再画页面

初学 Vibe Coding 容易陷入的一个误区是视觉优先。

让 AI 一口气生成了十几个页面，界面做得很丰富，返回的数据全是 mock 假数据。等到准备接入真实后端时，才发现数据表结构混乱，底层实体关系根本支撑不了业务流转，只能推倒重来。

数据结构是业务的基石，长期可维护的项目，推导顺序通常是：

业务对象 ➔ 实体关系 ➔ 数据约束（主外键/唯一/索引）➔ 表结构与迁移 ➔ API 接口 ➔ 页面与交互

需要梳理清楚：

• 核心实体有哪些，是一对多还是一对一；
• 主键、唯一键和外键关系在哪里；
• 状态字段如何流转，是否需要软删除；
• 数据库变更必须有明确的迁移（Migration）脚本，能从零执行，也能安全回滚。

在 vibe-workflow 的规则里，对 AI 设定了明确的代码边界：只要涉及数据结构的调整，必须先写 Migration 迁移和约束校验，不能在未更新数据层的前提下先行拼凑业务代码。同时限制在 UI 组件里直接写 SQL 或越权查库，保持系统底层的整洁。

三、上下文工程：给每一个新 AI 会话准备项目说明

使用 Agent 编程常会遇到类似困扰： 昨天聊得好好的，今天新建一个会话窗口，AI 记不住之前的约定；或者写着写着，AI 突然改变了原有的目录规范。

因为 AI 只了解当前窗口里的临时上下文，并不天然理解项目的完整历史。

解决这个问题的关键是做好上下文工程（Context Engineering），核心载体就是项目根目录下的 AGENTS.md。

1. 打造清晰的 AGENTS.md

AGENTS.md 规定了 AI 在当前仓库里的行为规范，它不需要重复抄写全部需求，而是明确规则边界：

• 项目定位与架构约束：核心目录分别放什么，依赖方向怎样流向；
• 权威文档优先级：当代码与需求冲突时以哪份文档为准，避免随意猜测；
• 操作规范：哪些核心公共文件未获明确指令不得修改，不随意做无关的大重构；
• 完成标准：什么样的状态才算任务结束，比如测试通过、文档同步。

2. 闭环的轻量文档治理

代码会随迭代频繁变动，但核心架构决策需要沉淀在 docs/ 目录下（如 docs/architecture.md、docs/database.md）。

在 vibe-workflow 中，内置了 $vibe-workflow init 命令。接管新项目或旧仓库时，它会自动审计当前工程，提取事实源并建立规则基线。

隔天开启全新会话时，执行 $vibe-workflow 从仓库事实恢复当前软件项目，它会自动依据 Git 状态、现有测试用例和文档恢复任务进度，不再依赖零散的聊天记录。

四、控制工作边界：最小纵向切片与熔断机制

尽量避免对 AI 下达“帮我把这个系统完善一下”这类大指令。

这种黑盒指令往往会导致 AI 在几十个文件里同时做修改，最后留下难以定位的问题。

可持续的推进方式是采用最小纵向切片（Minimal Vertical Slice）：

• 每次只给 AI 指派一个边界清晰的小闭环，比如“只实现登录接口的频率限制，不改动响应格式”；
• 尽量拆成小批次的改动，避免一次性合并过大范围的代码；
• 审查修改一行权限校验代码，通常比审查十处文案更重要。

同时，在流程中设立熔断机制很有必要。

在实际开发中，容易遇到 AI 陷入反复修改的死循环：为了修一个报错改了 A 文件，导致 B 文件报错，改了 B 文件又导致 A 文件报错。

在 vibe-workflow 的 Building 阶段，设定了一条规则：如果连续 3 次尝试遇到同类失败，或者出现破坏已有稳定功能的倾向，Agent 必须立即停止盲改，主动保存当前现场并向开发者汇报原因。

这个机制能确保即使出现调试偏差，影响范围也能被控制在当次的小切片之内。

五、Harness 护栏：代码能跑不等于任务完成

围绕 AI 建立的这套工程体系，通常被称为 Harness（工程护栏）。

它由几道防线共同组成：

项目规则（AGENTS.md）+ 结构化任务切片 + 类型系统 + Linter 规范检查 + 自动化测试套件 + 人工最终审查

有了这套护栏，开发者的重心也相应转移：从单纯手动编写语法，转向把控产品方向、系统架构、上下文管理与最终审查。

在 vibe-workflow 的生命周期里，一条明确原则是：完成声明必须跟着证据走。

如下图所示，这是 vibe-workflow 在项目推进中运行的 7 阶段工程闭环：

在 Testing 阶段，Agent 汇报完成时需要交出对应的检查依据：哪些单测通过了、在运行环境下的响应如何。如果没有配置真实运行环境，则明确列出未经验证的缺口。

同时，遇到较重型的决策时，vibe-workflow 可以调度专项工具配合使用：

• 需要严苛梳理需求、做全量规划时，可以委派给 gstack 的 autoplan；
• 需要严格执行测试驱动开发、拆解细分切片时，可以调度 Superpowers；
• 无论外部扩展各自擅长哪块，整体的范围把控、事实记录与下一步决策，依然保留在 vibe-workflow 的主流程中。

如下表所示，两种模式在核心维度上的差异很直观：

六、实操：如何把这套工作流接入你的项目

把这套开发流应用到日常开发中，步骤相对直接。

1. 安装扩展

确保本地的开发环境（如 Claude Code 或支持相关规范的 Agent 工具）就绪后，在终端执行以下命令：

▼
bash
复制代码
npx skills add sz-xiaohuolong/vibe-workflow

安装完成后，该 Skill 就挂载到了 Agent 环境中。

2. 接管与恢复项目的两条核心指令

在实际使用中，比较常用的指令有两条：

• 场景 A：接管新项目或既有代码库 刚克隆了一个项目，或者准备把已有仓库纳入规范管理时，在对话中输入：

  ▼
  text
  复制代码
  $vibe-workflow init 审计当前仓库，沿用已有文档和构建入口，报告待澄清的事实。
  

  AI 会通读仓库，梳理技术栈、目录规范与现有规则，建立起清晰的开发基线。

• 场景 B：跨会话继续之前的进度 开启新的聊天窗口时，不需要复制之前冗长的聊天记录，直接输入：

  ▼
  text
  复制代码
  $vibe-workflow 从仓库事实恢复当前软件项目，并核验下一个待执行的任务。
  

  AI 会检视 Git 状态、当前未完成的切片文档以及测试结果，定位接下来需要处理的任务。

3. 上手建议

初次使用时，建议选一个范围清晰、验收条件明确的小需求来跑一遍闭环： 观察它在动手前是否协助确认好了边界，写代码时是否只修改约定的文件，汇报结果时是否能够对应具体的测试用例。

跑顺几次之后，开发过程会更加可控。

写在最后

AI 编程改变了代码生产的节奏，但软件工程本身的基本规律依然在起作用。

现在的关键在于：能不能拆解出清晰的领域模型、能不能制定出合理的工程护栏，以及能不能有效驾驭 AI 工具推进项目。

做好规划与边界约束，让每一部分改动都走在可验证的轨道上，才能真正发挥 AI 编程的长期复利。

我是小火龙，一个持续在 GitHub 等开源社区挖掘真正好用、能打的高价值项目，同时记录自己用 AI 搓工具、做产品、踩坑填坑全过程的独立开发者。如果今天这篇对你有启发，欢迎关注公众号小火龙AI 手记，我们下篇见。