企业官网建设流程全解析

• AI 技能
• AI 插件

Antigravity Workflows 是 AAS（Agentic Awesome Skills）仓库中用于工作流级编排的专用技能：它把"多技能串联完成一个复杂目标"这件事固化为带校验检查点的引导式执行路径。本文以 implementation-playbook.md 为骨架，结合 SKILL.md、workflow-cards.md、docs/users/workflows.md 与 data/workflows.json，系统讲解 Agent 应如何确认目标、选择工作流、按步骤执行、产出工件、完成校验并安全收尾。读完本文，你将掌握在 AAS 生态中执行"交付 SaaS MVP、Web 应用安全审计、构建 AI Agent、浏览器 QA、DDD 核心域建模"五大工作流的完整实战方法。

工作流的定位：执行剧本而非工具箱

在 AAS 中，"工作流"与"技能包（bundle）"是两个互补的概念，docs/users/workflows.md 用一句话做了精炼区分：

• Bundles（技能包）告诉你哪些技能与某个角色相关——它们是工具箱；
• Workflows（工作流）告诉你如何按顺序使用这些技能去完成一个真实目标——它们是执行剧本。

换句话说，工作流不是一组技能的简单罗列，而是一条引导式、逐步推进、每一步都有明确产出与校验标准的执行路径。这正是 Antigravity Workflows 技能的核心价值：把"复杂目标"拆解为一系列可验证的技能调用序列。

从 SKILL.md 的元信息看，该技能声明的适用场景非常具体："当用户要求交付 SaaS MVP、审计应用安全、构建 AI Agent、运行浏览器 QA 或设计领域模型，且需要多技能协同与校验检查点时使用"，其risk: none、source: self，添加日期为 2026-02-27。

何时该启动该技能

根据 SKILL.md 的"When to Use This Skill"章节，以下场景应主动启用本技能：

• 用户希望组合多个技能完成目标，而不想逐个手动挑选；
• 目标是多阶段的（例如：计划 → 构建 → 测试 → 发布）；
• 用户要求对常见场景执行最佳实践，例如：交付 SaaS MVP、运行 Web 安全审计、构建 AI Agent 系统、实现浏览器自动化与 E2E QA。

执行契约：每个工作流都必须遵守的五步

implementation-playbook.md 的第一节定义了所有工作流通用的执行契约（Execution Contract），这是整个技能的行为基石，共五步：

1. 确认目标与范围（Confirm objective and scope）：明确用户要达成的具体结果，以及本次执行涉及/不涉及的范围边界；
2. 选择最匹配的工作流（Select the best-matching workflow）：从内置工作流中挑选 1～2 个候选，并基于目标做裁决；
3. 按顺序执行工作流步骤（Execute workflow steps in order）：严格遵守工作流定义的步骤序列，不跳步、不擅自增步；
4. 每步产出一个具体工件（Produce one concrete artifact per step）：每一步都留下可检查、可追溯的产物，杜绝"只有对话没有产出"的空转；
5. 继续前先校验（Validate before continuing）：当前步骤的完成标准通过后才允许进入下一步。

其中第 4、5 步是这套契约的关键约束。它把"执行进度"从不可见的主观判断，转化为可见、可审计的工件与校验证据。

步骤工件的具体形态

原文档给出了四个典型阶段对应的工件示例，这是判断"一个步骤是否真正完成"的客观锚点：

这套"阶段 → 工件"映射与 data/workflows.json 中机器可读的步骤元数据一一对应：每个步骤都带有title、goal、recommendedSkills与notes字段，其中goal即该步骤应达成的可观察结果，notes则是执行时的经验性提示。

默认路由：如何把请求映射到正确的工作流

Antigravity Workflows 内置了默认路由（Default Workflow Routing），见 SKILL.md，让 Agent 在收到请求时能快速映射：

这五个工作流 ID 在 data/workflows.json 中有完整的机器可读定义（generatedAt为 2026-02-10，version为 1），供工具与自动化流程消费。

运行工作流的一般流程

SKILL.md 的"How to Run This Skill"给出了 Agent 侧的执行流程：

