你是来找一份产品规格模板的——章节、标题、一套能照着开发的结构。它就在下面,拿去用。规格是离实现最近的那份文档:不是"做什么、为什么"(那是 PRD),而是"具体怎么做"。麻烦出在它住在哪里。写进一份独立文档,它就和上游的 PRD、决策断了联系——于是上面某个决定一改,规格还在描述一个你早已不做的东西,工程师(或 AI agent)照着一份虚构开发。Draftlize 给你同样这八节,把每一节做成一张连着它所依赖决策的卡片,任何一个决策一动,就把规格标为 stale。
这就是整份规格模板。在文档、wiki 或 markdown 里都能用——一份好的功能规格或技术规格本来就是这个形状。原样拿去。下一节讲的是:当每一部分不再是文档里的一个标题、而是一张知道自己依赖什么的卡片时,会发生什么。
这个功能是什么、面向用户产出什么结果,几行讲完。不写商业理由——那是 PRD 的事——但要让读的人在需求开始前先知道自己要做的是什么。
系统会做什么,写成具体、可验证的行为。"用户在标题为空时提交,显示内联错误并阻止保存。"一条需求若不能变成一个测试用例,它还只是愿望,不是规格。
实现的形状:有哪些组件、怎么流转、关键取舍以及为什么选这条而不是那条显而易见的路。规格的价值大半在这里——这是编码 agent 用来避免把已经定过的事重新定一遍的那一节。
表、字段、类型、接口——其它代码要遵守的那层表面。最贵的错都出在这一节,下游又最先把它写死,所以它最需要可被引用,而不是埋在某处。
空、并发、离线、格式错误、被限流、半途失败。demo 和产品之间的差距,全部住在这里——也是当 happy path 的设计一改、没人回头看边界时,最先悄悄烂掉的一节。
这份规格假定成立的那些决策、其它规格、服务——定价那个决定、鉴权模型、隔壁两个功能用的那张表。写进文档里,这是一份你会忘记更新的清单。当它上面的世界变动时,正是这一节决定规格还真不真。
你凭什么知道它能用:哪些用例必须通过、哪些行为必须成立。写在代码之前,这是"上线了"和"上线了,大概吧"之间的那条线。写在代码之后,它就只是在描述代码碰巧做成了什么。
开关、迁移、灰度、回滚。怎么把它送到用户面前而不毁掉某个夜晚——以及万一出事怎么把它收回来。人人都跳过的那一节,也是 on-call 工程师最希望它当初存在的那一节。
这就是模板。下面讲:写在文档里的规格,为什么会从上面的 PRD 漂走——以及我们怎么处理。
PRD 说做什么、为什么;规格说具体怎么做。这是一种真实的依赖:只有它要实现的那份 PRD 仍然成立时,这份规格才说得通。但在两份独立文档里,没有任何东西记下这层联系,于是规格自由漂浮——而它离实现越近,错的时候越贵。
一个决定变了——定价模型、鉴权流程、核心对象上的某个字段。PRD 也许更新了。建立在旧决定上的规格却没有,因为同步它是手工活,还要和发布抢时间。于是数据模型和边界态描述的是一个不再存在的系统,而没有任何横幅提示这件事。
把一份文档交给编码 agent,它会精确实现文档所说的——包括三个 commit 之前就悄悄过期的那些部分。一份说不清自己哪几节还可信的规格,比没有规格更糟:它给错误的实现镀上了一层虚假的信心。
在 Draftlize 里,规格不是一份大文档——每一部分都是一张有类型的卡片:概述、功能需求、技术方案、数据模型 / API、边界态、依赖、测试标准、发布。结构化、可按 ID 引用,能从一个 thread 或一份姊妹规格里被引,而不是埋在某个 wiki 标题下面。
因为"依赖"是指向上游决策的真实链接——不是一串名词——其中某个决策一改,建立在它之上的规格卡片就自动变 stale。在开发场景里我们叫它 drift_detected:底座注意到这份实现规格已经和它当初所依据的决定对不上了,就像构建系统让一个被改文件的所有下游全部失效。
Claude Code 或 Cursor,经 MCP,在写下一行代码之前先读这份活的规格——并在同一个表面上看到哪些节被标 stale、为什么。规格不再是一张 agent 盲信的快照,而成为它每一轮都重读、并更新到最近一个决策的上下文。
PRD 说做什么,规格说怎么做。只有上面的决策仍然成立,照着规格开发才安全——所以,让那些决策在变动时来标记它。留下这八节,让底座替你保持它们同步。
产品规格是离实现最近的那份文档：不是「做什么、为什么」——那是 PRD——而是「具体怎么做」。它把行为、状态、边缘情况和约束讲到足够细，让工程师或 AI agent 不用猜就能实现。
PRD 定意图——问题、用户、想要的结果。spec 把意图变成精确的行为。PRD 说「用户可以恢复被删的项目」；spec 讲清恢复具体怎么走、保留多久、要什么权限、每种失败下会怎样。一个决定做什么，另一个定义它怎么工作。
通常是：概述、目标与非目标、详细行为或用户流程、状态与边缘情况、技术约束、依赖、以及待解问题。上面这份模板都覆盖了——直接在文档、wiki 或 markdown 文件里用。
问题在于 spec 会和 PRD、和它上面的决策断了联系，于是上游一改，spec 还在描述一个你早已不做的东西。Draftlize 把每一节接到它所依赖的决策上，任何一个一动就把 spec 标成 stale，让工程师或 agent 永远不会照着一份僵死的旧版开发。
把上面那份模板拿去用,或者开一个项目,让 agent 从你的 PRD 和决策里把规格起草出来——然后在你开发时,替你把每一节、以及它所依赖的那些决定,一直保持同步。
注册送 $5,免费开始一键创建项目：这些章节会预置成结构化、互相链接的卡片。和 agent 一起回答它们——之后任何决策变了，依赖它的章节会自动标记过时，而不是悄悄失真。注册送 $5 额度，无需绑卡。