官方技能 · 运营与行政

项目启动简报

v1.0.0 · 2026年11月4日 更新

写一页项目启动简报：目标、一个成功指标、范围内外、里程碑、简化 RACI 表、各有负责人的主要风险，以及团队的沟通方式。

可在 Claude、ChatGPT 和编程智能体中使用。在 Team 和 Business 套餐中，Pod 里的官方技能会在我们改进后自动更新到最新版。

适用场景

• 项目、产品发布或客户合作即将开始，需要一页共同的文档
• 进行中的项目对范围或谁来拍板有分歧

你需要提供

• 目标及为什么现在做
• 目标日期
• 参与的人和角色
• 已知的限制和决定（可选）

你会得到

一页 Markdown 简报：目标、成功指标、范围表、里程碑、简化 RACI 角色、风险和沟通计划。

工作方式

1. 用 1 到 2 句话写目标 说明什么会变得不同，以及为什么现在很重要。Asana 的启动会指南认为，就“我们努力的方向以及这项工作为什么重要”达成一致，是启动会最重要的部分。
2. 选一个成功指标 一个数字加一个日期（“6月30日前有 40 个客户迁移到新套餐”），或者一个谁都能检查的“是 / 否”测试。Atlassian 的启动会方法把这类测试称为“对‘完成’的共同定义”。这个技能的默认做法：一个主要指标，最多 2 个护栏指标（不能变差的事项）。
3. 把范围分成范围内和范围外 列出 3 到 6 项范围内的事项，以及至少 3 项范围外的事项。范围外的事项，就是做到一半会有人来要的东西；提前写明是防止范围蔓延的办法。如果某项不清楚，放进待解决的问题，不要放进范围内。
4. 设定 3 到 6 个里程碑 每个里程碑都是一件已完成、可检查的事，带日期和负责人（“定价页在测试环境上线”），而不是一项活动（“做定价页”）。最后一个里程碑的日期就是成功指标的日期。
5. 填写简化 RACI 表 每个工作流一行。R（执行）负责做事；A（最终负责）签字确认并对结果负责；C（咨询）在推进前审阅；I（知会）了解进展。Asana 的 RACI 指南说：“每项任务只应有一个最终负责人。”这个技能的默认做法：整个项目也只有一位最终负责人，写在最上方。
6. 列出最主要的 3 到 5 个风险 每个风险写明：可能出什么问题、可能性多大（高 / 中 / 低）、现在采取什么措施，以及一位负责人。找风险的快捷方法是 Atlassian 的事前验尸（pre-mortem）：团队各自默默写下可能出问题的地方，然后投票选出最大的威胁，给每个主要风险安排一个带负责人的行动。没有负责人的风险只是担心，不是计划。
7. 写明团队怎么沟通 日常交流在哪里（频道）、进展怎么同步（每周书面更新，哪天、由谁写）、什么时候开会，以及决定记录在哪里。Asana 的启动会指南把这列为启动会的标准内容。
8. 列出待解决的问题和已决定的事项 待解决的问题要有负责人和日期。已经决定的事每条写一行，免得启动会上又重新讨论。

SKILL.md 全文

这就是 AI 读取的完整文件。 下载

---
name: project-kickoff-brief
description: 根据项目目标和零散笔记写一页项目启动简报：目标及其重要性、一个成功指标、范围内和范围外的事项、带日期的里程碑、只有一位最终负责人的简化 RACI 角色表、各有负责人的主要风险，以及团队的沟通方式。适用于项目即将启动、有人要一份启动文档、项目章程或项目简报，或者团队需要在开工前就谁做什么达成一致时。
---

# 项目启动简报

项目启动简报让所有人在开工之前，就项目为什么存在、“完成”是什么样子、谁负责什么达成一致。篇幅一页。凡是不影响大家这个月做什么的内容，都放进链接文档里。

## 适用场景

- 一个新项目、产品发布、系统迁移或客户合作即将开始，大家需要一页共同的文档。
- 有人要“启动文档”“项目章程”“项目一页纸”或“启动会预读材料”。
- 项目已经在进行，但大家对范围或谁来拍板有分歧。写这份简报来重新对齐。
- 不适用于产品规格或需求文档。产品做什么用 PRD；这份简报讲的是项目怎么推进。

## 需要准备

- 目标，以及为什么现在要做。没有的话，问一次：“这件事做完之后，业务或客户会有什么变化？”
- 截止日期或目标日期。没有的话，写“[未定日期]”，并把它列为第一个待解决的问题。
- 参与的人和各自的角色。如果角色不清楚，就列出姓名，并把 RACI 表标为“[草稿，启动会上确认]”。
- 可选：预算、已知的限制条件、相关项目，以及已经决定的事项。

