.projectstore

.projectstore / 方法 / 2

这一套，行业早就发明了。
智能体让它不再昂贵。

ADR、评审、待办池、验收标准、从目标到代码的关联。成熟的工程团队这样工作已有二十年。这些都不是 ProjectStore 发明的。

每个部分的来源
  1. 1969RFC：决策被写下来并编号，然后公开讨论。
  2. 1992DO-178B：在航空电子领域，每条需求都必须关联到代码和测试。
  3. 1995Scrum：工作成为待办列表，有序且可见。
  4. 1999XP：用户故事，以及说明何时算完成的验收标准。
  5. 2007用于软件开发的看板：显示哪些工作正在进行。
  6. 2011ADR，Michael Nygard：每个架构决策一个简短的文件。
  7. 现在编程智能体：每一步只需几分钟。没有这些工件，每个会话都从空白开始。
工件的作用

一个项目，许多双手。所有人站在同一块地基上。

ADR 说明决定了什么、否决了什么。spec 说明它必须如何工作。epic 及其 story 说明在构建什么，每一部分何时算完成。看板显示正在进行的事。

有了这些，明天加入的工程师、另一个团队的评审者、全新会话里的智能体，都从第一个人所知道的出发。这就是构建大型系统的团队数十年来一直维护这些文档的原因。

昂贵的部分

流程一直都有价值。昂贵的是每一步都要由人来执行。

这套流程是有效的。项目结束后，它留下的文档是公司最有价值的资产：系统为什么这样构建，什么才算完成，每个功能在代码的什么位置。但靠人手工推进时，它很慢。写一份 ADR 要一个下午，等评审要一周。文档跟不上代码。看板和实际情况对不上。于是团队在流程上能省就省，“敏捷”成了什么都不写的借口。

缺少这些工件时，人和智能体的情形一样：已定的问题重新冒出来，没人说得清代码为什么是这样，每个新人都从猜测开始。

智能体正好相反。写一份 ADR、把 epic 拆成 story、对照标准检查 diff，智能体只需几分钟，而不是几天。智能体缺的，恰恰是人天然就有的东西：会话之间的记忆、与同事共享的上下文、从目标到代码的关联。每个新会话都从空白开始，把早已定下的事再决定一遍。

人的流程+智能体的速度=ProjectStore

ProjectStore 把两者结合起来。智能体的速度第一次让这套老流程的成本降了下来。流程留下的文档以文件形式放在代码旁边，给了智能体从未有过的东西：项目的上下文，向上连到目标，向下连到代码。每一步都按规则由另一个没有参与写草稿的智能体评审。速度有了记忆，记忆有了检查。

六个阶段

六个阶段，手工做与用 ProjectStore 做。

阶段实践及其年代由人执行在 ProjectStore 中
决策为什么ADR（架构决策记录），Michael Nygard，2011 年。在此之前是架构委员会和设计评审。写要一个下午，在评审队列里排一周。被否决的备选方案只留在某个人的脑子里。智能体一分钟写出草稿，独立的 critic 找出其中的弱点，再由你批准。结果是一个带日期的文件，被否决的方案也记在里面。
契约怎么做Spec、设计文档、RFC。RFC 自 1969 年起就有编号；设计文档在大公司是标配。写要一周，到发布时已经过时。没人检查代码是否仍与之相符。spec 用带编号的规则写明预期行为。它的检查项适用于它覆盖的每个 story。spec 还是草稿时，story 无法关闭。
待办池做什么产品待办列表，Scrum，1995 年。用户故事，XP，1999 年。用于软件开发的看板，2007 年。待办池梳理会。看板靠手工维护，不出一周就与现实脱节。每个 story 文件自己记录状态。看板、索引和关系图都由这些文件生成。一旦对不上，一条命令就能重建。
计划改哪里技术设计、影响分析。技术负责人判断改动会落在现有代码的哪个位置。早先的功能是怎样落到代码里的，这些知识只存在于技术负责人的脑子里。而他正在休假。planner 查看早先的 epic 落在代码的哪些位置，指出改动应该放在哪里、复用什么。计划写进 story。
验收证明验收标准、完成的定义（Definition of Done）。XP 和 Scrum，2000 年代初。冲刺末尾的一轮 QA。“完成”靠宣布；标准只做抽查。reviewer 拿 diff 对照每一条标准，并要求证据：一个测试、一条运行过的命令、一行代码。没有证据，就不能关闭。
可追溯性关联需求可追溯性。自 DO-178B（1992 年）起在航空电子领域是强制要求，在医疗软件中也是。一张“需求 → 代码 → 测试”的 Excel 矩阵，第二个版本发布后就再没人更新。每个 story 向上关联到它的 epic、ADR 和 spec，向下关联到它的代码。证据写在每条验收标准下方。关系图和代码地图是自动生成的，没人需要手工维护。
链条

智能体顺带获得的关联：从目标到证明

  1. 目标EpicCHECKOUT · 为什么要做这件事epic:
  2. 为什么ADR决策及被否决的方案adr: [ ]
  3. 怎么做Spec预期行为specs: [ ]
  4. 做什么Story计划与验收标准code_refs:
  5. 在哪里代码src/billing/cards/ · 早先的 epic 已经在这里— 证据：
  6. 证明证据tests/cards.test.ts:58 · 每条标准一份

关联写在每个文件的文件头里，证据则是每条验收标准下方的一行。这些都由智能体边工作边填写。关系图展示每份文档与哪些内容相连。代码地图说明每个 epic 的代码在哪里。新的会话、新的模型或新的同事，都从这条链开始，而不是从零开始。

直接对 Claude Code 说：
Install the projectstore plugin from https://github.com/SmartAndPoint/ProjectStore and set it up for this project.

工作原理 →一个 vault，多人协作 →安装 →