presentation-creation

演示文稿制作

此技能可让 AI Agent 将原始内容——大纲、文档、会议纪要或数据——转换为专业的演示文稿。Agent 会运用每页一个核心观点、视觉层次和精简文字等幻灯片设计原则，制作清晰、生动且可直接用于演示的幻灯片。支持多种输出格式，包括 Marp Markdown、reveal.js HTML、Google Slides 和 PPTX。

工作流

1. 收集内容并明确受众。 收集源材料——大纲、技术文档、会议纪要或一组谈话要点。确定目标受众（高管、工程师、客户、投资者）和演示目标（告知、说服、培训、推介）。受众决定了用词深度、详细程度和视觉风格。投资者推介应使用大胆的主张和数据；技术深入讲解则应使用架构图和代码片段。

2. 构建叙事脉络。 将内容组织成逻辑清晰的故事：开场引子、问题陈述、解决方案或核心信息、支撑证据，以及结尾行动号召。将这一脉络映射为逐页大纲。典型的 15 分钟演示通常包含 10-15 张幻灯片。每张幻灯片应传达一个核心观点——如果一张幻灯片需要两个标题，就应拆成两张。在各部分之间加入过渡内容，以保持叙事流畅。

3. 精简撰写幻灯片内容。 为每张幻灯片撰写简洁的标题（不超过 8 个词），说明结论，而非主题。使用“营收同比增长 40%”，而不是“营收概览”。正文控制在 3-5 个项目符号或一段简短文字以内。尽可能用视觉元素替代文字——使用能够更快传达观点的图表、示意图、屏幕截图或图片。为每张幻灯片撰写演讲者备注，列出演示者应口头陈述的完整要点。

4. 建议视觉元素和版式。 为每张幻灯片推荐适当的视觉呈现方式：对比使用柱状图，趋势使用折线图，流程使用流程图，产品演示使用屏幕截图，功能列表使用图标网格，营造情绪感染力则使用满版图片。指定版式为仅标题、标题加正文、双栏、左侧图片或满版图片。建议统一的配色方案和字体搭配（例如，标题使用 Inter，正文使用 Source Sans）。

5. 按目标格式生成幻灯片。 按照指定格式生成完整的幻灯片。Marp 格式应输出单个 Markdown 文件，并使用 --- 作为幻灯片分隔符及 Marp 指令。reveal.js 格式应输出带有 section 标签的 HTML 文件。PPTX 格式应生成 python-pptx 脚本或直接生成文件。Google Slides 格式应输出与 Slides API 兼容的结构化 JSON 载荷。包括演讲者备注、幻灯片编号和所有嵌入媒体的引用。

6. 检查并优化。 根据演示文稿最佳实践检查幻灯片：每张幻灯片的正文不超过 40 个词；每张幻灯片都有清晰的结论式标题；通过视觉形式的变化避免单调（不要全部使用项目符号）；开场页要引人注目；结尾页要明确指出下一步。调整节奏——如果幻灯片过长，找出可以合并或移至附录的页面。

用法

向 Agent 提供源内容（或主题描述）、目标受众、所需幻灯片数量和输出格式。Agent 将返回包含演讲者备注的完整幻灯片。

提示词格式：

Create a presentation about [topic].
Source material: [outline, document path, or key points]
Audience: [who will see this]
Slide count: [target number of slides]
Output format: [marp / revealjs / pptx / google-slides]

示例

示例 1：产品发布演示文稿（Marp 格式）

输入：

Create a presentation for the launch of "Nimbus," a cloud cost optimization tool.
Audience: Engineering managers and VPs at mid-size SaaS companies.
Slide count: 7
Output format: marp

输出：

---
marp: true
theme: default
paginate: true
---

# Nimbus
## Cut your cloud bill by 35% — automatically

![bg right:40%](cloud-hero.png)



---

# The Problem: Cloud Spend Is Out of Control

- 73% of engineering leaders say cloud costs exceeded budget last quarter
- Idle resources, oversized instances, and forgotten dev environments
- Manual cost reviews happen quarterly at best — waste compounds daily



---

# How Nimbus Works

1. **Connect** — Link your AWS, GCP, or Azure accounts in under 5 minutes
2. **Analyze** — Nimbus scans utilization, traffic patterns, and billing data
3. **Optimize** — Get prioritized recommendations ranked by savings impact
4. **Automate** — Enable auto-scaling rules and scheduled shutdowns



---

# Results: What Our Beta Customers Achieved

| Company       | Monthly Savings  | Time to ROI |
|---------------|-----------------|-------------|
| Acme Corp     | $42,000 (31%)   | 2 weeks     |
| DataFlow Inc  | $67,000 (38%)   | 3 days      |
| Bright SaaS   | $28,000 (29%)   | 1 week      |

Average: **35% cost reduction** within the first month.



---

# Built for Engineering Teams, Not Finance

