项目标题里那句话说得很扎心：“会开完了，活还是没人干。”我在这行摸爬滚打多年，见过太多团队不是执行力差，而是开会产生的行动项在散会之后直接蒸发。说什么“会后发纪要”“我到时候跟进”，结果三天后连当事人自己都想不起来当时承诺了什么。这次我尝试把AiiOnly和Workbuddy组合起来，做了一个“会议行动项助手”，一个管语义拆解，一个管执行跟踪，硬是把“开会”这件事的最后一公里给补上了。
这篇文章不是产品发布会，也不是纯理论分析，而是我实际跑通一个流程之后的完整复盘。适合谁看？两类人：一类是被会议纪要折磨的运营、项目经理、团队负责人，另一类是已经在折腾 AI 工作流工具但不知道怎么落地到具体场景的效率爱好者。下面我会把需求拆解、方案设计、实操步骤、踩坑过程全部写出来，配置和提示词模板可以直接抄走改一版。
1. 先拆需求：会议行动项助手到底要解决什么问题
1.1 一个行动项的完整生命周期：从口头承诺到任务关闭
开会这件事，本质上是在制造“承诺”。有人承诺周五给方案，有人承诺下周三对接完客户，有人承诺月底前把数据跑出来。但问题在于，这些承诺大多停留在口头层面，散会之后就回到了聊天记录、邮件、甚至大脑缓存里。
一个合格的行动项，从诞生到关闭要经历五个阶段：产生（会议讨论时冒出来）、明确（定责任人、截止时间、验收标准）、分发（同步给相关人）、跟踪（确认是否推进、有无阻塞）、关闭（完成或重新排期）。市面上 90% 的会议纪要工具，价值停留在“产生”和“明确”之间——把话说清楚了，但没人保证后续会执行。
我想要的助手，必须能管到“关闭”这一步。也就是说，它不仅要能听懂会议里“这个事我来跟一下”这种模糊表达，还要能把它翻译成一个带负责人、带截止日、带状态的任务卡片，然后在后续几天里主动提醒、催办、汇总。这就不是一个简单的语音转文字工具能干的事了，需要一个能理解语义的 AI 前端，加一个能跑定时任务、能维护任务状态的工作流后端。
1.2 为什么不是“一个工具全搞定”，而是 AiiOnly + Workbuddy 组合
很多人看 AI 工具的思维是“找一个最强的，解决我所有问题”。但我试过不少一体化工具之后发现，越是想包揽所有环节的工具，在具体场景里越容易显得笨重。会议行动项这个需求，本质上包含两种完全不同的能力：
- 语义理解能力：把口语化、碎片化、夹杂着甩锅和模糊承诺的会议内容，提炼成结构化的“谁、做什么、何时完成、怎么算完成”。这是大语言模型最擅长的事。
- 流程执行能力：任务拆出来之后，要存下来、要定时扫描、要到期提醒、要按人汇总、要更新状态、要同步到业务系统。这是工作流引擎和任务管理工具擅长的事。
AiiOnly 在我这套方案里承担的是前者。它更像一个“场景化 AI 应用编排层”，我可以快速定义一个“会议纪要解析员”智能体，把提示词、输出格式、示例数据都配置好，然后接入会议纪要文本，拿到结构化的 JSON。Workbuddy 承担的是后者，它本身是一个效率智能体工作台，支持自定义指令、Skill（技能）、定时任务、历史对话和本地记忆，像一个能长期值守的机器人秘书，正好用来做任务分发、催办和进度汇总。
这种“认知层 + 执行层”的组合方式，比我以前用“一个表格 + 人工催”的模式舒服太多。人工催的痛点在于：提醒内容总是一句干巴巴的“记得完成 XX”，没有上下文，容易被无视。而用 Workbuddy 做定时任务，每次催办都可以带上行动项的原始背景、上次进展、还剩几天，责任人想忽略都难。
1.3 AiiOnly 和 Workbuddy 的分工边界
很多人在搭建这类方案时最纠结的就是：两个工具能力有重叠，到底谁干什么？我的经验是，按“是否需要对自然语言做深度理解”来划线。
| 能力环节 | AiiOnly | Workbuddy |
|---|---|---|
| 会议纪要原文输入 | 负责解析 | 不参与 |
| 行动项提取与结构化 | 负责生成结构化数据 | 不参与 |
| 任务存储与状态维护 | 可以短期存储 | 负责长期维护 |
| 定时催办提醒 | 不参与 | 负责定时触发与消息生成 |
| 多轮追问/澄清 | 负责 | 协助 |
| 历史记忆与习惯积累 | 弱 | 负责，会记住我的催办风格 |
| 数据同步到业务表 | 输出端 | 输入端 |
简单说，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 里建了三个 Skill：
- parse_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", json=row) 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 解析出来的结果，大概率会有需要人工微调的地方，所以一定要留一个人工确认的入口——不管是表格里设一个“确认人”字段，还是每天花两分钟浏览新增任务。工具是帮你省掉重复劳动，而不是替你做判断。想清楚这一点，你的工具组合才会越用越顺手，而不是越用越不敢信。
