writing-checks

编写检查项

为 Continue 编写检查项文件——用于定义审核拉取请求的 AI Agent 的 Markdown 文件。

文件格式

检查项是包含 YAML 前置元数据和正文的 Markdown 文件。前置元数据用于配置元数据。正文是 Agent 审核 PR 时遵循的提示词。

---
name: Migration Safety
description: Flag destructive database migrations
---

Your prompt here. This becomes the agent's system prompt
when evaluating the pull request.

前置元数据字段

字段	必填	类型	描述
name	是	字符串	在 GitHub 状态检查和 continue.dev 上显示的名称
description	是	字符串	简要描述此检查项的验证内容
model	否	字符串	要使用的模型。默认使用 Claude Sonnet。示例：anthropic/claude-sonnet-4-5-20250514

文件位置

将检查项保存到仓库根目录下的 .continue/checks/<name>.md。系统只会扫描该目录中的 .md 文件，不会扫描子目录。

编写正文

正文是 Agent 的提示词。请使用直接指令，告诉 Agent 要查找什么以及如何处理。

明确限定范围

每个检查项只关注一个问题。试图同时涵盖安全性、测试覆盖率和文档的检查项会导致结果混乱。请将其拆分为三个检查项。

具体明确

列出具体标准。模糊的指令会产生模糊的结果。

良好示例：

Look for these issues in the changed code and fix them:

- New REST endpoints missing request body validation
- Database queries using string interpolation instead of parameterized queries
- Error responses that expose stack traces or internal paths

不良示例：

Check that the code is secure.

无需编写的内容

系统会自动在提示词前添加元提示词，其中：

• 提供完整差异和更改文件列表
• 指示 Agent 只审核更改的行
• 防止 Agent 处理未更改代码中的既有问题
• 限定只能编辑已更改的文件

不要加入“审核已更改的文件”或“只查看差异”之类的指令——这些已经处理好了。请专注于要查找什么以及如何修复。

检查项可以执行的操作

运行检查项的 Agent 可以：

• 读取差异之外的仓库文件，以获取上下文
• 运行 bash 命令，例如 grep、find 或自定义脚本
• 使用浏览器访问 URL、截屏并验证渲染结果
• 访问 PR 差异，包括文件名、新增内容和删除内容
• 使用 GitHub CLI（gh）读取 PR 元数据、评论或关联的问题

检查项、测试与代码 lint

代码 lint负责格式、风格和静态模式。如果某条规则可以通过语法模式匹配来表达，就应该放在代码 lint 工具中。

测试用于验证正确性和行为。如果问题是“此函数是否返回了正确的输出”，就应该编写测试。

检查项用于处理需要理解上下文的判断：

• “这个数据库迁移在包含 5 亿行的表上运行是否安全？”
• “此 PR 是否更新了 API 文档，以反映端点的变更？”
• “这个身份验证流程是否存在代码 lint 工具无法发现的安全问题？”

工作流

当用户要求你编写检查项时：

1. 了解代码库——阅读相关源文件、配置和 .continue/checks/ 中现有的检查项，了解项目使用的技术栈、约定和已有覆盖范围。
2. 选定一个问题——如果用户提出的需求范围较广（例如“安全性”），请根据其技术栈找出影响最大的单一问题，并为此编写检查项。可提出后续继续编写其他检查项。
3. 编写具体标准——准确列出要查找的内容。尽可能使用项目实际采用的框架和模式，提供良好和不良代码示例。
4. 明确通过/失败的条件——Agent 需要知道何时通过、何时失败。适当时，明确列出“无需采取行动的情况”。
5. 保存文件——写入 .continue/checks/<name>.md。

检查项示例

---
name: Migration Safety
description: Flag destructive database migrations
---

If no migration files were added or changed, no action is needed.

When migrations are present, look for these issues:

- `DROP TABLE` or `DROP COLUMN` without a preceding migration that backs up or migrates the data — add a data migration step or split into separate migrations
- Column type narrowing (e.g., `TEXT` to `VARCHAR(50)`, `BIGINT` to `INT`) without a backfill step — add a backfill or guard against data truncation
- `NOT NULL` constraint added to an existing column without a `DEFAULT` value — add a default or a data backfill migration
- Renaming a column or table that is referenced by application code without updating that code in the same PR — update the references
- A destructive and a constructive change in the same migration file — split into separate migrations for safe rollback