用 Rules 和 Skills 固化项目习惯

创建工作区规则和专用审阅技能，并验证它们在后续任务中真正发挥作用。

先分清两种用途

项目长期遵守的约定适合写成 Rule，例如沿用已有包管理器；具有固定步骤的任务适合写成 Skill，例如审阅阅读清单功能。

官方 Rules 文档说明了 .agents/rules/ 工作区规则及其启用方式；Skills 文档介绍了 .agents/skills/ 下包含 SKILL.md 的技能目录。本练习采用工作区级配置，让要求只影响当前项目。

1. 新建一条简短规则

在 Agent 面板打开 Customizations → Rules，创建工作区规则。本次练习将启用方式设为 Always On，命名为 project-basics，写入以下本站示例：

沿用当前锁文件对应的包管理器。
修改应用行为前，先说明用户将看到什么变化。
界面文案与项目已有表达保持一致。
任务结束时报告修改文件和实际执行过的检查。

不要照搬其他项目的包管理器名称。规则要与当前仓库相符，才能减少后续返工。

Customizations 的 Rules 页面与 + Workspace 按钮 — 本练习选择 + Workspace，让规则属于当前项目。旁边的 Workflows 标签并不是 Skills 文件夹。
官方示例截图（原图未修改） · 来源：Google Codelabs · CC BY 4.0 · 点击图片放大

哪些要求应该放在哪里

要求	放置位置	原因
沿用当前包管理器	工作区 Rule	多数开发任务都需要遵守。
按固定顺序审阅清单存储行为	Skill	只在特定任务中需要的一组步骤。
今天修改空状态文案	当前任务提示词	一次性需求，不必变成长久约定。

优先写能验收的小规则。“编写优秀代码”没有明确通过标准；“报告执行命令及其结果”可以与对话和终端记录核对。发现两条要求互相矛盾时，直接修订规则文件，让后续任务有清晰一致的目标。

2. 创建专用审阅技能

新建 .agents/skills/reading-list-review/SKILL.md：

---
name: reading-list-review
description: 审阅阅读清单的表单与存储行为。检查阅读清单应用的改动时使用。
---

# 阅读清单审阅

1. 找到表单验证与数据保存的代码。
2. 检查空标题、无效网址、刷新保留和删除条目。
3. 跟踪一次用户操作如何影响最终保存的数据。
4. 每项问题注明复现方法和预期结果。
5. 区分仅阅读代码得出的判断与实际测试的结果。
6. 除非用户要求修复，否则不要修改文件。

这是可按需改写的本站示例。技能范围越明确，越容易判断它是否适合当前任务。

检查文件放置位置

project-root/
└── .agents/
    ├── rules/
    │   └── project-basics.md
    └── skills/
        └── reading-list-review/
            └── SKILL.md

规则的配置由 Rules 界面管理，检查它在项目里生成的文件，不要拿其他示例覆盖其配置元数据。Skill 则需要独立目录和 SKILL.md，顶部保留示例中的 name、description。使用文本编辑器时，注意不要误存成 SKILL.md.txt。

描述应说清主题和触发场景。“助手”过于宽泛；“审阅阅读清单的表单与存储行为”更容易匹配任务。先写纯说明版技能，确实需要重复执行程序时，再添加脚本或参考文件。

3. 在新任务中验证

在同一工作区开启新对话：

使用 reading-list-review 审阅当前应用。
遵循项目规则，并报告实际做过的检查。
先不要修改代码。

对照保存的规则与技能检查结果：是否覆盖清单场景，是否避免无关改动，是否区分了代码检查和实际运行。技能未被识别时，先检查工作区根目录、文件名和 frontmatter 格式，不要盲目叠加更多指令。

官方示例在新对话中列出 code-review 技能及 SKILL.md — 先在新对话中确认技能可被发现，再执行匹配任务。图中是官方 code-review 示例，本练习的技能名是 reading-list-review。
官方示例截图（原图未修改） · 来源：Google Codelabs · CC BY 4.0 · 点击图片放大

不只检查“发现了”，还要检查“照着做了”

能列出技能，只证明元数据被找到。继续让 Agent 指出相关验证与存储文件，说明完成了哪些审阅步骤，再与技能中的六项要求对照。

在练习应用中做一个小改动，例如调整未读筛选，然后要求审阅。检查结果是否追踪了保存数据的变化，而不只是看界面有几行。如果没有运行浏览器，报告应写“已检查代码”或“未测试”，不能写成“测试通过”。

问题	检查方法
找不到技能	核对项目根目录、目录层级、文件名和 frontmatter。
列出来却不使用	提示词中写出准确名称，并把描述写得更具体。
输出仍然泛泛而谈	将抽象要求换成输入样例和预期行为。
无关任务也背负大量指令	从 Always On 规则中移除一次性需求。

4. 随项目维护

项目变化后及时删除过时要求。使用可观察、可验收的描述，比堆积抽象原则更容易验证。

如果你已有 Workflows，请先阅读官方迁移提示，再决定如何维护。该页目前说明 Workflows 将在 2026 年 11 月 1 日前转向 Skills。

下一篇：通过 MCP 连接外部工具。

用 Rules 和 Skills 固化项目习惯

On this page