## 步骤

1. **用 1 到 2 句话写目标。** 说明什么会变得不同，以及为什么现在很重要。Asana 的启动会指南认为，就“我们努力的方向以及这项工作为什么重要”达成一致，是启动会最重要的部分。
2. **选一个成功指标。** 一个数字加一个日期（“6月30日前有 40 个客户迁移到新套餐”），或者一个谁都能检查的“是 / 否”测试。Atlassian 的启动会方法把这类测试称为“对‘完成’的共同定义”。这个技能的默认做法：一个主要指标，最多 2 个护栏指标（不能变差的事项）。
3. **把范围分成范围内和范围外。** 列出 3 到 6 项范围内的事项，以及至少 3 项范围外的事项。范围外的事项，就是做到一半会有人来要的东西；提前写明是防止范围蔓延的办法。如果某项不清楚，放进待解决的问题，不要放进范围内。
4. **设定 3 到 6 个里程碑。** 每个里程碑都是一件已完成、可检查的事，带日期和负责人（“定价页在测试环境上线”），而不是一项活动（“做定价页”）。最后一个里程碑的日期就是成功指标的日期。
5. **填写简化 RACI 表。** 每个工作流一行。R（执行）负责做事；A（最终负责）签字确认并对结果负责；C（咨询）在推进前审阅；I（知会）了解进展。Asana 的 RACI 指南说：“每项任务只应有一个最终负责人。”这个技能的默认做法：整个项目也只有一位最终负责人，写在最上方。
6. **列出最主要的 3 到 5 个风险。** 每个风险写明：可能出什么问题、可能性多大（高 / 中 / 低）、现在采取什么措施，以及一位负责人。找风险的快捷方法是 Atlassian 的事前验尸（pre-mortem）：团队各自默默写下可能出问题的地方，然后投票选出最大的威胁，给每个主要风险安排一个带负责人的行动。没有负责人的风险只是担心，不是计划。
7. **写明团队怎么沟通。** 日常交流在哪里（频道）、进展怎么同步（每周书面更新，哪天、由谁写）、什么时候开会，以及决定记录在哪里。Asana 的启动会指南把这列为启动会的标准内容。
8. **列出待解决的问题和已决定的事项。** 待解决的问题要有负责人和日期。已经决定的事每条写一行，免得启动会上又重新讨论。

## 输出格式

```markdown
# [项目名称] — 项目启动简报

**最终负责人：** [一个名字] · **开始：** [日期] · **目标日期：** [日期或“未定日期”]

## 目标
[1–2 句话：什么会改变、为谁改变、为什么是现在。]

## 成功指标
- **主要指标：** [数字 + 日期，或“是 / 否”测试]
- **护栏指标：** [不能变差的事项，或删除此行]

## 范围
| 范围内 | 范围外 |
|---|---|
| [事项] | [事项] |

## 里程碑
| 里程碑（一件已完成的事） | 负责人 | 日期 |
|---|---|---|
| [里程碑] | [姓名] | [日期] |

## 角色（简化 RACI）
| 工作流 | 执行（R） | 最终负责（A） | 咨询（C） | 知会（I） |
|---|---|---|---|---|
| [工作流] | [姓名] | [一个名字] | [姓名] | [姓名或群组] |

## 风险
| 风险 | 可能性 | 现在采取的措施 | 负责人 |
|---|---|---|---|
| [风险] | [高/中/低] | [行动] | [姓名] |

## 沟通方式
- **日常：** [频道]
- **进展：** [书面更新，哪天，由谁写]
- **会议：** [什么会，多久一次]
- **决定记录在：** [位置]

## 已决定
- [决定，一行]

## 待解决的问题
- [问题] — [负责人]，[日期] 前
```

## 示例

**输入：** “我们要把 120 个活跃客户从旧的计费工具（账易）迁到 Stripe。4月7日启动；账易 6月30日停用。王丹牵头，马骏做系统对接，李雪负责客户邮件，财务（刘琳）要在 5月2日前确认新的发票模板。CEO 唐涛希望在 7月1日调价前完成。马骏的计划：4月25日前 5 个内部测试账户在 Stripe 测试模式下计费正确，6月13日前所有客户上线。李雪 5月16日前发出通知，之后在每个客户迁移前 1 周发提醒，并给前 20 大客户打电话。不做的：已取消客户的历史记录、自助计费门户、会计系统的改动。担心的：保存的银行卡可能迁不过来；切换当月有人被重复扣费。付款失败率不能上升。我们在 #billing-migration 沟通，王丹每周五写进展更新，每周二开 20 分钟会，决定记在项目文档里。已经决定迁移期间不调价。刘琳想知道停用后账易要不要保留一个月的只读权限。”

