需求文档skill回溯专家博弈之前
This commit is contained in:
@ -1,205 +0,0 @@
|
||||
# Q&A资源库类会议纪要 (2025-11-25)
|
||||
|
||||
## 一、会议信息
|
||||
|
||||
- **会议时间:** 2025-11-25
|
||||
- **参会人员:** 连云波(主持)、江争达、闫旭隆、陶西平、郝倩玉
|
||||
- **请假人员:** 刘志豪
|
||||
|
||||
---
|
||||
|
||||
## 二、工作问题 Q&A
|
||||
|
||||
### 1. 项目:会议纪要Skill开发
|
||||
|
||||
**Q1: 会议纪要Skill数据映射逻辑复杂怎么办?**
|
||||
|
||||
**A:**
|
||||
- 参考会议转写文本进行状态更新,会议转写内容优先级最高
|
||||
- 优化架构:主窗口负责协调,每个子Agent获得全量上下文独立处理一个功能模块
|
||||
- 不再使用分块索引搜索,改用主窗口直接处理全文,提高准确性
|
||||
- 负责人字段需要根据会议讨论更新,不能仅沿用上周数据
|
||||
|
||||
**Q2: Read工具读取会议转写文本受token限制(每次约300行),如何处理大文件?**
|
||||
|
||||
**A:**
|
||||
- Read工具可以通过指定offset和limit参数分多次读取完整文件
|
||||
- prompt第一句话就要求"用Read工具读取全文",上下文保持干净
|
||||
- 可以指定按1000行分块读取,强制要求"必须全部读完"
|
||||
- 改用全文加载方案:主窗口直接读取全文,每个子Agent都获得全量上下文
|
||||
|
||||
### 2. 项目:需求文档质量提升
|
||||
|
||||
**Q3: 需求文档罗列了大量默认功能,如何区分默认需求与核心需求?**
|
||||
|
||||
**A:**
|
||||
- 使用"如果不提是否就不实现"原则筛选需求——不提就不实现才叫需求
|
||||
- 需求要聚焦核心难点,排除默认功能(如"PPT能动"、"有声音"等)
|
||||
- 深度挖掘用户真实需求,不能停留在表面功能罗列
|
||||
- 需求文档要明确:既不能太普通(默认功能),也不能太拔尖(无法实现)
|
||||
- 先明确当前遇到的核心问题,再提炼需求
|
||||
|
||||
**Q4: 需求文档Skill生成的领域专家不相关(如医疗信息化专家),如何优化?**
|
||||
|
||||
**A:**
|
||||
- 优化专家生成提示词,增加AI专家作为固定专家
|
||||
- 改进领域专家识别逻辑,确保生成相关领域专家
|
||||
- 增加专家评审后的博弈机制,多轮评审提高质量
|
||||
- 未来可扩展为多轮博弈:一个专家读另一个专家的评审,相互质证
|
||||
|
||||
### 3. 项目:Skill开发效率
|
||||
|
||||
**Q5: Skill每次测试需要启动半小时,如何提升测试效率?**
|
||||
|
||||
**A:**
|
||||
- 开发Skill测试工具(类似skill-quality-checker)
|
||||
- 自动提取各个逻辑分支,检查边界信息传递是否正确
|
||||
- 人工测试聚焦于效果验证,自动化测试负责逻辑验证
|
||||
- 使用调试输出来追踪异常情况
|
||||
- 赋予Agent测试人员职能,自动定位问题,反馈边界错误
|
||||
|
||||
**Q6: 开发复杂Skill时逻辑混乱,前后矛盾怎么办?**
|
||||
|
||||
**A:**
|
||||
- 开发前必须先绘制流程图,画大图把逻辑连线的过程就是思考过程
|
||||
- 人脑记不住多个逻辑线,视觉理解优于文字
|
||||
- 开发流程断了一环(如缺少流程图),后面优化就很难
|
||||
- 流程图帮助发现逻辑漏洞和前后矛盾
|
||||
|
||||
### 4. 项目:需求对接管理
|
||||
|
||||
**Q7: 需求方需求不明确且不实际,项目无法推进怎么办?**
|
||||
|
||||
**A:**
|
||||
- 等待需求方与决策者(如窦主任)沟通明确需求后再启动
|
||||
- 需求方向建议:要么做深度分析,要么做广度覆盖,不可能比业务员更了解业务细节
|
||||
- 不是所有需求都要开发,不明确的需求宁可暂停
|
||||
- 提供可借鉴思路,但决策权留给需求方
|
||||
|
||||
---
|
||||
|
||||
## 三、重点工作方法
|
||||
|
||||
### 方法1: 全量上下文优于分块搜索
|
||||
|
||||
**方法描述:**
|
||||
在会议纪要Skill架构讨论中强调:准确性优先于效率。在上下文允许的情况下,每个子Agent都应获得全量上下文独立处理功能模块,而非通过分块索引搜索。主窗口负责协调,子Agent获得全文处理,避免语义检索导致的信息丢失。子Agent返回精简结果给主窗口汇总,保证准确性。
|
||||
|
||||
**适用场景:** Claude Code Skill架构设计、大文本处理
|
||||
|
||||
**关键要点:**
|
||||
- 准确性优先于效率
|
||||
- 主窗口协调,子Agent独立处理
|
||||
- 子Agent返回精简结果
|
||||
- 避免语义检索的信息丢失
|
||||
|
||||
---
|
||||
|
||||
### 方法2: 需求提炼的层次性原则
|
||||
|
||||
**方法描述:**
|
||||
需求分析要区分默认需求与核心需求。默认需求(如PPT能动、有声音)无需单独列出,应聚焦于用户真实痛点和技术难点。判断标准:"不提就不实现"才叫需求。需求排列要考虑优先级,避免罗列所有功能,需深度挖掘比用户想得更深远的需求。
|
||||
|
||||
**适用场景:** 需求文档撰写、需求评审
|
||||
|
||||
**关键要点:**
|
||||
- "不提就不实现"才叫需求
|
||||
- 默认能实现的不是需求
|
||||
- 深度挖掘比用户想得更深远
|
||||
- 需求分层次,聚焦核心难点
|
||||
|
||||
---
|
||||
|
||||
### 方法3: 开发流程图先行
|
||||
|
||||
**方法描述:**
|
||||
在开发复杂逻辑前必须先绘制流程图。人脑记不住多个逻辑线,画大图把逻辑连线的过程就是思考过程,避免前后矛盾。流程图断了一环,后面优化就很难。视觉理解优于文字,尤其涉及空间关系的逻辑。
|
||||
|
||||
**适用场景:** Skill开发、复杂系统设计
|
||||
|
||||
**关键要点:**
|
||||
- 先画图再写代码
|
||||
- 连线过程就是思考过程
|
||||
- 视觉理解优于文字
|
||||
- 避免开发流程断环
|
||||
|
||||
---
|
||||
|
||||
### 方法4: Agent设计的自治性原则
|
||||
|
||||
**方法描述:**
|
||||
Agent内部应固化所有执行规则、工具使用规范、评估标准,配置文件由Agent自己读取,不依赖主窗口传递。主窗口只传递标识符(如项目类型)和文件路径,不传递Agent的行为规则或配置内容。Agent间通过temp/文件传递数据,Agent向主窗口直接返回文字结果。
|
||||
|
||||
**适用场景:** 多Agent系统设计、Skill架构
|
||||
|
||||
**关键要点:**
|
||||
- 主窗口传标识符,Agent读详细配置
|
||||
- Agent间传文件路径
|
||||
- Agent向主窗口返回文字结果
|
||||
- Agent内部固化执行规则
|
||||
|
||||
---
|
||||
|
||||
### 方法5: 需求访谈的动态提问法
|
||||
|
||||
**方法描述:**
|
||||
不规定具体问题,只规定目标和方法论,把提问空间留给大模型。提供示例、原则、访谈目标,让Agent动态生成问题。增加交互澄清机制:检测用户回答包含问号、疑问性语句或明确说"需要帮助"时,立即切换到自由对话,讨论明确后再返回访谈。
|
||||
|
||||
**适用场景:** 需求澄清Skill、用户访谈
|
||||
|
||||
**关键要点:**
|
||||
- 规定目标而非具体问题
|
||||
- 把提问空间留给大模型
|
||||
- 增加交互澄清机制
|
||||
- 检测用户困惑并及时切换
|
||||
|
||||
---
|
||||
|
||||
### 方法6: 专家评审的多轮博弈机制
|
||||
|
||||
**方法描述:**
|
||||
引入多个领域专家Agent(固定AI专家+动态识别领域专家)并行评审需求文档第一版。专家评审后可选自动整合或用户确认,节省时间。未来可扩展为多轮博弈:一个专家读另一个专家的评审,相互质证,充分交流后质量更高。
|
||||
|
||||
**适用场景:** 需求文档评审、多角色协作
|
||||
|
||||
**关键要点:**
|
||||
- 固定AI专家+动态领域专家
|
||||
- 可选自动整合或用户确认
|
||||
- 多轮博弈相互质证
|
||||
- 充分交流提高质量
|
||||
|
||||
---
|
||||
|
||||
### 方法7: 模型差异化使用策略
|
||||
|
||||
**方法描述:**
|
||||
不同任务使用不同模型:专家评审等需要深度thinking的任务用Opus;文字简单处理用Sonnet更快。Opus的thinking开到middle时,能力接近Sonnet但token消耗降低48%。在Agent定义时可指定模型,优化性能和成本。
|
||||
|
||||
**适用场景:** Skill性能优化、成本控制
|
||||
|
||||
**关键要点:**
|
||||
- 深度思考用Opus
|
||||
- 简单处理用Sonnet
|
||||
- thinking设置影响能力和消耗
|
||||
- Agent定义时指定模型
|
||||
|
||||
---
|
||||
|
||||
### 方法8: 会议纪要驱动工作流
|
||||
|
||||
**方法描述:**
|
||||
会议纪要是团队所有人智慧的结晶,后续所有工作都围绕它展开:项目管理、学习安排、任务分配。甚至可以根据会议纪要生成人员招聘要求,因为工作要求都在里面。会议纪要质量直接影响后续执行,好的会议纪要员能把逻辑理得清晰、任务安排妥当。
|
||||
|
||||
**适用场景:** 团队协作、项目管理
|
||||
|
||||
**关键要点:**
|
||||
- 会议纪要是团队智慧结晶
|
||||
- 后续工作围绕会议纪要展开
|
||||
- 纪要质量影响执行效果
|
||||
- 可驱动项目管理和任务分配
|
||||
|
||||
---
|
||||
|
||||
**纪要整理人:** Claude
|
||||
**纪要时间:** 2025-11-25
|
||||
**下次会议:** 2025-12-02
|
||||
@ -0,0 +1,199 @@
|
||||
# Q&A资源库类会议纪要 (2025-12-09)
|
||||
|
||||
## 一、会议信息
|
||||
|
||||
- **会议时间:** 2025-12-09
|
||||
- **参会人员:** 连云波(主持)、闫旭隆、郝倩玉、陶西平、江争达
|
||||
- **记录整理:** Claude
|
||||
|
||||
---
|
||||
|
||||
## 二、工作问题 Q&A
|
||||
|
||||
### 1. 项目名称:数字人视频生成相关问题
|
||||
|
||||
**问题1:数字人视频生成流程存在逻辑不自洽**
|
||||
|
||||
- **问题描述:** 当前数字人视频生成流程需要先录制绿幕视频训练数字人模型,再上传图片生成动作参考视频,最后生成口播视频。如果可以通过图片直接生成动作视频,为什么还需要先上传真人视频训练模型?两个视频同时训练一个东西在逻辑上存在矛盾。
|
||||
- **解决方案:**
|
||||
1. 测试直接用图片创建数字人专家,不拍摄绿幕视频,对比效果是否一致
|
||||
2. 使用剪映等外部软件先抠背景再导入黑镜平台
|
||||
3. 删除现有专家账号重新测试流程,验证是否必须上传真人视频
|
||||
- **责任人:** 江争达、陶西平
|
||||
- **截止时间:** 2025-12-16
|
||||
|
||||
**问题2:数字人视频背景抠不干净**
|
||||
|
||||
- **问题描述:** 生成的数字人视频存在背景抠不干净的问题,有浅蓝/浅绿色阴影残留。
|
||||
- **解决方案:**
|
||||
1. 不要依赖平台自身的抠图功能
|
||||
2. 使用剪映等外部软件先进行背景去除
|
||||
3. 将处理后的视频再导入平台使用
|
||||
- **责任人:** 江争达、陶西平
|
||||
- **截止时间:** 2025-12-16
|
||||
|
||||
### 2. 项目名称:VEO视频生成相关问题
|
||||
|
||||
**问题1:VEO视频生成工具使用不当导致效果差**
|
||||
|
||||
- **问题描述:** 使用VEO Three生成分镜脚本视频时,使用中文prompt且首尾帧图片完全相同,导致生成的视频人物几乎不动,动作指令完全没有执行。VEO Three对英文prompt的遵循效果远好于中文。
|
||||
- **解决方案:**
|
||||
1. 必须使用英文prompt,VEO Three对英文指令遵循效果最好
|
||||
2. 首尾帧应使用不同的图片(如尾帧是往前走两步后的状态)
|
||||
3. 多学习网上其他人的使用经验(YouTube、Twitter、Reddit)
|
||||
4. 重新用英文prompt制作视频
|
||||
- **责任人:** 陶西平
|
||||
- **截止时间:** 2025-12-16
|
||||
|
||||
### 3. 项目名称:问答系统前端重构相关问题
|
||||
|
||||
**问题1:前端重构缺乏明确目标和需求文档**
|
||||
|
||||
- **问题描述:** 汇报前端重构工作时,PPT直接展示做成什么样,缺乏"为什么要重构"(Why)的分析。没有说明前端具体存在哪些问题、想要达成的目标是什么、理想的展示效果是什么样的。"没有需求文档就开发"、"先生成代码再倒回来补文档"是错误做法。
|
||||
- **解决方案:**
|
||||
1. 先明确目标,说清楚想要什么样的效果,画出设计草图
|
||||
2. 整理前端代码存在的具体问题案例
|
||||
3. 按照"Why-How-What"的逻辑结构重新组织汇报材料
|
||||
4. 需求文档必须先批准才能开发,不准先开发再补文档
|
||||
5. 需求可以分阶段开发,但必须有整体的阶段设计
|
||||
- **责任人:** 江争达
|
||||
- **截止时间:** 2025-12-16
|
||||
|
||||
### 4. 项目名称:Gartner报告转写相关问题
|
||||
|
||||
**问题1:报告转写规则和风格提取困难**
|
||||
|
||||
- **问题描述:** 转写后的英文翻译生硬(如"构建者"、"综合者"等不符合信通院用语习惯);AI痕迹明显,缺乏观点;风格规则难以精确提取,写多了约束可能偏,写少了表现不好。
|
||||
- **解决方案:**
|
||||
1. 先提取每段要点总结,再重新生成文章(骨架提取法)
|
||||
2. 不必完全忠实于原文英文词汇,可以进行意义转写
|
||||
3. 使用NotebookLM做Deep Research,融合相关资料后再写
|
||||
4. 请信通院专家来审核和调整专业术语
|
||||
5. 转写后需要有检查优化的流程
|
||||
- **责任人:** 闫旭隆
|
||||
- **截止时间:** 2025-12-16
|
||||
|
||||
### 5. 项目名称:工具使用能力相关问题
|
||||
|
||||
**问题1:工具使用能力不足,不会学习**
|
||||
|
||||
- **问题描述:** 团队成员对AI工具(黑镜、VEO、Claude Code等)的使用能力不足,不会主动学习。同样的工具在不同人手里效果完全不同,90分的工具用出50分都不到的效果。遇到问题不去网上搜索学习,而是闷头自己试。
|
||||
- **解决方案:**
|
||||
1. 多上网学习,看YouTube、Twitter、Reddit上别人的使用经验和案例
|
||||
2. 遇到问题先用Deep Research等工具搜索解决方案
|
||||
3. 利用多个AI工具(GPT、Claude、DeepSeek等)交叉验证和获取建议
|
||||
4. 不要自以为是,要AI First,从别人那里学习
|
||||
- **责任人:** 江争达、陶西平
|
||||
- **截止时间:** 2025-12-16
|
||||
|
||||
### 6. 项目名称:汇报表述相关问题
|
||||
|
||||
**问题1:汇报表述不清晰、逻辑混乱**
|
||||
|
||||
- **问题描述:** 多名成员在汇报时存在表述不清、逻辑混乱的问题。解释技术流程时反复说不清楚,无法用简洁明了的语言描述工作内容和技术流程。
|
||||
- **解决方案:**
|
||||
1. 汇报前先理清思路,用一句话概括核心流程
|
||||
2. 练习表达能力,学会用简洁语言描述复杂流程
|
||||
3. 汇报时按照步骤一二三清晰说明,不要东一下西一下
|
||||
- **责任人:** 江争达、陶西平
|
||||
- **截止时间:** 2025-12-16
|
||||
|
||||
---
|
||||
|
||||
## 三、重点工作方法
|
||||
|
||||
### 方法 1:需求文档先行原则
|
||||
|
||||
- **方法描述:** 在开发之前必须先完成需求文档的撰写和批准。需求文档必须包含三个核心要素:Why(为什么要做)、What(要做成什么样)、How(怎么做)。不能先生成代码再倒回来补文档,需求不明确时不准开发。需求可以分阶段开发,但必须有完整的阶段设计,不能走一步看一步。
|
||||
- **适用场景:** 前端重构、问答系统开发、任何需要开发的项目
|
||||
- **关键要点:**
|
||||
- 需求文档必须先批准才能开发
|
||||
- 包含Why-What-How三要素
|
||||
- 分阶段开发也要有整体设计
|
||||
|
||||
### 方法 2:问题驱动的重构方法
|
||||
|
||||
- **方法描述:** 重构前必须先明确:1)现有系统存在哪些具体问题(需要案例展示);2)想要达到的目标是什么(理想效果);3)为什么现有方案达不到目标。不能简单说"代码冗余"就重构,必须有具体的问题分析和目标定义。
|
||||
- **适用场景:** 代码重构、系统优化、架构调整
|
||||
- **关键要点:**
|
||||
- 用案例展示具体问题
|
||||
- 明确目标和理想效果
|
||||
- 分析现有方案的不足
|
||||
|
||||
### 方法 3:AI工具使用的英文优先原则
|
||||
|
||||
- **方法描述:** 使用VEO等AI视频生成工具时,必须使用英文Prompt才能获得最佳效果。中文Prompt的指令遵循能力很弱,可能导致生成的视频完全不符合要求。需要先学习工具的使用规范,不能想当然地使用。
|
||||
- **适用场景:** VEO视频生成、AI图像生成、大模型调用
|
||||
- **关键要点:**
|
||||
- 英文Prompt效果远好于中文
|
||||
- 先学习工具使用规范
|
||||
- 参考网上优秀案例
|
||||
|
||||
### 方法 4:外部工具增强法
|
||||
|
||||
- **方法描述:** 当平台内置功能效果不好时,不要依赖平台自身功能,应该使用外部专业工具先进行预处理,再将处理后的素材导入平台使用。例如使用剪映先进行视频背景去除,再导入黑镜平台。
|
||||
- **适用场景:** 数字人视频制作、视频后期处理、图片编辑
|
||||
- **关键要点:**
|
||||
- 识别平台功能的不足
|
||||
- 选择合适的外部工具
|
||||
- 预处理后再导入使用
|
||||
|
||||
### 方法 5:AI First学习方法
|
||||
|
||||
- **方法描述:** 遇到不会的问题时,要主动到网上学习(YouTube、Twitter、Reddit等),搜索别人的先进经验,而不是闭门造车自己摸索。使用AI工具前要先学习官方文档和最佳实践,内化为自己的能力。不会学习的时候,把学习过程也告诉大家,让大家帮助纠正。
|
||||
- **适用场景:** 新工具学习、问题解决、技能提升
|
||||
- **关键要点:**
|
||||
- 主动搜索别人的经验
|
||||
- 学习官方文档和最佳实践
|
||||
- 利用AI工具交叉验证
|
||||
|
||||
### 方法 6:逻辑结构四维度框架
|
||||
|
||||
- **方法描述:** 文档和汇报应遵循清晰的逻辑结构,包含四个维度:1)时间维度(发展历程);2)空间维度(范围边界);3)层次维度(从粗到细);4)认知维度(是什么-为什么-怎么做)。从Why开始,不能上来就是How。
|
||||
- **适用场景:** 需求文档编写、PPT汇报、方案设计
|
||||
- **关键要点:**
|
||||
- 时间、空间、层次、认知四维度
|
||||
- 从Why开始,不是从How开始
|
||||
- 由粗到细逐层展开
|
||||
|
||||
### 方法 7:首尾帧差异化设计原则
|
||||
|
||||
- **方法描述:** 使用VEO等工具生成视频时,首帧和尾帧图片不能用同一张。如果两张图片完全一样,视频默认就是静止不动的。应该生成一张有动作变化的尾帧图片(如往前走两步),这样生成的视频才会有动态效果。
|
||||
- **适用场景:** VEO视频生成、AI视频制作
|
||||
- **关键要点:**
|
||||
- 首尾帧必须不同
|
||||
- 尾帧应体现动作变化
|
||||
- 避免静止画面输出
|
||||
|
||||
### 方法 8:报告转写的骨架提取法
|
||||
|
||||
- **方法描述:** 转写报告时,可以先提取每一段的要点总结,形成骨架结构,然后再基于骨架重新生成文章。这样可以避免生硬地照着原文翻译,产生更自然的转写效果。原文只保留骨架逻辑和关键数据,表达方式可以完全重写。
|
||||
- **适用场景:** 报告转写、文档翻译、内容改写
|
||||
- **关键要点:**
|
||||
- 先提取要点形成骨架
|
||||
- 基于骨架重新生成
|
||||
- 保留逻辑和数据,重写表达
|
||||
|
||||
### 方法 9:多模态融合工作流设计
|
||||
|
||||
- **方法描述:** 未来工作应该把多模态能力(文字、图片、视频、语音)融合到日常工作中。PPT制作可以用AI直接生成,图片中的文字可以直接编辑修改。要思考如何将多模态能力集成到自己的业务流程中,形成更高效的输出。
|
||||
- **适用场景:** PPT制作、视频生成、内容生产
|
||||
- **关键要点:**
|
||||
- 多模态能力融合
|
||||
- 思考业务流程集成方式
|
||||
- 形成高效的生产工作流
|
||||
|
||||
### 方法 10:Skill持续进化学习机制
|
||||
|
||||
- **方法描述:** Skill应该设计成可以自我学习和进化的。方法是:在使用过程中遇到问题后,把对话记录发给AI,让它帮助总结问题并改进Skill。随着每天的使用,Skill会自动进化。这种方式可以让知识持续沉淀在Skill中。
|
||||
- **适用场景:** Skill开发、知识管理、自动化流程优化
|
||||
- **关键要点:**
|
||||
- 设计自我学习机制
|
||||
- 对话记录用于改进
|
||||
- 知识持续沉淀进化
|
||||
|
||||
---
|
||||
|
||||
**纪要整理人:** Claude
|
||||
**纪要时间:** 2025-12-09
|
||||
**下次会议:** 2025-12-16
|
||||
@ -0,0 +1,91 @@
|
||||
# 云大所需求相关进度会议纪要 (2025-12-09)
|
||||
|
||||
## 一、会议信息
|
||||
|
||||
- **会议时间:** 2025-12-09
|
||||
- **参会人员:** 连云波(主持)、闫旭隆、郝倩玉、陶西平、江争达
|
||||
- **记录整理:** Claude
|
||||
|
||||
---
|
||||
|
||||
## 二、需求项目进展
|
||||
|
||||
| 项目名称 | 负责人 | 本周进展 | 存在问题 | 下周计划 | 优先级 |
|
||||
| -------- | ------ | -------- | -------- | -------- | ------ |
|
||||
| 投标商务应答自动生成系统 | 郝倩玉、闫旭隆 | 架构设计已完成,企业信息库建设存在困难 | 企业信息库格式混乱(Excel、Word、PDF混杂);图片库来源分散缺少描述;保密信息处理问题;响应文件模板不统一 | 周四客户交流后确定最终方案,从最新招投标响应文件提取企业信息作为基础库 | P0 |
|
||||
| 数字人项目 | 江争达、陶西平、郝倩玉 | 基本可用,已完成阶段一样本视频;VEO3分镜脚本测试效果不理想 | 黑镜平台背景抠图有浅色阴影残留;数字人生成流程存在逻辑不自洽;VEO3使用中文prompt效果极差 | 测试直接用图片生成数字人模型;VEO3用英文prompt重新测试;为领导制作数字人演讲视频;郝倩玉参与视频学习 | P0 |
|
||||
| Gartner报告解读转写系统 | 郝倩玉、闫旭隆 | 架构设计和可行性单元测试已完成 | 翻译生硬不符合信通院风格;AI痕迹明显缺乏专家观点;输出字数难以控制;图片处理尚未完成 | 抓紧测试API(额度快到期),先提取每段要点总结再重新生成文章,使用NotebookLM做deep research后融合生成 | P0 |
|
||||
| 邮件自动处理转发系统 | 江争达 | 新版本已投入使用(功能优化) | 无 | 持续优化 | P1 |
|
||||
|
||||
> **备注:** 市场部需求清单中的其他项目(运营商信息精准爬取系统、客户风险推送自动化系统、证书信息提取系统、云大阁新报告自动推送)本次会议未涉及讨论。
|
||||
|
||||
---
|
||||
|
||||
## 三、问题与风险
|
||||
|
||||
### 1. 投标商务应答自动生成系统
|
||||
|
||||
**问题描述:**
|
||||
- 企业信息库格式混乱(Excel、Word、PDF混杂)
|
||||
- 图片库来源分散,缺少描述和映射关系
|
||||
- 保密信息处理问题(部分内容不能给AI读取)
|
||||
- 响应文件模板不统一,每个招标文件要求不同
|
||||
- 逻辑映射规则复杂,难以移植
|
||||
|
||||
**解决方案:**
|
||||
1. 从最新招投标响应文件提取企业信息作为基础库
|
||||
2. 使用AI读取历史文件中的图片和位置,生成索引后让市场部审核标注
|
||||
3. 保密内容由市场部先筛选删除后再提供
|
||||
4. 不够的信息再去原有库补充
|
||||
5. 周四客户交流后再确定最终方案
|
||||
|
||||
**责任人:** 郝倩玉、闫旭隆
|
||||
**截止时间:** 2025-12-16
|
||||
|
||||
### 2. 数字人项目
|
||||
|
||||
**问题描述:**
|
||||
- 数字人视频生成流程存在逻辑不自洽(先录绿幕训练+再用图片生成动作可能冗余)
|
||||
- 黑镜平台背景抠图效果不理想
|
||||
- VEO3使用中文prompt效果极差,首尾帧相同导致视频无动作
|
||||
- 工具使用方法需要学习提升
|
||||
|
||||
**解决方案:**
|
||||
1. 测试直接用图片生成数字人模型,验证是否需要先录制绿幕视频
|
||||
2. 使用剪映等外部软件先抠背景再导入黑镜平台
|
||||
3. VEO3必须使用英文prompt,首尾帧需使用不同图片
|
||||
4. 多学习网上优秀案例(YouTube、Twitter、Reddit)
|
||||
|
||||
**责任人:** 江争达、陶西平
|
||||
**截止时间:** 2025-12-16
|
||||
|
||||
### 3. Gartner报告解读转写系统
|
||||
|
||||
**问题描述:**
|
||||
- 转写后的英文翻译生硬,不符合信通院用语习惯
|
||||
- AI痕迹明显,缺乏专家观点
|
||||
- 风格规则难以精确提取
|
||||
- Gemini API额度快到期(还剩一天)
|
||||
|
||||
**解决方案:**
|
||||
1. 允许意义转写而非忠实于原词
|
||||
2. 先提取每段要点总结再重新生成文章(骨架提取法)
|
||||
3. 使用NotebookLM做Deep Research后融合生成
|
||||
4. 抓紧时间测试API,在额度到期前跑完报告
|
||||
|
||||
**责任人:** 闫旭隆
|
||||
**截止时间:** 2025-12-16
|
||||
|
||||
---
|
||||
|
||||
## 四、下周重点
|
||||
|
||||
1. 🔴 **投标商务应答自动生成系统**:周四客户交流后确定最终方案,从最新招投标响应文件提取企业信息作为基础库
|
||||
2. 🔴 **数字人项目**:测试直接用图片生成数字人模型;VEO3用英文prompt重新测试;为领导制作数字人演讲视频
|
||||
3. 🔴 **Gartner报告解读转写系统**:抓紧测试API(额度快到期),使用骨架提取法优化转写效果
|
||||
|
||||
---
|
||||
|
||||
**纪要整理人:** Claude
|
||||
**纪要时间:** 2025-12-09
|
||||
**下次会议:** 2025-12-16
|
||||
@ -1,255 +0,0 @@
|
||||
# 工程类会议纪要 (2025-11-25)
|
||||
|
||||
## 一、会议信息
|
||||
|
||||
- **会议时间:** 2025-11-25
|
||||
- **参会人员:** 连云波(主持)、江争达、闫旭隆、陶西平、郝倩玉
|
||||
|
||||
---
|
||||
|
||||
## 二、工作内容
|
||||
|
||||
### 1. 重点项目进展情况汇总
|
||||
|
||||
| 项目名称 | 负责人 | 截止时间 | 项目进展情况 |
|
||||
|---------|--------|----------|-------------|
|
||||
| 会议纪要流程文档和现场测试 | 连云波/郝倩玉/闫旭隆 | 11月25日 | 郝倩玉完成需求文档撰写并获连总确认,闫旭隆完成Skill第一版编写。会议讨论发现存在数据映射逻辑复杂、架构不够优雅等问题,需优化为全量加载方案 |
|
||||
| 公众号/网站信息获取优化和新需求开发 | 郝倩玉/江争达/陶西平/刘志豪 | 11月25日 | 需求方(富有、琳贤)反馈现有方案"为了做而做",需求不明确,项目暂停等待窦主任明确需求后再推进 |
|
||||
| 数字人需求文档 | 江争达 | 11月25日 | 已完成初版,但会议中被严厉批评:需求提炼能力不足,罗列默认功能而非核心难点,未深度挖掘用户痛点,需重新整理 |
|
||||
| 需求澄清Skill优化 | 闫旭隆 | 持续优化 | 已完成1.0版本优化测试,增加交互澄清、专家自动整合等功能,会议演示效果良好,建议增加专家多轮博弈机制 |
|
||||
|
||||
### 2. 重点项目问题及解决方案
|
||||
|
||||
#### 问题1: 会议纪要Skill数据映射和逻辑复杂性问题
|
||||
|
||||
**问题描述:**
|
||||
会议纪要Skill第一版实现中存在多个问题:
|
||||
|
||||
- 数据映射逻辑复杂,
|
||||
- 负责人变更逻辑处理不当
|
||||
- 项目进展状态更新需参考会议转写但未实现
|
||||
- 上周会议纪要和本周会议讨论内容的优先级和整合逻辑不清晰
|
||||
- 分块索引搜索方案可能影响准确性和搜索命中率
|
||||
|
||||
**解决方案:**
|
||||
1. 参考会议转写文本进行状态更新,会议转写内容优先级最高
|
||||
2. 优化架构:主窗口负责协调,每个子Agent获得全量上下文独立处理一个功能模块
|
||||
3. 不再使用分块索引搜索,改用主窗口直接处理全文,提高准确性
|
||||
4. 负责人字段需要根据会议讨论更新,不能仅沿用上周数据
|
||||
5. Read工具可通过指定offset和limit参数分多次读取完整文件
|
||||
|
||||
**责任人:** 闫旭隆、郝倩玉
|
||||
**截止时间:** 2025-12-02
|
||||
|
||||
#### 问题2: 数字人PPT需求文档质量问题
|
||||
|
||||
**问题描述:**
|
||||
江争达提交的数字人PPT需求文档存在严重问题:
|
||||
- 需求提炼能力不足,未区分默认需求与核心难点需求
|
||||
- 罗列了大量无价值的默认功能(如"动态切换"、"PPT能动"等)
|
||||
- 未深度挖掘用户真实痛点
|
||||
- 需求描述不明确,如"动态切换"实际含义不清
|
||||
|
||||
**解决方案:**
|
||||
1. 需求要聚焦核心难点,排除默认功能
|
||||
2. 使用"如果不提是否就不实现"原则筛选需求
|
||||
3. 深度挖掘用户真实需求,不能停留在表面功能罗列
|
||||
4. 需求文档要明确:既不能太普通(默认功能),也不能太拔尖(无法实现)
|
||||
5. 先明确目前数字人生成PPT讲座中遇到的核心问题,再提炼需求
|
||||
6. 结合窦主任的个性特点设计内容,不要过于死板
|
||||
|
||||
**责任人:** 江争达、郝倩玉
|
||||
**截止时间:** 2025-12-02
|
||||
|
||||
#### 问题3: 公众号/网站信息获取需求未确认
|
||||
|
||||
**问题描述:**
|
||||
公众号/网站信息获取优化和新需求开发项目,需求方(富有、林贤)的需求不明确,他们认为现有方案"为了做而做",对市场发展没有实际用处,需要重新思考需求逻辑。
|
||||
|
||||
**解决方案:**
|
||||
1. 等待需求方与窦主任沟通明确需求后再启动
|
||||
2. 可考虑整合公众号和网站信息到一个邮件中
|
||||
3. 需求方向建议:要么做深度分析,要么做广度覆盖,不可能比业务员更了解业务细节
|
||||
|
||||
**责任人:** 郝倩玉、江争达
|
||||
**截止时间:** 待定(等待需求明确)
|
||||
|
||||
#### 问题4: Skill测试效率低下问题
|
||||
|
||||
**问题描述:**
|
||||
需求文档Skill每次测试需要启动半小时,发现问题后修改再测试非常费时,缺乏自动化测试机制。
|
||||
|
||||
**解决方案:**
|
||||
|
||||
1. 开发Skill测试工具(类似skill-quality-checker)
|
||||
2. 自动提取各个逻辑分支,检查边界信息传递是否正确
|
||||
3. 人工测试聚焦于效果验证,自动化测试负责逻辑验证
|
||||
4. 使用调试输出来追踪异常情况
|
||||
|
||||
**责任人:** 闫旭隆、江争达
|
||||
**截止时间:** 待定
|
||||
|
||||
#### 问题5: 日报驱动系统架构设计不系统
|
||||
|
||||
**问题描述:**
|
||||
江争达提出通过会议纪要驱动日报的需求,但缺乏系统化的需求分析和架构设计,只关注点上的问题,未考虑整体框架。
|
||||
|
||||
**解决方案:**
|
||||
1. 先明确根本目的:提高工作效率、提高学习能力等
|
||||
2. 研究Linear项目管理工具的MCP集成
|
||||
3. 设计语音交互日报填写流程:每天5分钟语音交流完成日报
|
||||
4. 通过项目管理工具自动生成日报和周报
|
||||
5. 学习学习型组织建设理论,构建AI Native团队框架
|
||||
6. 先搭建框架(横纵梁柱),再逐步实现各个功能点
|
||||
|
||||
**责任人:** 江争达
|
||||
**截止时间:** 待定(长期探索)
|
||||
|
||||
### 3. 下周工作安排
|
||||
|
||||
| 项目名称 | 负责人 | 下周会前目标 | 优先级 | 截止时间 |
|
||||
|---------|--------|-------------|--------|----------|
|
||||
| 🔴 会议纪要Skill架构优化 | 闫旭隆 | 简化架构,改用主窗口全量加载会议转写,子Agent负责不同功能模块,提升准确性 | P0 | 2025-12-02 |
|
||||
| 🔴 需求澄清Skill测试与推广 | 闫旭隆、郝倩玉、江争达 | 完成1.0版本,发布给团队成员试用,收集反馈并优化 | P0 | 2025-12-02 |
|
||||
| 🔴 数字人PPT需求文档重写 | 郝倩玉 | 重新提炼核心需求,区分默认需求与核心难点需求,深度挖掘用户痛点 | P0 | 2025-12-02 |
|
||||
| 问答系统V1.1前端重构方案 | 江争达 | 完成需求文档和前端重构方案,使用Claude/Gemini生成前端页面,参考麦肯锡等优秀网站设计风格 | P1 | 2025-12-02 |
|
||||
| 问答系统V1.0测试推动 | 江争达 | 推动市场部及内部同事测试问答系统V1.0,收集用户反馈和问题 | P1 | 2025-12-02 |
|
||||
| 招投标文件Skill架构设计 | 郝倩玉、闫旭隆 | 郝倩玉确认需求文档并设计Skill架构,闫旭隆负责后期调试 | P1 | 2025-12-02 |
|
||||
| PDF Skill技术调研 | 江争达 | 调研Claude Code的PDF Skill功能,探索PDF文件的处理能力 | P1 | 2025-12-02 |
|
||||
| Cosmos文献综述流程整理 | 陶西平 | 整理Cosmos文献综述的完整流程和Agent编排,生成流程文档供PPT使用 | P1 | 2025-11-26上午 |
|
||||
| 日报驱动系统需求研究 | 江争达 | 研究Linear项目管理工具,探索通过会议纪要自动驱动日报和周报的系统化需求 | P2 | 待定 |
|
||||
| cc-switch并行测试 | 陶西平 | 确认cc-switch是否支持多终端并行运行,测试多模型切换场景能力 | P2 | 待定 |
|
||||
| Skill Plugin管理系统搭建 | 江争达 | 学习并搭建内部Skill Marketplace,管理团队开发的所有Skill | P2 | 待定 |
|
||||
| Skill自动化测试工具开发 | 闫旭隆、江争达 | 开发Skill测试工具,自动化检测Skill逻辑分支、边界信息传递等问题 | P2 | 待定 |
|
||||
|
||||
### 4. 组内成员工作进展
|
||||
|
||||
#### 江争达
|
||||
|
||||
**上周完成:**
|
||||
- ✅ 数字人生成需求文档初版
|
||||
- ✅ 天眼查批量删除需求文档
|
||||
- ✅ 日报/日报汇总模板需求文档初版
|
||||
|
||||
**进行中:**
|
||||
- 🔄 数字人生成调研报告修改中
|
||||
- 🔄 问答系统V1.1前端重构调研
|
||||
|
||||
**收到的反馈/学习建议:**
|
||||
- **严厉批评:** 数字人PPT需求文档质量问题严重,需求提炼能力不足,罗列所有功能而非核心难点
|
||||
- **批评:** 未区分默认需求与核心需求,需求描述不明确让人看不懂
|
||||
- **建议:** 需求调研应先识别当前最迫切的问题,区分默认需求与核心难点需求
|
||||
- **建议:** 深度挖掘背后逻辑,理解需求真实含义,需求文档要让非技术人员也能看懂
|
||||
- **建议:** 避免与大模型拍脑袋对话生成需求,要有自己的理解和整合能力
|
||||
|
||||
**下周任务:**
|
||||
- [ ] 🔴 P0|试用需求澄清Skill并提供反馈
|
||||
- [ ] P1|问答系统V1.1前端重构方案
|
||||
- [ ] P1|PDF Skill技术调研
|
||||
- [ ] P2|日报驱动系统需求研究
|
||||
- [ ] P2|Skill Plugin管理系统搭建
|
||||
|
||||
#### 闫旭隆
|
||||
|
||||
**上周完成:**
|
||||
- ✅ 需求澄清-需求文档skill优化测试 (11-21完成)
|
||||
- ✅ 会议纪要生成Skill编写 (11-25完成)
|
||||
- ✅ 安定医院Deepresearch项目需求文档初稿
|
||||
- ✅ 医院数据治理体系数智化转型PPT
|
||||
|
||||
**进行中:**
|
||||
- 🔄 会议纪要Skill架构优化
|
||||
|
||||
**收到的反馈/学习建议:**
|
||||
|
||||
- **批评:** 未绘制流程图导致思考过程不清晰,开发流程断了一环
|
||||
- **建议:** 需要绘制流程图梳理复杂逻辑关系,避免依赖抽象记忆
|
||||
- **建议:** 简化架构,尝试全量加载转写文本而非分块索引搜索,提高准确性
|
||||
- **表扬:** 会议纪要Skill整体可用,大的要点逻辑清楚,基本实现70%核心功能
|
||||
- **表扬:** 需求文档Skill迭代版本增加了交互澄清、专家自动整合等功能,演示效果良好
|
||||
|
||||
**下周任务:**
|
||||
- [ ] 🔴 P0|会议纪要Skill架构优化
|
||||
- [ ] 🔴 P0|需求澄清Skill测试与推广
|
||||
- [ ] P1|招投标文件Skill架构设计和调试
|
||||
- [ ] P2|Skill自动化测试工具开发
|
||||
|
||||
#### 郝倩玉
|
||||
|
||||
**上周完成:**
|
||||
- ✅ 会议纪要需求文档撰写(连总已审核确认)
|
||||
- ✅ 投标商务应答文件自动生成系统需求文档确认(已发闫旭隆)
|
||||
- ✅ 运营商信息精准爬取系统多轮沟通(待需求方明确)
|
||||
|
||||
**进行中:**
|
||||
- 🔄 招投标文件Skill架构设计
|
||||
- 🔄 运营商信息精准爬取系统需求跟进
|
||||
|
||||
**收到的反馈/学习建议:**
|
||||
- **任务分配:** 负责PDF Skill调研的需求整理工作
|
||||
- **任务分配:** 负责招投标文件Skill的需求文档确认和架构设计
|
||||
- **任务分配:** 负责天眼查自动化需求的沟通确认,推动窦主任明确做深还是做广
|
||||
|
||||
**下周任务:**
|
||||
- [ ] 🔴 P0|试用需求澄清Skill并提供反馈
|
||||
- [ ] 🔴 P0|数字人PPT需求文档重写
|
||||
- [ ] P1|招投标文件Skill架构设计
|
||||
- [ ] P1|运营商信息精准爬取系统需求跟进
|
||||
|
||||
#### 陶西平
|
||||
|
||||
**上周完成:**
|
||||
- ✅ 学习使用web-artifacts-builder、frontend-analysis、gemini3pro构建个性化组件
|
||||
- ✅ 本地部署lobe-chat和nextchat前端开源框架
|
||||
- ✅ 本地部署cc-switch,生成使用结果文档
|
||||
- ✅ PPT与数字人视频结合调研,构建了结合短视频
|
||||
|
||||
**进行中:**
|
||||
- 🔄 数字人调研报告草稿
|
||||
- 🔄 前端框架调研
|
||||
|
||||
**收到的反馈/学习建议:**
|
||||
- **批评:** 数字人PPT需求文档存在严重问题,需求提炼能力不足,无法区分默认需求与核心难点需求
|
||||
- **批评:** 对"动态切换PPT"需求理解浅薄,未理解背后技术实现逻辑
|
||||
- **建议:** 需求提炼要先调研当前遇到的问题,按优先级排列
|
||||
- **建议:** 需求文档要体现难点和第一阶段核心点,不要放置小功能到核心需求里
|
||||
- **建议:** 每一步工作都要做扎实,经得起推敲
|
||||
|
||||
**下周任务:**
|
||||
- [ ] P1|Cosmos文献综述流程整理(11-26上午前完成)
|
||||
- [ ] P1|完成数字人调研报告
|
||||
- [ ] P1|完成PPT与数字人结合调研
|
||||
- [ ] P2|cc-switch并行测试
|
||||
|
||||
---
|
||||
|
||||
## 三、会议总结
|
||||
|
||||
**核心议题:** 会议纪要Skill架构优化、需求文档质量提升、需求澄清Skill推广
|
||||
|
||||
**关键决策:**
|
||||
1. **会议纪要Skill架构优化方案:** 主窗口负责协调,每个子Agent获得全量上下文独立处理一个功能模块,放弃复杂的语义检索方案
|
||||
2. **会议纪要Skill必须参考会议转写更新项目进展状态:** 不能只依赖周报
|
||||
3. **需求文档不要罗列默认功能:** 只提炼核心难点需求,深度挖掘用户真实痛点
|
||||
4. **数字人项目第一阶段采用公开虚拟形象:** 不用个人数字人,简化开发难度
|
||||
5. **需求文档Skill增加专家博弈机制:** 采用多轮评审而非一次性评审
|
||||
6. **问答系统前端重构方案:** 采用Gemini或Claude,参考麦肯锡风格,生成整套设计方案
|
||||
7. **测试Skill的Skill需要开发自动化测试工具:** 提升Skill开发效率
|
||||
8. **使用cc-switch作为多模型终端管理工具:** 为未来部署国内模型做准备
|
||||
9. **不同任务使用不同模型优化:** 专家评审用Opus,简单处理用Sonnet
|
||||
10. **公众号信息获取项目等待富有确认需求后再继续:** 避免无效开发
|
||||
|
||||
**下周工作重点:**
|
||||
|
||||
1. 🔴 会议纪要Skill架构优化,简化为全量加载方案,提升准确性
|
||||
2. 🔴 需求澄清Skill 1.0版本推广,团队成员试用并反馈
|
||||
3. 🔴 数字人PPT需求文档重写,聚焦核心难点需求
|
||||
4. 问答系统V1.1前端重构方案完成
|
||||
5. 招投标文件Skill架构设计启动
|
||||
6. Cosmos文献综述流程整理(明天上午前完成)
|
||||
|
||||
---
|
||||
|
||||
**纪要整理人:** Claude
|
||||
**纪要时间:** 2025-11-25
|
||||
**下次会议:** 2025-12-02
|
||||
@ -0,0 +1,291 @@
|
||||
# 工程类会议纪要 (2025-12-09)
|
||||
|
||||
## 一、会议信息
|
||||
|
||||
- **会议时间:** 2025-12-09
|
||||
- **参会人员:** 连云波(主持)、闫旭隆、郝倩玉、陶西平、江争达
|
||||
- **记录整理:** Claude
|
||||
|
||||
---
|
||||
|
||||
## 二、工作内容
|
||||
|
||||
### 1. 重点项目进展情况汇总
|
||||
|
||||
| 项目名称 | 原负责人 | 原截止时间 | 项目进展情况 |
|
||||
| -------- | -------- | ---------- | ------------ |
|
||||
| 会议纪要Skill全量处理优化 | 闫旭隆、郝倩玉 | 2025-12-09 | 已完成初步对比测试,Gemini画面效果带来一些提升。存在问题:gemini视频上传限制(不能超过1小时、200MB)、清洗力度难以控制、主窗口上下文不够用(200KB文件需90kTokens)、Sub-agent并行写文件权限问题。**解决方案:** 1)使用Gemini进行清洗,Gemini上下文更大;2)压缩视频后再上传Gemini;3)尝试Gemini API直接生成;4)清洗后再用Claude做会议纪要 |
|
||||
| 数字人PPT视频样本生成 | 江争达、陶西平 | 2025-12-08 | 基本可用,已完成阶段一样本视频。存在问题:黑镜平台背景抠图有浅色阴影残留;数字人生成流程存在逻辑不自洽(上传真人视频训练+上传图片生成动作可能存在冗余);汇报表述不清。**解决方案:** 1)使用剪映等软件先抠背景再导入黑镜;2)测试直接用图片生成数字人模型,验证是否需要先录制绿幕视频;3)郝倩玉参与视频学习和制作 |
|
||||
| Gemini分镜脚本生成测试 | 江争达、陶西平 | 2025-12-09 | 已完成测试,但效果不理想。存在问题:VEO3使用中文prompt效果极差,模型不遵循指令;首尾帧使用相同图片导致视频无动作;对工具理解不够。**解决方案:** 1)必须使用英文prompt,VEO3对英文指令遵循度高;2)首尾帧需使用不同图片(如走动前后的姿态);3)学习网上优秀案例(YouTube、Twitter、Reddit) |
|
||||
| 问答系统V1.1前端重构 | 江争达、陶西平 | 2025-12-09 | 已完成前端代码重构,采用麦肯锡风格。存在问题:缺少需求文档、缺少目标定义、缺少问题分析;汇报逻辑混乱,直接展示"怎么做"而非"为什么做";代码生成后倒着补文档。**解决方案:** 1)补充完整需求文档(问题分析、目标定义、验收标准);2)遵循"Why-How-What"逻辑结构;3)需求文档不批准不准开发 |
|
||||
| 需求澄清Skill专家博弈优化 | 闫旭隆 | 2025-12-09 | 已完成。可视化结果及录制视频已完成,专家交叉回应的字段映射整理完毕 |
|
||||
| 投标商务应答自动生成系统Skill架构设计 | 郝倩玉、闫旭隆 | 2025-12-09 | 架构设计已完成,企业信息库建设存在困难。存在问题:企业信息库格式混乱(Excel、Word、PDF混杂);图片库来源分散缺少描述;保密信息处理问题;响应文件模板不统一。**解决方案:** 1)从最新招投标响应文件提取企业信息作为基础库;2)AI读取历史文件图片生成索引后让市场部审核标注;3)保密内容由市场部先筛选删除;4)周四客户交流后确定最终方案 |
|
||||
| Gartner报告解读转写Skill架构设计 | 郝倩玉、闫旭隆 | 2025-12-09 | 架构设计和可行性单元测试已完成。存在问题:翻译生硬(如"构建者"、"综合者"不符合信通院风格);AI痕迹明显缺乏专家观点;输出字数难以控制;图片处理尚未完成。**解决方案:** 1)允许意义转写而非忠实于原词;2)先提取每段要点总结再重新生成文章(抽骨架换血肉);3)使用NotebookLM做deep research后融合生成;4)抓紧测试API(额度快到期) |
|
||||
| 数字分身方案调研及方案撰写 | 郝倩玉 | 2025-12-09 | 进行中。发现市场上数字分身应用已比较成熟,需研究自研还是定制化定位。**解决方案:** 1)郝倩玉参与视频生成学习;2)探索黑镜、VEO3等工具的融合使用 |
|
||||
|
||||
### 2. 重点项目问题及解决方案
|
||||
|
||||
#### 问题1: 数字人视频生成流程存在逻辑不自洽问题
|
||||
|
||||
**问题描述:**
|
||||
当前数字人视频生成流程需要先录制绿幕视频训练数字人模型,再上传图片生成动作参考视频,最后生成口播视频。领导质疑这个流程的必要性,认为如果可以通过图片直接生成动作视频,为什么还需要先上传真人视频训练数字人模型,两个视频同时训练一个东西在逻辑上存在矛盾。另外,生成的视频存在背景抠不干净(有浅蓝/浅绿色阴影)的问题。
|
||||
|
||||
**解决方案:**
|
||||
|
||||
1. 测试直接用图片创建数字人专家,不拍摄绿幕视频,对比效果是否一致
|
||||
2. 使用剪映等外部软件先抠背景再导入黑镜平台,效果可能比黑镜自带抠图更好
|
||||
3. 删除现有专家账号重新测试流程,验证是否必须上传真人视频
|
||||
|
||||
**责任人:** 江争达、陶西平
|
||||
**截止时间:** 2025-12-16
|
||||
|
||||
#### 问题2: VEO视频生成工具使用不当导致效果差
|
||||
|
||||
**问题描述:**
|
||||
陶西平使用VEO Three生成分镜脚本视频时,使用中文prompt且首尾帧图片完全相同,导致生成的视频人物几乎不动,动作指令完全没有执行。对比领导用英文prompt生成的视频,手势动作完全按照指令执行。问题核心是:1)VEO Three对英文prompt的遵循效果远好于中文;2)首尾帧使用相同图片会导致视频没有动作变化;3)花了一周多时间但产出质量很差。
|
||||
|
||||
**解决方案:**
|
||||
|
||||
1. 必须使用英文prompt,VEO Three对英文指令遵循效果最好
|
||||
2. 首尾帧应使用不同的图片,比如尾帧图片应该是往前走两步后的状态
|
||||
3. 多学习网上其他人的使用经验,如YouTube、Twitter、Reddit上的VEO使用案例
|
||||
4. 重新用英文prompt制作视频
|
||||
|
||||
**责任人:** 陶西平
|
||||
**截止时间:** 2025-12-16
|
||||
|
||||
#### 问题3: 前端重构缺乏明确目标和需求文档
|
||||
|
||||
**问题描述:**
|
||||
江争达汇报前端重构工作时,PPT直接展示做成什么样,缺乏"为什么要重构"(Why)的分析。没有说明:1)前端具体存在哪些问题和案例;2)想要达成的目标是什么;3)理想的展示效果、交互体验是什么样的。领导严厉批评这种"没有需求文档就开发"、"先生成代码再倒回来补文档"的做法,认为这是思想懒惰的表现。
|
||||
|
||||
**解决方案:**
|
||||
|
||||
1. 先明确目标,说清楚想要什么样的效果,画出设计草图
|
||||
2. 整理前端代码存在的具体问题案例,分析代码扫描和人工智能读取后暴露的问题
|
||||
3. 按照"Why-How-What"的逻辑结构重新组织汇报材料
|
||||
4. 需求文档必须先批准才能开发,不准先开发再补文档
|
||||
5. 需求可以分阶段开发,但必须有整体的阶段设计,不能走一步看一步
|
||||
|
||||
**责任人:** 江争达
|
||||
**截止时间:** 2025-12-16
|
||||
|
||||
#### 问题4: 汇报表述不清晰、逻辑混乱
|
||||
|
||||
**问题描述:**
|
||||
多名成员在汇报时存在表述不清、逻辑混乱的问题。江争达解释数字人视频生成流程时反复说不清楚;陶西平解释VEO视频生成流程时也无法清晰表达是用首尾帧还是视频扩展。领导多次要求"你们回去好好学练习语文"。核心问题是无法用简洁明了的语言描述工作内容和技术流程。
|
||||
|
||||
**解决方案:**
|
||||
|
||||
1. 汇报前先理清思路,用一句话概括核心流程
|
||||
2. 练习表达能力,学会用简洁语言描述复杂流程
|
||||
3. 汇报时按照步骤一二三清晰说明,不要东一下西一下
|
||||
|
||||
**责任人:** 江争达、陶西平
|
||||
**截止时间:** 2025-12-16
|
||||
|
||||
#### 问题5: 工具使用能力不足,不会学习
|
||||
|
||||
**问题描述:**
|
||||
团队成员对AI工具(黑镜、VEO、Claude Code等)的使用能力不足,不会主动学习。领导指出:1)同样的工具在不同人手里效果完全不同,90分的工具用出50分都不到的效果;2)遇到问题不去网上搜索学习,而是闷头自己试;3)没有AI First的思维,不懂得利用AI来帮助分阶段、规划需求。
|
||||
|
||||
**解决方案:**
|
||||
|
||||
1. 多上网学习,看YouTube、Twitter、Reddit上别人的使用经验和案例
|
||||
2. 遇到问题先用Deep Research等工具搜索解决方案
|
||||
3. 利用多个AI工具(GPT、Claude、DeepSeek等)交叉验证和获取建议
|
||||
4. 不要自以为是,要AI First,从别人那里学习
|
||||
|
||||
**责任人:** 江争达、陶西平
|
||||
**截止时间:** 2025-12-16
|
||||
|
||||
#### 问题6: 报告转写规则和风格提取困难
|
||||
|
||||
**问题描述:**
|
||||
在做Gartner报告转写工作中,发现:1)转写后的英文翻译生硬(如"构建者"、"综合者"等不符合信通院用语习惯);2)AI痕迹明显,缺乏观点;3)风格规则难以精确提取,写多了约束可能偏,写少了表现不好;4)转写较忠实于原文用词,但信通院的专业术语和表达方式不同。
|
||||
|
||||
**解决方案:**
|
||||
|
||||
1. 先提取每段要点总结,再重新生成文章,相当于把骨架抽出来重新填充
|
||||
2. 不必完全忠实于原文英文词汇,可以进行意义转写
|
||||
3. 使用NotebookLM做Deep Research,融合相关资料后再写
|
||||
4. 请信通院专家来审核和调整专业术语
|
||||
5. 转写后需要有检查优化的流程
|
||||
|
||||
**责任人:** 闫旭隆
|
||||
**截止时间:** 2025-12-16
|
||||
|
||||
### 3. 下周工作安排
|
||||
|
||||
| 项目名称 | 负责人 | 下周会前目标 | 优先级 | 截止时间 |
|
||||
| -------- | ------ | ------------ | ------ | -------- |
|
||||
| 🔴 数字人视频生成流程优化测试 | 江争达 | 测试不使用绿幕视频直接用图片生成数字人的效果:删除现有专家数字人,直接上传图片生成动作视频,验证是否可以省略绿幕拍摄步骤。同时尝试用剪映等外部软件先抠图再导入黑镜平台 | P0 | 2025-12-16 |
|
||||
| 🔴 VEO3视频生成重新测试 | 陶西平 | 使用英文prompt重新测试VEO3视频生成功能,参考领导发送的英文prompt示例,确保指令执行效果。首尾帧需使用不同图片(如人物走动两步的图片) | P0 | 2025-12-16 |
|
||||
| 🔴 问答系统前端重构需求文档完善 | 江争达 | 需求文档必须包含:1)明确的目标和期望效果(包括UI草图/设计图);2)现有问题的具体案例分析(代码扫描结果、组件冗余示例);3)为什么要重构的充分论证;4)分阶段的需求规划设计。需求文档未批准前不准开发 | P0 | 2025-12-16 |
|
||||
| 🔴 视频制作学习与多模态工作流探索 | 郝倩玉 | 参与数字人视频的学习和制作,开通Gemini/API账号,探索如何将多模态能力(PPT生成、视频生成、图片编辑)融合到市场部工作中,形成高效的视频生产工作流 | P0 | 2025-12-16 |
|
||||
| 🔴 数字人演讲视频制作 | 江争达、陶西平 | 为领导制作数字人演讲视频用于即将到来的演讲场合。需要:领导提供一张图片和声音,以及演讲稿文字内容,团队负责生成完整的数字人演讲视频 | P0 | 2025-12-16 |
|
||||
| 🔴 会议纪要Skill全量处理优化 | 闫旭隆、郝倩玉 | 使用Gemini进行转写清洗,清洗后再用Claude做会议纪要;尝试压缩视频后上传Gemini;测试Gemini API直接生成 | P0 | 2025-12-16 |
|
||||
| 🔴 投标商务应答自动生成系统Skill架构设计 | 郝倩玉、闫旭隆 | 周四客户交流后确定最终方案,从最新招投标响应文件提取企业信息作为基础库 | P0 | 2025-12-16 |
|
||||
| 🔴 Gartner报告解读转写Skill架构设计 | 郝倩玉、闫旭隆 | 抓紧测试API(额度快到期),先提取每段要点总结再重新生成文章,使用NotebookLM做deep research后融合生成 | P0 | 2025-12-16 |
|
||||
| Gartner报告转写优化 | 郝倩玉 | 继续优化报告转写效果:1)考虑分段提取要点后重新生成文章;2)调整prompt允许意译而非直译;3)处理图片提取和匹配插入;4)优化英文术语的中文表达 | P1 | 2025-12-16 |
|
||||
| 知识库整理与管理 | 郝倩玉 | 接手知识库整理工作(从江争达处转交),系统化整理:1)市场部知识文档;2)云大哥相关知识;3)AIEC团队从成立至今的各类文档、文章、视频、会议纪要等 | P1 | 2025-12-16 |
|
||||
| 前端重构问题反思总结 | 江争达 | 整理并总结代码问题的典型案例:1)记录哪些具体问题导致需要重构;2)分析问题成因;3)形成经验教训文档供后续学习借鉴 | P1 | 2025-12-16 |
|
||||
| 数字分身方案调研及方案撰写 | 郝倩玉 | 继续调研市面上做得好的版本,研究自研还是定制化定位 | P1 | 2025-12-16 |
|
||||
|
||||
### 4. 组内成员工作进展
|
||||
|
||||
#### 闫旭隆
|
||||
|
||||
**上周完成:**
|
||||
|
||||
- ✅ 会议纪要Skill开发:生成市场部需求相关会议纪要、主窗口加载转写文本优化、三种方式对比测试
|
||||
- ✅ 需求澄清Skill专家博弈优化:可视化结果整理及录制视频
|
||||
- ✅ Skill-designer-v1开发完成
|
||||
- ✅ Gartner报告解读转写Skill架构设计及可行性单元测试
|
||||
- ✅ 投标商务应答自动生成系统Skill架构设计
|
||||
|
||||
**进行中:**
|
||||
|
||||
- 🔄 会议纪要Skill全量处理优化(Gemini清洗方案测试)
|
||||
- 🔄 Gartner报告转写优化(API测试)
|
||||
|
||||
**收到的反馈/学习建议:**
|
||||
|
||||
- **建议:** 会议纪要skill技术选型基本确定,接下来是优化工作。建议把相关流程、需求、开发文档管理起来,形成1.0版本发布
|
||||
- **建议:** gemini视频上传问题建议尝试视频压缩,因为大量静止画面编码可以压缩;另外可以调用API而非界面端,稳定性会更高
|
||||
- **建议:** 清洗工作交给gemini处理更合适,因为gemini上下文更大;清洗后再用Claude做会议纪要
|
||||
- **建议:** skill开发设计时,建议先画一个大逻辑框架图,把大的模块架构先理清楚
|
||||
- **表扬:** 在自动化方向上的探索尝试是值得鼓励的,但现在是一步一步完善,不要期望一步到位
|
||||
- **建议:** Gartner报告转写skill需要考虑长上下文处理问题,单份报告可以拆开一段一段翻,把上一段翻译压缩后作为下一段的上下文
|
||||
|
||||
**下周任务:**
|
||||
|
||||
- [ ] 🔴 P0|会议纪要Skill全量处理优化
|
||||
- [ ] 🔴 P0|Gartner报告解读转写Skill架构设计(API测试)
|
||||
- [ ] 🔴 P0|投标商务应答自动生成系统Skill架构设计
|
||||
- [ ] P1|Claude Code需求文档-Skill套壳Web前端交互测试
|
||||
|
||||
#### 郝倩玉
|
||||
|
||||
**上周完成:**
|
||||
|
||||
- ✅ 会议纪要Skill架构优化(协助旭隆优化学习类+Q&A类会议纪要Skill逻辑)
|
||||
- ✅ Gartner报告解读转写Skill架构设计
|
||||
- ✅ 投标商务应答自动生成系统Skill架构设计(和开发人员讨论需求细节)
|
||||
- ✅ 数字分身方案调研
|
||||
|
||||
**进行中:**
|
||||
|
||||
- 🔄 投标商务应答自动生成系统需求待明确(市场部反馈需求可能会变)
|
||||
- 🔄 数字分身方案撰写
|
||||
|
||||
**收到的反馈/学习建议:**
|
||||
|
||||
- 无
|
||||
|
||||
**下周任务:**
|
||||
|
||||
- [ ] 🔴 P0|视频制作学习与多模态工作流探索
|
||||
- [ ] 🔴 P0|会议纪要Skill全量处理优化
|
||||
- [ ] 🔴 P0|投标商务应答自动生成系统Skill架构设计
|
||||
- [ ] 🔴 P0|Gartner报告解读转写Skill架构设计
|
||||
- [ ] P1|Gartner报告转写优化
|
||||
- [ ] P1|知识库整理与管理
|
||||
- [ ] P1|数字分身方案调研及方案撰写
|
||||
|
||||
#### 陶西平
|
||||
|
||||
**上周完成:**
|
||||
|
||||
- ✅ 数字人PPT视频样本生成:完成数字人阶段一的样本视频
|
||||
- ✅ 数字人与ppt结合:完成数字人讲解PPT视频生成步骤文档
|
||||
- ✅ Gemini分镜脚本生成测试:完成veo3.1调研结果文档
|
||||
|
||||
**进行中:**
|
||||
|
||||
- 🔄 VEO3视频生成优化(需用英文prompt重新测试)
|
||||
|
||||
**收到的反馈/学习建议:**
|
||||
|
||||
- **批评:** VEO Three工具使用错误:使用中文prompt,而VEO Three根本不认中文prompt,至少需要八个英文单词才能启动,导致prompt完全没有起作用,生成的视频动作和节奏完全没有执行指令
|
||||
- **批评:** 汇报表述不清:无法用简洁的语言说清楚工作流程,领导多次追问才能理解其工作内容,被批评"回去好好学练习语文"
|
||||
- **批评:** 工作方式偷懒:使用同一张图片同时作为首帧和尾帧生成视频,被批评为"把偷懒发挥到极致"、"完全不动脑子工作的最新最高境界"
|
||||
- **批评:** 工作效率低下:一整周时间都在做数字人视频,结果却不理想,被批评"效率太低了"
|
||||
- **建议:** 使用英文prompt:VEO Three需要英文prompt才能正常工作,应参考领导发送的示例提示词进行学习和改进
|
||||
|
||||
**下周任务:**
|
||||
|
||||
- [ ] 🔴 P0|VEO3视频生成重新测试(英文prompt)
|
||||
- [ ] 🔴 P0|数字人演讲视频制作
|
||||
- [ ] P1|继续推进数字人讲解ppt视频
|
||||
|
||||
#### 江争达
|
||||
|
||||
**上周完成:**
|
||||
|
||||
- ✅ 问答系统V1.1前端重构:前端采用麦肯锡风格进行重构
|
||||
- ✅ 数字人PPT视频样本生成:完成样本生成,完成制作步骤和费用分析
|
||||
- ✅ Gemini分镜脚本生成测试:指导西平完成测试
|
||||
|
||||
**进行中:**
|
||||
|
||||
- 🔄 问答系统前端重构需求文档完善(缺少Why和目标定义)
|
||||
- 🔄 服务器采购
|
||||
|
||||
**收到的反馈/学习建议:**
|
||||
|
||||
- **批评:** 逻辑表达不清晰,思维混乱。在汇报数字人视频技术方案时,领导多次指出"你脑子就是乱的"、"东一下西一下的"、"逻辑全变了",要求其先理清思路再表达
|
||||
- **批评:** 对底层技术理解不透彻。关于黑镜数字人生成流程,领导指出"你们对黑镜根本没有了解清楚",质疑为什么需要先拍绿幕视频训练模型再用图片生成参考视频的必要性
|
||||
- **批评:** Cloud Code的PDF Skill功能没有研究透。领导明确指出"你们还没研究透它的PDF",要求深入研究PDF处理能力
|
||||
- **批评:** 前端重构缺乏明确目标和需求文档。领导严厉批评"你这不叫需求文档,你这叫开发动机"、"你连目标都不清楚,你能做出个需求文档出来"、"需求文档不批准的时候不准开发"
|
||||
- **批评:** 汇报缺乏案例支撑,只有空洞描述。领导指出"你缺乏案例展示别人是没有直观感觉的",要求展示具体的代码问题案例
|
||||
- **批评:** 先开发后补文档的做法错误。领导强烈反对"先生成代码再回头补文档"的做法,认为这是"糊弄鬼",明确表示"如果没有需求文档去开发以后就不要干了"
|
||||
- **批评:** 工具使用方法有问题。当说让AI严格按接口规范生成17个接口结果只生成9个时,领导指出"说明你一次生成17个是错的,你工具不会使用"
|
||||
- **批评:** 问答系统前端重构的PPT汇报逻辑混乱。领导评价"上来就是HOW,不是这样的,是WHY",批评缺少为什么要做这个决策的分析
|
||||
- **建议:** 需要从问题中吸取经验教训。领导建议"把这些问题找出来",分析为什么会出现不规范的现象,结果是因为之前什么原因造成的
|
||||
- **建议:** 汇报应该有完整的逻辑链条。需要先说明"饿不饿"(为什么要做),再说"吃什么"(怎么做),而不是上来就讲具体操作
|
||||
- **建议:** 前端设计需要先画草图和交互逻辑图
|
||||
- **建议:** 数字人视频流程需要验证是否真正需要拍摄绿幕。领导建议测试直接用图片生成动作视频,如果效果差不多,"那证明前面这个绿幕你们就是脱裤子放屁"
|
||||
- **建议:** Gemini API额度快到期(还剩一天),需要抓紧时间测试报告转写功能
|
||||
|
||||
**下周任务:**
|
||||
|
||||
- [ ] 🔴 P0|数字人视频生成流程优化测试
|
||||
- [ ] 🔴 P0|问答系统前端重构需求文档完善
|
||||
- [ ] 🔴 P0|数字人演讲视频制作
|
||||
- [ ] P1|前端重构问题反思总结
|
||||
- [ ] P1|服务器采购
|
||||
|
||||
---
|
||||
|
||||
## 三、会议总结
|
||||
|
||||
**核心议题:** 数字人视频生成、VEO3视频测试、问答系统前端重构、Gartner报告转写
|
||||
|
||||
**关键决策:**
|
||||
|
||||
1. **需求文档不批准时不准开发:** 针对江争达前端重构项目,领导明确指出在需求文档没有明确目标、没有经过批准之前,不允许进行开发工作
|
||||
2. **数字人视频工作流需要重新测试优化:** 针对黑镜平台数字人视频生成流程,要求测试直接用图片生成数字人模型是否可行,如果效果相同则绿幕录制步骤是多余的
|
||||
3. **VEO视频生成必须使用英文prompt:** VEO对中文prompt执行效果很差,必须使用英文prompt才能获得好的指令遵循效果
|
||||
4. **视频生成工作由郝倩玉参与学习和制作:** 考虑到视频将成为市场部重要方向,决定让郝倩玉加入视频学习和制作工作
|
||||
5. **知识库整理工作从江争达转交给郝倩玉统一负责:** 系统化整理市场部知识、云大哥知识、AIEC团队各类文档
|
||||
6. **需求可以分阶段开发,但不代表需求没有阶段设计:** 可以把所有需求都设计出来,然后分段开发,而不是想到多少算多少
|
||||
7. **转写报告风格规则需要调整,不完全忠于原文:** 可以进行意义转写,更重要的是保持逻辑框架和数据引用的准确性
|
||||
8. **采用先提取每段要点再重新生成的工作流:** 针对报告转写的优化方案,先做每一段要点的总结,把骨架抽出来,然后基于骨架重新生成文章
|
||||
|
||||
**下周工作重点:**
|
||||
|
||||
1. 🔴 数字人视频生成流程优化测试,验证是否需要拍摄绿幕视频
|
||||
2. 🔴 VEO3视频生成重新测试,使用英文prompt
|
||||
3. 🔴 问答系统前端重构需求文档完善,补充Why和目标定义
|
||||
4. 🔴 视频制作学习与多模态工作流探索(郝倩玉)
|
||||
5. 🔴 数字人演讲视频制作
|
||||
6. 🔴 会议纪要Skill全量处理优化,使用Gemini进行清洗
|
||||
7. 🔴 投标商务应答自动生成系统Skill架构设计,周四客户交流后确定方案
|
||||
8. 🔴 Gartner报告解读转写Skill架构设计,抓紧测试API
|
||||
|
||||
---
|
||||
|
||||
**纪要整理人:** Claude
|
||||
**纪要时间:** 2025-12-09
|
||||
**下次会议:** 2025-12-16
|
||||
Reference in New Issue
Block a user