Build Club 第二周:PRD 并未捕获所有内容
Source: Dev.to

本周构建
上周我发帖说我没有代码,只有让代码成为可能的工作:PRD、提示规范、架构文档以及 Kiro 的构建简报。我本以为本周所有决策都已经预先做好。
于是我开始动手构建。
- 到 Block 2 时,真实的测试暴露出模型使用的一句话,法院工作人员根本不会说。“Strip identifiers”(去除标识符)对开发者来说听起来合理,但对法院文员来说既晦涩又技术化——在培训中很可能会被跳过。严格来说这不是 bug,也不在 PRD 中,但却很显眼。
- 到 Block 3 时,我开始标记对比问题、帮助文本的微文案以及需要验证的禁用状态。这些都不在原始范围内,也不是阻止构建的关键问题,但它们是真实存在的。
- 到 Block 4 时,我在进行活跃构建的同时脑中记着一长串打磨项。晚上 11 点,我问 Claude 它是否已经把所有事情都跟踪了。答案很诚实:它并没有,以任何可靠的方式都没有。这正是我在自己的构建简报中指出的“我会记住它”的信任问题,而我却让它悄悄出现了。
待办清单(Punchlist)

Punchlist 不是 PRD。PRD 说明要构建什么;Punchlist 捕获在实际构建时出现的所有细节。它们的职责不同,需要存放在不同的文档中。
到本周结束时,我的 Punchlist 已经增长到:
- 14 条打磨项
- 8 条推迟到 v2 的项目
- 4 条部署前的清理工作
- 4 条经验教训条目
其中一些是潜在的范围蔓延——“我们应该加这个,只要一个小时”这种想法会把四周的构建拖成八周。另一些是真正的 bug,PRD 无法预见,因为我还没有把足够的产品交付出来以发现它们。还有一些是我一看到自己用真实法院员工的口吻读回来就知道不对的语言。
我会怎样做不同的事
在第 1 天就开始建立 Punchlist,和 PRD 并行。不要把它作为 PRD 的一个章节(它们的职责不同),而是作为一个兄弟文档,随时准备使用。把空的 Punchlist 当作一个功能,而不是占位符。
收获
- PRD 锁定范围;Punchlist 保存 PRD 还未看到的所有内容。
- 两份文档都必不可少。
- 关键不在于写出完美的 PRD,而在于立刻知道一个想法该放在哪份文档里并立即放进去,而不是靠记忆。
下周:打磨与部署
第 三周的重点是打磨和部署。正在进行的 Punchlist 将指引我们完成:
- 延迟加载的 Loading‑state 体验
- PDF 中的品牌横幅
- 移动端响应式布局
- 使用 AWS Amplify 部署到线上 URL
与 Build Club in the Women in AI Accelerator 同步构建。感谢 Annie Liao 与 Caroline Ciaramitaro 运营的深思熟虑、慷慨的社区。