描述：为任何技术、产品、平台、系统、协议、研究项目、AI/ML系统、软件架构、基础设施平台、网络安全解决方案、硬件系统或新兴技术撰写可信且结构良好的技术白皮书。
# 技术白皮书撰写者
## 为什么需要这项技能
大多数AI生成的白皮书读起来像营销文档：模糊的声明、过多的形容词、将功能列表呈现为创新、无支持的性能数字、通用的架构图，以及用路线图替代技术证据。
一份强有力的白皮书则相反，它解释**为什么问题存在、提出的系统做什么、如何工作、为什么设计如此构建、它做了哪些假设、在正常和故障条件下如何表现，以及设计在哪些方面仍有局限。**
目标是让文档读起来像**工程和技术研究**，而不是销售手册。
白皮书应能让有技术能力的读者回答：
1. 正在解决什么问题？
2. 为什么现有方法失败或变得不足？
3. 提出了什么？
4. 提出的系统实际如何工作？
5. 主要组件是什么，它们如何交互？
6. 设计做了哪些假设？
7. 正常操作期间会发生什么？
8. 出错时会发生什么？
9. 什么证据支持技术声明？
10. 有哪些局限和未解决的风险？
11. 这与现有方法有何不同？
12. 实现、评估或部署它需要什么？
写作应优先考虑**清晰性、技术精确性、可追溯性和知识诚实**，而非听起来令人印象深刻的语言。
---
## 步骤1 — 写作前收集输入
在核心信息可用之前，不要开始起草完整白皮书。如果关键信息缺失，请询问（见步骤20），而不是编造。
**1. 问题。** 用一句清晰的话陈述，然后描述一个具体场景，展示没有提议的解决方案时会失败什么。
- 避免：*“行业需要一种革命性的新方法。”*
- 优先：*“当前系统要求每个应用独立集成多个模型提供商，导致集成逻辑重复、可观测性不一致以及提供商切换困难。”*
**2. 项目类型。** 识别主要类别（以及任何重要的次要类别），不要强行将项目归入不适当的类别。示例：AI/ML系统、LLM应用、AI基础设施、数据平台、开发者工具、云/分布式系统、网络安全系统、网络系统、数据库/存储系统、硬件/嵌入式系统、机器人系统、科学/研究系统、企业架构、SaaS平台、API/中间件、代理系统、金融科技、医疗科技、工业或能源科技、协议/标准系统或其他。
**3. 核心机制。** 描述系统内部实际发生什么——输入、处理、状态、转换、决策、输出、反馈循环、外部依赖、故障路径、系统边界。不是功能列表。
- 避免：*“该平台提供智能路由、安全、可观测性和可扩展性。”*
- 优先：*“传入请求根据模型、延迟、成本和策略要求进行分类。路由层选择一个符合条件的提供商，执行请求，记录遥测数据，并在所选提供商失败时应用重试或回退逻辑。”*
**4. 系统边界。** 系统内部与外部是什么？哪些组件是受控的与依赖的？数据在哪里进入和离开？信任在哪里开始和结束？
**5. 参与者和利益相关者。** 仅包括与系统相关的参与者（例如，最终用户、开发者、管理员、操作员、服务、模型、代理、数据/基础设施提供商、验证者、攻击者、外部系统）。对于每个重要参与者：他们做什么、需要什么、控制什么、能观察到什么，以及哪些激励或约束塑造他们的行为。
**6. 资源、经济或代币——仅在适用时。** 如果系统有代币、积分、使用单位、订阅、费用、激励、奖励、惩罚、计算分配或配额，解释其*机械*目的。永远不要仅仅因为白皮书“预期”有代币经济学或金融机制就引入它们。如果没有经济机制，省略此部分。
**7. 已知局限和风险。** 什么可能失败、退化或仍未解决——可扩展性限制、延迟约束、依赖风险、模型限制、数据质量问题、安全假设、操作复杂性、成本约束、硬件限制、隐私问题、监管不确定性、可用性依赖、集成复杂性。明确陈述这些；不要隐藏它们。
---
## 步骤2 — 选择白皮书结构
不要将每个项目强行套入相同的模板。默认技术主线：
1. 摘要
2. 引言
3. 问题与动机
4. 现有方法
5. 设计目标与非目标
6. 提议的架构
7. 核心机制
8. 系统工作流
9. 技术设计
10. 安全/安全/可靠性模型
11. 性能与可扩展性
12. 实现考虑
13. 工作示例
14. 评估/证据
15. 局限与开放问题
16. 未来工作
17. 结论
18. 参考文献
并非每个部分都是强制性的——只使用能实质性提升理解的内容：
- 简单的软件架构可以跳过繁重的数学分析。
- AI研究系统可能需要实验和评估方法。
- 网络安全系统可能需要详细的威胁模型。
- 硬件系统可能需要物理约束和基准测试。
- 分布式系统可能需要一致性、容错和故障分析。
- 商业SaaS平台可能需要部署/运营架构而非形式化证明。
---
## 步骤3 — 建立技术差异
如果项目基于或扩展现有技术，明确追踪：
> 之前存在什么 → 仍存在什么局限 → 此设计改变了什么 → 为什么该改变重要。
- 避免：*“这是世界上第一个革命性架构。”*
- 优先：*“现有方法A提供X但需要Y。方法B消除了Y但引入了Z。提议的架构将X与不同的执行模型相结合，消除了Y，同时在Z上接受明确的权衡。”*
---
## 步骤4 — 从最小模型构建机制
逐步引入复杂性，而不是一次性呈现完整架构：
1. **直觉** — 用简单语言表达想法。
2. **最小模型** — 能解决问题的最小系统。
3. **架构** — 主要组件。
4. **数据/请求流** — 信息如何在系统中移动。
5. **技术机制** — 算法、协议、模型、API、状态转换、策略。
6. **故障行为** — 当组件失败或假设被打破时会发生什么。
7. **优化** — 性能、可扩展性、缓存、批处理、路由、并行性。
---
## 步骤5 — 应用证据纪律
诸如*更快、更便宜、更安全、可扩展、可靠、准确、更低延迟、更高*等声明吞吐量、减少幻觉、提升效率* 绝不能在缺乏支持的情况下被断言。
在可能的情况下，提供：基准测试结果、测量数据、公式、阈值、实验结果、架构推理、引用、假设或比较方法。
- 避免：*"该架构提供极低的延迟。"*
- 优先：*"在评估配置下，路由层在 Y 工作负载下增加 X 毫秒的中位处理开销。"*
如果某个数字无法获得，请说明。**绝不要捏造测量数据。**
---
## 第 6 步 — 分析每个重要参与者
对每个参与者：职责、输入、输出、权限、依赖关系、激励、约束、故障模式以及错误行为的后果。示例集合（根据实际项目调整）：
- **用户** — 提交请求并接收响应。
- **应用** — 对请求进行身份验证并调用平台 API。
- **模型提供方** — 处理推理请求。
- **网关** — 应用路由、策略、重试和可观测性逻辑。
- **运维人员** — 配置策略并监控系统健康状况。
---
## 第 7 步 — 定义威胁、故障或风险模型
根据项目情况，分析相关风险：恶意用户、被攻陷的组件、未授权访问、数据泄露、模型操纵、提示注入、供应链攻击、拒绝服务、数据损坏、错误输出、基础设施/依赖故障、网络分区、硬件故障、运维人员错误、配置错误、对抗性输入、经济攻击、隐私侵犯。
对每一个重大威胁：
> 威胁 → 攻击/故障机制 → 影响 → 缓解措施 → 剩余风险
- 避免：*"该系统高度安全。"*
- 优先：解释**针对什么**安全、**在哪些假设下**安全、**采用哪些控制措施**。
---
## 第 8 步 — 包含一个完整示例
每一份实质性白皮书都需要至少一个具体的端到端示例——交易生命周期、API 请求、推理请求、数据管道、用户工作流、状态转换、攻击场景、故障场景或数值计算。在有帮助的地方包含真实数字。
示例形态：
> 1. 客户端提交请求。
> 2. 网关验证策略。
> 3. 路由器选择提供方。
> 4. 提供方执行推理。
> 5. 响应通过验证。
> 6. 记录遥测数据。
> 7. 客户端接收响应。
---
## 第 9 步 — 清晰地解释架构
架构描述应回答：主要组件有哪些？每个组件做什么？它们如何连接？哪些协议/接口将它们连接起来？状态存储在哪里？计算在哪里发生？决策在哪里做出？安全边界在哪里？故障可能在哪里发生？
仅在反映现实的地方使用分层结构，例如：
```text
用户 / 客户端层
↓
API / 接口层
↓
应用 / 编排层
↓
核心处理层
↓
数据 / 模型 / 存储层
↓
基础设施层
```
不要仅为视觉对称而添加层级。
---
## 第 10 步 — 恰当地处理数学
当方程能阐明机制时使用方程：优化目标、概率模型、评分函数、成本/延迟/吞吐量计算、容量规划、密码学公式、机器学习目标、资源分配、经济模型、可靠性计算。始终用通俗语言解释每个方程。绝不要仅为外观而添加数学。
---
## 第 11 步 — 恰当地处理 AI/ML 系统
清晰区分模型架构、训练、微调、推理、检索、编排、评估、安全、监控、数据管道和人在回路流程。
明确地框定管道：
> 输入 → 处理 → 模型 / 检索 / 工具使用 → 验证 → 输出
在相关处，涵盖：模型选择、训练方法、数据集假设、上下文管理、检索策略、评估方法、幻觉缓解、护栏、延迟、推理成本、可观测性和模型故障模式。
避免使用"智能"、"认知"或"类人"等模糊术语，除非有技术定义。
---
## 第 12 步 — 与现有方法进行比较
在相关处，基于具体维度进行比较：
| 维度 | 现有方法 | 提出的方法 |
|---|---|---|
| 架构 | ... | ... |
| 延迟 | ... | ... |
| 可扩展性 | ... | ... |
| 成本 | ... | ... |
| 安全性 | ... | ... |
| 灵活性 | ... | ... |
| 运维复杂度 | ... | ... |
每一行都需要有可辩护的依据——不要仅为看起来完整而构建表格。
---
## 第 13 步 — 讨论权衡
每一个有意义的架构都有权衡。明确讨论相关权衡：性能与成本、灵活性与复杂度、安全性与可用性、一致性与可用性、延迟与准确性、集中化与去中心化、自动化与人工控制、计算与内存、精确率与召回率、隐私与可观测性。
绝不要声称该设计消除了权衡——解释**选择了哪些权衡，以及为什么**。
---
## 第 14 步 — 将当前能力与未来工作分开
不要将路线图项目作为系统当前可用的证据来呈现。区分：
- **当前设计** — 今天已存在或在技术上已明确规定的。
- **实验性 / 已验证** — 已实现并测试的。
- **提议的扩展** — 以后可能构建的。
- **开放研究问题** — 仍未解决的。
路线图不是技术可行性的证明。
---
## 第 15 步 — 反模式过滤器
在呈现草稿之前，扫描并重写：
**营销语言** — 革命性的、突破性的、颠覆性的、下一代的、世界级的、前所未有的、高度智能的、无限可扩展的、军用级的、企业级的——除非有技术定义和支持。
**无支持的声明** — "快 10 倍"、"99.99% 可靠"、"100% 安全"、"零幻觉"、"完全自主"、"无限可扩展性"——除非存在证据。
**功能堆砌** — 功能列表不是架构。
**流行词替换** — "AI + 区块链 + 云 + 量子 + 自主代理"不是机制。
**路线图即证明** — 未来计划不能证明当前可行性。
**无目的的代币经济学** — 不要发明经济机制。
**无比较的新颖性** — 不要在没有解释前人的情况下声称创新。
**无威胁建模的安全性** — 不要在没有指明威胁和缓解措施的情况下声称安全。
**无数据流的架构** — 仅凭组件无法解释一个系统。
**缺失局限性** — 每一个严肃的设计都有局限性；请说明它们。
---
## 第 16 步 — 外部研究与引用
使用外部信息时：引用每一项外部技术声明，优先使用一手和权威来源，科学声明引用研究论文，技术规格引用官方文档，标准引用标准机构，供应商相关引用供应商文具体行为。
使用行内编号引用：
> Transformer 架构使用自注意力来建模 token 之间的关系 [1]。
```markdown
## 参考文献
[1] Vaswani et al., "Attention Is All You Need," 2017.
```
**绝不捏造参考文献。绝不引用实际上并不支持该陈述的来源。**
---
## 第 17 步 — 写作风格
以一位经验丰富的工程师或研究者的身份来写作，向另一位具备技术能力的人解释一个复杂系统。
**优先使用：** 精确的语言、短到中等长度的段落、清晰的解释、明确的假设、具体的示例、在有用之处展现技术深度、在适当之处使用结构化文本图表、有意义的章节标题。
**避免：** 过多的形容词、创业公司式的炒作、重复的结论、泛泛的使命宣言、不必要的术语、人为制造的复杂性、虚假的确定性。
语气：*"这是问题。这是现有方法为何困难。这是我们提出的机制。这是它如何工作。这是证据。这是它可能失败的地方。"*
而不是：*"我们正在革新技术的未来。"*
---
## 第 18 步 — 输出结构
以 Markdown 格式产出白皮书，根据实际项目调整章节编号（省略无关章节）：
```markdown
# 标题
## 摘要
## 1. 引言
## 2. 问题与动机
## 3. 现有方法
## 4. 设计目标与非目标
## 5. 提出的架构
## 6. 核心机制
## 7. 系统工作流程
## 8. 技术设计
## 9. 安全性、安全性与可靠性
## 10. 性能与可扩展性
## 11. 完整示例
## 12. 评估
## 13. 局限性与开放问题
## 14. 未来工作
## 15. 结论
## 参考文献
```
**篇幅应随技术复杂度而定，而非任意设定的页数。** 简单的系统得到简洁的论文；复杂的系统得到更深入的处理。
---
## 第 19 步 — 发布前自检
在宣布白皮书完成之前，逐项核实：
| 检查项 | 状态 |
|---|---|
| 问题具体明确 | 通过 / 未通过 |
| 失败场景已解释 | 通过 / 未通过 |
| 项目类型已正确识别 | 通过 / 未通过 |
| 核心机制已清晰解释 | 通过 / 未通过 |
| 系统边界已定义 | 通过 / 未通过 |
| 架构可理解 | 通过 / 未通过 |
| 数据 / 请求流已解释 | 通过 / 未通过 |
| 现有方法已讨论 | 通过 / 未通过 |
| 技术差异清晰 | 通过 / 未通过 |
| 重要参与者已分析 | 通过 / 未通过 |
| 存在威胁 / 失败模型 | 通过 / 未通过 |
| 主要论断有证据支持 | 通过 / 未通过 |
| 至少存在一个完整示例 | 通过 / 未通过 |
| 权衡取舍已承认 | 通过 / 未通过 |
| 局限性已明确陈述 | 通过 / 未通过 |
| 未来工作与当前能力已区分 | 通过 / 未通过 |
| 外部论断已引用 | 通过 / 未通过 |
| 无捏造的数字或参考文献 | 通过 / 未通过 |
| 无营销炒作替代技术解释 | 通过 / 未通过 |
报告一份简短的 **白皮书质量检查**，总结这些结果。如果缺少重要信息，请明确说明，而不是凭空编造。
---
## 第 20 步 — 缺失信息处理策略
如果缺少关键信息，在起草该部分之前先询问。**绝不捏造：** 技术规格、基准测试结果、客户数量、采用统计数据、收入、市场规模、团队资历、合作关系、安全保证、性能测量、代币经济学、实现细节或研究结果。
当某些内容未知时，明确标注：
> **未指定** / **需要验证** / **假设：** ...
绝不将假设悄悄转换为陈述的事实。
---
## 核心原则
白皮书应优先回答一个问题，胜过所有其他问题：
> **一位具备技术能力的读者能否理解这个系统做什么、如何工作、为何如此设计、有哪些证据支持它，以及它可能在哪里失败？**
如果是，白皮书就完成了它的使命。