1. 识别用户要达成的具体结果（concrete outcome）；
2. 提出1～2 个最匹配的工作流候选；
3. 若用户已指定工作流则直接遵循，仅在选项会实质性改变范围时才提问；
4. 逐步执行，每个步骤：
   • 宣布当前步骤与预期工件（announce current step and expected artifact）；
   • 调用该步骤推荐技能；
   • 在进入下一步前验证完成标准；
   • 若校验失败：保留失败记录，修复相关输入或实现，重跑该校验，通过后才继续；若前置条件不可用，则明确报告被阻断的步骤，并继续执行不受影响的独立工作；
   • 安装技能前，先审查确切的技能 ID 与其支持文件，使用受支持安装器的--dry-run预览，且仅在用户授权范围内安装；
5. 结束时交付：完成的工件、校验证据、剩余风险与下一步行动。

其中"失败的预览绝不授权安装（A failed preview never authorizes installation）"是安装环节的硬性门槛，这一点在 workflow-cards.md 的 reviewed-selection handoff 中会被再次强调。

五大内置工作流的完整分解

以下五个工作流在 docs/users/workflows.md 中有面向人类的完整 playbook，同时在 data/workflows.json 中有结构化元数据。两者互为补充：前者读起来直观，后者可供程序化消费。

1. Ship a SaaS MVP：交付最小可用产品

前置条件：本地仓库与运行时已配置；用户问题与 MVP 范围清晰；已选定基本部署目标。

提示词示例：Use @concise-planning to define milestones and acceptance criteria for my SaaS MVP.

workflows.json为该工作流的各步骤补充了实操注记：计划步骤应在编码前定义问题、用户画像、MVP 边界与验收标准；后端步骤"优先采用小而垂直的切片（vertical slices），保持 API 契约显式且可测试"；测试步骤在 Go 技术栈下使用go-playwright；发布步骤需定义发布检查清单、最小遥测与回滚触发条件。

2. Security Audit for a Web App：安全审计

前置条件：测试已获得显式授权；范围内目标已记录；日志与环境信息可用。

提示词示例：Use @threat-modeling-expert to map critical assets and trust boundaries for my web app.

workflows.json补充强调：范围步骤应记录范围内的目标、假设与范围外约束；发现应按严重度与可利用性映射，而非只看 CVSS 分数；修复应跟踪责任人与目标日期，并用证据验证每个修复。安全类工作流的授权边界要求同样体现在实施手册的 Safety Guardrails 中（见下文）。

3. Build an AI Agent System：构建 AI Agent 系统

前置条件：窄化的用例与可量化结果；模型提供商与可观测性工具可用；有初始数据集或知识语料。

提示词示例：Use @agent-evaluation to define benchmarks and success criteria for my agent.

机器可读元数据进一步提示：检索质量必须可度量，并对手册化 prompt/工具契约做版本管理；编排实现"从受限的工具权限与显式回退行为开始"；迭代循环应使用测试数据集与失败分桶来引导。

4. QA and Browser Automation：QA 与浏览器自动化

前置条件：测试环境与稳定凭据；已识别关键用户旅程；CI 管道可用。

提示词示例：Use @go-playwright to implement browser automation in a Go project.

workflows.json的注记要求测试策略"聚焦业务关键流程并保持 setup 确定性"，对失败的分类维度包括：选择器漂移、时序、环境、数据。这正是实施手册中"Test step -> test results and failure triage"工件的具体落地。

5. Design a DDD Core Domain：设计 DDD 核心域

前置条件：至少可访问一位领域专家或产品负责人代理；当前系统上下文与集成全景可用；业务目标与关键领域成果已达成共识。

提示词示例：Use @domain-driven-design to evaluate if full DDD is justified for our billing and fulfillment platform.

workflows.json的关键注记极具工程价值：战术建模"从不变量与事务边界出发，而不是从表或端点出发"；事件化模式"仅在一致性、扩展性权衡被显式声明并接受时使用"。这与工作流卡片中"不要仅为了套用 DDD 术语而引入服务或抽象"的约束一脉相承。

安全护栏：执行中的三条红线

implementation-playbook.md 明确列出三条安全护栏（Safety Guardrails），任何工作流执行都不得越界：

1. 未经用户明确批准，绝不执行破坏性操作（Never run destructive actions without explicit user approval）；
2. 若所需技能缺失，应明确陈述缺口，并回退到最接近的可用技能（state the gap and fallback to closest available skill）；
3. 涉及安全测试时，确保授权是显式的（ensure authorization is explicit）。

这三条护栏在仓库多处被强化：安全审计工作流的前置条件即要求"测试已获得显式授权、范围内目标已记录"；workflow-cards.md 中安全审计卡片更进一步——"仅检查已存在的认证实现，不发明端点，也不在授权范围外运行漏洞利用命令；不得用扫描结果推断安全认证"。

