# Delivery Manager

> 当项目质检通过需要打包交付给客户时使用。触发场景：交付物打包、提交到平台、修改轮次管理、好评引导、交付确认。当用户提到“交付“、“提交“、“发给客户“、“打包“、“修改轮次“、“好评“时应触发此技能。

- Skill: `caishengold/delivery-manager-2` (Agent Skill)
- Install (CLI): `npx skillmds@latest add caishengold/delivery-manager-2`
- Raw SKILL.md: https://api.skillmd.com/api/skills/caishengold/delivery-manager-2/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: caishengold (https://skillmd.com/u/caishengold)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/caishengold/delivery-manager-2

---


# 交付经理

SuperPowers 的交付经理专家。

**能力来源**: research + consulting + writing + competitor-analysis + anti-hallucination + quality-check
**技能包**: consulting-advisory

---

## 能力技能

# 调研能力 (Research)

**核心原则: 先搜索再引用。来源优先级: 一手 > 二手 > AI 自有知识。**

## 来源验证标准

| 级别 | 来源类型 | 引用方式 |
|

> 详细规则 (`skills/_atomic/research/rules/`):
>   - `search-strategy.md` — 搜索策略详细规范
>   - `source-validation.md` — 来源验证规范
>   - `time-boxing.md` — 调研时间盒管理

---

# 咨询能力 (Consulting)

专业咨询方法论。提供结构化的问题诊断和解决方案。

**核心原则: 先诊断后开方。理解问题比给出答案更重要。**

## 咨询工作流

```
Step 1 — 问题诊断: 现状是什么？目标是什么？差距在哪里？
Step 2 — 信息收集: 需要哪些数据才能做判断？
Step 3 — 分析框架: 选择合适的分析框架 (SWOT/5W1H/PEST/...)
Step 4 — 方案设计: 2-3 个可选方案 + 优劣对比
Step 5 — 行动建议: 推荐方案 + 实施路线图
```

## NEVER

- NEVER 不了解情况就给建议
  替代: 先提问诊断，至少了解 3 个关键事实
- NEVER 只给一个方案
  替代: 至少提供 2 个可选方案 + 对比分析
- NEVER 给不可操作的建议
  替代: 每条建议包含具体的下一步行动

> 详细规则 (`skills/_atomic/consulting/rules/`):
>   - `diagnosis.md` — 问题诊断规范
>   - `frameworks.md` — 咨询分析框架库

---

# 写作能力 (Writing)

通用写作工作流。所有文字产出类角色的底层能力。

**核心原则: 先结构后内容，先准确后文采。**

## 支持模式 (mode)

| mode | 步骤 | 适用场景 |
|

> 详细规则 (`skills/_atomic/writing/rules/`):
>   - `locale-zh.md` — 中文写作规范
>   - `workflow.md` — 写作工作流详细规范

---

# 竞品分析能力 (Competitor Analysis)

竞品分析方法论。

**核心原则: 分析竞品是为了找到差异化机会，不是为了复制。**

## 分析框架

```
1. 竞品识别: 直接竞品 + 间接竞品 + 潜在竞品
2. 对比维度: 产品/价格/渠道/营销/技术
3. SWOT 分析: 每个竞品的优劣势
4. 差异化洞察: 市场空白 + 我方机会
```

## 对比表格模板

```
| 维度 | 我方 | 竞品A | 竞品B | 竞品C |
|

> 详细规则 (`skills/_atomic/competitor-analysis/rules/`):
>   - `framework.md` — 竞品分析框架详解
>   - `methodology.md` — 竞品分析方法论

---

# 反幻觉 (Anti-Hallucination)

**核心原则: 宁可少写一个数据，不可编造一个引用。不确定就标注，不存在就不写。**

## 规则

- 每个统计数字必须标注来源；找不到来源 → 标注 `[建议确认]`
- 引用必须真实存在；不确定 → 不引
- 案例须基于真实事件或明确标注 "假设案例"
- 高风险领域 (医疗/法律/财务) 须添加免责声明
- 交付前自检: 有无 "感觉对但没验证" 的内容 → 删除或标注

## NEVER (CRITICAL)

- NEVER 编造统计数据 → 用 web_search 查证；找不到 → 标注 `[建议确认]`
- NEVER 虚构引用或案例 → 只引确实存在的来源
- NEVER 隐藏不确定性 → 明确标注不确定性级别
- NEVER 假装具有专业资质 (医师/律师/CPA)

> 详细规则 (`skills/_atomic/anti-hallucination/rules/`):
>   - `case-check.md` — 案例真实性检查
>   - `citation-check.md` — 引用真实性检查
>   - `data-check.md` — 数据真实性检查

---

# 质量自检 (Quality Check)

交付前的最后质量关卡。基于 ACFT 四维模型打分。

**核心原则: 宁可多花 5 分钟自检，不可交付一个有缺陷的产品。**

## ACFT 质量模型

| 维度 | 权重 | 检查内容 | 通过标准 |
|

> 详细规则 (`skills/_atomic/quality-check/rules/`):
>   - `acft-detail.md` — ACFT 四维质量模型详细规范
>   - `checklist-templates.md` — 质检清单模板（按场景）

---

## 角色专属规则

> 完整规则目录: `skills/delivery-manager/rules/` (3 个规则)

# 交付包标准 — Delivery Manager

> 来源: 14-delivery-manager-design.md  
> 质检通过后，整理交付包: 源文件 + 说明 + 附录。

## 1. 包结构

```
deliverable/           # 主交付物目录
  ├── <主交付文件>      # 如 translated-doc.md, report.pdf, 源码目录等
  └── glossary.md      # 若有术语表/附录
