WorkBuddy 最稳的用法，是把评审标准变成模板

我不太信“越用越聪明”的评审 Agent。最近刷到一篇讲 ECC Kiro code-reviewer 的文章，里面那套方法挺硬，先拿 diff，再定范围，读周边代码，套清单，最后只报置信度大于 80% 的问题；严重度分 CRITICAL、HIGH、MEDIUM、LOW，没有值得报的就闭嘴。

只报告确定问题，零发现即通过。

我第一反应想到 WorkBuddy。WorkBuddy 我用了大约一个月，之前写过合并表格报错，后来确认多半是模式选错。办公工具也一样，没必要让它现场推理，把动作固化成模板更稳。

我们组每周要把代码合并请求的评论、飞书文档里的会议纪要、测试导出的缺陷表汇总成评审日报。以前是人工贴 Excel，vlookup 来回补字段。现在我把这套动作搬进 WorkBuddy。第一次用的人别急着丢文件。打开 WorkBuddy，首页左侧找 模板中心；我这版在左侧导航，右上角有 新建模板。名称写 PR评审日报，类型选 表格处理，不要选 自由问答。模板就是预先固定输入字段和输出格式，自由问答更像聊天，容易漏列。

上传源文件。我的环境是飞书文档导出 .xlsx，也就是 Excel 表格文件，字段包括 file、line、severity、confidence、summary、owner、status。WorkBuddy 右侧会出现列名预览，能看到它把表头识别成字段。如果列名没出来，点 字段映射，把 严重度 映射到 severity，把 置信度 映射到 confidence。这一步别省。我踩过的坑就是表头从 等级 改成 severity，模板直接跑歪。

规则区填固定指令，筛选 severity 为 CRITICAL 或 HIGH，且 confidence 大于等于 80；MEDIUM 按文件和规则合并；LOW 跳过；未变更代码里的问题跳过，只有 CRITICAL 安全类例外；没有命中记录时输出 零发现，通过。置信度就是评审者或工具对问题真实性的把握，阈值设太低会噪声满屏。我用 80 是因为我们组接受误报少于漏报，不一定适用所有人。

输出模板再配一下，标题用日期，正文先放 结论，再放表格。点 试运行，右侧会生成日报预览，确认 零发现，通过 能正常出现，再点 导出 或复制到飞书文档。我一般导到共享文件夹，文件名固定 review_daily_YYYYMMDD.xlsx。看到导出成功提示后，再回源表核对一次严重度和负责人，基本就能放心交给组员看。

权限也顺手设。模板所有者只留给我，组员在共享文件夹只读，测试同学可以提字段修改，但不能直接改线上模板。

在飞书共享文件夹里，把 WorkBuddy 的输出账号设成只读源表，只能写输出目录。这样出错时能回滚，也不会在会上互相追问谁改了表。它要是真能替我开会，我反而不敢用。

日常运维就三件事。每周五跑前检查源表列名，跑后看 confidence 有没有空值，规则改动先 复制模板 试跑。我这边试下来，一次只让它干一件事，比把需求堆成一段话准得多。

往后看，办公 Agent 大概会走代码评审那条路，先有阈值、分级、通过判据，再谈智能。WorkBuddy 这类工具真正省时间，靠的是把扯皮的标准写进模板。能用就行。