aily-doc-project-kickoff-report

name	aily-doc-project-kickoff-report
label	项目启动报告
description	项目启动报告：统一目标、范围、里程碑、分工与风险，形成可落地的启动材料。

SKILL: aily-doc-project-kickoff-report

项目启动报告：统一目标、范围、里程碑、分工与风险，形成可落地的启动材料。

---

1) Overview

⚠️ 输出形式（强制）

• 本 skill 被触发即代表用户期望生成飞书云文档，主 Agent 无需询问用户是否需要写成文档，也不得以对话文本替代文档作为最终交付物。
• 数据收集完成后，必须通过 task（subagent_type: writer）委托 Writer Agent 创建飞书云文档。

飞书工具优先（必须遵守）

• 所有飞书相关信息获取与写作，先参考 feishu-use-skills-map 并按其指引调用对应技能
• 需要访问飞书文档/群消息/会议/任务时，必须先 get_skills 获取对应飞书技能说明

工具/Skill 明确清单（执行前先 get_skills）

• 必须先参考 feishu-use-skills-map 并调用对应技能
• 主要技能：

工具	用途	适用场景
aily-doc	搜索/读取飞书云文档	需求文档、立项文档、历史启动报告
aily-calendar	查询日历/会议	项目相关会议、排期信息
aily-im	获取群消息/群成员	项目群成员列表、历史讨论
knowledge_answer	查询内部知识库	项目背景、技术栈、组织信息
file	将素材写入 draft.md（append 模式）	每个数据步骤完成后

证据与时间约束（与主/写作agent一致）

• 任何数据/结论必须来自可追溯来源；不确定则明确标注"需补充资料"。
• 若用户指定时间范围，必须严格筛选在时间窗内的资料，过期内容不得使用。
• 不可编造事实、链接或来源；引用必须有明确出处。

可读性规则（强制）

• 并列项>=3：优先使用无序/有序列表或表格
• 单段>150字必须拆分（列表/小节/Callout）
• 连续两段无列表且信息密度高：插入列表或 Callout

触发方式（Triggers）

• "项目启动"
• "kickoff"
• "启动会"
• "帮我写一份项目启动报告"
• "准备 kickoff 材料"
• "启动XX项目"

输入（Inputs）

• 必选：项目名称、项目目标、项目范围
• 可选：
  • 干系人列表（项目负责人、核心成员、利益相关方）
  • 资源需求（人力、预算、设备）
  • 初步计划/排期
  • 技术约束/系统依赖
  • 风险预判

核心输出（Deliverables）

• 飞书云文档项目启动报告：目标清晰、范围明确、分工到人、里程碑可追踪、风险有预案

质量标准

• 共识明确：项目目标、范围、成功标准在报告中统一表述，无歧义
• 执行可落地：每个里程碑有明确的时间节点、交付物和责任人；RACI矩阵完整
• 风险可控：识别主要风险并附带应对措施和Owner
• 沟通有机制：例会、信息同步、升级机制三者齐全

---

2) 任务分解示例（todo_write）

主 Agent 收到项目启动报告请求后，使用 todo_write 分解任务：

{
  "todos": [
    {"content": "A1. 获取项目背景资料（需求文档/立项文档/项目背景）", "status": "in_progress"},
    {"content": "A2. 获取干系人信息（项目群成员/相关会议参与人）", "status": "pending"},
    {"content": "A3. 搜索历史参考（类似项目启动报告）", "status": "pending"},
    {"content": "A4. 查询技术约束与系统依赖", "status": "pending"},
    {"content": "B. 结构化整理：目标/范围/里程碑/分工/风险/沟通", "status": "pending"},
    {"content": "C. 调用 writer agent 生成项目启动报告飞书云文档", "status": "pending"}
  ]
}

---

3) Module A — 资料获取（主 Agent 执行）

核心原则：优先使用飞书工具获取内部资料，knowledge_answer 作为补充和兜底。每个步骤完成后，将结果结构化写入 draft.md。

A1. 项目背景

目标：获取项目的来龙去脉、立项原因、业务目标。

工具与策略：

1. aily-doc 搜索需求文档/立项文档：

aily-doc(
  action: "search",
  query: "{项目名称} 需求文档 立项 PRD",
  filters: { doc_type: "docx" }
)

2. aily-doc 读取关键文档（搜索到后深度阅读）：

aily-doc(
  action: "read",
  doc_token: "{文档token}",
  prompt: "提取项目背景、业务目标、核心需求、发起原因"
)

3. knowledge_answer 查询项目背景：

knowledge_answer(
  query_list: [
    "{项目名称} 项目背景 立项原因",
    "{项目名称} 业务目标 核心需求"
  ],
  explanation: "获取项目背景信息和立项依据"
)

