# Manage Up Core

> ManageUp 核心方法论：将大模型的空洞报告改造为数据驱动、结论先行的高质量职场报告。Use when writing any workplace report, status update, or professional document for a boss/manager. Triggers on: '写报告', '汇报', 'report', 'write a report', 'status update', '周报', '月报', '项目汇报', '绩效', '提案', '会议纪要', '复盘'. Applies to ALL report types across industries.

- Skill: `yhyu13/manage-up-core` (Agent Skill, multi-file: 2 files)
- Install (CLI): `npx get-skill add yhyu13/manage-up-core`
- Raw SKILL.md: https://api.skillmd.com/api/skills/yhyu13/manage-up-core/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Docs & Writing
- Author: yhyu13 (https://skillmd.com/u/yhyu13)
- Updated: 2026-11-12
- Page: https://skillmd.com/skills/yhyu13/manage-up-core

---


# ManageUp 核心方法论

大模型写的报告为什么不好？因为它没有你的数据，只能用空话填充。ManageUp 的核心思路：**先收集事实，再组织表达**。让 AI 成为你的写作助手，而不是空话制造机。

---

## 触发场景

- 用户要求写任何向上汇报类内容，例如周报、月报、项目汇报、绩效自评、提案、会议纪要、复盘
- 用户只给了一个模糊请求，例如“帮我写个报告”“整理成老板能看的版本”
- 其他 ManageUp 技能被触发时，本技能的五大原则默认一并生效

---

## 五大原则

所有 ManageUp 技能共享以下原则。生成任何报告前，逐条检查是否违反。

### 原则一：BLUF — 结论先行 (Bottom Line Up Front)

老板的时间比你贵。第一段就要回答"所以呢？"。

- 报告的第一句话必须是结论、状态或核心请求
- 背景信息放在结论之后，不是之前
- 如果老板只读第一段就关掉，他应该已经知道最重要的事

**反面示例**：
> 本周团队在多个方面开展了工作，包括前端优化、后端重构、以及与产品团队的需求对齐……

**正面示例**：
> 核心结论：项目整体进度提前 2 天，但支付模块存在一个高风险阻塞项，需要本周五前决策是否增加 1 名后端人力。

### 原则二：数据锚定 (Data-Anchored)

每一个判断都必须挂钩到用户提供的具体数据。AI 不编造数据，不用模糊词代替数字。

- "进展顺利" → 必须替换为具体完成率、日期、数量
- 没有数据支撑的断言，宁可不写
- 引用用户原始输入中的数字、日期、事实

**禁用词 → 替换表**：

| 禁用表达 | 替换为 |
|---------|-------|
| 取得了一定进展 | 完成率从 X% 提升至 Y% |
| 进展顺利 | 按计划完成 N 项里程碑中的 M 项 |
| 显著提升 | 提升了 X%（从 A 到 B） |
| 有所改善 | 指标从 X 变为 Y |
| 大量工作 | 完成了 N 个任务/处理了 N 个工单 |
| 各方面表现良好 | 在 X、Y、Z 三个维度达标 |
| made good progress | completed N of M milestones |
| significant improvement | improved from X to Y (Z% increase) |
| worked on various tasks | delivered A, B, and C |
| positive feedback | NPS increased from X to Y |

### 原则三：So-What 测试 (So-What Test)

写完每一段，问自己：**老板看完会说"所以呢？"吗？** 如果会，这段话没有价值。

- 每一段必须能回答"这对团队/项目/业务意味着什么？"
- 不是罗列做了什么，而是说明做了之后**产生了什么影响**
- 如果一件事没有影响，考虑是否值得写进报告

### 原则四：行动导向 (Decision-Ready)

报告不是日记，是决策工具。每份报告必须明确：

- **需要老板做什么？** → 审批 / 决策 / 知悉 / 协调资源
- **截止时间是什么？** → 何时需要回复或行动
- **不行动的后果是什么？** → 不决策会导致什么延误或损失

如果报告不需要老板做任何事，在开头标注 `[仅供知悉 / FYI]`。

### 原则五：校准语言 (Calibrated Language)

消灭模糊词。用精确表达替代笼统描述。

| 模糊 | 精确 |
|-----|------|
| 尽快 | 3月25日前 |
| 部分用户 | 影响了 12% 的付费用户（约 3,400 人） |
| 风险较高 | P1 风险：如不处理将导致上线延迟 5 天 |
| 资源紧张 | 差 1 名后端工程师，当前 3 人承担 4 人工作量 |
| soon | by March 25 |
| some users | 12% of paid users (~3,400) |
| high risk | P1: 5-day launch delay if unresolved |
| resource constrained | need 1 more backend engineer; 3 people covering 4-person workload |

---

## 必填输入 (Required Inputs)

在通用场景下，如果用户没有提供足够事实，先一次性收集以下输入：

```text
为了写出一份数据驱动、可汇报的内容，请尽量提供：

1. 你完成了什么：具体交付物、决策、里程碑
2. 关键数据：数量、日期、比例、金额、时长、前后对比
3. 风险或阻塞：卡在哪里、影响多大、需要谁帮助
4. 下一步：接下来最重要的 2-3 件事和目标时间
5. 是否需要老板决策：如果需要，请写明截止时间和不决策的后果

没有的信息可以留空，我不会编造数据。
```

---

## 输入优先工作流 (Input-First Workflow)

这是 ManageUp 最关键的设计：**先问，再写**。

### 为什么要先收集输入？

大模型的空话来源于信息不足。当用户只说"帮我写个周报"，AI 没有任何事实可用，只能编造"本周团队积极推进各项工作"这类废话。

ManageUp 的每个技能都包含一个 **Required Inputs（必填输入）** 清单。在生成报告前，必须先通过提问收集这些信息。

### 收集输入的原则

1. **一次性列出所有需要的输入项**，不要一个一个问（减少来回）
2. **给出示例**，让用户知道该提供什么格式和粒度
3. **接受不完美的输入**，用户可以用口语化、碎片化的方式提供信息
4. **用户没有的数据就留空**，不要 AI 编造
5. **允许用户用中文或英文提供输入**，输出语言跟随用户偏好

### 输入收集模板

当用户请求写报告但没有提供足够信息时，使用以下格式请求输入：

```
为了写出一份数据驱动的 [报告类型]，请提供以下信息（可以用口语化的方式，我来帮你整理）：

1. [输入项 1]：例如 [示例]
2. [输入项 2]：例如 [示例]
3. [输入项 3]：例如 [示例]
...

没有的信息可以跳过，我不会编造数据。
```

---

## 受众分析框架

不同受众需要不同的报告风格。在生成报告前，确认受众类型：

| 受众 | 关注点 | 风格 |
|------|-------|------|
| 直属上级 (Direct Manager) | 细节、执行、风险 | 详细、有数据支撑 |
| 隔级上级 (Skip-level) | 大局、趋势、战略对齐 | 精炼、聚焦结果和影响 |
| 跨部门 (Cross-functional) | 协作点、依赖、时间线 | 去掉专业术语、聚焦接口 |
| 客户/外部 (External) | 价值、进展、信心 | 专业、正面但诚实 |

默认假设受众是**直属上级**。如果用户指定了不同受众，调整详略程度和用词。

---

## 双语策略 (Bilingual Strategy)

ManageUp 同时支持中文和英文输出。

### 语言检测规则

1. **跟随用户输入语言**：用户用中文提供输入 → 输出中文报告；用户用英文 → 输出英文
2. **混合输入**：如果用户混用中英文，默认按占比多的语言输出，或直接询问用户偏好
3. **模板双语**：技能内部的模板和示例同时提供中英文版本

### 中文报告风格

- 简洁、有力、不啰嗦
- 使用短句，避免长从句
- 关键数字加粗或独立成行
- 用 `·` 或 `-` 做列表，不要大段落

### 英文报告风格

- Professional, concise, action-oriented
- Use bullet points over paragraphs
- Bold key metrics and decisions
- Avoid passive voice where possible

---

## 反空话规则 (Anti-Fluff Rules)

- 没有数据支撑的判断不要写
- 优先把“进展顺利”“积极推进”“表现出色”改成数字、日期、交付物和影响
- 如果一句话不能回答“所以呢”或“老板需要做什么”，就删掉或重写
- 具体替换方式遵循上文“禁用词 → 替换表”和“校准语言”规则

---

## 质量检查清单 (Quality Checklist)

每份报告生成后，逐项验证：

- [ ] 第一段是否直接给出了结论/状态？（BLUF）
- [ ] 每个判断是否都有具体数据支撑？（Data-Anchored）
- [ ] 每一段是否能回答"老板看完会怎么想/做什么"？（So-What）
- [ ] 是否明确了需要老板做的事？（Decision-Ready）
- [ ] 是否有禁用词表中的模糊表达残留？（Calibrated Language）
- [ ] 是否遗漏了用户提供的关键信息？
- [ ] 语言是否与用户输入一致？
- [ ] 报告长度是否适当？（不超过必要长度）

---

## 与其他 ManageUp 技能的关系

本技能是基础层。以下技能继承本技能的五大原则，并添加各自的报告模板和规则：

| 技能 | 用途 |
|------|------|
| `weekly-report` | 周报 / 月报 |
| `project-update` | 项目进展汇报 |
| `performance-review` | 绩效自评 |
| `proposal` | 提案 / 资源申请 |
| `meeting-summary` | 会议纪要 |
| `quarterly-review` | 季度复盘 / QBR |

使用任何报告技能时，五大原则和禁用词表自动生效。