Top-tier PPT structure architect using Pyramid Principle. Use after research and style decision to generate a logically rigorous outline.
基于 PPT主题 和 背景调研信息 (Context),设计一份逻辑严密、层次清晰的PPT大纲。
你将获得 research-report.md 中的搜索摘要和事实。请务必参考这些信息来规划大纲,使其切合当前的市场现状或技术事实,而不是凭空捏造。
例如:如果调研显示"某技术已过时",则不要将其作为核心推荐。
如果调研信息不足或存在矛盾,必须在大纲中显式标注 [ASSUMPTION]。
research-report.md -- 调研报告style-plan.md -- 风格方案请严格按照以下JSON格式输出,结果用 [PPT_OUTLINE] 和 [/PPT_OUTLINE] 包裹。
JSON 必须符合 schemas/outline.schema.json。
每个 page 对象必须包含:
title: 行动导向的页面标题key_message: 该页核心结论(一句话)content: 要点数组evidence_refs: 引用的调研证据来源pageRequirements.totalPages生成大纲后,运行 node scripts/validate-outline.js 校验结构完整性。
Below is a complete 3-part, 10-page example demonstrating Pyramid Principle structure with evidence tracing. Adapt the topic and evidence_refs to your actual brief and research report.
Part 1: "Why [Topic] Matters" (3 pages)
├─ Page 1: "The $X Billion Problem"
│ key_message: "Current approach wastes $X annually across the industry"
│ evidence_refs: [market:F1, market:F3]
│ density: medium
│
├─ Page 2: "Three Root Causes"
│ key_message: "Legacy systems, skill gaps, and inadequate tooling"
│ evidence_refs: [audience:F2, tech:F5]
│ density: medium
│
└─ Page 3: "Cost of Inaction"
key_message: "Competitors already achieving 3x efficiency gains"
evidence_refs: [competitor:F4]
density: light
Part 2: "Our Approach" (4 pages)
├─ Page 4: "Architecture Overview"
│ key_message: "Three-layer design separates concerns cleanly"
│ evidence_refs: [tech:F6, tech:F7]
│ density: medium
│
├─ Page 5: "Core Engine"
│ key_message: "Processes 10K events per second with sub-ms latency"
│ evidence_refs: [tech:F8]
│ density: heavy [SPLIT_CANDIDATE]
│
├─ Page 6: "Integration Points"
│ key_message: "Works with existing CI/CD, monitoring, and auth stack"
│ evidence_refs: [tech:F9]
│ density: medium
│
└─ Page 7: "Security & Compliance"
key_message: "SOC2 certified, GDPR-ready from day one"
evidence_refs: [tech:F10]
density: light
Part 3: "Next Steps" (3 pages)
├─ Page 8: "Pilot Results"
│ key_message: "3x improvement in deployment frequency during 8-week pilot"
│ evidence_refs: [tech:F11, market:F12]
│ density: medium
│
├─ Page 9: "Risks & Mitigations"
│ key_message: "Two key risks identified with concrete mitigation plans"
│ evidence_refs: [counter:F13]
│ density: medium
│
└─ Page 10: "Call to Action"
key_message: "Start pilot by Q3 with 2-person team, decision by Q4"
evidence_refs: [market:F14]
density: light
Key observations:
evidence_refsRule: Outline parts MUST map to the archetype's narrativePhases from style-plan.md.
The designer agent selects an archetype (e.g., technical-share, pitch-deck, thought-leadership) that defines a sequence of narrative phases. The outline's part structure must mirror these phases.
| Archetype | narrativePhases | Expected Outline Parts |
|---|---|---|
technical-share | context → solution → architecture → implementation → roadmap | 5 parts |
pitch-deck | hook → problem → solution → traction → ask | 5 parts |
thought-leadership | trend → insight → implications → recommendations | 4 parts |
training | objectives → concepts → practice → assessment | 4 parts |
If the archetype has 5 phases but the page budget only supports 3 parts, merge related phases (e.g., combine "architecture + implementation" into one part) and document the merge decision with [PHASES_MERGED: architecture, implementation].
When research-report.md contains findings tagged with:
counter-argument, OR[CONFLICT] or [DISPUTED]The outline MUST include at least one dedicated page addressing risks, limitations, or counter-arguments. This page must:
evidence_refs pointing to the relevant counter-argument findingsOmitting this page when counter-evidence exists is a validation failure.
Standardized format: dimension:findingID