用途：在需要起草、修订或评审软件设计文档时使用，把设计文档当作解决问题、建立共识的工具，而不是实现手册。
主要能力：判断是否值得写设计文档——当设计含糊、复杂、有争议、跨职能、需要资深评审或具有组织记忆价值时撰写；方案显而易见且无实质权衡时，改用简短说明、issue 或直接实现；小而并不显然的改动可用迷你设计文档。围绕决策与权衡起草：先写客观背景与范围，再以明确边界定义目标与非目标，按总览到细节呈现所选设计，解释其在已知约束下为何最满足目标，并比较现实可行的备选方案及未选原因。在相关时覆盖安全、隐私、可靠性、可观测性、迁移与运维等横切关注点。保持可读性，面向需要理解决策的忙碌评审者，链接需求、原型、schema、代码或既有文档而非整段复制；仅当有助于厘清权衡时才放图表或紧凑的 API/数据草图；除非解释新算法，避免大段代码。管理生命周期：标注状态（draft、in review、accepted、implementing、superseded 或 archived），先建议最小有效评审组，设计稳定后再扩大评审；系统未发布前若实现暴露错误假设或需求变化则更新文档，文档与现实分歧时链接修订或后续文档。
使用方式：起草或评审实质性设计文档前，先阅读 references/design-doc-guidance.md，其中包含源自文章的模板、决策清单、章节指引与评审标准。仅在缺失信息会实质改变目标、非目标或权衡时提聚焦问题；信息不全而继续时，明确写出假设。
适用场景：跨职能、需资深评审或需沉淀组织记忆的软件设计工作。限制：资料未提供具体平台支持、收费方式或安装命令等信息，暂未提供。