目录

• 第 1 章　项目概述（背景 · 定位 · 商业模式 · 名词 · 边界）
• 第 2 章　角色与权限体系
• 第 3 章　总体业务流程（主流程 · 状态机 · 异常流程）
• 第 4 章　功能需求详述（甲方端 · 包工头端 · 工人端 · 管理后台）
• 第 5 章　核心业务规则（双账单 · 计价 · 会员 · 支付 · 结算 · 打卡）
• 第 6 章　数据模型设计（核心表与字段）
• 第 7 章　技术架构建议（Go vs Java · 技术栈 · 第三方服务 · 部署）
• 第 8 章　迭代计划（P0 / P1 / P2 功能分级）
• 第 9 章　非功能需求与风险合规
• 第 10 章　附录（询价单样例 · 待定决策清单）

在车展、中秋展、品牌路演、临时舞台等商业活动中，甲方（品牌方或活动公司）有短周期的搭建需求：设计稿确定后，需要临时组织美工、搬运工、电工、安装工等劳务力量，并配套物料运输、仓储、保险等执行环节。当前业务以纯线下方式运作，存在以下痛点：

• 报价靠 Excel、收款靠催：每单手工做报价单（如询价表），通过微信发图片给客户，支付无凭据、对账困难；
• 客户关系无沉淀：老客户复购时找不到历史订单和历史价格，每年会员（准入）费无法系统化收取；
• 下游供应商（包工头）管理混乱：电话谈价、口头确认，转包价与对客价的差价（平台核心利润）缺乏系统性记录；
• 施工过程黑箱：甲方不知道工人是否到场，出勤、进度无法留痕，完工后容易产生扯皮；
• 资金往来不透明：收款、打款、利润全靠个人记账，规模一上来就乱。

本项目旨在将上述线下流程产品化：通过微信小程序 + 管理后台，实现「需求录入 → 双账单生成 → 会员+账单支付 → 派单接单 → 工人打卡 → 验收结算 → 线上打款」的全链路闭环。

典型单笔经济模型（以询价表样例订单为例）：对客账单含税合计 79,447 元（税金 6%），若人工与运输转包成本合计约 68,000 元，则本单平台毛利约 11,447 元；同期收取甲方会员年费 1 笔（金额待定，见附录 B）。

本期做（In Scope）

• 微信小程序三角色端：甲方端、包工头端、工人端（同一个小程序，按角色分流，也可拆分为多个小程序，见 7.2 技术决策）；
• Web 管理后台：订单录入、双账单制作、派单、财务、打卡监管；
• 微信支付（含首单「会员费 + 账单费」合并支付）与退款；
• 完工结算：微信支付「商家转账到零钱」线上打款给包工头；
• 工人定位 + 拍照打卡与异常预警。

本期不做（Out of Scope）

• 不做开放竞价市场（不搞抢单大厅模式，P2 再评估），派单由平台人工主导；
• 不做物料供应链（物料采购、库存、生产管理），物料以账单行项目形式记录费用；
• 不做发票在线开具（仅预留开票信息字段，开票走线下税务流程）；
• 不做 App / H5 / 支付宝渠道（仅微信生态）；
• 不做灵活用工个税代缴（合规建议见 9.3 节）。

系统共 4 类角色，均通过手机号 + 微信授权登录。角色在注册时选择并互斥（一个微信号一个角色，避免甲乙方身份混用导致价格泄露）。

下述流程覆盖从需求进线到打款完结的完整链路。每步标注执行角色：管理者=后台，甲方/包工头/工人=小程序端。

1. ① 需求获取管理者（线下）

   甲方老板/项目经理通过微信或电话找到平台，给出设计文档（或口述）与用工需求：x 名美工、x 名搬运工、电工、时间、城市场馆。P2 阶段支持甲方小程序自助提交需求单。

2. ② 订单录入管理后台

   管理员新建订单：填写项目名、城市场馆（含定位坐标）、搭建期/活动日/撤场日期、需求描述，上传设计文档（图片/PDF 存对象存储）。

3. ③ 制作对客账单管理后台

   按询价表结构录入行项目（人工/物料/运输/仓储/差旅/保险，含数量、单位、单价、工艺描述），系统自动计算不含税合计、税金（默认 6%）、含税合计，支持标记「待定项」。

