HDRP 不想做“把新闻再转述一遍”的站点。我们更关心一条信息进入工程现场之后，会不会改变板卡选型、系统预算、验证顺序，或者至少让团队少走一轮弯路。
Table of contents
Open Table of contents
先看它是不是工程问题
一条内容值不值得进入讨论区，第一判断不是它有多热，而是它会不会改变工程决策。最常见的高价值信号有三类：
- 让系统边界重画，例如内存层级、互连、散热或供电方案被迫重做。
- 让验证顺序改变，例如原本后置的量化、数据搬运、时序收敛必须前置。
- 让成本结构改变，例如 BOM、开发周期、工具链投入出现明显拐点。
如果一条消息只是在重复厂商口号，没有把变化映射到这些具体决策上，它最多算资讯，不算讨论。
再看它有没有信息密度
HDRP 讨论稿至少要回答三个问题：
- 新信号到底是什么。
- 它会影响哪一层设计决策。
- 团队下一步应该验证什么。
只有“性能更高”“生态更强”“成本更低”这种口号，信息密度是不够的。真正有价值的讨论，会把结论落到带宽、延迟、热设计功耗、驱动成熟度、可重复性这些能被复查的维度上。
我们默认的讨论模板
一篇 HDRP 讨论稿，至少要包含下面四块内容：
- 背景信号：新闻、论文、开源项目或真实项目现场发生了什么。
- 设计影响：哪些模块、接口、工序、资源预算会被改写。
- 验证建议：团队应该先测什么，后测什么，避免什么伪结论。
- 未决问题：当前信息还缺什么，读者应该继续追踪哪里。
这套结构的好处是，读者看完之后可以直接拿去安排下一次评审或实验，而不是只得到一个模糊判断。
什么内容不进入讨论区
下面这些内容更适合留在快讯区或干脆不发：
- 只有融资、发布会和市场口号，没有技术细节。
- 只有 benchmark 截图，没有测试方法、输入条件和硬件约束。
- 单纯复制文档或 README，没有新的工程判断。
- 把通用软件经验硬套到硬件 AI 场景，没有考虑 I/O、功耗和验证成本。
编辑结论
HDRP 的讨论区要服务于“下一步做什么”。如果一条内容不能帮助读者更快做出设计判断、验证判断或资源判断，那它就不应该占用讨论入口。我们宁可少发，也不把讨论区做成模板站点的延伸页面。