写入 draft.md（使用 file(path: "/home/workspace/draft.md", mode: "append")）：

## A1. 项目背景

### 立项背景
- 业务驱动因素：...
- 市场/客户需求：...
- 战略对齐：...

### 核心需求
| 需求编号 | 需求描述 | 优先级 | 来源 |
|---------|---------|--------|------|
| R001 | ... | P0 | PRD文档 |
| R002 | ... | P1 | 客户反馈 |

### 相关文档
- [需求文档](飞书链接)：核心要点...
- [立项文档](飞书链接)：核心要点...

### 数据来源
- 来源1：{文档名称}（飞书文档）
- 来源2：knowledge_answer 查询结果

---

A2. 干系人信息

目标：明确项目组织结构、核心成员、利益相关方。

工具与策略：

1. aily-im 获取项目群成员：

aily-im(
  action: "get_group_members",
  query: "{项目名称}",
  prompt: "获取项目相关群组的成员列表及其角色"
)

2. aily-calendar 查询相关会议：

aily-calendar(
  action: "search",
  query: "{项目名称} 启动 评审 规划",
  time_range: "近30天"
)

• 从会议参与人中补充干系人信息
• 识别高频参与者，推断核心成员

3. knowledge_answer 补充组织信息：

knowledge_answer(
  query_list: [
    "{项目名称} 项目负责人 团队成员",
    "{项目名称} 相关团队 组织架构"
  ],
  explanation: "获取项目组织与人员信息"
)

写入 draft.md（使用 file(path: "/home/workspace/draft.md", mode: "append")）：

## A2. 干系人信息

### 项目群成员
| 姓名 | 群角色 | 推断项目角色 |
|------|--------|-------------|
| @XX | 群主 | 项目负责人（推测） |
| @XX | 成员 | 核心开发（推测） |

### 相关会议参与人
| 会议名称 | 日期 | 关键参与人 |
|---------|------|-----------|
| XX项目规划会 | YYYY-MM-DD | @XX, @XX, @XX |
| XX需求评审会 | YYYY-MM-DD | @XX, @XX |

### 高频协作对象
- @XX（出现 N 次）—— 可能角色：...
- @XX（出现 N 次）—— 可能角色：...

### 待确认
- [ ] 项目负责人需用户确认
- [ ] RACI矩阵中的具体分工需用户补充

---

A3. 历史参考

目标：找到公司内部类似项目的启动报告，作为结构和内容参考。

工具与策略：

1. aily-doc 搜索类似项目启动报告：

aily-doc(
  action: "search",
  query: "项目启动报告 kickoff",
  filters: { doc_type: "docx" }
)

2. aily-doc 搜索同类型项目文档：

aily-doc(
  action: "search",
  query: "{项目类型关键词} 启动 立项 规划",
  filters: { doc_type: "docx" }
)

3. 读取参考报告（如搜索到）：

aily-doc(
  action: "read",
  doc_token: "{参考文档token}",
  prompt: "提取该启动报告的结构、里程碑设置方式、分工方式、风险识别方法"
)

写入 draft.md（使用 file(path: "/home/workspace/draft.md", mode: "append")）：

## A3. 历史参考

### 参考项目启动报告
| 项目名称 | 文档链接 | 参考价值 |
|---------|---------|---------|
| XX项目启动报告 | [链接](url) | 里程碑设置方式可参考 |
| YY项目Kickoff | [链接](url) | RACI矩阵结构可参考 |

### 可复用经验
- 里程碑粒度：按双周/月划分阶段
- 分工模式：使用RACI矩阵
- 风险管理：概率-影响矩阵 + Owner

### 应避免的问题
- XX项目启动报告中未明确沟通机制，后续沟通混乱
- YY项目里程碑过于粗放，无法追踪进度

---

A4. 技术约束

目标：了解项目涉及的技术栈、系统依赖、架构约束。

工具与策略：

1. knowledge_answer 查询技术栈/系统约束：

knowledge_answer(
  query_list: [
    "{项目名称} 技术栈 技术架构",
    "{项目名称} 系统依赖 接口依赖",
    "{项目名称} 技术约束 非功能性需求"
  ],
  explanation: "获取项目的技术约束和系统依赖信息"
)

2. aily-doc 搜索技术方案文档：

aily-doc(
  action: "search",
  query: "{项目名称} 技术方案 架构设计 系统设计",
  filters: { doc_type: "docx" }
)

写入 draft.md（使用 file(path: "/home/workspace/draft.md", mode: "append")）：

## A4. 技术约束

### 技术栈
- 前端：...
- 后端：...
- 基础设施：...

