**会议日期**：2025-12-02 **参会人员**：连云波、闫旭隆、焦老师等 --- ## 一、会议纪要工具与Gemini多模态能力讨论 **画面内容：** 01:20 画面切换显示 Windows 桌面，正在打开一份 Excel 表格，标题显示"P0项目进展情况"。01:23 画面切换至微信电脑版界面。 **发言者（连云波）：** 关于这个会议纪要，基本上找到一条路径了。 **画面内容：** 01:36 微信界面点击切换到与"江达"的聊天窗口，显示发送过一个名为"20251201-问题摘录...md"的文件。 **画面内容：** 02:07 微信界面点击切换到与"连云波"的聊天窗口。02:11 打开一张聊天记录截图。02:14 滚动浏览微信聊天记录，显示关于 Gemini 的讨论内容。 **画面内容：** 02:32 切换至 Google Chrome 浏览器，显示 Gemini 界面，标题为"信息系统建设方案书工作指导"。 **发言者（连云波）：** 我一直认为纯粹的语音识别效率很低，因为好多背景信息都是没有的。文字它不知道，视频它也不知道，我们的切换它也不知道。所以从这个角度来说，多模态以后一定是做文字识别最重要的一个路径。 上周那个Gemini出来之后，我觉得非常好。我拿那个视频去测试了一下，大概半小时的会议我上传上去，让它原文转写所有视频里的文字稿。 **画面内容：** 02:58 浏览器中点击右侧历史记录，打开名为"信息系统建设方案书工作指导"的对话记录。页面显示上传了一个名为"2025112618...的继续会议-视频.mp4"的文件。 **画面内容：** 03:01 页面向下滚动，显示 Gemini 输出的"时间轴：00:00-03:40"及其对应的文字描述内容。 **发言者（连云波）：** 基本上可以看到它能识别画面内容，比如"Lian正在操作电脑，查找文件"，然后画面静止黑屏连接什么的。我特意对了一下，基本上没有错误的单字了。更重要的是，这个模型最厉害的是它本身就是多模态的，你可以用prompt来调整需要提取的内容。 所以有可能最厉害的做法是，直接给它一个会议模版，把视频给它，它就有可能直接生成，一步到位了。Gemini里面也有那种Gem，你可以自定义，把会议纪要模版全部放进去，然后上传视频，根据模版自动生成。 **画面内容：** 05:57 鼠标点击"Writing editor"图标。06:02 进入 Writing editor 界面。 **画面内容：** 06:14 点击输入框左侧的"+"号，显示上传文件选项。 **发言者（连云波）：** 所以这是我找到的目前最有效的路径。Gemini大家肯定要用了，因为它的多模态能力是最强的，而且它上下文是最长的。 **发言者（连云波）：** Gemini目前能力是最全面的。不是说最聪明，最聪明我觉得GPT 5.1还是聪明。但最全面的是Gemini，而且它的多模态尤其是视觉能力是超强的。我用它来做PPT的效果非常好。 所以前端用Gemini，中间逻辑整个代码的构造部分用Cloud，整个项目的修复、查找问题或测试可以用GPT的Codex。但主力我现在用下来还是Cloud Code，因为它的工具调用能力目前无人能及，工具调用和工具理解能力是没有人能赶过它的。所以我们做Agent的话，对于工具的理解肯定是第一位的。 --- ## 二、会议纪要Skill架构讨论 **画面内容：** 11:15 打开文件夹 `AA_Work` -> `skills合集` -> `.claude` -> `skills` -> `meeting-minutes-generator-v1`。11:32 打开文件夹内的 `Phase2执行流程图.drawio` 文件。 **画面内容：** 11:42 `draw.io` 软件正在加载。11:48 打开了流程图，标题为"工程类会议纪要 Skill 执行流程图"。 **发言者（闫旭隆）：** 会议纪要Skill主要改了一下整体的架构。之前是用索引搜索，我改成了全量读取，确实可以。这个是每一个字段的来源映射逻辑图。包括上周提到的负责人要改为原负责人，就是第一个字段代表这个项目原本交给谁了。截止时间我也改为原截止时间，就是上周会议纪要定下的这个任务的截止时间。 **发言者（连云波）：** 你这个很重要。我自己在做Skill过程当中，总觉得Claude自己的逻辑不够清晰，容易瞎改，改完之后改前忘后，改后忘前。目前我认为它最缺的就是逻辑的一致和前后的连贯性。 **发言者（闫旭隆）：** 进展情况应该以会议转写为优先，这个也改进去了。下周逻辑我也顺了一下，也是会议转写优先。测下来发现最大的问题还是文字的语义识别，比如交给谁了这种信息。 **发言者（连云波）：** 目前会议纪要里面最头疼的事情就是文字转写的准确性和上下文的约束能力。转写能力如果不清晰，又没有很好的约束，它很难处理。因为我们是在非常清晰的上下文背景下来开会的，它是不知道的。 所以后面到底用什么工具，比如继续用Claude来处理还是用Gemini。有可能直接调Gemini的API，在Cloud里面调Gemini的API来做。 **发言者（闫旭隆）：** 这样自动化程度更高。 **发言者（连云波）：** API现在好像还行，转写成文字也没多少。半小时6000多字，一分钟200多字。5个小时也才3万字，差不多2万多token。对于它100万token来说太小了。 --- ## 三、会议目的与工作安排 **发言者（连云波）：** 整个会议最重要的是下周的工作安排。以后要知道，开会的目的首要是为了解决问题，其次才是分享知识。分享知识不一定需要在周会讨论，可以直接在群里分享。只有会议纪要是需要大家共同坐在一起的。 尤其是未来人多了，项目分散以后更是了。每个人都做一部分，完全需要一个大项目协调，有人负责前有人负责后，就需要信息沟通。 所以整个会议里面最核心的目的是为了得到下周工作安排的合理安排。一切逻辑都是往这儿聚的。能把这个写清楚，基本上大部分问题不大了。因为前面的信息得提取正确，汇报的信息得提取正确，逻辑理顺清楚，才能得出下周工作纪要。 --- ## 四、Skill并行架构与子Agent设计 **发言者（连云波）：** 这些目标是一次性的提取完成，还是分次提取？ **发言者（闫旭隆）：** 我是并行用搜索Agent。并行搜索Agent去搜，然后把搜到的信息都反馈给主窗口，主窗口负责读所有的信息然后写。 **画面内容：** 18:03 闫旭隆在流程图中点击查看"三、会议总结..."部分。 **发言者（连云波）：** 这个方法比较清晰。但第一，我觉得它资源浪费太大了，每一个过程全部全量处理一遍。第二，会造成逻辑的割裂。因为你要在主窗口主上下文窗口里面再去做整合。 **发言者（闫旭隆）：** P0任务识别是根据语义来识别。比如领导说紧急、优先，它就会识别为P0。 **发言者（连云波）：** 这个是最难的。作为判断，如果它能做得到，比你们都强。因为人对于整个项目里面的轻重缓急判的没那么清晰，而且你们都会忘。会议当中内容早就忘掉了。 所以它如果能提取出来，你可以让它给个建议。让它先给出建议，不要上来就生成P0。建议排序是什么，然后人再给它一个反馈。每个人都会得出下周工作的P0到P2的。最好是让它发给你们确认一下。这样把确认过程所有的材料都保留下来，作为后续的强化学习或微调。 **画面内容：** 20:49 滚动查看 `draw.io` 文件中的"Phase 2: 工程类会议纪要生成 - 并行执行流程图"。 **发言者（连云波）：** 现在已经有个新的AI drawIO开源项目，可以在里面直接用AI修改。它要Gemini的API，免费的API调用次数肯定够用。 **发言者（闫旭隆）：** Phase 1是输入数据的加载，都加载到主窗口。会议信息由主窗口直接生成，因为主窗口已经有这些了，足够生成。 **发言者（连云波）：** P0任务列表是周报P0任务列表还是上周纪要的P0任务？要写清楚。 **发言者（闫旭隆）：** 这两块去重之后形成最终的P0任务列表，传递给子Agent时会传递这个信息，让子Agent知道已确认的P0任务有哪些，然后去搜索。这也是给子Agent的一个上下文。 **发言者（闫旭隆）：** 并行提取会根据会议纪要模版的字段判断哪些字段需要涉及到。主要是涉及到需要去文字转写里面去搜索的字段。每次去搜的时候会调用通用Agent，里面预设了很多种任务类型，每一种任务类型返回做了Json格式的约束。 **发言者（连云波）：** 你是到里面去搜索是吗？ **发言者（闫旭隆）：** 不是搜索，是全量加载，然后给它任务，自己去找，自己执行。 **发言者（连云波）：** 叫搜索是很容易出问题的。人的语言里面有大量的跳脱，会议当中很多语言没那么清晰，直接搜索是搜索不出来的。但通过上下文Attention的处理，它能够理解并提取出来。如果用RAG你是绝对RAG不出来的。 **发言者（连云波）：** 你把这几个问题同时合到一个问题传给它，几个Agent并发的时候，把这几个全部合进到一个里面让它执行。因为都是一次性全量加载的。 **发言者（闫旭隆）：** 行肯定是行。我现在是靠主窗口来整合。可能每一个Agent只执行特定任务会找得更多一点，冗余重叠部分更多，主窗口可能也更好给它整合出来。 **发言者（连云波）：** 主窗口里面上下文是所有的都加载的？ **发言者（闫旭隆）：** 主窗口包括输入数据都给了，除了转写文本没给。 **发言者（连云波）：** 这种方式可能比较精准，但逻辑会割裂。每个Agent提取出来的东西直接给到主Agent，主Agent没法建立起每个之间的关联性。 **发言者（闫旭隆）：** 关联性我给它写了映射规则，体现在Skill.md里。主窗口接收到每一种类型的返回后，会根据这每一种类型的返回按照我给它的方法论去映射，然后一起合并。 --- ## 五、子Agent与主窗口上下文优化建议 **画面内容：** 屏幕显示 ProcessOn 或类似的在线流程图工具，标题为"Phase 2 并行执行流程图"，图表中包含多个 Agent 节点（如 User Proxy Agent、Agent C、Agent D1/Dn 等）。 **发言者（连云波）：** 你一旦把上下文剥离之后，最全量的上下文剥离之后，比如转写文本剥离之后，它的效果一定不如给它一个主窗口让它自己去处理。 我举个例子，我给了它一篇文章让它生成PPT，两种方法：一个是读完文章给我一个提示词，然后用提示词去生成图；另一个是直接让它在主窗口生成图。我看了这两个信息量差距非常大。它真的是把上下文全部用在图形生成过程中，而且逻辑关系更清楚更明确。你现在相当于把提示词生成的结果给到主上下文，会丢失好多信息。 **画面内容：** 鼠标在流程图左侧的"Phase 1 基础信息提取"区域画圈示意。 **发言者（连云波）：** 我建议你把转写文本Clean一次，把那些脏的、重复的全部做一遍加工。保证信息全面的同时，内容是紧凑的，没有太多重复。然后把这个Clean后的直接加载给主上下文。 **画面内容：** 鼠标指向流程图中间的"主窗口（全量Context，全量Prompt）"。 **发言者（闫旭隆）：** 那子Agent的上下文也是Clean后的？ **发言者（连云波）：** 也是Clean后的。然后把子Agent提取出来的东西，其实某种程度上就是一个大的Prompt，给到主上下文，让主上下文结合Clean的文档加上这个大的长的Prompt，因为Prompt已经运算过一次了。 **发言者（闫旭隆）：** 加强了一次。 **发言者（连云波）：** 我觉得这个可能最准，而且信息量损失最小。不要一次性上来就处理，不然每个人都喂垃圾进去。 另外还可以尝试一个更大胆的：把映射规则写在主上下文，让它主上下文一次性处理，不用子Agent。尤其是Gemini的情况下，你给Gemini调用一次试试看。反正有300美金的API免费额度，不用都浪费了。 差不多3万字，Clean之后差不多剩2万字左右。这2万字一定是包含了大量信息的。还有之前的上下文，足够了。重复处理开销太大，每个人都要精加工一遍有点浪费。 --- ## 六、会议纪要Skill测试结果对比 **画面内容：** 屏幕切换，打开一个文件夹窗口，然后打开一个 Markdown 编辑/预览工具（VS Code 或类似编辑器）。 **发言者（闫旭隆）：** 这个是用上周的资源生成的比较。这个是大家手动订正过的。 **画面内容：** 屏幕显示左右分栏的文档对比。标题为"工程类会议纪要（2025-11-25）"。左侧内容较少，右侧内容较多。 **发言者（连云波）：** 右边是你生成的，左边是手动的？ **发言者（闫旭隆）：** 右边是我生成的，左边是手动的。 **发言者（连云波）：** 那为什么请假人员刘艳红一直在？ **发言者（闫旭隆）：** 因为应该是上上周那个里面有。 **画面内容：** 文档继续向下滚动，对比"二、工作内容"和"1. 重点项目进展情况汇总"。 **发言者（连云波）：** 发现存在逻辑映射不大。它比较概括，你这个非常具体。为什么它那么概括？这可能就是存在的差异了。我们想要的是概括性的呢，还是具体的？我觉得具体性更好，容易执行。 **画面内容：** 文档向下滚动，浏览表格内容，包括"项目名称"、"负责人"、"截止时间"、"项目进展情况"等列。 **发言者（连云波）：** 领导建议和领导指示这块，可能是大家共同商量的结果。领导建议那写成解决方案。 **画面内容：** 文档滚动至"2. 重点项目问题及解决方案"。 **发言者（连云波）：** 会议纪要Skill信息提取准确性问题。这里有一个没提取出来，就是要找加力去商量。你要看它为什么没有提取出来。 **画面内容：** 切换浏览器窗口，打开 Bing 搜索页面，然后点击收藏夹中的某个链接，进入 HackMD 页面。 **画面内容：** HackMD 页面加载中，随后显示"工程类会议纪要（2025-11-25）"。 **画面内容：** 切换回 HackMD 页面，鼠标选中"项目组导致的事情主要由主理人承担后果不再推诿"这一行。 **画面内容：** 切换回 VS Code 的文档对比界面。 **发言者（连云波）：** 左边归纳的好像更好。两个都对。需求澄清Skill完成1.0版本测试，我觉得左边的更好，更细一点。 **画面内容：** 文档滚动至"问题 5：数字人 PPT 需求文档存在产出问题"。 **发言者（闫旭隆）：** 更好肯定是人改的更好。但是比较接近，主要的要点是有的。以前没有的，上一版本没有的也有了。 **发言者（连云波）：** Opus做专家评审，我只建议做多轮博弈。 **画面内容：** 文档继续向下滚动，查看"问题 6：日报驱动系统架构设计不系统"。 **发言者（连云波）：** 日报驱动系统这块全部丢掉了？ **发言者（闫旭隆）：** 可能是我写提示词的时候，让它以上面这些项目为叙述汇总的逻辑，新的就没有了。 **画面内容：** 文档滚动至"4. 组内成员工作进展"。 --- ## 七、天眼查需求与技术实现讨论 **发言者（连云波）：** 天眼查需求明确，现在的情况是已经跟小鹏把这个接好了。具体的技术实现，让江老师出一个技术方案和时间方案，可以帮助小鹏自动更新他那个客户库。 **发言者（闫旭隆）：** 目前应该是江老师正在做。 **画面内容：** 文档滚动至"问题 4：Skill 测试效率低下问题"。 --- ## 八、全量处理与信息遗漏问题 **发言者（连云波）：** 你看，未记报告。它比你们记忆力好。因为太长了之后你们确实没有人有耐心把它读完。 我建议你写一个精简版，就是一个很易读的文本。我读那个原文转写的时候特别耗脑子，因为逻辑老是中断，动不动就错，思路完全被打断，根本没办法推进。 Gemini最大的好处是它几乎每个都是我们说话时候的原封不动给你转述。哪怕有一些语气词，错误得少，能读得下去。稍微改写就能成为大家能够很快能够读的东西。 **发言者（连云波）：** 我下面给你们建议是：生成一个每个人一份的会议纪要。全量生成完，每个人给它一份跟你相关的发言。这样有助于当你回忆不清纪要的时候，可以回到那个版本去看一下。全量的文档放在上面，标注好每个人和每个时间段，会议纪要里面一点回去就能看到原文。GPT就是这么干的，每一条都有对应的时间点。 **发言者（连云波）：** 你可以用全量的主上下文窗口全量做一次，我觉得你还能找到漏洞。因为你这个其实肯定信息有遗漏的。 --- ## 九、会议纪要实时确认建议 **发言者（连云波）：** 我们会议有一个什么最好的状态？就是会议刚开完没多久或者在开的过程中，你把前面的全量整理了，然后会上直接做一个确认。这样会议成果是最清晰的，时间上肯定来得及。 这么复杂，完全靠它的判断非常困难，尤其是判断P0、P1、P2这些事。这个还是靠人。 另一个方案是：我每次会议上把会议纪要直接确认掉，人写或者我自己去在会上直接确认。我们认为这个是P0还是P1，给它一个确认。所以会上就要辅助它，让它自己判断太难了。 --- ## 十、会议纪要Skill测试结果详细对比 **画面内容：** 屏幕显示 Typora 软件界面，打开的文件名为"工程类会议纪要 2025-11-25"，右侧为 Markdown 预览模式。 **画面内容：** 鼠标滚动至文档"4. 组内成员工作进展"部分，对比"已完成"和"进行中"的任务描述。 **发言者（连云波）：** 负责人和那个投标进行中的不一样了。这个是你改过吗？ **发言者（闫旭隆）：** 这个是我用的更加准确的一个名称。 **画面内容：** 鼠标选中"进行中"列表下的"数智人需求文档及技术实现方式"。 **画面内容：** 鼠标指向"运营商信息挖掘系统需求总确认沟通"。 **发言者（连云波）：** 明显不具体。 **画面内容：** 屏幕切换至浏览器窗口，显示 HackMD 页面，标题为"我的工作空间 / 工程类会议纪要"。 **画面内容：** 在 HackMD 页面中查看历史记录或相关条目，鼠标悬停在"江平达"名字附近。 **画面内容：** 屏幕切回 Typora 文档，查看"进行中"的任务列表。 **画面内容：** 再次切换回 HackMD 浏览器页面，查看表格内容。 **画面内容：** 并在 Typora（左侧）和 HackMD（右侧）之间进行内容比对。 **画面内容：** 查看 Typora 文档下方的"下周工作任务"列表，关注 P0 和 P1 的任务分级。 **发言者（连云波）：** 搜索Skill功能调研，那个大纲报告整理其实也不对的，但是没有写那个细。 **画面内容：** 在 HackMD 页面向上滚动，查看"上周完成"部分。 **发言者（连云波）：** 那你分块搜索一定会丢好多东西，所以全文一定是最有效的。而且你又做了一次加工之后再给提示词，我认为也会丢很多。 所以我建议你还是尝试做一次全量的主上下文窗口搜索。因为你并行都已经处理那么多次了，不在乎主窗口输入输出这一次了。 **发言者（闫旭隆）：** 主窗口也没耗多少token。 **发言者（连云波）：** 主窗口耗的还没几个并行多呢。 --- ## 十一、天眼查自动更新需求确认 **发言者（闫旭隆）：** 就是那个天眼查。上次开会的时候联通说让你后续可以做一个帮助小童自动更新她那个天眼查客户数据库的技术实现方式。 **发言者（连云波）：** 后来是说她不需要嘛，她现在也不需要每天更新那么多次了。你再确认一下，她这个自动更新要不要。 **发言者（闫旭隆）：** 后续小童她没有跟我反馈过。 **发言者（连云波）：** 那你再确认一下。 **画面内容：** 打开 Windows 图片查看器，显示一张流程图，标题包含"工程类会议纪要 SKILL 执行流程图"。 **画面内容：** 关闭图片查看器，回到 Typora 界面。 **画面内容：** 在 Typora 中对比左右两侧的文本列表。 **画面内容：** 滚动查看文档中的"Cosmos 文档翻译"相关条目。 **画面内容：** 查看"进行中"的任务状态。 **发言者（连云波）：** 他这个是按照周报写的判断他完成了。其实根据会议纪要他没完成。他的逻辑判断上有点矛盾。 **画面内容：** 对比文档上下的"日报"相关条目。 **发言者（连云波）：** 日报驱动，他没有总结出来日报驱动，这一版里面上面没有日报驱动这个东西。 **发言者（闫旭隆）：** 下面有，可能是日报里。 **发言者（连云波）：** 所以这个逻辑可能还是不全的。 **画面内容：** 查看关于"公众号"的任务条目。 **画面内容：** 滚动至文档下方的"P1 搜索 Skill 架构调研及优化设计"。 **发言者（连云波）：** 去调Skill优化，当时是让他做的。您当时让我发给江老师了。可能直接为P0了，但是变成他们的P0了。你想这逻辑多复杂。 **画面内容：** 鼠标指向 P0 任务列表。 **发言者（连云波）：** 这里面逻辑肯定是有冲突。左边提取出来了测试推动，但是放到了P1，他是放到了P0。 **画面内容：** 对比左右两侧关于"测试"任务的优先级。 **发言者（连云波）：** 下周任务完成批量删除功能，当时是给了这个要求，但后来不需要了。先保留吧，大概理解他的逻辑。 --- ## 十二、会议纪要Skill改进总结与工作安排 **发言者（连云波）：** 整体的处理方案大概总结一下：第一，整个的文字转写换成Gemini，这个我们就拿这个试试。第二，做了那个之后，让Gemini直接生成全量版的，但不是逐字转写的，就是把核心主要的、语气连贯的、没有错误的文字稿把它拿出来，这个作为以后所有的输入。第三，在那个基础上，做一次全量的主上下文窗口处理。把Skill全部写到主Agent里面去就完了。 **发言者（闫旭隆）：** 这样等于把Subagent里面的所有逻辑映射变成一个Skill文件，放到让主Agent去读这个Skill就完了。 **发言者（连云波）：** 这样试一次，我觉得效果不一定会差。然后再拿我们这次生成的好的文字稿，再做一次两边的对比。这两个对比完了，差不多就能够确定是主上下文来处理全量的，还是要用Subagent来处理。 --- ## 十三、上下文管理与Agent执行时限思考 **发言者（连云波）：** 现在我们有个执念，我对你们上下文要求太高。之后每个人把主窗口，我都觉得得干干净净的。这是个执念。不一定准确。但凡能够在主上下文窗口里处理好的，就全部放到主上下文窗口，因为我们不是一个长连续工作的上下文。 有个人前两天做了一个非常有意思的，就是强制每个Subagent只能工作十五分钟。超过十五分钟的算全部中断，然后把你的工作产出扔给下一个Agent。不允许超过十五分钟上下文。跑上下文人就乱了。我们现在人能连续工作八个小时，我们的上下文系统基本还是连贯的，甚至还可以拖到第二天。它不行。 --- ## 十四、AI辅助与人工介入的关键节点 **发言者（连云波）：** 总结出现问题的目的是为了看用什么样的解决方案，是让它自己修改靠Prompt能修改，还是靠人来帮助它。我们一定要记住，它现在想完全脱离人是不可能的。但是人在什么地方给到最关键的帮助给它最有效，是我们要思考的。 比如在会上强调一下P0、P1这件事情，给它帮助就很大。为什么？它这个逻辑是真的很难分析的。它不知道你们每个人的年龄、级别、工作时间长短，这些都作为我们的潜意识的上下文。工作时间长分配的任务和工作时间短分配的任务不一样，工作优先排级也不一样。 这些潜上下文它是没有的，我们也没有办法给它，太多了。所以也可以尝试着慢慢去给它，把这些潜在上下文变成显性上下文把它显性化出来。但是这个也不见得就都对，这只能进步。 --- ## 十五、需求Skill多专家评审流程讨论 **画面内容：** 屏幕显示文档 `requirement_final.md`，界面为 Typora。当前展示"6.3 Agent间协作关系"流程图，包含主协调Agent、检查Agent、分析Agent、知识图谱Agent及报告生成Agent的指向关系。 **发言者（闫旭隆）：** 它给了四个选项，就是这四个都有。 **发言者（连云波）：** 这个主协调Agent是我提出来的。分阶段交付，这是他问了一下。 **画面内容：** 屏幕向下滚动，显示"7. 分阶段交付计划"及"7.1 阶段1：MVP版本"的内容。 **发言者（连云波）：** 那主Agent分析完之后给到它，然后它反馈完更新完之后反馈给它。这里面可能都需要主Agent的东西。分析Agent直接改成主Agent。对，都有可能。他要不要去更新知识图谱，谁来判断？这是一个很重要的流程。 **发言者（闫旭隆）：** 他做个分析就更新了。 **发言者（连云波）：** 所以我觉得主Agent它其实在每一个子Agent之后都要做个判断的，都要做下一步动作的判断。分析Agent可能只是涵盖在主Agent里面。所以说这个Agent流程还得好好思考。 --- ## 十六、知识图谱属性设计讨论 **画面内容：** 屏幕继续向下滚动，显示"7.2 阶段2：完整版本"及"7.3 阶段划分说明"。 **发言者（闫旭隆）：** 这个知识图谱类型，他给我出了四个，我都选了。 **发言者（连云波）：** 这个你得想想，这个知识图谱你得想想。他其实是属性。我觉得属性特别重要。 **发言者（闫旭隆）：** 实体关系，他只跟属性给。 **发言者（连云波）：** 就是属性表。我现在觉得那个属性特别重要。 --- ## 十七、多专家博弈评审机制分析 **画面内容：** 退出视频播放，打开 Windows 文件资源管理器，进入 `temp` 文件夹。选中 `evaluate_dev.json` 并在 VS Code 中打开。 **发言者（连云波）：** 这是开发专家提出来的。目标内容就是开发专家这条意见原本是什么，然后他的comment是怎么不同意。我给他的一个总体指导是要根据不能背离用户的原始需求，就是我给他的唯一的做方法论指导。 **发言者（闫旭隆）：** My comment是他对这个target content的评价。 **发言者（连云波）：** 所以这可能就是要评估，必须判断一下它有这个过程和没这个过程到底带来了怎样的一个评分质量的能力。所以要把那个所有的干脆直接，你下一次可以把它那个评估意见和最后的相应的那个打成一篇文档，把它整合的不要json文件了。把所有的这些东西整合成一问一答。这样你就知道它这个发生了什么。 **发言者（闫旭隆）：** 专家之间发生了什么。 **发言者（连云波）：** 你就看他这个水平够不够。如果评估的水平不够就不需要了。因为我们是没看到响应的，我只看到他提问了。看他提问和响应的水平到底对应不对应得了。如果对应不起来，那就没有必要增加这个。 多专家博弈这个，我个人理解将来是一定有效果的，但是现在的prompt可能没写好。这是基于专家经验的。好了，这里面可能要最后要几个，就是你每个领域的专家自己把自己找人去把这个prompt给写了。 定义这个Agent实际上挺难的。Agent里面最重要的，你看那Agent说不好听就还是MD文件。你这个MD文件写的好坏其实就决定了他的这个能力的边界了。 **优化建议：** 在第一版需求文档生成的时候可以尝试用AI来模拟专家回答访谈问题。如果有一个特别牛的、比我们经验丰富的人回答得肯定比我们好。甚至可能比我们还全面。你完全可以模拟一个专家Agent来回答它，让整个流程自动化下来。 --- ## 十八、数字人PPT需求文档评审 **画面内容：** 打开浏览器窗口，显示标题为"专家数字人讲解PPT视频需求文档"的文件。 **发言者（连云波）：** 共享一下，讲一下。 **发言者（正浩）：** 数字人那个就是根据上周连总的建议，把有用的需求保留，有些不提到、默认能做的功能大概进行了删减，然后生成的一个需求文档。首先就是那个项目背景和核心目标，主要就是下面基本都是进行了缩减。 **画面内容：** 屏幕向下滚动，展示"项目分阶段规划"部分，光标停留在"第一阶段：PPT+数字人讲解"处。 **发言者（正浩）：** 分阶段还是上周一样，第一阶段就是基础功能，第二阶段就是高级点的功能，比如高亮这些东西。 **发言者（连云波）：** 上面那个分阶段，基础功能是什么，和后面的规划说明在后面有还是没了？ **发言者（正浩）：** 第一阶段我有的，但是第二阶段这一篇文档里面没有。 **发言者（连云波）：** 我建议你都写。 --- ## 十九、数字人视频时长需求讨论 **画面内容：** 屏幕滚动到"2.2 时长分配"部分。 **发言者（连云波）：** 三到五分钟是对的吗？这个是富友他们提出来的还是张媛提出来的？ **发言者（正浩）：** 这个是跟贤林老师那边对了一下，大概是五分钟左右。 **发言者（连云波）：** 我建议这个地方要加一下。未来做一个PPT宣讲，一般需要二十分钟到半小时。这个可能从技术架构上难度并不高。 **发言者（正浩）：** 主要从开销上，就是花费钱。 **发言者（连云波）：** 技术架构上，所以我觉你可以先试一试。一到三十、三到五分钟都肯定能做，无非就是花销。所以这个需求提的就不是特别准。其实二十到三十分钟应该是主要需求。 --- ## 二十、数字人核心需求分析 **画面内容：** 屏幕向下滚动到"4. 第一阶段核心需求"，展示"4.1.1 PPT宣讲的时间与PPT视频画面精准同步"。 **发言者（连云波）：** 这为什么是需求？因为这个东西你不明确了之后就是容易出歧义的地方。比如说数字人主导还是PPT主导，这个你不说清楚就是有人理解不同。所以这个就是要需求来明确。 **发言者（正浩）：** 第一个需求就是讲解时间和PPT同步。 **发言者（连云波）：** 视频最后你可以再出现一个数字人的再见画面，大概率能出来有始有终。就不是画中画了，可以是数字人独立的告别。 **画面内容：** 屏幕滚动到"4.1.2 数字人口型的视觉吻合以及智能避让"。 **发言者（正浩）：** 第二个需求就是数字人的窗口不能遮挡到PPT的主内容。有些内容可能出现在右下角，主内容是不能被遮挡的，数字人要根据PPT的位置来做调整。 **发言者（连云波）：** 这个你们得处理，目前是人来处理的吧？ **发言者（连云波）：** 你认为有一个很大的问题，你的人的动作，手是没有。前十秒和后十秒没有动作是不行的。前十秒人呆呆的站在那讲是有问题的。至少有个手势也行，没有躯体动作也可以，你手的动作得有。这个标准里面要把手势至少先加进去。 --- ## 二十一、数字人真实性与选型讨论 **画面内容：** 屏幕向下滚动到"4.1.3 高质量数字人"。 **发言者（正浩）：** 第三段就是一个质量高的数字人的要求，然后也加上了你说的就是老外不能出现一口流利中文这种。 **发言者（连云波）：** 这个就是典型问题——只看树木不看森林。老外生成的中文很流利就很好？不是这样的。因为在人的印象当中，这是一个不真实的事情。一个老外说的中文比你还流利，那是真实的吗？你一看就质疑这人是真是假。你这上来就让人质疑你，你好不容易想把它做真，上来第一个就让人质疑你真假。你的所有目标都在追求真，最后来一个最假的表现出来，这是本末倒置了。 接下来就是录成人，录成自己、录成需要的人物形象之后用他的语音来训练上面的一些动作模型什么这些东西，或者来生成，看看他生成的质量。 --- ## 二十二、数字人平台选型与费用对比 **画面内容：** 屏幕显示"数字人平台选型"表格，列出了HeyGen、百度希壤、即梦AI等平台的费用和参数。 **发言者（正浩）：** 这块基本上就是根据西平给我的调研文档，然后我自己又确认过了的结果。大概就是视频生成的费用。 **发言者（连云波）：** 可灵即梦这么贵吗？数字人？ **发言者（正浩）：** 数字人确实积分挺贵的，是按秒算的。 **发言者（连云波）：** 数字人其实没有那么多计算量的。你那个直接文字生成视频还贵。百度希壤的和黑镜的，目前的最佳可能就这两了，前面不可能。另外一个VEO 3再看看。 **发言者（正浩）：** 百度的是便宜的，是按分钟包的。40块钱可以买10分钟。黑镜会员在平台上是免费的，只要买两个数字人的授权。百度希壤如果做定制数字人，好像一个要一千还是两千块钱，然后生成视频也要钱。黑镜就只收定制费，后面用生成好的数字人再生成视频就不要钱了。 **发言者（连云波）：** 你再试试那个Gemini的VEO 3.1看看。但他现在生成比较短，是完全自主生成，数字人还没用。 **发言者（正浩）：** VEO 3.1是不是升级了？我之前测试VEO 3.1无声视频的效果中，VEO的表现没有那几个图生视频的效果好。 **发言者（连云波）：** 他现在Nano Banana出来之后视频都升级了，3.0 Pro出来之后都升级了。我觉得你可以再试试，现在的水平还挺高的。如果是这样的话，Nano Banana或者3.0 Pro可能是一统江湖了，几乎所有事都能干了。 --- ## 二十三、AI视频生成工作流建议 **发言者（连云波）：** 我给你个建议，通过Gemini 3给你生成分镜头脚本。你给它一段比如说谁谁谁上台，上台之后什么样一个要求，然后什么样的背景，镜头机位怎么运转。给它一个分镜头脚本，比如做一个两分钟的分镜头脚本出来，然后给到V3或者什么模型分段生成就好了。 甚至你都可以把分段的图片都先生成，通过Nano把分段的图片都生成，生成之后再利用首尾帧再生成图像，做成两分钟的合起来的视频。 Gemini 3对镜头的理解和分镜脚本的生成是比一般的模型要做得好的，视觉现在没有能超过它的。 **发言者（正浩）：** 其实就是用Gemini 3.0把分镜头的提示词让它生成，图片也让它生成，然后再找个地方生成视频。 --- ## 二十四、前端重构需求讨论 **画面内容：** 屏幕切换至另一份 Word 文档，标题为"前端重构需求"。 **发言者（正浩）：** 前端重构的话就是我只重构前端的展示部分和代码结构，保留现在前端的一些基础功能。 **发言者（连云波）：** 流程不动是对的，先不动，后面再说。但是我建议你在重构的时候就考虑到下一个版本的交互逻辑的更改。不要到时候架构调整又过不了了或者要重新修改。最好把下一个版本的功能需求结合这一次重构一起考虑进去。 后端都不要动，但是你现在可以拿Opus 4.5或者Codex把现在的后端代码审查一遍。先不动它，先让他提意见，看审查出来有多少问题，慢慢重构。最好找一个Code Review去做一次审查，审查出来的毛病记下来之后再说，这就相当于需求文档了。 --- ## 二十五、Skill调用Sub-agent调研 **画面内容：** 屏幕切换至另一份 Word 文档，标题为"Skill 调用自定义 Sub-Agent 调研文档"。 **发言者（连云波）：** 首先Sub-agent的作用是什么？就是为了做上下文区分，上下文的隔离。我们要看究竟这次调用有没有起到这个作用：第一，Sub-agent调用的时候我的上下文是不是真的减少了。我们测下来，只要你调用Sub-agent确实主窗口上下文是减少了。但是第一怎么验证？第二个怎么能证明我们这个Sub-agent是被调用了？ 出现的问题是什么呢？Sub-agent在子项目下调用的时候，会出现一个什么？它会去读那个Sub-agent的提示词。主窗口去读，它只是作为一个参考文档，而不是自动实现了一个独立的Sub-agent去调。 而且有时候很怪，它没有用Task调，它有时候也能够实现上下文的隔离。首先发现第一个现象是它会去读Sub-agent，读完之后会把上下文里面加入这个Sub-agent的一些要求，但这个要求并不能完全实现。 **技术备注：** Claude Code最新版Mac版已经不依赖NPM安装。另外发现VPN会导致第一轮对话总是不通的问题，需要切换网络才能解决。 --- ## 二十六、Sub-agent调用测试场景与结论 **画面内容：** 屏幕显示 VS Code 界面，左侧资源管理器显示 `.cursor` 文件夹结构。 **发言者（闫旭隆）：** 主要是分两个大块，一块是Sub-agent在全局下的调用，一块是Sub-agent在项目下的调用。项目下分两个场景，全局下分一个场景，一共三个场景。 **测试结论：** - **场景一（全局下调用）**：用项目下的Skill调用全局下的Sub-agent，能按照全局下的prompt来执行任务。Read动作出现了，上下文没有占用主窗口。 - **场景二（项目下，相对路径）**：Sub-agent在项目下，使用相对路径调用，几乎没有成功过。它会读Sub-agent的提示词，但不执行。 - **场景三（项目下，绝对路径）**：使用绝对路径调用，成功了。测试七八次基本稳定。 **发言者（连云波）：** 我的理解是：它在给定绝对目录的时候确实能够调用。如果不给绝对目录，它去搜的时候可能搜不到，觉得有这个全局的Sub-agent叫这个名字但搜不到，它就认为你这个指令不正确。但它同时读过这个Sub-agent的Prompt，读完但不执行。指定目录之后，它去这个主目录下读了，在Agent目录下能找到，能找到以后它就会去调用。 它没有那么严格地说一定不能执行子目录下的Sub-agent，但是如果你不给它发生冲突的时候，它会首先默认去找全局Agent。这对后面应该是有很大的影响的，如果可以的话，我们用什么样的指令、怎么调用，这对Sub-agent的架构组织就不一样了。 --- ## 二十七、Agent组织架构建议 **发言者（连云波）：** Skill调用Sub-agent还不是一个非常好的方式。真的应该是Agent调用Skill。最好的方法就是用Agent调用Skill。Skill里面装Sub-agent这个方法确实有点问题，组织会乱。 不要在Skill里面调用，在Agent里面调用Agent。不要把所有的Sub-agent全部放在全局，你可以放在子项目下，但由谁来调用呢？用Agent调Agent，这是最容易的。Agent可以调Agent，分分钟的事情，没有问题的。 你可以定义一个主Agent，怎么定义怎么激活呢？直接在Agent下面定义这个主Agent之后，你直接选定它，它就是主Agent。这种Agent下你再去调用其他的Agent就全部是Sub-agent。子项目应该这么来组织。不然一会儿Skill调Agent，Agent调Skill，来回嵌套，逻辑关系能搞死你。 我们索性，非必要情况下，用Agent来组织Agent会更好，不用Skill来组织Agent。Skill最大的问题是，Skill的上下文其实也在主窗口里面。 **发言者（闫旭隆）：** 调试的时候可以用现在这种方式，调试整个流程调通了之后，可以把Skill.md移植到Agent里面，然后用主窗口去调。 --- ## 二十八、本周P0任务确认 **发言者（闫旭隆）：** P0任务汇总： 1. 会议纪要Skill：先用现在版本生成一份，然后主窗口加载会议转写上下文 2. 转写文本两边各生成一个：腾讯会议版本和Gemini视频转写版本 3. 用Gemini转写文本套到Skill + 直接用Gemini喂视频生成会议纪要 4. 需求Skill：再看一下二阶段专家交叉回应那块，整理出可视化效果 5. 需求Skill流程图也走一遍，看未来流程里面需要怎么修改完善 6. 招投标的Skill架构设计（从P1提到P0，比较急） **发言者（正浩）：** 数字人这块P0： 1. PPT样本生成，用自己真实人容貌训练出来的语音和视频 2. 工作流研究，API调用或网站操作或剪映自动化工具 3. 通过Gemini 3.0生成分镜头脚本和图片，找平台试生成视频效果 **发言者（连云波）：** 前端重构：第一用Codex或大模型把后端走一遍看有什么问题。第二把前端方案用大模型再做一遍，看跟现在方案有什么差异。还有把下个版本可能修改的逻辑先考虑一下。 --- ## 二十九、PPT自动生成Skill演示 **画面内容：** 展示Mac电脑桌面，打开了多个窗口，包括终端命令行、浏览器和代码编辑器。终端界面显示正在运行Playwright代码。 **发言者（连云波）：** 这是我做最简单的一个了。生成PPT，它会启动这个Skill，问你要什么主题。我需要生成两页PPT，手写体风格。首先创建PPT工作目录，然后调用Gemini图片生成器来创建。 我后来直接把Skill嵌套Skill来做了，直接放弃Sub Agent了。虽然上下文会比较长，但是调用逻辑关系非常清晰。Skill套用Skill反而比Sub Agent要清晰得多，因为上下文是共享的。逻辑控制上非常精确。到了Sub Agent里面因为不带上下文之后，逻辑控制有很大问题。 **画面内容：** 终端显示 "The 'gemini-image-generator' skill is running"。 **发言者（连云波）：** 我本来想用上下文隔离，后来直接把它调拉到主窗口下来了。主上下文的窗口最好用。但凡多，但我们不是多轮对话了，其实没必要。 **技术实现要点：** 用Playwright MCP来控制浏览器操作，这个控制得非常精准。整个流程是：Playwright打开Gemini → 激活生图模式 → 上传文件 → 输入提示词 → 等待生成 → 点击下载。下载时会弹出存储窗口，已经脱离浏览器控制，这时候用OS Scripts来操控保存。最后用Python脚本组装PPT并自动打开。 对Agent有很多行为规范的限定才能保证数据质量。Skill里面写示例很重要，正确示例和错误示例都要写，输入之后它执行就好了。 --- ## 三十、Gemini图片生成与自动化流程 **画面内容：** 终端显示Playwright正在操作浏览器，上传文件到Gemini。 **发言者（连云波）：** 为什么用Gemini？Claude无论你生成多好的提示词，都不如Gemini自己读这份文档然后自己制定的方案好。给我一个很大的启示：你不要规定它做什么，上下文给它越全，它其实做的效果越好。所以我现在对上下文有另外一个考量，上下文其实越全越好。 **画面内容：** Gemini界面显示生成的规划方案，手写体风格，然后开始生成图片。 **发言者（连云波）：** 这个是先生成规划方案。手写体风格上下文代入得很好。一开始不是这样的，它有很多自己加工的东西进去，把文件的理解全都加进去了。 **画面内容：** 浏览器界面显示图片生成完毕，鼠标点击下载按钮，然后通过OS Scripts保存图片。 **发言者（连云波）：** 生成之后点击下载，它已经脱离了浏览器，Playwright已经操作不了了。这时候用OS Scripts做一个Save Image的脚本，操控存下来。存完之后用Python脚本组装PPT，然后自动打开。完全自动化，你只要给它一个目录就OK了。 --- ## 三十一、Canva自动生成PPT演示 **画面内容：** 展示通过Canva自动生成的"探索日本"PPT，文本框可编辑。 **发言者（连云波）：** 还有一个方案，直接用Canva来生成。我给它一个HTML文件，说根据这个HTML文件直接生成PPT。这是完全基于文字都可修改的。而且它还可以直接导到Doc里面。 最重要的是它在里面可以修改图，用Gemini来做的，跟Copilot很像了。比如这张图分辨率很低，直接让它生成成2K分辨率的。直接在Canva里面自动就找到了。 还有一个是一张长信息图，也很有价值。不用那么多页，一张图把这份文档的要点总结出来。长信息图做得非常好。 --- ## 三十二、日报驱动项目管理系统任务分配 **发言者（连云波）：** 把Cloud Agent Cloud Code那个Max版本的到时候给丁康用一下，他的主要任务就是做日报驱动的整个项目管理系统那个Skill或者开发。包括基于会议纪要做日报，然后日报出来之后怎么驱动项目管理、跟Asana这些MCP怎么对接。 **发言者（姜正达）：** 昨天也跟他沟通过了，让他先学一下Asana的架构、模块什么的，先熟悉一下然后再设计一下。 --- ## 三十三、Skill到LangChain架构迁移思考 **发言者（连云波）：** 都用Skill。因为他要看到的都是样子，后面这些东西但凡用得多了，我们就开始转化。转化我想好有什么框架，比如基于Kimichat2、基于Claude自己的API、Cloud Code Agent或者Cloud Agent。怎么转到别人的Agent框架？LangChain LangGraph都是非常好的，那如果Deep Agent架构能用的话也行。但是脚手架、上下门这些东西得找一个小程序做一次研究或学习，做一个小功能怎么去映射过去。 作为P1或者P2吧，就这个从Cloud Code Skill转移到LangChain LangGraph的Deep Agent架构的研究项目。 **发言者（焦老师）：** 你要是忙不过来那个Skill，我都可以帮你写。先试着做，那个挺简单的。 **发言者（连云波）：** 前期得把Skill这些整个的底层东西全部学一遍，不然出来的东西不好用。包括Skill、Agent、检索有什么关系，这东西得学好久呢。