**输出：**

```markdown
# 计费系统迁移到 Stripe — 项目启动简报

**最终负责人：** 王丹 · **开始：** 4月7日 · **目标日期：** 6月30日

## 目标
在 7月1日调价前把所有客户从账易迁到 Stripe，让新价格在同一个系统上生效，并停用账易。

## 成功指标
- **主要指标：** 6月30日前，120 个活跃客户全部通过 Stripe 计费。
- **护栏指标：** 任何月份都没有客户被重复扣费或漏扣；付款失败率不高于目前的月度水平。

## 范围
| 范围内 | 范围外 |
|---|---|
| 迁移活跃订阅和已保存的银行卡 | 调价（已决定：迁移期间不调价） |
| 经财务确认的新发票模板 | 迁移已取消客户的历史记录 |
| 迁移前后发给客户的邮件 | 新的自助计费门户 |
| 停用账易 | 会计系统的改动 |

## 里程碑
| 里程碑（一件已完成的事） | 负责人 | 日期 |
|---|---|---|
| Stripe 测试模式下 5 个内部账户计费正确 | 马骏 | 4月25日 |
| 发票模板确认通过 | 刘琳 | 5月2日 |
| 客户通知邮件已发出 | 李雪 | 5月16日 |
| 120 个客户全部在 Stripe 上线 | 马骏 | 6月13日 |
| 账易已停用 | 王丹 | 6月30日 |

## 角色（简化 RACI）
| 工作流 | 执行（R） | 最终负责（A） | 咨询（C） | 知会（I） |
|---|---|---|---|---|
| 系统对接和数据迁移 | 马骏 | 王丹 | 刘琳 | 唐涛 |
| 发票 | 马骏 | 刘琳 | 王丹 | 李雪 |
| 客户邮件 | 李雪 | 王丹 | 刘琳 | 唐涛 |

## 风险
| 风险 | 可能性 | 现在采取的措施 | 负责人 |
|---|---|---|---|
| 已保存的银行卡迁不过来，客户必须重新填写 | 中 | 本周询问账易客服是否支持把银行卡数据导出到 Stripe | 马骏 |
| 切换当月有客户在两个系统里都被扣费 | 中 | 每个订阅在 Stripe 开始计费的当天就关闭账易里的对应订阅；每天核对清单 | 马骏 |
| 客户忽略通知，错过变更 | 高 | 5月16日前发出通知，每次迁移前 1 周发提醒；李雪给前 20 大客户打电话 | 李雪 |

## 沟通方式
- **日常：** #billing-migration
- **进展：** 王丹每周五发书面更新
- **会议：** 每周二 20 分钟进度会
- **决定记录在：** 项目文档的“决定”部分

## 已决定
- 迁移期间不调价。

## 待解决的问题
- 停用后账易要不要保留一个月的只读权限？ — 刘琳，[启动会上确定日期] 前
```

## 发送前检查

- [ ] 目标说明了为什么是现在，成功指标是带日期的数字或“是 / 否”测试。
- [ ] 范围外至少有 3 项有人可能会来要的事项。
- [ ] 每个里程碑都是一件已完成的事，有一位负责人和一个日期。
- [ ] RACI 表每行只有一个最终负责人，项目最上方写明了一位负责人。
- [ ] 每个风险都有现在就采取的措施和一位负责人。
- [ ] 没有出现输入中没有的姓名、日期或数字；空缺标为“[未定日期]”或列为待解决的问题。
- [ ] 篇幅在一页以内。

## 常见错误

- 写一个谁都没法检查的成功指标（“改善计费”）。问清楚什么数字或测试能证明它。
- 范围外留空。第 4 周的争论就是从这里开始的。
- 一行里有两位最终负责人。如果两人都必须同意，就让一人做最终负责人，另一人做咨询。

与团队共享

把它添加到 AI Skill Pod，团队里的每个人（包括外包人员）都能在自己的 AI 中使用同一个版本。 了解与团队共享 AI 技能的最佳方式

添加到团队的 Pod

更新记录

• v1.0.0 · 2026年11月4日 · First release.