7.4 确定一份 Skill 负责什么任务。这一节继续问：在这项任务里，哪些做法可以让 Agent 自行选择，哪些必须明确规定？
按每一步的需要调整控制程度。 允许多种正确做法时，交代目标与理由，保留判断空间；操作依赖固定顺序、参数或一致性时，把要求写具体。存在多种方案时，先给默认值，再说明切换条件。让处理方法适用于下一次同类任务。
本节对应 Calibrating control 及其三个子主题。原文强调的是任务的 fragility（脆弱程度）：改变做法后，是否容易出错。复杂程度本身不能决定需要多少约束。
下面先读官网例子的中文译文，再将三个判断用于 7.4 的 write-learning-unit。译文保留命令、库名、文件路径和字段名，英文原文可通过对应链接查阅。这些片段用于说明写法，其中的迁移脚本和数据库资料并未包含在本站练习中。
7.5.1 哪些操作要规定具体，哪些可以保留判断空间
Match specificity to fragility 给出两种不同的情况。
允许多种正确做法：交代检查目标
官网代码审查例子的中文译文：
## 代码审查流程
1. 检查所有数据库查询是否存在 SQL 注入风险，使用参数化查询。
2. 验证每个接口是否进行身份认证检查。
3. 检查并发代码路径中是否存在竞态条件。
4. 确认错误信息不会泄露内部细节。
这里明确了检查内容，并对查询写法提出约束，但没有规定必须先打开哪个文件、以什么顺序阅读全部代码。Agent 可以根据项目结构组织审查。
做法变化容易出错：规定具体操作
官网数据库迁移例子的中文译文：
## 数据库迁移
严格按以下命令执行：
```bash
python scripts/migrate.py --verify --backup
```
不要修改命令，也不要添加其他参数。
这里把需要保持不变的内容明确到了具体命令与参数。
同一份 Skill 中可以同时存在这两种写法。可以逐步问：
| 检查问题 | 写作上的选择 |
|---|---|
| 换一种顺序或方法，仍能满足结果要求吗？ | 说明目标和理由，保留选择空间 |
| 结果是否依赖指定的参数、顺序或一致性？ | 把这些必要约束写清楚 |
| 哪些细节目前并没有依据要求固定？ | 先交给判断，再观察实际执行是否暴露问题 |
以本站写作为例：解释顺序可以根据读者理解来调整；引用原例时名称与命令要对应，不能为了翻译随意改动。
7.5.2 多种方法如何确定默认方案与切换条件
Provide defaults, not menus 讨论的是：怎样让 Agent 知道从哪里开始。
官网先展示了一个只列选项的写法，译为中文是：
可以使用 pypdf、pdfplumber、PyMuPDF 或 pdf2image……
随后改成默认方案与例外情况，中文译文如下：
使用 pdfplumber 提取文字：
```python
import pdfplumber
```
如果扫描版 PDF 需要文字识别（OCR），改用 pdf2image 配合 pytesseract。
这是这个例子采用的工具约定。
变化不在于删掉了所有备选方案，而在于补上了两条决策信息：
- 从哪里开始：正常情况先用哪个方案。
- 什么时候切换：遇到什么输入或条件，再采用另一个方案。
用于本站写作时，可以默认运行项目已有的页面与导航检查；当本次增加交互行为时，再补充对应的浏览器检查。这样既有起点，也保留针对实际变化补充检查的空间。
7.5.3 如何把一次任务的做法提炼成可复用流程
Favor procedures over declarations 中的 procedures 指处理方法或流程。这里的重点是让方法能用于同类新任务。
官网先给出一个具体查询的做法，译为中文是：
通过 `customer_id` 连接 `orders` 表与 `customers` 表，
按 `region = 'EMEA'` 筛选，再汇总 `amount` 列。
这里的表名、筛选地区和汇总列都已经固定。
改成可复用流程后，中文译文如下：
1. 读取 `references/schema.yaml` 中的数据结构，找出相关的表。
2. 按 `_id` 外键命名约定连接表。
3. 根据用户请求添加 WHERE 筛选条件。
4. 按需汇总数值列，并以 Markdown 表格输出。
这里仍然保留了具体细节：结构资料的位置、外键约定、输出格式。变化的是，将每次可能不同的表、条件和汇总目标交给本次输入决定。
对应到本站：d20 是 7.1 的具体知识点；“解释当前例子中理解任务必需的术语”才是下一节也能使用的方法。
综合练习：逐步校准同一份 Skill
继续使用 7.4 的任务边界、名称和描述，只在正文中明确判断空间、默认方案与必要约束：
---
name: write-learning-unit
description: 为本站编写或修改一个技术学习小节时使用。依据用户指定的资料，用完整最小示例解释当前知识点。
---
## 输入与范围
确认本节学习目标、用户指定的来源，以及要修改的页面。
本流程覆盖该小节的正文、示例，以及使该页可访问所必需的导航关联。
阅读项目已有的写作约定，确认本地预览和项目要求的构建工具可用。
## 工作步骤
1. 阅读指定资料，核对要讲解的例子和本节范围。
2. 展示完整的最小示例，再解释必要组成部分。解释顺序可根据内容调整，以帮助读者连贯理解。
3. 英文原例提供中文译文，保留相同的程序名称与命令。
4. 解释理解当前示例必需的术语，每次只展开当前学习点。
5. 默认运行 `bash tests/test-project-navigation.sh` 检查页面与导航；若本次增加交互行为，再补充对应的浏览器检查。检查失败时修正问题并重新验证。
## 完成与交付
说明与示例一致，相关页面和导航验证通过后，给出预览链接并说明本节完成了什么。
这是根据本站已有约定整理的教学稿。检查命令来自当前项目；使用它需要满足项目规定的 Hugo 等环境要求。
三类判断可以在同一份文件里找到：
| 改写位置 | 调整了什么 |
|---|---|
| 第 2 步 | 固定完整示例这一要求，让解释顺序保留判断空间 |
| 第 3 步 | 固定名称与命令的一致性，避免翻译改变接口 |
| 第 5 步 | 给出默认检查命令，以及增加浏览器检查的条件 |
| 输入与第 1、4 步 | 根据每次主题和资料执行，不固定成 d20 的一次答案 |
检验这份写法时，可以分别观察：换一个主题能否继续使用；允许的解释顺序变化是否仍满足学习目标；原例名称与命令是否保持一致；新增交互后是否补充了对应检查。
这些是待观察的执行条件，尚未作为真实 Agent 对照实验运行。写成“必须”或“验证通过后”，表达的是执行要求；是否由程序阻止跳过检查，需要后续的运行机制来落实。