我用 WorkBuddy 给装机店搭了个「经营日报 AI 员工」：工作原理与搭建全过程
现在这件事交给了一个 AI 员工。早上说一句「出今天的经营日报」，它自己去拉数据、算指标、出报表，我只需要花 1 分钟补两个数字。
下面把它怎么工作，以及在 WorkBuddy 里是怎么一层层搭出来的，完整写一遍。
一、三条前提，决定了它长什么样
市面上大部分「AI 报表」是拿表格喂给模型，让它自由发挥。这套东西刚好相反——它是先把口径钉死，再让机器照着算。理解它的工作原理，先接受三条前提：
- 数据源不是猜的，是员工每天干活时本来就拍的照片（今日水印相机）。不需要额外让谁去填表。
- 规则是定死的，代码只是执行者。同一个指标，今天和三个月后的数字必须能横向比，所以口径一旦拍板就不许改。
- 机器算不了的事，老老实实留给人。照片是快照，账是流水——收没收到钱，照片永远拍不出来。
二、工作原理
1. 数据从哪来：两类接口，一次取完
员工每天拍照，照片上带一整块水印文字。最开始我以为得下载原图做视觉识别，成本不可控；后来实测发现，接口可以直接把水印里的文字读出来，一次调用就够，完全不用图像识别。
| 水印字段 | 示例 | 在日报里干什么 |
|---|---|---|
| 工程名称 | 上门安装电脑 / 电脑出租 | 这就是「模板名」，日报按它给业务分类 |
| 施工内容 | 更换硬盘 / 维修监控 | 具体干了什么 |
| 施工责任人 | 张三 / 李四 | 真名，不用再猜账号对应谁 |
| 施工位置 / 地点 | 济源市·天坛创业园 C 区 | 任务点聚类、地址链条 |
| 拍摄时间 | 2026.09.12 18:40 | 在岗跨度、停留时长、任务点合并 |
另一类是考勤，单独一个接口，返回上下班时间与地点。两个数据源合起来，日报要的「谁、几点、在哪、干了什么」就齐了。
2. 一条流水线：从照片到日报
整个系统其实是一条很朴素的流水线。每一步只做一件事，中间产物全部落成 JSON 文件，任一环节出问题都能单独重跑。
3. 设计一：口径定死，共 17 条
这是整套系统里最容易被低估的部分。同样一句「今天人效怎么样」，口径不同能算出完全不同的结论。所以所有指标都在文档里写成明文规则，代码只是执行者。举几条最有代表性的：
| 口径 | 怎么算 | 为什么这么定 |
|---|---|---|
| 任务点 | 同人 + 同地点 + 同模板 + 45 分钟内 = 1 个点；跨度不足 60 秒标「路过」 | 同一地址上的两件事不能被并成一件，否则单量虚低 |
| 在岗跨度 | 首末两张照片的时间差 | 明确标注「不等于实际工时」，避免被当成考勤工时用 |
| 人效（双轨） | 创收轨：元/小时 = 收入 ÷ 创收工时；支撑轨：内务 / 送修 / 售前单独成列、不计创收 | 跑腿和上门维修不该用同一个分母，硬算平均等于谁都不准 |
| 协作拆分 | 两人做同一件事，按各自当日在岗时长比例分摊单量与金额 | 顺序是「先比例 → 再金额 → 最后时效」，保证总额不虚增 |
| 代拍 ≠ 协作 | 账号是 A、署名是 B，而 B 当天在同一地址链上有自己的留痕 → 整单归 B | 店里互相借号拍照是常态，不区分就会把一个人拆成两半 |
| 金额校验 | 价格 = 收入金额 + 应收账款，不等就在清单下方提示 | 把「数字对不上」变成系统主动报错，而不是月底才发现 |
「这周是不是比上周忙」这个问题，只有在两周用同一把尺子的前提下才有答案。所以规则里写着一条硬性约定：要改口径，先跟人确认，不许擅自调整。
4. 设计二：机器算不出来的，不硬算
系统里有一块是刻意保持「人工」的——收款状态和金额。原因很直白：
- 照片拍完就固定在那一刻了，而「收没收到钱」是个会变的状态。今天没收，明天客户转过来，照片改不了。
- 水印里就算让员工填了金额，那也只是文本，无法验真——填 500 就是 500，可能是漏填、错填。
- 工作台里补录约 1 分钟，但换来的是账目可信。
同样的态度也用在数据缺失上：拿不到就说拿不到，不用 0 或占位符糊过去。营业额还没接收款端，日报里就老实写「待接入」，而不是先编个数让你先看着高兴。
5. 设计三：一套算法，两个出口
这套东西有两个使用界面：一是每天发给同事的静态 HTML 日报，二是在店里局域网里随时打开的在线工作台。两者展示内容几乎一样，都是固定的 12 个板块：
这里踩过一个典型坑：一开始两边各写一套算法，结果同一份数据，网页上算出一个数、导出的 HTML 里算出另一个数。后来改成两侧共用同一个计算核心（一个 1387 行的 Python 模块），所有涉及「人效 / 考勤 / 台账 / 异常」的算法只有一份实现，改口径只改这一个文件，两边同时生效。
光靠自觉还不够，所以又加了两个自动校验：一个逐项核对成品与工作台是不是分叉，其中一个硬校验是「每一笔业务单在个人工作内容里必须恰好出现 1 次」；另一个用最小 DOM 环境把前端真跑一遍，检查 12 个板块是否都渲染出来了。
前端脚本里只要有一处语法错误，整段脚本不会执行——页面只剩顶栏、内容全空，但服务端照样返回 200。工作台白屏了很久才发现。所以现在的规矩是：改完前端必须跑一次冒烟测试。
6. 第 12 块：异常自动检测
日报最后一块不写任何固定文案，全部实时算出来，按高 / 中 / 低分级。目前会检测这些情况：
- 施工内容未填写的比例（早期实测有 45% 的照片描述是空的）
- 同一人名下多个账号（借号现象）
- 工程名称的自由写法数量（早期同一件事有 15 种写法：
下班卫生反馈/下班卫生反馈。/下班卫生…） - 在岗不足 10 分钟的出勤
- 价格 ≠ 已收 + 应收
- 出租设备缺编号、收款状态未填、应出勤却未打卡
这一块的价值可能比报表本身更大——它把「员工的填写习惯」变成了可量化、可改进的指标。
三、在 WorkBuddy 里，它是怎么搭出来的
上面讲的是「系统怎么工作」，这部分讲「它是怎么被造出来的」。WorkBuddy 提供的是三种可直接复用的东西：技能（Skill）、专家（Agent）、以及能读写本地文件和调接口的执行能力。
1. 分三层，各管一件事
为什么要费劲分三层？因为把规则写两遍，必然分叉。项目实践中真的踩过：文档里写了一套口径，代码里改了另一套，两边悄悄跑偏。所以定了一条死规矩——
2. 技能里装什么
技能文件是这套系统的「操作手册 + 法规汇编」，核心是四样东西：
- 先判数据可得性的第一步：能调通接口就走完整流程；调不通就明说「今天拉不到数据，原因是 X」，绝不允许编数据。
- 6 步 SOP：每一步用什么脚本、传什么参数、产出什么文件，写成可照抄的命令。
- 统计口径表：17 条，前面展示过。
- 接口避坑清单：把所有踩过的坑写成明文，见下。
3. 把踩过的坑，一条条写成知识
这部分我觉得是整套东西最值钱的地方。以下每一条都是真金白银换来的：
| 坑 | 真相 |
|---|---|
| 以为要下载原图做视觉识别 | 不用。水印文字可以直接读出来，一次调用搞定，成本差几个量级 |
| 时间参数只传日期 | 直接报错。必须传完整的 起止时分秒 |
| 当天没有照片 | 返回空数据，但这不是故障，不要当异常处理 |
| 接口返回结构悄悄换代 | 字段名、键名会变，值尾部还会混进不可见控制符，解析器必须容错，否则某天突然全空 |
| 打包成 exe 时顺手排除掉某个标准库 | 程序启动即崩，而且用无窗口模式打包时连报错都看不见 |
| 关键词匹配顺序 | 「售后」的规则必须排在「维修」前面，否则「返修」会被当成维修吃掉 |
4. 专家：给人一个好用的入口
技能是给机器看的规则，专家是给人用的入口。它决定「你怎么跟它说话」，配置文件本身很短：
{
"name": "jingying-ribao",
"expertType": "agent",
"agentName": "jingying-ribao",
"displayName": { "zh": "经营日报分析师" },
"profession": { "zh": "门店经营数据分析师" },
"categoryId": "04-DataAI",
"defaultInitPrompt": { "zh": "出今天的经营日报" },
"quickPrompts": [
{ "zh": "出今天的经营日报" },
{ "zh": "这周谁的人效最高" },
{ "zh": "还有多少应收没收回来" }
]
}关键是专家说明文件 frontmatter 里的这一行：
skills: [jingying-ribao]它让技能在专家启动时自动加载。于是形成了很舒服的维护关系：改规则只改技能，专家自动跟随；改说话方式才动专家包，改完重新注册一次即可。
人设文件里还写死了几条输出规范，直接影响它说话的质感：
- 直接给结论，先说数字和异常，再补细节；已经正常的事不罗列
- 数字必须标注口径，比如「在岗 = 首末打卡时间差，不等于实际工时」
- 涉及钱的地方区分已收 / 应收，应收标红提示
- 数据缺失就明说缺什么、为什么缺
5. 质量闸门：两个必跑的校验
改完东西要跑两个脚本才算完成：一个检查成品与工作台的数字是否一致（防止两侧分叉），一个跑前端冒烟（防止白屏）。两者都默认跑独立的演示数据，不碰真实台账，所以随时可以验证，不怕把当天的数据改坏。
6. 时间线：从零到能用
| 时间 | 进展 |
|---|---|
| 9 月 12 日 | 确认水印文字可直读，取代原定的视觉识别方案；同一天把 11 项待定配置一次拍板 |
| 9 月 13 日 | 专家正式注册，能对话出报表 |
| 9 月 14 日 | 统计口径定稿；维修前后两个模板合并成一个「维修工单」加一个维修状态单选 |
| 9 月 19—20 日 | 兼容接口结构换代；工作台客户端定稿；项目按最新口径完整重建 |
| 9 月 22 日 | 人员归属改为按水印「责任人」判定，彻底解决借号拍照导致的人员拆分问题 |
十一天。没有一行前端框架，没有数据库，没有一个第三方 Python 依赖——解析、计算、服务全部用标准库写。这样做的代价是土，好处是十年后还能跑起来。
四、代价与边界
写得像软文的部分到此为止，下面是不好听但必须说的：
- 营业额还没接收款端，目前靠人工补录与核对，不是自动的。
- 局域网工作台没有登录鉴权，能打开页面的人就能改金额。只能在内网用，上公网前必须先加口令，或只开只读版。
- 前提是那台电脑开着，服务窗口不能关，否则别人访问不到。
- 依赖员工填得规范。工程名称写法不统一、施工内容留空，日报的准确度就跟着下降——所以第 12 块的异常检测才会一直盯着填写率。
- 涉及钱的数据只有人工补录的才可信，任何从照片推断出来的金额都只是旁证，不进营业额。
五、这套做法能复制到别处吗？五条经验
- 先定口径，再写代码。 顺序反了，代码写得越漂亮越难办——你要么改数据，要么改结论。
- 规则和数据必须分开放。 规则进技能，数据留在项目里。把数据复制进技能，早晚会出现「技能里跑的是上个月的旧口径」。
- 一个算法只能有一份实现。 两个出口就合并成一个计算核心，再加一个自动校验脚本兜底，别指望靠自觉。
- 把坑写进知识库，而不是写进聊天记录。 踩过的每个接口异常、每处环境差异，都应该是下一个人的现成答案。
- 机器算不了的事，大方交给人工。 每天省下 1 分钟的可信，好过自动化出一份据说很准的假账。
回到最初那个问题：一家 9 个人的装机店，该不该为「出一份日报」专门做一套系统？
我的答案是——真正值钱的不是日报这份文件，而是那份不会随人走掉的口径。它让「今天谁干了什么、店到底赚没赚钱」这些以前只存在老板脑子里的判断，第一次变成了可以对比、可以复盘、可以被追问的数字。
工具是 WorkBuddy，数据来自每个人本来就在拍的照片。这件事最妙的地方在于：没有让任何一位同事多填一张表。