### 系统依赖
| 依赖系统 | 依赖类型 | 负责团队 | 当前状态 |
|---------|---------|---------|---------|
| XX系统 | 接口调用 | XX团队 | 已就绪 |
| YY平台 | 数据依赖 | YY团队 | 需对齐 |

### 技术约束
- 性能要求：...
- 兼容性要求：...
- 安全合规：...

### 关键假设
- 假设1：XX系统接口在M月前可用
- 假设2：XX团队能提供N人支持

---

4) Module B — 结构化整理（主 Agent 执行）

核心原则：将 Module A 收集的原始资料，按照启动报告的框架进行结构化分析和整理，形成"目标-范围-计划-分工-风险-沟通"完整链条。

B1. 项目目标与成功标准

分析要点：

• 从 A1 中提取并提炼项目目标，区分业务目标和技术目标
• 将模糊目标转化为可量化的成功标准
• 每个目标配备验收维度和目标值

写入 draft.md（使用 file(path: "/home/workspace/draft.md", mode: "append")）：

## B1. 项目目标与成功标准

### 项目目标
- **业务目标**：...（从需求文档/立项文档中提取）
- **技术目标**：...（从技术方案中提取）
- **用户目标**：...（从用户反馈/PRD中提取）

### 成功标准
| 维度 | 指标 | 目标值 | 衡量方式 |
|------|------|--------|---------|
| 业务 | XX转化率 | 提升X% | 数据看板 |
| 技术 | 系统响应时间 | <Xms | 监控系统 |
| 用户 | 用户满意度 | >X分 | 用户调研 |
| 进度 | 按时交付率 | 100% | 里程碑检查 |

### 非目标（明确排除）
- 本项目不追求...
- 本阶段不涉及...

---

B2. 范围界定（做什么/不做什么）

分析要点：

• 从 A1 的需求文档中提取范围边界
• 明确 In Scope 和 Out of Scope，避免范围蔓延
• 列出关键假设与约束条件

写入 draft.md（使用 file(path: "/home/workspace/draft.md", mode: "append")）：

## B2. 范围界定

### 项目范围（In Scope）
1. **功能范围**：
   - 功能模块1：...
   - 功能模块2：...
   - 功能模块3：...
2. **用户范围**：目标用户群体...
3. **平台范围**：Web/App/API...

### 不在范围内（Out of Scope）
1. XX功能（计划在二期实现）
2. XX平台适配（当前仅支持XX）
3. XX场景（不在本次需求内）

### 关键假设
| 编号 | 假设内容 | 影响 | 验证方式 |
|------|---------|------|---------|
| H001 | XX团队能按时交付接口 | 影响集成阶段排期 | 周会同步 |
| H002 | XX方案技术可行 | 影响架构设计 | 技术验证 |

### 约束条件
- 时间约束：必须在YYYY-MM-DD前上线
- 资源约束：团队N人，无额外HC
- 技术约束：必须基于现有XX架构

---

B3. 里程碑与排期

分析要点：

• 结合 A1 的需求和 A4 的技术约束，规划合理排期
• 参考 A3 的历史项目排期经验
• 每个阶段有明确的交付物和负责人

写入 draft.md（使用 file(path: "/home/workspace/draft.md", mode: "append")）：

## B3. 里程碑与排期

### 整体排期
| 阶段 | 时间 | 交付物 | 负责人 |
|------|------|--------|--------|
| 需求确认 | MM.DD - MM.DD | 需求文档终稿 | @产品经理 |
| 技术设计 | MM.DD - MM.DD | 技术方案文档 | @技术负责人 |
| 开发实现 | MM.DD - MM.DD | 功能代码 | @开发团队 |
| 测试验收 | MM.DD - MM.DD | 测试报告 | @测试负责人 |
| 上线发布 | MM.DD | 线上版本 | @项目负责人 |

### 关键里程碑
| 里程碑 | 日期 | 标志事件 | 检查方式 |
|--------|------|---------|---------|
| M1：需求冻结 | MM-DD | 需求文档签字确认 | 评审会议 |
| M2：技术方案评审通过 | MM-DD | 方案评审通过 | 评审会议 |
| M3：开发完成/提测 | MM-DD | 代码合入主分支 | CI/CD |
| M4：测试通过 | MM-DD | 全量用例通过 | 测试报告 |
| M5：正式上线 | MM-DD | 线上发布成功 | 监控确认 |

### 关键路径
- 需求确认 → 技术设计 → 核心模块开发 → 集成测试 → 上线
- 关键路径预估工期：XX 工作日

---

B4. 组织与分工（RACI矩阵）

分析要点：

