任务会结束，理由会留下。
Tasks end. Reasons remain.
Leelaa PM，一个记得为什么的任务系统。
这四个词每天都会出现。却很少被连在一起。
上下文，产生决策。
决策，产生任务。
任务，产生结果。
一 · 问题
每一次，都从空白开始。
你向一个 AI 解释这个项目：它是做什么的，做到了哪里，上个月为什么放弃了另一个方案。它听懂了，把事情做完了。第二天，换一个窗口，或者换一个模型——你再解释一遍。有时候，连你自己也不记得了。
上下文并没有丢失。它从来就没有被留下。
任务清单写着做什么。却没有写为什么。
二 · 原因
工具默认，读任务的人已经知道为什么。
这个假设，对人大多成立。理由散落在会议里、聊天记录里、某个人的记忆里，需要的时候，总能找到一个人去问。对 AI，它不成立。AI 只能读到被写下来的东西。
现在，一个任务常常要经过好几双手。
- 创建AI
- 实现AI
- 验收AI
- 测试AI
- 确认人
一个 AI 创建它，另一个实现，第三个验收，第四个测试，最后由人确认。
每一次交接，都是一次遗忘的机会。
问题不在于 AI 不够聪明。而在于来龙去脉，没有一个可以存放的地方。
三 · 方法
不让 AI 记住更多，而让项目自己记住。
我们只坚持四件事。
- 3.1REASON FIRST · 知识挂靠
先有理由，才有任务。
每个任务在创建时，必须指向它所服务的知识——一条需求、一个决策、一项约定。说不出为什么的任务，不会被创建。
- 3.2DECISION LOG · 行为开工判定
判断，在开工时写下。
开始之前，先回答：它会改变产品的行为吗？为什么？用户会感知到吗？需要写进更新日志吗？判断不留在对话里，留在任务上。
- 3.3VERIFIABLE · 证据与时间线
完成，需要证据。
「做完了」不是一个勾选框。提交验证时附上证据；每一次状态变化——谁、何时、从哪里到哪里——都被记下。
- 3.4FEEDBACK LOOP · 闭环回写
结果，回到上下文。
改变了产品行为的任务，交付之前必须把变化写回知识。这一次的结果，成为下一次的上下文。
四 · 连续体
上下文，决策，任务，结果。然后，结果成为新的上下文。这不是一个循环。循环会回到原点。这是一条向前延伸的线——每一次，都从上一次停下的地方开始。
一个项目，不是一堆任务，而是一段连续的推理。
五 · 系统
这些想法，在系统里的样子。
以下是 Leelaa PM 里真实存在的部分。
图版 01CONTEXT
知识树
示意数据
图版 02DECISION
开工声明
- 行为
- 改变
- 理由
- 任务详情和流转接口的行为改变
- 用户可见
- 是
- 更新日志
- 需要
示意数据
图版 03TASK
状态与流转
- 计划
- 就绪
- 进行中
- 待验证
- 已完成
- gpt-5.6@codex开始实现 · 行为改变
- claude@claude-code提交验证 · 附证据
- glm-5@zcode测试通过
- chen（真人账号）确认完成
示意数据
图版 04RESULT
证据与版本
端到端验证通过：原样命令可建真任务并完成状态流转
- +AI 模型配置改为全局
- +「系统状态」更名为「系统」
示意数据
图版 05
同一份记录，两种读法
"prdRefs": ["pm-api", "pm-pages"]"reason": "任务详情和流转接口的行为改变""evidence": [{ "summary": "端到端验证通过" }]示意数据
图版 06
每个 AI 都有名字
在线凭据gpt-5.6@codex开始实现
在线凭据claude@claude-code提交验证
在线凭据glm-5@zcode测试通过
示意数据
图版 07
可以被提问的项目
这周推进了什么，卡在哪里？
本周完成 6 项，其中 3 项进入 v2.17.0。1 项仍在待验证，等待真实供应商连通测试。
示意数据
下一次开始时，它已经知道为什么。