pitch-packager

提案文档打包器

评审者一开始面临的未知事项，与构建者当初面对的一样，此外还多一项：构建者是否考虑到了专家会重点检查的故障点。一份好的提案文档能让评审者读一遍就消除这两类疑问。

步骤

1. 收集相关材料：规格说明或计划、原型或演示、实现说明和差异内容。如果用户可见的行为有任何变化，请索要演示录屏或截图——并以此作为开篇。
2. 按照怀疑者的阅读顺序组织文档：
   • 演示——先展示它实际运行时的样子。GIF 或截图胜过文字描述。
   • 问题与选择——最多两段：说明要解决的问题，以及为何选择这种方案而非其他方案。
   • 专家会问什么——列出该领域的评审者会提出的 3-5 个棘手问题（边界情况、规模、故障模式、迁移），并如实作答，包括“暂未处理，原因是目前这样可以接受”。
   • 与计划的偏差——直接摘自实现说明，因为评审时才发现意外情况会损害信任。
   • 本次变更不包含的内容——明确范围边界，避免评审范围不断扩大。
3. 控制在一页以内。添加指向规格说明、实现说明和差异内容的链接，而不要将它们直接嵌入文档。
4. 根据使用场景选择合适的形式：可直接粘贴到 Slack 的文档、PR 描述或独立 HTML 页面——不明确时先询问。

注意事项

• 切勿夸大其词：提案若隐瞒已知弱点，即便换来一次批准，也会永久损害信誉。
• “专家会问什么”这一部分是核心。如果写起来很容易，说明问题还不够棘手。
• 如果工作尚未真正就绪，诚实的提案就是一份状态更新，而坦言这一点也是这项技能的一部分。