大多数人用 AI 编程助手，停留在"打开编辑器，开始对话"。但如果你花过几个月认真用下来，一定会遇到同一个问题：它永远不记得上次的教训。每次新会话，都像带了个失忆的实习生。
本文给你一套经过长期实战验证的方法------用 Antigravity 的三层机制 Rule、Workflow、Skill，把工作区从"能用"升级到"能打"。
三层铠甲：Rule、Workflow、Skill
Antigravity 提供了三个可自定义的机制层级。它们加载时机不同、职责不同、维护成本也不同。理解这三层的本质差异，是把工作区武装起来的前提。顺带一提，这套机制的设计理念在 Claude Code、Codex 等工具中也通用------在 Antigravity 里配好的规则和技能，其他工具也能读取。
| # | 层级 | 本质 | 加载时机 |
|---|---|---|---|
| 1 | Rule | 每次会话都加载的底层认知 | 会话启动时自动读入 |
| 2 | Workflow | 用到时才加载的标准流程 | /slash-command 触发 |
| 3 | Skill | 可复用的"能力封装" | 意图匹配时自动加载 |
核心思维是：离 Agent 心智距离越近的层，放越通用的东西。Rule 是 Agent 的"默认人格"，Workflow 是它的"作业手册"，Skill 是它的"工具箱"。三者组合起来，就是一个完整的武装体系。
"不要试图教会 Agent 所有事，而是设计一个系统------让它在需要的时候，自己去学。"
第一层：Rule------给 Agent 装上"骨架"
Rule 层的内容每次会话启动时都会被读入上下文。这意味着它是成本最高、但影响最大的一层。在这里放什么，直接决定了 Agent 的"初始智商"。
我在这一层通常会维护以下几类内容：
1. Soul 和 Domain------自进化的双脑系统
soul.md 记录跨项目通用的技术原则和设计哲学；domain.md 记录当前项目的架构真相和领域知识。这两个文件放在项目的 .agent/rules/ 目录下。通过设置全局提示词，Claude Code 和 Codex 也可以读取和更新这个目录的内容。
关键设计：这套自进化机制是通过全局提示词驱动的------我在全局 Rule 中写了一段指令，要求 Agent 在每次会话结束时评估是否需要更新这两个文件。不管你用 Antigravity、Claude Code 还是 Codex，只要加载了同一份全局提示词，它们就会自动维护 soul 和 domain。新发现的架构决策写入 domain，被验证的通用原则提升到 soul。这不是"日记"，是一个持续压缩、持续淘汰的知识蒸馏过程。
💡 为什么不用一个文件？ 因为"跨项目通用"和"项目专属"有本质区别。把它们混在一起，long-term 一定会出现项目 A 的经验污染项目 B 的判断。Soul 装的是"世界观"，Domain 装的是"地图"，二者必须分离。
2. 知识索引------用"指针"代替"全文"
Rule 层的 Token 预算有限。把参考文档、API reference、第三方教程全文塞进去，是一种极其浪费的做法。
我的做法是：维护一个知识索引文件，只存 URL、本地路径和一句话摘要。当 Agent 在工作中需要某个知识点时，引导它去渐进式加载详细内容。这就像给 Agent 装了一个"参考文献目录"------它知道知识在哪里，但不需要一开始就全部背下来。
yaml
# .agent/rules/knowledge-index.yml 示例
references:
- name: "Tauri v2 Migration Guide"
path: "docs/tauri-v2-migration.md"
summary: "v1 → v2 的 Breaking Changes 和迁移步骤"
- name: "OpenCode SDK API"
url: "https://github.com/opencode/sdk/docs/api.md"
summary: "Agent Runner 的核心接口：createSession / prompt / cleanup"
- name: "部署流程"
path: ".agent/workflows/deploy.md"
summary: "编译 → 上传 → 重启服务的标准流"这种索引机制的好处是显而易见的------Agent 在需要事实的时候，倾向于使用文档化的真相，而不是凭自己幻觉编造。
3. 运维资产注册------让 Agent 知道"家里有几台服务器"
如果你有云服务器，直接在 Rule 层维护一份机器清单：名字、端点、用途。SSH 认证通过密钥完成，文件里不存任何密码。这样一来，你在对话中只需要说"连接到 prod-01 检查日志"，Agent 就知道该去哪里。
💡 Rule 层的核心原则：只放"每次会话都大概率会用到"的东西。对于复杂的知识体，用索引 + 渐进加载。保持这一层精简且高价值，就像一个人的长期记忆------不该什么都记，但该记的一定要准。
第二层：Workflow------固化"正确的做事方式"
Workflow 和 Rule 最大的区别是：它只在被触发时才加载 。你通过 /slash-command 调用，Agent 才会读取对应的 Markdown 文件。这意味着它不会占用每次会话的"初始上下文预算"。
我通常会在 Workflow 里放两类东西：
1. 思维框架和规划流程
我经常用语音转文字把想法快速倒出来，内容通常是碎片化的。这时候引用一个规划 Workflow，Agent 就能用一个结构化的框架去整理这些碎片------先分析意图、再设计方案、最后拆解任务。
这解决了一个实际痛点：当你的输入不够清晰时，Agent 对意图的识别能力会急剧下降。Workflow 相当于给它配了一副"阅读理解眼镜"------即使你说得很散，它也能按照预设的框架去提取关键信息。
2. 项目特定的操作流
比如"同步编译部署到测试环境"这样的流程，涉及多个步骤、多个工具的组合使用。把这些整理成 Workflow，本质上是创建了一个面向 Agent 的 SOP。它混合了自然语言描述和脚本命令，Agent 可以逐步执行，你可以选择性地自动审批。
"Workflow 的价值不是自动化本身，而是把你脑子里'理所当然'的流程外化成 Agent 也能理解的协议。"
第三层：Skill------构建你的"能力飞轮"
Skill 是三层中最重的一层，也是长期价值最高的一层。
一个 Skill 本质上是一个自包含的目录，包含 SKILL.md 指令文件、辅助脚本和参考资料。Agent 在匹配到相关意图时自动加载。我的 Skill 体系分两层：
全局层------跨项目复用的通用技能
我在本地维护了一个技能仓库项目，专门沉淀通用技能。每次遇到一个值得固化的问题，就把解决方案提炼成一个 Skill。通过同步脚本，这些技能可以一键分发到 Antigravity 的 skills 目录------同时也自动同步到 Claude Code 和 Codex，算是一个额外的便利。
这是一个典型的飞轮场景：第一次解决问题的时候确实慢，但 Skill 创建完成后，下一次遇到同类问题直接加载就能跳过大部分踩坑时间。积累得越多，Agent 的"出厂能力"越强。
💡 飞轮效应的关键：不是写了一个 Skill 就完事了。Skill 本身也在持续迭代------每次使用中发现的问题、更好的做法、新的边界条件，都会反馈回来优化 Skill。这就是"越用越好"的核心机制。
项目层------针对特定项目的定制技能
有些技能天然是项目特定的。比如我的一个 Agent 产品项目，其核心开发不是通过对话完成的，而是通过代码开发。但围绕它的调试、部署、环境配置等综合性工作，重复且容易出错------这些场景就很适合做成项目级 Skill，大大减少上下文消耗和流程性损耗。
同步机制------让 Skill 自动流转
技能仓库有一套同步脚本。SKILL.md 作为主要识别文件会被物化复制，其他资源通过软链接连接。你在仓库里修改了一个脚本，Antigravity 中立刻生效。如果你同时用其他工具，同步脚本也支持分发到 Claude Code 和 Codex 的 skills 目录。
同步脚本还有一个 manifest 元数据文件，用来追踪同步状态。当仓库中的技能发生变更，只要执行同步，脚本就能自动识别变更、新增、删除并相应处理------不侵入工作区中已有的独立技能。
"不要重复踩同一个坑。踩完第一次，就把它变成地图上的标记。"
全局视角：三层联动的效果
把这三层拉通来看：
- Rule 保证了 Agent 每次启动时就有正确的基础认知------项目架构、开发原则、关键资产清单。
- Workflow 把重复的流程标准化，让 Agent 在处理模糊输入时也能按框架行事。
- Skill 把解决过的问题封装成可复用的能力模块，形成越用越强的飞轮。
当然，工作区的武装只是基础设施。真正要把效率拉满，还需要配合项目层面的架构设计、质量门禁、测试规范等工程实践。但只要你把这三层机制玩明白，你的 Antigravity 工作区就已经从一个"临时聊天窗口"变成了一个有记忆、有章法、能自我进化的开发合伙人 。而且由于 .agent/ 目录的通用性，这套武装在切换到其他 AI 编程工具时也不会浪费。
这就是武装后和武装前的本质区别------不是 Agent 变聪明了，而是你给它搭了一个可以持续变聪明的系统。
本文基于个人在 Antigravity 工作区的长期实践经验整理。如果你也在用 AI 编程助手，欢迎在评论区分享你的工作区配置心得。