不是模型不行，是“当初为什么”没人替它记住。
*图：Backlog.md 官网首页。它把任务、验收标准、实施计划和执行记录写成仓库里的 Markdown 文件。官网：kuwork.github.io/Backlog.md
你有没有见过这种项目？
第一版，AI 按你的描述做完，验收通过。
第二版，基于现有代码改，也没问题。
第十版，功能一个不少，界面甚至更漂亮了。
但你说不上来哪里不对。
直到你想加回最初那个设计，才发现代码里已经找不到它存在过的证据。
这不是 AI 突然变笨，而是它每次都在读“结果”，没有读到“原因”。
一、代码知道“现在是什么”，不知道“当初为什么”
AI 接到任务，第一件事通常是读代码。
这很合理。它要先知道项目现在长什么样，才知道从哪里下手。
但代码只能告诉它：这里有一个函数、那里有一层缓存、某个参数被特殊处理过。
代码不会主动解释：
- 这个奇怪的判断，是为了兼容哪个老客户？
- 这层看起来多余的抽象，躲过哪次线上事故？
- 这个“先这样、以后再改”的临时方案，为什么一直没改？
于是 AI 只能根据现状，反推当初的设计意图。
反推一次，误差很小。
新代码覆盖旧代码，下一轮再基于新代码反推。
每一轮都合理，每一次验收都能过。
误差却顺着任务链，一点点累加。
最后你得到的，是一个“每个功能都对、整体方向却偏了”的项目。
二、Backlog.md 做的事，其实很朴素
它没有发明一套复杂方法论。
它只是把 AI 干活前该说清楚的东西，写进仓库里的 Markdown 文件：
- 为什么做：任务背景与目标；
- 怎样算完成：可勾选的验收标准；
- 准备怎么做：AI 调研代码后写下的实施计划；
- 最后做了什么：实现笔记与最终总结。
AI 写代码，人审任务。
审查发生在三个位置：规格、计划、结果。
这里要说清楚一件事：
Backlog.md 不是权限系统，不会在技术上强行拦住 AI 写代码。
它做的是把审查点变成流程的一部分。Agent 是否先写计划、是否停下来等批准，取决于它有没有读到工作流指令，也取决于你有没有真的去看。
工具给你一张检查表，不能替你签字。
三、它里面到底有些什么
不用记很多名词，先分清这几样：
任务：一个任务一份 Markdown，四块正文外加 frontmatter 元数据。它可以被 diff、被 review、被搜索，也可以归档。
文档：开发策略、技术方案、背景资料。人主导，AI 辅助。
决策记录：为什么选 A 不选 B。过几个月再回看，这类记录比代码更有用。
Memos：随手记。灵感、碎片、待验证的念头先钉住，不必马上变成正式任务。
看板：它不是另一种文件，只是读同一批任务文件的一个视图。拖动卡片，改的还是 Markdown 里的状态。
Wiki：知识沉淀层。它需要安装对应技能并执行摄取，不是“任务一完成就自动长出来”。
把这几样串起来，Backlog.md 的核心就一句话：
任务存 Markdown，进度是 diff，知识可以沉淀成可查的 Wiki。
四、一条想法，怎么走完最小闭环
假设你想给 Web 视图加一个搜索功能。
你可以先把想法记在 Memos，也可以直接交给 Agent。这里按真实协作流程走：人不敲命令，人提需求；任务由 Agent 建。
第一步，把需求说清楚。
你对 Agent 说：
“把‘Web 视图增加全局搜索’拆成 Backlog.md 任务。写清目标、验收标准和范围，先不要写代码。”
Agent 会按项目里的 Backlog.md 工作流说明来做：自己调用 CLI 建任务，把描述和验收标准写进 backlog/tasks/，你不用背命令。
这份说明由 backlog init 写进 Agent 的指令文件。前提是 Agent 会读取项目里的 AGENTS.md、CLAUDE.md 这类文件；之后对话里涉及 backlog，它就会自动查阅当前版本的工作流。
任务建好后，你审第一道：规格。
- 它有没有理解错目标？
- 验收标准是不是可验证？
- 范围有没有被悄悄放大？
第二步，让 Agent 写计划。
任务方向确认后，再让 Agent 研究代码库，把实施计划写进任务，停下来等你批准。
你审第二道：计划。
- 它准备改哪些地方？
- 有没有绕开现有架构？
- 有没有漏掉验收标准？
方向不对，这时候改，成本是一段话。
第三步，执行并核对。
批准计划后，Agent 再动代码。完成后看 diff、跑测试、逐条核对验收标准，这是第三道：结果。
通过后写最终总结，再把状态改成 Done。
本文讲的是 AI 协作的主流程：人负责目标和验收，Agent 负责拆解和执行。
官方建议尽量做到：一个任务，一个会话，一个 PR。
注意，这是建议，不是系统强制。任务拆得太大，diff 照样会失控。
五、它真正解决的，不是“记忆”，是“可接续”
很多人把 Backlog.md 说成 AI 的“长期记忆”。
更准确的说法是：它给项目留了一份可以接续的事实源。
新会话不会自动继承上一次的聊天记录。
新 Agent 也不会一进门就懂你的项目。
但它有地方可读：
- 任务描述里有目标；
- 验收标准里有边界；
- 实施计划里有取舍；
- 实现笔记里有“当时为什么这么干”；
- 依赖关系里有前后顺序。
换人、换模型、隔一周再回来，不用从“我们上次说到哪了”重新讲一遍。
这带来的最大变化，不是 AI 突然不会犯错，而是：
错误更容易在写代码之前被发现。
以前你要等它写完两千行，才知道方向错了。
现在你看一屏任务和计划，就能说“不对，重来”。
返工从代码层，前移到了纸面层。
六、三个容易误会的地方
误会一：装了它，AI 就会自动守规矩。
不会。
它提供任务结构和工作流指令，但 Agent 仍可能跳过计划、误解验收标准，或者做多余的事。你仍然要审，仍然要跑测试。
误会二：任务拖到 Done，知识就自动进 Wiki。
也不完全对。
Wiki 需要先安装对应技能、初始化，再执行摄取。任务总结是原料，不是自动生成的成品。
误会三：所有事都值得建任务。
不必。
改个错别字、调一个颜色、一次性小脚本，直接做更快。Backlog.md 更适合这些场景：
- 一个需求要跨多轮迭代；
- 你要把工作委派给 AI；
- 同时跑多个 Agent；
- 一周后还要回来搞清楚“到底改了什么、为什么改”。
[图片上传失败...(image-f4ea3a-1794406842484)]
图：左边每一步都打勾，路线却离目标越来越远；右边每轮回到同一份任务文件校准，路径始终贴着目标。
七、想试的话，先从一个小需求开始
不用先搭一套完美流程。
- 安装后，在项目里运行
backlog init；没有 Git 就加--no-git； - 初始化时选择 CLI 指令，让 Backlog.md 把工作流提示写进 AGENTS.md、CLAUDE.md 等项目指令文件；
- 之后对话里涉及 backlog，Agent 会自动查阅工作流；
- 拿一个真实的小需求，交给 Agent 建一个任务；
- 只要求三件事：为什么做、怎样算完成、准备怎么做；
- 让 AI 先交计划，你批准后再动代码；
- 完成后核对验收标准，写总结，再改状态。
先跑通一个任务，再决定要不要把它用成长期习惯。
AI 不会因为多了一个工具，就突然变得可靠。
可靠的是另一件事：
当它想不起来“当初为什么”时，仓库里有一份文件，能把它拉回来。
