功能规格说明书撰写指南

问题在哪

功能规格说明书（FSD）只定义系统做什么：功能需求、行为规则、接口约定与异常处理，不写实现细节。团队常见问题是需求与设计混写、流程只写 Happy Path、接口缺类型与边界，以及「快速响应」这类无法验收的表述——测试和评审因此反复扯皮。

技能如何帮你写规约

本技能按文档级 → 功能级 → 可测试性组织输出，核心包括：

• 适用边界：明确 FSD 与架构设计、代码 Review、轻量 README 的分工；场景表区分「行为规约 / API 契约」与「算法、表结构、用户手册」。
• 通用结构：文档概述、功能清单（F-001 编号与依赖）、功能详述（前置条件、正常/扩展/异常流程、规则与约束、接口表）、非功能需求。
• 撰写原则：正确性、无歧义、完整性、一致性、可测试性、可追溯性；对照反模式表（实现细节、模糊副词、UI 混入等）改写法。
• 模板与评审：AUTOSAR/嵌入式与 Web/API 请求响应示例；评审清单 + One-Shot 流程（通读 → 逐项核对 → 结论：通过/有条件通过/不通过 → 按 P0/P1 给修改建议）。

注意边界

纯代码 Review、架构图、需求调研应换用对应技能。规约里若出现线程、内存分配等「怎么做」，应挪到设计文档；读者含测试与 PM 时，异常路径与接口参数（必选/可选、默认值、错误码）不宜省略。