从 0 到 1 可持续 Vibe Coding我做了一个 harness 工程的开发工作流 Skill大家好我是不会喷火的小火龙。过去大半年“Vibe Coding”成了技术圈讨论最多的词。几句自然语言 Prompt十分钟就能让 AI 搓出一个界面漂亮、能跑能点的原型。那种即时出成果的快感确实让人很难再适应纯手写代码的节奏。但如果试着用这套方式从零打磨一个跨多个业务模块、需要长期维护的真实项目大概率很快就会遇到现实瓶颈代码行数超过两三千行上下文窗口变大之后AI 开始自相矛盾甚至顺手把之前写好的核心逻辑当成废弃代码重构掉数据表结构全凭 AI 自由发挥字段缺少约束加个小功能发现表关联全是乱的修一个 Bug 反而引爆三个新 Bug屏幕上“暂时能跑”看着很美底层架构却脆弱前期省下的编码时间后期要加倍以排错和返工的形式还回去。很多开发者折腾到最后忍不住觉得“AI 只能写写玩具一碰复杂工程就抓瞎。”可持续的 Vibe Coding关键在于分工人负责规划、架构、约束与最终验收AI 则在明确的工程化护栏内负责高效执行。标准流程可以参考鱼皮哥的文章Vibe Coding 项目开发流程为了解决 AI 容易偏离预期的问题我结合自己的踩坑经验与工程实践最近多次迭代并开源了一个开发流 skillvibe-workflow。它把一套原本需要人肉反复提醒的开发纪律沉淀成了 AI 可以遵守的规则。如下图所示任由 AI 自由发挥与给它套上工程护栏相比在开发效率和系统稳定性上差异很大。这篇文章主要梳理从 0 到 1 推进一个 Vibe Coding 项目的具体心法并介绍vibe-workflow是如何在关键节点起到护栏作用的后面会在实践过程中持续更新迭代。一、规划比写代码重要别给 AI 一个模糊的大 Prompt很多 Vibe Coding 出现偏差往往在敲下第一句 Prompt 时就已经埋下了隐患。比如直接对 AI 说“帮我做一个类似 Notion 的记事本要有分类、标签和搜索。”这是一个典型的模糊大 Prompt。AI 收到之后会立刻开始写代码但在它的逻辑里缺少阶段和优先级。它可能会直接引入三个重型第三方编辑器库同时实现没有经过验证的复杂树形目录最后连基础的文本保存都会报错。模糊的指令很容易产生边界不清的复杂工程。在让 AI 动代码之前先把四件事明确下来很有必要核心用户路径用户进入产品后最核心的一条闭环操作到底是什么技术栈与架构选型为什么选这个框架状态怎么管理前后端如何通信不做清单Out-of-scope第一版明确不做什么比做什么更重要砍掉不必要的衍生需求只保留核心闭环可测试的验收标准怎样才算做完比如“创建后刷新页面不丢失”、“空输入提交有明确拦截提示”。在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.mdAGENTS.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的主流程中。如下表所示两种模式在核心维度上的差异很直观对比维度传统放养式 Vibe Codingvibe-workflow 护栏开发流需求把控模糊大 Prompt想到哪写到哪明确核心路径与不做清单架构设计视觉优先页面先行数据模型混乱数据优先严格先写迁移与模型约束会话切换换会话易失忆依赖聊天历史推断自动从 Git 与仓库事实恢复上下文编码推进动辄修改几十个文件难以排查最小纵向切片连续失败 3 次自动熔断验收标准只要屏幕暂时能跑就算完成完成声明必须携带测试与运行证据外部协作多套扩展互相抢占流程、反复提问统一主线管理按需调度专项能力最终结果容易形成代码坏味道后期重构成本高结构清晰、适合长期迭代的工程项目六、实操如何把这套工作流接入你的项目把这套开发流应用到日常开发中步骤相对直接。1. 安装扩展确保本地的开发环境如 Claude Code 或支持相关规范的 Agent 工具就绪后在终端执行以下命令npx skillsaddsz-xiaohuolong/vibe-workflow安装完成后该 Skill 就挂载到了 Agent 环境中。2. 接管与恢复项目的两条核心指令在实际使用中比较常用的指令有两条场景 A接管新项目或既有代码库刚克隆了一个项目或者准备把已有仓库纳入规范管理时在对话中输入$vibe-workflow init 审计当前仓库沿用已有文档和构建入口报告待澄清的事实。AI 会通读仓库梳理技术栈、目录规范与现有规则建立起清晰的开发基线。场景 B跨会话继续之前的进度开启新的聊天窗口时不需要复制之前冗长的聊天记录直接输入$vibe-workflow 从仓库事实恢复当前软件项目并核验下一个待执行的任务。AI 会检视 Git 状态、当前未完成的切片文档以及测试结果定位接下来需要处理的任务。3. 上手建议初次使用时建议选一个范围清晰、验收条件明确的小需求来跑一遍闭环观察它在动手前是否协助确认好了边界写代码时是否只修改约定的文件汇报结果时是否能够对应具体的测试用例。跑顺几次之后开发过程会更加可控。写在最后AI 编程改变了代码生产的节奏但软件工程本身的基本规律依然在起作用。现在的关键在于能不能拆解出清晰的领域模型、能不能制定出合理的工程护栏以及能不能有效驾驭 AI 工具推进项目。做好规划与边界约束让每一部分改动都走在可验证的轨道上才能真正发挥 AI 编程的长期复利。
从 0 到 1 可持续 Vibe Coding我做了一个 harness 工程的开发工作流 Skill大家好我是不会喷火的小火龙。过去大半年“Vibe Coding”成了技术圈讨论最多的词。几句自然语言 Prompt十分钟就能让 AI 搓出一个界面漂亮、能跑能点的原型。那种即时出成果的快感确实让人很难再适应纯手写代码的节奏。但如果试着用这套方式从零打磨一个跨多个业务模块、需要长期维护的真实项目大概率很快就会遇到现实瓶颈代码行数超过两三千行上下文窗口变大之后AI 开始自相矛盾甚至顺手把之前写好的核心逻辑当成废弃代码重构掉数据表结构全凭 AI 自由发挥字段缺少约束加个小功能发现表关联全是乱的修一个 Bug 反而引爆三个新 Bug屏幕上“暂时能跑”看着很美底层架构却脆弱前期省下的编码时间后期要加倍以排错和返工的形式还回去。很多开发者折腾到最后忍不住觉得“AI 只能写写玩具一碰复杂工程就抓瞎。”可持续的 Vibe Coding关键在于分工人负责规划、架构、约束与最终验收AI 则在明确的工程化护栏内负责高效执行。标准流程可以参考鱼皮哥的文章Vibe Coding 项目开发流程为了解决 AI 容易偏离预期的问题我结合自己的踩坑经验与工程实践最近多次迭代并开源了一个开发流 skillvibe-workflow。它把一套原本需要人肉反复提醒的开发纪律沉淀成了 AI 可以遵守的规则。如下图所示任由 AI 自由发挥与给它套上工程护栏相比在开发效率和系统稳定性上差异很大。这篇文章主要梳理从 0 到 1 推进一个 Vibe Coding 项目的具体心法并介绍vibe-workflow是如何在关键节点起到护栏作用的后面会在实践过程中持续更新迭代。一、规划比写代码重要别给 AI 一个模糊的大 Prompt很多 Vibe Coding 出现偏差往往在敲下第一句 Prompt 时就已经埋下了隐患。比如直接对 AI 说“帮我做一个类似 Notion 的记事本要有分类、标签和搜索。”这是一个典型的模糊大 Prompt。AI 收到之后会立刻开始写代码但在它的逻辑里缺少阶段和优先级。它可能会直接引入三个重型第三方编辑器库同时实现没有经过验证的复杂树形目录最后连基础的文本保存都会报错。模糊的指令很容易产生边界不清的复杂工程。在让 AI 动代码之前先把四件事明确下来很有必要核心用户路径用户进入产品后最核心的一条闭环操作到底是什么技术栈与架构选型为什么选这个框架状态怎么管理前后端如何通信不做清单Out-of-scope第一版明确不做什么比做什么更重要砍掉不必要的衍生需求只保留核心闭环可测试的验收标准怎样才算做完比如“创建后刷新页面不丢失”、“空输入提交有明确拦截提示”。在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.mdAGENTS.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的主流程中。如下表所示两种模式在核心维度上的差异很直观对比维度传统放养式 Vibe Codingvibe-workflow 护栏开发流需求把控模糊大 Prompt想到哪写到哪明确核心路径与不做清单架构设计视觉优先页面先行数据模型混乱数据优先严格先写迁移与模型约束会话切换换会话易失忆依赖聊天历史推断自动从 Git 与仓库事实恢复上下文编码推进动辄修改几十个文件难以排查最小纵向切片连续失败 3 次自动熔断验收标准只要屏幕暂时能跑就算完成完成声明必须携带测试与运行证据外部协作多套扩展互相抢占流程、反复提问统一主线管理按需调度专项能力最终结果容易形成代码坏味道后期重构成本高结构清晰、适合长期迭代的工程项目六、实操如何把这套工作流接入你的项目把这套开发流应用到日常开发中步骤相对直接。1. 安装扩展确保本地的开发环境如 Claude Code 或支持相关规范的 Agent 工具就绪后在终端执行以下命令npx skillsaddsz-xiaohuolong/vibe-workflow安装完成后该 Skill 就挂载到了 Agent 环境中。2. 接管与恢复项目的两条核心指令在实际使用中比较常用的指令有两条场景 A接管新项目或既有代码库刚克隆了一个项目或者准备把已有仓库纳入规范管理时在对话中输入$vibe-workflow init 审计当前仓库沿用已有文档和构建入口报告待澄清的事实。AI 会通读仓库梳理技术栈、目录规范与现有规则建立起清晰的开发基线。场景 B跨会话继续之前的进度开启新的聊天窗口时不需要复制之前冗长的聊天记录直接输入$vibe-workflow 从仓库事实恢复当前软件项目并核验下一个待执行的任务。AI 会检视 Git 状态、当前未完成的切片文档以及测试结果定位接下来需要处理的任务。3. 上手建议初次使用时建议选一个范围清晰、验收条件明确的小需求来跑一遍闭环观察它在动手前是否协助确认好了边界写代码时是否只修改约定的文件汇报结果时是否能够对应具体的测试用例。跑顺几次之后开发过程会更加可控。写在最后AI 编程改变了代码生产的节奏但软件工程本身的基本规律依然在起作用。现在的关键在于能不能拆解出清晰的领域模型、能不能制定出合理的工程护栏以及能不能有效驾驭 AI 工具推进项目。做好规划与边界约束让每一部分改动都走在可验证的轨道上才能真正发挥 AI 编程的长期复利。
