把暂时不做的需求放进 BacklogHERMES & AGENT ENGINEERING · 课时 02

2.1 先别急着生成 SPEC

上一节已经生成了胶囊系统的需求简报。按照原来的安排，接下来似乎就可以执行 $speckit-specify，让 Spec Kit 把它整理成正式 SPEC。

但需求简报只是草稿。真正进入 SPEC 之前，还要重新读一遍，判断哪些是当前版本必须完成的，哪些只是我们对未来系统的设想。

这次重读，很快就能发现第一个问题。需求简报把内化层写进了主流程：

### 6. 形成内化结构

- 当前判断
- 主题索引
- 页面链接
- 输出调用

可我们现在并没有做出这个决定。

2.2 内化层还没有想清楚

前面讨论胶囊系统时，已经分析过内化层的方向。知识页应该不断变成一篇好文章，用户可以反复回到同一条知识线；主题页还可以沉淀当前判断，整个 Wiki 也可以维护一张主题索引。这些想法没有问题。

问题在于，它们还不是一套可以直接开发的方案。

每个人的知识结构都不一样。有人需要一张主题索引，有人更需要在写作时调用旧知识，也有人只想保留几条短判断。内化层是一个个性化极强的功能，所以它应该交给用户自己去思考。

所以第一版先不做内化层。当前主流程做到知识页演化为止。

2.3 暂时不做，不等于从文档里消失

把内化层从当前需求简报中删掉以后，还有一个问题：这些想法应该放在哪里？

如果彻底删掉，过一段时间很可能忘记当时讨论过什么。可如果继续留在当前需求里，Spec Kit 又会把它们变成本次承诺。

产品开发里通常会用 Product Backlog 保存这类内容。中文常翻译成“产品待办列表”。它记录可能要做的功能、已经明确延期的需求、还需要验证的假设，以及暂时没有排进版本的改进方向。

Backlog 里的内容是候选，不是承诺。

这句话很重要。SPEC、Plan 和 Tasks 都会推动当前版本向前执行，Backlog 不会。只有当一个条目经过讨论，问题、范围和验收方向都足够清楚以后，它才会从 Backlog 进入新的 SPEC。

2.4 给 Product Backlog 一个正式结构

项目里的 Backlog 不能长期保持成一堆聊天片段。至少要知道这个想法从哪里来、目前是什么状态、为什么暂缓，以及满足什么条件以后才值得继续。

这份文档先定义五种状态：

内化层不是刚刚冒出来的念头。前面已经讨论过它，也明确决定第一版不做，所以它的状态是 Deferred。

一个正式的 Backlog 条目，至少要保留这些内容：

Product Backlog 没有一份所有团队都必须照抄的 Markdown 模板。有的团队把它放在 Jira，有的团队放在 Linear，也有人直接维护一张表。我们这里需要的是一套项目标准：同一个项目里的每条候选需求都用相同字段，状态变化也留得下记录。

下面不是条目摘要，而是一份完整的 product-backlog.md。它包含文档级信息、状态定义、正式条目和变更记录，可以直接作为胶囊系统的 Product Backlog 使用。

# 胶囊系统 Product Backlog（产品待办）

> **文档性质**：本文件记录尚未进入当前 SPEC 的候选需求、延期事项和产品想法。Backlog 中的内容不是版本承诺，不进入当前验收，也不应直接出现在 `tasks.md` 中。

## 文档信息

| 项目 | 内容 |
| --- | --- |
| 产品 | 胶囊系统 |
| 文档类型 | Product Backlog |
| 文档版本 | 1.0 |
| 当前状态 | Active |
| 建立日期 | 2026-08-10 |
| 最近更新 | 2026-08-11 |
| 维护原则 | 先记录候选，再经过讨论；准备实施时单独生成 SPEC |

## 状态定义

| 状态 | 含义 |
| --- | --- |
| Inbox | 刚记录的想法，尚未整理和判断 |
| Candidate | 值得继续研究，但范围和价值还没有确认 |
| Deferred | 已经讨论过，明确不进入当前版本 |
| Ready for Spec | 问题、范围和验收方向已经足够清楚，可以生成独立 SPEC |
| Rejected | 已决定不做，并保留不做的理由 |

## Backlog 条目

### PB-001：知识内化层