4. ④ 账单推送甲方小程序

   账单发送后，甲方小程序收到服务通知；未注册甲方通过手机号验证码注册并登录（个人主体即可下单，企业主体需补充认证资料）。

5. ⑤ 支付甲方小程序

   甲方核对账单明细后支付：首单 = 会员年费 + 账单费合并支付（微信合单支付）；有效期内老会员仅支付账单费。支付成功后订单进入「已支付待派单」。

6. ⑥ 洽谈与制作内部账单管理者（线下）

   运营通过自有渠道联系包工头，确认可承接的工种、人数与转包价（如搬运工对客 300 元/工、转包 220 元/工）。管理员据此制作内部账单（行项目与对客账单对应，价格独立）。

7. ⑦ 派单管理后台

   创建派单：选择包工头、关联内部账单、设置接单截止时间，可整单派给一家，也可按行项目拆分派给多家（如人工给 A、运输给 B）。包工头小程序收到派单通知。

8. ⑧ 接单包工头小程序

   包工头查看派单信息（场馆、时间、工作内容、内部账单价格；看不到对客价格）与设计文档（接单后开放），确认接单或填写理由拒绝（拒绝后订单回到待派单）。

9. ⑨ 录入工人名单包工头小程序

   包工头按需求录入工人：姓名 + 手机号 + 工种（美工/搬运/电工/安装/普工）。系统向工人手机号发送邀请短信。

10. ⑩ 工人绑定工人小程序

    工人用微信登录小程序，手机号与名单匹配后自动关联订单，进入「我的出工任务」。绑定即视为报名确认。

11. ⑪ 施工与打卡工人/包工头

    施工期间，工人每日到场上卡（定位 + 现场照片，1~3 张）；定位距场馆超半径则标记异常。包工头同口径打卡（监督岗）。甲方端可查看每日出勤汇总与照片墙，进度透明。

12. ⑫ 完工报告包工头小程序

    撤场完成后，包工头提交完工报告：完工照片（≥3 张）+ 文字说明（实际用工数、增减项说明）。

13. ⑬ 验收甲方小程序

    甲方查看完工报告与结算单（如有差异项，见 5.7）后确认验收，存在尾款的须先补付；超时规则：完工后 72 小时未操作推送提醒，120 小时（后台可配置）后可由管理员代确认（需填写备注）。验收通过后订单进入结算队列。

14. ⑭ 结算打款管理后台

    前置：订单应收款已全部收清（含尾款）。管理员核对内部账单与打卡记录后确认结算金额，通过微信「商家转账到零钱」打款给包工头（需包工头实名信息一致），电子回单归档，订单完结，利润入账统计。

订单状态由平台统一维护，甲方端 / 包工头端展示的状态文案由各自状态映射生成。状态码采用两位数字，便于扩展。

补充约定：管理员作废与甲方取消共用状态 31（已取消），以操作日志区分发起方与原因；甲方「申请修改」每单限 3 次，超出转人工沟通；后台代确认验收后 7 天内甲方仍可发起争议（71）。

① 甲方支付前取消

订单置为已取消(31)，无资金动作。同场次可重新开单，历史账单保留可复制。

② 甲方支付后取消

• 未派单：全额原路退款（41）。会员子单规则：生效 ≤7 天随单退，超 7 天不退（后台可人工干预）；
• 已派单未开工：无准备成本的全额退（41）；与包工头协商确认产生准备成本的，平台裁定后部分退款（42），退款方案后台留痕；
• 施工中取消：按已完成工作量结算，未完成部分退款，具体金额线下协商 + 后台执行。

③ 包工头拒单 / 超时未接

派单关闭(D90)，订单回到已支付待派单(40)，管理员重新洽谈其他包工头并重新派单。拒单记录纳入包工头合作评级（P2）。

④ 验收驳回与争议

甲方驳回验收须填写理由（附照片），订单回到施工中(60)整改；累计驳回 2 次自动转争议中(71)。争议也可由甲方（验收页）、包工头（对账页）在验收环节发起，或管理员直接置入。由平台仲裁，仲裁结果三选一：继续验收、部分退款、全额退款；状态映射：继续验收 → 80，部分退款 → 42（退款完成后继续结算），全额退款 → 41 且对应派单关闭(D90)。全程后台操作留痕并推送双方通知。

⑤ 打款失败

