OSpec 1.0.0，正在把 AI 自动开发从设计一路拉到交付
最近几天，这个发布页最容易让人误判的地方
最近几天，点开 OSpec 的发布页，第一眼看到的标题其实挺朴素，1.0.0 - Modular Plugin Installation。
乍一看，很容易把它当成一次安装方式整理。
说实话，这种误判太常见了！
但继续往下翻 1.0.0 版本标签对应的 README，再去看本地仓库里那个 refactor: optimize architecture 提交，就会发现文案当然变了，更关键的是产品边界真的掰开了。
为什么会有这种判断？
因为这次改动，根本没停在发布说明层面。
代码层也跟着一起换了，这就完全不一样了！
这次到底更新了什么
能确认的变化，其实可以压成几条很实在的东西。
核心架构重构了。
原来内建在核心里的 Stitch、Checkpoint 相关适配层被拆掉了，仓库里多了 plugins/registry.json 和 PluginRegistryService 这种更像插件系统底座的东西。
Stitch 和 Checkpoint 都有了单独的官方 npm 包，分别是 @clawplays/ospec-plugin-stitch 和 @clawplays/ospec-plugin-checkpoint。
安装语义也收得更清楚了。
换个项目就重装一遍，真的有必要吗？
在 AI 对话里说，帮我打开 Stitch 或 Checkpoint，它的理解不再是无脑重装一遍，而是先检查机器上有没有全局安装，已经装过就直接复用，然后只在当前项目里启用。
启用之后，插件自己的详细文档还会同步进项目里的 .ospec/plugins/<plugin>/docs/。
进一步看，Checkpoint 在启用时，还会把目标项目做运行检查需要的依赖一起补进去。
你会发现，这次更新不是多了一个命令。
它是在回答一个更像产品边界的问题，OSpec 自己到底该管到哪里，哪些能力应该交给插件去处理。
这件事为什么比看上去更大
最明显的一个变化，是 OSpec 到了 1.0.0 之后，终于更像一个协议壳了。
核心就守住变更工作流、验证、收口这些主骨架。
设计预览和运行验证这种更具体的能力，则交给插件去处理。
这看着像工程整理，实际影响挺直接。
不需要为了一个根本不碰页面的项目，把整套设计能力都背在身上。
也不需要为了一个只想做页面审核的项目，把所有东西都塞进同一个核心包里。
轻一点。
也清楚一点，这就是 1.0.0 最直接的观感。
说真的，一个工具做大以后，最怕的是功能一多，什么都想管，最后自己也说不清自己到底是什么。
OSpec 这次呈现出来的方向，反而是克制下来了。
说回 Stitch，它优化的不是一张图
这一段更适合直接看图。
如果只看名字，你很容易把 Stitch 理解成一个生成页面截图的工具。
但越往下看，越能发现它厉害的地方不只是能出图，而是能把设计推进这件事做得很连续。
先看三张图，这个判断就更容易成立。
第一张，是从一张很粗糙的手绘草图，直接长成一个可以继续讨论的网页版本。
这一步其实很关键。
因为很多团队以前卡住，往往不是缺想法。麻烦在于，脑子里有个大概轮廓，可要把它翻成一个能让所有人一起看的页面，中间总要消耗掉很多来回沟通。
Stitch 现在可以把这一步直接提前。
第二张更有意思。
它不会只给你一个固定版本。你看这张图，连同同一路径下的明暗主题都一起推出来了，左边是暗色，右边是亮色，结构和气质是连着的，但呈现又明显不同。
这就不是随便换个配色那么简单了。
它更像是在帮你把一个页面完整铺开。
第三张再进一步，连移动端页面都一起带出来了。
这也是很重要的地方。
因为你一旦开始认真做产品页面，桌面端和移动端通常根本不能拆开聊。桌面端长什么样，移动端怎么继承这个气质，很多时候本来就是同一轮设计判断。
而这张图能很直观地说明，Stitch 不会停在首页首屏，它还能把页面继续延展出去。
在 OSpec 的完整工作流里，这些图最有价值的地方，其实是让页面方向更早被看见，而不是拿来炫效果。
前面做登录页 Stitch 试点的时候，前后其实留过 5 个页面稿。
最后真正被认成当前有效版本的，只有 1 个。
其他几个，都被当成历史探索稿留着。
图很多，可当前到底认哪一版，你说得清吗？
这个动作看起来像整理文件，其实是在收设计版本。
它是在把设计讨论从群里看两眼，改成当前到底认哪一版、哪一版可以继续实现。
这也是为什么会说，Stitch 优化的不是单张图漂不漂亮。
它优化的是三件事。
先把页面方向看见。
再把当前版本定下来。
最后把这个判断和变更一起留下来。
这样后面不管是谁回来看，都不会再陷进那种截图一堆、版本一堆、每个人嘴里说的还是不同一版的状态。
这种收束感，对交付很重要。
因为页面型需求最怕的，往往是图已经很多了，大家却没有一个明确的当前版本。
如果准备认真用 Checkpoint，更适合直接在 Antigravity 里开发
这一段更值得看实操感，而不是只抄命令。
当前这套开发环境，本来就是 Antigravity IDE + Codex 插件。
本机 Stitch 这边走的是官方远程 MCP + API Key，也已经实测通过了 create_project 和 generate_screen_from_text 这些调用。
所以真正顺手的地方，不在于单独多了一个 Checkpoint 命令。
而是你写页面的时候，不用老在浏览器、文档、终端之间来回跳。
在 IDE 里可以直接连着 Stitch 的预览和截图看，先确认这一版是不是需要的，再接着跑 Checkpoint 去看关键流程有没有断。
既然同一个窗口里就能看到结果，还要再切出去核一遍吗？
比如这张图，就是在 Antigravity 的对话里直接把生成结果打出来。
你上面还是提示词和约束，往下就是实际生成的画面。这个体验和以前那种先去别的地方出图，再回来说结果，差别还是很大的。
再比如这张图，更能说明 Checkpoint 的价值。
页面改完以后，它不会只回你一句通过了。
它会回到同一个手机视口里复查布局，把任务列表、修改状态和当前页面一起摆在你面前。像 ospec.ai 官网这种首页布局，一旦牵涉到移动端 topbar、首屏换行、按钮顺序，其实特别需要这种边做边复查的节奏。
这套路径的价值，其实很直接。
为什么这套路径值得单独拿出来讲？
因为很多时候，问题不在会不会写，麻烦在设计稿一边、代码一边、验收又在另一边，切着切着，人就乱了……这种情况在实际开发里并不少见，窗口一多，反而更不确定现在看的到底是不是同一版。
当然，这里也得把边界说清楚。
能不能在 IDE 里顺滑看到图，还是取决于本地 Stitch MCP、认证和客户端接入有没有配好。
它不是装上就自动魔法生效。
但一旦这块跑顺，前面用 Stitch 看方向，后面用 Checkpoint 验流程，这条路径就真的很舒服。
OSpec 1.0.0 真正值得看的是什么
1.0.0 最值得注意的，不是版本号到了 1.0。
而是它终于用结构把方向说清楚了。
核心就做核心。
插件就做插件。
Stitch 把设计确认往前拉。
Checkpoint 把运行验证往后接。
中间那条变更工作流，才是 OSpec 真正想长期维护的主线。
这也是为什么这个版本出来之后，整个项目突然清楚了很多。
如果想自己去看原始资料，仓库在这里。
https://github.com/clawplays/ospec
官网在这里。
如果正在用 AI 做产品、做页面、做交付，这个版本更值得拿一个真实项目试一下。
你会更容易看清，OSpec 终于不是一堆功能堆在一起了，它开始像一条能走通的路径了。