| 字段 | 内容 |
| --- | --- |
| 编号 | PB-001 |
| 名称 | 知识内化层 |
| 状态 | Deferred |
| 类型 | Future Capability |
| 目标版本 | 未确定 |
| 来源 | Hermes 教材“胶囊系统：让知识真正进入你的思考” |
| 关联需求 | [胶囊系统主流程需求简报](./capsule-system-requirements.md) |

**要解决的问题**

人类一生都在追求效率。而效率最高的资料索引方式永远不是来自于外部，而是来自于自己大脑或者说是自己的知识内含。比如“华北是平原还是丘陵“，这个判断直接从你脑子里出来的速度远大于你去查资料或者问 AI。但进入人的知识内含往往是一件很困难的事儿。你从小到大的知识体系，那可是你上了十几年学才逐步积累下来的。

胶囊系统可以让资料形成证据、进入索引，并持续演化主题页、概念页和综合页。但 Wiki 变得更完整，不等于这些知识已经进入用户自己的的知识体系，这依然是用户的外挂，不是用户的内含。传统的做法是通过刷题、反复背诵，加强式学习来刻意记忆。但内化的想做的是，让用户从工作、生活、娱乐中潜移默化的将知识吸纳进入自己的内含。这仍然需要单独设计。

**可能包含的能力**

- 在主题页中沉淀简短、可修正的“当前判断”。这个判断可制作成知识卡片，定期通过微信推送给用户。
- 维护全局主题索引，让用户看到自己的主要知识线及其关系。
- 在写作、方案、制作课程和问答任务等用户日常工作中主动调用已有知识页，并标记出处。
- 根据用户的职业、兴趣和使用习惯选择不同的内化方式。
- 区分值得长期内化的原理和判断，以及只需随用随查的工具性知识。

这些内容只是候选方向，不构成最终功能清单。

**暂缓原因**

内化高度依赖个人环境。有人需要主题索引，有人更重视当前判断，也有人只希望在写作时调用知识页。现在还没有足够的真实使用证据，无法确定哪一种方案值得成为产品功能。

把内化层同时放进当前 SPEC，会让本次范围失去边界，也会把尚未想清楚的方案提前变成实现承诺。

**进入 SPEC 的条件**

1. 胶囊系统主流程已经稳定运行，并积累了一段时间的真实使用记录。
2. 用户能够指出现有知识页在阅读、写作或判断中的具体缺口。
3. 至少有一种内化方案的用户动作、结果和边界可以被清楚描述。
4. 该方案能够形成独立、可验证的用户场景和成功标准。
5. 用户确认将该条目从 `Deferred` 调整为 `Ready for Spec`。

**后续动作**

满足进入条件后，为“知识内化层”单独执行 `$speckit-specify`。新 SPEC 应引用胶囊系统宪章和主流程产物。

## 变更记录

| 日期 | 条目 | 变更 |
| --- | --- | --- |
| 2026-08-10 | PB-001 | 创建“知识内化层”，状态设为 Deferred |
| 2026-08-11 | PB-001 | 补全文档级信息和标准条目字段，不改变需求范围 |

这份文件有两层结构。文档级信息负责说明它是什么、采用哪些状态；条目级字段负责回答某个想法为什么被记录、为什么现在不做，以及在什么条件下可以重新进入需求讨论。以后再增加 PB-002、PB-003，只需要继续复用条目结构，不必重复文档信息和状态定义。

2.5 把内化层移出当前需求

有了 Product Backlog，接下来就可以修改需求简报。这里不是简单删掉“内化”两个字，而是要把它从所有会形成当前承诺的位置移出去。

可以向 Codex 输入：

修改胶囊系统需求简报。第一版主流程到知识页演化为止，移除当前判断、全局主题索引和输出调用等内化层要求，并从当前验收条件中删除这些内容。把内化层作为 Deferred 条目写入正式的 Product Backlog，在需求简报的“本次不处理”中引用该条目。不要生成 SPEC。

修改以后，需求简报仍然可以提到内化层，但它只能出现在范围边界里：

## 本次不处理的事情

- 内化层不属于第一版 SPEC 的实现和验收范围。
- 当前判断、全局主题索引以及在写作和方案中主动调用知识页，暂存于 Product Backlog，后续确定方案后再单独生成 SPEC。

这和把内化层留在主流程里完全不同。前者是在声明边界，后者是在承诺交付。

