YEA Business · Workshop 证据库
把真实工作交给 Agent 系统之后留下的证据。每天一条记录,格式固定:三个关键数据、发生的事情、我们设计的系统。每一条都标明来源与证据等级。
以前我对每个 project 的现状没有第一手视角 —— 要等团队汇报。工具也是散的:排名在一个平台、AI 搜索在另一个、自然流量在 Google Search Console、进度在专案看板,每个只看得到一小块。要拼出一个客户的全貌得开四个页面,再乘以二十几个客户,就变成没有人会天天做的事。这一天把五条数据线接进一台自己用 AI 写出来的 dashboard —— 数据每周自己跑进来,我不用问任何人。
上面三个数字之外,同一轮还量到这些。全部实测,来自 dashboard 的生产数据与专案看板,可现场复核。
把范围缩到单独一位专员:2026 年 1 月他名下 5 个 project,8 月 13 个。中间没有换人,也没有把工作拆出去。专案看板每个月存一个分组,翻回去就能一个月一个月数。
Dashboard 里扣掉 3 个暂停、1 个自家网站,剩 24 个客户 project;专案看板 8 月那两组是 13 + 11 = 24。两套彼此不相通的系统,同一天数出同一个数字 —— 这是「数据是真的」最便宜的一次验证。
每个月实际跑出来的关键词量测次数:2025 年 11 月 128 次,2026 年 7 月 3,708 次。project 数是 2.8 倍,量测量是 29 倍 —— 因为每个客户追的关键词也一起变多了。人手做的东西不可能这样长。
1,027 个关键词分布在 9 个市场/语言组合:英文马来西亚 462、英文新加坡 397、马来文 82、中文 12、菲律宾 2,另有 25 个是城市级的本地搜索。7 个 project 是多地点。同一个词在两个语言底下算两条独立的追踪线 —— 这正是人手排表最容易漏掉的地方。
新客户上线走一份固定清单:5 个阶段、平均 20.3 项任务,目前 11 个 project 在跑,合计 223 项。状态是 63 项完成、14 项卡在「等客户给 access」、146 项还没开始。卡在哪一格,不用开会问。
最新一轮快照里 540 个关键词抓到排名:前三名 208 个、首页 344 个、前二十 439 个。这是一句话就能对客户交代的东西,以前要开三个平台才拼得出来。
1,027 个关键词里,559 个绑了目标页面,468 个没有。没绑就代表没有人决定过这个词要靠哪一页去赢。看板把这一栏摊出来之后,它从「没人知道」变成「一个可以清掉的数字」。
两个排名账号走本机(一个 Claude Code、一个 Codex,都要 OAuth)、备用排名源与 AI 搜索走云端排程、自然流量走另一套云端 routine。四种执行环境、同一个数据库。哪条线什么时候跑过、下一次几点,写在同一页上。
排名平台的授权大约每周过期一次,而排程是无人值守的 —— 它没办法自己重新授权。这是已知而且已经写进流程的失败模式:跑挂了就发通知,人工重授权后补跑。写下来的失败模式,才不会变成惊喜。
今天的自然流量刷新 23 个 project 全部成功。8 月 5 日那一轮是 19/20(1 个暂停跳过),当时还有 8 个 project 根本没拿到 Search Console 权限。三周之内补齐 —— 因为看板把「没接上」列成一行,而不是让它安静地不存在。
专案看板上有一栏「Send Report」。7 月那两组一共 20 个 project:13 个标了已送、2 个标「不送」、5 个空白。空白不等于没送,而是没有人知道有没有送 —— 这一栏本身就是这套系统里还没自动化的那一块。
客户月报是从同一份数据自动排出来的,固定 11 个区块:总分、访客里有多少人本来不认识你、曝光、点击、排名分布、最强的三个关键词、按服务分组的表现、Top 5 页面、AI 搜索可见度、AI 回答里真的被问到的问题、这是合作的第几个月。28 个 project 四大板块全部开着。
24 个 project 绑了客户账号,客户登进来只看得到自己那一个,而且看到的就是我看到的同一份数据。报告不再是「我们整理给你看的那个版本」。
部署出去的应用是一个单文件网页,17,393 行、1.0 MB,里面包含项目看板、关键词表、AI 搜索、自然流量、竞争对手、上线清单、页面规划、客户账号管理。全部是用 AI 写出来的 —— 没有外包,也没有买第三方 SaaS。
28 个 project 里 22 个标了网站平台(WordPress 14、自建站台 6、Shopify 1、开发者自订 1),6 个还空着。平台决定这个客户的东西我们能不能自己动手改 —— 这一栏空着,报价和排期就会估错。
从 2025 年 7 月 11 日到今天,累计 204 个不同的快照日期、533 份 project 快照、15,724 个排名数据点。历史留在系统里,不在某个人的记忆里 —— 客户问「三个月前我排第几」,是查得到的。
五个系统全部接进同一个看板,才有办法在同一页上把「排第几」「有没有人点」「AI 有没有提到我们」「做到哪了」并排看。
两套系统交叉对上:看板数出来的 24 个客户 project,与专案看板 8 月的 13 + 11 完全一致。数字不是单一来源自己讲自己。
自动频率:五条数据线全部每周一次,各自的执行时间、执行环境与下一次预计时间写在同一页上,哪条线没跑一眼看得到。
客户可见:24 个 project 有客户账号,客户看到的是同一份数据,不是另外整理过的版本。
报告是否送达仍靠人手打勾(7 月 20 个 project 有 5 个空白)· 排名平台的授权每周过期仍需人工重授权 · 「跑一轮要多久」没有基线 · 468 个关键词还没绑目标页面
以前公司不可能请一个人,专门检查前面的人做得对不对 —— 那是冗员,成本看得见、价值在出事之前都看不见。所以这个角色一直是我,用剩下来的时间做。今天把薪资、激励制度、报销、AI 花费四条线全部接进 agent:团队做完的东西,先过一轮稽查才算完成。
今天一共十九条发现,上面三个是挑出来放在最前面的。以下是其余十六条 —— 全部实测,来自生产资料,可现场复核。
一位员工报了 RM 230 医疗费,Claim Summary 里没有她那一行;另一位没交表的同事那一行,金额与分类一模一样。总数一分不差,只有把表格和行逐份配对才看得到。
一条部门 subtotal 公式往回扫过了前面各部门的小计,等于重算一次。三个分类表上合计 RM 55,126.06,实际 RM 18,882.67 —— 虚高 2.92 倍。总额那一栏是对的,所以从上面看什么问题都没有。
上面那个公式错误,六月底就报出来过。七月底再跑同一份工作簿,原封不动。发现问题和关掉问题,是两种不同的能力。
四月的董事报销总额,六月验证是一个数字,七月底从活的表上读到的是另一个 —— 而那个月早就结账付款了。活的试算表没有 audit trail,结掉之后任何修改都是无声的。
一次薪资结算:一项因为抄上个月数字而多报 RM 733.75、一项 RM 600 空着、一项 RM 75 空着、一整节激励完全没出现。多报与漏掉几乎抵消,净差只有 −RM 58.75。那个月有四个人的数字是错的。
一次薪酬核对要横跨十三套激励制度、四种发放节奏、七个系统、84 名员工。没有人是故意设计成这样的 —— 每个制度加进来的当下都合理,复杂度是累积出来的。
最近改过五条激励规则:一条时差 T+3 改 T+2、一条整个取消、一条版本化、两条换参与人。主文件上还有两条是旧值。人手计算的人读的是文件,过期规则会直接变成付出去的钱。
一本报销账八个月 RM 35,966,订阅占 RM 21,827。月度占比最低 20.3%、最高 98.2%,期末停在 74.7%。这是大多数公司既不编预算、也不复盘的那一类支出。
一家 AI 供应商在账上 27 笔、三个独立账号,其中一个扣款日跟另外两个不同,落在其他账号被检查的周期之外。另一个工具从每月 RM 184 涨到 RM 1,578.50(8.5 倍),内部没有任何通知。同一个月还有三个人各自申报同一个平台的认证费,合计约 RM 1,145。
用「供应商 + 项目 + 金额 + 月份」对完整历史去重,抓到 4 笔已经报过的发票;另有 5 笔排除,因为是公司直接付款而非本人垫付。剩下送出的 176 笔,176 笔有收据。
供应商发票编号是按客户连续编的。比对手上这一串,浮出一份缺失单据 —— 要么扣款发生了而发票没寄到,要么根本没发生。在拿到已付款发票之前挂着不报。成本是零,而且几乎没有人在做。
同一家数据供应商用了两种大小写写法,四笔交易分成两组。任何按供应商归并的报表看到的都是两家中等供应商而不是一家大的,两边都碰不到会触发复查的门槛。
一次月结付款里,一位员工的身份证号码出现在银行户口栏。两者都是长串数字、都看起来合理,金额也是对的 —— 唯一错的是收款目的地。任何以金额为基础的控制都抓不到它。
把未付发票文件夹拿来对当月付款清单,浮出一张没有对应付款行的供应商发票。反方向的对账 —— 每张发票有没有对应付款 —— 才是抓到漏付供应商的那一个。
单月十六张平台广告发票、十四个客户账户。预扣税是广告金额的 8%,不是含税的收据总额 —— 把两者搞混已被记录为反复出现的错误。申报按上下半月各有死线,缴款参考号一次性,每期重新申请。算对了但迟交,就是罚款。
一次月结出账:薪资、报销、外包、创作者、预扣税、水电、杂费、团队激励、介绍佣金。九份来源文件汇到同一个放款日,转账记录单月增加 68 笔。同期发生一次批次编号碰撞,两批都从 001 开始编,一个类别的记录盖掉了另一个。
四个系统全部接进 agent,才有办法在同一轮里交叉比对。十六条发现里超过一半,是交叉两个以上来源才跳出来的。
只读:稽查层对薪资与账务系统只做读取,不具备写入权限。所有修正都回到人来执行。
例外优先:常规项目按既定规则自动通过,只把需要补证据、改分类或调整月份的部分拦下来 —— 七月那一轮 26 人自动通过,只有 2 人需要看。
留快照:每个月结账时留一份已验证快照。四月那笔 RM 414.25 的事后变动,就是靠这个才看得到。
每条发现的负责人与关闭机制(六月报出、七月还在,就是缺这一段)· 自动运行频率 · 稽查报告自动送到哪里
大部分老板对现金流只有感觉 ——「最近好像比较紧」—— 但说不出紧在哪里、从哪个月开始、是哪些客户造成的。这一天把账务系统、银行月结单、专案管理系统三边打通让 agent 直接读:它自己查,不用等人做报告。
除了上面三个,同一轮还查出这些。全部实测,来自账务生产库与银行月结单。
把 20 个月的银行月结单拿来对应收账:四个月里十笔入账、汇款人栏位全部指向同一家关联公司,合计 RM 558,662。账上该客户的收款记录是 0 笔,发票还挂着未收,最老一张 871 天。四个月没人发现。
报表上的平均账龄里混着那笔已经用银行转账还掉、但从来没入账的余额。剔掉之后,加权平均账龄从 318.7 天掉到 116.9 天。同一家公司、同一天,两个数字差 202 天 —— 而账龄决定你先催谁、给谁账期、提多少备抵。
主营运户口净现金流从 2025 年的 −RM 54,560 变成 2026 年的 +RM 38,060,六月底余额是五年记录里最高。但把那笔一次性关联方汇款拿掉之后是 −RM 520,602 —— 核心营运现金流是变差的,不是变好。
把客户结构固定住,只看两年同一窗口都有下单的 81 个客户:30 天清账率从 74.2% 掉到 64.9%。看全部客户只掉 2.4 个点。增长会在你最需要看清的时候把讯号稀释掉。
把每个客户按「金额 × 逾期天数」排名,268 个客户里的前 20 名占了整本账 49.1% 的拖欠。一样的人手,换一份名单。
客户的钱进来了,但从来没有冲到任何一张发票上。
四十张 credit note 开出去之后没有冲销,其中两张还标着已开发票。
还在继续下单,同时挂着超过 180 天的老账。
三个数据源同时读,才看得到单看任何一套软件都发现不了的问题。
只读权限:数据库账号实测只有 CONNECT 与 SELECT,写入权限为 0。Agent 不可能改动账务。
执行环境:Claude Code + MCP。账务系统走 MSSQL MCP,银行月结单走本机文件读取。
数据保存:分析结果写成记录条目,存进 Impact Ledger,同步导出 Excel/CSV。
自动运行频率(目前为人工触发)· 人工审核在哪一步介入 · 谁负责执行催款 · 最终报告自动送到哪里