| 节点 | 图中原文 | 说明 |
|---|---|---|
| 1 | 发布需求：过滤敏感词、敏感图片，可能通过 AI 处理（敏感词库 + 图片 OCR 识别） | 内容风控在发布前执行 |
| 2 | 发布需求 | 入口 |
| 3 | 先扣余额，再扣报酬，最后扣买卖所得 | 扣款顺序（三条资金来源依次扣） |
| 4 | 状态为 0（待支付） | 下单未支付的状态 |
| 5 | 钱是否够 | 判断：余额 + 可扣来源是否足够 |
| 14/15/16 | 钱原路退回 · 直接结束 · 取消订单 | 不够时：订单取消，钱原路退回 |
| 节点 | 图中原文 | 说明 |
|---|---|---|
| 9/10/11/12 | 是否为公示 → 是 → 是公示 → Y | 公示单走公开匹配 |
| 13 | 机制需要优化 | 图上标注：非公示机制待优化 |
| 17 | 走匹配 | 进入匹配池 |
| 节点 | 图中原文 | 说明 |
|---|---|---|
| 19 | 施助者愿施助 | 施助者响应 |
| 18/20 | 施助者拒绝 → 确定施助关系表中会记录（拒绝关系） | 拒绝要落库留痕 |
| 21/22/23 | 求助者确认 → 同意 / 拒绝施助者的施助 | 求助者拥有确认权 |
| 25 | 确定施助关系表中会记录（成立关系） | 同意后建立施助关系 |
| 24 | 订单状态为 1（等待中） | 订单成立后的状态 |
| 26 | 求助者在施助前的移除施助者 | 开始前可移除 |
| 节点 | 图中原文 | 说明 |
|---|---|---|
| 27~29 | 判断是否多人 → 是 / 否 | 单人单与多人单分流 |
| 30 | 实需 5 人但只有 4 人时，订单状态为 2；有效期内没点进入施助中 → 订单直接取消；点了 → 订单继续，所有金额退回后重新扣 4 人费用 | 人数不足的结算规则（多退少补） |
| 33 | 订单状态为 2（待同意状态） | 人数未满的中间态 |
| 31/32/34 | 是否最后一次 → 是 / 否 | 语义不清，见第 6 节 |
| 35 | 不会自动进入施助中 | 必须人点 |
| 36/37/40/41/42 | 定时任务判断是否超过有效时间 → 是 / 否 → 没有点击 | 超时由定时任务判定 |
| 39 | 订单自动结束，资金原路返回 | 超时未操作 → 取消退款 |
| 38 | 求助者点击进入施助中 | 由求助者触发 |
| 节点 | 图中原文 | 说明 |
|---|---|---|
| 44 | 进入施助中 | 主状态 |
| 45 | 求助者点击进入施助中时，如果是非公示订单，求助金将直接给施助者 | 非公示的资金路径 |
| 46 | 往施助者账户上打钱，但为冻结状态 | 钱到账但不可提 |
| 43 | 非公示所需要人数订单：需要 10 人、实需 4 人，系统匹配 6 人；发布时扣 10×10=100，进入施助中只匹配 6 人，则返回 4×10 给求助者，这 4×10 要给药施助者，相当于平台吃了 2×10 | 算账逻辑混乱，见第 6 节 |
| 节点 | 图中原文 | 说明 |
|---|---|---|
| 53/54 | 完成施助；如果订单期望完成时间超过 7 天，自动完成施助 | 超期自动完成 |
| 55 | 将施助者账户中的钱解冻 | 完成即解冻 |
| 56 | 如果使用的是余额，那么会返回百分之 10 给求助者 | 余额支付返 10% |
| 57 | 评价；评价后，如果发布订单时使用的是余额报酬，那么会有红包机会 | 评价 + 红包机会 |
| 状态 | 含义 | 进入条件 |
|---|---|---|
| 状态 0 | 待支付 | 发布下单后、支付前 |
| 状态 1 | 等待中 | 双方确认、施助关系成立后 |
| 状态 2 | 待同意 | 多人单，人数未满（如实需 5 只到 4） |
| 施助中 | 履约中 | 求助者点击「进入施助中」 |
| 完成施助 | 已完成 | 确认完成或超期望完成时间 7 天 |
| 订单自动结束 | 已取消（退款） | 有效期超时未点进入施助中 |
| 纠纷中 | 争议状态 | 任一方提交纠纷，直到提交方确认解决 |
| 环节 | 规则 |
|---|---|
| 扣款顺序 | 先扣余额 → 再扣报酬 → 最后扣买卖所得 |
| 发布扣款 | 按「需要人数 × 单价」扣（例：10 人 × 10 = 100） |
| 钱不够 | 钱原路退回、订单取消 |
| 人数不足 | 有效期内点进入施助中 → 金额全退后按实到人数重扣；不点 → 超时自动结束、资金原路返回 |
| 非公示 | 进入施助中时求助金直接打给施助者，但为冻结状态 |
| 完成 | 解冻施助者账户的钱 |
| 返现 | 使用余额支付的部分，返 10%；评价后有红包机会 |
| 退款 | 整单退款（需后台审核）／协商退款（可按比例或金额） |
| 规则 | 值 | 出处节点 |
|---|---|---|
| 需求修改 | 只能修改 1 次 | 85 |
| 协商退款提交 | 只能提交 1 次 | 65 |
| 移除施助者 | 同一人最多 2 次 | 66 |
| 纠纷 | 一人一案，谁提交谁确认 | 58 / 60 |
| 自动完成施助 | 期望完成时间超 7 天 | 54 |
| 自动结算 | 未点平台介入且超期望完成时间 7 天 | 59 |
| 退款扣分 | 整单退款扣双方信誉分；移除扣施助者信誉分 | 47 / 78 |
| # | 位置 | 问题 | 建议 |
|---|---|---|---|
| 1 | 节点 13 | 公示/非公示分支标注「机制需要优化」，规则没定义 | 明确为：公示 = 公开可响应；非公示 = 定向邀请指定人 |
| 2 | 节点 63 | 「后台审核（待运行和产品经理沟通是否保留）」 | 确定哪些场景必须审核（建议只整单退款强制审核） |
| 3 | 节点 43 | 算账表述混乱：需要 10 人、实需 4 人、匹配 6 人、返回 4×10、平台吃 2×10 —— 与「平台不抽成」矛盾 | 重新定义人数与金额口径，明确平台是否抽成 |
| 4 | 节点 31/32/34 | 「是否最后一次」语义不清，不知道指最后一次什么 | 改为「是否为最后一次招募机会」或明确为截止判定 |
| 5 | 节点 56 / 57 | 「余额返 10%」与「评价后红包机会」是否同一件事 | 合并为一个规则：余额段返 10%，评价后发放 |
| 6 | 节点 30 / 43 | 「人数不足」的两种处理并存：全退后按实到人数重扣 vs 返回差额 | 统一为一种口径 |
| 7 | 文字 | 错别字：双发 → 双方；施主中 → 施助中；使用的时余额 → 使用的是余额；次施助者 → 该施助者 | 出图前统一校对 |