主题
商家中心文档风格与收录内容总结
一、总结对象
本文总结《商家中心产品设计与使用说明》的写作风格、内容结构和收录范围，供后续维护商家中心文档或编写其他业务模块说明时参考。
原文档基本情况：
| 项目 | 说明 |
|---|---|
| 文档名称 | 商家中心产品设计与使用说明 |
| 文档定位 | 产品设计基线与实际使用手册合一 |
| 主要读者 | 产品、运营、客服、测试、审计及商家支持人员 |
| 内容规模 | 15 个一级业务章节，共 898 行 |
| 图表形式 | 规则表格、步骤清单和 8 个 Mermaid 流程图 |
| 内容依据 | 当前项目已经实现的商家中心功能 |
二、文档整体风格
2.1 产品说明与操作手册合一
文档不是单纯的功能列表，也不是只面向开发人员的技术设计。每个模块同时回答以下两类问题：
- 产品为什么这样设计，包括状态划分、权限边界、数据生效规则和业务约束。
- 使用者具体如何操作，包括前置条件、操作步骤、处理结果和失败后的处理方式。
这种写法让产品、运营、客服和测试可以使用同一份文档，减少不同岗位分别维护规则说明造成的不一致。
2.2 以商家生命周期为主线
全文按照商家的实际业务顺序组织：
text
账号与登录
→ 入驻申请
→ 平台审核
→ 缴费或体验
→ 正常经营
→ 资料与账户维护
→ 通知、处罚与申诉
→ 关店与退出章节顺序不按前端菜单或代码目录排列，而是按照用户完成业务的先后关系排列。读者能够从头到尾理解一个商家如何进入、使用和退出平台。
2.3 规则优先，界面描述从简
文档重点说明不会因为页面改版而轻易变化的内容：
- 状态及其含义；
- 字段口径；
- 前置条件；
- 数据何时生效；
- 哪些旧数据继续保留；
- 哪些操作需要审核；
- 异常和重复操作如何处理；
- 敏感信息怎样保护。
文档不依赖截图，不逐个描述按钮颜色、页面布局或临时交互位置。页面改版后，只要业务规则没有变化，文档仍然有效。
2.4 面向业务人员的中文表达
正文使用直接、明确的业务语言：
- 使用“平台审核通过后，新账户才生效”，不使用数据库更新之类的实现术语。
- 使用“原经营位置继续生效”，明确告诉使用者当前结果。
- 使用“最多申诉 3 次”“提醒时间必须早于截止时间”等可以直接执行和验收的表述。
- 对必要的系统状态同时给出中文名称和业务含义，避免只列代码值。
句式以主动语态和短句为主，尽量避免口号、宣传性语言和不明确的“视情况处理”。
2.5 产品边界明确
文档明确商家中心负责商家身份、入驻、经营资格和基础管理，但不展开酒店房型、商品、活动、订单、核销、履约、发货和售后等具体经营模块。
对这些外部模块只说明：
- 商家类型是否拥有对应能力；
- 经营资格到期后是否限制该能力；
- 工作台和菜单是否显示相关入口。
这种边界避免一份文档无限扩展，也方便以后为各经营模块单独编写说明。
三、结构和排版风格
3.1 固定的章节层级
文档采用三级结构：
| 层级 | 用途 | 示例 |
|---|---|---|
| 一级标题 | 文档名称 | 商家中心产品设计与使用说明 |
| 二级标题 | 完整业务模块 | 商家入驻、结算账户、关店与退出 |
| 三级标题 | 模块中的规则或操作 | 入驻方案、商家修改账户、审核通过和退款 |
章节采用中文序号，子章节采用阿拉伯数字编号，适合较长的产品和操作文档。
3.2 表格用于准确对照
以下内容优先使用表格表达：
- 状态值、状态名称和允许操作；
- 字段用途和校验规则；
- 不同方案之间的差异；
- 审核通过与驳回的不同结果；
- 商家类型和功能能力的映射；
- 常见问题的原因和处理方式。
表格的目的不是装饰，而是让读者能够快速比较和核查。
3.3 Mermaid 用于跨角色流程
文档收录了 8 个 Mermaid 图，分别用于表达：
- 商家中心核心业务对象关系；
- 商家主状态流转；
- 入驻申请整体流程；
- 正式入驻支付时序；
- 保证金处罚扣减逻辑；
- 经营地址变更审核时序；
- 平台通知生命周期；
- 关店和保证金退款流程。
只有涉及多个角色、多个状态或多个判断分支时才使用图。单一步骤仍使用普通编号列表，避免图表过多影响阅读。
3.4 操作步骤使用编号列表
涉及商家或平台人员实际执行的任务时，使用有先后顺序的编号列表。例如：
- 商家补料重提；
- 体验转正式；
- 商家修改结算账户；
- 平台发布通知；
- 商家申请关店；
- 平台处理入驻和申诉。
每个步骤只描述一个动作或一个检查点，便于运营照单执行，也便于测试转化为用例。
3.5 先正常流程，再异常处理
每个主要模块先说明正常业务规则和操作，再集中列出常见失败或边界情况。这样既保持主流程清晰，又不会遗漏错误状态。
四、内容组织方式
4.1 每个模块回答的核心问题
各业务模块基本围绕以下问题展开：
| 问题 | 文档中的体现 |
|---|---|
| 这个功能解决什么问题？ | 模块定位或用途说明 |
| 谁可以使用？ | 使用角色、商家状态或商家类型 |
| 使用前需要满足什么条件？ | 前置状态、资料和资金条件 |
| 需要填写哪些内容？ | 字段和规则表格 |
| 操作步骤是什么？ | 编号操作列表 |
| 操作后什么数据生效？ | 审核、支付、替换和保留规则 |
| 失败时会发生什么？ | 常见问题、异常和边界处理 |
| 如何验证功能正确？ | 文末功能验收要点 |
4.2 特别强调“何时生效”
文档对容易误解的数据生效规则进行了重点说明：
- 入驻资料只有审核通过后才能进入缴费或营业阶段。
- 经营地址变更在审核通过前继续使用原位置。
- 结算账户变更在审核通过前继续使用原账户。
- 体验转正式只有支付成功后才建立正式周期和保证金账户。
- 关店存在可退保证金时，要等退款成功后才变为已关店。
- 查看平台通知不代表已经确认，必须执行确认操作。
4.3 特别区分不同状态层次
文档把状态分为三层：
- 商家主状态：描述审核、支付、营业和关店阶段；
- 经营资格状态：描述入驻周期或体验期是否允许继续经营；
- 资金子状态：描述支付、处罚、申诉和退款的处理进度。
这种划分用于解释“主状态正常但功能仍受限”等常见问题。
4.4 敏感信息贯穿各模块
敏感信息说明没有只放在单独的安全章节，而是放入实际使用场景：
- 入驻审核说明身份证号、法人手机号和银行账号的脱敏规则；
- 结算账户说明新旧账户和完整账号查看边界；
- 密码管理说明密码变化对登录状态的影响；
- 平台运营说明敏感资料不得进入工单、聊天和测试报告；
- 资金操作说明不能绕过处罚、补缴或退款流程直接修改余额。
五、文档收录内容
5.1 文档说明
收录文档目的、适用范围、使用角色和金额、时间、手机号、状态等基本口径。
5.2 产品整体设计
收录商家中心定位、三个使用端、核心业务对象、7 种商家主状态、主状态流转，以及主状态、经营资格和资金状态之间的关系。
5.3 账号、登录与访问控制
收录登录手机号、联系电话和密码的用途，登录和密码失效逻辑，不同商家状态的访问边界，忘记密码操作和常见登录问题。
5.4 商家入驻
收录分类选择、正式与体验两种方案、通用必填资料、经营主体资料、个人合作资料、结算账户规则、须知版本确认、提交后的系统处理和常见提交失败。
5.5 平台审核与补料重提
收录平台审核检查项、审核通过和驳回结果、商家补料重提步骤，以及密码、证件、手机号、银行账号和附件的敏感信息规则。
5.6 入驻费用、体验期与续费
收录费用组成、经营资格状态、扫码与小程序支付、体验期配置和调整、体验转正式、正式续费、免费续费及支付异常处理。
5.7 保证金、处罚与申诉
收录保证金余额口径、处罚在保证金与钱包之间的承担逻辑、商家最多 3 次申诉、平台申诉审核、主动撤销处罚和保证金补缴。
5.8 商家资料与经营位置
收录可以直接修改和需要审核的资料边界、地址变更流程、重复提交规则、平台直接更新地址及位置来源说明。
5.9 结算账户
收录当前生效账户与待审核账户的双账户设计、入驻账户生效、商家修改、平台审核和账号脱敏规则。
5.10 商家类型、功能能力与菜单
收录商家类型、服务端功能能力和前端菜单三层控制，本地生活、酒店、商城、外包、司机、摄影、车行和物品租赁等类型的能力范围，以及经营资格对能力的影响。
5.11 工作台与平台通知
收录工作台经营数据、待办入口、通知目标、通知发布和取消、商家查看与确认、提醒时间、接收人冻结和消息发送失败处理。
5.12 关店与退出
收录商家关店申请、进行中订单校验、平台审核、钱包负余额校验、保证金退款、失败重试、审核拒绝和关店后的数据保留规则。
5.13 平台运营使用说明
收录日常处理顺序、入驻审核、地址和账户审核、费用与体验管理、处罚申诉、通知发布及敏感操作要求。
5.14 常见问题
收录正常营业但不能经营、地址未生效、新银行卡未生效、支付状态未更新、申诉金额恢复、关店退款中、菜单缺失、通知未确认、敏感字段不回填和关店后恢复等问题。
5.15 功能验收
收录入驻审核、账号能力、费用保证金、资料账户、通知关店五组验收要点，便于测试和产品验收使用。
六、未收录内容
为保持文档定位清晰，原文档没有收录以下内容：
- 具体接口路径、请求参数和返回结构；
- 后台权限码和代码类名；
- 数据库表、字段映射和加密实现细节；
- 文档站构建、部署、域名和服务器配置；
- 前端页面截图和按钮级视觉说明；
- 酒店、商品、订单等经营模块的内部功能；
- 尚未实现的产品规划、优化建议和技术债；
- 真实商家、手机号、证件号码、银行账号和支付数据。
七、后续维护规范
7.1 内容更新原则
- 只记录已经实现并可以验证的功能。
- 状态、金额、次数和时间限制发生变化时，同步修改规则表、操作步骤、常见问题和验收要点。
- 新增审核流程时，必须说明审核前数据、审核中数据和审核后生效数据。
- 新增敏感字段时，必须说明存储、展示、查看和操作记录要求。
- 新增商家类型或功能能力时，同步修改类型说明、菜单规则和经营资格影响。
7.2 写作规范
- 标题直接使用业务名称，不使用宣传性标题。
- 一个段落只说明一个核心规则。
- 可比较的数据使用表格，有顺序的操作使用编号列表。
- 涉及三个以上状态或角色的流程优先使用 Mermaid。
- 明确使用“必须”“不能”“审核通过后”“原数据继续生效”等可验证措辞。
- 避免“可能”“大概”“按需处理”等无法验收的描述。
7.3 更新后的检查项
- [ ] 新内容是否仍在商家中心范围内；
- [ ] 产品规则和实际操作是否一致；
- [ ] 商家端与平台端的职责是否分别说明；
- [ ] 状态流转和数据生效时点是否明确；
- [ ] 正常流程和异常流程是否都覆盖；
- [ ] 敏感信息是否避免明文展示；
- [ ] 流程图、表格和章节编号是否正确；
- [ ] 常见问题和验收要点是否同步更新。
本文总结基于 2026-08-30 版本的《商家中心产品设计与使用说明》。