商家转账失败（收款人姓名与实名不符、单笔/单日额度超限、账户风控等），派单停在待打款，后台展示微信返回的错误码与原因，修正后重新发起，不自动重试超过 3 次。

功能按端拆分，每项标注优先级：P0 首个上线版本（甲方端 + 管理后台核心）必须交付　P1 包工头端/工人端上线版本交付　P2 后续迭代。优先级语义与第 8 章迭代计划一一对应。

4.1.1 注册登录与主体认证

• 微信授权登录（P0）：wx.login 获取 code 换 openid，首次登录强制绑定手机号（微信手机号快捷授权，失败降级短信验证码）；
• 主体类型（P0）：注册时选择「个人 / 企业」。个人即可完成下单与支付；
• 企业认证（P1）：企业用户补充：企业名称、统一社会信用代码、营业执照照片（存对象存储）、联系人。认证仅做资料留档（开票与合同用），不阻塞下单；支持 OCR 识别营业执照自动填充（P2）；
• 多联系人（P2）：一个企业主体下多个成员共用订单视图。

4.1.2 会员开通与续费

• 会员状态展示（P0）：个人中心显示会员有效期、剩余天数；到期前 30 天小程序弹窗 + 服务通知提醒续费；
• 开通方式（P0）：首单与账单费合并支付时自动开通（支付回调写入会员记录）；也可在会员页单独购买（主动续费）；
• 续费规则（P0）：有效期内续费，新周期从当前到期日顺延 365 天；过期后续费从支付日起算；
• 会员权益说明页（P0）：静态页说明会员权益（平台承接资格、历史订单档案、发票信息维护）。

4.1.3 账单查看与支付

• 账单详情（P0）：按询价表结构完整展示——项目信息（城市场馆、搭建期/活动日/撤场）、行项目列表（序号、分组、物料/工种名称、工艺描述、数量、单位、单价、金额、备注、待定标记）、不含税合计、税金、含税合计；
• 账单确认（P0）：甲方点「确认无误」后进入支付；也可点「申请修改」填写修改意见（回到平台编辑，重新发送）；
• 支付（P0）：微信支付 JSAPI 合单支付；支付成功页展示两笔子单金额拆分；
• 支付凭证（P0）：订单详情内可查看支付时间、金额、微信交易单号，可保存电子收据图片（P2）；
• 待定项提示（P1）：含「待定」行项目（如美工画面按实结算）的账单，确认时强提示「待定项按实际发生结算，最终金额以完工后的结算单为准，多退少补」，流程见 5.7；
• 结算尾款支付（P1）：验收环节若结算单金额高于已付金额，验收确认与尾款支付合并完成（微信支付单独一笔）；低于已付金额的差额走部分退款流程。

4.1.4 订单跟踪

• 订单列表（P0）：按状态筛选（待支付/进行中/待验收/已完成），列表项显示项目名、场馆城市、时间、状态、金额；
• 订单详情（P0）：状态时间轴（对应 3.2 状态机）、对客账单入口、支付信息；
• 施工进度（P1）：按日展示出勤汇总（当日出勤人数、工种分布、打卡照片墙缩略图），照片点击放大；
• 完工报告查看（P1）：完工照片 + 包工头说明 + 实际用工说明；
• 设计文档查看（P0）：本人订单的设计文档在线预览（图片直看、PDF 用微信文档预览）。

4.1.5 完工验收

• 验收确认（P1）：查看完工报告后点「确认验收」，二次确认弹窗（提示验收后进入结算）；
• 驳回（P1）：填写驳回理由（必填）+ 上传现场照片（0~9 张）；累计 2 次驳回转争议流程；
• 超时规则（P1）：完工后 72 小时（可配置）未操作，向甲方推送提醒；120 小时后可由管理员后台代确认（需填写备注）；代确认后 7 天内甲方仍可发起争议。

4.1.6 个人中心与自助需求（P2）

• 企业认证资料维护、开票信息维护（抬头、税号、邮寄地址）；
• 历史订单档案（跨年检索、复用往期需求发起新单）；
• 自助需求发布：填写活动信息（名称/城市/场馆/时间）、用工需求（工种 × 人数）、上传设计文档后提交，管理员后台审核（通过后转正式订单并制作账单 / 驳回并附意见）。

4.2.1 注册与实名认证（P1）

