# Output Examples

只在需要稳定输出格式、导出模板或 JSON 结构时阅读。默认优先用 Markdown；需要程序消费时再输出 JSON。

## 真实场景示例

### 场景 1：项目站会纪要（Brief）

**输入：** 50 条 Telegram 群消息 + 30 条 Slack 消息

**输出：**
```markdown
# 多渠道聊天纪要
时间范围：2026-03-21 09:00 至 2026-03-22 09:00
覆盖范围：Telegram「Project Alpha」、Slack「#project-alpha」

## 核心摘要
- v2.3 功能开发已完成，计划周五上线
- 发现 iOS 支付崩溃（P0）和数据导出报错（P1），需今晚前修复
- 客户 A 反馈性能问题，技术团队正在排查

## 关键讨论
### 产品进展
- 搜索性能优化完成，预计提升 40%
- 测试覆盖率达到 85%
- iOS 支付崩溃影响所有 iOS 用户，优先级最高

> 💬 张三 (10:23): "v2.3 所有功能已开发完成，测试通过，建议周五上线"
> ⚠️ 李四 (14:56): "支付崩溃问题比较严重，影响所有 iOS 用户，必须今天修复"

来源：Telegram / Project Alpha

### 客户反馈
- 客户 A 反馈页面加载超过 10 秒，影响业务使用
- 客服已升级至技术团队，需今晚给出解决方案

来源：Slack / #customer-support

## 决策记录
- 按原计划准备周五上线，前提是今晚完成 P0 bug 修复

## 行动项
| 任务 | 负责人 | 截止时间 | 状态 | 来源 |
| --- | --- | --- | --- | --- |
| 修复 iOS 支付崩溃 (#1234) | 李四 | 今天 18:00 | 进行中 | Telegram |
| 修复数据导出报错 (#1235) | 王五 | 今天 18:00 | 待开始 | Telegram |
| 排查客户 A 性能问题 | 老张 | 今天 20:00 | 进行中 | Slack |

## 风险与阻塞
- iOS 支付缺陷若今晚未修复，周五上线计划可能延期

## 待跟进问题
- 客户 A 的性能问题根因是什么？
- 上线后的监控和回滚方案是否已确认？
```

---

### 场景 2：管理层周报（Comprehensive）

**输入：** 3 个群，7 天，约 500 条消息

**输出：**
```markdown
# 项目周报（2026-03-15 至 2026-03-22）

覆盖范围：Telegram「Project Alpha」、Slack「#project-alpha」、企业微信「产品讨论群」

## 核心摘要
- ✅ v2.3 版本按计划完成开发和测试，已于周五上线
- 💰 Q2 推广预算 50 万已批准，市场部正在制定详细执行计划
- ⚠️ 发现 3 个 P0 级 bug，已全部修复
- 📈 搜索性能提升 40%，用户反馈积极
- 🔥 客户 A 性能问题已定位并解决，根因是数据库索引缺失

## 本周关键决策
1. 批准 Q2 推广预算 50 万，重点投入短视频平台
2. 确定 v2.3 周五上线，并制定了回滚预案
3. 决定增加 2 名后端工程师，加快 v3.0 开发进度

## 产品与技术进展
### v2.3 版本上线
- 新增用户画像功能
- 搜索性能提升 40%
- 修复 15 个已知 bug
- 测试覆盖率 85%
- 已于周五 18:00 顺利上线，无回滚

### 技术债务处理
- 修复 iOS 支付崩溃（影响所有 iOS 用户）
- 优化数据库索引（解决客户 A 性能问题）
- 升级依赖库版本（修复安全漏洞）

## 市场与运营
### Q2 推广方案
- 预算：50 万
- 重点渠道：抖音、小红书 KOL 合作（30 万）
- 线下活动：3 场（15 万）
- 信息流广告：5 万
- 预期 ROI：2 倍以上

### 客户反馈
- 客户 A：性能问题已解决，客户满意
- 客户 B：希望增加批量导出功能（已记录需求）
- 客户 C：询问企业版定价（销售跟进中）

## 下周重点
1. 启动 v3.0 需求评审
2. 完成 Q2 推广详细执行计划
3. 招聘 2 名后端工程师
4. 跟进客户 B 的批量导出需求

## 风险与关注点
- v3.0 排期较紧，需尽快确定技术方案
- 市场推广效果需持续监控 ROI
- 客户 B 的需求可能影响 v3.0 排期

---
*本周报基于 Telegram、Slack、企业微信 3 个渠道共 487 条有效消息生成*
```

---

## JSON Shape

```json
{
  "summary": {
    "time_range": {
      "start": "2026-03-21T09:00:00+08:00",
      "end": "2026-03-22T09:00:00+08:00"
    },
    "coverage_note": "Only includes user-provided exports.",
    "channels": ["telegram:Project Alpha", "slack:#project-alpha"]
  },
  "executive_summary": [
    "v2.3 功能开发已完成，计划周五上线。",
    "发现 2 个高优先级缺陷，今晚前需要回归结论。"
  ],
  "topics": [
    {
      "title": "产品进展",
      "key_points": [
        "搜索性能优化已完成，预计提升约 40%。",
        "iOS 支付崩溃仍在排查。"
      ],
      "sources": ["telegram:Project Alpha"]
    }
  ],
  "decisions": [
    {
      "text": "按原计划准备周五上线，但以前提是今晚完成高优缺陷回归。",
      "confidence": "high"
    }
  ],
  "action_items": [
    {
      "task": "修复 iOS 支付崩溃",
      "assignee": "李四",
      "due_at": "2026-03-22T18:00:00+08:00",
      "status": "in_progress",
      "source": "telegram:Project Alpha"
    }
  ],
  "risks": [
    "iOS 支付缺陷若今晚未修复，周五上线计划可能需要延期。"
  ],
  "follow_ups": [
    "客户 A 的性能问题根因是什么？"
  ]
}
```

## Partial Results Note

当数据不完整时，在输出开头增加一行说明，例如：

```text
说明：Slack 渠道抓取失败，以下纪要仅覆盖 Telegram 和企业微信记录。
```

## Writing Rules

- 高管摘要优先结果、风险、下一步
- 执行纪要优先上下文、owner、deadline、状态
- 没有证据的字段写 `待确认`
- 引用原话时只保留高信号片段，不大段搬运原始聊天