2026-W21 第 20 周周志

✅ 本周进展

CRM 系统：施工师傅按部位提成模块重新设计

这周继续围绕门店 CRM 做了一轮实际业务侧的优化。销售端的问题相对清晰：字段太多、录入太重，需要围绕车牌、客户、报价和跟进来简化。但施工师傅这边的问题更细：他们不是在填写一张普通工单，而是在完成一台车的不同施工部位，并且这些部位直接关系到师傅提成。

一开始我尝试把这个模块拆成比较标准的数据结构：

• 施工师傅表
• 工单表
• 产品项目表
• 施工部位项目表
• 施工师傅工单项目表

这个结构从数据库建模角度看是合理的，但放到飞书多维表里会变得很重。因为每多一个关联表，就会产生双向关联字段；再加上查找引用、汇总字段、公式字段，最后表格之间会形成一张很绕的网。对门店来说，这种设计虽然“规范”，但不够好用。

后来重新回到实际操作场景：施工师傅真正需要做的事情其实很简单。

一个工单如果有 3 个师傅参与，就建 3 条记录；如果有 2 个师傅参与，就建 2 条记录。每条记录代表：

一个师傅 + 一个工单 + 该师傅完成的施工部位 + 自动计算提成

也就是说，不再强行让系统通过多层关联去推导所有东西，而是把施工提成模块收敛成一张更直观的表：施工师傅工单提成表。

这张表里的核心字段包括：

这次比较关键的判断是：当前阶段不追求最标准的数据模型，而优先追求门店一线能不能顺手用。

如果继续使用“施工部位项目表 + 查找引用 + 多选关联”的方式，理论上更灵活，但师傅需要理解关联记录、默认部位、完成部位、查找引用这些概念，操作成本会变高。对于小团队来说，更适合让师傅直接在自己的那一行勾选部位，系统用公式算钱。

这次模块设计最后形成了一个比较清晰的结论：

• 一张表解决施工师傅提成记录
• 一行代表一个师傅在一个工单中的施工结果
• 部位用复选框表达完成情况
• 提成金额写入公式自动计算
• 店长只需要按师傅和月份汇总即可

这个方案牺牲了一部分后期扩展性，但换来了更低的使用门槛。对现在这个门店 CRM 来说，这是更合适的取舍。

蓝辉网站：用 lanhui-product-imagegen 生成理想 i8 产品图

这周还把蓝辉网站里的产品图生成流程跑通了一次。用到的是项目里的 lanhui-product-imagegen skill，它的作用不是简单“画几张图”，而是把一张车型产品目录海报，转成可以直接放进网站目录里的产品卡素材。

这个 skill 的核心规则很清楚：

• 用户提供的海报只作为车型轮廓、视觉氛围和品类参考，不能复制海报排版、文字、Logo、价格或车牌。
• 每个改装品类单独生成一张图，避免多个不相关产品混在同一张图里。
• 最终图片统一输出为 1448x1086、4:3，适配网站产品卡。
• 图片状态统一记录为 generated-preview，明确它是生成预览图，不是真实施工案例。
• 最终资产必须进入 public/images/products/<topic>/generated/，不能只停留在 Codex 的临时生成目录。
• 每次生成都要配套输出 manifest.json、prompts.md 和 contact-sheet.jpg，方便后续接入页面、复查提示词和快速验图。

这次执行的车型是 理想 i8。我先读取参考海报，确认它包含的是一组轻改产品目录，然后按项目已有目录习惯，把输出位置定在：

public/images/products/li-auto/i8/generated/

接着从海报里拆出 20 个品类：

真正执行时，每个品类都写了一条独立提示词。提示词里会固定强调几个限制：photorealistic product/catalog preview、4:3 product-card composition、主体产品必须清楚可见、不能有文字、Logo、水印、价格、可读车牌，也不能暗示不真实的施工效果或性能承诺。

生成完成后，我创建了一份临时 items 清单，把每张图的英文 key、中文名称、分类 tier 和提示词摘要记录下来。然后运行 skill 自带的 finalize-product-images.mjs 脚本，把 Codex 临时目录里的图片统一复制、裁切、压缩到网站目录，并生成：

manifest.json
prompts.md
contact-sheet.jpg

最后做了两层检查：

• 用脚本校验 manifest 数量和 PNG 数量都是 20。
• 用 sharp 校验每张 PNG 都是 1448x1086。
• 打开 contact-sheet.jpg 人工看一遍，确认每个品类主体能看懂，没有明显文字、Logo、水印或车牌污染。

