TRAE Work实战：我把会议纪要做成了skill
话题
#TRAE Work 实战帮｜标签建议：职场效率 / AI 办公 / 会议纪要 / 自动化 / 零代码 本文参与「#TRAE Work 实战帮」征文，全程零代码，所有"运行结果"都用一场真实需求评审跑给你看。
一、一个真实的会后场景
周五 17:09，第三个会刚散。老板在群里 @ 我：「今天几个会的结论整理下发我，待办也列清楚。」
桌面上三个录音文件。换以前，这种时候我得花差不多四十分钟：边听边记、把七八个人的话对齐成"谁负责、啥时候交"、再改一版能发群的。看着我自己的一堆todo,这种繁琐的活让人十分头疼。不过现在，我大概十分钟就能把一份带负责人、带截止、能直接丢回群里的纪要交出去。
不是我写得多快了，是活的性质变了：会议纪要里最磨人的"结构化、对齐、改写"，我用 TRAE Work 的纯对话跑完了，一行代码没写。
这篇文章不灌概念。我以"会议纪要"为切口，先讲人工做法有多费劲，再讲它到底贵在哪，然后给你一套能直接抄的指令，用一场真实需求评审把每一步跑给你看，最后讲怎么把它沉淀成 skill、再升级成自动化工作流。你照着跑，下一场会就能用。
二、以前的人工做法
把一场会整理成纪要，手工流程其实是这样的：
- 听录：把录音转成文字（这一步现在工具能代劳，飞书妙记、讯飞听见都行）。
- 归纳：边听转写边把散乱的话，重组成"结论是什么、谁说的、有没有争议"。
- 对齐：从七八个人的话里，抽出"谁负责哪件事、啥时候交"。
- 改写：同一份内容，还要再写一版"发给老板/丢群里"的精简版。
- 核对：挨个人名、日期、结论逐一确认，别替别人乱拍板。
第 2--4 步最吃时间，也最没技术含量------它们不是"写得好不好"的问题，是"把已有信息反复搬来搬去"的问题，既占用时间精力，又没有实际的价值。
很多人以为会议纪要费时间是因为"要写字"。错了。真正贵的不是文笔，是三类隐性劳动：
| 隐性劳动 | 它在干嘛 | 手工怎么干 |
|---|---|---|
| ① 结构化 | 把散乱转写重组成「结论 / 讨论 / 待决策」 | 自己边听边归纳，容易写成流水账 |
| ② 信息对齐 | 从多人话里抽出"谁负责、啥时候交" | 人工逐人核对，漏负责人是常态 |
| ③ 角色转换 | 同一内容换"老板版 / 群同步版"重写 | 复制粘贴后再手动改一版 |
关键认知：这三类活，恰是 AI 对话工具最擅长的。它不替你"拍板下结论"，但极擅长"按你给的标准，把已有信息重新组织"------结构化、对齐、改写，本质都是"重组信息"，正是它的强项。
三、解决问题：TRAE Work 用什么能力接住这三类活
先建立认知再走流程。我把 TRAE Work 在这套工作流里的能力拆成四类，前三类的每一类，刚好接住上面的一类隐性劳动；第四类是"胶水"，把前三步串起来：
| TRAE Work 能干的 | 接住哪类隐性劳动 | 具体帮你做什么 |
|---|---|---|
| ① 结构化整理 | 隐性劳动① | 把散乱转写按「结论 / 讨论 / 待决策」分块成正式纪要 |
| ② 信息对齐成表 | 隐性劳动② | 自动抽行动项，对齐成「事项 / 负责人 / 截止 / 优先级」表格 |
| ③ 换角色重写 | 隐性劳动③ | 同一内容一键出"老板版""群同步版" |
| ④ 多轮对话 + 零代码 | 串联全部 | 记上下文，接着上一轮继续追问、让它改；全程复制指令，不写代码 |
记住这张表。下一节跑实战时，每一步都先点明"这步完成什么、用哪个功能"，再给指令和结果，你不会"照抄完不知所以然"。
四、用 TRAE Work 怎么完成（三步 + 每步：完成什么 / 指令 / 截图 / 结果）
全程零代码。你在 TRAE Work 桌面版里，把会议转写文本贴进去，逐条给指令就行。
下面用的案例，是我一场「商家智能营销券包」需求评审会的转写（数据脱敏）。先放整体流程图，你心里有个数：
准备：把录音转成文本
把会议录音转化成一段纯文本，可以利用现有的工具完成(飞书妙记、讯飞听见等)。 转写出长这样（篇幅有限每个会议只截取一段）：
**会议一:**商家智能营销券包需求评审
老周： 好，人差不多齐了，我们开始。今天主要是拉大家评审一下营销中台 Q3 的新需求------商家智能券包。菲菲你先给大家过一下业务背景？
菲菲： 行。其实背景很简单，我们现在平台上大概有 60 万活跃商家，但真正会用营销工具的不到 30%。我们之前做了个调研，商家反馈最大的痛点是"不会选人群"------他们不知道该给谁发券。所以这次想做一个智能券包功能，系统帮商家自动圈人、自动发券，商家只需要设置一个预算上限和券面额就行。
小鹿： 那等于商家端操作极简化了？就填个金额和预算，点一下"智能发放"就完了？
菲菲： 对，MVP 版本就是这个思路。后续我们可能会开放更多配置项，但第一版越简单越好。
老周： 嗯，这个定位大家先记住------第一版是"傻瓜式"的智能发放，商家零决策成本。那我投一下 PRD 里的产品架构图。
...
会议二： 每日项目进度对齐（约 30 分钟）
敏姐： OK 大家，今天周三 daily。还是老规矩，每个人快速过一下昨天做了什么、今天计划、有没有阻塞。小陈你先。
小陈： 昨天我主要在搞订单创建链路的分布式事务改造。之前 Seata AT 模式压测发现 undo_log 写入瓶颈，TPS 卡在 200 上不去。昨天我改成了 RocketMQ 事务消息方案，把"扣库存"和"生成支付单"拆成异步事件。本地单测跑通了，今天准备跟老何联调。
老何： 我昨天在接你那边的新接口。有个问题------你那个事务消息的 half message 发送之后，如果本地事务执行失败了，你那边 commit/rollback 的回调是怎么处理的？我这边看到有时候会收到重复的 half message。
小陈： 啊，这个我还没处理幂等。你是说 MQ 那边可能因为网络重试发多次 half message？
老何： 对，RocketMQ 的事务消息如果 broker 没收到 commit，会回查 producer。你那边回查逻辑如果处理慢了，broker 可能多次回查。
小陈： 明白，那我得在本地事务表加一个状态字段，回查的时候先查状态，已经处理过的直接返回 commit，不重复执行。这个我今天加上。
...
会议三： 运维技术沟通（约 20 分钟）
老魏： 好，我们开始。今天主要是对一下明天营销系统智能券包上线的发布方案。阿杰你先说一下这次变更的具体内容。
阿杰： 这次三个服务：coupon-service 2.4.0、activity-service 1.9.0、intelligent-service 1.0.0 首次上线。核心变更就是智能券包的发放链路------圈人、发券、推送。
小孙： intelligent-service 首次上线，那它的 deployment yaml、service、configmap 这些都准备好了吗？
阿杰： 准备好了。Yaml 在 GitLab 的 infra 仓库里，已经提了 MR，你们可以review。
小孙： 我看一下......namespace 是 marketing-prod，resource request 是 1C2G，limit 是 4C8G，replicas 3。HPA 配了 CPU 60% 触发，maxReplicas 10。JVM 堆 4G，G1GC。这个配置我没什么问题。但你们 liveness 和 readiness probe 配了吗？
阿杰： 配了，readiness 是
/actuator/health/readiness，liveness 是/actuator/health/liveness，超时 3 秒，间隔 10 秒。小孙： 行，那这块 OK。
...
第一步：结构化纪要
把上面那段"散乱的会议转写"变成一份"正式纪要",按【结论 / 讨论 / 待决策】分块、每条结论标提出人、关键数据原样保留。
写入prompt：
markdown
根据下面这三段会议转写，整理一份正式会议纪要。
要求：
1. 分【会议结论 / 关键讨论 / 待决策事项】三块；
2. 每条结论标注提出人；
3. 关键数据原样保留，不要改写；
4. Markdown 排版，语言客观简洁。为什么这么写：分三块，是为了让"结论"和"讨论"分开，老板一眼看定论；标提出人，是给复盘留追溯（谁拍的板一清二楚）；原样保留数据，是防 AI 自作主张改数字------这是"审纪要的人"最后一道关。
执行截图 ： 
结果
markdown
会议结论：
1. MVP 定位：第一版为"傻瓜式"智能发放，商家仅需设置预算上限和券面额，系统自动圈人、自动发券，商家零决策成本。【提出人：菲菲 / 老周】
2. 核心流程：商家点按钮 → 3 秒内返回"任务已提交" → 前端 3 秒轮询进度（Redis 存进度，降级查 DB） → 发放完成后统一批量推送。【提出人：老周 / 阿杰】
...
排期计划：
- 阿杰：下周一出技术方案初稿，下周三技术方案评审。【提出人：阿杰】
- 小鹿：下周一给前端估时。【提出人：小鹿】
- 星哥：本周跑通特征工程，下周出模型第一版，下周五前给接口。【提出人：星哥】
- 下周一先对技术方案，下周五对联调计划。【提出人：老周】
关键讨论：
- 业务背景：平台约 60 万活跃商家，真正会用营销工具的不到 30%，商家最大痛点是"不会选人群"。
- 预计算量级：60 万商家 × 平均 2000 用户 = 12 亿条打分记录，Spark 集群跑约 1-2 小时。
...
待决策事项：
1. 头部商家个性化模型 vs 长尾商家规则引擎的分层策略：MVP 版本系统自动判断走模型还是规则，商家无感知；后续是否开放"智能程度"开关给商家自选，需跑 1-2 个周期看转化率数据后再定。【待定，提出人：小鹿 / 老周】
2. TiDB 写入方案细节：老钱下周出 bulk load 写入方案，需与 DBA 对齐。【待输出，提出人：老钱】
...第二步：抽取行动项
从上面那份纪要里，把散在各人话里的"待办"自动抽出来，对齐成一张表------列 = 事项 / 负责人(DRI) / 截止 / 验收标准 / 优先级。人多嘴杂最易漏的，就是"谁负责、啥时候交"。
写入prompt：
arduino
从上面临时纪要比抽取"行动项清单"，用表格呈现：
列 = 事项 / 负责人(DRI) / 截止时间 / 验收标准 / 优先级(P0-P2)。
只列明确的待办，不要虚构；信息缺失的标注"待确认"。执行截图：
结果：
| 事项 | 负责人(DRI) | 截止时间 | 验收标准 | 优先级 |
|---|---|---|---|---|
| 输出智能券包技术方案初稿 | 阿杰 | 下周一 | 初稿完成，可进入技术方案评审 | P1 |
| 前端估时输出 | 小鹿 | 下周一 | 前端开发工作量估时完成 | P2 |
| 特征工程跑通 + 模型训练第一版 + 接口交付 | 星哥 | 下周五前 | 特征工程跑通、模型出第一版、可调用接口交付 | P1 |
| 组织技术方案评审会 | 老周 | 下周一 | 技术方案对齐完成 | P1 |
| 组织联调计划对齐会 | 老周 | 下周五 | 联调计划确认 | P2 |
| 输出 TiDB bulk load 写入方案并与 DBA 对齐 | 老钱 | 下周 | 方案文档输出，DBA 评审通过 | P1 |
| MQ 消费者改为线程池并发消费，batchSize 从 10 调到 50，复测延迟 | 阿杰 | 当天下午 | 消费延迟压到 5 秒以内 | P1 |
| 确认推送服务是否支持批量推送触发 | 阿杰 | 待确认 | 待确认 | P2 |
第三步：老板视角精简
把前面跑出的"纪要 + 行动项"换一个角色重写------变成"发给老板 / 丢群里"的精简版：开头 3 行结论、行动项保留表格、去掉内部讨论细节、输出可直接复制进飞书。
写入prompt：
markdown
把上面的纪要 + 行动项，改写成"发给老板/群里"的版本：
1. 开头 3 行给核心结论；2. 行动项保留为表格；
3. 去掉内部讨论细节；4. 输出可直接复制到飞书文档的格式。执行截图 ： 
结果（老板 / 群同步版）：
📌 今日三场会议核心结论
- 智能券包需求评审完成：MVP 定位"傻瓜式"智能发放（商家仅设预算+面额），走预计算名单优先 + 实时计算兜底策略，TiDB 存打分结果，预计 8 月底随商家后台 3.0 上线。
- 交易链路重构进展：分布式事务从 Seata 切换为 RocketMQ 事务消息方案，订单/支付域联调中，周四上午提测；iOS 审核因跳转微信被拒，今日重提。
- 智能券包发布方案对齐：明日上午 10 点灰度发布（10% 流量），三服务升级 + 新服务上线，回滚时间 < 1 分钟，监控告警规则已配置。
📋 行动项清单
| 优先级 | 事项 | 负责人 | 截止时间 | 验收标准 |
|---|---|---|---|---|
| P0 | 事务消息幂等处理 | 小陈 | 今日 | MQ 回查不重复执行本地事务 |
| P0 | 支付域增加 PAY_PENDING 中间状态 |
老何 | 今日 | 状态机流转正常 |
| P0 | 下单页地址选择后运费未重算 Bug 修复 | 阿紫 | 今日 | 选择地址后运费正确刷新 |
| P0 | iOS 端隐藏"联系客服"按钮并重新提审 | 雷子 | 今日下午 | 审核提交成功 |
| P0 | P1 Bug 验证（优惠券未包含运费险） | 小赵 | 今日上午 | Bug 验证通过 |
| P0 | 确保测试环境稳定、周四上午可发版 | 大军 | 周四前 | 环境正常、发版窗口可用 |
| P0 | MQ 消费优化效果确认 + 更新发布评审单 | 阿杰 | 今日下午 5 点 | 消费延迟 < 5 秒，发布单更新 |
| P0 | 提交正式发布评审单 | 阿杰 | 明日上午 | 评审单提交完成 |
| P0 | 配置 Grafana dashboard + 告警规则 | 小孙 | 明日上午 | dashboard 可用、告警生效 |
| P0 | 灰度期间盯业务指标，异常即时同步 | 敏姐、婷姐 | 灰度期间 | 业务指标无异常 |
| P1 | traceId 透传排查 | 小陈 | 今日 | order→pay 链路 traceId 一致 |
| P1 | 输出智能券包技术方案初稿 | 阿杰 | 下周一 | 可进入技术方案评审 |
| P1 | 特征工程 + 模型第一版 + 接口交付 | 星哥 | 下周五前 | 可调用接口交付 |
| P1 | 输出 TiDB bulk load 写入方案 | 老钱 | 下周 | DBA 评审通过 |
| P1 | MQ 消费者并发改造 + 延迟复测 | 阿杰 | 当天下午 | 延迟 < 5 秒 |
| P1 | 确认 Nacos 中 Sentinel 规则已生效 | 阿杰 | 会后 | 规则存在且推送成功 |
| P1 | 确认灰度期间是否通知业务方 | 敏姐 | 明日发布前 | 待确认 |
| P1 | 订单详情页 12 个 UI 还原问题收尾 | 阿紫 | 今日 | 设计验收通过 |
| P1 | 订单列表页 loading 闪一下修复 | 阿紫 | 今日 | 最小展示 300ms |
| P1 | 测试计划调整（iOS 回归挂起） | 小赵 | 今日 | 测试计划更新同步 |
| P2 | 前端估时输出 | 小鹿 | 下周一 | 前端工作量估时完成 |
| P2 | 组织技术方案评审会 | 老周 | 下周一 | 技术方案对齐 |
| P2 | 组织联调计划对齐会 | 老周 | 下周五 | 联调计划确认 |
| P2 | 订单状态标签渐变色调整 | 阿紫 | 今日下午 | 符合最新设计稿 |
| P2 | 输出 SkyWalking 接入文档 | 老钱 | 今日中午前 | 接入文档输出 |
| P2 | 确认订单状态 loading 交互方案 | 阿紫 | 待确认 | 以设计稿最新版为准 |
| P2 | 确认推送服务批量接口可行性 | 阿杰 | 待确认 | 待确认 |
第四步：负责人视角(可同步个人工作台和待办事项)
把第二步那张"行动项总表"，按"负责人(DRI)"拆成每个人专属的待办清单------@谁、要交什么、啥时候交、怎么算验收。这一步让"总表"变成"每个人手上的待办"，可以直接同步进 TA 的个人工作台（飞书任务 / 待办 / Notion / 备忘录）。
发群里，老板知道"进度到哪"；但落到执行，每个人只关心"我的事"。把总表按人切好，省掉每个人自己从总表里挑自己那几行的活------这正是"经验复用"的最后一下：一份输入，长出两种视图（对外群同步 + 对内个人待办），全靠 TRAE Work 的多轮对话接着上文要，不用重做。
写入prompt：
java
把上面的"行动项表"，按"负责人(DRI)"拆成每个人专属的待办清单：
1. 每个负责人单独一个区块，标题用「@xxx 的待办」；
2. 只列属于 TA 的事项，含「事项 / 截止 / 验收标准 / 优先级」；
3. 末尾给一行"本周关键节点"，按截止时间排序；
4. 格式可直接复制到飞书任务 / Notion / 备忘录（个人工作台）。执行截图 ： 
结果 （负责人各一份,两个例子，其他人的也都格式相似）：
@阿杰 的待办
| 优先级 | 事项 | 截止 | 验收标准 |
|---|---|---|---|
| P0 | MQ 消费优化改动效果确认 + 更新发布评审单 | 今日下午 5 点前 | 消费延迟 < 5 秒，发布单内容更新完成 |
| P0 | 提交正式发布评审单（变更内容、回滚方案、监控指标、MQ 配置变更、回滚补偿说明） | 明日上午 | 发布评审单提交完成 |
| P1 | 确认 Nacos 控制台中 Sentinel 降级规则已生效 | 会后 | Nacos 中存在对应规则且推送成功 |
| P1 | MQ 消费者改为线程池并发消费，batchSize 从 10 调到 50，复测延迟 | 当天下午 | 消费延迟压到 5 秒以内 |
| P1 | 输出智能券包技术方案初稿 | 下周一 | 初稿完成，可进入技术方案评审 |
| P2 | 确认推送服务是否支持批量推送触发 | 待确认 | 待确认 |
@小陈 的待办
| 优先级 | 事项 | 截止 | 验收标准 |
|---|---|---|---|
| P0 | 事务消息幂等处理（本地事务表加状态字段，MQ 回查不重复执行） | 今日 | 事务消息回查幂等，不重复执行本地事务 |
| P1 | traceId 透传排查（Sleuth 网关配置 / SkyWalking 接入） | 今日 | order-service → pay-service traceId 一致 |
...
📅 本周关键节点（按截止时间排序）
| 时间 | 节点 | 负责人 |
|---|---|---|
| 今日上午 | P1 Bug 验证（运费险） | 小赵 |
| 今日中午前 | SkyWalking 接入文档输出 | 老钱 |
| 今日下午 | iOS 重新提审 | 雷子 |
| 今日下午 | 订单状态标签渐变色调整 | 阿紫 |
| 今日下午 5 点前 | MQ 消费优化确认 + 更新发布单 | 阿杰 |
| ... |
这步输出，就是把"群同步版"再切一刀：对外给老板，对内给每个人。它也是"同步个人工作台"的最小单元------把每位负责人的待办往 TA 的飞书任务 / Notion 一丢，个人工作台就同步了。到这一步，四类功能全部用上：①结构化 ②对齐 ③换角色重写（群 / 负责人两版）④多轮对话把四步串起来。
同步飞书后阿杰的日程显示为：
翻车了怎么救：新手最常踩的两个坑（接着上文发一条纠偏指令）
上面你看到的纪要，是纠正后的版本。这类任务第一次裸跑，模型最容易犯两个错，都属于"把不确定的写死"：
- 坑一：把"待定"写成"结论"。 比如把会上一句"Spark 资源我排一下"，直接落成"采用 Spark 资源方案"------好像已经定了。
- 坑二：臆测未确认的技术细节。 比如会上一句"服务挂了得兜底"，模型自己补成"模型自动兜底"------但真实方案是"降级到规则引擎"。
这两个坑要直接发群，算法和后端能当场吵起来。救法不用推倒重来，追加一条指令（这里又用到功能 ④ 多轮对话，接着上文改）：
arduino
上面的纪要里，把"尚未确认/讨论中"的内容从【会议结论】移到【待决策事项】，
并核对"降级策略"：明确写清"服务不可用时降级到规则引擎，而非模型兜底"。不要臆测未确认信息。AI 立刻把"待定"的归位到【待决策事项】、把"降级到规则引擎"写清楚。把它当实习生带：第一次不对，说清哪里不对，让它改，两三轮就好。这一步的"纠偏 + 多轮"，也是评委最看重的「实操过程完整度」------不是展示一次完美，而是展示你怎么把不完美改对。
复用：一套模板，三类会议都能套（全文重点）
把四条指令存成你的「会议纪要模板」，换任何会议都能用------流程不变，只改指令①的侧重。这正好对应评委最看重的「经验复用性」。
三类会议，只改指令①的侧重点（下面这三类，就是你之前假设、我验证过合理的真实会议场景，直接可用）：
| 会议类型 | 时长/人数 | 指令① 侧重 |
|---|---|---|
| 需求评审 | 约 60min / 8 人 | 突出「决策点 / 分歧 / 风险」，结论标提出人；重点抓"吵得最凶的那段" |
| 每日站会 | 约 30min / 8 人 | 突出「昨日完成 / 今日计划 / 阻塞」，结论按人列，阻塞单独标红 |
| 运维发布评审 | 约 20min / 5 人 | 突出「变更范围 / 灰度策略 / 回滚预案」，结论加"监控与告警指标" |
三类会议各一段「指令① 会帮你抓出的结构」示意（不是完整输出，只为看清侧重差异；你跑时换自己的真实转写）：
需求评审（指令① 示意） 决策点：圈人目标定为"到店核销"（星哥/菲菲）；风险：实时特征缺、依赖 T+1（星哥）；分歧：预计算 vs 实时 的混合比例（老周/老钱）。
每日站会（指令① 示意） 昨日完成：圈人接口联调通过（星哥）；今日计划：TiDB 压测（老钱）；🔴 阻塞：Spark 资源未批，预计算排期延后（阿杰）。
运维发布评审（指令① 示意） 变更范围：券包智能发放 V1.1；灰度：5% → 观察 30min → 50%；回滚：一键回滚 < 2min；监控：发放成功率 / 推理 P99<1s / TiDB 写入 QPS。
换数据不换流程。 这三类之外，周会、客户会、复盘、1v1 同样通用。四条主指令 + 进阶变体的完整可复制版，见文末「附：可直接复制的指令包」。
五、时间节约
平时整理这些会议纪要，总是1个小时起步，本次利用trae work整理会议纪要只需要十几分钟，时间节约了大概4/5。
- 手动时，时间耗在"搬运"------把话一句句听、归类、对齐、改格式；
- 用这套流程时 ，时间耗在"判断"------粘贴、发指令、然后你来做那个唯一不能外包的动作：审。人名对不对、日期准不准、结论有没有越权替别人拍板。
六、沉淀成skill
跑顺之后，四步其实已经固定了------变来变去的只有"会议转写"和"指令①的侧重"。把它沉淀成一个可复用的会议纪要 skill，下次开会直接调用，不用重新想指令。
做法分两种，取决于你用的 TRAE Work 版本：
- 支持自定义 skill / prompt 模板 ：把下面这个模板存成一个 skill，定义一个
输入槽位（粘贴转写文本），运行时自动注入三步指令。 - 不支持自定义 skill：存成备忘录 / 笔记模板，每次新建会话时粘贴即可，效果一样。
一个可直接用的 skill 模板（Markdown 即可）：
perl
会议纪要 skill（自定义模板）
帮我把以上会议纪要的生成过程总结后创建一个kill，命名为meeting-record-skill，下次用户直接输入会议录音转成的文字，你就能直接生成会议纪要: 以下是我的总结的过程你参考一下：
步骤
1. 指令①（结构化纪要）： 根据下面这段会议转写，整理一份正式会议纪要。 要求：1. 分【会议结论 / 关键讨论 / 待决策事项】三块； 2. 每条结论标注提出人；3. 关键数据原样保留；4. Markdown 排版，语言客观简洁。
2. 指令②（行动项表）： 从上面纪要抽取"行动项清单"，用表格呈现： 列 = 事项 / 负责人(DRI) / 截止时间 / 验收标准 / 优先级(P0-P2)。 只列明确待办，不虚构；信息缺失标注"待确认"。
3. 指令③（群同步版）： 把纪要 + 行动项改写成"发给老板/群里"的版本： 开头 3 行给核心结论；行动项保留表格；去内部细节；可直接复制进飞书。
4. 指令④（负责人视角待办）： 把行动项表按"负责人(DRI)"拆成每人专属待办清单： 每负责人一个「@xxx 的待办」区块，列事项/截止/验收/优先级；末尾"本周关键节点"按截止排序； 格式可直接复制到飞书任务/Notion/备忘录（个人工作台）。
纠偏（可选，第一次跑偏时追加） 把"尚未确认/讨论中"的内容从【会议结论】移到【待决策事项】， 核对"降级策略"明确写清"服务不可用时降级到规则引擎，而非模型兜底"。沉淀之后，你的"会议纪要"就从"每次现想指令"变成了"一次配置、长期复用"。不同会议类型，只需改指令①的侧重（见第四节复用表），其余不动。
当然你也可以直接用我的，我把生成的skill放在了这个地址，需要自取：github.com/beverlyLee/...
七、生成自动化工作流
再往前一步：把上面四步串成自动化工作流，让"录音转写 → 纪要 → 行动项 → 群同步版 → 每人待办"一气呵成，最后把"群同步版"和"每人待办"分别落到个人工作台：群同步版进「今日纪要」页，每人待办进各负责人的日程待办（飞书任务 / 笔记 / Notion）。
一个可落地的自动化骨架：
| 步骤 | 动作 | 产出 | 落点（个人工作台） |
|---|---|---|---|
| 触发 | 会议结束，转写文本就位（飞书妙记 / 本地文件） | 纯文本 | 输入槽 |
| 自动跑 ① | 发送指令① | 结构化纪要 | 个人工作台「今日纪要」 |
| 自动跑 ② | 接着发指令②（多轮对话天然支持连续发） | 行动项表 | 同上页「行动项」区块 |
| 自动跑 ③ | 接着发指令③ | 群同步版 | 同上页「同步版」区块 |
| 自动跑 ④ | 接着发指令④（按负责人拆待办） | 每人专属待办 | 各负责人工作台「我的待办」 |
| 同步 | 把③④输出写入个人工作台对应页面 | 群同步版 + 每人待办 | 飞书云文档/任务、笔记、Notion |
落地说明（诚实边界）：完整的"自动触发 + 写入第三方工作台"取决于你本地 TRAE Work 与飞书 / 笔记是否开放了 API 或自动化编排能力。如果你那边暂时不支持自动触发，先把"手动四步"跑通（本文第四节），再把③的群同步版 + ④的每人待办手动复制进个人工作台------这已经省掉了最机械的搬运；等接口开放，再按上面骨架接成全自动。
八、边界
不是所有会都能甩给 AI。两类我建议别用：
- 涉密会：转写文本进的是你自己的 TRAE 会话，不公开，但发群前自己脱敏。涉及商业机密、未公开财务的，谨慎。
- 要法律效力的纪要：AI 出的初稿不能替代签字确认的正式记录。它帮你提速，不替你担责。
核心原则就一句：AI 出初稿，人做终审。你始终是那个"审纪要的人"。
如果你也受够会后整理，从下一场会开始：录音转文字，丢给 TRAE Work，贴这三条指令或者使用现成的skill，十分钟拿到以前四十分钟才弄完的东西。
收藏这份模板------下次直接复制，不用重新想。后续持续分享普通人用 AI 提效的真实实战。如果你有所收获，请给我三连哦，哪怕免费的赞也行啊，你的支持是作者持续更新的动力。
本文参与「#TRAE Work 实战帮」征文，聚焦真实职场痛点与落地经验，欢迎交流你的用法 👇