• 结合 A2 的干系人信息，明确角色分工
• 使用 RACI 矩阵（Responsible/Accountable/Consulted/Informed）
• 确保每项关键活动有且仅有一个 A（Accountable）

写入 draft.md（使用 file(path: "/home/workspace/draft.md", mode: "append")）：

## B4. 组织与分工

### 项目组织架构
- **项目发起人（Sponsor）**：@XX —— 资源协调、重大决策
- **项目负责人（PM）**：@XX —— 整体推进、风险管理
- **技术负责人（TL）**：@XX —— 技术方案、代码质量
- **产品负责人（PD）**：@XX —— 需求管理、验收标准
- **测试负责人（QA）**：@XX —— 测试策略、质量保障

### 角色与职责
| 角色 | 人员 | 核心职责 |
|------|------|---------|
| 项目负责人 | @XX | 项目计划制定与跟踪、风险管理、干系人沟通 |
| 技术负责人 | @XX | 技术方案设计、Code Review、技术难题攻关 |
| 产品负责人 | @XX | 需求管理、优先级排序、验收确认 |
| 前端开发 | @XX, @XX | 前端功能开发、联调 |
| 后端开发 | @XX, @XX | 后端功能开发、接口设计 |
| 测试 | @XX | 测试用例设计、执行、缺陷跟踪 |
| 设计 | @XX | UI/UX设计、设计稿交付 |

### RACI矩阵
| 活动 / 角色 | PM | TL | PD | 开发 | QA | 设计 |
|-------------|----|----|----|----|----|----|
| 需求评审 | A | C | R | C | I | C |
| 技术方案设计 | I | A | C | R | I | - |
| UI/UX设计 | I | C | A | I | - | R |
| 功能开发 | I | A | - | R | I | - |
| 代码Review | I | A | - | R | - | - |
| 测试执行 | I | C | C | C | R/A | - |
| 上线发布 | A | R | I | R | C | - |
| 项目进度汇报 | R/A | C | C | I | I | I |

> R=Responsible（执行）, A=Accountable（负责）, C=Consulted（咨询）, I=Informed（知会）

---

B5. 风险与依赖识别

分析要点：

• 从 A4 的技术约束中提取技术风险
• 从 A2 的干系人信息中识别资源风险
• 从 A3 的历史经验中借鉴风险管理方法
• 每个风险有概率、影响、应对措施、Owner

写入 draft.md（使用 file(path: "/home/workspace/draft.md", mode: "append")）：

## B5. 风险与依赖

### 风险清单
| 编号 | 风险描述 | 概率 | 影响 | 风险等级 | 应对措施 | Owner |
|------|---------|------|------|---------|---------|-------|
| R001 | XX接口交付延期 | 高 | 高 | 严重 | 提前对齐排期，准备降级方案 | @XX |
| R002 | 核心开发人员请假 | 中 | 高 | 高 | 关键模块安排backup | @XX |
| R003 | 需求变更频繁 | 中 | 中 | 中 | 需求冻结后变更需评审 | @XX |
| R004 | 性能不达标 | 低 | 高 | 中 | 提前做性能测试 | @XX |

### 外部依赖
| 依赖项 | 依赖团队 | 预计就绪时间 | 当前状态 | 对接人 |
|--------|---------|-------------|---------|--------|
| XX系统接口 | XX团队 | MM-DD | 开发中 | @XX |
| YY平台权限 | YY团队 | MM-DD | 待申请 | @XX |
| 设计稿交付 | 设计团队 | MM-DD | 设计中 | @XX |

### 风险应对策略
- **规避**：提前识别并消除风险源
- **缓解**：降低发生概率或减轻影响
- **转移**：将风险转移给更合适的责任方
- **接受**：低概率低影响的风险可接受并监控

---

B6. 沟通机制设计

分析要点：

• 基于项目规模和团队分布设计沟通机制
• 参考 A3 历史项目的沟通方式
• 覆盖例会、信息同步、升级三个层面

写入 draft.md（使用 file(path: "/home/workspace/draft.md", mode: "append")）：

## B6. 沟通机制

### 例会安排
| 会议类型 | 频率 | 参与人 | 目的 | 时间 |
|---------|------|--------|------|------|
| 项目站会 | 每日 | 全体项目成员 | 同步进展、暴露阻塞 | 每天 10:00（15分钟） |
| 项目周会 | 每周 | 全体 + 干系人 | 里程碑检查、风险评审 | 每周X 14:00（1小时） |
| 技术评审会 | 按需 | TL + 开发 | 方案评审、技术决策 | 按需安排 |
| 项目汇报会 | 双周/月 | PM + Sponsor | 项目状态汇报 | 按需安排 |

