前面几篇我们已经把项目地图、状态机和 SIADOS 讲清楚了。
这一篇要继续往下走，回答一个非常实际的问题：
当前这一轮任务，到底应该怎么写，AI 才能看得懂、做得对、不会越界？
本书把这个问题交给 current_task.md。
它不是聊天记录，
也不是随手写的一句口头要求，
而是一份短期有效、可以验收、可以回写状态的任务契约。
1. 为什么还要有 current_task.md？
很多时候，人类给 AI 的任务本来是模糊的。
比如你可能会说：
- “把这个 Bug 修一下”
- “顺便把相关测试补上”
- “改完以后尽量别影响其他部分”
- “如果有兼容性风险，先记下来”
这些话人能听懂一点，但对系统来说并不够清楚。
因为它没有把下面几件事明确写出来：
- 这轮的目标到底是什么
- 这轮允许改哪里
- 这轮禁止碰哪里
- 什么结果算通过
- 哪些歧义需要先确认
所以本书把这类信息收敛到 current_task.md 里。
它的作用就是把“当前这一轮要做什么”固定下来。
2. 为什么要先有一个主任务？
current_task.md 最重要的原则，是单一主任务原则。
“完成项目修复”“继续开发项目”这种说法，只能算长期方向。
真正的一轮任务，还必须具体到一件可做、可验收的事。
比如：
- 只修一个函数
- 只补一处测试
- 只修一个接口返回
- 只更新一个问题记录
为什么要这样做？
因为如果一轮任务太散，AI 很容易把很多相关事情一起做掉。
看起来像“顺手优化”，实际上可能会：
- 扩大修改范围
- 混淆任务目标
- 把局部动作变成全局改动
所以，一轮任务最好只有一个主目标，其他事情如果重要，就写进 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
## Constraint
- preserve normal checkout
- keep changed files within allowlist
## Acceptance
1. Empty-cart checkout is handled safely.
2. Normal checkout still passes.
3. Only allowed files changed.
4. Unresolved compatibility concerns are recorded.
这份任务契约的重点，不在于格式多漂亮，
而在于它把模糊请求变成了可检查的动作范围。
6. 从自然语言到任务契约
这一章很重要的一点，是把自然语言输入“编译”成任务契约。
比如人说：
“把这个 Bug 修一下，顺便保证不影响其他模块。”
这句话本身并不适合直接执行。
因为它包含了两个问题：
- “修一下”不够具体
- “不影响其他模块”可能会诱导越界修改
所以系统不能直接照着做，
而要把它编译成一份结构化任务：
- 目标：修复空购物车结算
- 允许：checkout/service.py、tests/test_checkout.py
- 禁止：auth/、payment_gateway/、docs/*
- 一致性问题：记录，不执行
- 验收：只检查结算路径和回归测试
这样，AI 就不会把“顺便保证不影响其他模块”理解成“可以把别的模块也一起改”。
7. 为什么 current_task.md 是人和 AI 共同签署的？
current_task.md 不是单方面命令，
它更像是一份双向契约。
人的作用
人负责：
- 定义方向
- 确认范围
- 决定哪些歧义不能直接执行
- 判断是否要扩张任务
AI 的作用
AI 负责：
- 理解当前任务
- 在允许范围内推进
- 把发现的问题写入候选状态
- 在不越界的前提下完成修改
所以当任务目标变化时，正确做法不是让 AI 在原任务里硬改，
而是先结束或暂停当前转移，再创建新的任务契约。
这能避免系统一边跑一边换目标，最后变成失控扩散。
8. 冲突怎么处理？
任务里经常会出现冲突。
本书把冲突处理分成优先级：
- 系统与安全边界
- 当前任务的明确禁止项
- 当前任务的目标与验收
- 补充偏好和软性措辞
这个顺序很重要。
因为很多问题不是“怎么改得更好”，
而是“能不能改”。
例子
如果当前任务要求只改结算逻辑，
那“顺便统一认证模块”的建议就不能直接执行。
它可能是合理的后续工作，
但不是当前轮的授权范围。
所以 current_task.md 的作用之一，就是把这些优先级固定下来，避免模型把软性建议当成硬性命令。
9. 任务编译器做什么？
如果把任务契约生成过程抽象出来，可以把它看成一个任务编译器。
它接收：
- 用户输入
- 项目状态
- 当前阶段
输出：
- 结构化任务契约
这个过程通常可以拆成六步：
- 提取目标对象
- 识别目标变化
- 计算最小必要动作
- 继承长期不变量
- 生成验收条件
- 标记需要确认的歧义
这样，任务就不是“看起来差不多”，
而是变成了一个可以执行、可以验证、可以回写的结构。
10. 为什么验收条件要写得可观察？
如果验收条件还是“尽量写好一点”“提高质量”“写得更专业”，那系统其实没法判断到底算不算完成。
所以验收最好是可观察的：
- 修改范围是否正确
- 行为是否恢复正常
- 是否保留了必要的限制说明
- 是否记录了未决问题
比如：
- “空购物车返回安全错误”
- “正常结算路径不受影响”
- “只改允许文件”
- “不新增无关修改”
这类条件可以检查，
而“写得更好”不行。
11. 三类任务契约
不同类型的任务，契约内容也不完全一样。
本书里可以粗略分成三类：
11.1 代码修复
关注：
- 可复现故障
- 修改范围
- 回归测试
- diff 是否越界
11.2 程序整理
关注：
- 目录结构
- 入口文件
- 依赖关系
- 状态文件更新
11.3 资料研究
关注：
- 研究问题
- 来源范围
- 时间窗口
- 不确定性记录
它们的格式可以统一，
但字段的重点不同。
12. 本章小结
这一章想讲清楚的核心是：
current_task.md 的作用，是把自然语言要求变成一份可执行、可验收、可回写的任务契约。
它让 AI 知道：
- 这一轮到底做什么
- 哪些地方能动
- 哪些地方不能碰
- 什么结果算通过
- 哪些歧义要留下来
有了它，AI 才不会每轮都重新猜任务，
而是能在一个明确边界里推进。
扫一扫
931
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
