Menu
项目启动报告：统一目标、范围、里程碑、分工与风险，形成可落地的启动材料。
Instalar com Codex ou Claude Copie este prompt, cole no Codex, Claude ou outro assistente e deixe que ele revise a página da skill e instale para você.
Baseado na classificação ocupacional SOC
文档创作年度报告：主要借助 `aily-doc` 获取用户年度文档信息（数量、点赞、评论、PV、UV 等），并基于这些指标与代表性文档产出年度总结型飞书云文档。
商业计划书：强调市场机会、产品与商业模式、竞争、团队、财务与风险，形成可评审BP。
季度/年度业务汇报：围绕指标达成、业务进展、问题与对策输出结构化业务汇报。
公司调研：基于官方与公开信息输出公司概况、业务结构、竞争位置、经营与风险的结构化研究。
竞品分析：通过统一维度对比产品与市场信息，形成结构化对比结论与机会点。
概念解释：由浅入深讲清概念的定义、原理与本质，面向不同知识背景的读者。
| name | aily-doc-project-kickoff-report |
| label | 项目启动报告 |
| description | 项目启动报告：统一目标、范围、里程碑、分工与风险，形成可落地的启动材料。 |
项目启动报告：统一目标、范围、里程碑、分工与风险，形成可落地的启动材料。
task（subagent_type: writer）委托 Writer Agent 创建飞书云文档。feishu-use-skills-map 并按其指引调用对应技能get_skills 获取对应飞书技能说明feishu-use-skills-map 并调用对应技能| 工具 | 用途 | 适用场景 |
|---|---|---|
aily-doc | 搜索/读取飞书云文档 | 需求文档、立项文档、历史启动报告 |
aily-calendar | 查询日历/会议 | 项目相关会议、排期信息 |
aily-im | 获取群消息/群成员 | 项目群成员列表、历史讨论 |
knowledge_answer | 查询内部知识库 | 项目背景、技术栈、组织信息 |
file | 将素材写入 draft.md（append 模式） | 每个数据步骤完成后 |
主 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"}
]
}
核心原则：优先使用飞书工具获取内部资料，
knowledge_answer作为补充和兜底。每个步骤完成后，将结果结构化写入draft.md。
目标：获取项目的来龙去脉、立项原因、业务目标。
工具与策略：
aily-doc 搜索需求文档/立项文档：aily-doc(
action: "search",
query: "{项目名称} 需求文档 立项 PRD",
filters: { doc_type: "docx" }
)
aily-doc 读取关键文档（搜索到后深度阅读）：aily-doc(
action: "read",
doc_token: "{文档token}",
prompt: "提取项目背景、业务目标、核心需求、发起原因"
)
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 查询结果
目标：明确项目组织结构、核心成员、利益相关方。
工具与策略：
aily-im 获取项目群成员：aily-im(
action: "get_group_members",
query: "{项目名称}",
prompt: "获取项目相关群组的成员列表及其角色"
)
aily-calendar 查询相关会议：aily-calendar(
action: "search",
query: "{项目名称} 启动 评审 规划",
time_range: "近30天"
)
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矩阵中的具体分工需用户补充
目标：找到公司内部类似项目的启动报告，作为结构和内容参考。
工具与策略：
aily-doc 搜索类似项目启动报告：aily-doc(
action: "search",
query: "项目启动报告 kickoff",
filters: { doc_type: "docx" }
)
aily-doc 搜索同类型项目文档：aily-doc(
action: "search",
query: "{项目类型关键词} 启动 立项 规划",
filters: { doc_type: "docx" }
)
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项目里程碑过于粗放，无法追踪进度
目标：了解项目涉及的技术栈、系统依赖、架构约束。
工具与策略：
knowledge_answer 查询技术栈/系统约束：knowledge_answer(
query_list: [
"{项目名称} 技术栈 技术架构",
"{项目名称} 系统依赖 接口依赖",
"{项目名称} 技术约束 非功能性需求"
],
explanation: "获取项目的技术约束和系统依赖信息"
)
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人支持
核心原则：将 Module A 收集的原始资料，按照启动报告的框架进行结构化分析和整理，形成"目标-范围-计划-分工-风险-沟通"完整链条。
分析要点：
写入 draft.md（使用 file(path: "/home/workspace/draft.md", mode: "append")）：
## B1. 项目目标与成功标准
### 项目目标
- **业务目标**：...（从需求文档/立项文档中提取）
- **技术目标**：...（从技术方案中提取）
- **用户目标**：...（从用户反馈/PRD中提取）
### 成功标准
| 维度 | 指标 | 目标值 | 衡量方式 |
|------|------|--------|---------|
| 业务 | XX转化率 | 提升X% | 数据看板 |
| 技术 | 系统响应时间 | <Xms | 监控系统 |
| 用户 | 用户满意度 | >X分 | 用户调研 |
| 进度 | 按时交付率 | 100% | 里程碑检查 |
### 非目标（明确排除）
- 本项目不追求...
- 本阶段不涉及...
分析要点：
写入 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架构
分析要点：
写入 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 工作日
分析要点：
写入 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（知会）
分析要点：
写入 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 |
### 风险应对策略
- **规避**：提前识别并消除风险源
- **缓解**：降低发生概率或减轻影响
- **转移**：将风险转移给更合适的责任方
- **接受**：低概率低影响的风险可接受并监控
分析要点：
写入 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个工作日内对齐 |
主 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 收到任务
↓
1. file_read: 读取 /home/workspace/draft.md
↓
2. outline_generator: 基于模板生成结构化大纲
↓
3. document_write: 生成 项目启动报告.feishu.md
↓
4. feishu_doc_create: 转换为飞书云文档
↓
5. end: 返回飞书文档链接
draft.md，不得编造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 | 初始版本 |
用户: "帮我准备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: 返回飞书文档链接 │
└─────────────────────────────────────────────────────────────┘
↓
飞书云文档项目启动报告
| 失败模式 | 原因 | 修复方法 |
|---|---|---|
| 目标模糊 | 直接照搬用户原话，未提炼 | 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 必须附上完整模板结构 |