### 信息同步方式
| 渠道 | 用途 | 频率 |
|------|------|------|
| 项目飞书群 | 日常沟通、快速响应 | 实时 |
| 飞书文档（项目看板） | 进度追踪、里程碑状态 | 实时更新 |
| 邮件/飞书通知 | 重要决策、变更通知 | 按需 |
| 周报 | 项目进展总结 | 每周 |

### 升级机制
| 升级条件 | 升级层级 | 响应时限 |
|---------|---------|---------|
| 阻塞超过1个工作日 | TL / PM | 4小时内响应 |
| 影响里程碑的风险 | PM → Sponsor | 1个工作日内决策 |
| 需求变更（P0） | PD → PM → Sponsor | 2个工作日内评审 |
| 跨团队协作问题 | PM → 对方PM/TL | 1个工作日内对齐 |

---

5) Module C — 写作生成（Writer Agent）

任务分发

主 Agent 完成 Module A（资料获取）和 Module B（结构化整理）后，将所有内容写入 draft.md，然后调用 task 工具分发给 Writer Agent：

{
  "description": "生成项目启动报告飞书云文档",
  "prompt": "基于 /home/workspace/draft.md 中的项目启动报告素材，生成一份结构完整的飞书云文档项目启动报告。\n\n要求：\n1. 严格按照项目启动报告模板结构\n2. 项目摘要放在最前面，3-5条核心要点\n3. 所有数据来源于 draft.md，不要编造\n4. RACI矩阵必须完整\n5. 风险清单必须有应对措施和Owner\n6. 沟通机制必须包含例会、信息同步、升级机制\n7. 表格优先，确保可读性\n\n报告模板见下方。",
  "subagent_type": "writer"
}

Writer Agent 执行流程

Writer Agent 收到任务
      ↓
1. file_read: 读取 /home/workspace/draft.md
      ↓
2. outline_generator: 基于模板生成结构化大纲
      ↓
3. document_write: 生成 项目启动报告.feishu.md
      ↓
4. feishu_doc_create: 转换为飞书云文档
      ↓
5. end: 返回飞书文档链接

Writer Agent 写作规则

• 严格遵循下方文档模板结构
• 所有内容来源于 draft.md，不得编造
• 表格内容不可省略，宁可标注"待补充"
• 并列项>=3 使用列表或表格
• 每个章节有导言说明该章节目的

---

6) 详细文档模板（Writer Agent 遵循）

Writer Agent 使用 document_write 生成飞书云文档时，必须遵循以下模板结构：

# {项目名称} 启动报告

> 启动日期：YYYY-MM-DD | 项目负责人：@XX
> 文档状态：草稿/评审中/已确认
> 生成时间：YYYY-MM-DD HH:MM

---

## 项目摘要

<!-- 3-5条核心要点，高度概括整个项目 -->

1. **项目目标**：一句话概括项目要达成什么
2. **项目周期**：YYYY-MM-DD ~ YYYY-MM-DD，共N个工作日
3. **核心团队**：N人，涉及XX、XX、XX团队
4. **关键里程碑**：M1需求冻结(MM-DD)、M2提测(MM-DD)、M3上线(MM-DD)
5. **主要风险**：XX风险需重点关注

---

## 一、项目背景与目标

### 1.1 项目背景

<!-- 说明项目的来龙去脉、发起原因、业务背景 -->

- **业务背景**：...
- **发起原因**：...
- **战略对齐**：...

### 1.2 项目目标

- **业务目标**：...
- **技术目标**：...
- **用户目标**：...

### 1.3 成功标准

| 维度 | 指标 | 目标值 | 衡量方式 |
|------|------|--------|---------|
| 业务 | XX指标 | 提升X% | 数据看板 |
| 技术 | 响应时间 | <Xms | 监控系统 |
| 用户 | 满意度 | >X分 | 调研问卷 |
| 进度 | 按时交付 | 100% | 里程碑检查 |

---

## 二、范围与边界

### 2.1 项目范围（In Scope）

1. **功能范围**：
   - 功能模块A：...
   - 功能模块B：...
   - 功能模块C：...
2. **用户范围**：...
3. **平台范围**：...

### 2.2 不在范围内（Out of Scope）

| 排除项 | 原因 | 后续计划 |
|--------|------|---------|
| XX功能 | 非本期需求 | 计划二期实现 |
| XX平台 | 资源限制 | 视情况扩展 |

### 2.3 关键假设与约束

**关键假设**：
| 编号 | 假设内容 | 影响范围 | 验证方式 |
|------|---------|---------|---------|
| H001 | ... | ... | ... |
| H002 | ... | ... | ... |

**约束条件**：
- 时间约束：...
- 资源约束：...
- 技术约束：...

---

## 三、里程碑与计划

