项目标题里那句话说得很扎心“会开完了活还是没人干。”我在这行摸爬滚打多年见过太多团队不是执行力差而是开会产生的行动项在散会之后直接蒸发。说什么“会后发纪要”“我到时候跟进”结果三天后连当事人自己都想不起来当时承诺了什么。这次我尝试把AiiOnly和Workbuddy组合起来做了一个“会议行动项助手”一个管语义拆解一个管执行跟踪硬是把“开会”这件事的最后一公里给补上了。这篇文章不是产品发布会也不是纯理论分析而是我实际跑通一个流程之后的完整复盘。适合谁看两类人一类是被会议纪要折磨的运营、项目经理、团队负责人另一类是已经在折腾 AI 工作流工具但不知道怎么落地到具体场景的效率爱好者。下面我会把需求拆解、方案设计、实操步骤、踩坑过程全部写出来配置和提示词模板可以直接抄走改一版。1. 先拆需求会议行动项助手到底要解决什么问题1.1 一个行动项的完整生命周期从口头承诺到任务关闭开会这件事本质上是在制造“承诺”。有人承诺周五给方案有人承诺下周三对接完客户有人承诺月底前把数据跑出来。但问题在于这些承诺大多停留在口头层面散会之后就回到了聊天记录、邮件、甚至大脑缓存里。一个合格的行动项从诞生到关闭要经历五个阶段产生会议讨论时冒出来、明确定责任人、截止时间、验收标准、分发同步给相关人、跟踪确认是否推进、有无阻塞、关闭完成或重新排期。市面上 90% 的会议纪要工具价值停留在“产生”和“明确”之间——把话说清楚了但没人保证后续会执行。我想要的助手必须能管到“关闭”这一步。也就是说它不仅要能听懂会议里“这个事我来跟一下”这种模糊表达还要能把它翻译成一个带负责人、带截止日、带状态的任务卡片然后在后续几天里主动提醒、催办、汇总。这就不是一个简单的语音转文字工具能干的事了需要一个能理解语义的 AI 前端加一个能跑定时任务、能维护任务状态的工作流后端。1.2 为什么不是“一个工具全搞定”而是 AiiOnly Workbuddy 组合很多人看 AI 工具的思维是“找一个最强的解决我所有问题”。但我试过不少一体化工具之后发现越是想包揽所有环节的工具在具体场景里越容易显得笨重。会议行动项这个需求本质上包含两种完全不同的能力语义理解能力把口语化、碎片化、夹杂着甩锅和模糊承诺的会议内容提炼成结构化的“谁、做什么、何时完成、怎么算完成”。这是大语言模型最擅长的事。流程执行能力任务拆出来之后要存下来、要定时扫描、要到期提醒、要按人汇总、要更新状态、要同步到业务系统。这是工作流引擎和任务管理工具擅长的事。AiiOnly 在我这套方案里承担的是前者。它更像一个“场景化 AI 应用编排层”我可以快速定义一个“会议纪要解析员”智能体把提示词、输出格式、示例数据都配置好然后接入会议纪要文本拿到结构化的 JSON。Workbuddy 承担的是后者它本身是一个效率智能体工作台支持自定义指令、Skill技能、定时任务、历史对话和本地记忆像一个能长期值守的机器人秘书正好用来做任务分发、催办和进度汇总。这种“认知层 执行层”的组合方式比我以前用“一个表格 人工催”的模式舒服太多。人工催的痛点在于提醒内容总是一句干巴巴的“记得完成 XX”没有上下文容易被无视。而用 Workbuddy 做定时任务每次催办都可以带上行动项的原始背景、上次进展、还剩几天责任人想忽略都难。1.3 AiiOnly 和 Workbuddy 的分工边界很多人在搭建这类方案时最纠结的就是两个工具能力有重叠到底谁干什么我的经验是按“是否需要对自然语言做深度理解”来划线。能力环节AiiOnlyWorkbuddy会议纪要原文输入负责解析不参与行动项提取与结构化负责生成结构化数据不参与任务存储与状态维护可以短期存储负责长期维护定时催办提醒不参与负责定时触发与消息生成多轮追问/澄清负责协助历史记忆与习惯积累弱负责会记住我的催办风格数据同步到业务表输出端输入端简单说AiiOnly 是把“人话”翻译成“机器能读的结构化语言”Workbuddy 是把“结构化语言”翻译成“人会去执行的动作”。边界划清楚之后后面配置时就不会两遍都加提示词导致逻辑混乱。2. 方案设计从会议纪要“被动存档”到行动项“主动闭环”2.1 AiiOnly 端怎么配用“OWSAS 结构”约束输出而不是让 AI 自由发挥第一次做的时候我犯了一个新手都会犯的错只给 AiiOnly 说“请帮我提取会议行动项”然后它输出了一个又长又散的自然语言段落根本没法被下游处理。后来我把输出格式硬约束成一种我称之为OWSAS的结构每个行动项包含五个字段Owner责任人、What做什么、Start开始时间、Acceptance验收标准、Status状态。这五个字段不是拍脑袋定的。Owner 解决“活没人认领”的问题明确到人What 解决“到底做什么”的问题必须是一个动作描述Start 解决“什么时候开始”的问题很多任务完不成是因为根本没排期Acceptance 是最关键的一环让“做完了”这件事有客观标准而不是各说各话Status 用来标记未开始、进行中、阻塞、已完成。我在 AiiOnly 里配的智能体提示词核心大概长这样可以直接抄根据你的会议类型微调你是一个会议行动项解析器。请把用户输入的会议记录中所有行动项提取出来 按以下 JSON 格式输出不要输出任何额外说明 [ { owner: 责任人姓名或角色, what: 要做的事尽量是动词开头的短句, start: 开始日期格式 YYYY-MM-DD, deadline: 截止日期格式 YYYY-MM-DD, acceptance: 可验收的完成标准具体可衡量, status: not_started | in_progress | blocked | done } ] 约束 1. 如果会议中某件事没有明确负责人owner 写 待指派并把这条标记为高优先级关注。 2. 如果截止时间不明确根据上下文合理推断并在 start 或 deadline 旁边加注释。 3. 宁可提取少而准不要提取多而滥。 4. 若没有任何行动项输出 []。为什么要强迫它输出 JSON 而不是自然语言因为下一步 Workbuddy 要读取这个结果去做定时任务操作结构化数据才能稳定地写入表格、按人分组、按日期排序。如果让 AI 自由发挥输出千奇百怪下游脚本就得写一大堆异常处理纯属给自己挖坑。另外一个我实测有效的技巧在提示词里塞一个 few-shot 示例。AiiOnly 这类平台的 AI 对格式的理解有时候飘忽不定给一个“输入开头 正确输出”的示例稳定性会明显提升。下面是我用的示例节选示例输入“关于官网改版小王负责首页文案下周五前给到一版设计这边李姐说周四能出初稿上线时间还没定等文案和设计稿对齐后再确认。” 示例输出 [ { owner: 小王, what: 完成官网首页文案初稿, start: 2025-06-09, deadline: 2025-06-13, acceptance: 首页全部文案含主标语、板块描述、CTA以文档形式交付, status: in_progress }, { owner: 李姐, what: 输出官网改版设计初稿, start: 2025-06-09, deadline: 2025-06-12, acceptance: 设计稿包含首页视觉方案可供评审, status: in_progress }, { owner: 待指派, what: 确认官网改版上线时间, start: 2025-06-13, deadline: 2025-06-17, acceptance: 与文案、设计对齐后确定上线排期并同步全员, status: not_started } ]把这段喂给 AiiOnly 之后输出稳定性明显上了一个台阶。之前偶尔会出现字段名写错、把两个人合并成一个行动项、甚至编造不存在的任务的情况加了示例之后这些低级错误基本消失。2.2 Workbuddy 端怎么做一个 Skill 管一件事别把全家桶塞进一个 Prompt热搜词里有不少人搜“workbuddy skill 怎么用”我估计大家都是被“技能”这个词吸引来的但又不清楚在实践里到底怎么设计。我的经验是不要试图让一个 Skill 完成所有动作而是拆成多个职责单一的 Skill。我在 Workbuddy 里建了三个 Skillparse_action_items接收 AiiOnly 输出的 JSON 或者原始纪要文本做二次规整。重点是把“待指派”的任务单独过滤出来防止它被后续流程漏掉。distribute_tasks按人分组把每个责任人的任务发送到对应会话或群组。这里有个细节消息模板要固定否则每次 AI 生成的语气不一样人会感觉是机器在催还是人在催差别很大。daily_followup每日扫描任务表找出今天到期、明天到期、已经阻塞的任务生成一份“今日行动项清单”和“到期预警清单”。为什么要拆成三个而不是合一个核心原因是排错和维护的便利性。合在一个 Skill 里一旦输出不对你不知道是解析的问题、分组的问题还是消息模板的问题。拆开之后每个 Skill 都能单独测试哪个环节挂了直接看哪一段日志。而且 Workbuddy 的 Skill 机制本身也鼓励模块化每个 Skill 可以绑定独立的指令和历史记忆互不污染。2.3 两个工具怎么衔接共享表格比 API 直连更省心一开始我本来想通过 API 把 AiiOnly 的输出直接推到 Workbuddy后来发现维护成本太高认证、字段映射、错误重试都是事。后来我改了一个更务实的方式中间用一张多维表/电子表格作为数据总线。AiiOnly 负责把会议纪要解析成 JSON通过脚本写入表格Workbuddy 定时读取表格做催办和状态更新。这个做法牺牲了一点点实时性但换来了极大的灵活性你随时可以打开表格看全局手动修正某条任务甚至让业务同事直接填状态。你可以根据实际情况把表格换成飞书多维表、维格表、在线 Excel思路完全一致。我用到的表格字段如下字段名类型说明任务ID文本唯一标识避免重复负责人文本Owner任务内容文本What开始日期日期Start截止日期日期Deadline验收标准文本Acceptance状态单选未开始/进行中/阻塞/已完成来源会议文本记录是哪次会议产生的最后跟进日期日期用于判断是否长时间没动静这个结构看起来简单但真正用起来你就知道“来源会议”和“最后跟进日期”是两个容易被忽视却极其有用的字段。前者让你的行动项有回溯入口后者让 Workbuddy 在发提醒时可以判断“这条任务是不是已经躺在那就没人管了”。3. 实操复盘从零到一搭出一个能用的助手3.1 环境准备Workbuddy 安装与启动踩坑记录先说 Workbuddy 的安装。它支持多种使用方式我个人的建议是先别一上来就本地部署先装官方客户端或者使用网页版流程跑通了再考虑私有化部署。我一开始过于自信直接上了本地部署结果环境依赖调了半天连基础服务都没起来差点放弃。Workbuddy 在安装和启动环节高频出现的问题有两个启动非常慢和网络连接失败错误码 3002。我分别说一下排查思路。启动慢先看历史对话记录是不是太长。Workbuddy 有本地记忆机制会把历史会话和记忆加载到工作区如果你的历史记录已经积累了几个月首次启动会明显变慢。处理方式是在设置里清理不重要的历史会话或者对本地记忆做一次归档迁移保持工作区精简。网络连接失败 3002我遇到的场景是服务能打开但一执行联网类操作就报错。后来排查下来是系统防火墙把 Workbuddy 内置依赖的本地服务端口拦了。这个问题在 mac 和 Windows 上都可能遇到。排查步骤我整理如下先看系统时间是否同步。别笑时间偏差超过几分钟很多本地服务握手就会失败。检查防火墙是否放行了 Workbuddy 及其关联服务。这里建议不要一刀切关闭防火墙而是手动添加入站/出站规则。检查端口冲突。Workbuddy 内置服务如果不幸和某个本地应用占用了同一端口启动就会异常。你可以在开发者平台或者日志里看到具体端口信息换成空闲端口即可。如果以上都排除了查看日志文件重点看是connection refused还是timeout。前者一般是端口/服务问题后者一般是网络路由问题。这些坑排查完之后Workbuddy 基本就能稳定跑了。我的建议是先把一个最简单的定时任务跑通比如每天 9 点输出一句“今日行动项提醒”确认定时触发链路是通的再往里面加业务逻辑。别上来就一天配 10 个 Skill一旦出错全都在冒泡你根本不知道从哪查起。3.2 核心流程落地AiiOnly 解析之后Workbuddy 怎么接任务整个流程的起点是“把会议纪要喂给 AiiOnly”。我是这样做的会议结束后把录音转文字或者直接把手动整理的要点丢进 AiiOnly 配置好的智能体它会返回标准的 JSON 数组。然后我用一个简单的脚本把这个 JSON 写入多维表。脚本逻辑参考如下这是一个最小可用版本的 Python 示例实际你根据用的表格 API 调整即可import json import requests # AiiOnly 解析得到的结果 action_items [ { owner: 小王, what: 完成官网首页文案初稿, start: 2025-06-09, deadline: 2025-06-13, acceptance: 首页全部文案以文档形式交付, status: in_progress } ] # 写入多维表的通用逻辑替换为实际表 API for item in action_items: row { 负责人: item[owner], 任务内容: item[what], 开始日期: item[start], 截止日期: item[deadline], 验收标准: item[acceptance], 状态: item[status], 来源会议: 官网改版周会 } # requests.post(your-table-api-endpoint, jsonrow) print(f写入任务: {row[负责人]} | {row[任务内容]})这个脚本本身没什么技术含量但它把 AiiOnly 和 Workbuddy 之间“最后一米”给接通了。写完数据之后Workbuddy 就可以登场了。3.3 配置定时催办与状态同步Workbuddy 的核心用法Workbuddy 接任务的方式我用的是“定时扫描 条件触发”的思路。在 Workbuddy 里新建一个名为daily_followup的 Skill配置一个每天上午 9 点执行的计划任务主要做三件事读取多维表中所有未完成的行动项。按截止日期分组今天到期、明天到期、已过期、无截止日期待补充。生成两条消息一条是“今日行动项提醒”发给相关责任人一条是“待指派任务列表”发给项目负责人。这里最重要的就是消息模板。模板一旦确定不要频繁换风格否则大家会失去熟悉感。我的模板参考如下【今日提醒】你有 3 条行动项需要在今天内推进 1. [官网文案] 截止今天验收标准首页全部文案交付 2. [竞品调研] 截止明天当前状态进行中 3. [设计稿评审] 已逾期 2 天负责人李姐请确认是否阻塞 如果有阻塞请回复“阻塞原因”我会记录并同步到项目表。这个模板里我刻意加了一句“请确认是否阻塞”目的是把“催进度”变成“收集信息”人的抗拒感会低很多。很多人被催任务时天然有防御心理但如果只是让他回一个“阻塞原因”配合度会高很多。定时任务之外我还配了一个“手动触发”入口。每次开完会我直接在 Workbuddy 对话里说“解析今天会议纪要并入库”它就会调起 parse 流程。这样既保留自动采集又有临时应急的能力。4. 常见问题与排查技巧实录4.1 为什么 AiiOnly 偶尔提取不准行动项被漏掉这是使用初期最高频的问题。我复盘后总结出三个主要原因和对应解法输入太乱如果原始纪要是多人发言交织的长文本AiiOnly 容易抓错主语。解决办法是在喂给 AiiOnly 之前先做一层轻量清洗——至少把不同发言人用分隔符切开或者手动加一句“下面是小王在会议中做出的承诺”这类上下文引导。格式约束不够硬有些模型平台对“只输出 JSON”的遵守并不严格。除了在系统提示词里写清楚还可以在 AiiOnly 后处理环节加一道“JSON 合法性检查”解析失败就自动要求模型重试一次。漏掉“隐性行动项”有时会上说的不是“我负责”而是“这个方向我们需要研究一下”这种容易被当成闲聊跳过。我的解决方法是在提示词里专门加一条“如果出现‘需要、应该、得、想办法’这类表达视为潜在行动项并提取owner 写待指派。”实践下来漏项率大幅下降。另外还有一个小技巧每跑完一次解析顺手在表格里记录统计——输入了多少条会议记录、提取出多少行动项、多少条被判为待指派。持续两周之后你就知道当前提示词在这个场景下的真实召回率而不是凭感觉觉得“好像还行”。4.2 Workbuddy 连接不上、执行异常真正管用的排查顺序前面提过 3002 连接失败这里再扩展一下这类问题在 Workbuddy 里基本分三层网络层、服务层、配置层。网络层检查本地网络能不能正常工作访问外部服务是否受限。之前遇到过一个很隐蔽的问题公司内网对某些服务域名解析异常导致 Workbuddy 联网能力时好时坏。服务层Workbuddy 内置的服务进程有没有正常启动。可以在任务管理器/活动监视器里看进程是否存续或者查看日志。这一步能直接过滤掉 70% 的“莫名其妙挂了”的问题。配置层多个 Skill 之间是否存在自定义指令冲突。注意这里说的冲突不是报错而是两个 Skill 都在抢同一个动作导致重复执行。我有一次配置了“自动解析”和“手动解析”两个 Skill结果自动解析的规则把手动触发的 task 也吞了动作重复执行了两遍。最后处理方式是在 Skill 配置里加一个“触发来源”的判断条件自动任务和手动入口走完全不同的分支。4.3 催办没人理、消息被屏蔽收敛频率比提高语气强度更有用这个问题的根源通常不是 Workbuddy 不会催而是“催得太频繁、太机械”。我刚开始配置的时候设了每天早上和下午各催一次结果第三天就有同事跟我说“能不能把机器人静音”。后来我把策略改了只在三个时间点提醒——截止前 1 天、截止当天、逾期后第 1 天。前两个正常提醒逾期后不催促只发一条“任务状态确认”消息让责任人选择“已完成”“延期并给新时间”“需要帮助”。这比一味催更有效因为你把“冲突”转化为“信息收集”。另外Workbuddy 本身支持自定义指令和个性化语气我强烈建议把催办语气调整成你们团队的说话风格而不是机器翻译腔。比如我们团队喜欢“哥们官网文案今天要交了有问题随时喊我”这种风格那就在 Skill 的指令里注明“语气口语化、同事间交流风格”。4.4 历史对话和本地记忆迁移换电脑不丢“习惯”我中途换过一次机器一开始以为 Workbuddy 的配置和记忆是同步在云端的结果发现本地记忆默认不自动迁移。如果你在旧机器上积累了大量历史对话和自定义指令习惯换机器前务必做一次数据目录备份。Workbuddy 的本地记忆迁移核心是把数据库文件和配置文件拷贝到新机器的对应目录。建议顺序是先在新机器上装好、启动一次再关闭然后用旧文件覆盖新文件。如果你在开发者平台有账号也可以先导出配置再在新环境导入。我当时没做任何备份直接换了机器结果所有 Skill 指令、记忆、历史会话全没了等于从零开始重配。所以这一条算是我用真金白银换来的教训。还有一个容易被忽略的点本地记忆如果积累了太多无关对话反而会影响 Workbuddy 后续生成质量。它把自己看到的“历史对话习惯”当成你的风格参考如果你经常在里面聊午饭吃什么它可能在催办消息里也带着一股美食推荐味儿。定期清理历史对话和定期清理缓存一样重要。最后的一些体会这套 AiiOnly Workbuddy 的组合我用了快一个月最大的感受不是“省了多少时间”而是会议纪要从“存档”变成了“驱动”。以前散会后纪要躺在文档工具里无人问津现在散会后行动项会自动变成带责任人、带截止时间、带验收标准的任务并且有人盯着推进。这种变化对团队效率的提升非常明显。如果你也想搭一套我建议从最小闭环开始先用 AiiOnly 把一次真实会议的纪要解析成结构化 JSON再在 Workbuddy 里配一个最简单的每日提醒不要一上来就整十几个 Skill。流程跑通之后再逐步加“阻塞标注”“周报汇总”“待指派任务复盘”这些衍生功能。最后分享一个我踩了多次坑之后觉得最值得记住的经验不要追求 AI 一次输出完美。AiiOnly 解析出来的结果大概率会有需要人工微调的地方所以一定要留一个人工确认的入口——不管是表格里设一个“确认人”字段还是每天花两分钟浏览新增任务。工具是帮你省掉重复劳动而不是替你做判断。想清楚这一点你的工具组合才会越用越顺手而不是越用越不敢信。