汽修厂的账，通常坏在三个地方
汽修厂的业务不复杂：车进来、修好、收钱。难的是这三步之间的信息是断开的。
- 接车单在纸上，配件在仓库里。 接待写了一张接车单，师傅去仓库拿了三滤、刹车片、一瓶防冻液。仓库是库管凭记忆在本子上记的，月底盘库，配件账和维修记录对不上。谁拿的、装到哪台车上了，说不清。
- 工时靠嘴说。 结算的时候客户问"这四个工时是什么项目"，接待只能回忆。师傅之间的工时归属也模糊，绩效考核全靠印象。更麻烦的是增项——修到一半发现水泵也坏了，电话里跟客户说了一句"要多花点"，事后客户不认，扯皮。
- 挂账客户按月对账，靠翻微信。 企业车队、单位公务车、事故车挂保险，都是先修后结。一个月下来十几二十台车，价格、优惠、上个月付了没有,全散在微信聊天记录里。对账时对方问一句"这台车为什么这么贵",没人答得上来。
还有一个隐性问题：同一台车的历史查不到。客户说"这个毛病上个月你们刚修过",你翻不出上次修了什么、换了什么件、谁修的,责任和返修成本只能自己吞。
这一篇讲的不是"汽修厂应该上什么系统",而是用 Inkwell AI 构建器能把这个场景做成什么样的一个模块——一张从接车到收款的通行单，数据怎么建、页面怎么用、哪些重复的事可以交给规则跑、上线前该查哪几项。
这张单要装下的完整链路
一条维修单，业务上其实横跨六个环节：
- 接车：谁的车、什么牌照、进厂里程、油量、随车物品、客户说的故障现象、预估交期、预估金额。
- 报价：修之前给客户一个说法。工时按项目报，配件按件报，客户同意才动工。
- 施工：谁做、做了多久、做了什么。中途发现新问题要增项，增项必须单独留痕并再次确认。
- 配件领用：从仓库领了什么、几件、装到了哪台车上、是不是客户自带件。
- 结算：工时费 + 配件费 + 外协费（比如钣金喷漆外送）- 优惠 = 应收；现付、挂账还是走保险。
- 收款：一次付清还是分期，挂账的进应收台账，到期要催。
纸质单的通病是把 2 和 4 混在一起，把 5 和 6 混在一起。系统建模时最容易犯的也是这个错。下面五个设计决定，是这个模块能不能立住的关键。
底表怎么建：五个关键设计决定
决定一：客户和车辆必须是两张表
最常见的偷懒做法是一张"客户车辆表"，把车主姓名、电话、车牌、车型写在一行里。这样做的后果是：一台车换了车主，历史记录跟人走了，车辆的维修履历就断了；一个客户有三台车，就要重复录三次电话。
正确的关系是：客户 1 对多 车辆，车辆 1 对多 接车单。
- 客户表：名称、类型（个人/企业/保险）、联系电话、挂账额度、结算账期、开票信息。
- 车辆表：车牌、车型、VIN 码、发动机号、初次登记日期、当前里程、所属客户、车辆备注（比如"底盘低，举升机注意"）。
关联时用系统内部 ID，车牌只作为业务上的辨识字段。车辆表里还要保留一个"当前归属客户"——车辆过户时改这一个字段，历史接车单的归属不动。
决定二：施工项目和配件领用是两张子表，不是一张"费用明细"
很多老板第一反应是"一行一行往下写费用就行"。但工时和配件的结算规则完全不同：工时按项目×工时单价，配件要按配件档案的售价、要考虑加价率、要联动库存出库、还要区分客户自带件（不计配件费但照样登记装了什么）。
所以接车单下面挂两张明细子表：
- 施工项目明细：项目名称、工时数、工时单价、施工技师、开始时间、完工时间、是否返修。
- 配件领用明细：配件、数量、单价、来源（库存/客户自带/外购）、对应出库单、领用人。
两张表分开，结算时才能分别汇总、分别核对，也才能做后面"技师产值""配件毛利率"这类分析。配件领用明细和库存模块之间靠引用引擎（系统里跨模块的软外键，选一个配件时自动带出它的档案与当前库存）连起来，不走手工二次录入。库存本身怎么建，可以对照通用库存管理：入库、出库与盘点那篇的思路。
决定三：报价要留两版，增项必须单独确认
接车时给客户报过价，施工中又发现新问题——这是汽修厂天天发生的事，也是纠纷的第一来源。
底表上要把这两件事分开记：
- 接车报价：动工前那一版，包含预估工时项目和预估配件，需要有客户确认的标记（确认方式、确认人、确认时间）。
- 增项：施工中追加的项目，每条独立成行，带原因、追加金额、客户确认结果。
结果就是结算单上的费用永远能追溯到"哪一版报价同意了、哪几条增项谁同意过"。客户质疑时，翻开就能讲清楚，不必靠回忆。
决定四：结算单一车一单，收款另行记录
结算单是对客户的一次"费用结清声明"，收款是对这笔声明的一次"钱到账"。两张表。
- 结算单：关联接车单，汇总工时费、配件费、外协费、优惠金额、应收总额；支付方式（现付/挂账/保险）、结算日期、优惠审批人。
- 收款记录：金额、收款方式、收款日期、收款人、票据号、备注。
一张结算单可以对应多笔收款（比如先付一半）。挂账的结算单不生成立即的收款记录，而是生成一条应收，进入应收台账按客户、按账期归集。应收怎么管，参考应收应付：业务台账怎么建。
决定五：状态先定义清楚，再动手做页面
接车单的状态流转是这个模块的骨架：
接车登记 → 已报价待确认 → 施工中 → 完工待结算 → 已结算 → 已交车
中途可能进入：挂起（等配件）、取消、返修
状态用系统的数据字典集中管理，不要在页面里写死选项、也不要用自由文本让人手填。这样以后加一个"等待保险定损"的状态，只改字典，不用改页面。字典的通用做法见数据字典：管好下拉选项的统一口径。## 页面怎么分：一个模块，四种人的视角
同一个模块，接待、技师、库管、老板要看的东西完全不同。做页面时按角色切视角，比做一个"什么都有"的大表单有效得多。权限上把角色分开配（系统的角色与权限配置支持内置角色和自定义授权，见角色与权限配置），谁能改金额、谁能作废，先在配置里定死。
服务顾问（接待）
- 接车登记页：选客户 → 选车（老客户直接带出车辆列表）→ 录进厂里程、油量、随车物品、客户描述的故障 → 拍两张车况照片作为附件上传 → 填预估交期和预估金额 → 存单。老流程里最费时间的现场描述，用手机直接拍照上传比回来补录靠谱。
- 报价页：从配件档案和工时单价里挑项目，生成一版报价，登记客户确认结果。
- 在厂车辆看板：按状态分列今天在厂的车——刚接车、等报价确认、在施工、等配件、完工待结算。前台接电话时，客户问"我的车好了没"，看一眼就能答。
车间主管与技师
- 派工与施工登记页：主管把接车单上的施工项目分给技师；技师在手机上登记自己这条项目的开始时间、结束时间、实际工时。
- 我的活：技师只看自己名下的项目，今天几台车、哪台先做，一目了然。这条视角对绩效也有用——工时数据是自然产生的，不用月底再回忆。
- 增项提交：发现新问题，从这里提一条增项，写清原因和预估金额，走确认流程，不能私下加。
库管
- 按单领料页：输入接车单或车牌，把这张单要用的配件逐条领出，系统生成出库并把库存扣掉。这是把"配件账和维修记录对上"的关键一环——领用必须挂在接车单上，不能只做一张出库单。
- 退料：多领的、领错的，按原单退回，库存加回，留痕。
- 安全库存预警清单：常用易损件低于设定下限时列出来，该补货了。
财务与老板
- 结算单页：工时费、配件费、外协费自动汇总，优惠要填理由并走审批，付款方式选择现付或挂账，确认后单据锁定。
- 挂账对账单：按客户、按期间拉出所有未结算的结算单，生成对账清单发给对方，收回来的钱逐笔核销。
- 今日/本月看板：接车台次、完工台次、产值、已收、未收。老板最关心的两个数——今天进了几台车、这个月还有多少钱没收。
顺带说一句：售后工单类的模块在别的行业里长得很像，如果厂里同时有对外服务性质的业务，售后工单：报修、派单、完工、回访的闭环那篇的闭环思路可以对照着看，两个模块的派单与完工验收逻辑是相通的。
哪些重复的事可以交给规则跑
页面解决"人要做什么"，规则解决"人不该再记的事"。这个模块里值得做成自动化的有四类，都落在平台现有的能力上。
一、需要人点头的，走审批流
系统的审批流支持自定义流程与节点（图形化配置，节点就是"谁在什么条件下批什么"）。这里至少设两条：
- 优惠审批：折扣超过设定金额或比例，必须主管批；批准了才能出结算单。
- 大额增项审批：增项金额超过阈值，先批再施工。这一条能挡掉大部分事后争议。
二、条件触发的小动作，走数据流规则
数据流规则是"当某张表的数据变成某个样子，就自动改另一个地方"的规则，不用写代码，配置条件和动作即可。适合放在这里的几个：
- 接车单状态改为"完工待结算" → 给服务顾问和财务发一条站内通知。
- 配件领用登记后 → 库存自动扣减；退料 → 自动加回。
- 结算单挂账 → 自动生成一条应收记录，带上客户、账期、金额。
- 车辆里程更新时 → 同步到车辆档案的"当前里程"，下次接车带出的是最新值。
三、按时间跑的，走定时任务
定时任务按 Cron 周期执行（Cron 可以理解为"每天几点、每周几跑一次"的时间表达式）。这个场景里真正有用的三件：
- 每天扫逾期应收：超过账期还没收的挂账单，自动生成催收提醒给财务和销售，附客户与金额。
- 每周一生成上周挂账客户的对账清单：不用等财务想起来。
- 每月统计单车产值与技师工时：月底不用再手工汇总。
定时任务和工作流怎么配、怎么写条件，平台的使用文档里讲得比较细：工作流与定时任务：让重复性工作自动跑。
四、动过钱的地方，全留痕
结算单的金额修改、优惠审批、作废重开、价格字段变更，这几类动作必须留审计记录——谁改的、什么时候改的、改前改后各是什么。系统自带操作审计日志能力，敏感操作默认留痕且可导出。汽修厂的纠纷十次有八次是"当时说好的价格"，有了这条记录，内部复盘和对外解释都有依据。## 手机端在这个场景里不是"顺带支持"
汽修厂的现场天然是移动的：车在举升机上、配件在仓库货架上、老板在路上。接待坐在电脑前，技师蹲在车旁边——这两类人需要的入口不一样。
在平台里构建的模块会同步到手机端，不用为手机另做一套（手机端怎么用、工作台和模块页怎么组织，见移动端使用指南）。这个场景里主要用得上三件事：
- 拍照上传：接车时的车况、施工中的拆检照片、旧件照片，直接在车前拍完挂到接车单上。旧件留证这件事，过去靠"扔在客户看得见的地方"，现在靠一张照片。
- 技师登记工时：手里有活就点开始，做完点结束，工时数据自然形成。比事后填表准，也比月底回忆准。
- 手机上看板：老板在外面临时想看今天接了几台车、欠款多少，打开手机即可，不用回厂开电脑。
要注意的是：手机端的页面布局需要在构建时就考虑到字段别太密。把"登记"和"查询"分开——登记页只留必要字段，其余放详情页，手机上才用得顺手。
上线前要查的七项
模块建完不等于能用。下面这些是这个场景里最容易翻车的地方，上线前逐条过一遍：
- 基础数据先导进去，别一边用一边补。 配件档案、工时单价表、客户与车辆档案，先用 Excel 导入把存量数据灌进去（平台支持从表格直接建模块与导入模式，见用 Excel 一步建模块）。空着基础数据上线，等于让接待第一天用不了。
- 状态字典定完再动手。 接车状态、支付方式、配件来源、客户类型，这四组枚举先定全，把"后期可能加的"也想一遍。字典改了，历史单据的显示会跟着变，早期定得太粗，后面越改越乱。
- 库存联动真的测一遍。 领料是不是真扣了库存、退料是不是真加回来了、客户自带件是不是不扣库存、领错了能不能退回。这四条在测试数据上跑一遍，比上线后发现配件的账又对不上强。
- 权限按岗位切，尤其金额字段。 谁能改结算单价、谁能给优惠、谁能作废结算单，必须在角色配置里分开。默认给所有人开编辑权限是最常见的上线事故。
- 挂账客户先把额度与账期填上。 客户的挂账额度和结算账期不填，逾期应收的自动提醒就是空的——规则没错，是数据没准备好。
- 处理在厂车的过渡。 上线当天的现实是：厂里停着十几台没完工的车，账面上还有一批旧应收。建议只把未完结的单录进来（带原始接车日期），期初应收单独整理成一份台账导入，历史已结清的单据不追，避免上线变成一场数据搬家。
- 走一遍发布预检，再并行跑一周。 模块的测试与发布有预检环节，能提前把字段、权限、页面的问题挡在门外，跑完记得检查手机端页面是否正常（见模块的测试与发布）。之后建议纸质单和系统并行一周，一周后对比两边的配件与金额是否一致，一致了再停纸质单。
之后可以怎么延伸
这套底表立住以后，往上加东西的成本很低，因为主线数据已经在了：
- 客户回访：完工后三天自动生成一条回访任务（用车满意度、有没有异响），回访结果记在接车单上。这块可以直接用平台的任务能力承接。
- 配件采购：配件领用数据积累下来，就有真实的消耗速度，可以据此定安全库存、走采购请购，思路见采购管理：请购、订单、入库、对账一条线。
- 技师绩效：施工项目明细里已经有时长、项目类型、是否返修，按技师汇总就是一张产值与返修率报表。
- 会员与套餐：洗车卡、保养套餐这类预付费业务，本质是"储值 + 按次核销"，是另一套底表，建议单独建模块，不要塞进维修结算单里。
这个方案的边界：哪些事它不做
说清楚不做什么，比承诺能做什么更有用：
- 不对接整车厂 DMS、保险定损平台、交管系统。 这些都需要对方开放接口并谈授权，属于集成项目，不是模块本身能解决的。系统里有集成凭据管理的底座，但对接哪家、怎么对接要单独评估。
- 不直连诊断仪、四轮定位仪、举升机等维修设备。 设备数据采集涉及硬件协议，不在 AI 构建器的交付范围内。
- 不做工时定额的自动测算和智能排程。 工时单价和工时数是人定的基础数据，系统负责记录和汇总，不负责替老师傅判断"这个活该算几个工时"。
- 不做给车主用的自助查询门户。 客户查询维修进度、在线确认报价，目前的做法是由服务顾问在自己的手机端登记确认结果与附件，不开放外部账号。如果确实需要车主自助端，这是一个独立的需求，要单独立项评估。
- 不做发票开具接口。 结算单上可以留发票号与开票信息字段供财务登记，但开票动作仍在税控系统里完成。
一句话收口：这个模块要解决的不是"汽修厂有没有系统"，而是同一台车的每一笔费用，都能追回到哪张单、哪个项目、谁做的、客户什么时候同意的。做到这一步，配件账、工时账、挂账对账这三本账就是一个账，而不是三个说法。