### 3.1 整体排期

| 阶段 | 时间 | 交付物 | 负责人 | 验收标准 |
|------|------|--------|--------|---------|
| 需求确认 | MM.DD - MM.DD | 需求文档终稿 | @XX | 需求评审通过 |
| 技术设计 | MM.DD - MM.DD | 技术方案文档 | @XX | 方案评审通过 |
| UI/UX设计 | MM.DD - MM.DD | 设计稿 | @XX | 设计评审通过 |
| 开发实现 | MM.DD - MM.DD | 功能代码 | @XX | 提测标准达成 |
| 测试验收 | MM.DD - MM.DD | 测试报告 | @XX | 用例通过率100% |
| 上线发布 | MM.DD | 线上版本 | @XX | 线上验证通过 |

### 3.2 关键里程碑

| 里程碑 | 日期 | 标志事件 | 检查方式 | 负责人 |
|--------|------|---------|---------|--------|
| M1 需求冻结 | MM-DD | 需求文档签字确认 | 评审会议 | @XX |
| M2 设计完成 | MM-DD | 设计稿交付 | 设计评审 | @XX |
| M3 开发完成 | MM-DD | 代码合入/提测 | CI/CD | @XX |
| M4 测试通过 | MM-DD | 全量用例通过 | 测试报告 | @XX |
| M5 正式上线 | MM-DD | 发布上线 | 线上监控 | @XX |

---

## 四、组织与分工

### 4.1 项目组织架构

项目发起人（Sponsor）: @XX | 项目负责人（PM）: @XX | ┌─────┼─────┬──────┐ | | | | 产品 技术 测试 设计 @XX @XX @XX @XX | ┌───┼───┐ | | 前端 后端 @XX @XX

### 4.2 角色与职责

| 角色 | 人员 | 核心职责 | 投入度 |
|------|------|---------|--------|
| 项目发起人 | @XX | 资源协调、重大决策 | 10% |
| 项目负责人 | @XX | 计划制定、进度跟踪、风险管理 | 50% |
| 产品负责人 | @XX | 需求管理、验收确认 | 40% |
| 技术负责人 | @XX | 方案设计、技术决策 | 60% |
| 前端开发 | @XX, @XX | 前端功能开发 | 100% |
| 后端开发 | @XX, @XX | 后端功能开发 | 100% |
| 测试 | @XX | 测试设计与执行 | 80% |
| 设计 | @XX | UI/UX设计 | 30% |

### 4.3 RACI矩阵

| 活动 | Sponsor | PM | PD | TL | 开发 | QA | 设计 |
|------|---------|----|----|----|----|----|----|
| 项目立项 | A | R | C | C | I | I | I |
| 需求评审 | I | A | R | C | C | I | C |
| 技术方案设计 | I | I | C | A | R | I | - |
| UI/UX设计 | I | I | A | C | I | - | R |
| 功能开发 | - | I | - | A | R | I | - |
| 代码Review | - | I | - | A | R | - | - |
| 测试执行 | - | I | C | C | C | R/A | - |
| 上线发布 | I | A | I | R | R | C | - |
| 进度汇报 | I | R/A | C | C | I | I | I |

> **R**=Responsible（执行），**A**=Accountable（负责），**C**=Consulted（咨询），**I**=Informed（知会）

---

## 五、沟通机制

### 5.1 例会安排

| 会议类型 | 频率 | 时间 | 时长 | 参与人 | 目的 |
|---------|------|------|------|--------|------|
| 每日站会 | 每日 | 10:00 | 15分钟 | 全体项目成员 | 同步进展、暴露阻塞 |
| 项目周会 | 每周 | 周X 14:00 | 1小时 | 全体 + 干系人 | 里程碑检查、风险评审 |
| 技术评审 | 按需 | 待定 | 1-2小时 | TL + 开发 + QA | 方案评审、技术决策 |
| Sponsor汇报 | 双周 | 待定 | 30分钟 | PM + Sponsor | 项目状态汇报 |

### 5.2 信息同步方式

| 渠道 | 用途 | 更新频率 | 负责人 |
|------|------|---------|--------|
| 项目飞书群 | 日常沟通、即时响应 | 实时 | 全体 |
| 项目看板/文档 | 进度追踪、任务状态 | 实时更新 | PM |
| 项目周报 | 进展总结、风险通报 | 每周 | PM |
| 邮件/通知 | 重要决策、正式变更 | 按需 | PM |

### 5.3 升级机制

