WorkBuddy 用了一个月，它不是游戏开发 Harness，却是我策划案日常任务的 SSR 入口

WorkBuddy 用了一个月，它更像游戏策划案日常任务的 SSR 入口

凌晨三点，我还在改策划案，刷到一篇 KayingCodex 的介绍。介绍里说它被描述成专为游戏开发深度优化的 Agent Harness，把项目上下文、素材、运行、发布串成一条线，Agent 能驱动开发、检查、试玩，甚至推进发布。

我看完没先担心会不会替代策划，只想到另一个问题，WorkBuddy 用了大约一个月，能不能也给我这种散乱日常任务搭一个类似的工作面。

我是游戏策划，每天最头疼的是策划案、资产表、Unity 配置表、运营邮件、版本会议、临时需求全都散在各处。玩法中二与否排在后面。

Skill 有用，决定 WorkBuddy 能不能进日常流程的关键，是它能不能把信息整理成可检查、可追溯、可回退的状态。没有状态和边界的 AI，就像一个刚学会放技能的队友，场面华丽，落地全是事故。

我把 WorkBuddy 放在策划案日常入口

WorkBuddy 用了大约一个月后，我把它放在策划案日常入口，每天把 Unity 导出变更、文档新增、邮件反馈、会议结论汇总成一份可检查的版本日报。最近一周才接上飞书文档，飞书表格也刚上手，定时任务则用了大约一个月。这些工具只是入口，最终要看能不能稳定产出可检查的版本日报。

这个流程并不复杂，但很真实。复杂的是字段和状态。同一个资源，在不同来源里叫法不同，Unity 导出叫 asset_type，设计文档叫分类，运营表里可能只剩一串文件名。WorkBuddy 如果只负责理解，很容易理解过头，把没有依据的空字段补成特效，还会把待确认写成已完成。

对策划案来说，这类错误比生成慢更致命。所以我更看重 WorkBuddy 能不能把任务拆成明确状态，成功生成、字段缺失、源文件无法读取、输出为空。定时任务用了大约一个月后，我的态度也很明确，不要追求全自动。WorkBuddy 跑定时任务，最怕静默失败。权限没开，表格没同步，任务没动静，看起来在自动跑，实际什么也没产出。

一次只让它干一件事，先抽字段，再对齐枚举，最后生成检查清单。结果反而稳定。没有完全解放，但至少把最没技术含量的汇总活交出去了，剩下的时间用来盯异常项。

WorkBuddy 和 KayingCodex 的差别在验证方式

KayingCodex 这套东西很像一个游戏开发专属 Harness。它把对话、项目、素材、本地运行、TapTap Maker、发布流程放在同一个工作面里。你负责说清目标、试玩和做决定，它负责把每次对话落到项目文件、开发动作与可验证结果里。

你负责说清目标、试玩和做决定；Harness 负责把每次对话落到项目文件、开发动作与可验证结果里。

这句话点到了 WorkBuddy 的短板。

WorkBuddy 是职场 AI 智能体工作台，能处理文档、表格、邮件、PPT、数据分析、文件整理。它的核心是把办公信息整理成可检查，不负责把游戏跑起来。KayingCodex 关心游戏有没有被做出来，WorkBuddy 关心策划案有没有被写明白、表格有没有对齐、会议结论有没有变成任务。

如果让我下判断，KayingCodex 更像程序、TA、制作人需要的游戏开发 Harness。WorkBuddy 更像策划、运营、行政、内容团队需要的通用办公 Harness。两者面向的工作面不同。

我羡慕 KayingCodex 的地方，是它把验证做成了工作台的一部分。对话、项目文件、下一步能执行什么，都一直可见。这个设计很成熟。Agent 产品最怕上下文散掉。聊着聊着，它忘了当前项目是谁，忘了文件在哪里，忘了刚才那个字段是不是已经确认过。

WorkBuddy 现在的问题也在这里。它可以处理很多办公任务，但任务之间还是太像独立会话。这一个月里，只要输入源一多，它就会开始凭感觉。最近一周接上飞书文档、刚上手飞书表格，再加上邮件和 Unity 导出，这些东西如果没被绑成一个项目上下文，WorkBuddy 很容易把今天的需求接到昨天的版本上。

我不喜欢那种宣传里一句话生成 Demo 的爽感。对策划来说，一句话生成出来的东西不可信。生成漂亮页面本身不难，麻烦的是每次改动能不能追溯，能不能检查，能不能被团队接受。一个可玩 Demo 如果说不清改了哪个字段、为什么改、谁确认过，那它更像视频素材，离生产资产还差检查。

所以 WorkBuddy 和 KayingCodex 的差别主要落在验证方式上。一个偏游戏开发流程，一个偏办公信息流程。前者验证玩法，后者验证任务状态。

它需要补上项目上下文和检查点

这几天我在试 Notion，飞书表格也刚上手。说实话，这两个东西都还在能不能用的阶段，谈不上用得多深。我已经明显感觉到，表格和文档用来承载任务状态，展示只是附带。Notion 的页面结构、飞书表格的字段、WorkBuddy 的自动化，只要缺一个检查点，最后都会变成一堆漂亮垃圾。

WorkBuddy 的优势很明显。它通用，能接文档、表格、邮件、PPT、数据分析。它适合那种没有标准答案的工作流，今天整理分镜，明天汇总运营反馈，后天把 Unity 导出的配置变更写成版本日志。对很多团队来说，这种通用能力比垂直游戏开发 Harness 更日常。

但是 WorkBuddy 的缺点也很直接。它还没有把办公任务做成一套有状态、有边界、有验证的工作台，现在更像一个很会干活的助手。你给它一堆输入，它会尽量交差，但它不天然知道交差的标准。这个标准还得人写。

所以我现在给 WorkBuddy 的定位很明确，它承担通用办公工作台角色，把素材、文档、表格、邮件、任务状态串起来。对策划来说，它更像日常任务的 SSR 入口，不替你做游戏，但能把散乱需求收束成可检查、可追溯、可回退的工作面。

我希望它后续补上更清楚的项目上下文。它不需要变成 KayingCodex，不需要本地 runtime，也不需要管游戏发布。一个版本包下面，能绑定飞书文档、Unity 导出、邮件线程、飞书表格、Notion 页面、检查点状态。每次任务都知道自己服务哪个版本，哪个需求，哪次变更。输出最好是一组可点击、可回退、可追责的对象，单篇报告不够。