Menu
项目启动报告：统一目标、范围、里程碑、分工与风险，形成可落地的启动材料。
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
Based on SOC occupation classification
文档创作年度报告：主要借助 `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 必须附上完整模板结构 |