• 微信授权登录 + 手机号绑定；
• 实名认证（P1）：真实姓名 + 身份证号 + 身份证人像面照片。姓名须与微信「商家转账到零钱」收款人一致，否则打款失败；
• 团队信息（P1）：团队名称、常驻城市、可承接工种（美工/搬运/电工/安装/普工 多选）、团队规模、过往案例照片（≤9 张）；
• 认证审核（P1）：管理员后台人工审核，通过后方可接收派单。

4.2.2 派单通知与接单（P1）

• 派单列表：按状态筛选（待接单/进行中/待结算/已完成）；新派单通过小程序服务通知 + 短信提醒；
• 派单详情：项目名、场馆（含地图坐标）、搭建/活动/撤场时间、工作内容描述、内部账单（行项目明细与合计）、接单截止时间。设计文档在确认接单后方可查看；
• 接单 / 拒单：接单须二次确认（提示按内部账单金额结算）；拒单必填理由；
• 数据隔离：本端任何页面与接口不出现对客账单金额、甲方支付信息（见 9.2 节）。

4.2.3 工人名单管理（P1）

• 接单后录入工人：姓名（必填）+ 手机号（必填，唯一）+ 工种（美工/搬运/电工/安装/普工）；
• 可从「历史工人库」一键带入往期名单（P2）；
• 名单状态：待绑定（已录入未登录）/ 已绑定（工人登录成功）；未绑定工人施工前须完成绑定；
• 编辑与替换：开工前可自由增删；开工后增补需备注原因（留痕），删除不删除已产生打卡记录。

4.2.4 施工管理（P1）

• 开工：到达现场后点「开工」，触发派单状态 D30，开放打卡；建议上传开工现场照（可选）；
• 监督打卡：包工头本人口径的定位 + 拍照打卡（与工人一致），用于交叉验证；建议每日打卡但不强制，缺卡不阻塞流程，仅后台提示；
• 增减项登记：施工中发现工作量增减（临时加人、工期延长），登记说明与金额建议；后台审核后，转包价计入内部账单新版本，对客价由平台与甲方线下谈定（参考对客单价库）后生成对客账单新版本，统一走 5.7 结算单流程收退款；
• 完工报告：完工照片 ≥3 张 + 文字说明（实际用工、增减项），提交后等待甲方验收。

4.2.5 对账与收款（P1）

• 对账确认：订单验收后，包工头查看最终内部账单（含增减项调整），点「确认对账」进入打款队列；有异议可提交异议说明，由平台线下处理；超 72 小时未确认，管理员可代确认（留痕）；
• 收款记录：历史打款流水列表（金额、时间、微信转账批次单号）；
• 电子回单：下载/分享微信商家转账电子回单（图片）。

定位说明：工人报酬由包工头线下自行发放，平台不介入工人薪酬，仅提供出勤留痕与任务查看工具。

4.3.1 登录绑定（P1）

• 工人从包工头短信邀请链接进入小程序 → 微信授权登录 → 绑定手机号；
• 手机号与名单匹配：命中待绑定名单 → 自动关联对应派单，进入「我的出工任务」；
• 未命中名单的登录用户：提示「暂无出工任务」，留存为潜在工人（后续可被包工头检索加入名单，P2）。

4.3.2 每日打卡（P1）

• 打卡操作：任务页点「上工打卡」→ 授权地理位置 → 系统计算与场馆坐标距离 → 拍摄现场照片（1~3 张，调相机不可从相册选）→ 提交；
• 下班打卡（P1.1 小版本）：同口径，记录工时区间；首版仅上工打卡也可满足出勤留痕；
• 异常规则：距离 > 打卡半径（默认 500 米，订单级可配置）时仍可提交，但记录标记「越界」，进入后台异常列表；
• 补卡（P2）：当日漏卡，次日提交补卡申请 + 说明照片，包工头确认、后台留痕；
• 出勤记录：按日历视图查看出勤天数与打卡详情；仅能看本人记录。

4.4.1 账号与权限（P0）

• 管理员账号密码登录（P0），支持双角色：超级管理员（全部权限）/ 运营（订单、派单、账单，无资金操作）；
• 操作日志（P0）：全后台关键操作留痕（谁、何时、改了什么），资金类操作不可删除。

4.4.2 订单管理（P0）

