前面几篇我们已经把项目地图、状态机和 SIADOS 讲清楚了。
这一篇要继续往下走，回答一个非常实际的问题：

当前这一轮任务，到底应该怎么写，AI 才能看得懂、做得对、不会越界？

本书把这个问题交给 current_task.md。

它不是聊天记录，
也不是随手写的一句口头要求，
而是一份短期有效、可以验收、可以回写状态的任务契约。

---

1. 为什么还要有 current_task.md？

很多时候，人类给 AI 的任务本来是模糊的。

比如你可能会说：

• “把这个 Bug 修一下”
• “顺便把相关测试补上”
• “改完以后尽量别影响其他部分”
• “如果有兼容性风险，先记下来”

这些话人能听懂一点，但对系统来说并不够清楚。
因为它没有把下面几件事明确写出来：

• 这轮的目标到底是什么
• 这轮允许改哪里
• 这轮禁止碰哪里
• 什么结果算通过
• 哪些歧义需要先确认

所以本书把这类信息收敛到 current_task.md 里。
它的作用就是把当前任务收窄到一个可执行范围内。

---

2. 一轮任务只能有一个主目标

current_task.md 最重要的原则，是单一主任务原则。

“完成项目修复”“继续开发项目”这种说法，只能算长期方向。
真正的一轮任务，还必须具体到一件可做、可验收的事。

比如：

• 修一个 Bug；
• 补一个测试；
• 改一个接口；
• 更新一个状态文件；
• 记录一个未决问题。

如果一轮任务太散，Agent 就会把相关事情一起做掉。
看起来像“顺手优化”，实际上可能会：

• 修改范围扩大；
• 任务目标混乱；
• 验收条件不清；
• 后续无法回滚。

其他重要但不属于当前轮的内容，应该写入 open_issues.md 或后续任务，而不是塞进当前任务。

---

3. current_task.md 应该写什么？

一份可执行的 current_task.md，不需要很长，但要写清几个字段：

# Current Task

## Task
Fix the empty-cart checkout path in `checkout/service.py`.

## Goal
Return a safe error when the cart is empty,
while preserving normal checkout behavior.

## Allowed
- `checkout/service.py`
- `tests/test_checkout.py`
- `revision_log.md`
- `open_issues.md`

## Forbidden
- `auth/*`
- `payment_gateway/*`
- `docs/*`
- unrelated modules

## Acceptance
1. Empty-cart checkout is handled safely.
2. Normal checkout still passes.
3. Only allowed files changed.
4. Unresolved compatibility concerns are recorded.

重点不是格式漂亮，而是把任务变成可检查的边界。

Agent 看到这份文件以后，应该能判断：

• 当前要做什么；
• 修改范围在哪里；
• 哪些地方不能动；
• 什么结果算通过；
• 哪些问题需要记录而不是直接处理。

4. 从自然语言到任务契约

这一章很重要的一点，是把自然语言输入“编译”成任务契约。

比如人说：

“把这个 Bug 修一下，顺便保证不影响其他模块。”

这句话本身并不适合直接执行。
因为它包含了两个问题：

• “修一下”不够具体
• “不影响其他模块”可能会诱导越界修改

所以系统不能直接照着做，
而要把它编译成一份结构化任务：

• 目标：修复空购物车结算
• 允许：checkout/service.py、tests/test_checkout.py
• 禁止：auth/、payment_gateway/
• 验收：只检查结算路径和回归测试

这样，Agent 不会把“保证不影响其他模块”理解成“可以把其他模块一起改”。

它只能在当前授权范围内完成任务。

5. 冲突和歧义怎么处理？

任务里经常会出现冲突。

例如当前任务要求只修结算逻辑，但又有人补了一句：

顺便统一一下认证模块。

这时不能直接执行。

因为认证模块不在当前任务范围内。

current_task.md 应该规定优先级：

1). 安全和系统边界；
2). 当前任务的禁止项；
3). 当前任务目标和验收条件；
4). 补充偏好和软性建议。

也就是说，软性建议不能覆盖明确边界。

如果 Agent 发现了相关问题，可以写入 open_issues.md，留给后续任务处理。

6. 验收条件必须可观察

任务能不能完成，取决于验收条件是否清楚。

“写好一点”“提高质量”“尽量优化”都不适合作为验收条件。

更好的验收条件应该是可观察的：

空购物车返回安全错误；
正常结算路径不受影响；
只修改允许文件；
未决兼容性问题已记录。

这些条件可以检查。

可检查，任务才有结束点。

不可检查，Agent 就容易继续猜、继续改，最后越改越散。

本章小结

current_task.md 的作用，是把自然语言要求变成一份当前轮任务契约：

• 这一轮做什么；
• 哪些地方能动；
• 哪些地方不能碰；
• 什么结果算通过；
• 哪些问题要记录下来。

Agent 不需要每轮重新猜任务，而是在明确边界里推进。

下一章，我会继续讲：修改日志 revision_log.md 为什么能帮系统收敛，以及它和 Git 的分工到底是什么。