| 级别 | 触发条件 | 升级对象 | 响应时限 | 处理方式 |
|------|---------|---------|---------|---------|
| L1 | 阻塞超过4小时 | TL / PM | 4小时内响应 | 协调资源、调整优先级 |
| L2 | 影响里程碑节点 | PM → Sponsor | 1工作日内决策 | 评估影响、制定补救方案 |
| L3 | 需求P0变更 | PD → PM → Sponsor | 2工作日内评审 | 变更评审会议 |
| L4 | 跨团队协作阻塞 | PM → 对方PM | 1工作日内对齐 | 联合会议、资源协调 |

---

## 六、风险与依赖

### 6.1 风险清单

| 编号 | 风险描述 | 概率 | 影响 | 风险等级 | 应对措施 | Owner |
|------|---------|------|------|---------|---------|-------|
| R001 | XX接口交付延期 | 高 | 高 | 严重 | 提前对齐排期；准备降级方案 | @XX |
| R002 | 核心人员变动/请假 | 中 | 高 | 高 | 关键模块安排backup人员 | @XX |
| R003 | 需求变更频繁 | 中 | 中 | 中 | 需求冻结后变更需评审流程 | @XX |
| R004 | 性能不达标 | 低 | 高 | 中 | 提前做性能基准测试 | @XX |
| R005 | 第三方服务不稳定 | 低 | 中 | 低 | 设计降级和熔断机制 | @XX |

> 风险等级 = 概率 x 影响：严重(高x高)、高(高x中/中x高)、中(中x中/低x高/高x低)、低(低x中/低x低)

### 6.2 外部依赖

| 依赖项 | 依赖团队 | 对接人 | 预计就绪 | 当前状态 | 备选方案 |
|--------|---------|--------|---------|---------|---------|
| XX系统接口 | XX团队 | @XX | MM-DD | 开发中 | Mock接口先行 |
| YY平台权限 | YY团队 | @XX | MM-DD | 待申请 | 提前走审批流程 |
| 设计稿交付 | 设计团队 | @XX | MM-DD | 设计中 | 先用线框图开发 |

---

## 七、资源需求

### 人力资源

| 角色 | 人数 | 投入周期 | 来源 |
|------|------|---------|------|
| 前端开发 | N人 | MM.DD - MM.DD | 现有团队 |
| 后端开发 | N人 | MM.DD - MM.DD | 现有团队 |
| 测试 | N人 | MM.DD - MM.DD | 现有团队 |
| 设计 | N人 | MM.DD - MM.DD | 需协调 |

### 其他资源

| 资源类型 | 需求描述 | 预算/成本 | 审批状态 |
|---------|---------|----------|---------|
| 服务器/云资源 | XX环境部署 | 待评估 | 待申请 |
| 第三方服务 | XX API调用 | XX元/月 | 待审批 |
| 测试设备 | XX机型覆盖 | 待评估 | 待确认 |

---

## 附录

### A. 相关文档索引
| 文档名称 | 链接 | 说明 |
|---------|------|------|
| 需求文档/PRD | [链接](url) | 详细需求说明 |
| 技术方案 | [链接](url) | 架构与设计 |
| 设计稿 | [链接](url) | UI/UX设计 |
| 项目看板 | [链接](url) | 任务与进度 |

### B. 术语表
| 术语 | 说明 |
|------|------|
| RACI | Responsible/Accountable/Consulted/Informed |
| MVP | Minimum Viable Product，最小可行产品 |
| CR | Concentration Ratio，集中度 |

### C. 变更记录
| 版本 | 日期 | 修改人 | 修改内容 |
|------|------|--------|---------|
| v1.0 | YYYY-MM-DD | @XX | 初始版本 |

---

7) 执行流程图

用户: "帮我准备XX项目的启动报告" / "项目启动" / "kickoff"
          ↓
┌─────────────────────────────────────────────────────────────┐
│                    主 Agent 执行                              │
├─────────────────────────────────────────────────────────────┤
│                                                             │
│ 1. todo_write: 分解任务（6个子任务）                          │
│                                                             │
│ 【Module A — 资料获取】                                      │
│ 2. A1 项目背景                                               │
│    ├─ aily-doc: 搜索需求文档/立项文档                         │
│    ├─ aily-doc: 读取关键文档                                 │
│    ├─ knowledge_answer: 查项目背景                           │
│    └─ → 写入 draft.md                                       │
│                                                             │
│ 3. A2 干系人信息                                             │
│    ├─ aily-im: 获取项目群成员                                │
│    ├─ aily-calendar: 查相关会议及参与人                       │
│    ├─ knowledge_answer: 补充组织信息                         │
│    └─ → 写入 draft.md                                       │
│                                                             │
│ 4. A3 历史参考                                               │
│    ├─ aily-doc: 搜索类似项目启动报告                          │
│    ├─ aily-doc: 读取参考报告                                 │
│    └─ → 写入 draft.md                                       │
│                                                             │
│ 5. A4 技术约束                                               │
│    ├─ knowledge_answer: 查技术栈/系统约束                     │
│    ├─ aily-doc: 搜索技术方案文档                              │
│    └─ → 写入 draft.md                                       │
│                                                             │
│ 【Module B — 结构化整理】                                    │
│ 6. B1 项目目标与成功标准 → 写入 draft.md                      │
│ 7. B2 范围界定(In/Out Scope) → 写入 draft.md                │
│ 8. B3 里程碑与排期 → 写入 draft.md                           │
│ 9. B4 组织与分工(RACI) → 写入 draft.md                       │
│ 10. B5 风险与依赖识别 → 写入 draft.md                        │
│ 11. B6 沟通机制设计 → 写入 draft.md                          │
│                                                             │
│ 【Module C — 分发写作】                                      │
│ 12. task(writer): 分发给 Writer Agent                       │
│                                                             │
└─────────────────────────────────────────────────────────────┘
          ↓
