1) 文档摘要（示例）
丙方公司｜逆生成目的：给甲方一个“可验收”的功能基线
本《功能式样书》为“从源码/画面/接口反推”的结构化整理：它不是乙方正式需求定义书，
但可作为甲方验收时的“功能清单 + 可讨论依据”。本示例以“母婴会所 App”常见业务推测构成。
功能域覆盖（示例）
8 个模块
预约 · 会员 · 订单 · 支付 · 护理师 · 评价 · 消息 · 后台
目标端（示例）
3 个 App + 2 Web
B端/C端/护理师端 + H5 + 小程序
验收用“关键路径”
12 条
用于上线前动作确认（非本番测试）
2) 端 × 模块覆盖矩阵（示例）
用于快速确认“哪些功能在哪个端存在/缺失”
| 模块 | B端 App（会所） | C端 App（客户） | 护理师端 App | H5 | 小程序 |
|---|---|---|---|---|---|
| 账号/权限 | 门店员工角色 | 手机号/微信 | 实名认证 | 仅登录 | 微信授权 |
| 预约/排班 | 排班/修改 | 预约下单 | 接单/改期 | 展示/下单 | 简化预约 |
| 订单/支付 | 收款/退款 | 订单/支付 | 仅查看 | 支付页 | 微信支付 |
| 会员/积分 | 会员管理 | 会员权益 | — | — | 卡券 |
| 护理师服务 | 查看档案 | 选择护理师 | 服务记录 | — | — |
| 消息/IM | 通知 | IM/通知 | IM/通知 | — | 通知 |
注：绿色/黄色为示例标注（非真实结果），用于表达“存在/部分存在/缺失”的呈现方式。
3) 核心功能页示例：C端「预约下单」
以“可验收”为目标：流程、画面、接口、数据、异常点
所属模块：预约/排班
端：C端 App / H5（部分）/ 小程序（简化）
验收关注：流程完整性
主流程（示例）
- 用户选择会所门店 → 查看服务项目与可预约时间
- 选择服务项目（如：月子护理 / 产后修复 / 婴儿护理）
- 选择时间段与护理师（可选：系统推荐/手动指定）
- 填写顾客/宝宝基础信息（必要字段：姓名/手机号/预产期/宝宝月龄等）
- 确认订单 → 支付（微信/支付宝/店内收款等）
- 生成预约单：状态=已支付/待服务 → 推送通知（客户/护理师/门店）
| 画面（推测） | 入口 | 关键字段/交互点 |
|---|---|---|
| 门店/服务选择页 | 首页 → 门店 | store_id、服务分类、价格、可预约图标 |
| 时间段选择页 | 服务详情 → 预约 | 可预约时段、满员提示、改期规则提示 |
| 护理师选择页 | 时间段确认 | 推荐逻辑（评分/距离/排班）、可指定护理师 |
| 订单确认/支付页 | 提交预约 | 折扣/卡券、支付方式、发票信息（若有） |
相关接口（示例）
REST / JSON
GET /api/stores/{store_id}/services
GET /api/stores/{store_id}/slots?date=YYYY-MM-DD
GET /api/matrons?store_id=...&slot_id=...
POST /api/orders (预约下单)
POST /api/payments (发起支付)
POST /api/notifications/push (通知)
GET /api/stores/{store_id}/slots?date=YYYY-MM-DD
GET /api/matrons?store_id=...&slot_id=...
POST /api/orders (预约下单)
POST /api/payments (发起支付)
POST /api/notifications/push (通知)
注：接口命名为示例推测，用于展示“写法与结构”。
验收关注点（示例）
① 若护理师满员：是否有明确提示 + 可替代方案？
② 支付失败/超时：订单状态是否可恢复？是否会产生“已扣款未生单”？
③ 改期/取消：规则是否一致地体现在 C端/护理师端/B端？
① 若护理师满员：是否有明确提示 + 可替代方案？
② 支付失败/超时：订单状态是否可恢复？是否会产生“已扣款未生单”？
③ 改期/取消：规则是否一致地体现在 C端/护理师端/B端？
验收结论栏（留空给甲方确认）
・功能是否满足当初需求：［未确认］
・是否存在遗漏/偏差：［未确认］
・需要乙方补充说明：［未确认］
・功能是否满足当初需求：［未确认］
・是否存在遗漏/偏差：［未确认］
・需要乙方补充说明：［未确认］
1) 报告摘要（示例）
丙方公司｜静态分析：完成度 Check + 隐患推测（不含单体/结合测试）
整体风险等级（示例）
中高
依据：配置/密钥管理 + 异常处理 + 依赖治理
完成度（示例）
约 80%
存在“UI 已有但逻辑不完整”的可疑点
重点服务（示例）
business / management
babysky-business-service-provider.jar 等
2) 代码体量与构成（示例）
来自你提供的表格“代码量（行）”
| 工程 | 代码量 | 关注度 |
|---|---|---|
| babysky-business-service-provider.jar | 1,018,400 | 最高 |
| babysky-management-rpc-service.jar | 420,000 | 高 |
| 悦母婴会所B端_APP_IOS | 600,000 | 高 |
| 悦母婴护理师端_APP_Android | 55,000 | 中 |
注：此处仅演示“报告如何引用你整理的数据并落到风险关注点”。
3) 风险分布（示例）
用简易条形展示：高/中/低 Issue 数占比
严重度占比（示例）
High
7
Medium
9
Low
6
高风险（上线阻断/合规/安全）
中风险（稳定性/可维护性）
低风险（规范/轻微缺陷）
注：条形长度由 Issue List 示例数据自动计算。
4) 典型隐患示例（推测）
每条都包含：现象 → 风险 → 建议 → 证据定位（示例写法）
| 隐患/问题（示例） | 风险说明（示例） | 建议（示例） | 证据（示例） |
|---|---|---|---|
| 配置/密钥疑似明文散落 | 可能导致第三方账号/Key 泄露；上线后难以追溯与轮换 | 统一采用环境变量/密钥服务；最小权限 & 定期轮换；提交前做密钥扫描 | resources/*.yml client keys |
| 异常处理与错误码不统一 | 前端难以稳定处理失败；可能出现“失败但提示成功”的体验 | 定义全局错误码规范；统一返回结构；关键路径加审计日志 | GlobalExceptionHandler? |
| 订单状态机缺少“幂等”保护 | 支付回调/重试可能造成重复创建订单、重复扣款或状态错乱 | 对支付/回调引入幂等键；对关键写操作加唯一约束与事务边界 | order_service payment_callback |
| 日志可能包含个人信息 | 涉及姓名/电话/宝宝信息等，可能触发隐私合规风险 | 日志脱敏；PII 单独审计；访问权限隔离 | log.info(user) |
重要：以上仅示例“报告写法”。真实结论需以源码/配置/流程实际取证为准。
1) 上线前动作确认（Smoke Check）摘要（示例）
声明：本番动作确认 ≠ 本番测试｜不覆盖系统级全面测试
本报告用于上线前最后确认“主干功能可跑通”。丙方公司仅记录动作确认的范围、前提条件、步骤与结果，
并输出指摘点；不承担乙方的测试代行与品质保证（QA）职责。
2) 环境与前提条件（示例）
上线前信息必须齐备（账号/配置/依赖）
| 项目 | 内容（示例） |
|---|---|
| 本番环境 | Prod（Staging 同配置）｜域名/证书已配置｜API 网关可用 |
| 账号 | 测试门店账号、测试客户账号、测试护理师账号（最小权限） |
| 第三方 | 支付（沙箱/本番）、短信、推送、微信小程序后台（如涉及） |
| 数据 | 至少 1 个门店、3 个服务项目、可预约排班数据、卡券/折扣（可选） |
建议：第三方平台信息尽量以子账号/临时授权方式提供，避免明文密码扩散。
3) 关键路径清单（示例）
建议上线前必须覆盖的“主干”动作
| 编号 | 关键路径（示例） | 结果 |
|---|---|---|
| KP-01 | C端注册/登录 → 完成个人信息 | PASS |
| KP-02 | C端预约下单 → 支付成功 → 生成预约单 | PASS* |
| KP-03 | 护理师端接单 → 确认服务时间 | PASS |
| KP-04 | B端排班调整 → C端可见更新 | RETEST |
| KP-05 | 取消/退款（规则内）→ 状态闭环 | BLOCK |
| KP-06 | 消息通知：下单/改期/取消 推送 | PASS* |
PASS* 示例含义：可跑通但存在注意点/需进一步确认（例如：回调延迟、通知偶发丢失等）。
4) 动作确认记录样例：KP-02 预约下单
写法示例：步骤 → 预期 → 实际 → 证据（截图/日志/订单号）
| 步 | 操作 | 预期 | 实际（示例） | 证据（示例） |
|---|---|---|---|---|
| S1 | 选择门店/服务/时间段 | 可预约时段加载成功 | 加载成功；偶发 1 次接口超时 | trace_id=... slot_api timeout |
| S2 | 提交订单 | 生成待支付订单 | 成功；返回结构字段缺失 1 项 | order_id=20251203-001 |
| S3 | 完成支付 | 订单状态=已支付 | 成功；回调延迟约 3~5s | payment_tx=... |
| S4 | 通知推送 | 客户/护理师/门店收到通知 | 客户收到；护理师端偶发未收到 | push_log missing? |
这类记录最终会对应到 Issue List（例如：通知丢失、接口超时）并要求乙方说明或修正。
Issue List（示例）
可筛选/可点选查看详情｜用于甲乙双方沟通与整改跟踪
| ID | 标题 | 端 | 严重度 | 状态 |
|---|
点击某一行可查看右侧详情。此处示例数据来自“常见母婴预约/支付/排班/通知”业务推测。
Issue 详情
证据/影响/建议（示例写法）
请在左侧列表点击一条 Issue。
暂时想定使用backlog或者Jira等工具进行管理
・每条 Issue 建议绑定：来源（静态分析/动作确认/甲方反馈）＋ 证据（路径/日志/截图）＋ 影响（上线阻断/体验/合规）＋ 期望处理（说明/修复/延期）
・若乙方无法修复：甲方可据此判断“验收条件是否满足/是否需保留款项/是否需补充合同条款”（具体法务判断需另议）
・每条 Issue 建议绑定：来源（静态分析/动作确认/甲方反馈）＋ 证据（路径/日志/截图）＋ 影响（上线阻断/体验/合规）＋ 期望处理（说明/修复/延期）
・若乙方无法修复：甲方可据此判断“验收条件是否满足/是否需保留款项/是否需补充合同条款”（具体法务判断需另议）