一个丑网页的逆袭OpenSpec 规范驱动开发全流程一个网页界面第一版做出来又丑又不顺手改到想推倒重来。有人换了条路用 OpenSpec 这套规范驱动开发框架先把要建的东西写清楚再让 AI 照着规格一步步施工。结果丑小鸭真的变成了小天鹅。这篇文章就是那次网页开发的完整实战复盘。我很早就想介绍一篇实战用 OpenSpec 做规范驱动开发的文章一直没找到合适的切入点直到看到作者 Sean Kochel 的这条视频让我眼前一亮。Sean 是一名持续拆解 AI 编程工具的作者。这条视频没停在功能介绍实打实地拿一个食谱应用界面从一处丑到不想用的第一版出发一路改造成接近设计稿的成品。整个过程用到的就是 OpenSpec 这一套规范驱动框架六条命令走完全程init、explore、propose、validate、apply、archive。下面顺着 Sean 的演示把每一步拆开看。一、先看清 OpenSpec 站在哪动手之前Sean 先把市面上的 AI 编程工具分成了三类。这个分类很实用新手能一眼看清 OpenSpec 的位置。第一类规格驱动。OpenSpec 就属于这一类同类的另有 GitHub Spec Kit。这类工具的核心是把 spec 当作驱动一切的产出物。使用者要花大量时间把「到底要建什么」对齐清楚之后的事情就顺理成章地往下走。这套逻辑的心智模型可以概括成八个字人负责编排agent 负责协助。Sean 的判断是刚接触 AI 编程的人走这条路更稳因为它逼着人把要建什么、它要做什么想清楚。第二类流程执行。比如 Agent Skills、Obra Superpowers、Compound Engineering。它们也有流程引导人走但真正的价值是把最佳实践和纪律植入编码过程。像 Obra 的 TDD 红绿重构是任何时候构建东西都该做的事而很多工具没有内置它。第三类自主流水线。比如 BMAD、GSD。这类工具给出一堆工具让人定义一件事之后可以走开回来时它已经建好几乎不用干预。二、真实的痛点第一版丑到不想用这条视频要解决的是一个很多开发者都踩过的坑。第一版做出来了回头看却觉得有点丑不像想要的样子。功夫没少花就是差口气。Sean 的解法分两步。他先打开 Claude Design花时间把东西搭出来做出一个专业得多、真正想用的参照稿。左边是食谱页现在的样子右边是它理想中的样子。接下来要做的是用一个规格驱动的开发工具把这个差距一步步弥合掉把所有页面都搭出来。这里还藏着一个 Sean 很看重的态度技能可以串联。用一个工具不等于不能用别的。他仍然会用 Obra 的 using-git-worktrees 技能建一个工作树跑完测试确认开工前的基线是干净的。三、先对齐再动手init 与 explore上手很轻。装上包进项目目录运行openspec init选个环境工具就就绪了。它还带一个 onboarding 技能。第一次用onboard命令会带着走完第一个功能很适合新手。Sean 为了演示每一步选择手动跑。他回到 Claude Design复制那里给出的命令让 Claude Code 去抓取设计稿。接着敲下第一个命令explore。explore 是 Sean 格外看重的一步。很多工具默认使用者已经知道自己要建什么直接跳进 spec。OpenSpec 给了一个可选的探索期动手前先跟模型把歧义谈清楚随时能在要改动的地方深入。读完全部上下文后它开始对要做的事做推理。这个例子里有几处歧义要回答。要彻底改 DESIGN.md 里记录的设计系统这份文件又被 AGENTS.md 引用两者都得更新。仓库结构也要动因为新设计稿的信息架构没法干净映射到现有结构。Sean 贴了一点额外上下文它就开始澄清计划的各个部分。这一步的价值是把推进前该留意的点提前标出来。太多人直接上手就建对话里浮现的假设模型在构建时当场拍板结果大概率不满意。explore 是不用太多仪式就能绕开这些坑的办法。四、三份文档把要改什么讲清楚探索充分之后下一步生成提案命令是opsx:propose。拿到手的是三份 Markdown一份 proposal、一份 system design另有任务清单。设计系统文件里第一块是主要架构决策。设计系统的 token 怎么迁移这些组件怎么在系统里重建因为它们和 Claude Design 里的不一样应用的路由和整体架构怎么变都写在这里。提案则更聚焦「这个项目里到底要改什么」。设计系统迁移、搭新页面、建新组件库、留意数据模型和 API 基于新界面要怎么变Sean 明确说现在先不做全部后端改动。它是一份非常清晰的 changelog写清这份 spec 到底要改什么。然后是分阶段、实际要执行的任务序列。三份文档分工明确提案回答「是什么、为什么」设计文档给出「怎么改」的高层任务文件给出实现步骤。这个约定很实用所有假设和决策都被清楚记录每步都有具体任务可依。最后拿到一个 specs 目录。书签迁移、发现页、关注的人、设计系统迁移每个主要工作块各有一份独立 spec写清到底需要哪些场景。五、多一道视觉校验validate 与 apply真正应用改动之前Sean 特别看中validate这一步。这个例子里他想让工具多做一轮检查用 Chrome 浏览器扩展 MCP 去验证自己的成果。这道工序不是流程里自带的。多数工具只在功能上描述一件事该怎么工作很少说它视觉上到底该长什么样。从另一个工具迁移设计系统时这恰恰是容易丢的地方。Sean 只是要求加一步必须验证。现在它做完新 spec会跑一遍 validate确保没丢 spec 里的关键细节。随后跑最后一个命令apply把项目目录或标识符传进去让它开工。一个小提示Sean 用 Chrome flag 启动了 Claude这样自检时能真正和浏览器交互。他认为这种前端视觉检查对 vibe coding 的成品质量提升明显。这一轮连续跑了约两个小时几乎没怎么干预。他仅有的干预是某个节点开了 auto mode让它别再停下来问问题。算上那些停顿实际花了三四个小时开了 auto mode 后纯处理时间是两小时八分钟。六、跑完看看结果有几处 Sean 特别想检查。第一处是发现页。设计非常清晰侧栏、hero 区的「Whats Cooking Now?」、筛选搜索选项再往下是编辑式的内容排布。进到屏幕里看非常接近。他在一个很大的屏幕上侧栏和中间栏的间距有点乱但顶部区域、人名、菜名、trending forks、editorial pick这些都很到位。另一处是用户主页。点进 Ren 的页面之前非常朴素几乎空白。现在接近设计稿了但有几处不对该有强调色的地方、某些按钮的对齐、按钮应该大致同尺寸且有一个强调。对于这么大范围的设计系统重构它已经非常接近。食谱页更是巨大的升级。规格驱动这一面正是它能做得这么有效的原因。有清晰的功能需求、清晰的验证步骤也知道该去核对参照设计稿。七、archive 归档让文档不脱节一个出人意料有用的点是它怎么收尾一个功能分支。跑archive命令本质是把这套变更积累的 spec 和上下文同步回应用根部的真值源。很多人抱怨应用文档越维护越难这就是 OpenSpec 帮人维护的方式。去看 OpenSpec 文件夹所有工作都在 changes 文件夹里。每个净新增功能书签视图、发现页、关注页、设计系统更新都拿到自己的 spec 文件。价值在于未来改动时手里有一份持久的真值源描述这东西该怎么工作。往后改了书签功能再去归档如果破坏了这份 spec 的关键部分它会揪出问题逼人跟它对账。这样就不会冒出黑天鹅不会出现那些藏在项目里、被改坏了却没人察觉的东西。它逼着为每个主要功能维护一套活着的规格说明。全部完成后拿到一个 archive 文件夹任务、提案、怎么保证视觉保真全被存下来随时能回头查。八、进阶工作流与 sync基础流程之外另有三套工作流。第一套其实是两个一起用new和continue。让这个工具出众的一个范式是它对规划采取迭代式。有想法开始规划过程中冒出信息想把它重新融回计划里new 和 continue 就是解法。发起 new 命令。前端改完了接下来补后端让 API 路由就位、数据模型就位。openspec continue走一遍和之前类似的过程有问题就把回答写在这里。当时有两个选项一个包含所有东西的大改动或者把这些改动切成更聚焦的小改动逐个处理每个都有自己的 proposal、specs、tasks。因为涉及后端逻辑Sean 选择切片更慢但可能做得更好。随后对每个切片再跑 new逐个走完建提案、应用改动、归档的完整过程。continue 命令起草提案逐步生成 specs。中途冒出什么问题可以跑 explore 把问题谈清楚再把改动融进当前所处的阶段。这个库很擅长生成上下文、智能地存储随后让人轻松进入下一阶段。如果某个时刻觉得计划已经够好只想让它自动跑完剩余阶段可以跑fast-forward。它快得多但仍不脱轨依然遵循系统、执行最佳实践、有 spec 在案、照着 spec 开发。这就引出最后一个功能sync命令。它持续记录应用所有功能的实际状态让文档不会失控、迅速过时。回到 master specs 文件夹向下滚动到 public profile能看到它已经基于这次工作更新。需求、数据库该长什么样全都基于刚做的这次改动。任何改动碰到已存在的东西都有一个内置步骤回写更新文档让内容不至于丢失、不至于与现实脱节。这是很多其他工具原生没有的增值。小结这个库相当出色。对日常主力工作流来说在需要时把 Obra 之类的插件调进来比如做子 agent 执行或 TDDOpenSpec 是一个新的日常主力尤其适合已经成型的项目。决定成品差距的是动手前把话说得多清楚。如果正在维护一个已经成型的项目又常被 AI 答非所问折磨值得照着做一遍。先把 Claude Design 里的参照稿准备好跑一遍 init、explore、propose、validate、apply、archive感受先对齐再动手和直接开写的差别。这套流程值得收藏动手前翻出来对一遍。#OpenSpec #AI编程 #VibeCoding #ClaudeCode #规范驱动开发 #开发者工具 #AI编程工具 #软件开发 #人工智能 #AI智能体参考OpenSpec GitHub 仓库原视频是 OpenSpec Will Change How You Vibe Code Forever作者 Sean Kochel 发布
一个丑网页的逆袭，OpenSpec 规范驱动开发全流程
一个丑网页的逆袭OpenSpec 规范驱动开发全流程一个网页界面第一版做出来又丑又不顺手改到想推倒重来。有人换了条路用 OpenSpec 这套规范驱动开发框架先把要建的东西写清楚再让 AI 照着规格一步步施工。结果丑小鸭真的变成了小天鹅。这篇文章就是那次网页开发的完整实战复盘。我很早就想介绍一篇实战用 OpenSpec 做规范驱动开发的文章一直没找到合适的切入点直到看到作者 Sean Kochel 的这条视频让我眼前一亮。Sean 是一名持续拆解 AI 编程工具的作者。这条视频没停在功能介绍实打实地拿一个食谱应用界面从一处丑到不想用的第一版出发一路改造成接近设计稿的成品。整个过程用到的就是 OpenSpec 这一套规范驱动框架六条命令走完全程init、explore、propose、validate、apply、archive。下面顺着 Sean 的演示把每一步拆开看。一、先看清 OpenSpec 站在哪动手之前Sean 先把市面上的 AI 编程工具分成了三类。这个分类很实用新手能一眼看清 OpenSpec 的位置。第一类规格驱动。OpenSpec 就属于这一类同类的另有 GitHub Spec Kit。这类工具的核心是把 spec 当作驱动一切的产出物。使用者要花大量时间把「到底要建什么」对齐清楚之后的事情就顺理成章地往下走。这套逻辑的心智模型可以概括成八个字人负责编排agent 负责协助。Sean 的判断是刚接触 AI 编程的人走这条路更稳因为它逼着人把要建什么、它要做什么想清楚。第二类流程执行。比如 Agent Skills、Obra Superpowers、Compound Engineering。它们也有流程引导人走但真正的价值是把最佳实践和纪律植入编码过程。像 Obra 的 TDD 红绿重构是任何时候构建东西都该做的事而很多工具没有内置它。第三类自主流水线。比如 BMAD、GSD。这类工具给出一堆工具让人定义一件事之后可以走开回来时它已经建好几乎不用干预。二、真实的痛点第一版丑到不想用这条视频要解决的是一个很多开发者都踩过的坑。第一版做出来了回头看却觉得有点丑不像想要的样子。功夫没少花就是差口气。Sean 的解法分两步。他先打开 Claude Design花时间把东西搭出来做出一个专业得多、真正想用的参照稿。左边是食谱页现在的样子右边是它理想中的样子。接下来要做的是用一个规格驱动的开发工具把这个差距一步步弥合掉把所有页面都搭出来。这里还藏着一个 Sean 很看重的态度技能可以串联。用一个工具不等于不能用别的。他仍然会用 Obra 的 using-git-worktrees 技能建一个工作树跑完测试确认开工前的基线是干净的。三、先对齐再动手init 与 explore上手很轻。装上包进项目目录运行openspec init选个环境工具就就绪了。它还带一个 onboarding 技能。第一次用onboard命令会带着走完第一个功能很适合新手。Sean 为了演示每一步选择手动跑。他回到 Claude Design复制那里给出的命令让 Claude Code 去抓取设计稿。接着敲下第一个命令explore。explore 是 Sean 格外看重的一步。很多工具默认使用者已经知道自己要建什么直接跳进 spec。OpenSpec 给了一个可选的探索期动手前先跟模型把歧义谈清楚随时能在要改动的地方深入。读完全部上下文后它开始对要做的事做推理。这个例子里有几处歧义要回答。要彻底改 DESIGN.md 里记录的设计系统这份文件又被 AGENTS.md 引用两者都得更新。仓库结构也要动因为新设计稿的信息架构没法干净映射到现有结构。Sean 贴了一点额外上下文它就开始澄清计划的各个部分。这一步的价值是把推进前该留意的点提前标出来。太多人直接上手就建对话里浮现的假设模型在构建时当场拍板结果大概率不满意。explore 是不用太多仪式就能绕开这些坑的办法。四、三份文档把要改什么讲清楚探索充分之后下一步生成提案命令是opsx:propose。拿到手的是三份 Markdown一份 proposal、一份 system design另有任务清单。设计系统文件里第一块是主要架构决策。设计系统的 token 怎么迁移这些组件怎么在系统里重建因为它们和 Claude Design 里的不一样应用的路由和整体架构怎么变都写在这里。提案则更聚焦「这个项目里到底要改什么」。设计系统迁移、搭新页面、建新组件库、留意数据模型和 API 基于新界面要怎么变Sean 明确说现在先不做全部后端改动。它是一份非常清晰的 changelog写清这份 spec 到底要改什么。然后是分阶段、实际要执行的任务序列。三份文档分工明确提案回答「是什么、为什么」设计文档给出「怎么改」的高层任务文件给出实现步骤。这个约定很实用所有假设和决策都被清楚记录每步都有具体任务可依。最后拿到一个 specs 目录。书签迁移、发现页、关注的人、设计系统迁移每个主要工作块各有一份独立 spec写清到底需要哪些场景。五、多一道视觉校验validate 与 apply真正应用改动之前Sean 特别看中validate这一步。这个例子里他想让工具多做一轮检查用 Chrome 浏览器扩展 MCP 去验证自己的成果。这道工序不是流程里自带的。多数工具只在功能上描述一件事该怎么工作很少说它视觉上到底该长什么样。从另一个工具迁移设计系统时这恰恰是容易丢的地方。Sean 只是要求加一步必须验证。现在它做完新 spec会跑一遍 validate确保没丢 spec 里的关键细节。随后跑最后一个命令apply把项目目录或标识符传进去让它开工。一个小提示Sean 用 Chrome flag 启动了 Claude这样自检时能真正和浏览器交互。他认为这种前端视觉检查对 vibe coding 的成品质量提升明显。这一轮连续跑了约两个小时几乎没怎么干预。他仅有的干预是某个节点开了 auto mode让它别再停下来问问题。算上那些停顿实际花了三四个小时开了 auto mode 后纯处理时间是两小时八分钟。六、跑完看看结果有几处 Sean 特别想检查。第一处是发现页。设计非常清晰侧栏、hero 区的「Whats Cooking Now?」、筛选搜索选项再往下是编辑式的内容排布。进到屏幕里看非常接近。他在一个很大的屏幕上侧栏和中间栏的间距有点乱但顶部区域、人名、菜名、trending forks、editorial pick这些都很到位。另一处是用户主页。点进 Ren 的页面之前非常朴素几乎空白。现在接近设计稿了但有几处不对该有强调色的地方、某些按钮的对齐、按钮应该大致同尺寸且有一个强调。对于这么大范围的设计系统重构它已经非常接近。食谱页更是巨大的升级。规格驱动这一面正是它能做得这么有效的原因。有清晰的功能需求、清晰的验证步骤也知道该去核对参照设计稿。七、archive 归档让文档不脱节一个出人意料有用的点是它怎么收尾一个功能分支。跑archive命令本质是把这套变更积累的 spec 和上下文同步回应用根部的真值源。很多人抱怨应用文档越维护越难这就是 OpenSpec 帮人维护的方式。去看 OpenSpec 文件夹所有工作都在 changes 文件夹里。每个净新增功能书签视图、发现页、关注页、设计系统更新都拿到自己的 spec 文件。价值在于未来改动时手里有一份持久的真值源描述这东西该怎么工作。往后改了书签功能再去归档如果破坏了这份 spec 的关键部分它会揪出问题逼人跟它对账。这样就不会冒出黑天鹅不会出现那些藏在项目里、被改坏了却没人察觉的东西。它逼着为每个主要功能维护一套活着的规格说明。全部完成后拿到一个 archive 文件夹任务、提案、怎么保证视觉保真全被存下来随时能回头查。八、进阶工作流与 sync基础流程之外另有三套工作流。第一套其实是两个一起用new和continue。让这个工具出众的一个范式是它对规划采取迭代式。有想法开始规划过程中冒出信息想把它重新融回计划里new 和 continue 就是解法。发起 new 命令。前端改完了接下来补后端让 API 路由就位、数据模型就位。openspec continue走一遍和之前类似的过程有问题就把回答写在这里。当时有两个选项一个包含所有东西的大改动或者把这些改动切成更聚焦的小改动逐个处理每个都有自己的 proposal、specs、tasks。因为涉及后端逻辑Sean 选择切片更慢但可能做得更好。随后对每个切片再跑 new逐个走完建提案、应用改动、归档的完整过程。continue 命令起草提案逐步生成 specs。中途冒出什么问题可以跑 explore 把问题谈清楚再把改动融进当前所处的阶段。这个库很擅长生成上下文、智能地存储随后让人轻松进入下一阶段。如果某个时刻觉得计划已经够好只想让它自动跑完剩余阶段可以跑fast-forward。它快得多但仍不脱轨依然遵循系统、执行最佳实践、有 spec 在案、照着 spec 开发。这就引出最后一个功能sync命令。它持续记录应用所有功能的实际状态让文档不会失控、迅速过时。回到 master specs 文件夹向下滚动到 public profile能看到它已经基于这次工作更新。需求、数据库该长什么样全都基于刚做的这次改动。任何改动碰到已存在的东西都有一个内置步骤回写更新文档让内容不至于丢失、不至于与现实脱节。这是很多其他工具原生没有的增值。小结这个库相当出色。对日常主力工作流来说在需要时把 Obra 之类的插件调进来比如做子 agent 执行或 TDDOpenSpec 是一个新的日常主力尤其适合已经成型的项目。决定成品差距的是动手前把话说得多清楚。如果正在维护一个已经成型的项目又常被 AI 答非所问折磨值得照着做一遍。先把 Claude Design 里的参照稿准备好跑一遍 init、explore、propose、validate、apply、archive感受先对齐再动手和直接开写的差别。这套流程值得收藏动手前翻出来对一遍。#OpenSpec #AI编程 #VibeCoding #ClaudeCode #规范驱动开发 #开发者工具 #AI编程工具 #软件开发 #人工智能 #AI智能体参考OpenSpec GitHub 仓库原视频是 OpenSpec Will Change How You Vibe Code Forever作者 Sean Kochel 发布