需求定义：先写清要解决的问题
这份简报用于内部评估pg官方精品项目相关方案，不做宣传口径的转述，只回答一个问题：在当前约束下，哪套组合最容易被团队长期维护。开始比较之前，先把需求写成可勾选的条目，否则后面的对比会变成偏好之争。
- 用一句话写明要解决的场景，例如入口信息分散、资源查找路径不清、动态更新无人跟踪。
- 列出使用者角色：谁每天用、谁每周看、谁只在交接时查。
- 写明现有做法与卡点，卡点要能指向具体动作，而不是“体验不好”。
- 标注硬约束：可用时间、维护人力、已有工具链、合规与权限要求。
- 确认哪些需求本期必须解决，哪些可以留到下一轮。
需求条目写完后，请让至少一位非提出者复述一遍，复述不一致的地方就是后续争议的来源。
必备项与加分项的分界
把清单分成两栏：不满足就淘汰的必备项，以及满足更好但不影响结论的加分项。分界不清是选型反复的常见原因。 pg官方指南
- 必备：信息入口有明确边界，能说清哪些内容属于该范围。
- 必备：资源清单可核对来源与更新时间，过期内容有处理方式。
- 必备：动态跟踪有固定节奏与责任人，不依赖个人记忆。
- 必备：交接时能凭文档复原判断依据，而不是靠口头说明。
- 加分：检索更顺手、展示更集中、提醒更及时。
- 加分：历史记录可回溯，便于复盘判断是否仍然成立。
- 加分：与现有工具链的衔接更少人工搬运。
若某个加分项被反复提及，先问它是否其实属于必备项；反之，若必备项长期无人执行，应重新评估它是否真的必要。
评估问题：向候选方案逐条提问
提问的目的不是让对方展示，而是检验在约束条件下能否持续运转。以下问题可直接用于内部讨论或方案说明会。
- 这套方案的第一周与第三个月分别由谁维护？
- 信息更新由谁触发，延迟多久算失效？
- 出现错误信息时，纠正路径是什么，谁有权修改？
- 新成员上手需要哪些前置说明，缺少时会怎样？
- 资源清单与动态跟踪是否共用同一套命名与分类规则？
- 当人力减少一半时，哪些环节会先崩，是否有降级方案？
- 如何判断这套方案已经不再适用，退出成本有多大？
把回答写成短句记录，保留提问日期，便于后续对照变化。
取舍：常见组合与代价
没有全优组合，只有代价可接受的组合。下面按组合方式列出典型取舍，供内部对照。
- 集中式入口：查找路径短，但对维护者的持续投入要求高。
- 分散式来源：各自维护灵活，但核对成本转移到使用者身上。
- 高频动态跟踪：信号及时，但噪声与误读风险同步上升。
- 低频定期核对：稳定省力，但异常发现滞后。
- 严格命名与分类：长期可维护，前期需要统一口径的沟通成本。
- 宽松命名：起步快，交接与检索时反复解释。
选择时先确认哪类代价团队能长期承担，再讨论具体工具或形式。
决策框架与下一步
把前面的勾选结果汇总成一页纸，用于内部决策而不是对外展示。框架只做三件事：排除、排序、留出复核点。
- 先按必备项排除，不满足者不再进入排序。
- 在剩余方案中按加分项排序，并写明排序理由。
- 为每条理由标注证据来源与记录时间。
- 设定复核点：什么信号出现时重新评估。
- 补齐需求定义中缺失的角色与约束。
- 用评估问题逐条记录候选方案的回答。
- 写出取舍说明，明确团队愿意承担的代价。
- 按决策框架形成一页结论，并约定下次复核时间。
清单的价值在于可被勾选与复查，而不是一次写完就归档。