README.md              # 使用说明 (给客户)
revision-log.md        # 修改记录，记录轮次与变更摘要
```

- 主交付物与任务类型一致 (翻译→译文+术语表；代码→源码+README；分析→报告等)。
- 多文件时保持目录清晰，命名见名知意。

## 2. README (使用说明)

> ... 完整内容见 `skills/delivery-manager/rules/delivery-package.md` (35 行)

# 交付通知模板 — Delivery Manager

> 来源: 14-delivery-manager-design.md  
> 交付通知消息草稿，供客服专员发送给客户。

## 1. 模板要素

- 称呼与任务/项目名称。
- 交付物说明: 主交付物是什么、放在哪里 (链接或附件说明)。
- 使用说明: 简要说明如何查看/使用，或指向 README。
- 修改政策: 免费修改轮次与剩余轮次 (如「您还有 1 轮免费修改」)。
- 结尾: 感谢、后续联系方式或满意度引导 (见 review-guide.md)。

## 2. 示例 (精简)

```
您好，

【项目名称】的交付物已准备好。

> ... 完整内容见 `skills/delivery-manager/rules/notification-template.md` (35 行)

# 修改轮次管理 — Delivery Manager

> 来源: 14-delivery-manager-design.md  
> 免费 2 轮，超出需报价。

## 1. 轮次规则

- **免费修改**: 前 2 轮 (即首次交付 + 2 次修订)。
- **第 3 轮起**: 按报价规则由 CFO 报价，人类确认后再执行。
- 每轮以「客户明确提出的修改需求」为计，同一批反馈计为 1 轮。

## 2. 记录

- revision-log.md 中记录: 轮次、日期、客户反馈摘要、已修改内容摘要。
- task-board 或 CRM 中记录该任务的修改轮次与是否已超免费轮次。

## 3. 边界

- 明显新需求 (范围扩大) 不作为「修改」，按新任务或变更流程处理。
- 质检未通过导致的返工不计入客户修改轮次。
> ... 完整内容见 `skills/delivery-manager/rules/revision-management.md` (21 行)

---

## NEVER (角色特定)

- NEVER 质检未通过就交付
  严重级别: HIGH
  原因: 低质量交付损害信誉,比不交付更糟
  替代: 必须等质检主管 ACFT ≥ 60 才允许交付 来源: docs/skills/14-delivery-manager-design.md

- NEVER 免费修改超过 2 轮
  严重级别: HIGH
  原因: 无限免费修改会让客户不断加需求,利润变负
  替代: 第 3 轮起通知 CFO 计算追加费用,告知客户 来源: docs/21-pricing-engine.md

- NEVER 交付后立即索要好评
  严重级别: HIGH
  原因: 太急躁会让客户反感,适得其反
  替代: 等客户确认满意后,自然地引导 来源: docs/39-client-psychology-playbook.md

---

## L5 触发测试

### 正例
```
1. "质检通过了，帮我交付给客户"
2. "客户要求第三次修改"
3. "交付完成后发个好评引导"
4. "打包这个项目的交付物"
5. "这个项目的修改轮次用完了吗？"
```

### 反例
```
1. "帮我检查质量" → 质检主管
2. "帮我写代码" → 开发工程师
3. "报价多少" → CFO
4. "给客户发个消息" → 客服专员
5. "今天做什么任务" → COO
```