简介传智健康PRD文档1是一份健康管理系统的产品需求说明文档面向产品经理、研发工程师、测试人员及项目管理人员用于明确会员管理、预约管理、健康评估、健康干预等核心业务模块的需求边界和业务流程。文档重点展开数据结构类型管理定义了序号、指标名称、参考值、单位、针对性别等字段的格式规则、是否必填和适用范围并划分了用户、医护人员、管理员三类角色的权限与操作场景。压缩包内共1个docx格式文档整体大小约890KB内容覆盖产品概述、总体流程、功能摘要以及会员管理、预约管理、健康评估、健康干预的流程图与操作说明同时包含修订记录。该资料已有599人学习/下载适合作为健康类系统需求分析、数据库设计及原型评审的参考模板读者可直接借鉴其中的字段定义、状态拆分和交互流程提升PRD编写质量与落地效率。1. 传智健康PRD文档1一份能直接指导开发验收的需求文档该怎么写拿到“传智健康PRD文档1”这个标题先对齐一下这是某健康管理平台的第一版产品需求文档面向用户端和管理端核心模块绕不开健康档案、体检报告、健康评估和干预建议。团队立项两周开发和测试都在等这份文档但真正缺的不是“功能清单”而是功能背后那些能写进验收标准的业务规则。文档写得模糊开发靠猜测试靠感觉上线靠运气。这篇笔记就围绕一件事把这份PRD写成开发、测试、运营拿到手就能照着干活的文档。2. 写PRD之前业务边界、角色权限与核心流程先定死2.1 业务边界先圈住健康管理别把挂号问诊也塞进来任何PRD在写第一条功能之前先做减法。传智健康第一版要做的事只有一件帮助用户沉淀健康档案、看懂体检报告、拿到可执行的健康建议。挂号、问诊、买药、医保结算这些相邻业务一概不做。我一般会在PRD正文前放一张边界表用“做 / 不做 / 暂不讨论”三列把范围圈死这样评审会上八成人不会再吵方向只会讨论具体规则。范围本版做本版不做暂不讨论健康档案用户手动创建、编辑、查看自动抓取医院数据档案跨机构共享体检报告上传图片/PDF识别结构化字段对接体检中心系统电子健康卡互通健康评估基于档案和报告生成评估结果医生在线解读报告AI自动诊断干预建议按评估结果推送建议在线复诊开方药品推荐与购买这张表的写法和填法是有讲究的。“本版不做”和“暂不讨论”要区分开不做是明确否掉暂不讨论是留着以后看。一个常见错误是把“暂不讨论”当成“不做”下个版本需求一来文档又要返工。与其这样不如一开始就留一个观察区只记录不承诺。边界表确定后再去补一句话定义传智健康是一个面向个人用户的健康管理工具输入是健康档案与体检报告输出是评估结果与干预建议。这句话写进文档首页后面所有功能的取舍都拿它来卡。卡不住的就是边界没写好。2.2 角色与权限用户、健康管理师、管理员三张表PRD里的角色权限最常见的翻车点不是写漏了角色而是“同一个动作在不同角色眼里的含义不一样”。传智健康这个场景用户端和管理端的权限要分开写不要混在一张表里。我建议先列角色清单再列权限矩阵顺序不要颠倒矩阵是给开发和测试用的角色清单是给产品和运营对齐用的。角色端核心职责能不能看到他人数据普通用户用户端维护个人档案、上传报告、查看评估与建议不能只能看自己健康管理师管理端审核报告、修正识别结果、维护评估规则能看到分配给自己的用户管理员管理端管理账号、配置字典、查看系统数据能看脱敏汇总数据角色清单让每个人知道“我是谁”权限矩阵让开发和测试知道“我能点哪个按钮”。常见的做法是权限矩阵用“端 模块 动作”的粒度来写动作统一用增删改查不要出现“处理报告”“查看信息”这类模糊词。比如“管理端-报告审核-改”比“管理端-报告处理”清楚得多。写权限矩阵时还有一个容易被忽略的点数据权限和数据字段权限是两个层面。健康管理师能看分配给自己的用户报告但报告里的敏感字段比如完整证件号码要默认脱敏显示只有获得额外授权后才能展开。这个“字段级授权”如果不写开发大概率会做成整行数据一刀切后面改起来就痛了。2.3 核心业务流档案创建→报告上传→识别解析→评估建议业务流程在PRD里一般不需要画成复杂的流程图画了反而容易让阅读者陷入“图里画了但我看不懂”的困境。更稳的做法是用一段文字描述加上步骤编号把主流程说清楚再把主流程每个环节的输入、输出、角色、异常情况写成一个表。传智健康第一版的主流程分四段用户先创建或完善健康档案然后上传体检报告支持拍照和PDF系统对报告做识别解析识别不了的关键字段交给健康管理师人工确认字段齐全后系统按评估规则生成健康评估结果和干预建议。每一步都有前置条件比如报告必须在档案存在之后才能上传评估必须在关键字段齐全后才能触发。这些先后关系写清楚一条就少一次开发回头问。步骤前置条件输入输出角色1 创建档案用户已注册基础信息、既往病史档案记录普通用户2 上传报告档案状态为“已创建”报告图片或PDF原始报告附件普通用户3 识别解析附件上传成功附件、识别规则结构化报告数据系统4 人工确认识别置信度低于阈值识别结果、原图确认后的报告数据健康管理师5 生成评估关键字段齐全档案报告评估结果系统这里有一个容易被忽略的业务细节如果用户档案都还没创建直接先传报告行不行产品形态上可以允许传但业务规则上要让系统提示“请先完善档案”。把这种边界场景写进PRD的状态里后面测试用例会好写很多。3. 把功能需求写成“可验收的条目”健康档案与体检报告模块实例3.1 需求描述模板用户故事 业务规则 验收标准PRD里每个功能模块描述结构长期统一比较好。我见过最省事的模板是四段式先说用户故事再说业务规则接着写验收标准最后挂数据项。验收标准必须是一条可以逐项打勾的句子句式统一为“当……时系统……用户看到……”。这种写法解决的核心问题是开发和测试不用再猜。一个模块一个模板文档里所有功能都按这个格式填。常见做法是直接在PRD里用Markdown写方便版本管理。下面是我常用的结构### 功能点创建健康档案 **用户故事** 作为普通用户我希望录入个人基本信息和既往病史 以便后续报告评估有参照基础。 **业务规则** 1. 档案必须先于报告上传。 2. 证件号码在同一系统内唯一重复录入要拦截。 3. 新增档案时身高体重填写的合理范围身高 100-250 cm体重 20-200 kg。 4. 超出范围时不允许保存并提示具体字段错误。 **验收标准** 1. 当用户填写合法数据并点击「保存」时系统生成「草稿」状态档案 用户看到「保存成功」提示。 2. 当证件号码已存在时系统阻断提交提示「该证件已创建过档案」。 3. 当身高填 300 时系统提示「身高需在 100-250 cm 之间」。 4. 草稿状态档案不可用于评估编辑完成后可提交为「已创建」。 **数据项** - 姓名文本必填最长 20 字 - 证件类型字典默认「居民身份证」 - 证件号码文本必填唯一 - 身高数字必填单位 cm - 体重数字必填单位 kg - 既往病史多选非必填来源字典模板里的“业务规则”是最值钱的段落。大家看PRD最关心的是边界参数和异常处理但很多文档只写了功能描述没有规则。这个模板把规则拆出来其实是逼着写文档的人先去想清楚每个输入值的边界而不是一句“前端做校验”就糊弄过去。3.2 健康档案模块字段清单、校验规则与三个边界坑健康档案模块是整个传智健康的数据基石文档里除了功能描述还要单列一张字段清单。字段清单不是给产品看的是给后端建表和前端写校验用的。字段表里要写清楚字段名、类型、是否必填、默认值、校验规则、来源。字段名类型必填默认值校验规则来源namestring是无1-20字符去首尾空格用户输入idTypestring是居民身份证字典项不可自由输入用户选择idNumberstring是无按证件类型校验格式系统内唯一用户输入heightnumber是无100-250单位cm用户输入weightnumber是无20-200单位kg用户输入allergyHistorystring否无多选提示来源字典用户选择三个边界坑都是在实际写文档和开发评审时遇到的。第一个坑是证件号码的唯一性校验放在哪一端。PRD里写“唯一”是一句概念但要明确唯一性校验在保存时触发不是输入时触发。输入时提示的是格式错误保存时提示的是重复数据这两条消息文案要分开写。第二个坑是身高的合理范围和档案里的“既往病史”多选上限。多选如果不设上限用户可以勾20个病种数据库字段存得下但后续评估规则跑起来会变得混乱。我一般会写“最多选择10项”并给出超出时前端拦截还是后端拦截的说明。第三个坑最容易被漏掉档案编辑时的校验规则与创建时是否一致。很多系统创建时校验严格编辑时就松了。PRD里要写清楚“创建和编辑共用一套校验规则”一句话堵住开发偷懒的口子。3.3 体检报告上传与识别从附件到结构化数据的完整路径体检报告模块是传智健康里最容易让开发“猜需求”的地方。用户上传的是图片或PDF系统要做的是把半结构化数据变成结构化数据然后喂给评估引擎。这个环节如果PRD只写“支持上传体检报告”开发大概率只会做一个附件存储功能识别和解析全都要追问才能落地。所以这一节PRD要写四件事上传约束、识别字段映射、置信度与人工确认机制、报告状态流转。上传约束放在文档里直接写清楚支持jpg、png、pdf单文件不超过10MB一次最多上传5张图片。超出时系统提示“文件格式不支持”或“文件过大”。前端限制和后端拦截都要写防止绕过前端直接传接口。识别字段映射表是这节的核心。体检报告有几十个常见指标第一版不可能全部支持识别。我一般会在PRD里明确只识别关键字段并预留扩展机制。报告类别识别字段字段类型常见单位允许范围血常规白细胞计数 WBC数字10^9/L1.0-30.0血常规血红蛋白 HGB数字g/L30-250生化谷丙转氨酶 ALT数字U/L1-1000血脂总胆固醇 TC数字mmol/L0.5-20.0基础指标舒张压数字mmHg30-200识别置信度与人工确认机制我建议这样写系统识别后给出每个字段的置信度低于90%的字段标记为“待确认”状态变为“待人工确认”只有健康管理师修正后才能进入“已归档”。这个规则的意义在于后续评估引擎不会拿到脏数据宁可让人工介入多一些也不能让错误指标生成错误建议。这种机制在PRD里要写成状态机的形式否则测试用例不好写。报告状态至少要有已上传、识别中、待确认、已归档、已废弃。每种状态由谁触发、怎么流转下一章单独说。4. 技术侧联动数据字典、接口约定与状态机4.1 数据字典把每个字段写清楚后端才能少问三次PRD光是有人能看懂还不够后端建表要能直接对着字段表来。数据字典单独成节按模块组织每张表字段对应一条记录。列名、类型、是否必填、默认值、说明、来源都写清楚后开发阶段能少掉一大批口径确认。特别是“健康管理师备注”这种字段要说明是内部备注还是对用户可见一句话不说清楚就等着返工。字段类型必填默认值说明report_idbigint是自增报告主键user_idbigint是无关联用户表report_typestring是无灰值字典如血常规、生化file_urlstring是无附件存储地址statusstring是uploaded状态机见4.3confidence_avgdecimal否无整体平均置信度created_atdatetime是now创建时间数据字典不要写太多每个表20个字段以内就够了超过的字段要么拆表要么重新审视是不是把不必要的复杂度引进了第一版。字段太多会让评估规则和接口联调都变慢。第一版控制字段数量的收益在联调阶段会体现得非常明显。4.2 接口约定前端不要靠猜PRD里附接口清单PRD不能直接写代码逻辑但附上接口清单和关键接口的请求响应示例是让前后端少吵架的常见做法。接口清单只需要写接口名、方法、路径、入参、出参、失败场景。粗细以“前端拿到能对接”为准PRD不是接口文档不需要写完整的OpenAPI但必须在评审时确认一遍出入参。传智健康里最重要的接口是“上传体检报告”和“获取评估结果”。上传逻辑用JSON示例来描述比文字描述一百遍都清楚。POST /api/v1/reports/upload 请求体: { user_id: 10001, files: [ {type: jpg, size: 2048000, name: 血常规.jpg}, {type: pdf, size: 5120000, name: 生化报告.pdf} ] } 正常返回: { code: 0, data: { report_id: 2024001, status: recognizing, message: 上传成功识别中 } } 失败返回: { code: 10012, message: 文件格式不支持仅支持jpg/png/pdf }接口清单里最容易漏的是“失败返回”。多条失败码对应不同提示文案必须在PRD阶段就定义好。比如10010是文件过大、10011是文件为空、10012是格式不支持。这些代码写得越全前端联调时越省力。另外一个容易被忽略的约定是“上传成功后的回调方式”。报告是异步识别的前端怎么知道识别完了我一般会写明接口返回“recognizing”识别完成后通过回调通知或者前端轮询状态接口来感知。这一条不写前端要么不会做异步处理要么轮询间隔设错了。4.3 报告状态机初始态、终态和边界都要写全状态机是PRD里最容易被写漏的部分。一个务实写法是只列状态、触发事件、当前状态、目标状态、操作角色。传智健康的报告状态机我建议写成六个状态已上传、识别中、待确认、已归档、已废弃、识别失败。当前状态触发事件目标状态操作角色补充说明已上传系统开始识别识别中系统上传接口成功后自动触发识别中所有字段置信度≥90%已归档系统自动转归档识别中存在字段置信度90%待确认系统进入人工队列待确认健康管理师确认/修正已归档健康管理师此时可附加备注识别中文件无法识别识别失败系统提示用户重新上传已归档用户发起删除已废弃普通用户需二次确认注意一个细节几乎所有状态机的问题都出在“没有初始态”和“没有终态”。上传动作发生前数据库里就可能有了一条记录吗有些团队的实现是先插一条“已上传”再上传文件PRD里就要用“上传中”这个状态来兜底。终态同理已归档之后还能不能变回待确认我一般会写“已归档不可逆如需修改走重新上传”一句话堵住逻辑漏洞。状态机表里还容易忽略的是“超时处理”。比如识别中这个状态如果识别服务挂了状态卡在识别中怎么办这里我一般会加一条规则大家可以在自己的PRD里参考识别服务在2分钟内未回调状态置为识别失败前端收到失败状态时也做兜底提示。这种兜底规则不一定每次都能想到但在文档里留一个“超时与异常”的小节开发就不会自己瞎定超时时间了。5. 写PRD最常见的5个坑现象、原因与改法5.1 坑一验收标准全是“正常流程”一写异常就含糊现象文档里“报告上传成功后系统进入识别”写得很详细但问到“上传过程中断网会怎样”没人能马上回答。原因写文档时顺着主流程的思路走异常分支想得不深或者觉得异常情况开发自己会处理。改法强制在“验收标准”里加三类异常用例网络异常、数据异常、权限异常。网络异常比如上传一半断网数据异常比如上传的是空白图片权限异常比如用户已被禁用三个用例各写一条具体提示文案。模板做好了写文档的人只要按格子填就不会漏。5.2 坑二状态机只有正常流转没有初始态和终态现象文档里报告状态写“待确认→已归档”开发问“新建的报告记录初始状态是什么”“识别失败算终态吗”全都没有答案。原因画状态机时只画了业务路径的中间节点倒推少了起点和终点。改法PRD里规定每个实体都必须画完整的“状态-触发-角色”表并且评审时把三种状态单独问一遍初始态、终态、异常态。初始态要能对应到数据落库的第一个动作终态要明确是否可逆异常态要写明恢复措施。这个习惯养成后开发阶段的状态字段设计会顺利很多。5.3 坑三权限描述用“能/不能”的句子而不是矩阵现象开发问“管理端的健康管理师能不能编辑用户档案”产品翻遍文档找不到一条确切描述只能在群里现问答。原因权限用自然语言写时同一个动词在不同角色间排列组合太多文档写着写着就漏了。改法每个角色对应一个模块权限矩阵行列交叉处填“增/删/改/查/无”。矩阵能一眼看出漏项而且评审时拿着矩阵逐行过比翻句子高效得多。传智健康这种有一个用户端加一个管理端的系统建议用户端单独列一张矩阵不要和管理端混在一起。5.4 坑四业务规则的边界值不写全靠开发“合理猜测”现象字段校验写成“身高填合理范围”结果前端觉得100-200合理后端觉得50-250合理两边对不上用户被不同的校验结果反复折腾。原因文本表述里的“合理”是主观判断不同人理解不同而且大多数“合理”这个词出现在文档里时背后都没有经过数值推演。改法所有可量化的规则一律写边界值。身高写100-250且单位cm体重写20-200且单位kg。没法量化的规则写判断标准比如“置信度低于90%”这里的90就是可执行标准。记住一句话宁可规则定得死不要定得巧。5.5 坑五修改记录不建立第2版来了PRD还是旧的现象需求和开发同步改了几轮后文档和代码已经对不上了后面接手的人看着文档里的旧逻辑干活做出来的功能和新需求完全脱节。原因PRD写完就算完事中间变更全靠口头转述没有回写文档的机制。改法每份PRD开头放一张“变更记录”表列版本号、变更人、日期、变更点。每次有需求变更顺手填一行不需要写长篇一行字即可。这个习惯虽然有点机械但等到第三版回看时你会感谢当时坚持做了记录。6. 文档写完不算完用评审清单和验收用例把逻辑收口评审清单是文档定稿前要过一轮的检查项我一般会把上面五个坑的要点反向做成清单。每一条在评审会上问一遍角色权限矩阵有没有全改到位、状态机有没有初始态和终态、验收标准里有没有异常用例、边界值有没有量化、变更记录有没有更新。清单不必长五到八条足够关键是评审时逐条签字确认而不是“整体看一下有没有问题”。评审通过后建议按PRD的验收标准做一份验收用例表这样UAT阶段可以直接拿来标记完成度。用例编号用例名称前置条件操作步骤预期结果状态TC-01创建合法档案已登录填写合法数据并保存保存成功档案状态为草稿待执行TC-02重复证件号拦截已存在档案再创建同证件档案提示证件已存在阻断提交待执行TC-03上传不支持的格式档案已创建上传gif文件提示格式不支持不产生报告待执行TC-04低置信度转人工确认上传带手写体检单照片等待识别完成状态为待确认可人工修正待执行验收用例这里有个小技巧用例的预期结果要原样抄PRD里的验收标准句子不要重新措辞。重新措辞会造成“文档说A、用例说B”的分裂到时候开发觉得测试在找茬不重新措辞就能避免这个问题。做这类文档的习惯我自己已经坚持了三四年文档写完先不放评审自己对着每一章检查一遍检查只看两件事——能否被开发直接执行、能否被测试直接验证。有一项答不上来就回去补不补完不进评审室。这个习惯帮我省下过不少后续改代码的麻烦。希望帮到你。本文还有配套的精品资源点击获取 
长河君 · 2026/10/13 13:33:31 · 阅读 1.2k 传智健康PRD实战：业务规则、状态机与验收标准全解析
简介传智健康PRD文档1是一份健康管理系统的产品需求说明文档面向产品经理、研发工程师、测试人员及项目管理人员用于明确会员管理、预约管理、健康评估、健康干预等核心业务模块的需求边界和业务流程。文档重点展开数据结构类型管理定义了序号、指标名称、参考值、单位、针对性别等字段的格式规则、是否必填和适用范围并划分了用户、医护人员、管理员三类角色的权限与操作场景。压缩包内共1个docx格式文档整体大小约890KB内容覆盖产品概述、总体流程、功能摘要以及会员管理、预约管理、健康评估、健康干预的流程图与操作说明同时包含修订记录。该资料已有599人学习/下载适合作为健康类系统需求分析、数据库设计及原型评审的参考模板读者可直接借鉴其中的字段定义、状态拆分和交互流程提升PRD编写质量与落地效率。1. 传智健康PRD文档1一份能直接指导开发验收的需求文档该怎么写拿到“传智健康PRD文档1”这个标题先对齐一下这是某健康管理平台的第一版产品需求文档面向用户端和管理端核心模块绕不开健康档案、体检报告、健康评估和干预建议。团队立项两周开发和测试都在等这份文档但真正缺的不是“功能清单”而是功能背后那些能写进验收标准的业务规则。文档写得模糊开发靠猜测试靠感觉上线靠运气。这篇笔记就围绕一件事把这份PRD写成开发、测试、运营拿到手就能照着干活的文档。2. 写PRD之前业务边界、角色权限与核心流程先定死2.1 业务边界先圈住健康管理别把挂号问诊也塞进来任何PRD在写第一条功能之前先做减法。传智健康第一版要做的事只有一件帮助用户沉淀健康档案、看懂体检报告、拿到可执行的健康建议。挂号、问诊、买药、医保结算这些相邻业务一概不做。我一般会在PRD正文前放一张边界表用“做 / 不做 / 暂不讨论”三列把范围圈死这样评审会上八成人不会再吵方向只会讨论具体规则。范围本版做本版不做暂不讨论健康档案用户手动创建、编辑、查看自动抓取医院数据档案跨机构共享体检报告上传图片/PDF识别结构化字段对接体检中心系统电子健康卡互通健康评估基于档案和报告生成评估结果医生在线解读报告AI自动诊断干预建议按评估结果推送建议在线复诊开方药品推荐与购买这张表的写法和填法是有讲究的。“本版不做”和“暂不讨论”要区分开不做是明确否掉暂不讨论是留着以后看。一个常见错误是把“暂不讨论”当成“不做”下个版本需求一来文档又要返工。与其这样不如一开始就留一个观察区只记录不承诺。边界表确定后再去补一句话定义传智健康是一个面向个人用户的健康管理工具输入是健康档案与体检报告输出是评估结果与干预建议。这句话写进文档首页后面所有功能的取舍都拿它来卡。卡不住的就是边界没写好。2.2 角色与权限用户、健康管理师、管理员三张表PRD里的角色权限最常见的翻车点不是写漏了角色而是“同一个动作在不同角色眼里的含义不一样”。传智健康这个场景用户端和管理端的权限要分开写不要混在一张表里。我建议先列角色清单再列权限矩阵顺序不要颠倒矩阵是给开发和测试用的角色清单是给产品和运营对齐用的。角色端核心职责能不能看到他人数据普通用户用户端维护个人档案、上传报告、查看评估与建议不能只能看自己健康管理师管理端审核报告、修正识别结果、维护评估规则能看到分配给自己的用户管理员管理端管理账号、配置字典、查看系统数据能看脱敏汇总数据角色清单让每个人知道“我是谁”权限矩阵让开发和测试知道“我能点哪个按钮”。常见的做法是权限矩阵用“端 模块 动作”的粒度来写动作统一用增删改查不要出现“处理报告”“查看信息”这类模糊词。比如“管理端-报告审核-改”比“管理端-报告处理”清楚得多。写权限矩阵时还有一个容易被忽略的点数据权限和数据字段权限是两个层面。健康管理师能看分配给自己的用户报告但报告里的敏感字段比如完整证件号码要默认脱敏显示只有获得额外授权后才能展开。这个“字段级授权”如果不写开发大概率会做成整行数据一刀切后面改起来就痛了。2.3 核心业务流档案创建→报告上传→识别解析→评估建议业务流程在PRD里一般不需要画成复杂的流程图画了反而容易让阅读者陷入“图里画了但我看不懂”的困境。更稳的做法是用一段文字描述加上步骤编号把主流程说清楚再把主流程每个环节的输入、输出、角色、异常情况写成一个表。传智健康第一版的主流程分四段用户先创建或完善健康档案然后上传体检报告支持拍照和PDF系统对报告做识别解析识别不了的关键字段交给健康管理师人工确认字段齐全后系统按评估规则生成健康评估结果和干预建议。每一步都有前置条件比如报告必须在档案存在之后才能上传评估必须在关键字段齐全后才能触发。这些先后关系写清楚一条就少一次开发回头问。步骤前置条件输入输出角色1 创建档案用户已注册基础信息、既往病史档案记录普通用户2 上传报告档案状态为“已创建”报告图片或PDF原始报告附件普通用户3 识别解析附件上传成功附件、识别规则结构化报告数据系统4 人工确认识别置信度低于阈值识别结果、原图确认后的报告数据健康管理师5 生成评估关键字段齐全档案报告评估结果系统这里有一个容易被忽略的业务细节如果用户档案都还没创建直接先传报告行不行产品形态上可以允许传但业务规则上要让系统提示“请先完善档案”。把这种边界场景写进PRD的状态里后面测试用例会好写很多。3. 把功能需求写成“可验收的条目”健康档案与体检报告模块实例3.1 需求描述模板用户故事 业务规则 验收标准PRD里每个功能模块描述结构长期统一比较好。我见过最省事的模板是四段式先说用户故事再说业务规则接着写验收标准最后挂数据项。验收标准必须是一条可以逐项打勾的句子句式统一为“当……时系统……用户看到……”。这种写法解决的核心问题是开发和测试不用再猜。一个模块一个模板文档里所有功能都按这个格式填。常见做法是直接在PRD里用Markdown写方便版本管理。下面是我常用的结构### 功能点创建健康档案 **用户故事** 作为普通用户我希望录入个人基本信息和既往病史 以便后续报告评估有参照基础。 **业务规则** 1. 档案必须先于报告上传。 2. 证件号码在同一系统内唯一重复录入要拦截。 3. 新增档案时身高体重填写的合理范围身高 100-250 cm体重 20-200 kg。 4. 超出范围时不允许保存并提示具体字段错误。 **验收标准** 1. 当用户填写合法数据并点击「保存」时系统生成「草稿」状态档案 用户看到「保存成功」提示。 2. 当证件号码已存在时系统阻断提交提示「该证件已创建过档案」。 3. 当身高填 300 时系统提示「身高需在 100-250 cm 之间」。 4. 草稿状态档案不可用于评估编辑完成后可提交为「已创建」。 **数据项** - 姓名文本必填最长 20 字 - 证件类型字典默认「居民身份证」 - 证件号码文本必填唯一 - 身高数字必填单位 cm - 体重数字必填单位 kg - 既往病史多选非必填来源字典模板里的“业务规则”是最值钱的段落。大家看PRD最关心的是边界参数和异常处理但很多文档只写了功能描述没有规则。这个模板把规则拆出来其实是逼着写文档的人先去想清楚每个输入值的边界而不是一句“前端做校验”就糊弄过去。3.2 健康档案模块字段清单、校验规则与三个边界坑健康档案模块是整个传智健康的数据基石文档里除了功能描述还要单列一张字段清单。字段清单不是给产品看的是给后端建表和前端写校验用的。字段表里要写清楚字段名、类型、是否必填、默认值、校验规则、来源。字段名类型必填默认值校验规则来源namestring是无1-20字符去首尾空格用户输入idTypestring是居民身份证字典项不可自由输入用户选择idNumberstring是无按证件类型校验格式系统内唯一用户输入heightnumber是无100-250单位cm用户输入weightnumber是无20-200单位kg用户输入allergyHistorystring否无多选提示来源字典用户选择三个边界坑都是在实际写文档和开发评审时遇到的。第一个坑是证件号码的唯一性校验放在哪一端。PRD里写“唯一”是一句概念但要明确唯一性校验在保存时触发不是输入时触发。输入时提示的是格式错误保存时提示的是重复数据这两条消息文案要分开写。第二个坑是身高的合理范围和档案里的“既往病史”多选上限。多选如果不设上限用户可以勾20个病种数据库字段存得下但后续评估规则跑起来会变得混乱。我一般会写“最多选择10项”并给出超出时前端拦截还是后端拦截的说明。第三个坑最容易被漏掉档案编辑时的校验规则与创建时是否一致。很多系统创建时校验严格编辑时就松了。PRD里要写清楚“创建和编辑共用一套校验规则”一句话堵住开发偷懒的口子。3.3 体检报告上传与识别从附件到结构化数据的完整路径体检报告模块是传智健康里最容易让开发“猜需求”的地方。用户上传的是图片或PDF系统要做的是把半结构化数据变成结构化数据然后喂给评估引擎。这个环节如果PRD只写“支持上传体检报告”开发大概率只会做一个附件存储功能识别和解析全都要追问才能落地。所以这一节PRD要写四件事上传约束、识别字段映射、置信度与人工确认机制、报告状态流转。上传约束放在文档里直接写清楚支持jpg、png、pdf单文件不超过10MB一次最多上传5张图片。超出时系统提示“文件格式不支持”或“文件过大”。前端限制和后端拦截都要写防止绕过前端直接传接口。识别字段映射表是这节的核心。体检报告有几十个常见指标第一版不可能全部支持识别。我一般会在PRD里明确只识别关键字段并预留扩展机制。报告类别识别字段字段类型常见单位允许范围血常规白细胞计数 WBC数字10^9/L1.0-30.0血常规血红蛋白 HGB数字g/L30-250生化谷丙转氨酶 ALT数字U/L1-1000血脂总胆固醇 TC数字mmol/L0.5-20.0基础指标舒张压数字mmHg30-200识别置信度与人工确认机制我建议这样写系统识别后给出每个字段的置信度低于90%的字段标记为“待确认”状态变为“待人工确认”只有健康管理师修正后才能进入“已归档”。这个规则的意义在于后续评估引擎不会拿到脏数据宁可让人工介入多一些也不能让错误指标生成错误建议。这种机制在PRD里要写成状态机的形式否则测试用例不好写。报告状态至少要有已上传、识别中、待确认、已归档、已废弃。每种状态由谁触发、怎么流转下一章单独说。4. 技术侧联动数据字典、接口约定与状态机4.1 数据字典把每个字段写清楚后端才能少问三次PRD光是有人能看懂还不够后端建表要能直接对着字段表来。数据字典单独成节按模块组织每张表字段对应一条记录。列名、类型、是否必填、默认值、说明、来源都写清楚后开发阶段能少掉一大批口径确认。特别是“健康管理师备注”这种字段要说明是内部备注还是对用户可见一句话不说清楚就等着返工。字段类型必填默认值说明report_idbigint是自增报告主键user_idbigint是无关联用户表report_typestring是无灰值字典如血常规、生化file_urlstring是无附件存储地址statusstring是uploaded状态机见4.3confidence_avgdecimal否无整体平均置信度created_atdatetime是now创建时间数据字典不要写太多每个表20个字段以内就够了超过的字段要么拆表要么重新审视是不是把不必要的复杂度引进了第一版。字段太多会让评估规则和接口联调都变慢。第一版控制字段数量的收益在联调阶段会体现得非常明显。4.2 接口约定前端不要靠猜PRD里附接口清单PRD不能直接写代码逻辑但附上接口清单和关键接口的请求响应示例是让前后端少吵架的常见做法。接口清单只需要写接口名、方法、路径、入参、出参、失败场景。粗细以“前端拿到能对接”为准PRD不是接口文档不需要写完整的OpenAPI但必须在评审时确认一遍出入参。传智健康里最重要的接口是“上传体检报告”和“获取评估结果”。上传逻辑用JSON示例来描述比文字描述一百遍都清楚。POST /api/v1/reports/upload 请求体: { user_id: 10001, files: [ {type: jpg, size: 2048000, name: 血常规.jpg}, {type: pdf, size: 5120000, name: 生化报告.pdf} ] } 正常返回: { code: 0, data: { report_id: 2024001, status: recognizing, message: 上传成功识别中 } } 失败返回: { code: 10012, message: 文件格式不支持仅支持jpg/png/pdf }接口清单里最容易漏的是“失败返回”。多条失败码对应不同提示文案必须在PRD阶段就定义好。比如10010是文件过大、10011是文件为空、10012是格式不支持。这些代码写得越全前端联调时越省力。另外一个容易被忽略的约定是“上传成功后的回调方式”。报告是异步识别的前端怎么知道识别完了我一般会写明接口返回“recognizing”识别完成后通过回调通知或者前端轮询状态接口来感知。这一条不写前端要么不会做异步处理要么轮询间隔设错了。4.3 报告状态机初始态、终态和边界都要写全状态机是PRD里最容易被写漏的部分。一个务实写法是只列状态、触发事件、当前状态、目标状态、操作角色。传智健康的报告状态机我建议写成六个状态已上传、识别中、待确认、已归档、已废弃、识别失败。当前状态触发事件目标状态操作角色补充说明已上传系统开始识别识别中系统上传接口成功后自动触发识别中所有字段置信度≥90%已归档系统自动转归档识别中存在字段置信度90%待确认系统进入人工队列待确认健康管理师确认/修正已归档健康管理师此时可附加备注识别中文件无法识别识别失败系统提示用户重新上传已归档用户发起删除已废弃普通用户需二次确认注意一个细节几乎所有状态机的问题都出在“没有初始态”和“没有终态”。上传动作发生前数据库里就可能有了一条记录吗有些团队的实现是先插一条“已上传”再上传文件PRD里就要用“上传中”这个状态来兜底。终态同理已归档之后还能不能变回待确认我一般会写“已归档不可逆如需修改走重新上传”一句话堵住逻辑漏洞。状态机表里还容易忽略的是“超时处理”。比如识别中这个状态如果识别服务挂了状态卡在识别中怎么办这里我一般会加一条规则大家可以在自己的PRD里参考识别服务在2分钟内未回调状态置为识别失败前端收到失败状态时也做兜底提示。这种兜底规则不一定每次都能想到但在文档里留一个“超时与异常”的小节开发就不会自己瞎定超时时间了。5. 写PRD最常见的5个坑现象、原因与改法5.1 坑一验收标准全是“正常流程”一写异常就含糊现象文档里“报告上传成功后系统进入识别”写得很详细但问到“上传过程中断网会怎样”没人能马上回答。原因写文档时顺着主流程的思路走异常分支想得不深或者觉得异常情况开发自己会处理。改法强制在“验收标准”里加三类异常用例网络异常、数据异常、权限异常。网络异常比如上传一半断网数据异常比如上传的是空白图片权限异常比如用户已被禁用三个用例各写一条具体提示文案。模板做好了写文档的人只要按格子填就不会漏。5.2 坑二状态机只有正常流转没有初始态和终态现象文档里报告状态写“待确认→已归档”开发问“新建的报告记录初始状态是什么”“识别失败算终态吗”全都没有答案。原因画状态机时只画了业务路径的中间节点倒推少了起点和终点。改法PRD里规定每个实体都必须画完整的“状态-触发-角色”表并且评审时把三种状态单独问一遍初始态、终态、异常态。初始态要能对应到数据落库的第一个动作终态要明确是否可逆异常态要写明恢复措施。这个习惯养成后开发阶段的状态字段设计会顺利很多。5.3 坑三权限描述用“能/不能”的句子而不是矩阵现象开发问“管理端的健康管理师能不能编辑用户档案”产品翻遍文档找不到一条确切描述只能在群里现问答。原因权限用自然语言写时同一个动词在不同角色间排列组合太多文档写着写着就漏了。改法每个角色对应一个模块权限矩阵行列交叉处填“增/删/改/查/无”。矩阵能一眼看出漏项而且评审时拿着矩阵逐行过比翻句子高效得多。传智健康这种有一个用户端加一个管理端的系统建议用户端单独列一张矩阵不要和管理端混在一起。5.4 坑四业务规则的边界值不写全靠开发“合理猜测”现象字段校验写成“身高填合理范围”结果前端觉得100-200合理后端觉得50-250合理两边对不上用户被不同的校验结果反复折腾。原因文本表述里的“合理”是主观判断不同人理解不同而且大多数“合理”这个词出现在文档里时背后都没有经过数值推演。改法所有可量化的规则一律写边界值。身高写100-250且单位cm体重写20-200且单位kg。没法量化的规则写判断标准比如“置信度低于90%”这里的90就是可执行标准。记住一句话宁可规则定得死不要定得巧。5.5 坑五修改记录不建立第2版来了PRD还是旧的现象需求和开发同步改了几轮后文档和代码已经对不上了后面接手的人看着文档里的旧逻辑干活做出来的功能和新需求完全脱节。原因PRD写完就算完事中间变更全靠口头转述没有回写文档的机制。改法每份PRD开头放一张“变更记录”表列版本号、变更人、日期、变更点。每次有需求变更顺手填一行不需要写长篇一行字即可。这个习惯虽然有点机械但等到第三版回看时你会感谢当时坚持做了记录。6. 文档写完不算完用评审清单和验收用例把逻辑收口评审清单是文档定稿前要过一轮的检查项我一般会把上面五个坑的要点反向做成清单。每一条在评审会上问一遍角色权限矩阵有没有全改到位、状态机有没有初始态和终态、验收标准里有没有异常用例、边界值有没有量化、变更记录有没有更新。清单不必长五到八条足够关键是评审时逐条签字确认而不是“整体看一下有没有问题”。评审通过后建议按PRD的验收标准做一份验收用例表这样UAT阶段可以直接拿来标记完成度。用例编号用例名称前置条件操作步骤预期结果状态TC-01创建合法档案已登录填写合法数据并保存保存成功档案状态为草稿待执行TC-02重复证件号拦截已存在档案再创建同证件档案提示证件已存在阻断提交待执行TC-03上传不支持的格式档案已创建上传gif文件提示格式不支持不产生报告待执行TC-04低置信度转人工确认上传带手写体检单照片等待识别完成状态为待确认可人工修正待执行验收用例这里有个小技巧用例的预期结果要原样抄PRD里的验收标准句子不要重新措辞。重新措辞会造成“文档说A、用例说B”的分裂到时候开发觉得测试在找茬不重新措辞就能避免这个问题。做这类文档的习惯我自己已经坚持了三四年文档写完先不放评审自己对着每一章检查一遍检查只看两件事——能否被开发直接执行、能否被测试直接验证。有一项答不上来就回去补不补完不进评审室。这个习惯帮我省下过不少后续改代码的麻烦。希望帮到你。本文还有配套的精品资源点击获取