• 订单列表：多条件筛选（状态、城市、甲方、时间范围、来源），关键词搜索；
• 新建订单：项目信息（名称、城市、场馆、经纬度选点、搭建期/活动日/撤场）、需求描述、设计文档上传（图片/PDF，多文件）；支持从历史订单复制；
• 自助需求审核（P2）：审核甲方提交的需求单，通过转订单 / 驳回附意见。

4.4.3 双账单制作（对客账单 P0 / 内部账单 P1，核心）

• 对客账单编辑器：行项目表格化编辑，字段对齐询价表：序号 / 项目分组 / 物料（工种）名称 / 工艺描述 / 尺寸（长宽高 mm）/ 数量 / 单位 / 单价 / 金额（自动 = 数量 × 单价，可手改覆盖）/ 备注 / 待定标记；
• 账单合计：不含税合计自动汇总、税率可改（默认 6%）、税金四舍五入到分、含税合计；
• 内部账单编辑器（P1）：独立编辑（默认从对客账单复制行项目再改价，一键「按比例调整单价」辅助工具）；与派单绑定；
• 账单发送：对客账单发送后甲方可见并收通知；发送前可反复编辑；
• 账单版本：每次发送生成版本快照（V1、V2…），甲方确认的是快照，防止事后改价争议。

4.4.4 派单管理（P1）

• 创建派单：选包工头（仅认证通过）+ 关联内部账单 + 接单截止时间 + 范围（整单 / 勾选对客行项目作为工作范围说明，内部账单仍独立编辑）；
• 派单跟踪：各派单状态一目了然（待接单/施工中/已完工/已结算）；
• 撤回与重派：待接单状态可撤回；拒单后可重派他人。

4.4.5 会员与用户管理（P0）

• 甲方列表：注册信息、主体类型、会员状态（有效期）、订单数、累计消费；
• 会员操作：人工开票续期（赠送场景）、作废（需备注）；会员费定价后台可配置（价格档位表）。

4.4.6 包工头管理（P1）

• 认证审核：身份证信息 + 团队资料人工审核；
• 合作档案：承接单数、拒单率、结算总额、异常打卡数（P1）；评级标签（P2）。

4.4.7 财务管理（P0）

• 收款流水：微信支付流水（订单款、会员款分列），支持对账导出（Excel）；
• 退款管理：发起全额/部分退款（调微信退款接口），退款记录留痕；
• 对公转账收款（P1）：大额订单支持甲方对公转账，后台登记银行流水人工核销，核销后订单等同已支付；
• 结算打款（P1）：结算队列 → 核对打卡与内部账单 → 调商家转账接口打款 → 回单归档；打款失败处理；
• 利润报表（P1）：按订单/按月统计：对客收入 − 转包成本 = 毛利；会员费收入单列。

4.4.8 打卡监管与消息（P1）

• 打卡看板：按订单查看出勤日历（每人每天打卡状态），越界/缺卡异常列表高亮；
• 照片抽查：打卡照片墙，点击放大核对；
• 消息配置：各类通知（账单发送、派单、接单、完工、验收、结算）的开关与模板变量配置；
• 数据大屏（P2）：月度订单数、GMV、毛利、出勤人次趋势。

1. 一个订单（project_order）有且仅有一张对客账单（type=client），可以有 1..N 张内部账单（type=contractor，每张挂在一条派单下）；
2. 两套账单行项目结构完全一致（同一套字段模型 bill_item），但行数与价格独立：对客 1 行「安装人员 56 工 × 350」，内部可拆为「安装 45 工 × 260 + 加班 11 工 × 240」；
3. 利润计算：订单毛利 = 对客账单含税合计 − Σ内部账单含税合计（双方含税价直接相减；内部账单税金字段仅展示参考，默认跟随对客税率）。财务报表以「分」为最小单位计算，展示四舍五入到元；
4. 快照规则：账单被甲方确认 / 包工头接单时冻结版本快照，后续任何调整（增减项）生成新版本并记录调整原因，历史版本只读可查；
5. 状态映射：对客账单 1 草稿 → 2 已发送 → 3 已确认 → 4 已支付 → 5 已结算；内部账单 1 草稿 → 2 已发送（派单时）→ 3 已确认（接单时）→ 5 已结算（打款完成），「4 已支付」仅对客账单使用；
6. 可见性：对客账单仅甲方 + 管理员可见；内部账单仅对应包工头 + 管理员可见（接口层强制过滤，见 9.2 节）。

