项目文档名称手册
项目里常见的 PRD、SRS、Design Doc、GDD、Protocol、Runbook 等名称，并不是一张从“粗略”到“正式”的统一等级表。它们分别描述不同对象、阶段、约束强度和使用目的；其中一部分有正式标准或官方定义，另一部分只是行业或组织惯例。
这份手册用于两件事：先判断当前真正需要哪一种文档，再用足够明确的上下文让人或 AI 写对它。 内容按 2026 年 7 月可查到的官方资料整理；实际交付时，仍应优先遵守所在组织、客户、资助机构、伦理委员会或目标期刊的模板。
最重要的规则： 不要只说“写一份 PRD”或“给我一个 TDD”。至少给出英文全称、文档目的、目标读者、当前阶段、范围、已确认事实和约束。缩写可能有歧义，模板也不会自动补齐缺失的项目事实。
先选对文档
先回答三个问题：
- 这份文档要推动什么决定或行动？
- 需要固定的是目标、需求、方案、步骤，还是已经发生的事实？
- 谁会阅读它，并据此设计、实现、审核、验收或处置？
| 当前目标 | 通常优先选择 |
|---|---|
| 快速建立共同认知或争取立项 | Brief、Concept Note、Vision、Pitch Deck |
| 说明为谁解决什么问题、准备做什么 | BRD、PRD、GDD、Research Proposal |
| 固定可验证的行为、质量或验收边界 | SRS、Functional Specification、NFR、Acceptance Criteria |
| 评审准备如何实现 | Engineering RFC、Design Document、Architecture Description |
| 记录一个重要选择及其后果 | ADR |
| 固定接口、数据或跨团队边界 | OpenAPI、ICD、Data Model、Data Dictionary |
| 指导一次具体执行 | Plan、Guide、Runbook、Migration Guide、Research Protocol |
| 面对分支较多的复杂事件 | Playbook |
| 记录已经发生的事情和结论 | Log、Report、Release Notes、Postmortem |
| 在研究开始前冻结假设与分析承诺 | Preregistration、Registered Report、SAP |
Guide、Manual、Specification、Plan 等词可以和具体对象组合。例如，API Migration Guide 是迁移指南，Incident Response Playbook 是事件处置框架，Statistical Analysis Plan 则是统计分析计划。先确定对象和用途，再决定名称。
先看懂文档名称
Brief / Concept Note
简短说明，帮助快速建立共同认知，不追求完整细节
它回答： 这是什么？为什么值得做？
Charter
正式授权或确立项目边界、责任和治理关系
它回答： 谁授权？谁负责？范围是什么？
Requirements
利益相关者需要什么，强调目标、能力或约束
它回答： 系统需要满足什么？
Specification / Spec
精确、可验证、可作为实现或验收依据的规定
它回答： 必须具体表现为什么？
Design
为满足需求而选择的解决方案
它回答： 准备怎么实现？
Architecture
系统级结构、组件关系、边界和关键约束
它回答： 整体如何组织？
Plan
尚未执行的活动、资源、时间和方法
它回答： 接下来怎么做？
Roadmap
中长期方向与阶段性成果，通常不是精确排期
它回答： 未来优先做什么？
Record / Log
已发生事件、实验、决策或变更的连续记录
它回答： 发生过什么？
Report
对结果、证据、问题或结论的整理和分析
它回答： 得到了什么结论？
Guide / Manual
面向人的说明性操作知识
它回答： 应该如何操作？
Runbook
可重复执行的具体运维步骤
它回答： 遇到某种情况按什么步骤执行？
Playbook
针对某类复杂情形的判断与处置框架
它回答： 如何调查、判断并选择处置路径？
Policy
必须遵守的原则或规则
它回答： 什么允许做，什么禁止做？
Standard
统一采用的规范、格式或质量基线
它回答： 所有人必须按什么一致方式执行？
软件与互联网产品
产品与需求
Product Vision · 产品愿景
描述产品希望创造的长期价值、目标用户和方向。它不是功能列表，也不是排期。
给 AI 的指令： “编写产品愿景，说明目标用户、核心问题、差异化价值和长期目标。”
Product Roadmap · 产品路线图
按时间或主题表达产品方向、优先级和阶段性成果。通常不等同于详细项目计划。
给 AI 的指令： “生成按季度组织的产品路线图，使用主题和结果，不虚构精确发布日期。”
Business Requirements Document, BRD · 业务需求文档
从业务视角描述商业目标、业务流程、利益相关者、范围和约束。侧重“业务为什么需要”，不负责完整软件技术规格。
给 AI 的指令： “编写 BRD，重点说明业务目标、现状流程、目标流程、范围和业务规则。”
Product Requirements Document, PRD · 产品需求文档
描述产品目的、用户问题、功能范围、行为、成功指标及非目标。主要回答“为什么做、为谁做、做什么”，通常不展开底层实现。
给 AI 的指令： “编写 PRD，不设计代码架构；包含用户问题、目标、非目标、功能范围、指标和开放问题。”
Software Requirements Specification, SRS · 软件需求规格说明
对软件应满足的功能、接口、约束和质量属性进行系统、可验证的规定。比 PRD 更工程化，应能支持设计、测试和验收。
给 AI 的指令： “把 PRD 转换为 SRS，将需求编号，并写成可验证的 shall 语句。”
Functional Specification · 功能规格说明
精确规定系统功能、输入、处理规则、状态、输出和异常行为。重点是可观察行为，而不是内部实现。
给 AI 的指令： “为账户注册功能编写功能规格，覆盖主流程、异常、边界条件和状态变化。”
Non-functional Requirements, NFR · 非功能需求／质量属性需求
规定性能、可靠性、安全性、可用性、兼容性、可维护性等质量要求。应带测量条件和阈值，不能只写“高性能”。
给 AI 的指令： “将非功能需求量化，给出测量场景、指标、目标值和验收方法。”
User Story · 用户故事
从用户价值视角表达一项小型需求。常用格式是“作为……我希望……以便……”，正文通常需要配合讨论和验收条件，不能单独替代完整规格。
给 AI 的指令： “把需求拆成可独立交付的用户故事，并为每项补充验收条件。”
Use Case Specification · 用例规约／用例说明
描述参与者为达成目标而与系统发生的交互，包括前置条件、主成功场景、备选流程、异常和后置条件。比用户故事更强调完整交互过程。
给 AI 的指令： “编写登录用例规约，列出参与者、触发条件、主流程、替代流程和失败状态。”
Acceptance Criteria, AC · 验收条件／验收准则
针对某项需求、故事或功能预先规定可接受的具体条件。它回答“这一项何时算完成”，范围通常小于团队级 Definition of Done。
给 AI 的指令： “使用 Given–When–Then 编写验收条件，并覆盖边界与错误场景。”
Product Backlog · 产品待办列表
产品所需改进事项的有序、持续演化列表，是 Scrum 团队工作的主要来源；条目可以是功能、缺陷、研究或技术工作。
给 AI 的指令： “整理 Product Backlog，为条目补充价值、优先级、依赖和验收条件。”
Sprint Backlog · 迭代待办列表
包含 Sprint Goal、选入当前 Sprint 的产品待办项，以及交付这些事项的可执行计划。它不是整个产品的需求清单。
给 AI 的指令： “从产品待办中形成 Sprint Backlog，围绕一个 Sprint Goal 拆分任务。”
Definition of Done, DoD · 完成定义
团队对“增量达到可交付质量”所采用的统一质量标准，例如测试、评审、文档和部署要求。它通常适用于所有工作，而 AC 针对单项需求。
给 AI 的指令： “生成团队级 DoD，不要把某个功能独有的验收条件写进去。”
Requirements Traceability Matrix, RTM · 需求跟踪矩阵
建立业务目标、需求、设计、实现、测试和发布项之间的映射，用于检查遗漏、变更影响和验证覆盖率。
给 AI 的指令： “创建 RTM：需求 ID → 设计章节 → 代码模块 → 测试用例 → 验收结果。”
设计、架构与接口
Engineering Proposal / Internal RFC · 工程提案／内部 RFC
在实施前提出一个需要团队讨论的技术变更，通常包含背景、目标、方案、替代方案、风险和开放问题。它是组织内部惯例。IETF RFC则是互联网技术文档系列，并非每一份 RFC 都是互联网标准。
给 AI 的指令： “编写内部 Engineering RFC，用于评审方案；不要把它写成 IETF 标准文档。”
Design Document / Technical Design Document · 设计文档／技术设计文档
对拟实施方案的组件、数据流、接口、算法、状态、部署、迁移和权衡进行说明。它回答“怎么实现”，不是重新描述产品需求。设计文档在实施后也可作为决策历史。
给 AI 的指令： “根据已确认的 SRS 编写 Technical Design Document，明确组件、数据流、失败处理和权衡。”
Architecture Description · 架构描述
使用架构视点、视图和模型描述系统的主要结构、关系、环境和关注点。它关注系统级结构，不承担每个函数的实现细节。
给 AI 的指令： “编写系统架构描述，分别呈现上下文、容器、组件、部署和数据视图。”
Software Architecture Document, SAD · 软件架构文档
行业中常用的架构文档名称，通常承载架构描述、质量属性、关键约束和主要技术决策。具体目录依组织而异。
给 AI 的指令： “创建 SAD，重点说明质量属性如何驱动架构选择。”
C4 Model Diagrams · C4 架构图
用 System Context、Container、Component、Code 等层级逐步放大软件结构。Context 和 Container 图常用于建立整体认知。
给 AI 的指令： “用 C4 语义描述系统；先输出 Context 和 Container，不要把部署节点误写成 Container。”
Architecture Decision Record, ADR · 架构决策记录
记录一项重要架构选择的背景、决策、状态和后果。ADR 应聚焦单个决策；多份 ADR 构成决策日志。
给 AI 的指令： “为选择 PostgreSQL 编写一份 ADR，包含 Context、Decision、Consequences 和 Status。”
API Specification · API 规格说明
对 API 的操作、路径、参数、请求、响应、错误和安全机制进行机器或人可读的契约化描述。OpenAPI Specification 专门用于描述 HTTP API。
给 AI 的指令： “生成 OpenAPI 3.x 规格；响应码、字段可空性和错误模型必须明确。”
Interface Control Document, ICD · 接口控制文档
精确规定两个系统、子系统或硬件／软件边界之间的接口，包括数据结构、协议、时序、单位、版本和错误处理。比一般 API 文档更强调跨团队接口控制。
给 AI 的指令： “编写 ICD，固定双方责任、消息格式、时序、兼容性和变更流程。”
Data Model · 数据模型
描述业务实体、属性、关系、约束和生命周期。可以分为概念模型、逻辑模型和物理模型。
给 AI 的指令： “先输出逻辑数据模型，再给出物理表结构；不要把业务实体直接等同于数据库表。”
Entity–Relationship Diagram, ERD · 实体关系图
以图形形式表示实体、属性、关系和基数，是数据模型的一种表达方式，不等于完整的数据语义说明。
给 AI 的指令： “生成 ERD，并显式标注一对一、一对多、多对多和可选性。”
Data Dictionary · 数据字典
对数据字段逐项定义名称、业务含义、类型、格式、单位、允许值、空值、来源和敏感级别。它解释字段，不负责管理整个数据生命周期。
给 AI 的指令： “根据数据库结构生成数据字典，重点补充业务含义和约束，不只复制字段类型。”
Threat Model · 威胁模型
系统化表示资产、信任边界、攻击面、潜在威胁、风险和缓解措施。它用于设计阶段的安全推理，不只是漏洞扫描结果。
给 AI 的指令： “基于数据流和信任边界编写威胁模型，使用 STRIDE，并给出缓解措施和剩余风险。”
测试、发布与运维
Test Strategy · 测试策略
定义跨项目或较大范围的测试原则、层级、自动化方向、环境策略、质量门槛和风险方法。它比单次发布的 Test Plan 更长期、更抽象。
给 AI 的指令： “编写测试策略，说明测试金字塔、自动化范围、环境、质量门槛和风险优先级。”
Test Plan · 测试计划
针对特定项目、版本或测试周期规定测试范围、人员、环境、时间、入口／出口条件及交付物。
给 AI 的指令： “为 2.0 发布编写测试计划，包含范围、排除项、环境、日程和退出标准。”
Test Case / Test Specification · 测试用例／测试规格
对测试前置条件、输入、步骤、预期结果和清理方式的具体定义。测试用例验证某项行为，不应只写操作步骤而没有预期结果。
给 AI 的指令： “从验收条件生成测试用例，给每项分配 ID，并标明对应需求。”
README · 项目说明文件
项目的入口文档，通常说明用途、安装、运行、配置、示例和进一步文档的位置。
给 AI 的指令： “编写面向新开发者的 README，确保从克隆仓库到运行示例路径完整。”
CONTRIBUTING.md · 贡献指南
说明如何提交问题、建立开发环境、遵守代码规范、运行测试和提交变更。
给 AI 的指令： “编写 CONTRIBUTING.md，包含分支、提交、测试、PR 和评审规则。”
SECURITY.md · 安全策略
说明支持的版本、安全漏洞报告渠道和披露流程；不应在其中公开具体未修复漏洞。
给 AI 的指令： “编写 SECURITY.md，说明支持版本和私密漏洞报告流程。”
CHANGELOG · 变更日志
按版本、按时间维护的显著变更列表，主要服务于持续追踪。它通常覆盖新增、修改、修复、弃用和安全变更。
给 AI 的指令： “根据提交记录整理面向用户的 CHANGELOG，过滤内部重构噪声。”
Release Notes · 发布说明
针对某一个具体发布编写的沟通材料，突出用户影响、重要变化、升级事项和已知问题；通常比 Changelog 更具叙述性和发布语境。
给 AI 的指令： “为 v3.0 编写 Release Notes，突出用户价值、破坏性变化、迁移步骤和已知问题。”
Migration Guide · 迁移指南
指导用户或开发者从旧版本、旧架构或旧数据模型迁移到新版本，重点是差异、步骤、兼容性和回滚。
给 AI 的指令： “生成 v1 到 v2 的迁移指南，逐项列出破坏性变化、替换方案和验证步骤。”
Runbook · 运行手册／操作手册
为可重复的运维任务或已知情形提供具体操作步骤，例如部署、扩容、恢复、证书轮换。
给 AI 的指令： “编写数据库故障切换 Runbook，包含前置检查、命令、验证和回滚。”
Incident Playbook · 事件处置剧本
为一类事件提供调查顺序、判断条件、升级路径和可选处置方式。它比 Runbook 更强调诊断和分支决策。
给 AI 的指令： “编写账户接管事件 Playbook，包含识别、分级、调查、遏制、恢复和通知路径。”
Incident Report / Postmortem · 事故报告／事后复盘
对已发生事故的时间线、影响、根因、促成因素、处置过程和后续行动进行记录。它是事实与改进文档，不是操作步骤。
给 AI 的指令： “基于事件时间线编写无责 Postmortem，区分根因、促成因素和行动项。”
游戏开发
游戏文档的命名最依赖工作室习惯。Unity 将 GDD 描述为随项目演化的“活文档”，并明确指出游戏设计文档不存在唯一固定格式；因此，向 AI 提问时应同时说明你需要的是概念、玩法规则、技术实现、内容生产还是商业提案。
概念与立项
High Concept / One-pager · 高概念说明／一页式概念书
用一页左右说明游戏类型、玩家、平台、核心幻想、独特卖点、核心循环和大致规模。它用于快速理解，不是完整 GDD。
给 AI 的指令： “编写游戏 One-pager，强调玩家幻想、核心循环、差异化卖点和目标平台。”
Game Pitch Deck · 游戏提案演示稿
面向发行商、投资方或内部立项决策者的说服性材料，通常包含概念、受众、市场定位、视觉方向、团队、预算、进度和合作诉求。
给 AI 的指令： “编写发行商 Pitch Deck 大纲，重点说明市场定位、可验证亮点、团队能力和资金用途。”
Game Design Document, GDD · 游戏设计文档
游戏设计的核心参考文档，描述设计支柱、玩法、规则、系统、内容范围与体验目标，并随设计验证不断更新。它主要定义“游戏如何玩”，不是代码架构文档或项目排期。
给 AI 的指令： “编写精简 GDD，覆盖设计支柱、核心循环、主要系统、内容范围和未决问题。”
玩法、系统与技术
Design Pillars · 设计支柱
少量用于约束设计决策的核心体验原则。例如“高机动性”“信息透明”“每局形成不同构筑”。不是营销口号。
给 AI 的指令： “根据游戏概念提炼 3 个可用于取舍功能的设计支柱。”
Core Gameplay Loop Specification · 核心玩法循环说明
描述玩家反复执行的行为、反馈、奖励和进阶关系，通常区分秒级、局内和长期循环。
给 AI 的指令： “绘制核心循环：行动 → 反馈 → 奖励 → 强化 → 新挑战，并指出循环频率。”
Gameplay Mechanic Specification · 玩法机制规格
对一项具体机制规定输入、状态、规则、公式、反馈、边界和可调参数，例如闪避、建造或潜行。比 GDD 更细、更可实现。
给 AI 的指令： “为冲刺机制编写规格，包含状态机、输入缓冲、无敌帧、资源消耗和边界条件。”
Systems Design Document · 游戏系统设计文档
描述多个相互影响的系统，例如战斗、成长、装备、经济、任务和掉落，并分析反馈循环与系统性后果。
给 AI 的指令： “编写成长系统设计，说明资源来源、消耗点、解锁节奏和系统间依赖。”
Technical Design Document · 游戏技术设计文档
描述引擎模块、代码架构、网络、存档、资源加载、工具链和性能预算等实现方案。这里的 TDD 指 Technical Design Document，不是 Test-Driven Development。
给 AI 的指令： “编写存档系统 Technical Design Document，覆盖数据版本、原子写入、云同步和迁移。”
Game Economy Specification · 游戏经济规格
描述货币、资源、产出、消耗、交换、价格、通胀控制和玩家进度之间的关系。
给 AI 的指令： “编写经济系统规格，列出每种资源的来源、消耗点、库存上限和目标周转速度。”
Balance Sheet / Tuning Sheet · 平衡表／参数调优表
集中保存伤害、生命、掉落率、成长曲线等可调数值及其公式。这里的 Balance Sheet 不是财务资产负债表。
给 AI 的指令： “建立战斗参数表，区分基础值、成长公式、单位和允许调节范围。”
Monetization Design Document · 商业化设计文档
描述付费点、商品、定价、奖励关系、购买流程及其与核心体验的边界。它不等同于完整游戏经济设计。
给 AI 的指令： “编写商业化设计，明确付费内容、展示时机、价值来源及不影响的核心体验。”
叙事、视听与关卡内容
Art Bible / Visual Style Guide · 美术风格指南／美术规范
统一形状语言、色彩、材质、比例、镜头、光照、角色、环境和资产制作约束。它约束视觉生产，不是单纯灵感拼贴。
给 AI 的指令： “编写 Art Bible，给出视觉原则、允许／禁止示例、资产规格和一致性检查项。”
Narrative Design Document · 叙事设计文档
描述叙事如何通过玩法、任务、对话、环境和玩家选择呈现。它关注故事与交互系统的关系，不等同于剧本。
给 AI 的指令： “编写叙事设计文档，说明剧情节点、玩家选择、状态变量和玩法触发条件。”
Story / World Bible · 故事设定集／世界观设定集
维护世界规则、历史、地点、组织、术语、时间线和连续性事实，是内容团队的统一事实来源。
给 AI 的指令： “建立 World Bible，区分已确认设定、传闻、未知信息和禁止冲突规则。”
Character Bible · 角色设定集
记录角色背景、动机、关系、语言风格、行为边界、视觉特征和成长弧线，用于保持跨内容一致性。
给 AI 的指令： “编写角色设定集，加入角色能做／不会做什么，以及对白语气示例。”
Level Design Document, LDD · 关卡设计文档
定义关卡目标、玩家路径、空间结构、机制教学、遭遇、节奏、资源和完成条件。关卡设计同时涉及空间、挑战和体验流。
给 AI 的指令： “编写 LDD，包含目标、关键路径、可选路径、遭遇节奏、资源布置和完成条件。”
Level Flow / Beat Sheet · 关卡流程／节拍表
按顺序表示关卡中的探索、战斗、叙事、休息、奖励和高潮节点。侧重体验节奏，不等同于最终几何布局。
给 AI 的指令： “用节拍表描述 20 分钟关卡，每个节点注明目标、情绪、挑战和预计时长。”
Blockout Plan / Greybox Plan · 白盒／灰盒验证计划
使用简单几何快速验证尺寸、动线、视线、节奏和玩法空间，不处理最终美术品质。
给 AI 的指令： “制定关卡灰盒验证清单，只评估空间、路径、视野和玩法，不评估最终美术。”
UI/UX Flow and Wireframes · 界面流程与线框图
描述玩家在菜单、HUD、商店、背包和设置中的任务流程、页面状态和信息层级。线框图关注结构，不代表最终视觉稿。
给 AI 的指令： “生成背包系统 UX 流程和低保真线框说明，覆盖空状态、满容量和批量操作。”
Audio Design Document · 音频设计文档
规定音乐、环境音、反馈音、语音、动态混音、触发条件和实现技术。
给 AI 的指令： “编写战斗音频设计，说明事件触发、优先级、层级变化和混音规则。”
Asset List / Asset Register · 游戏资产清单
列出需要制作的角色、动画、环境、特效、音频和 UI 资产，以及规格、负责人、状态、依赖和版本。
给 AI 的指令： “根据关卡内容生成 Asset Register，包含 ID、类型、规格、负责人、依赖和状态。”
Localization Kit · 本地化资料包
提供待翻译内容、术语表、上下文、角色信息、长度限制、截图、变量规则和语言风格。充分上下文对翻译、编辑和本地化测试很重要。
给 AI 的指令： “生成 Localization Kit，包含术语表、角色语气、变量占位符和 UI 长度限制。”
Accessibility Specification · 无障碍设计规格
规定字幕、输入重映射、色觉支持、难度辅助、运动与闪烁控制、信息冗余等可测试要求。
给 AI 的指令： “编写无障碍规格，将每项能力写成可验证需求，并标明默认设置。”
制作与验证
Production Plan / Milestone Plan · 制作计划／里程碑计划
将工作划分为原型、垂直切片、内容生产、Alpha、Beta、发布等阶段，并安排资源和交付物。
给 AI 的指令： “编写里程碑计划，每个阶段给出可验证交付物，而不只列日期。”
Prototype Brief · 原型验证说明
明确原型要验证的假设、最小功能、时间盒、成功标准和应舍弃的内容。原型追求学习速度，不追求完整品质。
给 AI 的指令： “制定两周原型 Brief，只验证移动和战斗手感，并给出停止／继续标准。”
Vertical Slice Definition · 垂直切片定义
规定一个覆盖玩法、技术、美术、音频和生产流程的代表性端到端片段，通常接近目标品质，用于证明整体生产可行性。它不等于只验证概念的粗糙原型。
给 AI 的指令： “定义 Vertical Slice 的范围与验收标准，要求代表最终品质和完整生产管线。”
Playtest Plan / Playtest Report · 试玩测试计划／报告
计划文档说明假设、参与者、任务、观察指标和访谈问题；报告整理行为证据、问题、解释和设计行动。
给 AI 的指令： “围绕新手引导编写试玩计划；报告中区分观察事实、参与者意见和设计推断。”
数据与长线运营
Telemetry / Event Tracking Specification · 遥测／埋点事件规格
精确定义游戏事件名称、触发条件、字段、类型、用户属性、会话规则和版本，用于行为分析。
给 AI 的指令： “编写埋点规格，为每个事件说明触发时机、字段、数据类型和分析用途。”
LiveOps Calendar / Content Roadmap · 长线运营日历／内容路线图
安排赛季、活动、内容发布、商店轮换、实验和运营依赖。它是上线后运营计划，不是开发期产品待办。
给 AI 的指令： “生成 12 周 LiveOps 日历，标明活动目标、内容依赖、配置冻结和复盘节点。”
科研项目
科研文档需要特别区分：研究方案用于指导研究执行；预注册用于在观察结果前冻结并留下时间戳记录；Registered Report 是在结果产生前接受同行评审的一种出版流程。
立项与研究定位
Research Concept Note · 研究概念说明
简洁说明研究问题、重要性、核心想法、方法概况和预期贡献，用于早期讨论或筛选。不是完整项目申请书。
给 AI 的指令： “编写两页 Concept Note，突出研究问题、知识缺口、方法和预期贡献。”
Research Proposal · 研究计划书／项目申请书
为获得批准、资源或资助而提出的完整研究计划，通常涵盖背景、问题、目标、方法、可行性、计划、预算和预期成果。
给 AI 的指令： “编写研究计划书，明确研究问题、创新性、方法、工作包、风险和交付物。”
Literature Review · 文献综述
系统地检索、组织、比较和综合既有研究，展示领域现状、争议、方法和知识缺口。它不应只是逐篇摘要。
给 AI 的指令： “按主题和观点综合文献，比较证据与方法，并明确研究空白。”
Related Work · 相关工作
论文中用于定位当前工作与最相关研究之间关系的章节，通常比完整文献综述更聚焦于贡献比较。
给 AI 的指令： “编写 Related Work，按研究路线组织，并明确本文相对每条路线的区别。”
方案、注册与伦理
Research Protocol · 研究方案／研究协议
对研究目标、设计、对象、方法、流程、统计考虑和组织方式的完整书面说明，用于一致地实施研究。
给 AI 的指令： “编写研究 Protocol，确保另一团队可按相同流程执行研究。”
Preregistration · 预注册
在采集数据或查看相关结果前，将假设、变量、排除规则和分析计划形成带时间戳、不可静默修改的记录，以区分验证性和探索性分析。
给 AI 的指令： “把研究方案转换为预注册，明确主要结局、排除规则、样本量和分析模型。”
Registered Report · 注册报告
一种期刊评审与发表模式：研究问题、方法和拟议分析在研究实施或结果完成前接受同行评审，并可能获得原则性接收。它不是普通的预注册文件。
给 AI 的指令： “按 Registered Report Stage 1 结构组织引言、方法、功效分析和拟议分析。”
Statistical Analysis Plan, SAP · 统计分析计划
比 Protocol 更细地规定分析人群、变量派生、模型、协变量、缺失值、多重检验、敏感性分析和表图输出。
给 AI 的指令： “编写 SAP，避免只写‘使用适当统计方法’，明确每个研究问题对应的模型。”
Ethics / IRB Application · 伦理审查申请
向伦理委员会说明研究目的、参与者、招募、风险、隐私、补偿、同意流程和数据保护，以获得研究许可。
给 AI 的指令： “根据 Protocol 编写伦理申请，重点说明参与者风险、隐私和退出机制。”
Informed Consent Form, ICF · 知情同意书
向参与者说明研究、程序、风险、收益、隐私、补偿、自愿性和退出权，并记录同意。WHO 模板通常区分信息说明与同意证明部分。
给 AI 的指令： “用普通参与者能理解的语言编写 ICF，不直接复制技术化 Protocol 文本。”
数据与执行记录
Data Collection Instrument · 数据收集工具
实际采集数据的工具总称，例如问卷、访谈提纲、观察表、测量量表或实验任务。
给 AI 的指令： “设计半结构化访谈提纲，每个问题标明对应研究问题，避免诱导性提问。”
Case Report Form, CRF · 病例报告表／研究数据采集表
在临床或受试者研究中按研究方案收集每位参与者规定数据的结构化表单。它是采集载体，不是知情同意书。
给 AI 的指令： “根据 Protocol 生成 CRF 字段，标明必填性、单位、时间点和数据校验规则。”
Data Management Plan, DMP · 数据管理计划
说明数据如何创建、命名、存储、备份、保护、记录、保留、归档和共享。它管理数据生命周期，不逐项定义变量含义。
给 AI 的指令： “编写 DMP，覆盖格式、存储、权限、备份、版本、保留和开放共享。”
Data Management and Sharing Plan, DMSP · 数据管理与共享计划
在 DMP 基础上强调数据、元数据及相关材料如何保存、发布和共享；部分资助机构将其作为项目申请组成部分。
给 AI 的指令： “按资助机构要求编写 DMSP，说明共享时间、存储库、限制和长期保存。”
Codebook · 编码本／变量编码手册
定义变量、题项、标签、值编码、缺失值、派生规则和分类体系，常用于调查和定量数据。
给 AI 的指令： “从问卷生成 Codebook，列出变量名、问题文本、值标签、缺失编码和派生逻辑。”
Research Data Dictionary · 研究数据字典
对数据表及字段的语义、类型、单位、范围、来源和关系进行说明。与 Codebook 相比，它更通用、更偏数据结构。
给 AI 的指令： “编写研究数据字典，说明字段含义、单位、允许范围和生成来源。”
Lab Notebook / Electronic Lab Notebook, ELN · 实验记录本／电子实验记录本
按时间记录实验目的、材料、环境、步骤、观察、原始结果和偏差，用于形成可追溯研究记录。ELN 是其电子化实现。
给 AI 的指令： “把零散实验笔记整理成 ELN 条目，保留时间、版本、失败尝试和原始数据引用。”
Experiment Log · 实验日志
针对多次实验运行记录配置、代码版本、随机种子、数据版本、指标和输出位置。通常比通用实验记录本更结构化。
给 AI 的指令： “设计机器学习 Experiment Log 模板，记录 commit、数据版本、参数、seed、指标和 artifact。”
Protocol Deviation Log · 方案偏离记录
记录实际执行与批准 Protocol 不一致的事件、原因、影响及处置。它不应通过修改原方案来掩盖偏离。
给 AI 的指令： “创建偏离记录，包含计划步骤、实际步骤、原因、数据影响和纠正措施。”
分析、投稿与评审
Analysis Report · 分析报告
记录数据处理、模型、结果、诊断、敏感性分析和解释，重点是分析证据与推断。它可以是论文形成前的内部材料。
给 AI 的指令： “生成分析报告，严格区分预注册分析、探索性分析、结果和解释。”
Technical Report · 技术报告
完整记录研究或工程工作的背景、方法、系统、实验和结果，通常比论文篇幅更宽松，可能由机构直接发布。
给 AI 的指令： “把项目材料整理为技术报告，保留实现细节、消融实验和限制。”
Preprint · 预印本
在正式同行评审出版之前或之外公开传播的论文版本。它描述发布状态，不代表某种特定写作结构。
给 AI 的指令： “将稿件整理为预印本版本，补充版本日期、作者信息、许可证和引用方式。”
Manuscript · 论文稿件／手稿
提交、评审或编辑过程中的论文文本统称；它可以是预印本，也可以尚未公开。
给 AI 的指令： “按目标期刊结构重写 Manuscript，不将预印本状态与稿件类型混为一谈。”
Supplementary Materials · 补充材料
承载正文篇幅之外但支持验证和理解的材料，例如额外方法、证明、表格、问卷、分析和多媒体内容。
给 AI 的指令： “整理补充材料，并在正文中建立清晰交叉引用。”
Response to Reviewers · 审稿意见回复
对每条评审意见逐项回应，说明接受、修改位置、补充证据或不同意的理由。它与修改后的论文稿件是两个交付物。
给 AI 的指令： “生成 point-by-point 回复，引用评审原意，并标明每项修改所在章节。”
Rebuttal · 评审申辩／答辩回复
常见于会议评审阶段的限字回复，目标是澄清误解、回答问题或纠正事实，未必允许全面修改论文。
给 AI 的指令： “编写限 800 字 rebuttal，优先处理影响评分的事实误解和关键疑问。”
制品、复现与元数据
Research Artifact · 研究制品
与研究相关的数字对象，例如代码、脚本、数据、模型、配置和实验输出。Artifact 是对象类别，不自动意味着它足以复现结果。
给 AI 的指令： “列出论文 Artifact，并说明每项内容、许可证、版本和与结果的对应关系。”
Reproducibility / Replication Package · 可复现性包／复现实验包
为重新运行分析或验证结果而整理的代码、数据、环境、说明、工作流和预期输出集合。它比单独公开代码更完整。
给 AI 的指令： “创建复现包目录，包含 README、环境锁定、数据说明、运行命令和预期结果。”
Datasheet for Datasets · 数据集说明表
系统记录数据集的动机、组成、收集过程、预处理、用途、限制、分发和维护信息。
给 AI 的指令： “按 Datasheets for Datasets 框架编写数据集文档，不只列文件和字段。”
Model Card · 模型卡
随模型发布的结构化说明，通常涵盖模型信息、预期用途、限制、评估条件、性能及相关群体表现。
给 AI 的指令： “生成 Model Card，分别说明 intended use、out-of-scope use、训练数据概况、评估和限制。”
CITATION.cff · 软件／数据引用元数据文件
使用机器和人可读格式提供作者、标题、版本、DOI 等引用信息，帮助代码或数据被正确引用。
给 AI 的指令： “根据项目元数据生成合法的 CITATION.cff，并区分软件版本与关联论文。”
CodeMeta · 科研软件元数据
用标准化词汇表达软件名称、作者、版本、许可证、代码仓库、运行环境和引用等元数据，支持发现与互操作。
给 AI 的指令： “将仓库元数据映射为 CodeMeta，不要只从 README 猜测作者和许可证。”
易混术语速查
| 容易混淆的文档 | 准确区分 |
|---|---|
| BRD vs PRD vs SRS | BRD：业务为什么需要；PRD：产品为谁解决什么问题、做什么；SRS：软件必须满足哪些可验证要求。 |
| User Story vs Use Case | User Story：简短表达用户价值；Use Case：完整展开参与者与系统的交互路径。 |
| Acceptance Criteria vs Definition of Done | AC：某项需求的特定验收条件；DoD：团队对所有可交付增量采用的统一质量标准。 |
| RFC vs Design Doc vs ADR | RFC：提交讨论的提案；Design Doc：完整实现方案；ADR：最终关键决策及其背景和后果。 |
| Architecture Document vs Detailed Design | 架构文档：系统级结构、边界和质量属性；详细设计：模块内部算法、状态和实现细节。 |
| API Documentation vs API Specification | Documentation：帮助人理解和使用；Specification：精确且可能机器可读的接口契约。 |
| Data Model vs ERD vs Data Dictionary | Data Model：完整数据概念与规则；ERD：实体关系的图形表达；Data Dictionary：逐字段语义定义。 |
| Test Strategy vs Test Plan vs Test Case | Strategy：长期测试原则；Plan：某次项目或发布如何测试；Case：一项具体测试如何执行和判断。 |
| CHANGELOG vs Release Notes | CHANGELOG：跨版本持续维护的变化记录；Release Notes：针对某一次发布、面向特定受众的说明。 |
| Runbook vs Playbook vs Postmortem | Runbook：执行步骤；Playbook：诊断与决策路径；Postmortem：事件发生后的事实、原因和改进。 |
| GDD vs Technical Design Document | GDD：游戏规则与玩家体验；Technical Design Document：代码、引擎、网络、存档等实现方案。 |
| Prototype vs Vertical Slice | Prototype：低成本验证某个假设；Vertical Slice：以接近目标品质验证完整端到端生产能力。 |
| Narrative Design Document vs Script | 叙事设计文档：叙事如何与玩法和状态交互；Script：具体对白、场景或表演文本。 |
| Research Proposal vs Protocol | Proposal：争取批准或资助；Protocol：研究实际如何被一致执行。 |
| Protocol vs Preregistration | Protocol：可执行研究方案；Preregistration：实施或观察结果前留下的时间戳分析承诺。 |
| Preregistration vs Registered Report | Preregistration：研究者登记计划；Registered Report：期刊在结果产生前评审研究问题和方法的出版机制。 |
| DMP vs Data Dictionary | DMP：数据整个生命周期如何管理；Data Dictionary：每张表和每个字段是什么意思。 |
| Lab Notebook vs Experiment Log | Lab Notebook：完整、连续的研究记录；Experiment Log：每次运行的结构化配置和结果记录。 |
| Model Card vs Dataset Datasheet | Model Card：描述模型用途、表现和限制；Datasheet：描述数据集来源、组成、用途和限制。 |
| Artifact vs Reproducibility Package | Artifact：任何相关数字对象；复现包：经过组织、能够帮助重新运行和验证结果的制品集合。 |
与 AI 协作的通用文档指令
请为【项目名称】编写一份【文档英文全称 + 缩写】。
文档目的：【立项 / 决策 / 需求约定 / 实现设计 / 执行 / 验收 / 记录 / 汇报】
目标读者：【产品经理 / 开发者 / 测试人员 / 运维人员 / 研究者 / 审稿人】
当前阶段：【概念 / 需求 / 设计 / 实现 / 测试 / 发布 / 运营 / 投稿】
已确认事实：【……】
目标与非目标：【……】
范围与边界：【……】
已有约束：【技术、时间、预算、数据、伦理、平台等】
输出形式：【Markdown / 表格 / Mermaid / OpenAPI / YAML 等】
要求：
1. 区分已确认事实、合理假设和待决问题；
2. 不自行虚构业务事实、实验结果或利益相关者决定；
3. 需求使用可验证表述，设计说明权衡和失败处理；
4. 给每项需求、决策或测试分配稳定 ID；
5. 文末列出依赖、风险、开放问题和下一步行动。最有效的表达不是“帮我写个项目文档”，而是：
“根据这份 PRD，生成 SRS；保留业务目标，将功能转换为编号、可验证的软件需求，并单独列出非功能需求、外部接口和需求跟踪关系。”
同一项目不需要为了“文档齐全”一次性创建所有文档。只保留能够支持真实决策、执行、验收或追溯的材料，并为每类事实指定唯一维护位置，避免多份文档长期互相冲突。
