首页

不同产品的工作流

# 不同产品的工作流

Antigravity IDE 像个事必汇报的项目助理，Kiro 像个一丝不苟的合规审计员，OpenSpec 像个不爱说话但靠谱的助理，Superpowers 像个反复确认细节的较真同事，gstack 则是个闷头干活的纯执行工具人。

# Antigravity IDE

Antigravity IDE (opens new window) 的特色在于 Artifact 化的交付：你一句话描述需求，它直接生成 Implementation Plan、Task 清单、Walkthrough 这几个标签页，agent 跑完不是甩一堆 log 给你看，而是结构化的 "看得懂的产物"，你可以直接 Review 后点 Proceed，跟批注文档差不多体验。它还能调用浏览器子代理实际把功能跑起来测试、截图验证，不是停留在 "代码生成完就算完事"。代价是这套流程偏重 —— 文档和验证步骤多，单个任务跑完往往需要更长时间，长会话容易让上下文变臃肿；而且原生集成偏 Google 系（Cloud Run、Firebase、Workspace），跨云部署得自己敲终端命令，不算 "开箱即用"。

# Kiro

Kiro (opens new window) 的可视化做得很好，它的核心是 specs 驱动 —— 基于 "需求 → 设计 → 任务" 三段拆分思想，把每个阶段的产物（requirements.md / design.md / tasks.md）都摆在侧边栏，一目了然，比纯聊天框直观很多。更关键的是这个流程是互动式的：每个阶段走完都会停下来，让你审核、改了再往下走，不是一股脑生成到底，发现需求理解错了也能直接改 requirements.md 重新推导，不用推倒重来。代价是仪式感重 —— EARS 这种航空级需求记法本身有学习成本，没法跳过阶段直接说 "随便写写"，适合需要留痕、可审计的正经项目，不适合临时起意的小修小补。

# OpenSpec

OpenSpec (opens new window) 没有花哨界面，就是几个 Markdown 文件 + CLI 命令，不会主动找你聊天确认，也不强制阶段门 —— 你想跳步骤就跳，想事后补 design.md 也行。优点是轻、不啰嗦；缺点也是因为太松散，全靠你自己的纪律性去维持规格和代码同步，工具本身不会逼你做对的事。

# Superpowers

Superpowers (opens new window) 的 brainstorm 技能会不断追问细节、反复确认范围，TDD 技能会卡着不让你跳过写测试这步，code review 技能完成后还会主动找茬。这种 "步步紧逼" 是刻意为之 —— 作者的初衷就是不信任 "一句话甩需求然后等代码" 的 vibe coding 模式。好处是确实能逼出更扎实的工程纪律；坏处是如果你只是想快速试个东西，会觉得它很烦 —— 好在你可以直接对它说 "跳过规划" "这个不用写测试"，它会让步，不是死板的强制阶段门。

# gstack

gstack (opens new window) 是这五个里唯一不涉及 AI / 需求管理的，纯粹是 Git 分支操作的自动化。没有可视化界面、没有交互式追问，命令行敲完就完事。适合已经习惯 stacked PR 工作流、只是嫌手动 rebase 麻烦的人；如果你想要个带 UI 的堆栈管理工具，得看 Graphite 这类（gstack 本身没有这块）。

SDD 和 TDD

SDD 是 Spec-Driven Development（规格驱动开发），TDD 是 Test-Driven Development（测试驱动开发）。SDD 关心的是 "我们有没有在动手之前把要做的事说清楚、说成一份能被审计的文档"；TDD 关心的是 "我们写的每一行代码有没有被一个先写好的测试约束住"。

1. Kiro —— SDD 做得 "硬"

EARS 句式（When/If/Then 固定格式）把需求写死，规格能被机器化校验（property-based verification），三阶段（需求→设计→任务）层层审核才能往下走，跳不过去。优点是规格和代码强绑定、可审计；代价是仪式感重，不适合随手改改。

2. OpenSpec —— SDD 做得 "软"

用 GIVEN/WHEN/THEN 场景写规格，但没有强制阶段门，提案、规格、设计、任务想什么时候补都行，还有 delta specs 专门追踪 "这次改了什么"。优点是轻量、不卡流程；代价是全靠自觉，工具不会逼你写规格。

3. Superpowers —— 走的是 TDD，不是 SDD

不靠正式规格文档打头阵，而是测试先行：execute-plan 阶段强制先写测试，代码围着测试长出来，写完还会触发代码评审技能把关。优点是代码质量有测试兜底；代价是过程啰嗦，会不断追问细节、不让你跳步骤（除非你明确叫它跳过）。

# 搭建自己的工作流

# 控制电脑

# 开发工作流

# 自动化测试

  • chrome-dev-mcp ⼿动的点击允许

  • playwright + playwrightbrdidge ⾃动化测试

  • comet ⾃动化

  • @broswer-use + @computer-use ⾃动化测试

  • 程序单元测试 JEST，⾃动化测试 cypress

  • use broswer skils

# 谷歌 Agent Skill 设计模式

5 Agent Skill design patterns every ADK developer should know (opens new window) 可以用来指导你怎么写 skill 以及 md 文件。

# 如何精确还原设计稿

  1. stitch 导出 HTML + CSS 设计稿

  2. codex 选择 /goal + gpt-5.4

  3. 使用 BackstopJS 验证像素级还原效果

请根据我的 HTML + CSS 设计稿，使用 React 和 Tailwind CSS 还原设计稿的 UI 界面，注意几点:
1. 请注意 UI 组件的结构和层次，确保还原设计稿的布局和样式。
2. 使用 Tailwind CSS 的实用类来实现设计稿中的样式，确保样式的一致性和可维护性。
3. 在还原设计稿时，注意细节和交互效果，确保用户体验与设计稿一致。
4. 如果设计稿中有动态交互或动画效果，请使用 React 的状态管理和生命周期方法来实现这些功能。
5. 使用 BackstopJS 验证像素级还原效果。
1
2
3
4
5
6
上次更新时间: 2026年06月20日 00:29:57

CSS 布局