计价模式：简单模式

系统按「数量 × 单价 = 金额」直接计算，不做工时系数引擎。行业系数（搭建日按 3 工/天、活动日 1.5 工/天、通宵 2 工/天）由管理员在心算/线下表格完成后，把折算结果作为数量录入，并在「工艺描述」「备注」中写明折算过程，与现有询价表习惯一致：

单位与分类枚举

• 单位（可维护字典）：项、工、人次、趟、天、㎡、米；
• 行项目分类：人工（默认）、物料、运输、仓储、差旅、保险、其他；分类用于报表聚合；
• 待定项（is_tbd）：金额为 0 或占位，账单合计含税额会标注「另有待定项 x 个，按实结算」；
• 税金：税率默认 6%（订单级可改），税金 = 不含税合计 × 税率，四舍五入到分；展示顺序与询价表一致：不含税合计 → 税金 → 含税合计。

• 定价：年费金额后台可配置（初版单一档位，定价建议见附录 B）；
• 首次开通：非会员甲方首次支付订单时，系统自动组成合单（子单 1 = 会员年费，子单 2 = 账单费），微信支付一次完成；
• 有效期：365 天，自支付成功时刻起算；续费顺延；
• 权益边界：会员身份是「下单资格」而非优惠折扣——不设会员价，账单价格一视同仁；
• 退款联动：首单全额退款时，会员生效 ≤7 天会员费子单随单退，超 7 天不退（后台可人工干预，与 3.4② 规则一致）；
• 到期处理：到期不下单不影响历史订单查看；再次下单时重新合单收取年费。

• 支付方式：微信支付 JSAPI（小程序），V3 接口；
• 合单支付：使用微信「合单支付」能力（combine transactions），两笔子单独立记账、独立可退款；
• 金额校验：支付发起金额取自账单快照，服务端二次校验，防客户端篡改；
• 回调幂等：支付回调以微信订单号去重，处理失败进入重试队列，人工兜底对账；
• 超时未付：预支付单 2 小时过期；订单 7 天未支付提醒一次，15 天可后台关闭；
• 对公转账（P1）：大额订单可申请对公转账，线下转账后由后台登记银行流水核销，核销后订单状态等同线上已支付；
• 退款：原路退回，全额/部分均支持；部分退款按子单（会员子单/账单子单）分别操作；退款需超级管理员权限。

1. 前置条件（全部满足才进入打款队列）：订单验收通过（甲方确认或后台代确认）→ 对应派单内部账单版本冻结 → 包工头已确认对账（超 72 小时管理员可代确认）→ 订单应收款已全部收清（含 5.7 结算尾款）；
2. 打款通道：微信支付「商家转账到零钱」（企业商户号需单独开通该权限）；单笔默认限额以微信侧配置为准（通常单日/单笔上限需申请提额）；
3. 收款人校验：转账收款人 openId 对应的实名姓名必须与平台实名认证姓名一致，不一致直接失败并提示修正；
4. 打款操作：后台结算队列勾选 → 提交（可批量）→ 轮询/回调确认结果 → 成功归档电子回单，失败展示原因转人工；
5. 留痕：转账批次单号、操作人、时间、金额全部入库；结算后内部账单不可再调整（如需调整走线下 + 手工台账）；
6. 降级预案：商家转账权限未开通或限额不足时，后台支持登记线下打款记录（银行流水号 + 凭证照片），状态同样流转到已结算，但页面标记「线下打款」。

• 打卡窗口：窗口全天开放（通宵作业按任务日归属当日），仅限制每日 1 次上工卡（下班卡 P1.1 增加）；
• 定位半径：与场馆坐标比对，默认 500 米；越界可提交但标记异常；
• 照片要求：1~3 张，必须现场调起相机拍摄（wx.chooseMedia 限 camera），记录拍摄时间；
• 防作弊（渐进）：P1 仅定位 + 相机限制；P2 增加照片水印（时间/地址/订单号）、设备指纹去重（同一设备短时间多次打卡预警）；
• 异常清单：越界、缺卡（名单工人当日无打卡记录）在后台打卡监管页高亮，推送管理员；
• 数据用途：打卡记录是出勤争议的仲裁证据（谁到场、何时到场、现场实况），但金额结算一律以账单版本快照为准，打卡数据不参与金额计算。