这次比较有价值的地方，是把“AI 生图”变成了一个可以复用的工程流程。以前生成图片很容易停在聊天窗口里：图有了，但文件名、尺寸、目录、状态、提示词记录、验图都没有形成闭环。这个 skill 则把流程拆成了固定步骤：

参考图识别 → 品类归一化 → 单图单提示词 → 生成图片 → 写 items 清单 → finalizer 入库 → manifest 记录 → contact-sheet 复核。

这样做之后，生成图不再是一次性的素材，而是可以被网站直接引用、被后续页面接入、也可以被团队复查和替换的资产。

Sales Agent：从销售话术助手推进到 CRM 写入助手

这周另一个比较重要的变化，是把有膜有漾 Sales Agent 的定位重新梳理了一遍。最早这个 agent 更像是销售知识和话术助手，主要解决几个问题：客户问车衣、窗膜、改色膜时怎么回答；客户嫌贵、担心施工、拿竞品比价时怎么处理；销售要发微信跟进时，怎么生成一段能直接复制的话术；客户想看改色效果时，怎么用实车图和色卡图生成上车预览。

这些能力本身有价值，但在实际门店场景里还不够。销售每天不是只缺一句话术，而是缺一个能把沟通结果沉淀下来的工作流。客户聊完以后，如果没有及时记录来源、车型、预算、产品意向、跟进时间和负责人，后面再好的话术也接不上。所以这次我把 Sales Agent 从“回答问题”往“辅助完成销售动作”推进了一步。

这次整理的过程大概分成几步。

第一步是先画业务工作流，而不是直接写 skill。现在 workspace 里把 Sales Agent 拆成了几个日常工作单元：产品知识与推荐、客户接待与诊断、CRM 自然语言填写、异议处理与成交推进、跟进售后、店长数据分析、改色膜上车效果图。这样做的好处是，agent 不再是一堆零散能力，而是围绕销售每天真实会发生的动作组织。

第二步是把 CRM 接入变成自然语言入口。销售不需要逐格打开飞书多维表，只要说一句“帮我录一个理想 L7 客户，想贴车衣，周六到店”，agent 先解析客户、车型、产品意向、来源、预算、下一步动作和负责人，再根据缺失字段追问。这个过程不是直接写表，而是先生成结构化确认摘要，销售明确确认后再写入 CRM。

第三步是把飞书多维表里的 7 张表和 Hermes skill 对齐。现在 CRM 不只是一张线索表，而是覆盖线索管理、跟进记录、报价表、客户车辆档案、工单表、售后表、产品项目表和人员表。对应到 agent 侧，也拆出了录线索、记跟进、报价、建档、下工单、售后、数据分析这些 skill。这样销售说短指令时，agent 能知道这句话应该进入哪张表、写哪些字段、哪些字段必须通过 record_id 或 open_id 关联。

第四步是补写安全边界。CRM 写入不能让模型自由发挥，尤其不能凭空补手机号、成交金额、负责人、价格政策，也不能把客户隐私写进 workspace 文档。所以这次把规则收得更明确：解析、追问、查重、确认、再写入；重复客户先让销售选择；隐私只进 CRM，不进入文档总结。

这次改完以后，Sales Agent 的形态更清楚了：它不是单纯帮销售“说得更好”，而是帮销售把一次客户沟通推进成下一条可执行记录。前端是自然语言，后端是飞书 CRM、销售 SOP、产品知识库和一组受控的写入规则。

💡 本周思考

这次 CRM 设计里最大的感受是：多维表不是数据库后台，也不是企业级 ERP。它更像是业务人员可以理解和维护的轻量系统。所以设计的时候不能只看“结构是否优雅”，还要看一线人员是否能在 10 秒内知道自己要填哪里。

施工师傅按部位提成这个模块尤其明显。标准化设计会自然导向更多表、更多关联、更多查找引用，但师傅每天面对的是车、膜、部位和交付，不是数据模型。如果系统为了准确而变复杂，最后可能就没人愿意填。

所以这一轮之后，我对 CRM 的判断更明确了：

销售端可以适度结构化，施工端要尽量动作化。

销售需要看线索、报价、客户、转化率，所以字段可以更完整；施工师傅只需要知道今天做哪台车、完成哪些部位、提成怎么算。两个角色使用系统的方式不一样，表格设计也不能用同一套思路硬套。

Sales Agent 这次调整也让我意识到，agent 的价值不只是“会回答”，而是能不能嵌进业务闭环。销售现场的问题往往不是缺少信息，而是信息没有在正确的时间进入正确的系统。把话术、CRM、跟进提醒、报价和工单串起来之后，agent 才更像一个销售工作台，而不是一个旁边随时可问的聊天框。