- No code changes required — works at the infrastructure layer
- Slack and PagerDuty integration for real-time alerts
- Granular controls per team, environment, or service
- Full audit log — every optimization is logged and reversible



---

# Pricing

- **Starter:** Free for accounts under $10K/month cloud spend
- **Pro:** 5% of realized savings (you only pay when you save)
- **Enterprise:** Custom pricing with dedicated support and SLAs

No upfront commitment. Cancel anytime.



---

# Get Started Today

**Start your free trial at nimbus.io/start**

- 5-minute setup, no credit card required
- See your first savings recommendations within 24 hours
- Questions? Email [email protected]

示例 2：将技术文档转换为演示文稿大纲

输入：

Convert the following technical document summary into a presentation outline.
Source: "Our API gateway handles 2.3M requests/day. Current P99 latency is
450ms, target is under 200ms. Root cause: synchronous auth middleware. Proposed
fix: move auth to async verification with JWT caching. Expected impact: 60%
latency reduction. Rollout plan: canary 5% then 25% then 100% over 3 weeks."
Audience: Backend engineering team
Output format: outline

输出：

Slide 1: Title
  Headline: "Cutting API Gateway Latency by 60%"
  Subtitle: Backend Architecture Proposal — February 2026
  Visual: None (clean title slide)

Slide 2: Current State
  Headline: "Our P99 Latency Is 2x Over Target"
  Bullets:
    - 2.3M requests/day through the API gateway
    - Current P99: 450ms | Target: under 200ms
    - Latency spikes correlate with auth middleware execution
  Visual: Line chart showing P99 latency over past 30 days with 200ms target

Slide 3: Root Cause
  Headline: "Synchronous Auth Is the Bottleneck"
  Bullets:
    - Every request performs a synchronous token validation round-trip
    - Auth middleware adds 180-250ms per request at P99
    - Blocking call prevents connection reuse under load
  Visual: Request waterfall showing auth middleware segment highlighted

Slide 4: Proposed Solution
  Headline: "Async Auth with JWT Caching"
  Bullets:
    - Replace synchronous token validation with async JWT verification
    - Cache validated tokens in Redis with 5-minute TTL
    - Fall back to synchronous validation on cache miss
  Visual: Before/after architecture diagram showing the request flow

Slide 5: Expected Impact
  Headline: "60% Latency Reduction, Zero Downtime"
  Bullets:
    - Projected P99: ~180ms (under the 200ms target)
    - Cache hit rate expected at 92%+ based on token reuse patterns
    - No API contract changes — fully backward compatible
  Visual: Bar chart comparing current vs. projected P99 latency

Slide 6: Rollout Plan
  Headline: "Canary Rollout Over 3 Weeks"
  Bullets:
    - Week 1: 5% canary with real-time latency monitoring
    - Week 2: 25% rollout if P99 stays under 200ms
    - Week 3: 100% rollout with automated rollback trigger
  Visual: Timeline graphic showing the three rollout phases
  CTA: "Review the RFC by Friday — link in Slack #backend-arch"

最佳实践

• 每张幻灯片只表达一个观点。 如果一张幻灯片需要两个标题，就拆成两张。认知负担过重会影响记忆效果。受众更容易记住单一、明确的要点。
• 标题应直接点明结论，而非主题。“收入同比增长 40%”比“收入概览”更好。受众只看标题就应能理解这张幻灯片要表达什么。
• 保持 3:1 的图文比例。 每三张包含图表、图片或示意图的幻灯片，最多安排一张以文字为主的幻灯片。丰富视觉内容有助于保持注意力。
• 为每张幻灯片撰写演讲备注。 幻灯片是受众的观看内容，演讲备注是演讲者的讲稿。不要把应该口头讲述的内容放在幻灯片上。
• 每分钟演讲时间不超过一张幻灯片。 15 分钟的演讲时段最多安排 12-15 张幻灯片。匆忙讲解内容密集的幻灯片，不如删减内容。
• 以明确的下一步行动收尾。 最后一张幻灯片应明确告诉受众该做什么：访问某个 URL、安排会议、批准提案，或在指定日期前审阅文档。

边缘情况

• 未提供源材料。 如果用户只给出主题，没有提供支持内容，则生成一份包含占位数据的大纲，并明确标注假设。提示用户提供关键指标和论点。
• 面向非技术受众的高技术性内容。 简化术语，用高层次的比喻替代架构图，并着重说明成果（如节省成本、提升速度），而非实现细节。
• 篇幅很长的源文档（10 页以上）。 大幅精简，找出 3-5 个最重要的要点，并将支持性细节移至附录幻灯片。可提供摘要版幻灯片和详细参考版幻灯片。
• 无障碍要求。 确保颜色对比度符合 WCAG AA，为所有视觉内容提供替代文本描述，并避免仅通过颜色传达含义。使用大号字体（正文不小于 24pt，标题不小于 32pt）。
• 要求多种输出格式。 先以 Marp Markdown（兼容性最高的格式）生成标准版本，再提供其他格式的转换说明或脚本。