解决两类「钱收少了」的场景：① 待定项按实结算（如美工画面）；② 施工中的增项。完整流程：

1. 全部派单提交完工报告后（订单状态 70），管理员汇总待定项实结金额与增减项差异，生成结算单——本质是对客账单的「结算版」新版本快照，仅列出差异项与最终合计；无差异的订单可跳过（后台一键「无差异确认」）；
2. 甲方在验收页同时看到完工报告与结算单：结算单金额 > 已付金额 → 验收确认与尾款支付合并完成（微信支付，支付场景 scene=4）；结算单金额 < 已付金额 → 差额走部分退款（42）；金额一致 → 直接验收；
3. 应收款全部收清后，订单才允许进入打款队列（对应 5.5 前置条件），避免「平台垫资打款」；
4. 增项的对客价格由平台与甲方线下谈定后录入，转包价随内部账单同步调整，两套版本各自快照留痕。

实体关系总览：user（用户）— 1:1 — enterprise / membership；user(甲方) 1:N project_order（订单）— 1:1 — bill(type=client 对客账单) — 1:N — bill_item（行项目）；project_order 1:N dispatch（派单）— 1:1 — bill(type=contractor 内部账单)；dispatch 1:N worker_roster（工人名单）— 1:N — attendance（打卡）；project_order 1:N payment（支付），dispatch 1:1 settlement（结算）。核心表字段如下（MySQL 8，字段名 snake_case）：

结合背景：开发者是 iOS 出身（熟悉 Swift），后端经验较少，需要独立完成开发与运维。结论：选 Go。

• 分层：router → controller（参数校验）→ service（业务事务）→ dao（数据访问）；支付回调、状态流转全部收敛在 service 层，controller 不写业务；
• API 风格：RESTful + 统一响应体 { code, msg, data }；金额字段一律返回分；时间统一 UTC+8 ISO 格式；
• 鉴权：小程序 JWT（openid 换 user）；后台账号密码 + JWT；角色权限在中间件统一拦截（重点是 9.2 节的账单可见性过滤）；
• 幂等：支付回调、打款发起、接单操作均要求幂等键（业务单号）；
• 异步任务：短信/通知发送、接单截止检查、对账日报用 Redis 延迟队列 + 定时任务，失败重试 3 次后告警；
• 环境：dev / prod 两套配置，密钥走环境变量不进代码库；日志按天切割保留 30 天。

按「先跑通钱、再跑通人」的顺序分期：P0 解决收钱与记账，P1 解决施工过程与打款闭环，P2 做增长与效率。以 1 名全职开发（本人）估算工期。

• 并发模型按「低频 B2B」设计：日订单 < 50、日打卡 < 5000 次，单机 2 核 4G 富余；
• 核心接口 P95 < 500ms；打卡照片直传 COS（小程序端拿签名直传），不占业务带宽；
• 数据库每日自动备份（保留 30 天）+ 每周异地（COS）归档；
• 支付与打款接口可用性优先级最高，失败必须告警（企业微信/短信通知管理员）。

• 账单隔离是商业生命线：接口层实现——所有账单查询接口按 role + bill.type + 归属（client_user_id / contractor_user_id）过滤，禁止仅靠前端隐藏；代码评审时把「包工头能拿到对客账单」定义为最高级缺陷；
• 设计文档访问控制：仅订单甲方与已接单派单的包工头可见，COS 签名 URL 有效期 30 分钟；
• 手机号/身份证加密存储（AES-256-GCM），展示脱敏（138****5678）；
• 后台资金操作（退款、打款、代验收）需二次确认 + 操作日志不可删；
• 小程序端不做任何价格本地缓存，支付金额服务端计算。

以下来自实际业务询价表（7×11 街霸 × 脉动路演-北京站，华熙五棵松），用于验证账单模型覆盖度。该单 16 个行项目覆盖 6 种分类，模型全部支持。

• 覆盖分类：人工（安装/小工/电工）、物料（电料辅料/美工画面）、运输（跨省+市内）、仓储、差旅、保险——与 5.2 节分类枚举一致；
• 该单可拆多个派单：人工与市内运输派给北京包工头 A，跨省干线运输派给物流 B，仓储派给仓储商 C（scope_items 标记范围）。