你们是否提供 PRD、原型、技术方案等文档？是否包含在合同内？

结论：提供，但“包含在合同内”必须逐项写清。签约前通常交范围说明和报价假设；完整 PRD、交互原型、UI 源文件、接口及部署方案属于付费工作，应在合同附件标明版本、格式、完成节点、确认人和是否交付源文件。

不能笼统承诺“所有文档都包含”，因为一个两周的小功能和一个多系统项目所需文档深度不同，也不能在尚未完成调研时假装已有完整 PRD。滚水科技会让文档服务于决策、开发、测试和接管，而不是为了页数制造材料。客户如果要在供应商招标前取得可交给任何团队开发的完整方案，可以先签独立的需求咨询/产品设计合同，其成果不应被免费售前方案替代。

不同合作阶段的合理交付如下：

阶段	典型文档	主要作用	合同写法建议
售前与估算	目标、首期范围、假设、不做范围、依赖与粗略里程碑	让报价有共同边界	作为报价/合同附件，不冒充完整 PRD
需求与设计	PRD、流程、角色权限、字段、状态、异常、原型与 UI 规范	确认“做什么、怎样使用”	写明轮次、页面范围、源文件和确认节点
技术设计	架构决策、数据模型、API、集成、权限、部署与非功能要求	确认“怎样实现和运维”	按复杂度列出必交内容，不要求空泛大而全
测试与上线	测试范围、缺陷清单、发布、监控、备份、回滚和培训资料	证明可上线、可恢复、可接管	与上线验收和质保起点绑定
最终交接	最新文档索引、仓库/版本、账号资产和未决事项	让客户或新团队接手	指定可编辑格式、存放位置和更新截止版本

PRD 至少描述目标用户、业务规则、正常和异常流程、角色权限、字段与状态、外部依赖、数据口径和验收场景。它不是页面截图说明书，也不是一经确认永远不变；每次变更应有版本、原因、影响和确认记录。ISO/IEC/IEEE 的 29148 需求工程标准 可作为需求活动和成果完整性的参考，但实际中小项目应选择必要内容，不必照搬成厚重模板。

原型用于尽早验证信息结构、操作路径和状态反馈。低保真原型先确认流程，高保真 UI 再确认视觉；加载、空数据、错误、无权限、长文本和移动适配等状态也应覆盖。合同要写清页面或关键流程范围、允许的修改轮次、使用 Figma/Axure 或其他格式、是否交可编辑源文件，以及第三方字体、图片和组件的许可。原型确认不等于软件验收，真实数据、性能和接口仍需开发后测试。

技术方案不应只列“前端 Vue、后端 Java、数据库 MySQL”。根据项目风险，它应记录模块边界、系统上下游、关键数据模型、身份与权限、接口和事件、第三方依赖、数据迁移、容量假设、日志监控、备份恢复和部署拓扑。接口建议提供与上线版本一致的 OpenAPI 文档；重要取舍用简短架构决策记录说明背景、选项和后果，便于后续团队理解。

文档要与版本关联。PRD、原型和接口各自有负责人、状态和最后更新时间；里程碑确认后继续修改时标记变更，而不是覆盖历史。最终交接提供一份索引，指出每份材料的位置、适用系统版本和是否仍有未决事项。只发 PDF 不一定够：客户后续需要维护的原型、设计、接口和部署资料应同时提供约定的可编辑或机器可读格式。

费用边界也要直接说明。包含在总价中，意味着报价已计算对应工作量，不等于文档免费。签约前要完整 PRD 用于多家比价，属于可独立交付的咨询成果；客户已有成熟 PRD 时，滚水科技会复核并补缺，费用可能降低，也可能因复杂度增加。超过约定修改轮次、改变核心流程或增加平台，应走变更确认，不能把所有变化都解释成“文档完善”。

验收文档不能只检查文件存在。随机选三项已上线功能，核对 PRD 规则、原型状态、接口字段、测试用例和实际系统一致；让客户技术人员按部署文档搭建或发布，让运营人员按手册完成配置。若文档无法完成这些任务，就仍需整改。滚水科技公开的 服务流程 与 透明交付标准 可作为清单起点，具体项目附件才是最终约束。