技能缺失时的降级策略：Standalone Workflow Cards

当完整 AAS 仓库的 playbook 不可用（例如独立安装场景）时，SKILL.md 指出应按以下顺序读取工作流来源：

1. docs/users/workflows.md：人类可读的 playbook 与已记录案例；
2. data/workflows.json：机器可读的工作流元数据。

这两条路径属于 AAS 仓库而非用户项目；当独立安装中缺少它们时，应使用随附的 workflow-cards.md（standalone cards）。这些卡片明确声明："每个技能 ID 只是待审查的候选，而非强制栈或基于元数据的背书"；应保留用户已选定的工作流，并使用项目现有的命令与约定。工作流卡片中记录的不是已完成案例的结果，而是程序卡片（procedure cards）——实际输出与局限必须与预期的退出条件分开呈现。

Reviewed-selection handoff：受审查的技能选择与预览安装

工作流卡片中专门给出了**"受审查选择交接（Reviewed-selection handoff）"**流程，用于把审查后的技能选择落到具体安装命令。以 Codex 项目中实际选中brainstorming与systematic-debugging为例：

npm exec --yes --ignore-scripts --package=agentic-awesome-skills@16.7.0 -- \ agentic-awesome-skills --release 16.7.0 --path .agents/skills \ --skills brainstorming,systematic-debugging --dry-run

执行该命令时，应将示例 ID 替换为审查后的技能集合，并确认该确切 release 确实包含这些技能、检查其前置条件。若预览报错，修正原因后重跑预览；只有预览成功且处于既有用户授权范围内时，才去掉--dry-run重跑相同命令完成安装；随后校验生成的技能文件，并在真实任务上调用所选技能。docs/users/workflows.md 也给出了 Codex 方向的等价预览示例：npx agentic-awesome-skills --codex --skills concise-planning,verification-before-completion --dry-run。

注意：直接安装器（direct installer）负责该预览流程，它不会应用 Core 计划（a Core plan remains a review artifact）——即计划产物只是审查材料，实际安装动作始终由安装器预览后、在授权内执行。

完成格式：收尾时必须返回的五要素

implementation-playbook.md 的最后一节规定了工作流完成时的建议完成格式（Suggested Completion Format），Agent 应向用户返回：

1. 已完成的步骤（Completed steps）；
2. 产出的工件（Artifacts produced）；
3. 校验证据（Validation evidence）；
4. 开放风险（Open risks）；
5. 建议的下一步行动（Suggested next action）。

这与 SKILL.md 中"结束时提供完成的工件、校验证据、剩余风险与下一步行动"完全对齐。该格式保证了每次工作流执行都能产出一份可审计的交接报告，把"做完了"变成"做完了什么、凭据是什么、还剩什么、接着干什么"。

局限性与相关技能

根据 SKILL.md 的 Limitations 章节，使用本技能时须明确其边界：

• 该技能负责编排，并不替代各专业技能的深度能力；
• 它依赖本地可用技能的存在；
• 没有环境访问权限、凭据或所需基础设施时，它不保证成功；
• 对于 Go 技术栈的浏览器自动化，go-playwright可能需要对应的技能存在于本地技能仓库中。

工作流编排与以下技能形成互补生态，可在执行中被调用或继续深入：concise-planning（skills/concise-planning/）、brainstorming（skills/brainstorming/）、workflow-automation（skills/workflow-automation/）、verification-before-completion（skills/verification-before-completion/）。其中verification-before-completion贯穿多个工作流的校验步骤，是"先验证再继续"契约在技能层面的直接支撑。

总结

Antigravity Workflows 把多技能协作从"凭感觉临场发挥"提升为"契约驱动的有序执行"：以五步执行契约为骨架，以"每步一工件、先验证再前进"为纪律，以安全护栏为底线，以默认路由与五大内置工作流为落地模板，以 standalone workflow cards 与--dry-run预览安装为独立安装场景的降级与安全机制。无论你是交付 SaaS MVP、执行安全审计、构建 AI Agent、稳定浏览器 QA，还是设计 DDD 核心域，都可以遵循 implementation-playbook.md 的契约，配合 docs/users/workflows.md 的完整 playbook 与 data/workflows.json 的机器可读元数据，让每一次多阶段目标执行都可预期、可校验、可审计。

• AI 技能
• AI 插件