goodbuddy/resources/skills/solution-whitepaper/SKILL.md

name, version, description, allowed-tools, compatibility

name	version	description	allowed-tools	compatibility
solution-whitepaper	1.0.0	编写解释行业问题、技术原理、参考架构、实现方法、测试证据和适用边界的产品或 解决方案白皮书。用于技术传播和决策评估；不编制客户项目计划，也不把宣传口号 当作技术论证。	Read Grep Glob Execute	Markdown；可配合 longdoc-docx 导出 Word（PDF 仅用于核验）

解决方案白皮书

必要输入

• 白皮书主题、目标读者、研究问题和发布范围。
• 产品事实、技术来源、测试报告、标准和第三方参考。
• 可公开的架构图、数据、案例和限制。
• 引用格式、目标篇幅和评审要求。

论证结构

1. 明确问题范围，不用泛化行业背景凑篇幅。
2. 定义术语、对象和评价标准。
3. 解释方法、原理和参考架构。
4. 用产品实现或参考流程说明方法如何落地。
5. 给出测试方法、条件、结果和不确定性。
6. 说明安全、部署、治理和人工复核边界。
7. 总结适用场景、限制和后续研究，不做空洞升华。

使用 templates/solution-whitepaper.md 建立章节。

证据规则

• 标准、论文、第三方观点和产品事实分开引用。
• 指标必须说明样本、版本、环境、周期和计算方法。
• 实测结果、设计目标和规划能力使用不同标签。
• 无法访问原始来源时标记二手来源，不把摘要转述成原始结论。
• 第三方图表必须检查许可并保留出处。
• 参考文献编号、正文引用和图表来源必须一一对应。

写作规则

• 标题说明对象或结论范围，不写“我们如何理解”“结果说明了什么”。
• 先给定义和条件，再给结论。
• 架构章节解释边界与数据流，不罗列产品菜单。
• 限制章节必须保留，不能在营销审校时被删除。
• 技术白皮书可以有观点，但必须区分事实、推断和建议。

导出

如已安装 deai-writing，在最终通读前扫描中文套路表达；如已安装 longdoc-docx，用其生成 DOCX 并借助临时 PDF 执行高分辨率视觉复核。

完成标准

研究问题得到回答；术语统一；关键结论有来源；测试可复核；架构图与正文一致； 限制、依赖和适用范围完整；参考文献无缺失、重复或无法定位条目。