┌─────────────────────────────────────────────────────────────┐
│                    Writer Agent 执行                         │
├─────────────────────────────────────────────────────────────┤
│ 1. file_read: 读取 /home/workspace/draft.md                  │
│ 2. outline_generator: 基于模板生成结构化大纲                  │
│ 3. document_write: 生成 项目启动报告.feishu.md               │
│ 4. feishu_doc_create: 转换为飞书云文档                        │
│ 5. end: 返回飞书文档链接                                      │
└─────────────────────────────────────────────────────────────┘
          ↓
      飞书云文档项目启动报告

---

8) Checklist

主 Agent — 资料获取检查项（Module A）

• A1：需求文档/立项文档已搜索并读取
• A1：项目背景信息已通过 knowledge_answer 补充
• A2：项目群成员已通过 aily-im 获取
• A2：相关会议已通过 aily-calendar 查询
• A3：类似项目启动报告已搜索
• A4：技术约束/系统依赖已查询
• 所有获取的资料已写入 draft.md

主 Agent — 结构化整理检查项（Module B）

• B1：项目目标已明确，成功标准可量化
• B2：In Scope / Out of Scope 已清晰界定
• B2：关键假设与约束已列出
• B3：整体排期表已完成，每阶段有交付物和负责人
• B3：关键里程碑已标注日期和检查方式
• B4：组织架构和角色职责已明确
• B4：RACI矩阵已完成，每活动有且仅有一个A
• B5：风险清单已完成，每项有概率/影响/应对/Owner
• B5：外部依赖已列出，有对接人和预计就绪时间
• B6：例会安排已设计
• B6：信息同步方式已明确
• B6：升级机制已设计

主 Agent — 分发检查项（Module C）

• draft.md 内容完整，涵盖 A1-A4 和 B1-B6
• 已调用 task(writer) 分发写作任务
• prompt 中明确要求遵循模板结构

Writer Agent 检查项

• 已读取 draft.md 完整内容
• 项目摘要完整（3-5条核心要点）
• 报告结构严格符合模板（七大章节 + 附录）
• 成功标准表格完整
• RACI矩阵完整且正确
• 风险清单有应对措施和Owner
• 沟通机制三要素齐全（例会/信息同步/升级）
• 所有内容来源于 draft.md，无编造
• 表格格式正确，无空缺（宁可写"待补充"）
• 已转换为飞书云文档

---

9) 常见失败模式与修复

失败模式	原因	修复方法
目标模糊	直接照搬用户原话，未提炼	A1 阶段需从需求文档中提炼量化目标，B1 必须有成功标准表格
范围蔓延	未明确 Out of Scope	B2 必须列出"不在范围内"清单，附原因和后续计划
分工不清	只列了团队成员，没有明确职责	B4 必须完成 RACI 矩阵，每活动有且仅有一个 Accountable
里程碑过粗	只写"开发阶段"没有细分	B3 里程碑需精确到周，每个节点有检查方式
风险走过场	只列风险不列应对措施	B5 每个风险必须有应对措施和 Owner
沟通机制缺失	启动报告中未设计沟通方式	B6 必须包含例会/信息同步/升级三层机制
资料获取不全	只用了一个工具	A1-A4 四步均需执行，aily-doc + aily-im + aily-calendar + knowledge_answer 组合使用
历史经验未参考	跳过了 A3 历史参考步骤	A3 必须搜索公司内已有的启动报告，提取可复用经验
draft.md 内容杂乱	原始资料未结构化直接交给 Writer	Module B 必须将原始资料整理为结构化要点后再分发
Writer 输出不符模板	prompt 中未明确模板要求	Module C 的 prompt 必须附上完整模板结构