添加-会议纪要skill-v0.5，索引版本
This commit is contained in:
闫旭隆
11
.claude/settings.local.json
Normal file
11
.claude/settings.local.json
Normal file
@ -0,0 +1,11 @@
|
||||
{
|
||||
"permissions": {
|
||||
"allow": [
|
||||
"Bash(ls:*)",
|
||||
"Skill(meeting-minutes-generator-v1)"
|
||||
],
|
||||
"additionalDirectories": [
|
||||
"C:\\Users\\10120\\.claude\\agents"
|
||||
]
|
||||
}
|
||||
}
|
||||
279
.claude/skills/CLAUDE.md
Normal file
279
.claude/skills/CLAUDE.md
Normal file
@ -0,0 +1,279 @@
|
||||
# Claude Code Skill 规范开发指南
|
||||
|
||||
本指南融合官方 skill-creator 指南与实践经验,为 Skill 开发提供完整的方法论和最佳实践。
|
||||
|
||||
## 一、Skill 基础概念
|
||||
|
||||
### 1.1 什么是 Skill
|
||||
|
||||
Skill 是模块化的自包含包,通过提供专业化知识、工作流程和工具来扩展 Claude 的能力。将 Skill 视为特定领域或任务的"入职指南"——它们将 Claude 从通用代理转变为配备了模型无法完全拥有的程序性知识的专业代理。
|
||||
|
||||
### 1.2 Skill 提供的能力
|
||||
|
||||
1. **专业化工作流** - 特定领域的多步骤过程
|
||||
2. **工具集成** - 处理特定文件格式或 API 的指令
|
||||
3. **领域专业知识** - 公司特定知识、模式、业务逻辑
|
||||
4. **捆绑资源** - 用于复杂和重复任务的脚本、参考资料和资源
|
||||
|
||||
### 1.3 渐进式披露原则
|
||||
|
||||
Skill 使用三级加载系统高效管理上下文:
|
||||
|
||||
1. **元数据(name + description)** - 始终在Claude code主窗口的上下文中(~100 词)
|
||||
2. **SKILL.md 主体** - 当 Skill 触发时(<3k 词)
|
||||
3. **捆绑资源** - 根据 Claude 需要加载(脚本可以在不读入上下文窗口的情况下执行)
|
||||
|
||||
## 二、Skill 目录结构
|
||||
|
||||
### 2.1 标准结构
|
||||
|
||||
```
|
||||
skill-name/
|
||||
├── SKILL.md (必需)
|
||||
│ ├── YAML frontmatter 元数据(必需)
|
||||
│ │ ├── name: (必需)
|
||||
│ │ └── description: (必需)
|
||||
│ └── Markdown 指令(必需)
|
||||
└── 捆绑资源(可选)
|
||||
├── scripts/ - 可执行代码(Python/Bash 等)
|
||||
├── references/ - 详细执行指南、领域知识、复杂流程说明(供按需查阅)
|
||||
├── assets/ - 项目类型配置、业务规则等数据性文件
|
||||
├── templates/ - 文档模板、输出格式模板
|
||||
├── examples/ - 示例文档、参考案例(不在执行时加载)
|
||||
└── temp/ - Agent 间传递数据的临时文件
|
||||
```
|
||||
|
||||
### 2.2 各目录职责
|
||||
|
||||
#### SKILL.md (必需)
|
||||
|
||||
- **元数据**: YAML frontmatter 中的 `name` 和 `description` 决定 Skill 触发时机,使用第三人称描述
|
||||
- **内容**: 只包含执行流程概要、关键步骤、必要的调用格式
|
||||
- **风格**: 使用祈使/不定式形式(如 "To accomplish X, do Y"),客观指导性语言
|
||||
|
||||
#### scripts/ (可选)
|
||||
|
||||
- **用途**: 确定性可靠的可执行代码,不依赖 Claude Code 能力
|
||||
- **优势**: Token 高效,可不加载到上下文直接执行
|
||||
- **适用**: 重复编写的相同代码
|
||||
|
||||
#### references/ (可选)
|
||||
|
||||
- **用途**: 详细执行指南、领域知识、复杂流程说明,按需加载
|
||||
- **最佳实践**: 大文件(>10k 词)在 SKILL.md 中提供 grep 搜索模式
|
||||
- **避免重复**: 详细信息放这里,核心精要放 SKILL.md
|
||||
|
||||
#### assets/ (可选)
|
||||
|
||||
- **用途**: 配置、业务规则等数据文件,用于输出而非加载到上下文
|
||||
- **示例**: 模板、图标、样板代码、字体
|
||||
|
||||
#### templates/ (可选)
|
||||
|
||||
- **用途**: 文档模板、输出格式模板
|
||||
|
||||
#### examples/ (可选)
|
||||
|
||||
- **用途**: 示例文档、参考案例,供用户参考,不在执行时加载
|
||||
|
||||
#### temp/ (可选)
|
||||
|
||||
- **用途**: Agents 间数据交换的临时文件
|
||||
|
||||
## 三、Skill 创建流程
|
||||
|
||||
### 步骤 1: 理解 Skill 使用场景
|
||||
|
||||
通过用户示例或验证的生成示例,理解 Skill 的具体使用方式。
|
||||
|
||||
**关键问题**:
|
||||
|
||||
- Skill 应支持什么功能?
|
||||
- 典型使用示例有哪些?
|
||||
- 什么样的用户请求应触发此 Skill?
|
||||
|
||||
**目标**: 对 Skill 应支持的功能有清晰认识。
|
||||
|
||||
### 步骤 2: 规划可重用资源
|
||||
|
||||
分析示例,识别可重用的资源:
|
||||
|
||||
**分析方法**:
|
||||
1. 考虑如何从头执行示例
|
||||
2. 识别重复执行时需要的脚本、详细的参考资料和资源
|
||||
|
||||
**示例**:
|
||||
- **pdf-editor**: 旋转 PDF 需重写代码 → `scripts/rotate_pdf.py`
|
||||
- **webapp-builder**: 前端样板重复使用 → `assets/hello-world/` 模板
|
||||
- **big-query**: 表模式需重复查询的详细指南 → `references/schema.md`
|
||||
|
||||
**输出**: 可重用资源列表 (scripts/references/assets)。
|
||||
|
||||
### 步骤 3: 初始化 Skill
|
||||
|
||||
运行 `init_skill.py` 脚本创建新 Skill 目录和模板:
|
||||
|
||||
```bash
|
||||
scripts/init_skill.py <skill-name> --path <output-directory>
|
||||
```
|
||||
|
||||
自动生成 SKILL.md 模板和示例资源目录,然后根据需要自定义或删除。
|
||||
|
||||
### 步骤 4: 编辑 Skill
|
||||
|
||||
**原则**: 专注于对 Claude 有益且非显而易见的信息。
|
||||
|
||||
#### 4.1 实现可重用资源
|
||||
|
||||
实现步骤 2 识别的 `scripts/`、`references/` 和 `assets/` 文件,可能需要用户提供素材。删除不需要的示例文件。
|
||||
|
||||
#### 4.2 编写 SKILL.md
|
||||
|
||||
**风格**: 祈使/不定式形式,客观指导性语言。
|
||||
|
||||
**内容**:
|
||||
|
||||
1. Skill 的目的(几句话)
|
||||
2. 触发时机
|
||||
3. 使用方法(引用所有可重用资源)
|
||||
|
||||
### 步骤 5: 迭代优化
|
||||
|
||||
实际使用 → 发现问题 → 更新资源 → 测试验证
|
||||
|
||||
## 四、多 Agents 协作最佳实践
|
||||
|
||||
### 4.1 Agents 创建准则
|
||||
|
||||
#### 4.1.1 Agent 定义位置
|
||||
|
||||
Agents 在全局 `.claude/agents/` 目录下创建,每个 agent 一个独立的 markdown 文件:
|
||||
|
||||
```
|
||||
.claude/
|
||||
└── agents/
|
||||
├── req_interviewer.md
|
||||
├── pm_reviewer.md
|
||||
└── domain_expert_reviewer.md
|
||||
```
|
||||
|
||||
**Agent 文件结构**:
|
||||
|
||||
```markdown
|
||||
---
|
||||
name: agent_name
|
||||
description: Agent 的简要描述和触发时机
|
||||
---
|
||||
|
||||
# Agent 名称
|
||||
|
||||
## 职责
|
||||
|
||||
[agent 的核心职责描述]
|
||||
|
||||
## 固化规则
|
||||
|
||||
[agent 内部固化的执行规则、工具使用规范、评估标准]
|
||||
|
||||
## 工作流程
|
||||
|
||||
1. [步骤1]
|
||||
2. [步骤2]
|
||||
...
|
||||
|
||||
## 输入参数
|
||||
|
||||
- 参数1: [说明,通常是标识符或文件路径]
|
||||
- 参数2: [说明]
|
||||
|
||||
## 输出格式
|
||||
|
||||
- **推荐**: 直接返回完整结果文字
|
||||
- **备选**: 结果极大时写入 `temp/` 文件并返回路径
|
||||
|
||||
## 可用工具
|
||||
|
||||
[列出 agent 可使用的工具]
|
||||
```
|
||||
|
||||
**SKILL.md 中引用 Agents**:
|
||||
|
||||
在 SKILL.md 中通过 Task tool 调用已定义的 agents,使用 `subagent_type` 参数指定 agent 名称。
|
||||
|
||||
#### 4.1.2 Agent 设计原则
|
||||
|
||||
**自治性**:
|
||||
|
||||
- Agent 内部固化所有执行规则、工具使用规范、评估标准
|
||||
- 配置文件由 Agent 自己读取,不依赖主窗口传递
|
||||
- 业务逻辑在 Agent 定义中完整描述
|
||||
|
||||
**职责单一**:
|
||||
|
||||
- 每个 Agent 只负责一个明确的任务阶段
|
||||
- 避免创建"万能 Agent",职责重叠会导致混乱
|
||||
|
||||
**数据自给**:
|
||||
- Agent 的行为准则应在自己的定义md文件中写定，必要时从 `references/` 或 `assets/` 读取所需配置
|
||||
- 主窗口只传递标识符(如项目类型)和文件路径
|
||||
|
||||
#### 4.1.3 Agent 命名规范
|
||||
|
||||
- 使用 `snake_case` 命名: `req_interviewer`, `domain_expert_reviewer`
|
||||
- 名称应体现职责: `{角色}_{动作}` 或 `{领域}_{专家}`
|
||||
- 避免泛化名称: 用 `pm_reviewer` 而非 `reviewer1`
|
||||
|
||||
### 4.2 主窗口职责
|
||||
|
||||
**定位**: 主窗口是流程协调者,不是数据中转站。
|
||||
|
||||
**职责**:
|
||||
- 只传递协调必要信息(如项目类型标识符、文件路径)
|
||||
- 不传递 agents 的行为规则、配置内容或完整数据
|
||||
- 根据工作流程依次调用 agents
|
||||
- 汇总 agents 返回的概要信息呈现给用户
|
||||
|
||||
### 4.3 数据传递优化
|
||||
|
||||
**主窗口 → agents**:
|
||||
- 主窗口只给 Agent 传递必须的、需要从主窗口上下文获取到的信息精要或标识符
|
||||
- agents 的行为规范或详细指南(不依赖主窗口上下文的)应该在 Agent 内部固化写入,不应依赖主窗口通过 prompt 传递
|
||||
|
||||
**agents → 主窗口**:
|
||||
- **推荐**: 直接通过 prompt 返回完整文字结果(高效)
|
||||
- **备选**: 结果极大时才写入 `temp/` 文件(需在主窗口 prompt 中提示读取)
|
||||
|
||||
**agents → agents**:
|
||||
|
||||
- 通过 `temp/` 文件传递数据
|
||||
- 主窗口只传文件路径,作为协调的中转站
|
||||
|
||||
**核心原则**: 主窗口传标识符,Agent 读详细配置;Agent 间传文件路径;Agent 向主窗口直接返回文字。
|
||||
|
||||
## 五、SKILL.md 设计最佳实践
|
||||
|
||||
### 5.1 渐进式披露与信息组织
|
||||
|
||||
**SKILL.md 只包含**:
|
||||
- 执行流程概要
|
||||
- 关键步骤
|
||||
- 必要的调用格式
|
||||
|
||||
**详细内容分类**:
|
||||
- 复杂执行细节 → `references/`
|
||||
- 示例案例 → `examples/`
|
||||
- 配置数据 → `assets/`
|
||||
- 输出模板 → `templates/`
|
||||
|
||||
**信息分配原则**(避免重复):
|
||||
1. 核心工作流指导 → SKILL.md
|
||||
2. 详细参考材料 → references/
|
||||
3. 配置和数据 → assets/
|
||||
4. 输出模板 → templates/
|
||||
|
||||
**效果**: 保持 SKILL.md 精简清晰,详细信息按需加载。
|
||||
|
||||
## 六、参考资源
|
||||
|
||||
- [代理技能 - Claude Code Docs](https://code.claude.com/docs/en/skills?utm_source=chatgpt.com)
|
||||
- [Claude Agent Skills: A First Principles Deep Dive](https://leehanchung.github.io/blogs/2025/10/26/claude-skills-deep-dive/)
|
||||
Binary file not shown.
@ -0,0 +1,283 @@
|
||||
# 会议纪要_工程部分(2025-11-18)
|
||||
|
||||
## 一、会议信息
|
||||
|
||||
- **会议时间:** 2025-11-18
|
||||
- **参会人员:** 连云波(主持)、江争达、闫旭隆、陶西平、郝倩玉、刘志豪
|
||||
- **请假人员:** 无
|
||||
|
||||
---
|
||||
|
||||
## 二、工作内容
|
||||
|
||||
### 1. 重点项目进展(上周回顾)
|
||||
|
||||
| 项目名称 | 负责人 | 截止时间 | 项目进展情况 |
|
||||
|---------|--------|----------|---------|
|
||||
| 会议纪要流程文档和现场测试 | 江争达/郝倩玉 | 11月18日 | 现场演示暴露严重质量问题:P0项目数量错误(4个显示2个)、合并逻辑不可控、P0定义错误,闫旭隆/连云波接手 |
|
||||
| 公众号/网站信息获取优化和新需求开发 | 江争达/陶西平/刘志豪 | 11月15日 | 上周无进展,需求对接环节停滞,需求文档流转混乱、原始需求缺失,已转交郝倩玉统一负责 |
|
||||
| 服务器选型方案 | 江争达 | 11月15日 | 方案存在严重逻辑混乱和前后矛盾问题,直接购买铭凡MS-S1 MAX(14999元) |
|
||||
| 开发规范-需求文档生成Skill | 连云波/闫旭隆 | 11月18日 | 闫旭隆完成1.0版本,整体框架获认可,需优化：sub_agent内部Prompt臃肿、交互时间和生成的领域专家 |
|
||||
| DeepResearch框架讨论 | 连云波/闫旭隆/刘志豪 | 11月15日 | 框架讨论完成,安定医院方第一阶段聚焦文献研究和假设生成，首先确定需求文档后讨论，做一个最小通用的deepresearch-skill |
|
||||
| 客户风险推送需求文档 | 江争达/郝倩玉 | 11月18日 | 已完成测试和部署,采用天眼查方案,通过隔天换名单解决500/1000企业监测限制 |
|
||||
| 发票处理需求文档 | 江争达/郝倩玉 | 11月18日 | 需求、开发、使用文档均已完成并部署,基于Python脚本实现,反馈基本满意 |
|
||||
|
||||
### 2. 会议重点问题及解决方案
|
||||
|
||||
#### 问题1: 会议纪要流程开发规范违规及质量问题
|
||||
|
||||
**问题描述:**
|
||||
江争达在没有需求文档的情况下就开始开发,违反了多次强调的开发规范。现场演示暴露严重问题:
|
||||
|
||||
- 闫旭隆周报中2个P0项目,会议仪表盘显示了4个,存在漏项
|
||||
- P0项目合并逻辑不清晰,大模型自动合并无法确认是否可控
|
||||
- 个人工作内容中P0项目重复或分类错误
|
||||
- 周报提取质量问题,详细工作内容未标明优先级导致P0项目识别错误
|
||||
- P0项目定义错误:将"下周规划要完成的"都标为P0,但P0应该是"无论如何都要完成的重大战略性任务"
|
||||
|
||||
**解决方案:**
|
||||
|
||||
1. 必须编写需求文档,所有P0项目开发前必须有需求文档(面向用户+面向大模型两类)
|
||||
2. 保留工作过程和原始版本,不要只提交结果,便于复盘和改进
|
||||
3. 建立周报、日报、会议仪表盘的完整生成流程文档
|
||||
4. 在详细工作内容中标明任务优先级(P0/P1/P2),避免映射错误
|
||||
5. 学习项目管理知识,理解P0项目的正确定义
|
||||
6. 建立前后校验机制,确保数据一致性
|
||||
|
||||
**责任人:** 闫旭隆、连云波
|
||||
**截止时间:** 2025-11-25
|
||||
|
||||
#### 问题2: 公众号需求对接流转混乱
|
||||
|
||||
**问题描述:**
|
||||
需求文档有两个版本:刘志豪写的"面向大模型"版本不可用于与用户确认,陶西平生成的"面向用户"版本缺少原始需求记录。刘志豪周五请假,江争达无法对接原始需求导致工作停滞。工作交接不清晰,没有追根到底确认原始需求文档。
|
||||
|
||||
**解决方案:**
|
||||
|
||||
1. 明确由郝倩玉负责所有市场部需求对接(包括会议纪要需求),没有郝倩玉确认的需求任何人不准开发
|
||||
2. 郝倩玉需要找刘志豪要原始需求(富有最初提的三条需求:多层分级、人事变动、每周考核汇总)
|
||||
3. 整合需求1.0文档 + 新提需求 + 信息聚合会议需求
|
||||
4. 生成可用的需求文档(面向用户可理解、面向大模型可开发)
|
||||
5. 下周过一遍需求文档和开发文档
|
||||
6. 江争达配合郝倩玉完成开发文档
|
||||
|
||||
**责任人:** 郝倩玉、江争达、陶西平、刘志豪
|
||||
**截止时间:** 2025-11-25(下周会议审核需求和开发文档)
|
||||
|
||||
#### 问题3: 服务器选型方案逻辑混乱不可用
|
||||
|
||||
**问题描述:**
|
||||
江争达汇报的服务器选型方案存在严重问题:
|
||||
- 没有总体规划文档,直接分成三个独立方案,缺少整体需求和分类说明
|
||||
- 前后矛盾:软件需求要求CUDA驱动,但推荐的英伟达/名牌服务器不支持X86架构和标准CUDA
|
||||
- 需求冲突:要求小型尺寸(家用主机)但又要扩展性,自组装没有扩展性
|
||||
- 噪音问题:5090显卡长时间运行噪音大,不适合办公环境
|
||||
- 显存不足:16GB显存只是最低要求,上下文一加载就不够用
|
||||
- 缺少基础知识:不理解MoE模型、高带宽内存、内存带宽瓶颈等底层机制
|
||||
|
||||
**解决方案:**
|
||||
|
||||
1. 江争达退出服务器选型工作
|
||||
2. 直接购买铭凡MS-S1 MAX服务器,领导已看过10+测评视频
|
||||
|
||||
**责任人:** 连云波、江争达
|
||||
**截止时间:** 待定
|
||||
|
||||
#### 问题4: 需求文档-skill待优化
|
||||
|
||||
**问题描述:**
|
||||
当前需求文档的skill存在交互时间过长、输出报告冗余过多、领域专家生成不准确、sub_agent内部提示词臃肿等问题。
|
||||
|
||||
**解决方案:**
|
||||
|
||||
1. 规范输出报告模板，从模板上避免冗余
|
||||
2. 增强最后重复校验机制，避免生成报告冗余过多
|
||||
3. 生成领域专家提示词改进，增加一个AI专家角色
|
||||
4. 可以在sub_agent内部增加使用web_search的提示词
|
||||
5. 精简sub_agent内部提示词
|
||||
6. 在专家评审阶段之后增加用户选项：由专家直接汇总/由用户确认，节省用户操作时间
|
||||
7. 增加一个向Claude code提问该问题的功能
|
||||
|
||||
**责任人:** 闫旭隆
|
||||
**截止时间:** 2025-11-25
|
||||
|
||||
#### 问题5: 客户风险推送企业监测数量限制
|
||||
|
||||
**问题描述:**
|
||||
天眼查账户只支持500个企业监测,但需求是1000个企业监测。
|
||||
|
||||
**解决方案:**
|
||||
|
||||
1. 采用更换500个企业名单方案(通过批量导入模板)
|
||||
2. 使用定时任务自动换名单
|
||||
3. 可以通过浏览器自动化,实现自动换名单
|
||||
4. 推送频率建议:2天一次,避免被认为是"钻漏洞"
|
||||
|
||||
**责任人:** 江争达/郝倩玉
|
||||
**截止时间:** 2025-11-22(本周内)
|
||||
|
||||
### 3. 下周工作安排
|
||||
|
||||
| 项目名称 | 负责人 | 本周目标 | 优先级 | 截止时间 |
|
||||
| ---------------------------------------- | -------------------- | --------------------------- | ------ | -------- |
|
||||
| 会议纪要流程文档和现场测试 | 连云波/郝倩玉/闫旭隆 | 完善需求文档,建立标准模板和校验机制，编写Skill | P0 | 2025-11-25 |
|
||||
| 公众号/网站信息获取优化和新需求开发 | 郝倩玉/江争达/陶西平/刘志豪 | 确认需求文档,完成开发文档,准备开发 | P0 | 2025-11-25 |
|
||||
| 数字人需求文档 | 江争达 | 整理需求文档 | P0 | 2025-11-25 |
|
||||
| 需求澄清Skill优化 | 闫旭隆 | 根据会上建议改进skill设计以及最后的需求文档质量 | P0 | 持续优化 |
|
||||
| DeepResearch文献研究模块开发 | 连云波/闫旭隆/刘志豪 | 生成安定医院方的需求文档，制作deepresearch最小流程通用skill | P1 | 明天启动会后 |
|
||||
| 招投标文件Skill开发 | 郝倩玉/闫旭隆 | 需求确认 | P1 | 明天启动会后 |
|
||||
| 客户风险推送自动化 | 江争达/郝倩玉 | 确认切换采集监控用户方案 | P1 | 2025-11-25 |
|
||||
| 服务器选型方案 | 连云波、江争达 | 尽快采购 | P1 | 待定 |
|
||||
| 问答系统V1.1问题跟踪 | 江争达/闫旭隆/陶西平 | 持续优化 | P1 | 持续优化 |
|
||||
| RAG参数优化和PDF转换智能体(会议未讨论) | 闫旭隆/江争达 | | | |
|
||||
|
||||
### 4. 组内成员工作进展
|
||||
|
||||
#### 江争达
|
||||
|
||||
**上周完成:**
|
||||
|
||||
- ✅ 会议纪要模板初步开发(周报、日报模板设计、会议仪表盘初步生成)
|
||||
|
||||
**进行中:**
|
||||
- 🔄 会议纪要需求文档编写(重新规范)
|
||||
- 🔄 公众号需求文档协助(转交郝倩玉主导)
|
||||
- 🔄 服务器选型(已退出,转交领导)
|
||||
|
||||
**收到的反馈/学习建议:**
|
||||
- 严厉批评:没有需求文档就开发,违反基本规范
|
||||
- 工作质量不负责,自检流于形式
|
||||
- P0项目定义错误,缺少项目管理知识:P0是"无论如何都要完成的战略任务",不是"计划完成的任务"
|
||||
- 缺少工作流程记录,无法追溯问题
|
||||
- 服务器选型方案逻辑混乱,基础知识不扎实(不理解MoE模型、高带宽内存、内存带宽瓶颈等)
|
||||
- 需求文档要分两类:面向用户的(人能看懂)和面向大模型的(用于开发)
|
||||
- 需求文档是"需求草稿",只有用户确认后才能标记为"需求文档已完成"
|
||||
|
||||
**下周任务:**
|
||||
|
||||
- [ ] P0｜完成数字人需求文档
|
||||
- [ ] P0｜配合郝倩玉完成公众号开发文档
|
||||
- [ ] P1 | 确认客户风险推送自动化系统切换采集监控用户方案
|
||||
- [ ] P1 | 确认服务器采购时间
|
||||
- [ ] P1｜问答系统V1.1问题分析和优化(会议未讨论)
|
||||
|
||||
#### 闫旭隆
|
||||
|
||||
**上周完成:**
|
||||
|
||||
- ✅ 需求澄清Skill 1.0版本开发
|
||||
- ✅ Claude Code Skill开发规范检查skill制作及经验分享
|
||||
- ✅ DOCX文件操作技术方案验证(占位符方法)
|
||||
|
||||
**进行中:**
|
||||
|
||||
- 🔄 需求澄清Skill优化(精简Prompt、减少交互时间.......)
|
||||
- 🔄 最小模块DeepResearch需求文档
|
||||
|
||||
**收到的反馈/学习建议:**
|
||||
|
||||
- 需求澄清Skill整体框架优秀,交互流程设计合理,多角色评审机制从不同视角完善需求
|
||||
- 需要优化:Prompt过于臃肿(Token消耗大,Skill像"检索机"而非"智能体")、交互时间过长(40+分钟)、领域专家识别不准(生成了"医疗信息化专家"而非"医疗科研专家")
|
||||
- Skill规范文档很有价值,帮助团队理解底层机制
|
||||
- Prompt应遵循"首要原则":判断什么是清楚的、什么是不清楚的,只补充不清楚的部分
|
||||
|
||||
**下周任务:**
|
||||
|
||||
- [ ] P0｜优化需求澄清Skill
|
||||
- [ ] P0｜待需求文档确认后开始会议纪要skill制作
|
||||
- [ ] P1｜做安定医院方的DeepResearch需求文档，开发Deepresearch最小通用skill
|
||||
- [ ] P1｜跟进开发招投标文件Skill
|
||||
- [ ] P1｜问答系统V1.1问题分析和优化
|
||||
|
||||
#### 郝倩玉
|
||||
|
||||
**上周完成:**
|
||||
|
||||
- ✅ “小红书新手摄影博主文案生成智能体”前期网页界面优化等问题已解决，已完成搭建。
|
||||
- ✅完成发票处理/客户风险推送系统开发需求对接，其中发票处理系统已完成需求、开发、测试工作， 客户风险推送项目涉及天眼查方案部分已进行测试。
|
||||
- ✅推进招投标文件自动处理与生成智能体开发需求对接、流程梳理等相关工作。
|
||||
|
||||
**进行中:**
|
||||
|
||||
- 🔄 接手负责市场部需求确认工作
|
||||
- 🔄 招投标文件自动处理与生成智能体开发需求文档撰写
|
||||
|
||||
**收到的反馈/学习建议:**
|
||||
- 发票处理项目完成度高,获得认可(基于纯代码实现Python脚本,基本功能满意)
|
||||
- 客户风险推送方案可行,需后续进行优化
|
||||
|
||||
**下周任务:**
|
||||
|
||||
- [ ] P0｜作为需求确认总负责人,把关组内所有需求文档质量
|
||||
- [ ] P0｜会议纪要需求文档撰写，完成与连总确认，无误后发闫旭隆编写Skill
|
||||
- [ ] P1｜招投标文件自动处理与生成智能体开发需求文档、技术文档撰写，确认无误后发闫旭隆开发
|
||||
- [ ] P1｜与刘志豪、黄富有明确公众号项目需求，推进需求文档确认
|
||||
|
||||
#### 刘志豪
|
||||
|
||||
**上周完成:**
|
||||
|
||||
- ✅ 参与公众号需求对接(周五请假,工作未交接)
|
||||
- ✅ DeepResearch项目skill简单测试版本开发
|
||||
|
||||
**进行中:**
|
||||
|
||||
- 🔄 公众号需求(转交郝倩玉)
|
||||
- 🔄 DeepResearch项目(准备参与)
|
||||
|
||||
**收到的反馈/学习建议:**
|
||||
- 需求对接工作交接不清晰
|
||||
- 原始需求记录需要移交给郝倩玉
|
||||
|
||||
**下周任务:**
|
||||
|
||||
- [ ] P0｜向郝倩玉移交公众号原始需求记录(富有最初提的三条需求:多层分级、人事变动、每周考核汇总)
|
||||
- [ ] P1｜参与DeepResearch项目的讨论和开发,持续优化DeepResearch的skill改进
|
||||
|
||||
#### 陶西平
|
||||
|
||||
**上周完成:**
|
||||
|
||||
- ✅ 协助公众号需求文档初版生成(面向用户版本)
|
||||
- ✅ 针对图定制数字人平台相关调研
|
||||
|
||||
**进行中:**
|
||||
|
||||
- 🔄 针对视频定制数字人平台相关调研
|
||||
- 🔄 针对企业定制化前端web开源框架调研
|
||||
- 🔄 公众号项目支持
|
||||
|
||||
**下周任务:**
|
||||
|
||||
- [ ] P0｜配合郝倩玉/江争达完成公众号新需求确认
|
||||
- [ ] P1｜完成针对视频定制数字人生成平台相关调研（学习阶段，必须完成，个人任务）
|
||||
- [ ] P1｜针对企业定制化前端web开源框架调研（学习阶段，必须完成，个人任务）
|
||||
|
||||
---
|
||||
|
||||
## 三、会议总结
|
||||
|
||||
**核心主题:** 强化开发规范,确保所有P0项目必须有需求文档,没有需求不准开发;提升工作质量意识,自检要真正有效不能流于形式;规范需求对接流程,郝倩玉统一负责市场部需求对接;技术深度学习,做技术选型和调研必须理解底层原理
|
||||
|
||||
**关键决策:**
|
||||
|
||||
2. 郝倩玉成为需求对接总负责人,所有市场部需求(包括会议纪要需求)必须经她确认,没有确认任何人不准开发
|
||||
3. 会议纪要项目重新规范开发流程,下周现场测试,必须编写需求文档并建立校验机制
|
||||
4. 明天安定医院启动会,DeepResearch和招投标项目正式启动
|
||||
5. 闫旭隆的需求澄清Skill获得认可,作为开发规范核心工具,需优化后进入实际应用
|
||||
6. 需求文档要分两类:面向用户的(人能看懂)和面向大模型的(用于开发),只有用户确认后才算完成
|
||||
|
||||
**下周重点:**
|
||||
|
||||
1. 会议纪要现场测试和全员评审,验证数据一致性和P0项目识别准确性
|
||||
2. 公众号需求确认和开发文档完成,下周会议过一遍需求和开发文档
|
||||
3. 安定医院项目启动,DeepResearch第一阶段开发(文献研究和假设生成)
|
||||
4. 招投标文件Skill开发和部署,使用DOCX操作+占位符方法
|
||||
5. 数字人需求确认和技术调研,独立完成调研确保充分可用
|
||||
6. 所有P0项目必须有完整需求文档才能开发,严格执行开发规范
|
||||
|
||||
---
|
||||
|
||||
**纪要整理人:** Claude AI
|
||||
**纪要时间:** 2025-11-18
|
||||
**下次会议:** 2025-11-25
|
||||
@ -0,0 +1,26 @@
|
||||
# 周报 - 2025年11月第4周（11月18日-11月24日）
|
||||
|
||||
## 一、P0任务完成情况
|
||||
|
||||
| 任务 | 状态 | 备注 |
|
||||
|------|------|------|
|
||||
| 数字人需求文档 | 已完成 | - |
|
||||
| 公众号/网站信息获取优化和新需求开发 | 进行中 | 需求未确认 |
|
||||
|
||||
## 二、遇到的问题
|
||||
|
||||
1. **公众号/网站信息获取优化和新需求开发**：需求未确认
|
||||
|
||||
|
||||
## 三、详细工作内容
|
||||
|
||||
- 数字人生成需求文档（已完成）
|
||||
- 天眼查批量删除需求文档（已完成）
|
||||
- 日报/日报汇总模板需求文档（初版已完成）
|
||||
- 数字人生成调研报告（修改中）
|
||||
- 问答系统V1.1前端重构，调研中，未形成报告（进行中）
|
||||
|
||||
### 下周计划
|
||||
- 数字人生成视频
|
||||
- 问答系统V1.1前端重构方案
|
||||
- 完成天眼查批量删除功能
|
||||
@ -0,0 +1,43 @@
|
||||
# 周报 - 2025年11月第4周（11月19日-11月25日）
|
||||
|
||||
## 一、P0任务完成情况
|
||||
|
||||
| 任务 | 状态 | 备注 |
|
||||
| ---------------------------------------- | ------ | ------------------------------------------------------------ |
|
||||
| 会议纪要需求文档撰写 | 已完成 | 会议纪要需求文档已完成，连总已审核确认，示例样本已协助旭隆生成 |
|
||||
| 运营商信息精准爬取系统需求对接确认 | — | 富有、琳贤对项目需求尚未明确，需与窦主任沟通明确后再进行反馈（反馈时间待定） |
|
||||
| 投标商务应答文件自动生成系统需求文档确认 | 已完成 | 投标商务应答文件自动生成系统需求文档已完成并确认，已发开发人员（旭隆） |
|
||||
|
||||
|
||||
|
||||
## 二、遇到的问题
|
||||
|
||||
问题1：运营商信息精准爬取系统中，需求方的需求不明确且不实际
|
||||
|
||||
解决方法：已进行多轮沟通，并提供可借鉴思路，待对方明确需求后再择期启动项目
|
||||
|
||||
|
||||
|
||||
## 三、详细工作内容
|
||||
|
||||
### -[✅] 会议纪要需求文档
|
||||
|
||||
-[✅] 会议纪要需求文档已完成，连总已审核确认，示例样本已协助旭隆生成
|
||||
|
||||
### -[✅] 运营商信息精准爬取系统
|
||||
|
||||
-[✅] 已进行多轮沟通，富有、琳贤对项目需求尚未明确，需与窦主任沟通明确后再进行反馈（反馈时间待定）
|
||||
|
||||
### -[✅] 投标商务应答文件自动生成系统需求文档确认
|
||||
|
||||
-[✅] 投标商务应答文件自动生成系统需求文档已完成并确认，已发开发人员旭隆
|
||||
|
||||
|
||||
|
||||
## 下周计划
|
||||
|
||||
- 与旭隆沟通投标商务应答文件自动生成系统需求文档的技术可行性，协助撰写技术实现文档
|
||||
|
||||
- 运营商信息精准爬取系统需求跟进
|
||||
|
||||
|
||||
@ -0,0 +1,49 @@
|
||||
# 周报 - 2025年11月第4周（11月19日-11月25日）
|
||||
|
||||
## 一、P0任务完成情况
|
||||
|
||||
| 任务 | 状态 | 备注 |
|
||||
| ------------------------------ | ------ | --------- |
|
||||
| 需求澄清-需求文档skill优化测试 | 已完成 | 11-21完成 |
|
||||
| 会议纪要生成Skill编写 | 已完成 | 11-25完成 |
|
||||
|
||||
|
||||
|
||||
## 二、遇到的问题
|
||||
|
||||
无
|
||||
|
||||
|
||||
|
||||
## 三、详细工作内容
|
||||
|
||||
### -[✅]需求澄清-需求文档skill优化、测试、视频录制
|
||||
|
||||
- 规范最终模板，在保证全面的基础上避免过多冗余
|
||||
- 生成领域专家提示词改进，增加一个AI专家角色
|
||||
- 只保留核心问题，精简sub_agent内部提示词，在sub_agent内部增加使用web_search的提示词
|
||||
- 增加向Claude code提问，中断进入交互-确认继续访谈的功能
|
||||
- 在专家评审阶段之后增加用户选项：由专家直接汇总/由用户确认，节省用户操作时间
|
||||
|
||||
### -[✅]安定医院Deepresearch项目讨论以及需求文档初稿
|
||||
|
||||
- 使用需求文档skill制作安定医院Deepresearch需求文档初稿，录制视频作为skill演示
|
||||
|
||||
### -[✅]会议纪要skill开发
|
||||
|
||||
- 整理工程类、学习类、Q&A资源库会议纪要的生成逻辑映射关系及优先级、矛盾处理逻辑
|
||||
- 设计“主窗口区分工程类/学习类项目，调配 + 会议转写文本索引处理Agent + 搜索Agent”整体架构，实现开发
|
||||
|
||||
### -[✅]医院数据治理体系数智化转型PPT
|
||||
|
||||
- 制作PPT
|
||||
|
||||
|
||||
|
||||
## 下周计划
|
||||
|
||||
- 优化会议纪要生成skill，优化SKILL.md及Agent内部提示词和映射逻辑优先级
|
||||
- 实现安定医院Deepresearch-Skill-MVP阶段开发
|
||||
|
||||
|
||||
|
||||
@ -0,0 +1,26 @@
|
||||
# 周报 - 2025年11月第4周（11月19日-11月25日）
|
||||
|
||||
## 一、任务完成情况
|
||||
|
||||
| 任务 | 状态 | 备注 |
|
||||
|------|------|------|
|
||||
| 数字人调研 | 进行中 | 完成基本调研，生成调研报告草稿 |
|
||||
| 前端框架调研 | 进行中 | 完成对claudecode frontend-design skill 和 web-artifacts-builder skill 以及gemini3 pro 相关调研 |
|
||||
|
||||
## 二、遇到的问题
|
||||
|
||||
|
||||
## 三、详细工作内容
|
||||
|
||||
- 学习使用web-artifacts-builder、frontend-analysis、gemini3pro构建个性化组件
|
||||
- 学习Frontend Design Skill和web-artifacts-builder skill如何通过prompt对页面的美学进行约束的以及构建前端页面的流程
|
||||
- 本地部署lobe-chat和nextchat这两个前端开源框架，并且尝试在框架上构建个性化组件
|
||||
- 本地部署cc-switch，生成cc-switch使用结果文档
|
||||
- 收集cswitch相关信息
|
||||
- 对ppt和数字人视频相结合进行调研和尝试，构建了ppt与数字人结合的短视频
|
||||
|
||||
## 下周计划
|
||||
- 完成数字人调研报告
|
||||
- 完成ppt与数字人结合调研
|
||||
- 持续优化工作流
|
||||
- 学习主流ai技术对于前端方面的知识
|
||||
File diff suppressed because it is too large
Load Diff
@ -0,0 +1,205 @@
|
||||
# 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,255 @@
|
||||
# 工程类会议纪要 (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,335 @@
|
||||
# Q&A资源库类会议纪要生成逻辑
|
||||
|
||||
## 一、输出结构总览
|
||||
|
||||
```
|
||||
Q&A资源库类会议纪要
|
||||
├── 一、会议信息
|
||||
├── 二、工作问题 Q&A
|
||||
│ ├── 1. 项目名称1
|
||||
│ │ ├── 主要问题
|
||||
│ │ └── 解决方案
|
||||
│ ├── 2. 项目名称2
|
||||
│ └── ...
|
||||
└── 三、重点工作方法
|
||||
├── 方法1
|
||||
│ ├── 方法描述
|
||||
│ ├── 适用场景
|
||||
│ └── 关键要点
|
||||
├── 方法2
|
||||
└── ...
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 核心定位说明 ⭐⭐⭐
|
||||
|
||||
**Q&A资源库类会议纪要是二次提取产物**：
|
||||
- **执行时机**：在工程类和学习研究类会议纪要生成之后执行
|
||||
- **核心目的**：知识沉淀，构建可复用的Q&A资源库
|
||||
- **数据来源**：
|
||||
- "工作问题 Q&A"：从已生成的工程类/学习研究类纪要中提取
|
||||
- "重点工作方法"：从会议转写+周报中新提取
|
||||
|
||||
**依赖文件**：
|
||||
- 已生成的工程类会议纪要（必需）
|
||||
- 已生成的学习研究类会议纪要（可选）
|
||||
- 会议转写文件（用于提取工作方法）
|
||||
- 成员周报（用于提取工作方法）
|
||||
|
||||
---
|
||||
|
||||
## 二、章节数据来源与处理动作
|
||||
|
||||
### 第一部分：会议信息
|
||||
|
||||
#### 输出格式
|
||||
```markdown
|
||||
一、会议信息
|
||||
- 会议时间：2025-11-18
|
||||
- 参会人员：连云波、江争达、闫旭隆、陶西平、郝倩玉
|
||||
- 记录整理人：Claude
|
||||
```
|
||||
|
||||
#### 数据来源映射
|
||||
|
||||
| 字段 | 主要来源 | 处理逻辑 |
|
||||
|------|---------|---------|
|
||||
| 会议时间 | 已生成的工程类会议纪要 | 直接复用"会议信息"章节的会议时间 |
|
||||
| 参会人员 | 已生成的工程类会议纪要 | 直接复用"会议信息"章节的参会人员 |
|
||||
| 记录整理人 | 固定值 | 固定为"Claude" |
|
||||
|
||||
#### 需要的动作
|
||||
1. 读取已生成的工程类会议纪要文件
|
||||
2. 提取"一、会议信息"章节内容
|
||||
3. 直接复用，格式保持一致
|
||||
|
||||
---
|
||||
|
||||
### 第二部分：工作问题 Q&A
|
||||
|
||||
#### 输出格式
|
||||
```markdown
|
||||
## 二、工作问题 Q&A
|
||||
|
||||
### 1. 项目名称：会议纪要信息提取
|
||||
- **主要问题：** 转写说话人识别不准确，导致无法正确归属发言内容
|
||||
- **解决方案：**
|
||||
1. 采用语义分析替代说话人标记
|
||||
2. 通过上下文推断发言者身份
|
||||
3. 结合周报内容进行交叉验证
|
||||
|
||||
---
|
||||
|
||||
### 2. 项目名称：Skill架构设计
|
||||
- **主要问题：** Agent间数据传递方式不清晰
|
||||
- **解决方案：**
|
||||
1. 主窗口传递标识符和文件路径
|
||||
2. Agent通过temp/目录交换数据
|
||||
3. Agent直接返回文字结果给主窗口
|
||||
```
|
||||
|
||||
#### 数据来源映射
|
||||
|
||||
**核心原则**：二次提取，从已生成纪要中汇总
|
||||
|
||||
| 字段 | 数据来源（优先级从高到低） | 提取逻辑 |
|
||||
|------|---------------------------|---------|
|
||||
| 项目名称 | 工程类纪要"问题及解决方案"章节标题 | 提取"问题N: XXX"中的项目/问题名称 |
|
||||
| 主要问题 | 工程类纪要"问题描述"字段 | 直接提取，精简为1-2句话 |
|
||||
| 解决方案 | 工程类纪要"解决方案"列表 | 直接提取，保持列表格式 |
|
||||
|
||||
**补充来源**（学习研究类纪要）：
|
||||
|
||||
| 字段 | 数据来源 | 提取逻辑 |
|
||||
|------|---------|---------|
|
||||
| 项目名称 | 学习研究类纪要的议题标题 | 从学习议题中识别问题讨论部分 |
|
||||
| 主要问题 | "关键讨论成果"中的Q&A | 提取讨论中的问题部分 |
|
||||
| 解决方案 | "关键讨论成果"中的答案/共识 | 提取讨论中形成的解决方案 |
|
||||
|
||||
#### 需要的动作
|
||||
|
||||
**动作1：提取工程类纪要中的问题（主窗口执行）**
|
||||
- 读取已生成的工程类会议纪要
|
||||
- 定位"### 2. 重点项目问题及解决方案"章节
|
||||
- 解析每个问题块，提取：
|
||||
- 问题标题（作为项目名称）
|
||||
- 问题描述（精简为主要问题）
|
||||
- 解决方案列表
|
||||
- 责任人（可选，用于追溯）
|
||||
- 截止时间（可选，用于追溯）
|
||||
|
||||
**动作2：提取学习研究类纪要中的Q&A（主窗口执行，可选）**
|
||||
- 读取已生成的学习研究类会议纪要（如存在）
|
||||
- 定位每个议题的"关键讨论成果"部分
|
||||
- 识别Q&A格式内容：
|
||||
- 问题：通常以"Q:"、"问题"、"？"等标识
|
||||
- 答案/方案：紧随问题之后的回答内容
|
||||
|
||||
**动作3：提取成员反馈中的问题（主窗口执行，可选）**
|
||||
- 从工程类纪要"### 4. 组内成员工作进展"中提取
|
||||
- 识别"收到的反馈/学习建议"部分中包含的问题和建议
|
||||
- 转化为Q&A格式
|
||||
|
||||
**动作4：合并去重（主窗口执行）**
|
||||
- 将所有来源的问题进行语义匹配
|
||||
- 相似度 > 80% 视为同一问题，合并解决方案
|
||||
- 按项目分组，同一项目的多个问题归类在一起
|
||||
|
||||
**动作5：格式化输出（主窗口执行）**
|
||||
- 按项目编号组织输出
|
||||
- 格式：### {序号}. 项目名称：{project_name}
|
||||
- 包含：主要问题 + 解决方案列表
|
||||
|
||||
---
|
||||
|
||||
### 第三部分：重点工作方法
|
||||
|
||||
#### 输出格式
|
||||
```markdown
|
||||
## 三、重点工作方法
|
||||
|
||||
- **方法 1：语义分析替代说话人标记**
|
||||
- 当转写文本说话人识别不准确时，通过分析发言内容的语义特征来判断发言者
|
||||
- 适用场景：会议转写处理、发言归属分析
|
||||
- 关键要点：
|
||||
- 关注发言中的人称代词和上下文
|
||||
- 结合周报内容进行交叉验证
|
||||
- 利用任务分配信息推断发言者
|
||||
|
||||
- **方法 2：渐进式披露原则**
|
||||
- Skill设计中采用三级加载系统，元数据→主体→资源按需加载
|
||||
- 适用场景：Claude Code Skill开发、大型项目架构
|
||||
- 关键要点：
|
||||
- 元数据始终在上下文中（~100词）
|
||||
- 主体内容触发时加载（<3k词）
|
||||
- 详细资源按需读取
|
||||
```
|
||||
|
||||
#### 数据来源映射
|
||||
|
||||
**核心原则**：会议转写 + 周报，两者结合
|
||||
|
||||
| 字段 | 数据来源 | 提取逻辑 |
|
||||
|------|---------|---------|
|
||||
| 方法标题 | 会议转写中的方法分享 + 周报经验总结 | 从分享内容中提炼方法名称 |
|
||||
| 方法描述 | 会议转写详细讲解 + 周报总结描述 | 合并两者，形成完整描述 |
|
||||
| 适用场景 | 会议讨论上下文 + 周报应用场景 | 从讨论中识别方法的适用范围 |
|
||||
| 关键要点 | 会议讲解要点 + 周报经验要点 | 提炼为3-5条核心要点 |
|
||||
|
||||
#### 需要的动作
|
||||
|
||||
**动作1：从会议转写提取方法分享（调用 Agent）**
|
||||
- 调用 transcript_searcher Agent
|
||||
- 搜索意图：提取会议中分享的工作方法、技巧、最佳实践
|
||||
- 识别特征：
|
||||
- "方法是..."、"技巧是..."、"经验是..."
|
||||
- "我的做法是..."、"建议..."、"注意..."
|
||||
- 总结性、经验性、指导性语句
|
||||
- 提取字段：方法名称、详细描述、提出人
|
||||
|
||||
```python
|
||||
Task(
|
||||
subagent_type="transcript_searcher",
|
||||
description="提取工作方法",
|
||||
prompt="""提取会议中分享的工作方法、技巧、最佳实践。
|
||||
|
||||
识别特征：
|
||||
- 方法论讲解（"方法是..."、"技巧是..."）
|
||||
- 经验分享（"我的做法是..."、"建议..."）
|
||||
- 总结性语句（"总结一下..."、"关键是..."）
|
||||
|
||||
需提取字段：
|
||||
- 方法名称（简短标题）
|
||||
- 方法描述（详细说明）
|
||||
- 提出人（从上下文推断）
|
||||
- 相关项目（方法关联的项目）
|
||||
|
||||
返回JSON格式。
|
||||
"""
|
||||
)
|
||||
```
|
||||
|
||||
**动作2：从周报提取经验总结（主窗口执行）**
|
||||
- 遍历所有周报
|
||||
- 从"详细工作内容"中识别方法论/经验总结内容
|
||||
- 识别特征：
|
||||
- 带有"方法"、"技巧"、"经验"等关键词的段落
|
||||
- 总结性、归纳性描述
|
||||
- 可复用的工作模式
|
||||
- 提取：方法标题、描述、作者
|
||||
|
||||
**动作3：合并整理（主窗口执行）**
|
||||
- 将会议方法与周报方法进行语义匹配
|
||||
- 相似方法合并，补充细节
|
||||
- 为每个方法生成完整结构：
|
||||
- 方法标题
|
||||
- 方法描述（合并会议详细讲解 + 周报简要描述）
|
||||
- 适用场景（从会议讨论上下文推断）
|
||||
- 关键要点（提炼为3-5条）
|
||||
|
||||
**动作4：格式化输出（主窗口执行）**
|
||||
- 按方法编号组织输出
|
||||
- 格式：- **方法 {序号}：{方法标题}**
|
||||
- 包含：描述 + 适用场景 + 关键要点列表
|
||||
|
||||
---
|
||||
|
||||
## 三、关键数据优先级规则总结
|
||||
|
||||
| 字段 | 数据来源 | 优先级规则 | 说明 |
|
||||
|------|---------|-----------|------|
|
||||
| **会议信息** | 工程类纪要 | **直接复用** | 无需重新提取 |
|
||||
| **Q&A-项目名称** | 工程类纪要 > 学习类纪要 | **工程类优先** | 工程类问题更明确 |
|
||||
| **Q&A-主要问题** | 工程类纪要 > 学习类纪要 | **工程类优先** | 工程类描述更完整 |
|
||||
| **Q&A-解决方案** | 工程类纪要 + 学习类纪要 | **互补合并** | 合并所有解决方案 |
|
||||
| **方法-标题** | 会议转写 > 周报 | **会议优先** | 会议分享通常更正式 |
|
||||
| **方法-描述** | 会议转写 + 周报 | **互补合并** | 会议详细 + 周报简要 |
|
||||
| **方法-适用场景** | 会议讨论上下文 | **仅会议** | 从讨论中推断 |
|
||||
| **方法-关键要点** | 会议转写 + 周报 | **互补合并** | 提炼核心要点 |
|
||||
|
||||
---
|
||||
|
||||
## 四、特殊情况处理
|
||||
|
||||
**情况1：工程类纪要不存在**
|
||||
```
|
||||
处理：无法生成Q&A资源库类纪要，提示用户先生成工程类纪要
|
||||
原因：工程类纪要是Q&A的主要数据来源
|
||||
```
|
||||
|
||||
**情况2：学习研究类纪要不存在**
|
||||
```
|
||||
处理：正常生成，仅使用工程类纪要作为Q&A数据来源
|
||||
说明：学习研究类纪要是可选补充来源
|
||||
```
|
||||
|
||||
**情况3：工程类纪要中无问题章节**
|
||||
```
|
||||
处理：
|
||||
- 如果学习研究类纪要存在且有Q&A → 使用学习研究类纪要
|
||||
- 如果都没有 → "二、工作问题 Q&A"章节输出"本次会议无记录的问题讨论"
|
||||
```
|
||||
|
||||
**情况4：会议中无方法分享**
|
||||
```
|
||||
处理：
|
||||
- 如果周报中有经验总结 → 使用周报内容
|
||||
- 如果都没有 → "三、重点工作方法"章节输出"本次会议无记录的方法分享"
|
||||
```
|
||||
|
||||
**情况5：同一问题在多个来源中重复**
|
||||
```
|
||||
工程类纪要和学习研究类纪要都有同一问题
|
||||
处理：
|
||||
- 语义匹配后合并
|
||||
- 问题描述取更完整的版本
|
||||
- 解决方案列表合并去重
|
||||
```
|
||||
|
||||
**情况6：方法分享过于零散**
|
||||
```
|
||||
会议中零散提到多个小技巧，但没有系统性方法
|
||||
处理：
|
||||
- 相关技巧归类合并为一个"方法"
|
||||
- 标题使用归纳性名称（如"XX相关技巧汇总"）
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 五、执行流程总结
|
||||
|
||||
```
|
||||
Phase 1: 检查依赖
|
||||
├── 检查工程类会议纪要是否存在（必需）
|
||||
├── 检查学习研究类会议纪要是否存在（可选）
|
||||
└── 检查会议转写和周报文件（用于提取方法）
|
||||
|
||||
Phase 2: 提取会议信息
|
||||
└── 从工程类纪要复用"会议信息"章节
|
||||
|
||||
Phase 3: 提取工作问题 Q&A
|
||||
├── 从工程类纪要提取"问题及解决方案"
|
||||
├── 从学习研究类纪要提取"关键讨论成果"中的Q&A（可选）
|
||||
├── 从成员反馈中提取问题建议（可选）
|
||||
└── 合并去重，按项目分组
|
||||
|
||||
Phase 4: 提取重点工作方法
|
||||
├── 调用Agent从会议转写提取方法分享
|
||||
├── 从周报提取经验总结
|
||||
└── 合并整理，生成完整方法结构
|
||||
|
||||
Phase 5: 最终输出
|
||||
├── 组装所有章节
|
||||
└── 写入文件：output/Q&A资源库类会议纪要_{date}_第X次周会.md
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 六、输出文件命名规则
|
||||
|
||||
- **文件名格式**：`Q&A资源库类会议纪要_{date}_第X次周会.md`
|
||||
- **日期格式**：YYYY-MM-DD
|
||||
- **周会次数**：与工程类纪要保持一致
|
||||
|
||||
**示例**：`Q&A资源库类会议纪要_2025-11-18_第二次周会.md`
|
||||
@ -0,0 +1,415 @@
|
||||
# 工程类会议纪要生成逻辑梳理
|
||||
|
||||
## 一、输出结构总览
|
||||
|
||||
```
|
||||
工程类会议纪要
|
||||
├── 一、会议信息
|
||||
├── 二、工作内容
|
||||
│ ├── 1. 重点项目进展情况汇总（表格）
|
||||
│ ├── 2. 重点项目问题及解决方案
|
||||
│ ├── 3. 下周工作安排（表格）
|
||||
│ └── 4. 组内成员工作进展
|
||||
└── 三、会议总结
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 项目类型区分规则
|
||||
|
||||
**核心问题**：周报中没有"学习类"/"工程类"标签，两类项目都混在"P0任务完成情况"和"详细工作内容"中。
|
||||
|
||||
**区分方法**：
|
||||
1. **资料库指引** ⭐：项目在 `input/成员本周资料库/` 下有对应md文件 → 学习研究类
|
||||
2. **语义判断**：根据任务性质（知识获取/技能提升 vs 产出交付/功能实现）语义判断
|
||||
|
||||
**背景**：成员会以周报为顶层，讲到学习内容时打开资料库里的md进行分享，资料库中的项目通常是学习研究类。
|
||||
|
||||
**本文档仅处理工程类项目**，学习研究类项目参见 `学习研究类会议纪要生成逻辑.md`。
|
||||
|
||||
---
|
||||
|
||||
## 二、章节数据来源与处理动作
|
||||
|
||||
### 第一部分：会议信息
|
||||
|
||||
#### 输出格式
|
||||
```markdown
|
||||
一、会议信息
|
||||
- 会议名称：日期+第X次周会
|
||||
- 会议时间：2025-11-18
|
||||
- 参会人员：连云波、江争达、闫旭隆、陶西平、郝倩玉
|
||||
- 记录整理人：Claude
|
||||
```
|
||||
|
||||
#### 数据来源映射
|
||||
|
||||
| 字段 | 主要来源 | 处理逻辑 |
|
||||
|------|---------|---------|
|
||||
| 会议名称 | 自动生成 | 根据会议时间生成"YYYY-MM-DD_第X次周会" |
|
||||
| 会议时间 | 会议转写文件名 | 从文件名提取日期："20251118134948-转写..." → "2025-11-18" |
|
||||
| 参会人员 | 成员周报文件名列表 | 提取所有周报的作者名：`20251118-闫旭隆周报.md` → "闫旭隆"<br>**规则**：交了周报的人即为参会人员 |
|
||||
| 记录整理人 | 固定值 | 固定为"Claude" |
|
||||
|
||||
#### 需要的动作
|
||||
1. 解析会议转写文件名，提取日期并格式化为"YYYY-MM-DD"
|
||||
2. 遍历周报文件名，提取所有姓名并去重，组成参会人员列表
|
||||
3. 自动计算会议次数（根据历史纪要数量）或默认显示"第X次周会"
|
||||
4. 记录整理人固定填写"Claude"
|
||||
|
||||
---
|
||||
|
||||
### 第二部分-1：重点项目进展情况汇总（表格）⭐核心追踪
|
||||
|
||||
> ⚠️ **仅处理工程类项目**，学习研究类项目由 Phase 4 单独生成纪要
|
||||
|
||||
#### 输出格式
|
||||
```markdown
|
||||
| 项目名称 | ！！！原负责人 | 截止时间 | 项目进展情况 |
|
||||
|---------|--------|----------|-------------|
|
||||
| 开发规范建立 | 连云波、闫旭隆 | 11月18日 | 闫旭隆完成需求文档Skill开发 |
|
||||
| 会议纪要流程 | 江争达 | 11月18日 | 未完成（上周计划本周未在周报中体现） |
|
||||
```
|
||||
|
||||
#### 数据来源映射
|
||||
|
||||
**核心原则**：**仅展示P0项目**，**必须包含上周计划的所有P0任务**，非P0任务不在此处展示
|
||||
|
||||
| 表格列 | 数据来源 | 处理规则 |
|
||||
|--------|---------|---------|
|
||||
| 项目名称 | ⭐ 上周纪要"下周工作安排"中的**仅P0任务**<br>⭐ 本周成员周报"P0任务完成情况"表格 | **取并集**：上周P0 ∪ 本周P0<br>上周P0必须全部出现<br>⭐**非P0任务不在此处展示** |
|
||||
| 负责人 | • 上周纪要"下周工作安排"中的负责人<br>• 本周周报作者姓名（若该P0只出现在成员周报里） | 多人负责时合并显示 |
|
||||
| 截止时间 | • 本周成员周报"P0任务"中的备注/时间<br>• 上周纪要"下周工作安排"中的截止时间**（！！注明，都保留）** | **周报优先** > 上周纪要<br>周报中有则用周报，无则用上周纪要 |
|
||||
| 项目进展情况 | ⭐⭐ 本周成员周报"P0任务"的状态列 | **有且仅有**本周周报，**不参考会议转写（！！参考会议转写更新最新状态）**<br>• 如果周报中有该P0 → 填写状态+备注<br>• 如果周报中无该P0 → 自动填写"未完成（上周计划本周未在周报中体现）" |
|
||||
|
||||
#### 数据交叉验证规则 ⭐⭐⭐
|
||||
|
||||
**规则1：强制包含上周P0任务**
|
||||
|
||||
```
|
||||
上周纪要"下周工作安排"中的所有P0任务，必须在本周进展汇总中出现
|
||||
- 如果该任务在本周周报中有 → 填写周报中的进展情况
|
||||
- 如果该任务在本周周报中无 → 自动标记"未完成（上周计划本周未在周报中体现）"
|
||||
```
|
||||
|
||||
**规则2：新增本周P0任务**
|
||||
|
||||
```
|
||||
本周周报"P0任务"中新出现的任务（上周纪要中没有）：
|
||||
- 必须添加到本周进展汇总中
|
||||
- 不能忽略
|
||||
```
|
||||
|
||||
**规则3：项目匹配逻辑**
|
||||
|
||||
```
|
||||
交给Claude根据语义判断"上周任务A"与"本周任务B"是否为同一项目：
|
||||
- 示例："需求文档Skill开发" ≈ "开发规范-需求文档生成阶段Skill"
|
||||
```
|
||||
|
||||
|
||||
|
||||
#### 特殊情况处理
|
||||
|
||||
**情况1：负责人变更**
|
||||
```
|
||||
上周：项目A - 负责人：张三
|
||||
本周：项目A - 负责人：李四
|
||||
|
||||
处理：标注"已转交给李四"
|
||||
```
|
||||
|
||||
**情况2：任务名称差异较大**
|
||||
```
|
||||
上周：会议纪要流程文档
|
||||
本周：会议纪要Skill需求文档
|
||||
|
||||
如果语义相似度 < 85%：
|
||||
→ 认为是两个不同任务
|
||||
→ 都要在进展汇总中显示
|
||||
```
|
||||
|
||||
**情况3：截止时间冲突**
|
||||
|
||||
```
|
||||
上周：项目A - 截止时间：11月18日
|
||||
本周：项目A - 截止时间：11月25日
|
||||
|
||||
处理：以本周周报为准（11月25日）
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
### 第二部分-2：重点项目问题及解决方案
|
||||
|
||||
#### 输出格式
|
||||
```markdown
|
||||
#### 问题1: 会议纪要信息提取准确性问题
|
||||
|
||||
**问题描述:** XXX
|
||||
**解决方案:**
|
||||
1. ...
|
||||
2. ...
|
||||
|
||||
**责任人:** XXX
|
||||
**截止时间:** XXX
|
||||
```
|
||||
|
||||
#### 数据来源映射
|
||||
|
||||
**核心原则**：会议转写与周报是互补关系，需合并两者信息
|
||||
|
||||
| 字段 | 数据来源（互补关系） | 提取与合并逻辑 |
|
||||
|------|---------------------|---------------|
|
||||
| 项目名称 | 会议转写问题讨论上下文 + 周报"遇到的问题" | 从问题描述中推断所属项目，两者互相验证 |
|
||||
| 问题描述 | 会议转写问题阐述 + 周报"遇到的问题" | 合并两者：周报提供问题初步描述，会议提供详细讨论和分析 |
|
||||
| 解决方案 | 会议转写讨论结论 + 周报"解决方法" | 合并两者：周报可能有初步方案，会议讨论后确定最终方案 |
|
||||
| 责任人 | 会议转写上下文推断 + 周报作者 | 会议中明确分配的责任人，若无则用周报作者（问题提出人） |
|
||||
| 截止时间 | 会议转写上下文推断 + 会议转写时间 | 会议中提取明确时间，无则默认下周周会前（写具体日期） |
|
||||
|
||||
#### 需要的动作
|
||||
|
||||
**动作1：从周报提取问题**
|
||||
|
||||
- 遍历所有周报，读取"二、遇到的问题"章节
|
||||
- 提取：问题描述、解决方法（如已填写）
|
||||
- 关联问题提出人
|
||||
|
||||
**动作2：从会议转写提取问题讨论**
|
||||
|
||||
- 语义识别问题讨论片段（提出问题→分析→讨论→方案）
|
||||
- 提取：问题完整描述、原因分析、讨论要点、确定方案
|
||||
- **责任人**：从会议上下文推断（识别"XX负责"、"XX去做"等）
|
||||
- **截止时间**：从会议中提取明确时间，无则默认下周周会前（写具体日期，如"11月25日"）
|
||||
|
||||
**动作3：问题去重与合并 ⭐互补关系**
|
||||
- 将周报问题与会议讨论问题进行语义匹配，注意去重
|
||||
- **合并信息**：
|
||||
- 问题描述：周报的简洁描述 + 会议的详细分析 → 综合描述
|
||||
- 解决方案：周报的初步方法 + 会议的讨论结论 → 最终方案
|
||||
- 责任人：优先使用会议上下文推断的责任人，无则用周报作者
|
||||
- 截止时间：使用会议中提取的时间，写具体日期
|
||||
|
||||
**动作4：结构化输出**
|
||||
- 按项目分组问题
|
||||
- 格式化：问题描述简洁、解决方案分点列表
|
||||
|
||||
---
|
||||
|
||||
### 第二部分-3：下周工作安排（表格）⭐核心
|
||||
|
||||
> ⚠️ **仅处理工程类项目**，学习研究类项目由 Phase 4 单独生成纪要
|
||||
|
||||
#### 输出格式
|
||||
```markdown
|
||||
| 项目名称 | 负责人 | 下周会前目标 | 优先级 | 截止时间 |
|
||||
|---------|--------|----------|--------|----------|
|
||||
| 🔴 Deepresearch Skill开发 | 闫旭隆 | 实现知识图谱增量更新 | P0 | 11月25日 |
|
||||
| 招投标技术方案调研 | 闫旭隆 | 调研文档处理能力 | P1 | 11月30日 |
|
||||
```
|
||||
|
||||
#### 数据来源映射
|
||||
|
||||
**核心原则**：会议转写与周报是互补关系，去重合并；冲突时以会议为准
|
||||
|
||||
| 表格列 | 数据来源（互补关系） | 提取与合并逻辑 |
|
||||
|--------|---------------------|---------------|
|
||||
| 项目名称 | 会议转写任务安排讨论 + 成员周报"下周计划" | 合并两者任务，注意语义去重 |
|
||||
| 负责人 | 会议中明确分配 + 周报作者 | 冲突时会议优先；无冲突时取并集；会议未提及的周报任务用周报作者 |
|
||||
| 下周会前目标 | 会议讨论的具体目标 + 周报"下周计划"描述 | 合并两者描述，冲突时会议优先，周报补充细节 |
|
||||
| 优先级 | ⭐⭐会议转写语义推断 + 周报标记（若有） | **核心**：从会议讨论的重要性、紧急程度、领导强调程度语义判断P0/P1/P2；会议未提及的周报任务默认P1 |
|
||||
| 截止时间 | 会议转写明确时间 + 周报时间 | 冲突时会议优先，无冲突时取更明确的；都无则推断（默认下次周会前，写具体日期） |
|
||||
|
||||
#### 需要的动作
|
||||
|
||||
**动作1：从会议转写提取任务安排**
|
||||
- 语义识别任务分配片段（"下周XX负责XX"、"XX需要完成XX"、"这个很重要"）
|
||||
- 提取：任务名称、具体目标、负责人、截止时间
|
||||
- **优先级判断规则**：
|
||||
- 领导明确说"P0"或"优先"、"重点"、"紧急" → P0
|
||||
- 领导反复强调、讨论时间长、要求本周完成 → P0
|
||||
- 一般性安排、探索性任务、长期任务 → P1
|
||||
- 探索性任务、长期优化、低优先级事项 → P2
|
||||
- 无法判断 → 默认P1
|
||||
|
||||
**动作2：从周报提取下周计划**
|
||||
- 遍历所有周报，读取"下周计划"章节
|
||||
- 提取：任务名称、任务描述
|
||||
- 注意：周报往往不全且无优先级标记
|
||||
|
||||
**动作3：任务合并与去重 ⭐互补关系**
|
||||
- 语义匹配去重，注意识别同一任务
|
||||
- **互补合并**：会议任务 + 周报任务 → 去重后的完整任务列表
|
||||
- **冲突处理规则**：
|
||||
- 同一任务的负责人冲突 → 以会议为准
|
||||
- 同一任务的优先级冲突 → 以会议为准
|
||||
- 同一任务的截止时间冲突 → 以会议为准（写具体日期，如"11月25日"）
|
||||
- 会议未提及但周报有的任务 → 保留，默认P1
|
||||
- **截止时间处理**：都无明确时间时，默认下次周会前，写具体日期
|
||||
- 计算逻辑：本次会议时间 + 7天（假设周会频率为每周一次）
|
||||
- 示例：本次会议2025-11-18 → 默认截止时间2025-11-25
|
||||
|
||||
**动作4：优先级排序 ⭐⭐⭐核心规则**
|
||||
```
|
||||
核心规则：P0任务必须排在P1任务之前，P1任务必须排在P2任务之前
|
||||
|
||||
排序逻辑：
|
||||
1. 先按优先级分组：P0组、P1组、P2组
|
||||
2. 组内按截止时间排序（紧急的在前）
|
||||
3. P0任务标记🔴emoji
|
||||
|
||||
输出顺序：[P0任务1] [P0任务2] ... [P1任务1] [P1任务2] ... [P2任务1] [P2任务2] ...
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
### 第二部分-4：组内成员工作进展
|
||||
|
||||
> ⚠️ **下周任务仅列工程类项目**，学习研究类项目由 Phase 4 单独生成纪要
|
||||
|
||||
#### 输出格式
|
||||
```markdown
|
||||
#### 闫旭隆
|
||||
|
||||
**上周完成:**
|
||||
- ✅ 需求文档生成Skill的MVP开发
|
||||
- ✅ Skill开发规范总结
|
||||
|
||||
**进行中:**
|
||||
- 🔄 Deepresearch框架学习
|
||||
|
||||
**收到的反馈/学习建议:**
|
||||
- 项目理解Skill框架获得认可
|
||||
- 需继续深入Claude Code优化研究
|
||||
|
||||
**下周任务:**
|
||||
- [ ] 🔴 P0|Deepresearch Skill开发
|
||||
- [ ] P1|招投标技术方案调研
|
||||
```
|
||||
|
||||
#### 数据来源映射
|
||||
|
||||
| 部分 | 主要来源 | 备选来源 | 提取逻辑 |
|
||||
|------|---------|---------|---------|
|
||||
| 上周完成 | 周报"P0任务完成情况"+"详细工作内容" | 无备选 | 提取状态为"已完成"或✅的项 |
|
||||
| 进行中 | 周报"详细工作内容"中未完成项 | 会议讨论的进行中工作 | 提取状态为"进行中"或🔄的项 |
|
||||
| 收到反馈 | 会议转写中领导对该成员的评价 | - | ⭐根据语义理解提取反馈（不依赖转写说话人识别） |
|
||||
| 下周任务 | 会议分配给该成员的任务 | 周报"下周计划" | ⭐以会议为准，按P0→P1→P2排序<br>**合并规则**：<br>1. 会议中明确分配给该成员的任务（带优先级）<br>2. 周报"下周计划"中的任务（会议未提及的默认P1）<br>3. 语义去重后按优先级排序 |
|
||||
|
||||
#### 需要的动作
|
||||
|
||||
**动作1：为每个成员提取周报信息**
|
||||
- 提取"上周完成"：P0任务状态="已完成"的项 + 详细工作内容✅项
|
||||
- 提取"进行中"：详细工作内容🔄项 + 未完成的P0任务
|
||||
- 提取"下周任务"："下周计划"章节的所有条目
|
||||
|
||||
**动作2：从会议转写提取个人反馈**
|
||||
- 在会议转写中搜索：涉及成员姓名的对话片段
|
||||
- ⭐**注意**：转写说话人识别不可靠，根据语义理解谁在给谁反馈（批评/表扬语气、内容逻辑）
|
||||
- 语义理解：正面评价、建议、批评
|
||||
- 提取并整理为1-3条关键反馈
|
||||
|
||||
**动作3：下周任务合并与排序 ⭐⭐⭐**
|
||||
- 从"下周工作安排"表格中筛选该成员负责的任务
|
||||
- 与成员周报"下周计划"合并去重
|
||||
- **核心规则**：每个成员的"下周任务"内部也要按P0→P1→P2排序
|
||||
- 格式：`- [ ] 🔴 P0|任务名称`（无空格）
|
||||
|
||||
---
|
||||
|
||||
### 第三部分：会议总结
|
||||
|
||||
#### 输出格式
|
||||
```markdown
|
||||
三、会议总结
|
||||
|
||||
**核心议题：** 开发规范建设、会议纪要流程规范化、Deepresearch框架选型
|
||||
|
||||
**关键决策：**
|
||||
1. 暂停江争达参与开发规范建设，要求先系统学习
|
||||
2. 采用闫旭隆的项目理解框架作为开发规范正面案例
|
||||
3. 会议纪要本周进行现场测试
|
||||
|
||||
**下周工作重点：**
|
||||
1. 会议纪要现场测试
|
||||
2. Deepresearch Skill开发
|
||||
3. 市场部需求对接
|
||||
```
|
||||
|
||||
#### 数据来源映射
|
||||
|
||||
| 部分 | 主要来源 | 备选来源 | 提取逻辑 |
|
||||
|------|---------|---------|---------|
|
||||
| 核心议题 | 会议转写中讨论最多的2-4个主题（通常是P0优先级） | "重点项目进展"的项目列表 | 统计高频关键词或主题，提取3-5个 |
|
||||
| 关键决策 | 会议转写中的决策性语句 | - | 识别"决定"、"确定"、"采用"等关键词 |
|
||||
| 下周重点 | 已生成的"下周工作安排"中P0任务 | 会议结尾总结部分 | 提取P0任务，归纳为3-5条 |
|
||||
|
||||
#### 需要的动作
|
||||
|
||||
**动作1：提取核心议题**
|
||||
- 方法1：对会议转写进行主题建模，识别讨论最多的3-5个主题
|
||||
- 方法2：统计项目名称出现频率，提取讨论时长最长的话题
|
||||
|
||||
**动作2：识别关键决策**
|
||||
- 在会议转写中语义搜索决策性语句
|
||||
- 特征："决定..."、"确定..."、"采用..."、"要求..."
|
||||
- 提取3-5条最重要的决策
|
||||
|
||||
**动作3：生成下周重点**
|
||||
- 从"下周工作安排"表格提取所有P0任务
|
||||
- 按项目或主题归类
|
||||
- 归纳为3-5条工作重点
|
||||
|
||||
---
|
||||
|
||||
## 三、关键的跨章节关联
|
||||
|
||||
### 1. 任务追踪线索（纵向连续性）
|
||||
|
||||
```
|
||||
上周纪要"下周工作安排"
|
||||
↓
|
||||
本周"重点项目进展情况汇总"（对应完成情况）
|
||||
↓
|
||||
本周"组内成员工作进展"（个人维度的完成情况）
|
||||
↓
|
||||
本周"下周工作安排"（新的计划）
|
||||
```
|
||||
|
||||
**处理逻辑**：
|
||||
- 建立任务ID映射表
|
||||
- 追踪任务状态变化：计划→进行中→已完成
|
||||
- 标记未完成任务的延续
|
||||
|
||||
### 2. 问题闭环（横向关联）
|
||||
|
||||
```
|
||||
"重点项目问题及解决方案"
|
||||
↓
|
||||
"下周工作安排"（问题的解决任务）
|
||||
```
|
||||
|
||||
### 3. 优先级一致性（全局规则）⭐⭐⭐
|
||||
|
||||
**所有涉及任务的地方必须遵循优先级排序原则：**
|
||||
- 重点项目进展：**仅显示P0任务**
|
||||
- 下周工作安排：P0在前，P1居中，P2在后（非P0任务也会出现）
|
||||
- 组内成员进展：每人的下周任务也按P0→P1→P2排序（**非P0任务会出现在这里**）
|
||||
- 会议总结：下周重点 = P0任务
|
||||
|
||||
---
|
||||
|
||||
## 四、关键数据优先级规则总结
|
||||
|
||||
| 字段/章节 | 数据来源 | 优先级规则 | 说明 |
|
||||
|----------|---------|-----------|------|
|
||||
| **项目进展-项目名称** | 上周纪要P0 + 本周周报P0 | **取并集，仅P0** | 上周P0必须全部出现，非P0任务不展示 |
|
||||
| **项目进展-负责人** | 上周纪要 + 本周周报 | 哪里有就填哪个 | 多人时合并显示 |
|
||||
| **项目进展-截止时间** | 本周周报 / 上周纪要 | **周报优先** | 周报可能更准确 |
|
||||
| **项目进展-进展情况** | 本周周报 | **仅周报** | 不参考会议转写 |
|
||||
| **问题方案-问题描述** | 会议转写 + 周报 | **互补合并** | 周报提供问题简述，会议提供详细分析和方案 |
|
||||
| **下周安排-任务** | ⭐会议转写 + 周报 | **互补合并** | 两者去重合并，冲突时会议为准，包含P0/P1/P2 |
|
||||
| **下周安排-优先级** | ⭐会议转写语义推断 + 周报标记 | **会议判断为主** | 会议语义判断P0/P1/P2；会议未提及的周报任务默认P1 |
|
||||
| **下周安排-负责人/时间** | 会议 + 周报 | **冲突时会议为准** | 同一任务的字段冲突时，以会议为准 |
|
||||
| **成员进展-下周任务** | 会议分配 + 周报计划 | **会议为准，合并去重** | 包含P0/P1/P2任务，按优先级排序 |
|
||||
| **成员进展-反馈** | 会议转写 | 仅会议 | 语义提取，不依赖说话人识别 |
|
||||
@ -0,0 +1,191 @@
|
||||
# 学习研究类会议纪要生成逻辑
|
||||
|
||||
## 一、输出结构总览
|
||||
|
||||
```
|
||||
学习研究类会议纪要
|
||||
├── 一、会议信息
|
||||
└── 二、学习研究内容
|
||||
├── 1. 议题标题1 (分享人)
|
||||
│ ├── 背景与目的
|
||||
│ ├── 核心议题概述
|
||||
│ ├── 关键讨论成果
|
||||
│ └── 下一步研究方向
|
||||
├── 2. 议题标题2 (分享人)
|
||||
└── ...
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 项目类型区分规则 ⭐⭐⭐
|
||||
|
||||
**核心问题**：周报中没有"学习类"标签，工程类和学习研究类项目都混在"P0任务完成情况"和"详细工作内容"中。
|
||||
|
||||
**区分方法**：
|
||||
1. **资料库指引** ⭐：项目在 `input/成员本周资料库/` 下有对应md文件 → 学习研究类
|
||||
2. **语义判断**：根据任务描述的性质（知识获取/技能提升 vs 产出交付/功能实现）语义判断
|
||||
|
||||
**资料库路径**：`D:\AA_Work\skills合集\AIEC-团队开发规范Skills\.claude\skills\meeting-minutes-generator-v1\input\成员本周资料库\`
|
||||
|
||||
**背景**：成员会以周报为顶层，讲到对应学习内容时打开资料库里的md进行分享。
|
||||
|
||||
---
|
||||
|
||||
## 二、章节数据来源与处理动作
|
||||
|
||||
### 第一部分：会议信息
|
||||
|
||||
#### 输出格式
|
||||
```markdown
|
||||
一、会议信息
|
||||
- 会议时间：2025-11-18
|
||||
- 参会人员：连云波、江争达、闫旭隆、陶西平、郝倩玉
|
||||
- 记录整理人：Claude
|
||||
```
|
||||
|
||||
#### 数据来源映射
|
||||
|
||||
| 字段 | 主要来源 | 处理逻辑 |
|
||||
|------|---------|---------|
|
||||
| 会议时间 | 会议转写文件名 | 从文件名提取日期："20251118134948-转写..." → "2025-11-18" |
|
||||
| 参会人员 | 成员周报文件名列表 | 提取所有周报的作者名：`20251118-闫旭隆周报.md` → "闫旭隆"<br>**规则**：固定"连云波"+交了周报的人即为参会人员 |
|
||||
| 记录整理人 | 固定值 | 固定为"Claude" |
|
||||
|
||||
#### 需要的动作
|
||||
1. 解析会议转写文件名，提取日期并格式化为"YYYY-MM-DD"
|
||||
2. 遍历周报文件名，提取所有姓名并去重，组成参会人员列表
|
||||
3. 自动计算会议次数（根据历史纪要数量）或默认显示"第X次周会"
|
||||
4. 记录整理人固定填写"Claude"
|
||||
|
||||
---
|
||||
|
||||
### 第二部分：学习研究内容
|
||||
|
||||
#### 输出格式
|
||||
```markdown
|
||||
### 1. 议题标题 (分享人)
|
||||
|
||||
**背景与目的：**
|
||||
- 学习来源及理论背景
|
||||
- 研究目的与问题背景
|
||||
|
||||
**核心议题概述：**
|
||||
- 核心观点或理论要点
|
||||
- 关键技术或方法论
|
||||
|
||||
**关键讨论成果：**
|
||||
- 会议讨论中的Q&A
|
||||
- 成员反馈与建议
|
||||
- 形成的共识或结论
|
||||
|
||||
**下一步研究方向：**
|
||||
- 方向1：具体方向描述
|
||||
- 方向2：具体方向描述
|
||||
- 方向3：具体方向描述
|
||||
```
|
||||
|
||||
#### 数据来源映射
|
||||
|
||||
**核心原则**：三个数据源是互补关系，需要合并整合
|
||||
|
||||
| 字段 | 数据来源（互补关系） | 提取与合并逻辑 |
|
||||
|------|---------------------|---------------|
|
||||
| 议题标题 | 周报"P0任务完成情况"+"详细工作内容" + 会议转写议题识别 | 从会议转写识别讨论主题，与周报学习内容匹配去重 |
|
||||
| 分享人 | 周报项目所属作者+会议转写上下文推断 | 从会议转写识别发言人，匹配周报作者 |
|
||||
| 背景与目的 | 周报项目内容描述 + 资料库文档上下文（需要Agent总结精要） | 周报提供学习目的，资料库提供理论背景 |
|
||||
| 核心议题概述 | 周报学习项目总结 + 资料库文档上下文（需要Agent总结精要） | 资料库提供详细理论要点，周报提供简要总结 |
|
||||
| 关键讨论成果 | ⭐会议转写讨论片段 + 周报反思 | 会议转写提取Q&A和讨论结论，周报补充个人反思 |
|
||||
| 下一步研究方向 | 会议转写讨论结论 + 周报下周计划 | 会议讨论中形成的研究方向，结合周报计划 |
|
||||
|
||||
#### 需要的动作
|
||||
|
||||
**说明**：动作1-3由主窗口在 Phase 1.5 执行，动作4-5由 Phase 4 执行。
|
||||
|
||||
**动作1：扫描资料库（主窗口执行）**
|
||||
- `Glob: input/成员本周资料库/*.md`
|
||||
- **轻量读取**：只读取文件名 + 前100行（标题、摘要）
|
||||
- ⚠️ 不读取完整内容，避免污染上下文
|
||||
- 提取：文件名、文档标题、简要描述
|
||||
- 作为"确定学习研究类"的强指引
|
||||
|
||||
**动作2：遍历周报提取项目（主窗口执行）**
|
||||
- 遍历所有周报的"P0任务完成情况"+"详细工作内容"
|
||||
- 对每个项目判断类型：
|
||||
- 检查资料库是否有对应md → `has_library_file=true`
|
||||
- 语义判断是否为学习研究类（知识获取/技能提升 vs 产出交付/功能实现）
|
||||
- 提取：项目名、成员、周报描述
|
||||
|
||||
**动作3：合并去重（主窗口执行）**
|
||||
- 资料库有 + 周报有 → 学习研究类（资料库里有的周报一定有）
|
||||
- 资料库无 + 周报有（语义判断为学习类） → 学习研究类
|
||||
- 去重后构建 `learning_projects` 列表：
|
||||
```python
|
||||
learning_projects = [
|
||||
{
|
||||
"name": "Claude Code Skill学习",
|
||||
"member": "闫旭隆",
|
||||
"has_library_file": true,
|
||||
"library_path": "input/成员本周资料库/xxx.md",
|
||||
"weekly_content": "周报描述..."
|
||||
}
|
||||
]
|
||||
```
|
||||
|
||||
**动作4：提取详细内容（调用 transcript_searcher Agent）**
|
||||
- 主窗口传递 `learning_projects` 给 Agent
|
||||
- Agent 根据 `has_library_file` 字段决定内容来源：
|
||||
- `true`：读取 `library_path` 资料库md + 会议转写
|
||||
- `false`：仅从会议转写上下文推断
|
||||
- Agent 提取：议题标题、分享人、背景与目的、核心议题概述、关键讨论成果、下一步研究方向
|
||||
- **合并规则**：
|
||||
- 背景与目的：周报学习目的 + 资料库/会议背景
|
||||
- 核心议题概述：资料库核心内容（有资料库时）或会议推断（无资料库时）
|
||||
- 关键讨论成果：会议Q&A + 反馈 + 共识
|
||||
- 下一步方向：会议讨论结论 + 周报下周计划
|
||||
|
||||
**动作5：结构化输出（主窗口执行）**
|
||||
- 遍历 Agent 返回的 topics，按模板格式化
|
||||
- 按议题组织内容（通常2-5个议题）
|
||||
- 按讨论顺序或重要性排序
|
||||
- 每个议题独立成节，格式统一
|
||||
|
||||
---
|
||||
|
||||
## 三、关键数据优先级规则总结
|
||||
|
||||
| 字段 | 数据来源 | 优先级规则 | 说明 |
|
||||
|------|---------|-----------|------|
|
||||
| **议题标题** | 会议转写 + 周报 | **会议优先** | 会议中讨论的主题更准确，周报标题作为补充 |
|
||||
| **分享人** | 会议转写推断 + 周报作者 | **会议为准** | 从会议上下文识别实际分享人 |
|
||||
| **背景与目的** | 周报 + 资料库 | **互补合并** | 周报提供学习目的，资料库提供理论背景 |
|
||||
| **核心议题概述** | 资料库 + 周报 | **资料库优先** | 资料库提供详细理论，周报提供简要概括 |
|
||||
| **关键讨论成果** | 会议转写 + 周报 | **会议为主** | 会议讨论内容是核心，周报反思作为补充 |
|
||||
| **下一步方向** | 会议转写 + 周报 | **会议优先** | 会议讨论中形成的方向更明确，周报计划作为补充 |
|
||||
|
||||
---
|
||||
|
||||
## 四、特殊情况处理
|
||||
|
||||
**情况1：资料库文件过大**
|
||||
```
|
||||
资料库中PDF/论文超过50页
|
||||
处理：只提取摘要、引言、结论章节，不读取全文
|
||||
```
|
||||
|
||||
**情况2：多人分享同一主题**
|
||||
```
|
||||
会议中多人共同讨论一个理论/项目
|
||||
处理：分享人标注为"张三、李四"，合并所有人的观点到一个议题
|
||||
```
|
||||
|
||||
**情况3：周报学习内容会议未讨论**
|
||||
```
|
||||
周报中提到的学习内容，但会议中未讨论
|
||||
处理：保留该议题，标注"（未在会议中讨论）"，内容仅基于周报和资料库
|
||||
```
|
||||
|
||||
**情况4：会议讨论内容周报未提及**
|
||||
```
|
||||
会议中临时讨论的学习内容，但周报中未记录
|
||||
处理：保留该议题，基于会议转写提取背景和讨论内容
|
||||
```
|
||||
900
.claude/skills/meeting-minutes-generator-v1/skill.md
Normal file
900
.claude/skills/meeting-minutes-generator-v1/skill.md
Normal file
@ -0,0 +1,900 @@
|
||||
---
|
||||
name: meeting-minutes-generator-v1
|
||||
description: 会议纪要生成器。当用户说"生成会议纪要"、"生成本周纪要"、"会议纪要"时自动触发。根据会议转写、成员周报、上周纪要生成三类结构化会议纪要：工程类、学习研究类、Q&A资源库类。
|
||||
---
|
||||
|
||||
# 会议纪要生成器
|
||||
|
||||
你是专业的会议纪要生成专家，负责编排整个生成流程，调度agents，合并多源数据，输出三类结构化会议纪要。
|
||||
|
||||
## 固化路径配置
|
||||
|
||||
```
|
||||
输入文件位置：
|
||||
- 会议转写：D:\AA_Work\skills合集\AIEC-团队开发规范Skills\.claude\skills\meeting-minutes-generator-v1\input\本周会议转写文本\*.txt
|
||||
- 成员周报：D:\AA_Work\skills合集\AIEC-团队开发规范Skills\.claude\skills\meeting-minutes-generator-v1\input\成员本周周报\*.md
|
||||
- 上周纪要：D:\AA_Work\skills合集\AIEC-团队开发规范Skills\.claude\skills\meeting-minutes-generator-v1\input\上周会议纪要\*.md
|
||||
- 成员资料库：D:\AA_Work\skills合集\AIEC-团队开发规范Skills\.claude\skills\meeting-minutes-generator-v1\input\成员本周资料库\*.md
|
||||
|
||||
临时文件：
|
||||
- 索引文件：D:\AA_Work\skills合集\AIEC-团队开发规范Skills\.claude\skills\meeting-minutes-generator-v1\temp\transcript_index.json
|
||||
|
||||
输出位置：
|
||||
- 工程类：output\工程类会议纪要_{date}_第X次周会.md
|
||||
- 学习研究类：output\学习研究类会议纪要_{date}_第X次周会.md
|
||||
- Q&A资源库类：output\Q&A资源库类会议纪要_{date}_第X次周会.md
|
||||
```
|
||||
|
||||
## 整体流程概览
|
||||
|
||||
```
|
||||
Phase 1: 准备阶段（读取输入、构建索引、区分项目类型）
|
||||
├─ 1.1 初始化目录（temp/、output/）
|
||||
├─ 1.2 读取所有成员周报 → members_data
|
||||
├─ 1.3 读取上周会议纪要 → last_week_p0_tasks
|
||||
├─ 1.4 提取会议日期 → meeting_date, default_deadline
|
||||
├─ 1.5 调用 transcript_indexer Agent → 构建语义索引
|
||||
└─ 1.6 项目类型区分 ⭐新增
|
||||
├─ 扫描资料库（轻量读取，仅标题+前100行）
|
||||
├─ 遍历周报项目 + 语义判断
|
||||
├─ 合并去重
|
||||
└─ 输出：engineering_projects + learning_projects
|
||||
|
||||
Phase 2: 工程类会议纪要生成（仅处理 engineering_projects）
|
||||
├─ 2.1 会议信息（主窗口直接生成）
|
||||
├─ 2.2 重点项目进展汇总（主窗口用周报，仅P0工程类）
|
||||
├─ 2.3 重点项目问题及解决方案（Agent搜索 + 主窗口合并）
|
||||
├─ 2.4 下周工作安排（Agent搜索 + 主窗口排序，仅工程类）
|
||||
├─ 2.5 组内成员工作进展（并行Agents + 主窗口整合，下周任务仅工程类）⭐
|
||||
└─ 2.6 会议总结（Agent搜索 + 主窗口归纳）
|
||||
|
||||
Phase 3: 工程类纪要输出
|
||||
└─ 组装所有章节并写入文件
|
||||
|
||||
Phase 4: 学习研究类会议纪要生成（仅当 learning_projects 非空时执行）
|
||||
├─ 4.1 提取学习研究内容（调用 transcript_searcher）
|
||||
├─ 4.2 整合生成纪要（主窗口）
|
||||
└─ 4.3 输出学习研究类纪要文件
|
||||
|
||||
Phase 5: Q&A资源库类会议纪要生成（二次提取，在 Phase 3/4 之后执行）
|
||||
├─ 前置检查：工程类纪要是否存在（必需）
|
||||
├─ 5.1 复用会议信息（主窗口）
|
||||
├─ 5.2 提取工作问题 Q&A（主窗口）
|
||||
├─ 5.3 提取重点工作方法（调用Agent + 主窗口）
|
||||
└─ 5.4 输出Q&A资源库类纪要文件
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Phase 1: 准备阶段
|
||||
|
||||
### 步骤 1.1: 初始化目录
|
||||
|
||||
**操作**：确保必要目录存在
|
||||
1. 检查/创建 `temp/` 目录（用于存放索引文件）
|
||||
2. 检查/创建 `output/` 目录（用于存放输出文件）
|
||||
|
||||
**路径**：
|
||||
- temp: `D:\AA_Work\skills合集\AIEC-团队开发规范Skills\.claude\skills\meeting-minutes-generator-v1\temp\`
|
||||
- output: `D:\AA_Work\skills合集\AIEC-团队开发规范Skills\.claude\skills\meeting-minutes-generator-v1\output\`
|
||||
|
||||
---
|
||||
|
||||
### 步骤 1.2: 读取成员周报
|
||||
|
||||
**操作**：
|
||||
1. Glob查找周报文件：`D:\AA_Work\skills合集\AIEC-团队开发规范Skills\.claude\skills\meeting-minutes-generator-v1\input\成员本周周报\*.md`
|
||||
2. 对每个周报文件：
|
||||
- 从文件名提取成员姓名（如 `20251118-闫旭隆周报.md` → "闫旭隆"）
|
||||
- Read读取完整内容
|
||||
- 提取关键信息：
|
||||
- P0任务列表（从"P0任务完成情况"表格）
|
||||
- 遇到的问题（从"二、遇到的问题"章节）
|
||||
- 下周计划（从"下周计划"章节）
|
||||
- 已完成任务（从详细工作内容提取带✅的项）
|
||||
- 进行中任务（从详细工作内容提取带🔄的项）
|
||||
|
||||
**构建数据**：
|
||||
- 为每个成员构建包含上述信息的数据结构
|
||||
- 汇总参会人员列表（所有交周报的成员姓名）
|
||||
|
||||
### 步骤 1.3: 读取上周会议纪要
|
||||
|
||||
**操作**：
|
||||
1. Glob查找上周纪要：`D:\AA_Work\skills合集\AIEC-团队开发规范Skills\.claude\skills\meeting-minutes-generator-v1\input\上周会议纪要\*.md`（应只有一个）
|
||||
2. Read读取文件
|
||||
3. 提取"三、下周工作安排"表格中的**所有P0任务**：
|
||||
- 项目名称
|
||||
- 负责人
|
||||
- 截止时间
|
||||
|
||||
**构建数据**：保存上周P0任务列表供后续追踪
|
||||
|
||||
### 步骤 1.4: 提取会议日期
|
||||
|
||||
**操作**：
|
||||
1. Glob查找会议转写文件：`D:\AA_Work\skills合集\AIEC-团队开发规范Skills\.claude\skills\meeting-minutes-generator-v1\input\本周会议转写文本\*.txt`
|
||||
2. 从文件名提取日期并格式化：
|
||||
- 如 `20251118134948-转写...txt` → "2025-11-18"
|
||||
3. 计算默认截止时间：会议日期 + 7天（假设周会频率）
|
||||
|
||||
> ⚠️ **注意**：本步骤只需从 Glob 返回的文件名中提取日期，**不要使用 Read 工具读取转写文件内容**。转写文件内容由步骤1.5的 transcript_indexer Agent 处理。
|
||||
|
||||
### 步骤 1.5: 构建会议转写索引
|
||||
|
||||
**操作**：调用 transcript_indexer Agent
|
||||
|
||||
```python
|
||||
Task(
|
||||
subagent_type="transcript_indexer",
|
||||
description="构建会议转写索引",
|
||||
prompt="构建会议转写索引"
|
||||
)
|
||||
```
|
||||
|
||||
**Agent输出**：
|
||||
- 文件：`D:\AA_Work\skills合集\AIEC-团队开发规范Skills\.claude\skills\meeting-minutes-generator-v1\temp\transcript_index.json`
|
||||
- 返回：简要摘要（如 "✅ 索引构建完成，共N块，识别M个主题"）
|
||||
- 分块参数：每块300行，50行重叠，即每块从+250位置开始
|
||||
|
||||
**验证**：检查索引文件是否存在
|
||||
|
||||
---
|
||||
|
||||
### 步骤 1.6: 项目类型区分 ⭐新增
|
||||
|
||||
**操作**：
|
||||
1. 扫描资料库：`Glob: input/成员本周资料库/*.md`
|
||||
2. **轻量读取资料库**（仅用于判断，避免污染上下文）：
|
||||
- 只读取文件名 + 前100行（标题、摘要）
|
||||
- 提取：文件名、文档标题、简要描述
|
||||
- ⚠️ 不读取完整内容，详细内容由 Phase 4 Agent 按需读取
|
||||
3. 遍历 `members_data` 中所有项目（P0任务 + 详细工作内容）
|
||||
4. 对每个项目判断类型：
|
||||
- 资料库有对应md → 学习研究类
|
||||
- 语义判断（知识获取/技能提升 vs 产出交付/功能实现）
|
||||
5. 合并去重（资料库有的周报一定有）
|
||||
|
||||
**构建数据**：
|
||||
```python
|
||||
# 工程类项目（供 Phase 2-3 使用）
|
||||
engineering_projects = [
|
||||
{"name": "项目A", "member": "闫旭隆", "p0_tasks": [...], "problems": [...]}
|
||||
]
|
||||
|
||||
# 学习研究类项目（供 Phase 4 使用）
|
||||
learning_projects = [
|
||||
{
|
||||
"name": "Claude Code Skill学习",
|
||||
"member": "闫旭隆",
|
||||
"has_library_file": True,
|
||||
"library_path": "input/成员本周资料库/xxx.md",
|
||||
"weekly_content": "周报描述..."
|
||||
}
|
||||
]
|
||||
```
|
||||
|
||||
**判断结果**：
|
||||
- `learning_projects` 非空 → Phase 4 执行
|
||||
- `learning_projects` 为空 → Phase 4 跳过
|
||||
|
||||
---
|
||||
|
||||
## Phase 2: 工程类会议纪要生成
|
||||
|
||||
> ⚠️ **本阶段仅处理工程类项目**（`engineering_projects`），学习研究类项目由 Phase 4 处理
|
||||
|
||||
### 步骤 2.1: 生成"一、会议信息"
|
||||
|
||||
**数据来源**：主窗口已有数据（会议日期、参会人员）
|
||||
|
||||
**处理逻辑**：
|
||||
- 填充会议时间
|
||||
- 填充参会人员列表（用顿号分隔）
|
||||
- 记录整理人固定为"Claude"
|
||||
|
||||
**无需Agent**，主窗口直接生成 ✅
|
||||
|
||||
---
|
||||
|
||||
### 步骤 2.2: 生成"### 1. 重点项目进展情况汇总"
|
||||
|
||||
**核心原则**：⭐ **仅展示工程类P0任务，非P0任务和学习研究类项目不在此处展示**
|
||||
|
||||
**数据来源**：
|
||||
1. 上周纪要的P0任务
|
||||
2. 本周周报的P0任务
|
||||
|
||||
**处理逻辑**：
|
||||
|
||||
**1. 收集所有P0任务（取并集）**：
|
||||
- 上周P0任务必须全部包含，初始状态标记为"待查询"
|
||||
- 本周周报的P0任务，语义去重后添加
|
||||
- 语义匹配规则：任务相似度 >85% 认为是同一任务
|
||||
|
||||
**2. 查询进展情况**：
|
||||
- 在本周周报中找到该任务 → 填写周报中的状态和备注
|
||||
- 在本周周报中未找到 → 标记"未完成（上周计划本周未在周报中体现）"
|
||||
- 负责人处理：合并上周和本周的负责人（多人时用顿号分隔）
|
||||
- 截止时间：周报优先，周报无则用上周纪要
|
||||
|
||||
**3. 生成表格**：
|
||||
- 输出格式：| 项目名称 | 负责人 | 截止时间 | 项目进展情况 |
|
||||
- 按项目顺序排列
|
||||
|
||||
**无需Agent**，主窗口直接处理 ✅
|
||||
|
||||
---
|
||||
|
||||
### 步骤 2.3: 生成"### 2. 重点项目问题及解决方案"
|
||||
|
||||
**核心原则**：会议转写与周报互补，合并信息
|
||||
|
||||
#### 2.3.1: 提取会议问题讨论（调用Agent）
|
||||
|
||||
**操作**：调用 transcript_searcher Agent
|
||||
|
||||
```python
|
||||
# 准备已知问题列表（来自周报）
|
||||
known_problems = []
|
||||
for member, data in members_data.items():
|
||||
for problem in data["problems"]:
|
||||
known_problems.append({
|
||||
"member": member,
|
||||
"description": problem["description"],
|
||||
"solution": problem.get("solution", "")
|
||||
})
|
||||
|
||||
# 调用Agent
|
||||
Task(
|
||||
subagent_type="transcript_searcher",
|
||||
description="提取问题讨论",
|
||||
prompt=f"""提取会议中讨论的所有问题及解决方案。
|
||||
|
||||
会议日期：{meeting_date}
|
||||
默认截止时间：{default_deadline}（下次周会前）
|
||||
|
||||
已知问题（来自周报）：
|
||||
{json.dumps(known_problems, ensure_ascii=False, indent=2)}
|
||||
|
||||
请提取会议中讨论的问题，包括：
|
||||
- 问题标题
|
||||
- 问题详细描述
|
||||
- 解决方案（列表形式）
|
||||
- 责任人（从讨论上下文语义推断）
|
||||
- 截止时间（明确时间或null，无明确时间则使用默认截止时间）
|
||||
|
||||
返回JSON格式（类型2：提取问题讨论）。
|
||||
"""
|
||||
)
|
||||
```
|
||||
|
||||
**Agent返回**（JSON字符串，实际数据在`data`字段内）：
|
||||
```json
|
||||
{
|
||||
"search_intent": "提取问题讨论",
|
||||
"matched_blocks": [2, 4],
|
||||
"data": {
|
||||
"problems": [
|
||||
{
|
||||
"problem_title": "会议纪要信息提取准确性问题",
|
||||
"problem_description": "...",
|
||||
"solutions": ["方案1", "方案2"],
|
||||
"assignees": ["江争达", "郝倩玉"],
|
||||
"deadline": "2025-11-25"
|
||||
}
|
||||
]
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
#### 2.3.2: 合并周报与会议问题（主窗口）
|
||||
|
||||
**处理逻辑**：
|
||||
|
||||
**1. 合并去重**：
|
||||
- 将会议提取的问题与周报问题进行语义匹配（相似度>80%）
|
||||
- 匹配成功：合并信息
|
||||
- 问题描述：会议的详细描述 + 周报的简述
|
||||
- 解决方案：合并两者的方案列表
|
||||
- 责任人：以会议判断为准
|
||||
- 截止时间：会议优先，无则用默认截止时间
|
||||
- 未匹配：保留为独立问题
|
||||
|
||||
**2. 补充周报独有问题**：
|
||||
- 周报中的问题在会议中未讨论 → 添加到问题列表
|
||||
- 解决方案：若周报有则填写，无则标记"待讨论"
|
||||
- 责任人：问题提出人（周报作者）
|
||||
- 截止时间：默认截止时间
|
||||
|
||||
**3. 生成输出**：
|
||||
- 按问题编号生成章节
|
||||
- 格式：#### 问题N: 标题
|
||||
- 包含：问题描述、解决方案列表、责任人、截止时间
|
||||
|
||||
---
|
||||
|
||||
### 步骤 2.4: 生成"### 3. 下周工作安排"
|
||||
|
||||
**核心原则**：仅工程类项目，会议+周报互补，冲突时会议优先，按P0→P1→P2排序
|
||||
|
||||
#### 2.4.1: 提取会议任务安排（调用Agent）
|
||||
|
||||
**操作**：
|
||||
```python
|
||||
Task(
|
||||
subagent_type="transcript_searcher",
|
||||
description="提取任务安排",
|
||||
prompt=f"""提取会议中讨论的下周工作安排。
|
||||
|
||||
会议日期：{meeting_date}
|
||||
默认截止时间：{default_deadline}（下次周会前）
|
||||
|
||||
已知P0任务（上周计划）：
|
||||
{json.dumps([t["name"] for t in last_week_p0_tasks], ensure_ascii=False)}
|
||||
|
||||
请提取任务安排，包括：
|
||||
- 任务名称
|
||||
- 负责人
|
||||
- 任务描述
|
||||
- 优先级（从讨论语气判断P0/P1/P2）
|
||||
- P0：领导明确强调"优先"、"重点"、"紧急"，或反复讨论
|
||||
- P1：一般性安排、常规任务
|
||||
- P2：探索性任务、长期优化、低优先级
|
||||
- 截止时间（明确时间或null）
|
||||
|
||||
返回JSON格式（类型1：提取任务安排）。
|
||||
"""
|
||||
)
|
||||
```
|
||||
|
||||
**Agent返回**（实际数据在`data`字段内）：
|
||||
```json
|
||||
{
|
||||
"search_intent": "提取任务安排",
|
||||
"matched_blocks": [1, 3, 5],
|
||||
"data": {
|
||||
"tasks": [
|
||||
{
|
||||
"task_name": "Deepresearch Skill开发",
|
||||
"assignees": ["闫旭隆"],
|
||||
"description": "实现知识图谱增量更新",
|
||||
"priority": "P0",
|
||||
"deadline": null
|
||||
}
|
||||
]
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
#### 2.4.2: 合并周报与会议任务（主窗口）
|
||||
|
||||
**处理逻辑**：
|
||||
|
||||
**1. 整合任务列表**：
|
||||
- 会议任务：直接添加，保留Agent判断的优先级和截止时间
|
||||
- 周报任务：会议未提及的添加，默认优先级P1，默认截止时间
|
||||
- 去重规则：语义匹配，相似度>85%认为同一任务
|
||||
|
||||
**2. 冲突处理**：
|
||||
- 同一任务的负责人冲突 → 以会议为准
|
||||
- 同一任务的优先级冲突 → 以会议为准
|
||||
- 同一任务的截止时间冲突 → 以会议为准
|
||||
|
||||
**3. 保存数据**：
|
||||
- 保存合并后的任务列表 `next_week_tasks`
|
||||
- ⭐ 重要：步骤2.5和2.6会使用这个列表
|
||||
|
||||
#### 2.4.3: 优先级排序
|
||||
|
||||
**核心规则**：P0任务在前，P1居中，P2在后
|
||||
|
||||
**排序步骤**：
|
||||
1. 按优先级分组：P0组、P1组、P2组
|
||||
2. 组内按截止时间排序（早的在前）
|
||||
3. 合并：P0 + P1 + P2
|
||||
|
||||
**生成表格**：
|
||||
- 表头：| 项目名称 | 负责人 | 下周会前目标 | 优先级 | 截止时间 |
|
||||
- P0任务前加 🔴 emoji
|
||||
- 负责人多人时用顿号分隔
|
||||
|
||||
---
|
||||
|
||||
### 步骤 2.5: 生成"### 4. 组内成员工作进展"
|
||||
|
||||
**核心原则**：并行提取反馈，主窗口整合；**下周任务仅列工程类项目**
|
||||
|
||||
#### 2.5.1: 并行提取成员反馈（调用多个Agents）⭐
|
||||
|
||||
**操作**：一次性并行调用多个 transcript_searcher Agents
|
||||
|
||||
```python
|
||||
# 为每个成员并行调用Agent
|
||||
feedback_agents = []
|
||||
|
||||
for member in attendees:
|
||||
member_data = members_data[member]
|
||||
|
||||
feedback_agents.append(
|
||||
Task(
|
||||
subagent_type="transcript_searcher",
|
||||
description=f"提取{member}反馈",
|
||||
prompt=f"""提取会议中对 {member} 的反馈（表扬/批评/建议）。
|
||||
|
||||
{member}的周报信息：
|
||||
- P0任务：{[t['name'] for t in member_data['p0_tasks']]}
|
||||
- 遇到问题：{[p['description'] for p in member_data['problems']]}
|
||||
|
||||
请提取会议中对该成员的反馈，包括：
|
||||
- 反馈类型（表扬/批评/建议）
|
||||
- 反馈内容
|
||||
|
||||
注意：
|
||||
1. 不依赖说话人标记，通过语义识别（讨论该成员的工作、对该成员的评价）
|
||||
2. 如果会议中未提及该成员，返回空列表
|
||||
|
||||
返回JSON格式（类型4：提取成员反馈）。
|
||||
"""
|
||||
)
|
||||
)
|
||||
|
||||
# 等待所有Agent返回
|
||||
feedback_results = [agent.result for agent in feedback_agents]
|
||||
```
|
||||
|
||||
**Agent返回示例**（实际数据在`data`字段内）：
|
||||
```json
|
||||
{
|
||||
"search_intent": "提取江争达的反馈",
|
||||
"matched_blocks": [2, 4],
|
||||
"data": {
|
||||
"member": "江争达",
|
||||
"feedbacks": [
|
||||
{"type": "批评", "content": "..."},
|
||||
{"type": "建议", "content": "..."}
|
||||
]
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
#### 2.5.2: 整合成员信息（主窗口）
|
||||
|
||||
**处理逻辑**：
|
||||
|
||||
对每个成员，整合以下信息生成章节：
|
||||
|
||||
**1. 上周完成**：
|
||||
- 从周报提取已完成任务列表（带✅标记的项）
|
||||
|
||||
**2. 进行中**：
|
||||
- 从周报提取进行中任务列表（带🔄标记的项）
|
||||
|
||||
**3. 收到的反馈/学习建议**：
|
||||
- 从并行Agent返回结果中匹配该成员的反馈
|
||||
- 如无反馈则显示"- 无"
|
||||
|
||||
**4. 下周任务**：
|
||||
- 从 `next_week_tasks` 筛选该成员负责的任务
|
||||
- 合并周报"下周计划"中的任务（语义去重）
|
||||
- 按优先级排序：P0 → P1 → P2
|
||||
- 格式：`- [ ] 🔴 P0|任务名称`（P0任务加红点，无空格）
|
||||
|
||||
**生成格式**：
|
||||
- 每个成员一个四级标题
|
||||
- 四个子部分按上述顺序排列
|
||||
|
||||
---
|
||||
|
||||
### 步骤 2.6: 生成"三、会议总结"
|
||||
|
||||
**核心原则**：提取决策 + 归纳总结
|
||||
|
||||
#### 2.6.1: 提取关键决策（调用Agent）
|
||||
|
||||
**操作**：
|
||||
```python
|
||||
Task(
|
||||
subagent_type="transcript_searcher",
|
||||
description="提取决策事项",
|
||||
prompt="""提取会议中的所有关键决策。
|
||||
|
||||
特征词："决定"、"确定"、"采用"、"要求"、"必须"、"不准"
|
||||
|
||||
请提取决策事项，包括：
|
||||
- 决策内容
|
||||
- 决策上下文
|
||||
|
||||
返回JSON格式（类型3：提取决策事项）。
|
||||
"""
|
||||
)
|
||||
```
|
||||
|
||||
**Agent返回**（实际数据在`data`字段内）：
|
||||
```json
|
||||
{
|
||||
"search_intent": "提取决策事项",
|
||||
"matched_blocks": [3, 6],
|
||||
"data": {
|
||||
"decisions": [
|
||||
{
|
||||
"decision": "采用Claude Code Skill架构",
|
||||
"context": "Deepresearch框架选型讨论"
|
||||
}
|
||||
]
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
#### 2.6.2: 归纳总结（主窗口）
|
||||
|
||||
**处理逻辑**：
|
||||
|
||||
**1. 核心议题**：
|
||||
- 从 `next_week_tasks` 提取项目名称
|
||||
- 统计高频项目（简化项目名，提取核心关键词）
|
||||
- 选取出现频率最高的前3个项目
|
||||
- 用顿号连接
|
||||
|
||||
**2. 关键决策**：
|
||||
- 直接使用Agent提取的决策列表
|
||||
- 按序号格式化输出
|
||||
|
||||
**3. 下周工作重点**：
|
||||
- 从 `next_week_tasks` 筛选所有P0任务
|
||||
- 按序号列表格式输出
|
||||
|
||||
**生成格式**：
|
||||
- 章节标题：## 三、会议总结
|
||||
- 三个子部分：核心议题、关键决策、下周工作重点
|
||||
|
||||
---
|
||||
|
||||
## Phase 3: 最终输出
|
||||
|
||||
### 步骤 3.1: 组装完整文档
|
||||
|
||||
**操作**：
|
||||
- 按顺序拼接所有生成的章节
|
||||
- 标题格式：# 工程类会议纪要-{日期}-第X次周会
|
||||
- 章节顺序：
|
||||
1. 一、会议信息
|
||||
2. 二、工作内容（包含4个子章节）
|
||||
3. 三、会议总结
|
||||
- 添加页脚信息：纪要整理人、纪要时间、下次会议时间
|
||||
|
||||
### 步骤 3.2: 写入文件
|
||||
|
||||
**操作**：
|
||||
- 确定文件名：`工程类会议纪要_{日期}_第X次周会.md`
|
||||
- 输出路径：`D:\AA_Work\skills合集\AIEC-团队开发规范Skills\.claude\skills\meeting-minutes-generator-v1\output\`
|
||||
- 使用Write工具写入文件
|
||||
|
||||
### 步骤 3.3: 返回结果
|
||||
|
||||
**返回给用户**：
|
||||
- 显示完成状态
|
||||
- 汇总统计信息：
|
||||
- 会议时间
|
||||
- 参会人数
|
||||
- P0任务数
|
||||
- 问题讨论数
|
||||
- 下周任务总数
|
||||
- 显示输出文件路径
|
||||
|
||||
---
|
||||
|
||||
## Phase 4: 学习研究类会议纪要生成
|
||||
|
||||
> ⚠️ **仅当 `learning_projects` 非空时执行本阶段**
|
||||
|
||||
### 步骤 4.1: 提取学习研究内容（调用 Agent）
|
||||
|
||||
**操作**：
|
||||
```python
|
||||
Task(
|
||||
subagent_type="transcript_searcher",
|
||||
description="提取学习研究讨论",
|
||||
prompt=f"""提取会议中的学习研究类讨论内容。
|
||||
|
||||
学习研究类项目列表：
|
||||
{json.dumps(learning_projects, ensure_ascii=False)}
|
||||
|
||||
请为每个项目提取：
|
||||
- 议题标题（会议中讨论的主题）
|
||||
- 分享人（语义推断）
|
||||
- 背景与目的
|
||||
- 核心议题概述
|
||||
- 关键讨论成果（Q&A、反馈、共识）
|
||||
- 下一步研究方向
|
||||
|
||||
注意：
|
||||
1. has_library_file=true 的项目，核心内容从资料库提取
|
||||
2. has_library_file=false 的项目，从会议转写上下文推断
|
||||
3. 资料库路径已固化，Agent 自行读取
|
||||
|
||||
返回JSON格式（类型5：提取学习研究内容）。
|
||||
"""
|
||||
)
|
||||
```
|
||||
|
||||
**Agent 返回**：
|
||||
```json
|
||||
{
|
||||
"search_intent": "提取学习研究内容",
|
||||
"matched_blocks": [2, 5],
|
||||
"data": {
|
||||
"topics": [
|
||||
{
|
||||
"title": "Claude Code Skill开发规范",
|
||||
"presenter": "闫旭隆",
|
||||
"background": "...",
|
||||
"overview": "...",
|
||||
"discussions": ["Q1...", "A1..."],
|
||||
"next_steps": ["方向1", "方向2"]
|
||||
}
|
||||
]
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
### 步骤 4.2: 整合生成纪要（主窗口）
|
||||
|
||||
**处理逻辑**：
|
||||
1. **会议信息**：复用 Phase 2.1 的数据
|
||||
2. **学习研究内容**：遍历 Agent 返回的 `data.topics`，按模板格式化
|
||||
|
||||
**输出格式**（每个议题）：
|
||||
```markdown
|
||||
### {序号}. {title} ({presenter})
|
||||
|
||||
**背景与目的：**
|
||||
- {background}
|
||||
|
||||
**核心议题概述：**
|
||||
- {overview}
|
||||
|
||||
**关键讨论成果：**
|
||||
- {discussions 列表}
|
||||
|
||||
**下一步研究方向：**
|
||||
- {next_steps 列表}
|
||||
```
|
||||
|
||||
### 步骤 4.3: 输出学习研究类纪要文件
|
||||
|
||||
**操作**：
|
||||
- 确定文件名：`学习研究类会议纪要_{日期}_第X次周会.md`
|
||||
- 输出路径：`D:\AA_Work\skills合集\AIEC-团队开发规范Skills\.claude\skills\meeting-minutes-generator-v1\output\`
|
||||
- 使用 Write 工具写入文件
|
||||
|
||||
**返回给用户**：
|
||||
- 显示学习研究类纪要完成状态
|
||||
- 显示议题数量
|
||||
- 显示输出文件路径
|
||||
|
||||
---
|
||||
|
||||
## Phase 5: Q&A资源库类会议纪要生成
|
||||
|
||||
> ⚠️ **二次提取产物**：在 Phase 3（工程类）和 Phase 4（学习研究类）之后执行
|
||||
>
|
||||
> **依赖**：已生成的工程类会议纪要（必需）
|
||||
|
||||
### 前置检查
|
||||
|
||||
**操作**：
|
||||
1. 检查 `output/` 目录下是否存在本次会议的工程类纪要文件
|
||||
2. 如不存在 → 提示用户先生成工程类纪要，跳过 Phase 5
|
||||
3. 如存在 → 继续执行
|
||||
|
||||
---
|
||||
|
||||
### 步骤 5.1: 复用会议信息（主窗口）
|
||||
|
||||
**数据来源**：已生成的工程类会议纪要
|
||||
|
||||
**操作**：
|
||||
1. 读取工程类纪要文件
|
||||
2. 提取"一、会议信息"章节内容
|
||||
3. 直接复用，格式保持一致
|
||||
|
||||
**无需Agent**，主窗口直接处理 ✅
|
||||
|
||||
---
|
||||
|
||||
### 步骤 5.2: 提取工作问题 Q&A（主窗口）
|
||||
|
||||
**核心原则**：从已生成的纪要文件中提取，非原始转写
|
||||
|
||||
#### 5.2.1: 从工程类纪要提取问题
|
||||
|
||||
**操作**：
|
||||
1. 定位"### 2. 重点项目问题及解决方案"章节
|
||||
2. 解析每个问题块：
|
||||
- 问题标题（作为项目名称）
|
||||
- 问题描述（精简为主要问题）
|
||||
- 解决方案列表
|
||||
|
||||
#### 5.2.2: 从学习研究类纪要提取 Q&A（可选）
|
||||
|
||||
**操作**（如学习研究类纪要存在）：
|
||||
1. 定位每个议题的"关键讨论成果"部分
|
||||
2. 识别 Q&A 格式内容
|
||||
|
||||
#### 5.2.3: 合并去重
|
||||
|
||||
**处理逻辑**：
|
||||
- 语义匹配（相似度 > 80%）视为同一问题，合并解决方案
|
||||
- 按项目分组，同一项目多个问题归类在一起
|
||||
- 格式化输出：`### {序号}. 项目名称：{project_name}`
|
||||
|
||||
**无需Agent**，主窗口直接处理 ✅
|
||||
|
||||
---
|
||||
|
||||
### 步骤 5.3: 提取重点工作方法（调用Agent + 主窗口）
|
||||
|
||||
**核心原则**：会议转写 + 周报，两者结合
|
||||
|
||||
#### 5.3.1: 从会议转写提取方法分享（调用Agent）
|
||||
|
||||
**操作**：
|
||||
```python
|
||||
Task(
|
||||
subagent_type="transcript_searcher",
|
||||
description="提取工作方法",
|
||||
prompt="""提取会议中分享的工作方法、技巧、最佳实践。
|
||||
|
||||
识别特征：
|
||||
- 方法论讲解（"方法是..."、"技巧是..."）
|
||||
- 经验分享（"我的做法是..."、"建议..."）
|
||||
- 总结性语句（"总结一下..."、"关键是..."）
|
||||
|
||||
需提取字段：
|
||||
- 方法名称（简短标题）
|
||||
- 方法描述（详细说明）
|
||||
- 提出人（从上下文推断）
|
||||
- 相关项目
|
||||
|
||||
返回JSON格式（类型6：提取工作方法）。
|
||||
"""
|
||||
)
|
||||
```
|
||||
|
||||
**Agent返回**（实际数据在`data`字段内）：
|
||||
```json
|
||||
{
|
||||
"search_intent": "提取工作方法",
|
||||
"matched_blocks": [2, 5],
|
||||
"data": {
|
||||
"methods": [
|
||||
{
|
||||
"name": "语义分析替代说话人标记",
|
||||
"description": "通过分析发言内容的语义特征来判断发言者",
|
||||
"presenter": "连云波",
|
||||
"related_project": "会议纪要信息提取"
|
||||
}
|
||||
]
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
#### 5.3.2: 从周报提取经验总结（主窗口）
|
||||
|
||||
**操作**：
|
||||
- 遍历 `members_data` 中"详细工作内容"
|
||||
- 识别方法论/经验总结内容（带"方法"、"技巧"、"经验"等关键词的段落）
|
||||
|
||||
#### 5.3.3: 合并整理（主窗口）
|
||||
|
||||
**处理逻辑**：
|
||||
- 将会议方法与周报方法进行语义匹配
|
||||
- 相似方法合并，补充细节
|
||||
- 为每个方法生成完整结构：
|
||||
- 方法标题
|
||||
- 方法描述（合并会议详细讲解 + 周报简要描述）
|
||||
- 适用场景（从会议讨论上下文推断）
|
||||
- 关键要点（提炼为3-5条）
|
||||
|
||||
**输出格式**：
|
||||
```markdown
|
||||
- **方法 {序号}：{方法标题}**
|
||||
- {方法描述}
|
||||
- 适用场景：{场景描述}
|
||||
- 关键要点：
|
||||
- {要点1}
|
||||
- {要点2}
|
||||
- {要点3}
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
### 步骤 5.4: 输出Q&A资源库类纪要文件
|
||||
|
||||
**操作**：
|
||||
1. 组装所有章节：
|
||||
- 一、会议信息（复用）
|
||||
- 二、工作问题 Q&A
|
||||
- 三、重点工作方法
|
||||
2. 确定文件名：`Q&A资源库类会议纪要_{日期}_第X次周会.md`
|
||||
3. 输出路径：`D:\AA_Work\skills合集\AIEC-团队开发规范Skills\.claude\skills\meeting-minutes-generator-v1\output\`
|
||||
4. 使用 Write 工具写入文件
|
||||
|
||||
**特殊情况处理**：
|
||||
| 情况 | 处理方式 |
|
||||
|------|---------|
|
||||
| 工程类纪要无问题章节 | Q&A章节输出"本次会议无记录的问题讨论" |
|
||||
| 会议中无方法分享 | 若周报有经验总结则使用，否则输出"本次会议无记录的方法分享" |
|
||||
|
||||
**返回给用户**：
|
||||
- 显示Q&A资源库类纪要完成状态
|
||||
- 显示Q&A数量、方法数量
|
||||
- 显示输出文件路径
|
||||
|
||||
---
|
||||
|
||||
## 关键辅助函数
|
||||
|
||||
### is_same_task(task1, task2)
|
||||
判断两个任务是否为同一任务（语义相似度 > 85%）
|
||||
|
||||
### is_similar_problem(desc1, desc2)
|
||||
判断两个问题是否相似（语义相似度 > 80%）
|
||||
|
||||
### merge_assignees(list1, list2)
|
||||
合并负责人列表并去重
|
||||
|
||||
### extract_project_name(task_name)
|
||||
从任务名称提取核心项目关键词
|
||||
|
||||
---
|
||||
|
||||
## 项目类型区分规则
|
||||
|
||||
**核心问题**：周报中没有"学习类"/"工程类"标签，两类项目都混在"P0任务完成情况"和"详细工作内容"中。
|
||||
|
||||
**区分方法**：
|
||||
1. **资料库指引** ⭐：项目在 `input/成员本周资料库/` 下有对应md文件 → 学习研究类
|
||||
2. **语义判断**：根据任务性质（知识获取/技能提升 vs 产出交付/功能实现）语义判断
|
||||
|
||||
**背景**：成员会以周报为顶层，讲到学习内容时打开资料库里的md进行分享，资料库中的项目通常是学习研究类。
|
||||
|
||||
---
|
||||
|
||||
## 注意事项
|
||||
|
||||
1. **优先级一致性**：
|
||||
- 项目进展：仅P0
|
||||
- 下周安排：P0/P1/P2按顺序
|
||||
- 成员进展：每人下周任务按P0→P1→P2排序
|
||||
|
||||
2. **数据互补原则**：
|
||||
- 问题：会议详细分析 + 周报初步描述
|
||||
- 任务：会议分配 + 周报计划，冲突时会议优先
|
||||
|
||||
3. **语义识别**：
|
||||
- 转写说话人标记不可靠
|
||||
- 责任人、优先级、反馈对象都需语义推断
|
||||
|
||||
4. **并行执行**：
|
||||
- 仅步骤2.5成员反馈提取并行（4-5个Agents）
|
||||
- 其他步骤串行执行（有数据依赖）
|
||||
|
||||
5. **默认值处理**：
|
||||
- 截止时间：会议日期 + 7天
|
||||
- 优先级：会议未提及的周报任务默认P1
|
||||
|
||||
6. **Agent返回数据解析**：
|
||||
- 所有transcript_searcher返回的JSON结构为：`{search_intent, matched_blocks, data}`
|
||||
- 实际业务数据在`data`字段内，需通过`result.data.xxx`访问
|
||||
- 示例：`result.data.problems`、`result.data.tasks`、`result.data.decisions`
|
||||
|
||||
---
|
||||
|
||||
## 根本逻辑文档
|
||||
|
||||
本 Skill 的详细执行逻辑（包括每个章节的数据来源、处理规则、输出格式），有任何问题请查阅：
|
||||
- **工程类**：`references/detailed_logic.md`
|
||||
- **学习研究类**：`references/学习研究类会议纪要生成逻辑.md`
|
||||
- **Q&A资源库类**：`references/Q&A资源库类会议纪要生成逻辑.md`
|
||||
@ -0,0 +1,115 @@
|
||||
{
|
||||
"meta": {
|
||||
"transcript_path": "D:\\AA_Work\\skills合集\\AIEC-团队开发规范Skills\\.claude\\skills\\meeting-minutes-generator-v1\\input\\本周会议转写文本\\20251125135528-信通院云大所市场部-张媛媛预定的会议-转写智能优化版-1.txt",
|
||||
"total_lines": 1642,
|
||||
"total_blocks": 7,
|
||||
"processed_at": "2025-11-25T14:30:00",
|
||||
"known_entities": {
|
||||
"people": ["闫旭隆", "江争达", "陶西平", "郝倩玉", "连云波", "张媛媛"],
|
||||
"projects": [
|
||||
"会议纪要Skill开发",
|
||||
"需求文档Skill优化",
|
||||
"公众号信息获取",
|
||||
"数字人生成",
|
||||
"问答系统V1.1",
|
||||
"DeepResearch",
|
||||
"招投标文件Skill",
|
||||
"天眼查自动化",
|
||||
"日报驱动系统"
|
||||
]
|
||||
}
|
||||
},
|
||||
"blocks": [
|
||||
{
|
||||
"block_id": 1,
|
||||
"lines": "0-299",
|
||||
"participants": ["张媛媛", "闫旭隆"],
|
||||
"topics": ["会议纪要Skill开发现状", "会议仪表盘讨论", "P0项目定义问题"],
|
||||
"projects": ["会议纪要Skill开发"],
|
||||
"has_task_assignment": false,
|
||||
"has_problem_discussion": true,
|
||||
"has_decision": true,
|
||||
"has_feedback": true,
|
||||
"key_phrases": ["会议纪要", "仪表盘", "P0项目", "逻辑复杂", "数据一致性", "负责人变更"],
|
||||
"summary": "讨论会议纪要Skill的第一版实现效果,发现数据映射、负责人更新、P0项目识别等逻辑问题,需要参考会议转写进行状态更新"
|
||||
},
|
||||
{
|
||||
"block_id": 2,
|
||||
"lines": "250-549",
|
||||
"participants": ["张媛媛", "闫旭隆"],
|
||||
"topics": ["会议纪要数据来源", "主窗口与Agent架构", "转写文本处理方案"],
|
||||
"projects": ["会议纪要Skill架构优化"],
|
||||
"has_task_assignment": true,
|
||||
"has_problem_discussion": true,
|
||||
"has_decision": true,
|
||||
"has_feedback": false,
|
||||
"key_phrases": ["数据来源", "主窗口上下文", "全量加载", "分块读取", "索引构建", "搜索命中率"],
|
||||
"summary": "讨论Skill架构,分析分块索引搜索vs全量加载方案,建议简化逻辑改用主窗口直接处理全文,提高准确性"
|
||||
},
|
||||
{
|
||||
"block_id": 3,
|
||||
"lines": "500-799",
|
||||
"participants": ["张媛媛", "闫旭隆", "江争达"],
|
||||
"topics": ["会议纪要架构设计", "Agent协作模式", "上下文管理"],
|
||||
"projects": ["会议纪要Skill重构方案"],
|
||||
"has_task_assignment": true,
|
||||
"has_problem_discussion": true,
|
||||
"has_decision": true,
|
||||
"has_feedback": false,
|
||||
"key_phrases": ["主窗口协调", "子Agent全量处理", "并行调用", "功能模块划分", "准确性优先"],
|
||||
"summary": "确定架构优化方向:主窗口负责协调,每个子Agent获得全量上下文独立处理一个功能模块,提升准确性"
|
||||
},
|
||||
{
|
||||
"block_id": 4,
|
||||
"lines": "750-1049",
|
||||
"participants": ["张媛媛", "江争达", "陶西平"],
|
||||
"topics": ["数字人PPT需求讨论", "需求文档质量问题", "PPT动态切换"],
|
||||
"projects": ["数字人PPT讲解视频"],
|
||||
"has_task_assignment": true,
|
||||
"has_problem_discussion": true,
|
||||
"has_decision": true,
|
||||
"has_feedback": true,
|
||||
"key_phrases": ["需求提炼", "默认需求vs核心需求", "动态切换", "口型对应", "需求层次"],
|
||||
"summary": "严厉批评数字人需求文档,强调需求提炼能力:区分默认需求与核心难点需求,不能罗列所有功能,需深度挖掘用户真实痛点"
|
||||
},
|
||||
{
|
||||
"block_id": 5,
|
||||
"lines": "1000-1299",
|
||||
"participants": ["张媛媛", "江争达"],
|
||||
"topics": ["日报驱动系统构想", "项目管理工具整合", "AI Native团队建设"],
|
||||
"projects": ["日报驱动系统", "AI Native组织"],
|
||||
"has_task_assignment": true,
|
||||
"has_problem_discussion": true,
|
||||
"has_decision": false,
|
||||
"has_feedback": false,
|
||||
"key_phrases": ["会议纪要驱动日报", "Linear项目管理", "MCP集成", "语音交互", "系统化需求"],
|
||||
"summary": "讨论通过会议纪要驱动日报的系统化需求,强调需先建立完整框架,整合Linear项目管理工具,实现AI Native自动化工作流"
|
||||
},
|
||||
{
|
||||
"block_id": 6,
|
||||
"lines": "1250-1549",
|
||||
"participants": ["张媛媛", "闫旭隆", "陶西平"],
|
||||
"topics": ["需求文档Skill迭代", "专家评审机制", "模型选择优化"],
|
||||
"projects": ["需求文档Skill优化", "cc-switch调研"],
|
||||
"has_task_assignment": true,
|
||||
"has_problem_discussion": true,
|
||||
"has_decision": true,
|
||||
"has_feedback": true,
|
||||
"key_phrases": ["交互中断", "专家博弈", "领域专家识别", "模型差异化使用", "opus vs sonnet"],
|
||||
"summary": "演示需求文档Skill优化版本,增加交互澄清、专家自动整合等功能,讨论多轮专家博弈机制和不同模型的差异化使用"
|
||||
},
|
||||
{
|
||||
"block_id": 7,
|
||||
"lines": "1500-1642",
|
||||
"participants": ["张媛媛", "江争达", "郝倩玉"],
|
||||
"topics": ["任务安排", "问答系统测试", "PDF Skill调研", "招投标Skill分工"],
|
||||
"projects": ["问答系统V1.1", "招投标文件Skill", "PDF处理Skill"],
|
||||
"has_task_assignment": true,
|
||||
"has_problem_discussion": false,
|
||||
"has_decision": true,
|
||||
"has_feedback": false,
|
||||
"key_phrases": ["任务分配", "前端重构", "需求确认", "明天会议", "学习资料整理"],
|
||||
"summary": "布置后续任务:会议纪要生成测试、cosmos流程整理、问答系统前端重构、PDF Skill技术调研、招投标Skill架构设计"
|
||||
}
|
||||
]
|
||||
}
|
||||
@ -0,0 +1,31 @@
|
||||
# Q&A共享资源库类会议纪要-{date}-第X次周会
|
||||
|
||||
## 一、会议信息
|
||||
- **会议时间：** {meeting_date}
|
||||
- **参会人员：** {attendees}
|
||||
- **记录整理人：** {recorder}
|
||||
|
||||
---
|
||||
|
||||
## 二、工作问题 Q&A
|
||||
|
||||
{qa_sections}
|
||||
<!-- 格式：
|
||||
### {序号}. 项目名称：{project_name}
|
||||
- **主要问题：** {problem_description}
|
||||
- **解决方案：** {solution_description}
|
||||
|
||||
---
|
||||
-->
|
||||
|
||||
---
|
||||
|
||||
## 三、重点工作方法
|
||||
|
||||
{work_methods}
|
||||
<!-- 格式：
|
||||
- **方法 {序号}：{方法标题}**
|
||||
- {方法描述}
|
||||
- 适用场景：{场景说明}
|
||||
- 关键要点：{要点列表}
|
||||
-->
|
||||
@ -0,0 +1,30 @@
|
||||
# 学习研究类会议纪要-{date}-第X次周会
|
||||
|
||||
## 一、会议信息
|
||||
|
||||
- **会议时间:** {meeting_date}
|
||||
- **参会人员:** {attendees}
|
||||
- **记录整理人:** {recorder}
|
||||
|
||||
---
|
||||
|
||||
## 二、学习研究内容
|
||||
|
||||
{learning_sections}
|
||||
<!-- 格式：
|
||||
### {{序号}}. {{议题标题}} ({{分享人}})
|
||||
|
||||
**背景与目的：**
|
||||
- {背景内容（来源、学习目的、理论或项目背景）}
|
||||
|
||||
**核心议题概述：**
|
||||
- {核心观点或理论要点}
|
||||
|
||||
**关键讨论成果：**
|
||||
- {结论或讨论结果}
|
||||
|
||||
**下一步研究方向:**（1-3个具体方向）
|
||||
- {方向1}
|
||||
- {方向2}
|
||||
- {方向3}
|
||||
-->
|
||||
@ -0,0 +1,77 @@
|
||||
# 工程类会议纪要-{date}-第X次周会
|
||||
|
||||
## 一、会议信息
|
||||
|
||||
- **会议时间：** {meeting_date}
|
||||
- **参会人员：** {attendees}
|
||||
- **记录整理人：** {recorder}
|
||||
|
||||
---
|
||||
|
||||
## 二、工作内容
|
||||
|
||||
### 1. 重点项目进展情况汇总
|
||||
|
||||
| 项目名称 | 负责人 | 截止时间 | 项目进展情况 |
|
||||
|---------|--------|----------|---------|
|
||||
{project_rows}
|
||||
|
||||
### 2. 重点项目问题及解决方案
|
||||
|
||||
{problem_details}
|
||||
<!-- 样例格式：
|
||||
|
||||
#### 项目 {序号}: {项目名称}
|
||||
**问题1：** {问题标题}
|
||||
- **问题描述：** {描述内容}
|
||||
- **解决方案：**
|
||||
1. {方案1}
|
||||
2. {方案2}
|
||||
- **需要支持：** {需要的资源或协助}
|
||||
- **涉及人员：** {相关人员}
|
||||
|
||||
……按项目顺序继续
|
||||
-->
|
||||
|
||||
### 3. 下周工作安排
|
||||
| 项目名称 | 负责人 | 本周目标 | 优先级 | 截止时间 |
|
||||
|----------|---------|-----------|-----------|-----------|
|
||||
{team_tasks_rows}
|
||||
|
||||
### 4. 组内成员工作进展
|
||||
|
||||
{members_section}
|
||||
<!-- 格式：
|
||||
|
||||
#### {姓名}
|
||||
|
||||
**上周完成:**
|
||||
|
||||
- ✅ {任务描述}
|
||||
|
||||
**进行中:**
|
||||
|
||||
- 🔄 {任务描述}
|
||||
|
||||
**收到的反馈/学习建议:**
|
||||
- {反馈内容}
|
||||
|
||||
**下周任务:**（自动排序：P0 → P1）
|
||||
|
||||
- [ ] P0｜{任务描述}
|
||||
- [ ] P1｜{任务描述}
|
||||
-->
|
||||
|
||||
---
|
||||
|
||||
## 三、会议总结
|
||||
|
||||
**核心议题:** {core_theme}
|
||||
|
||||
**关键决策:**
|
||||
{key_decisions_list}
|
||||
|
||||
**下周工作重点:**
|
||||
{next_week_list}
|
||||
|
||||
---
|
||||
495
.claude/skills/meeting-minutes-generator-v1/架构设计精要.md
Normal file
495
.claude/skills/meeting-minutes-generator-v1/架构设计精要.md
Normal file
@ -0,0 +1,495 @@
|
||||
# 工程类会议纪要生成系统 - 架构设计精要
|
||||
|
||||
## 一、核心设计原则
|
||||
|
||||
### 分阶段生成策略 ⭐⭐⭐
|
||||
|
||||
**核心思想**：按照会议纪要的章节顺序，分阶段提取信息并生成，而不是一次性提取所有信息。
|
||||
|
||||
**优势**：
|
||||
1. 每阶段任务量适中，Agent负载可控
|
||||
2. 可逐步验证结果质量
|
||||
3. 出现问题可重新搜索单个阶段
|
||||
4. 符合人类编写纪要的思维习惯
|
||||
|
||||
---
|
||||
|
||||
## 二、整体架构概览
|
||||
|
||||
```
|
||||
主窗口 (SKILL.md)
|
||||
职责：流程编排 + 分阶段调度 + 逐章节生成
|
||||
|
||||
Phase 1: 准备阶段
|
||||
├── 读取周报（主窗口）
|
||||
├── 读取上周纪要（主窗口）
|
||||
└── 构建索引（Agent: transcript_indexer）
|
||||
输出：temp/transcript_index.json
|
||||
|
||||
Phase 2: 分章节提取与生成（主窗口调度 + Agent执行）
|
||||
├── 2.1 生成"一、会议信息"（主窗口，无需会议转写）
|
||||
├── 2.2 生成"二-1. 重点项目进展情况汇总"（主窗口，主要用周报）
|
||||
├── 2.3 生成"二-2. 重点项目问题及解决方案"
|
||||
│ ├── 调用Agent提取问题讨论
|
||||
│ └── 主窗口合并周报问题
|
||||
├── 2.4 生成"二-3. 下周工作安排"
|
||||
│ ├── 调用Agent提取任务安排
|
||||
│ └── 主窗口合并周报计划
|
||||
├── 2.5 生成"二-4. 组内成员工作进展"
|
||||
│ ├── 并行调用多个Agent提取成员反馈
|
||||
│ └── 主窗口整合周报+反馈+任务
|
||||
└── 2.6 生成"三、会议总结"
|
||||
├── 调用Agent提取决策
|
||||
└── 主窗口从已生成内容归纳总结
|
||||
|
||||
Phase 3: 最终输出
|
||||
└── 主窗口组装完整Markdown并输出文件
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 三、职责分配
|
||||
|
||||
### 主窗口 (SKILL.md)
|
||||
|
||||
**负责**：
|
||||
- 流程编排（按章节顺序调度）
|
||||
- 读取小文件（周报、上周纪要）
|
||||
- 跨源数据合并（会议 + 周报 + 上周纪要）
|
||||
- 逐章节生成Markdown
|
||||
- 最终文件组装输出
|
||||
|
||||
**不负责**：
|
||||
- 读取大文件（会议转写）
|
||||
- 分块处理逻辑
|
||||
- 复杂语义分析
|
||||
|
||||
### Agent 1: transcript_indexer
|
||||
|
||||
**输入**：无（路径固化）
|
||||
**职责**：分块读取会议转写，构建语义索引
|
||||
**输出**：
|
||||
- 文件：`temp/transcript_index.json`
|
||||
- 返回：摘要文字
|
||||
|
||||
### Agent 2: transcript_searcher
|
||||
|
||||
**输入**：搜索意图（自然语言）
|
||||
**职责**：基于索引提取特定信息
|
||||
**输出**：JSON字符串（直接返回）
|
||||
**特点**：轻量级，可多次调用
|
||||
|
||||
---
|
||||
|
||||
## 四、分阶段执行详细设计
|
||||
|
||||
### Phase 1: 准备阶段
|
||||
|
||||
#### 步骤 1.1: 读取周报和上周纪要（主窗口）
|
||||
|
||||
```markdown
|
||||
**执行**：
|
||||
1. Glob: `input/成员本周周报/*.md`
|
||||
2. 提取每个周报：姓名、P0任务、问题、下周计划
|
||||
3. Glob: `input/上周会议纪要/*.md`
|
||||
4. 提取"下周工作安排"表格的P0任务
|
||||
|
||||
**输出数据结构**：
|
||||
members_data = {
|
||||
"闫旭隆": {
|
||||
"p0_tasks": [...],
|
||||
"problems": [...],
|
||||
"next_plan": [...]
|
||||
},
|
||||
...
|
||||
}
|
||||
last_week_p0_tasks = [...]
|
||||
```
|
||||
|
||||
#### 步骤 1.2: 构建会议转写索引（Agent）
|
||||
|
||||
```markdown
|
||||
**调用**：
|
||||
Task(
|
||||
subagent_type="transcript_indexer",
|
||||
description="构建会议转写索引",
|
||||
prompt="构建会议转写索引"
|
||||
)
|
||||
|
||||
**Agent处理**：
|
||||
- 分块读取会议转写（2000行/块，overlap 100）
|
||||
- 为每块打语义标签
|
||||
- 输出索引到 temp/transcript_index.json
|
||||
|
||||
**返回**：
|
||||
"✅ 索引构建完成，共8块，识别10个主题"
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
### Phase 2: 分章节提取与生成
|
||||
|
||||
#### 步骤 2.1: 生成"一、会议信息"（主窗口）
|
||||
|
||||
```markdown
|
||||
**数据来源**：
|
||||
- 会议时间：从会议转写文件名提取
|
||||
- 参会人员：从周报文件名提取
|
||||
- 记录人：固定"Claude"
|
||||
|
||||
**处理**：主窗口直接生成，无需Agent
|
||||
|
||||
**输出**：
|
||||
section_1 = """
|
||||
一、会议信息
|
||||
- 会议时间：2025-11-18
|
||||
- 参会人员：闫旭隆、江争达、...
|
||||
- 记录整理人：Claude
|
||||
"""
|
||||
```
|
||||
|
||||
#### 步骤 2.2: 生成"二-1. 重点项目进展情况汇总"（主窗口）
|
||||
|
||||
```markdown
|
||||
**数据来源**：
|
||||
- 上周P0任务：last_week_p0_tasks
|
||||
- 本周P0任务：members_data[*].p0_tasks
|
||||
|
||||
**处理**：主窗口直接处理
|
||||
1. 取并集（上周P0 ∪ 本周P0）
|
||||
2. 对每个P0任务：
|
||||
- 从周报提取进展情况
|
||||
- 如果周报无记录 → 标记"未完成"
|
||||
|
||||
**输出**：
|
||||
section_2_1 = """
|
||||
### 1. 重点项目进展情况汇总
|
||||
| 项目名称 | 负责人 | 截止时间 | 项目进展情况 |
|
||||
|---------|--------|----------|-------------|
|
||||
| ... | ... | ... | ... |
|
||||
"""
|
||||
|
||||
**注意**：此章节不需要会议转写（仅展示P0追踪）
|
||||
```
|
||||
|
||||
#### 步骤 2.3: 生成"二-2. 重点项目问题及解决方案"（Agent + 主窗口）
|
||||
|
||||
```markdown
|
||||
**步骤 2.3.1: 提取会议问题讨论（Agent）**
|
||||
|
||||
调用：
|
||||
Task(
|
||||
subagent_type="transcript_searcher",
|
||||
description="提取问题讨论",
|
||||
prompt=f"""
|
||||
提取会议中讨论的所有问题及解决方案。
|
||||
|
||||
已知问题（来自周报）：{members_data[*].problems}
|
||||
|
||||
需提取字段：
|
||||
- 问题标题
|
||||
- 问题描述
|
||||
- 解决方案（列表）
|
||||
- 责任人
|
||||
- 截止时间
|
||||
|
||||
返回JSON格式。
|
||||
"""
|
||||
)
|
||||
|
||||
**步骤 2.3.2: 合并数据（主窗口）**
|
||||
|
||||
1. 接收Agent返回的problem_results
|
||||
2. 与周报problems对比去重
|
||||
3. 互补合并：周报简述 + 会议详细方案
|
||||
|
||||
**输出**：
|
||||
section_2_2 = """
|
||||
### 2. 重点项目问题及解决方案
|
||||
|
||||
#### 问题1: ...
|
||||
**问题描述**: ...
|
||||
**解决方案**:
|
||||
1. ...
|
||||
**责任人**: ...
|
||||
**截止时间**: ...
|
||||
"""
|
||||
```
|
||||
|
||||
#### 步骤 2.4: 生成"二-3. 下周工作安排"（Agent + 主窗口）
|
||||
|
||||
```markdown
|
||||
**步骤 2.4.1: 提取会议任务安排（Agent）**
|
||||
|
||||
调用：
|
||||
Task(
|
||||
subagent_type="transcript_searcher",
|
||||
description="提取任务安排",
|
||||
prompt=f"""
|
||||
提取会议中讨论的下周工作安排。
|
||||
|
||||
已知P0任务：{last_week_p0_tasks}
|
||||
|
||||
需提取字段：
|
||||
- 任务名称
|
||||
- 负责人
|
||||
- 任务描述
|
||||
- 优先级（从讨论语气判断P0/P1/P2）
|
||||
- 截止时间
|
||||
|
||||
返回JSON格式。
|
||||
"""
|
||||
)
|
||||
|
||||
**步骤 2.4.2: 合并数据（主窗口）**
|
||||
|
||||
1. 接收task_results
|
||||
2. 与周报next_plan合并去重
|
||||
3. 冲突时会议优先
|
||||
4. 排序：P0 → P1 → P2
|
||||
|
||||
**输出**：
|
||||
section_2_3 = """
|
||||
### 3. 下周工作安排
|
||||
| 项目名称 | 负责人 | 下周会前目标 | 优先级 | 截止时间 |
|
||||
|---------|--------|------------|--------|----------|
|
||||
| 🔴 ... | ... | ... | P0 | ... |
|
||||
| ... | ... | ... | P1 | ... |
|
||||
"""
|
||||
|
||||
**保存**：next_week_tasks（供后续章节使用）
|
||||
```
|
||||
|
||||
#### 步骤 2.5: 生成"二-4. 组内成员工作进展"（并行Agent + 主窗口）⭐
|
||||
|
||||
```markdown
|
||||
**步骤 2.5.1: 并行提取成员反馈（多个Agent）**
|
||||
|
||||
一次性并行调用：
|
||||
for member in members:
|
||||
Task(
|
||||
subagent_type="transcript_searcher",
|
||||
description=f"提取{member}反馈",
|
||||
prompt=f"""
|
||||
提取会议中对 {member} 的反馈（表扬/批评/建议）。
|
||||
|
||||
{member}的周报内容：{members_data[member]}
|
||||
|
||||
需提取字段：
|
||||
- 反馈类型（表扬/批评/建议）
|
||||
- 反馈内容
|
||||
|
||||
返回JSON格式。
|
||||
"""
|
||||
)
|
||||
|
||||
**步骤 2.5.2: 整合数据（主窗口）**
|
||||
|
||||
对每个成员：
|
||||
1. 上周完成：从周报提取
|
||||
2. 进行中：从周报提取
|
||||
3. 收到反馈：从Agent返回提取
|
||||
4. 下周任务：从next_week_tasks筛选该成员 + 周报计划去重
|
||||
|
||||
**输出**：
|
||||
section_2_4 = """
|
||||
### 4. 组内成员工作进展
|
||||
|
||||
#### 闫旭隆
|
||||
**上周完成**:
|
||||
- ✅ ...
|
||||
|
||||
**收到的反馈/学习建议**:
|
||||
- ...
|
||||
|
||||
**下周任务**:
|
||||
- [ ] 🔴 P0|...
|
||||
- [ ] P1|...
|
||||
"""
|
||||
|
||||
**并行优势**：成员反馈提取互不依赖，可同时执行（4-5个Agent并行）
|
||||
```
|
||||
|
||||
#### 步骤 2.6: 生成"三、会议总结"（Agent + 主窗口）
|
||||
|
||||
```markdown
|
||||
**步骤 2.6.1: 提取决策（Agent）**
|
||||
|
||||
调用：
|
||||
Task(
|
||||
subagent_type="transcript_searcher",
|
||||
description="提取决策事项",
|
||||
prompt="""
|
||||
提取会议中的所有关键决策。
|
||||
|
||||
特征词："决定"、"确定"、"采用"、"要求"
|
||||
|
||||
需提取字段：
|
||||
- 决策内容
|
||||
- 决策上下文
|
||||
|
||||
返回JSON格式。
|
||||
"""
|
||||
)
|
||||
|
||||
**步骤 2.6.2: 归纳总结（主窗口）**
|
||||
|
||||
1. 核心议题：从decision_results + next_week_tasks提取高频项目
|
||||
2. 关键决策：从decision_results提取
|
||||
3. 下周重点：从next_week_tasks提取P0任务
|
||||
|
||||
**输出**：
|
||||
section_3 = """
|
||||
三、会议总结
|
||||
|
||||
**核心议题**: ...
|
||||
**关键决策**:
|
||||
1. ...
|
||||
|
||||
**下周工作重点**:
|
||||
1. ...
|
||||
"""
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
### Phase 3: 最终输出
|
||||
|
||||
```markdown
|
||||
**执行**：主窗口
|
||||
|
||||
**操作**：
|
||||
1. 组装所有章节：
|
||||
final_content = section_1 + section_2_1 + section_2_2 + ...
|
||||
2. 格式化检查
|
||||
3. 写入文件：`output/工程类会议纪要_{date}_第X次周会.md`
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 五、关键设计决策
|
||||
|
||||
### 1. 为什么分阶段而不是一次性提取？
|
||||
|
||||
❌ **一次性提取（原方案）**：
|
||||
- 同时发起7-8个Agent（任务、问题、决策、4-5个成员反馈）
|
||||
- 任务量大，Agent负载重
|
||||
- 难以验证中间结果
|
||||
- 出错需全部重来
|
||||
|
||||
✅ **分阶段提取（新方案）**：
|
||||
- 每阶段1-2个Agent任务（成员反馈可并行）
|
||||
- 任务量适中
|
||||
- 可逐步验证
|
||||
- 符合章节生成顺序
|
||||
|
||||
### 2. 哪些阶段可以并行？
|
||||
|
||||
**可并行**（步骤2.5）：
|
||||
- 成员反馈提取（4-5个Agent同时执行）
|
||||
- 原因：每个成员独立，互不依赖
|
||||
|
||||
**必须串行**：
|
||||
- 其他章节（有数据依赖）
|
||||
- 例如：section 2.4生成的next_week_tasks被section 2.5使用
|
||||
|
||||
### 3. 数据传递策略
|
||||
|
||||
**Agent → 主窗口**：
|
||||
- ✅ 直接返回JSON字符串
|
||||
- ❌ 不写temp文件（除了索引）
|
||||
- 原因：单次提取结果<10k tokens，直接传递高效
|
||||
|
||||
**主窗口内部**：
|
||||
- 使用变量传递中间结果
|
||||
- 例如：next_week_tasks在步骤2.4生成，步骤2.5使用
|
||||
|
||||
### 4. 主窗口 vs Agent 决策原则 ⭐本项目专用
|
||||
|
||||
```
|
||||
任务是否需要读取会议转写？
|
||||
├── 否 → 主窗口直接处理
|
||||
│ ├── 会议信息（从文件名提取）
|
||||
│ └── 项目进展（仅用周报，不参考会议转写）
|
||||
│
|
||||
└── 是 → **必须调用 transcript_searcher Agent**
|
||||
├── Agent读取语义索引（temp/transcript_index.json）
|
||||
├── 定位相关块（基于has_*字段和语义匹配）
|
||||
├── 精确读取会议转写片段（基于行号范围）
|
||||
└── 语义提取信息并返回JSON
|
||||
|
||||
⚠️ 重要：
|
||||
- 本项目所有会议转写信息提取都需要语义理解
|
||||
- 不存在简单关键词搜索场景
|
||||
- 不使用Grep工具（会议转写72k tokens，需深度语义分析）
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 六、完整执行流程总结
|
||||
|
||||
```
|
||||
Phase 1: 准备
|
||||
├── 主窗口读周报、上周纪要
|
||||
└── Agent构建索引 → temp/transcript_index.json
|
||||
|
||||
Phase 2: 逐章节生成
|
||||
├── 2.1 会议信息（主窗口直接生成）
|
||||
├── 2.2 项目进展（主窗口用周报生成）
|
||||
├── 2.3 问题方案
|
||||
│ ├── Agent提取会议问题
|
||||
│ └── 主窗口合并周报问题
|
||||
├── 2.4 下周安排
|
||||
│ ├── Agent提取会议任务
|
||||
│ └── 主窗口合并周报计划
|
||||
├── 2.5 成员进展
|
||||
│ ├── 并行Agent提取反馈（4-5个）⭐
|
||||
│ └── 主窗口整合周报+反馈+任务
|
||||
└── 2.6 会议总结
|
||||
├── Agent提取决策
|
||||
└── 主窗口归纳总结
|
||||
|
||||
Phase 3: 输出
|
||||
└── 主窗口组装Markdown并写文件
|
||||
```
|
||||
|
||||
**关键特点**：
|
||||
- ✅ 分阶段执行，任务量可控
|
||||
- ✅ 仅成员反馈提取并行（4-5个Agent）
|
||||
- ✅ 其他阶段串行，确保数据依赖
|
||||
- ✅ 主窗口负责跨源合并与生成
|
||||
- ✅ Agent专注会议转写信息提取
|
||||
|
||||
---
|
||||
|
||||
## 七、预估Token消耗
|
||||
|
||||
```
|
||||
Phase 1:
|
||||
- 读周报（4个×3k）: 12k
|
||||
- 读上周纪要: 5k
|
||||
- Agent构建索引: 72k（读会议转写）
|
||||
小计: ~89k
|
||||
|
||||
Phase 2:
|
||||
- Agent提取问题: 5k（读索引）
|
||||
- Agent提取任务: 5k
|
||||
- Agent提取决策: 5k
|
||||
- Agent提取反馈×4: 20k（并行）
|
||||
- 主窗口处理: 10k
|
||||
小计: ~45k
|
||||
|
||||
Phase 3:
|
||||
- 主窗口生成输出: 5k
|
||||
|
||||
总计: ~140k tokens（远低于200k限制）
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 八、后续优化方向
|
||||
|
||||
1. **动态调整**：如果某章节提取不理想，可重新搜索
|
||||
2. **增量生成**：边提取边展示部分结果给用户
|
||||
3. **质量检查**：主窗口可验证Agent返回的JSON完整性
|
||||
4. **错误恢复**：某Agent失败不影响其他章节生成
|
||||
Reference in New Issue
Block a user