2.6 Backlog 也不能替未来做决定

有了 Backlog 以后，另一个常见错误是提前为未来设计。

比如，我们可能会在当前方案里加很多暂时用不到的字段，只因为“以后内化层可能需要”；也可能要求当前主题页预留一套复杂结构，防止下一版不好扩展。听起来考虑得很周全，但这些设计依赖的仍然是一个没有确定的未来方案。

Backlog 的作用是保存问题，不是替未来做决定。

如果当前版本确实需要某个结构，就应该根据当前用户场景和验收条件把它写清楚。换一句话说，出现在 SPEC 里的条目都应该有用户场景和验收条件，不应该出现诸如为了某个版本预埋的需求，但却不给出验收条件。

比如内化层这里，你可能扩展了若干字段，但是却没有给出这些字段的验收标准和使用场景。这是不好的做法。

如果只是猜测未来也许会用到，就先留在 Backlog。等内化层真正进入 Ready for Spec，再根据那时的使用情况重新整理需求。

SDD 不是要求我们一次想完所有版本。它只是要求每一次进入开发的需求都有清楚边界。

2.7 从 Backlog 进入下一份 SPEC

以后真正准备做内化层时，不应该直接把 PB-001 复制进 tasks.md。Backlog 里的“可能方向”还没有经过需求确认，直接变成任务，等于跳过了 SDD 最重要的一步。

更合适的过程是：

换句话说，新的需求，一样要经历一份完整的：

需求-> SPEC->Plan->Tasks->Implements 阶段

2.8 现在这份需求简报清楚了

经过这次调整，胶囊系统第一版的边界变得清楚了。当前版本负责接收资料、固定证据、管理索引、理解关系并演化知识页。内化层仍然是胶囊系统的长期方向，但它不参与本次实现，也不参与本次验收。

这就是审查需求简报的价值。很多范围问题不是 Agent 写错了，而是我们在描述完整愿景时，没有区分“最终想要什么”和“这一次承诺做什么”。Product Backlog 刚好接住了两者之间的那一部分：它值得保留，但还没有准备好进入开发。

现在还不能急着生成 SPEC。内化层只是我们发现的第一个问题，需求简报里的其他范围和判断还要继续检查。这里就不再一一举例了，同学们应该自己去反复阅读需求简报，对齐做出增删改查。

2.9 大胆的删除

现在的 AI 很容易把同一个内容反复讲几遍。尤其是在长对话和长文档里，模型未必能稳定判断前面已经写过什么，于是同一条边界会在目标、主流程、用户结果和验收条件里反复出现；同一个判断也会换几种说法重新解释。

文档不会因为字多就变得更好。读者需要在多个地方比对同一个意思，真正的需求反而会变得模糊。我们在审计 AI 产出的文稿、同时教 AI 写下一版文稿时，不能只检查有没有遗漏，还要专门检查文档是不是很啰嗦。

所以这里你需要保持一种强烈的意识：该删就删，而且可以大刀阔斧地删。不要这也舍不得那也舍不得。

写作圈有句流传很广的话：Kill your darlings，杀掉你的宝贝。作家斯蒂芬·金在《写作这回事》里反复强调过这个理念——写完初稿，要敢于删掉自己最得意的句子；越是舍不得，越要警惕它是不是只是"自我感动"。写文章是这样，写需求文档也一样。那些"写得很好、但前面已经有类似表达"的段落，就是我们的 darlings：作者舍不得删，读者和模型却要为此多读一遍。

如果一段文字没有增加新的边界、动作、条件或验收信息，就不要因为它写得完整而继续保留。

可以用三个问题判断一段话是否应该留下：

1. 这段文字新增了什么？
2. 前面是否已经表达过相同的意思？
3. 删除以后，读者或 Agent 是否会失去一个必须执行或必须验收的约束？

如果第一个问题答不上来，第二个问题的答案是“已经说过”，而第三个问题的答案是“不会”，那就应该删除。文档越长不等于表达越清晰。对模型来说，重复文字还会稀释真正的约束，让它在多个近似表述之间自行猜测。

需求说明只需要用最精炼的语言把问题、范围和验收条件讲清楚。写得更多，有时反而是在给模型增加噪声。审计 AI 的工作，不是替它把每个意思再解释一遍，而是把真正需要执行的内容留下来。

2.10 ■ 学点英语