63 lines
2.4 KiB
Markdown
63 lines
2.4 KiB
Markdown
---
|
||
name: solution-whitepaper
|
||
version: 1.0.0
|
||
description: |
|
||
编写解释行业问题、技术原理、参考架构、实现方法、测试证据和适用边界的产品或
|
||
解决方案白皮书。用于技术传播和决策评估；不编制客户项目计划，也不把宣传口号
|
||
当作技术论证。
|
||
allowed-tools:
|
||
- Read
|
||
- Grep
|
||
- Glob
|
||
- Execute
|
||
compatibility: Markdown；可配合 longdoc-docx 导出 Word（PDF 仅用于核验）
|
||
---
|
||
|
||
# 解决方案白皮书
|
||
|
||
## 必要输入
|
||
|
||
- 白皮书主题、目标读者、研究问题和发布范围。
|
||
- 产品事实、技术来源、测试报告、标准和第三方参考。
|
||
- 可公开的架构图、数据、案例和限制。
|
||
- 引用格式、目标篇幅和评审要求。
|
||
|
||
## 论证结构
|
||
|
||
1. 明确问题范围，不用泛化行业背景凑篇幅。
|
||
2. 定义术语、对象和评价标准。
|
||
3. 解释方法、原理和参考架构。
|
||
4. 用产品实现或参考流程说明方法如何落地。
|
||
5. 给出测试方法、条件、结果和不确定性。
|
||
6. 说明安全、部署、治理和人工复核边界。
|
||
7. 总结适用场景、限制和后续研究，不做空洞升华。
|
||
|
||
使用 `templates/solution-whitepaper.md` 建立章节。
|
||
|
||
## 证据规则
|
||
|
||
- 标准、论文、第三方观点和产品事实分开引用。
|
||
- 指标必须说明样本、版本、环境、周期和计算方法。
|
||
- 实测结果、设计目标和规划能力使用不同标签。
|
||
- 无法访问原始来源时标记二手来源，不把摘要转述成原始结论。
|
||
- 第三方图表必须检查许可并保留出处。
|
||
- 参考文献编号、正文引用和图表来源必须一一对应。
|
||
|
||
## 写作规则
|
||
|
||
- 标题说明对象或结论范围，不写“我们如何理解”“结果说明了什么”。
|
||
- 先给定义和条件，再给结论。
|
||
- 架构章节解释边界与数据流，不罗列产品菜单。
|
||
- 限制章节必须保留，不能在营销审校时被删除。
|
||
- 技术白皮书可以有观点，但必须区分事实、推断和建议。
|
||
|
||
## 导出
|
||
|
||
如已安装 `deai-writing`，在最终通读前扫描中文套路表达；如已安装
|
||
`longdoc-docx`，用其生成 DOCX 并借助临时 PDF 执行高分辨率视觉复核。
|
||
|
||
## 完成标准
|
||
|
||
研究问题得到回答；术语统一；关键结论有来源；测试可复核；架构图与正文一致；
|
||
限制、依赖和适用范围完整；参考文献无缺失、重复或无法定位条目。
|