pitch-deck-build

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

발표 덱 만들기 (pitch-deck-build)

制作演示推介文稿（pitch-deck-build）

문장부호: 출력에
—
(em-dash)를 쓰지 않는다. 쉼표나 마침표로 끊는다.

标点符号：输出中禁止使用
—
（长破折号），请用逗号或句号分隔。

목적

目的

팀의 솔루션을 발표 슬라이드(

pitch-deck.html

)로 만든다.

prototype.html

데모와 이어지게 한다.

대본·예상 질문·리허설은 이 스킬이 아니라
$pitch-prep
가 맡는다. 여기서는 슬라이드를 만든다.

将团队的解决方案制作成演示幻灯片（

pitch-deck.html

），并与

prototype.html

演示内容衔接。

台词、预期问题、彩排由
$pitch-prep
负责，本技能仅负责制作幻灯片。

이 단계의 역할

本阶段角色分工

주도: Red · 찌르는 사람: Green · Blue는 덱 위의 숫자를 지킨다 화면을 아는 사람이 짜고, 이야기가 되는지 Green이 본다.

context.md

의

팀원

에서 이름을 읽어 세 명 다 부른다. 시작할 때 소리내어 배분한다.

🔴 Red: 주도. 제일 보여주고 싶은 한 장면에서 덱을 짠다. "데모데이에서 제일 보여주고 싶은 한 장면이 뭐예요?" 🟢 Green: 장과 장이 이야기로 이어지는지 본다. "이 장 다음에 왜 저 장이에요?" 🔵 Blue: 덱에 올라간 숫자마다 출처·기준시점이 붙었는지 지킨다. 여기 빠진 게 Q&A에서 그대로 터진다. "이 숫자, 물으면 답할 수 있어요?"

한 명에게 쏠리면 찌르는 사람을 이름으로 호명한다. 2인 팀이면 Red는 공동이다.

主导：Red · 审核：Green · Blue负责核查幻灯片中的数据 由熟悉演示逻辑的人主导搭建，Green负责检查内容连贯性。

从

context.md

的「团队成员」中读出所有三人的名字，开始时明确分配角色。

🔴 Red：主导。从最想展示的核心场景切入搭建文稿。“演示日最想展示的核心场景是什么？” 🟢 Green：检查幻灯片之间的逻辑连贯性。“这一页之后为什么是那一页？” 🔵 Blue：核查幻灯片中每个数据是否标注来源和基准时间。遗漏的内容会在问答环节暴露。“这个数据，被问到的话能回答上来吗？”

如果讨论集中在某一人身上，直接点名审核人介入。若为2人团队，Red由两人共同担任。

시작 전

开始前准备

덱은 시연을 감싸는 포장이지 시연을 대체하지 않는다. 데모 구간은 슬라이드 한 장으로 비워둬라. 시연 시나리오는 다음 단계(
$pitch-prep
)에서 짠다. 시연에서 보여줄 걸 슬라이드로 미리 다 설명하지 마라.
⚠ 그 빈 장에
시연 화면 전환
같은 작업 라벨을 그대로 띄우지 않는다. 화면에 뜨는 건 관객이 읽는 글자다. 서비스 이름 한 줄이면 충분하고, 말은 "이제 직접 보여드리겠습니다" 로 넘어간다.

context.md

의

우리 팀 주제카드

데이터 검증 요약

MVP 정의

발표 > 제한시간

산출물

(prototype.html)을 읽는다.

```
../design-setup/references/레이아웃-패턴.md
```
의 §4 피칭덱 크래프트와 §5 폴리시 체크리스트를 읽고 시작한다. 슬라이드 골격·글자 위계·자가점검 8항목이 거기 있다. 여기서 다시 만들지 않는다.
```
references/덱-골격.md
```
: HTML·CSS·JS 복붙용 골격. 이동·진행바·편집을 새로 짜지 않는다.

文稿是演示的包装，而非演示的替代。演示环节需留一页空白幻灯片。演示脚本将在后续步骤（
$pitch-prep
）中制定，不要提前在幻灯片中把演示内容全部说明。
⚠ 空白页上不要直接显示「切换至演示画面」这类操作标签。屏幕上的内容是给观众看的文字，只需保留服务名称一行即可，口头用“接下来为大家实际演示”过渡。

阅读
```
context.md
```
中的「团队主题卡片」「数据验证总结」「MVP定义」「演示 > 限时」「产出物」（prototype.html）。
阅读
```
../design-setup/references/레이아웃-패턴.md
```
的**§4 推介文稿制作和§5 规范检查表**后再开始。幻灯片框架、文字层级、8项自检内容都在其中，无需重新制作。
```
references/덱-골격.md
```
：用于复制粘贴的HTML·CSS·JS框架。无需重新编写页面导航、进度条、编辑逻辑。

★ 디자인부터 정한다: 반드시 묻는다

★ 先确定设计风格：必须询问团队

design.md

(프로토타입에 쓴 디자인)를 보여주고 팀에게 고르게 한다.

"프로토타입은 이 색·이 느낌으로 만들었어요. 발표 슬라이드도 똑같이 갈까요, 아니면 발표용으로 좀 손볼까요?"

선택	언제 좋나	어떻게
그대로 간다 (기본)	대부분. 화면과 슬라이드가 한 몸으로 보인다. 가장 안전하다	`design.md` 토큰을 그대로
발표용으로 손본다	프로토타입 색이 화면에선 예쁜데 빔프로젝터에선 흐릴 때	아래 조정

展示

design.md

（原型使用的设计规范），并让团队共同选择。

“原型是用这个配色、这种风格制作的。演示幻灯片是完全沿用该风格，还是针对演示场景稍作调整？”

选项	适用场景	操作方式
完全沿用（默认）	大多数情况。屏幕与幻灯片风格统一，最稳妥	直接使用 `design.md` 中的设计变量
针对演示调整	原型配色在电脑屏幕上美观，但投影后颜色模糊时	按照以下规则调整

발표용으로 손볼 때 (자주 필요하다)

针对演示场景调整时（高频需求）

빔프로젝터는 색이 날아가고 대비가 약해진다. 노트북에서 예쁜 파스텔이 스크린에선 안 보인다.

배경을 더 어둡거나 더 밝게: 중간 회색은 최악이다
글자를 키운다. 본문 16px → 슬라이드는 20~24px 이상. 뒷자리에서도 읽혀야 한다
대비를 올린다. 연한 색 글자 금지
메인 색은 유지한다 ← 이건 바꾸지 않는다. 바꾸면 프로토타입과 남남이 된다

팀이 "몰라요"라고 하면 그대로 간다. 시간이 아깝다. 고른 결과는
design.md
에 한 줄 덧붙인다.

投影仪会导致颜色失真、对比度降低。电脑上好看的淡色在投影屏幕上可能看不清。

背景调深或调浅：中等灰色效果最差
放大文字。正文从16px → 幻灯片需20~24px以上，确保后排观众能看清
提高对比度。禁止使用浅色文字
保留主色调 ← 此项不可修改，否则会与原型风格脱节

如果团队表示“不确定”，则选择完全沿用。节省时间，将选择结果在
design.md
中添加一行说明。

★ 구성도 팀이 짠다: 반드시 묻는다

★ 文稿结构由团队共同制定：必须询问团队

디자인만 묻고 내용은 AI가 채우면, 팀은 자기 발표를 남의 것처럼 읽게 된다. 슬라이드를 뽑기 전에 팀에게서 받는다. 순서를 먼저 정하고, 그다음에 각 장을 채운다. 한 번에 한 질문.

순서를 거꾸로 하지 마라. 내용부터 물으면 재료만 잔뜩 쌓이고 어디에 놓을지 몰라 결국 AI가 배치하게 된다. 뼈대가 먼저다.

시간을 꺼내놓고 시작한다.

context.md

의

발표 > 제한시간

을 읽어 그대로 말한다:

"우리 발표 6분이에요. 6분이면 생각보다 짧아요."

只确定设计风格，让AI填充内容的话，团队会像读别人的演示稿一样生硬。在制作幻灯片前，先从团队获取内容，先确定顺序，再填充每页内容，一次只问一个问题。

不要颠倒顺序。先问内容会导致素材堆积却不知如何排布，最终还是由AI决定。框架优先。

先明确时间限制，读出

context.md

中的「演示 > 限时」：

“我们的演示时长是6分钟，6分钟比想象中要短。”

1단계: 어떻게 구성할지 정한다

第一步：确定结构方式

여기서 정하는 건 방식뿐이다. 내용도, 장 수도 아직 묻지 않는다. 아래 셋을 보여주고 팀이 고르게 한다. AI가 하나로 몰지 않는다.

방법	언제	어떻게
A. 기본형 (권장 출발점)	대부분. 처음 발표하거나 시간이 없을 때	아래 6비트 그대로 쓰고, 내용만 우리 걸로 채운다
B. 기본형 + 얹기	우리 팀만의 강점이 6비트에 안 담길 때	6비트를 두고 선택 요소(뒤에 목록)를 골라 끼운다
C. 처음부터	이야기가 이미 뚜렷하거나 6비트가 안 맞을 때	뒤의 역산 4문항으로 우리 뼈대를 직접 짠다

"세 가지 길이 있어요. 검증된 기본 뼈대로 갈까요, 거기에 우리 것만 얹을까요, 아니면 아예 처음부터 짜볼까요?"

C를 고른다고 말리지 않는다. 다만 다 짜고 나서 뒤의 점검 4개는 같이 돌린다. 어느 길로 가든 장 수는 6이 아니어도 된다. 합쳐도, 쪼개도, 빼도 된다.

此处仅确定结构逻辑，暂不涉及内容和页数。展示以下三种方式，让团队选择，不要强制引导选择某一种。

方式	适用场景	操作方式
A. 基础型（推荐起点）	大多数情况，首次演示或时间紧张时	直接使用下方6模块框架，仅替换为团队内容
B. 基础型+扩展	团队独特优势无法被6模块覆盖时	保留6模块框架，选择扩展项（见后续列表）插入
C. 自定义框架	已有清晰叙事逻辑或6模块不适用时	通过后续逆向推导4个问题搭建专属框架

“有三种方案可选。是用经过验证的基础框架，还是在基础框架上添加团队特色内容，或是完全从零开始搭建？”

不要阻止选择C方案，但完成框架后必须共同进行4项检查。无论选择哪种方案，页数不一定是6页，可以合并、拆分或删减。

A. 기본형: YC 데모데이 6비트

A. 基础型：YC演示日6模块

마지막 날은 발표회가 아니라 데모데이다. 뼈대도 거기에 맞춘다. Y Combinator 데모데이 덱이 쓰는 여섯 비트다. 세계에서 제일 많이 검증된 순서이고, 마침 팀이 3일 동안 실제로 겪은 순서와 같다. 없는 이야기를 지어내는 게 아니라 이미 한 일을 순서대로 꺼내는 것이라, 팀이 자기 말로 할 수 있고 질문이 들어와도 안 무너진다.

비트	이 장이 하는 일	팀에게 던질 질문
① One-liner<br>한 문장	"저희는 ○○를 위한 △△입니다." 첫 15초 안에 뭘 만들었는지 말한다. 목차·인사·자기소개로 열지 않는다(넣고 싶으면 B의 선택 요소를 본다). YC가 가장 많이 지적하는 게 이거다. 1분이 지나도 뭐 하는 팀인지 모르겠는 발표	"이 발표를 한 문장으로 줄이면요?"
② Problem<br>문제	우리 페르소나가 언제·어디서 막히는 장면 하나. "통영 도착한 반려인이 저녁 먹을 데를 40분 검색하다 결국 편의점으로 간다" 이름·시간·장소가 있어야 남는다. "관광객이 불편하다"는 아무 팀이나 쓸 수 있는 문장이라 아무것도 아니다	"그 사람이 포기하는 순간이 정확히 언제예요?"
③ Insight<br>알아낸 것 ★	이 덱의 심장. "다들 이럴 거라 생각하는데, 데이터를 보니 아니었습니다." 우리 가설 → 받은 수치 → 거기서 뒤집힌 것. 비교 대상을 같이 두고(숫자 하나만으론 크고 작은지 모른다), 차트 1개, 기준시점 각주. 왜 이 지역인지도 여기서 답한다	"데이터 보기 전에 뭐라고 예상했었죠?"
④ Product<br>만든 것	그 인사이트에서 곧바로 따라 나오는 물건. 기능 목록이 아니라 선택과 버린 것. 사람이 정한 것과 AI에 맡긴 판단이 어디서 갈리는지 한 줄, 3일 내내 한 게 그거다	"③을 알았으니 이게 나오는 거예요? 뭘 버렸어요?"
⑤ Demo<br>돌아가는 화면	말 대신 실제로 눌러서 되는 것. 슬라이드는 거의 비우고 `prototype.html` 로 넘어간다. ④에서 말한 AI의 판단이 여기서 눈에 보여야 한다. 시나리오는 `$pitch-prep` 에서 초 단위로	"1분 안에 뭘 보여주면 믿을까요?"
⑥ The Ask<br>필요한 것	YC 덱은 "저희에게 필요한 건 이겁니다" 로 끝난다. "3일로 여기까지 왔고, ○○시 관광재단과 한 달만 붙여주시면 실제 이용 데이터를 받아보고 싶습니다." 가장 많이 빠뜨리는 장이다. 데모에서 끝내면 심사위원 머릿속에 "잘 만든 습작"으로 남는다. 마지막 문장은 팀이 직접 쓴다	"이거 진짜 굴리려면 뭐가 있어야 해요?"

③ Insight가 이 캠프의 무기다. YC가 말하는 인사이트는 "우리만 아는 것" 이다. 다들 아는 사실을 다시 말하면 인사이트가 아니다. 그리고 이 부트캠프는 그걸 만들 수 있는 유일한 자리다. 팀이 4단계에서 숫자를 보기 전에 예상을 적어뒀고, 그게

context.md

의

수집 전 예상

어긋난 지점

에 남아 있다. 빗나갔다면 그 얘기를 시킨다:

"저희도 처음엔 잘 곳이 없어서 안 자고 가는 줄 알았어요. 그런데 숙박 비중은 오히려 높더라고요. 문제는 다른 데 있었습니다."

아무 팀도 못 베끼는 문장이고, 데이터를 진짜로 봤다는 걸 한 번에 증명한다. 3일 중 하루를 데이터에 썼는데 덱에서 한 장으로 스쳐가는 팀이 매년 나온다. ③은 줄이지 않는다.

最终环节是演示日而非报告会，框架也需适配。这是Y Combinator演示日文稿常用的6个模块，是全球验证最多的顺序，恰好与团队3天内实际经历的流程一致。无需编造内容，只需按顺序整理已完成的工作，团队能自然用自己的语言表达，面对提问也不会慌乱。

模块	页面作用	向团队提出的问题
① One-liner<br>一句话定位	“我们是为○○打造的△△。” 在最初15秒内说明核心产品。不要用目录、问候、自我介绍开场（如需添加，请参考B方案的扩展项）。这是YC最常指出的问题：演示1分钟后观众仍不知道团队的业务方向	“用一句话概括本次演示的核心内容？”
② Problem<br>问题场景	描述用户何时、何地遇到的具体困境。例如“刚抵达统营的游客花了40分钟找晚餐地点，最终只能去便利店”。必须包含名字、时间、地点才能让观众记住。“游客不方便”这种通用描述毫无意义	“用户放弃的瞬间具体是什么时候？”
③ Insight<br>核心洞察 ★	文稿的核心。“大家都以为是这样，但数据显示并非如此。” 包含团队假设→验证数据→颠覆认知的结论。需搭配对比对象（单一数据无法体现大小）、1张图表、基准时间注释。在此页回答为什么选择该地区	“看数据前，你们的预期是什么？”
④ Product<br>产品方案	从洞察直接衍生出的产品。不要罗列功能，而是说明选择与舍弃的内容。用一句话说明人工决策与AI判断的分界点，这正是团队3天来的核心工作	“基于③的洞察，得出这个方案的原因是什么？你们舍弃了什么？”
⑤ Demo<br>产品演示	用实际可操作的演示替代口头说明。幻灯片几乎留白，切换至 `prototype.html` 。④中提到的AI判断必须在此环节可视化呈现。演示脚本将在 `$pitch-prep` 中精确到秒	“1分钟内展示什么能让观众信服？”
⑥ The Ask<br>需求诉求	YC文稿以“我们需要XX”结尾。例如“3天内我们完成了这些，如果能与○○市旅游局合作1个月，我们希望获取实际使用数据”。这是最容易遗漏的页面。如果在演示环节结束，评审会认为这只是“制作精良的练习作品”。最后一句话由团队亲自撰写	“要让项目落地，我们需要什么支持？”

③核心洞察是本次训练营的核心武器。YC所说的洞察是**“只有我们知道的信息”。重复所有人都知道的事实不能称为洞察。而本次训练营正是打造这种洞察的唯一机会。团队在第4步中看数据前的预期**，已记录在

context.md

的「收集前预期」「偏差点」中。如果预期与实际不符，引导团队讲述：

“我们最初也以为游客是因为找不到住处才熬夜，但数据显示住宿占比反而很高。问题其实出在其他地方。”

这是任何团队都无法复制的表述，能一次性证明团队确实分析了数据。每年都有团队花1天时间处理数据，却在文稿中一笔带过。③模块不能简化。

B. 기본형에 얹기: 선택 요소 메뉴

B. 基础型+扩展：扩展项菜单

얹는 건 추가가 아니라 교환이다. 6비트 기본형이 이미 6분 중 5분 40초를 쓴다(여유 20초). 남는 20초에 새 장을 넣을 수 없다. 하나를 얹으면 6비트 중 하나에서 그만큼 뺀다. 고르게 하기 전에 이 말을 먼저 하고, "넣으면 어디서 뺄까요?" 를 같은 질문 안에서 묻는다.

"'왜 우리 팀인가' 20초를 넣으면, Problem을 60초에서 40초로 줄이거나 Demo를 15초 깎아야 해요. 어느 쪽이 나을까요?"

이 교환을 안 시키면 리허설에서 시간이 터지고, 그때는 대본을 통째로 다시 짜야 한다.

얹을 것	언제 값을 하나	값	어디에
Why us<br>왜 우리 팀인가	전공이 갈리는 팀은 거의 항상. `우리 팀 주제카드` 의 `왜 우리인가` 가 이미 있다. "저희 중 둘이 의료 전공이라 이 동선이 보였습니다" 심사위원이 기억하는 건 대개 이거다	20초	⑥ 앞 또는 ① 뒤
Why now<br>왜 지금인가	데이터에 최근 변화가 잡혔을 때. "펫 동반 시설이 2년 새 3배 늘었는데 정보는 그대로입니다"	20초	② 뒤
기존 대안<br>지금은 어떻게 하나	심사위원이 "그거 네이버로 되지 않나요?" 할 것 같을 때. `idea-sketch` ③(지금의 대안)에 이미 답이 있다. 선제 방어	25초	② 뒤 또는 ④ 안
How it works<br>구조 한 장	서비스가 여러 데이터를 엮을 때. 입력→AI 판단→출력 흐름도 하나. 말로 설명하면 안 들리는 걸 그림이 3초에 끝낸다	30초	④ 안
규모<br>얼마나 큰 문제인가	지역 방문객 수처럼 받아둔 숫자가 있을 때. 없으면 넣지 마라, 추정치는 바로 질문을 부른다	15초	② 안
로드맵<br>3일 → 3개월	⑥ The Ask를 구체적으로 만들 때. 단계 3개까지만	20초	⑥ 안
팀 소개<br>이름·전공	얼굴을 알리고 싶을 때. 다만 앞에 두지 않는다. 앞에 두면 "뭐 하는 팀"이 15초 늦어진다	15초	⑥ 뒤
목차	"흐름을 먼저 알려주고 싶다" 할 때. 6분에는 대개 손해다. 안 듣고, 15초를 먹고, 다음 장에서 또 말하게 된다. 팀이 원하면 넣되 이 손익을 말해준다	15초	① 뒤
감사 / Q&A	마지막 장. Ask를 말한 뒤에 띄운다. 이 장에 내용을 담지 않는다	0초	맨 뒤

"이 중에 우리 발표를 더 세게 만들 것 같은 게 있어요? 하나씩만 골라볼까요. 넣으면 어디서 빼야 하는지도 같이 봐요."

두 개까지가 현실적이다. 셋을 얹으면 6비트에서 60초 넘게 빼야 하는데, 그러면 Insight나 Demo가 반토막 난다. 제일 센 두 장을 깎아 곁가지를 늘리는 셈이다. "셋 다 좋은데 6분이에요. 이 중 하나만 남긴다면 뭘까요?"

扩展是替换而非添加。6模块基础型已占用6分钟中的5分40秒（剩余20秒），无法在剩余时间内添加新页面。添加一个扩展项，就要从6模块中删减对应时长的内容。选择前先说明这一点，并在同一问题中询问“添加的话，要从哪个模块删减时长？”

“如果添加‘为什么是我们团队’的20秒内容，就要把Problem模块从60秒缩短到40秒，或者删减Demo模块15秒。哪种方案更好？”

如果不明确这种取舍，彩排时会超时，届时需要完全重写脚本。

扩展项	适用场景	时长	插入位置
Why us<br>为什么是我们团队	专业背景差异化的团队几乎必选。「团队主题卡片」中的「为什么是我们」已有相关内容。例如“我们中有两人是医疗专业出身，因此能发现这个用户路径”，评审通常会记住这一点	20秒	⑥之前或①之后
Why now<br>为什么是现在	数据中体现近期变化时。例如“允许携带宠物的设施2年内增长了3倍，但相关信息仍未更新”	20秒	②之后
现有替代方案<br>当前用户如何解决问题	预计评审会问“这用Naver不能实现吗？”时。 `idea-sketch` ③（当前替代方案）已有答案，属于提前防御	25秒	②之后或④之内
How it works<br>架构说明页	服务整合多种数据时。制作一个输入→AI判断→输出的流程图。口头无法快速说明的内容，图表能在3秒内讲清楚	30秒	④之内
规模<br>问题的严重性	有现成数据（如地区游客数量）时。没有数据则不要添加，估算值会直接引发质疑	15秒	②之内
Roadmap<br>3天→3个月规划	让⑥需求诉求更具体时。最多列出3个阶段	20秒	⑥之内
团队介绍<br>姓名·专业	希望让评审记住团队成员时。不要放在开头，否则“团队业务方向”的说明会延迟15秒	15秒	⑥之后
目录	希望提前告知演示流程时。6分钟演示中通常得不偿失，观众不会看，浪费15秒，后续页面还要重复说明。如果团队坚持，需说明利弊	15秒	①之后
致谢 / Q&A	最后一页。在需求诉求之后展示，页面不添加其他内容	0秒	最后一页

“这里面有没有能让我们的演示更有说服力的选项？我们一次选一个，同时确定要从哪个模块删减时长。”

最多选择2个扩展项。选择3个的话，需要从6模块中删减超过60秒的内容，会导致核心洞察或演示环节被拆分。不要为了添加分支内容而削弱核心模块。“三个都很好，但我们只有6分钟。如果只能保留一个，选哪个？”

C. 처음부터 짜기: 역산 4문항

C. 自定义框架：逆向推导4个问题

6비트가 안 맞는 팀도 있다. 어떤 모양으로 갈지부터 고르고, 그다음 순서를 뽑는다. 한 번에 한 질문.

1. 어떤 식으로 풀고 싶은지 고르게 한다.

"6분을 어떤 모양으로 쓰고 싶어요? 흔한 게 이 넷인데, 우리한테 맞는 게 있어요?"

모양	이렇게 흘러간다	어울리는 팀
데모 선공	화면부터 보여주고 → 왜 이게 필요한지 되짚는다	데모가 3초 만에 먹히는 팀
반전	다들 아는 통념을 깔고 → 데이터로 뒤집는다	`어긋난 지점` 이 뚜렷한 팀
한 사람 따라가기	페르소나 하루를 처음부터 끝까지 따라간다	페르소나가 선명한 팀
비교	지금 이렇게 한다 ↔ 우리 걸로는 이렇게 된다	기존 대안이 명확한 팀

고른 모양이 곧 뼈대의 성격이다. 여기서 안 고르면 2번으로 넘어가도 순서가 안 나온다.

2. 그 모양대로 순서를 뽑는다. 결론에서 거꾸로 짚는 게 제일 빠르다.

"그 흐름의 마지막에 심사위원이 뭘 알고 있어야 해요?" → 도착점
"그걸 알려면 그 전에 뭐가 먼저 나와야 해요?" → 안 나올 때까지 반복한다. 답이 3~5개 쌓이면 그게 뒤에서부터 짜인 순서다.
"그중에 우리가 증거를 가진 건 뭐예요?" → 증거 있는 항목은 한 장씩, 없는 항목은 한 줄로 줄인다.
"이 순서를 소리 내어 이어서 말해볼래요?" → 말로 안 이어지면 슬라이드로도 안 이어진다.

받아적은 순서를 그대로 보여주고 "이게 우리 뼈대 맞죠?" 확인한다.

짜고 나면 반드시 이 넷을 같이 점검한다. 어느 길(A·B·C)로 갔든 동일하다:

첫 15초에 뭐 하는 팀인지 나오나?: 안 나오면 1장을 앞에 붙인다
우리만 아는 것이 한 군데 있나?: 없으면 4단계
```
어긋난 지점
```
을 다시 본다
돌아가는 화면을 보여주는 자리가 있나?: 없으면 이건 발표지 데모데이 피칭이 아니다
뭐가 필요한지 말하고 닫나?: "감사합니다" 로 끝나면 마지막 30초가 빈다

部分团队不适用6模块框架。先确定叙事风格，再推导顺序，一次只问一个问题。

1. 选择叙事风格

“我们想怎么利用这6分钟？常见的有四种风格，哪种适合我们？”

风格	叙事流程	适配团队
演示前置	先展示产品演示→再回溯需求背景	演示能快速打动观众的团队
反转叙事	先提出普遍认知→再用数据颠覆	「偏差点」明确的团队
用户视角	全程跟随用户的一天流程	用户画像清晰的团队
对比叙事	当前解决方案 ↔ 我们的解决方案	现有替代方案明确的团队

选定的风格就是框架的核心逻辑，未选定则无法进入下一步推导顺序。

2. 按风格推导顺序。从结论逆向推导最快。

“演示结束后，希望评审记住什么？” → 目标终点
“要让评审记住这一点，需要先说明什么？” → 重复此问题直到无法拆分。得到3~5个要点后，从后往前排列就是顺序。
“其中我们有证据支持的内容是什么？” → 有证据的内容单独成页，无证据的内容简化为一行文字。
“把这个顺序大声读一遍，是否连贯？” → 口头不连贯的话，幻灯片逻辑也不连贯。

展示记录的顺序并确认：“这就是我们的框架，对吗？”

完成框架后必须共同进行以下4项检查，无论选择A/B/C哪种方案都适用：

最初15秒内是否说明团队业务方向？：未说明则在开头添加一页
是否包含只有我们知道的洞察？：没有则重新查看第4步的「偏差点」
是否预留产品演示的位置？：没有则不符合演示日的要求
是否明确提出需求诉求后结束？：如果以“谢谢大家”结尾，最后30秒就浪费了

2단계: 그 뼈대에 내용을 채운다

第二步：为框架填充内容

뼈대가 정해진 다음에 묻는다. 한 장씩, 한 번에 하나.

"이 발표에서 심사위원이 딱 하나만 기억한다면 뭐였으면 좋겠어요?" → 핵심 메시지 (뼈대의 어느 장에 놓을지도 같이 정한다. 대개 ① 아니면 ③)
"제일 세게 밀 장면은 어디예요?" → 클라이맥스
- "거기에 6분 중 몇 분을 쓰고 싶어요?" → 여기부터 시간을 떼어둔다.
장마다 "○○장, 여기서 뭘 말하고 싶어요? 한 문장으로요."
- "그거 뒷받침할 게
  context.md
  에 이런 게 있는데, 이거 쓸까요, 다른 거 있어요?"
- 재료를 꺼내 보여주는 것까지가 AI 몫이다. 뭘 고르고 뭐라고 말할지는 팀 몫이다.
다 채우면 같이 센다. "이러면 ○장이고 장당 ○○초쯤이에요. 넉넉해요, 빠듯해요?"
- 빠듯하다고 하면 합칠 장을 팀이 고르게 한다. AI가 잘라내지 않는다. "둘 중에 어느 걸 한 장으로 합칠까요?"
- 10장을 넘어가면 장당 30초대다. 그 숫자를 보여주고 팀이 판단하게 한다.

框架确定后再询问内容，一页一页来，一次一个问题。

“如果评审只能记住演示中的一个点，希望是什么？” → 核心信息（同时确定放在框架的哪一页，通常是①或③）
“最想强调的场景是哪个？” → 高潮环节
- “希望在这个环节分配6分钟中的多长时间？” → 先预留该时长
每页单独询问：“○○页，这里想表达什么？用一句话说明。”
- “
```
context.md
```
  中有这些内容可以支撑，用这个还是其他内容？”
- AI的职责仅为提供可选素材，选择内容和表述方式由团队决定。
全部填充后共同核对时长：“这样共有○页，每页约○○秒。时间充裕还是紧张？”
- 如果时间紧张，让团队选择合并的页面，AI不要擅自删减。“这两页中，哪一页可以合并？”
- 超过10页的话，每页平均30秒左右。展示这个数据，让团队自行判断。

장마다 주장을 편다: 이게 설명과 피칭을 가른다 ★

每页明确核心主张：区分说明与推介的关键 ★

대부분의 팀이 만드는 건 과제 보고서다. "주제는 이거고요, 데이터는 이랬고요, 이런 걸 만들었습니다." 전부 사실이지만 아무도 기억하지 않는다. 설명은 정보를 전달하고, 피칭은 판단을 요구한다.

한 장의 골격은 이렇다:

[섹션 라벨]  ← 지금 어디쯤인지
큰 제목        ← 명사형. "펫 동반 필터" (○) / "저희는 필터를 만들었습니다" (×)
2~3문장       ← 여기가 주장이다. 긴장 → 우리 결정 → 그렇게 한 이유
본문/차트/화면  ← 위 주장을 뒷받침하는 것 하나만

가운데 2~3문장이 핵심이다. "무엇을 했다"가 아니라 "왜 그게 맞다" 를 쓴다.

✗ "펫 동반 가능한 장소를 필터링하는 기능을 만들었습니다." ○ "동반 가능 여부는 블로그 후기에 흩어져 있어 확인에 30분이 걸립니다. 저희는 검색이 아니라 필터로 풀었습니다. 찾는 수고를 줄이는 게 아니라 아예 없애야 여행 계획이 바뀌기 때문입니다."

한 급 더 올리는 방법: 기각한 대안을 쓴다. "지도에 다 찍어주는 것도 봤지만, 그러면 다시 고르는 일이 사용자에게 남습니다." 검토한 흔적이 보이는 순간 심사위원의 질문이 절반으로 준다.

大多数团队制作的是任务报告：“主题是这个，数据是这样，我们做了这个。” 虽然都是事实，但没人会记住。说明是传递信息，推介是引导决策。

单页框架如下：

[章节标签]  ← 当前所处环节
大标题        ← 名词形式。“携宠筛选”（√） / “我们制作了筛选功能”（×）
2~3句话       ← 核心主张。冲突→我们的决策→决策原因
正文/图表/截图  ← 仅保留一项支撑核心主张的内容

中间2~3句话是核心。不要写“做了什么”，要写“为什么这样做是正确的”。

✗ “我们制作了筛选携宠场所的功能。” ○ “携宠场所信息分散在博客评论中，用户需要30分钟才能确认。我们没有做搜索，而是选择了筛选功能。因为只有彻底省去查找步骤，才能改变用户的旅行规划。”

进一步提升的方法：提及被否决的替代方案。“我们也考虑过在地图上标注所有场所，但这样用户还是需要重新选择。” 当展示出团队的思考过程时，评审的提问会减少一半。

YC식 문장 규칙 세 가지

YC式表述规则三条

형용사 말고 숫자. "많은 관광객이 방문하지만" → "연 1,817만 명이 오는데". 형용사는 아무 근거가 없다.
④는 ③에서 따라 나와야 한다. 인사이트와 상관없는 제품이 나오면 심사위원은 "그럼 그 데이터는 왜 봤나" 를 생각한다. ④를 쓴 뒤 되짚어 묻는다: "③이 없어도 이 제품 나왔을까요?" → 나왔다면 둘 중 하나가 틀렸다.
⑥은 구체적으로. "열심히 하겠습니다 · 발전시키고 싶습니다" 는 Ask가 아니다. 누구에게 · 무엇을 · 얼마 동안 이 들어가야 Ask다.

⚠ 점수 얘기를 팀 앞에서 하지 않는다. 이 뼈대는 100점 평가표 (
../bootcamp-start/references/guides/bootcamp-context.md §1
: 문제정의25·기획력25·실현발전30·기술활용20) 위에 세운 것이고, Problem·Insight가 문제정의를, Insight·Product가 기술 활용을, Demo·The Ask가 최고 배점인 실현·발전을 받는다. 그 대응은 내가 알고 있으면 되는 것이지 팀에게 브리핑할 게 아니다. "이 장은 25점짜리예요" 라고 말하는 순간 팀은 채점표를 채우러 간다. 점수를 노린 티가 나는 발표가 실제로 점수를 못 받는다. 대신 빠뜨렸을 때만 짚는다: "⑥이 없는데, 이거 3일 뒤에 어떻게 되는 건지 궁금하지 않을까요?"

用数字替代形容词。“很多游客来访，但” → “年接待1817万名游客，但”。形容词没有任何依据。
④必须从③推导而来。如果洞察与产品无关，评审会想“那看数据的意义是什么”。写完④后反问：“如果没有③，这个产品还会诞生吗？” → 如果会，说明其中一项存在问题。
⑥必须具体。“我们会努力 · 我们想发展”不是有效的诉求。诉求必须包含对象·内容·时长。

⚠ 不要在团队面前提及评分标准。本框架基于100分评分表（
../bootcamp-start/references/guides/bootcamp-context.md §1
：问题定义25分·规划能力25分·落地发展30分·技术应用20分）搭建，Problem·Insight对应问题定义，Insight·Product对应技术应用，Demo·The Ask对应分值最高的落地发展。 这些对应关系只需自己知晓，无需告知团队。如果说“这页占25分”，团队会只关注填充评分表。刻意迎合评分的演示反而无法获得高分。仅在遗漏关键内容时提醒：“缺少⑥的话，评审会好奇3天后项目会如何发展？”

발표 화면: 골격은 이미 있다 ★

演示页面：框架已就绪 ★

이동·진행바·편집 로직을 새로 짜지 마라.

references/덱-골격.md

의 HTML·CSS·JS를 그대로 복붙하고 색은

design.md

토큰으로, 내용은 팀이 정한 슬라이드로 채운다. 여기에 시간 쓰면 정작 내용이 빈다.

골격이 주는 것:

화면에 상시로 뜨는 컨트롤 UI가 없다. 하단 4px 진행바 하나뿐. 화살표 버튼도,
```
← → 이동
```
같은 키보드 안내문도 두지 않는다. 발표 중에 심사위원 눈이 거기로 간다. 조작법은 발표자만 알면 된다. 페이지 번호는 슬라이드 안 우상단(
```
.pageno
```
)에 있다.
이동: 키보드(←→↑↓ Space PgUp/PgDn Home/End) · 마우스 휠 · 터치 스와이프 ·
```
#3
```
해시로 바로 열기.
1920×1080 고정 캔버스를 뷰포트에 맞춰
scale()
한다. 리플로우가 없으니 노트북에서 짠 게 빔프로젝터에서 그대로 나온다. 반응형으로 짜면 화면 비율마다 다르게 깨진다.
인쇄하면 슬라이드 1장 = 1페이지.
```
Cmd/Ctrl+P
```
→ PDF. 노트북이 죽었을 때의 백업이 공짜로 생긴다. 리허설 때 한 번 뽑아두라고 팀에 권한다.
발표장 네트워크 없이 뜨는 단일 파일. 데이터 슬라이드는 인라인 SVG 또는 CSS 막대로 그린다. 차트 라이브러리를 불러오지 않는다. wifi가 끊기면 하필 데이터 근거 슬라이드만 빈다.

不要重新编写导航、进度条、编辑逻辑。直接复制

references/덱-골격.md

中的HTML·CSS·JS代码，配色使用

design.md

的变量，内容填充团队确定的幻灯片。在此处浪费时间会导致核心内容缺失。

框架提供的功能：

屏幕上无常驻控制UI。仅底部有4px进度条，无箭头按钮、“←→切换”等键盘提示。演示时评审的注意力会被这些元素分散。操作方法只需演示者知晓。页码显示在幻灯片右上角（
```
.pageno
```
）。
切换方式：键盘（←→↑↓ 空格 PgUp/PgDn Home/End）· 鼠标滚轮 · 触摸滑动 · 通过
```
#3
```
哈希直接跳转至第3页。
将1920×1080固定画布通过
scale()
适配视口。无重排问题，电脑上制作的效果会完全还原到投影仪上。响应式设计会导致不同屏幕比例下页面错乱。
打印时1张幻灯片=1页PDF。按
```
Cmd/Ctrl+P
```
即可生成PDF，作为电脑故障时的备份。建议团队在彩排时打印一份。
无需网络即可打开的单文件。数据页使用内嵌SVG或CSS柱状图绘制。不要引入图表库，断网时恰好会缺失数据支撑的页面。

나중에 고칠 수 있게 (골격이 지키는 계약)

便于后续修改（框架的保障）

발표 직전에 FT나 팀이 "이 문장만 바꿔주세요" 한다. 그때 5분 안에 고쳐져야 한다.

슬라이드 1장 =
<section class="slide">
1개.
슬라이드 텍스트는 마크업 안에 직접 쓴다. JS 배열·객체에 넣고 렌더링하지 않는다. 그러면 화면에서 찾은 문장을 소스에서 못 찾고, 편집 모드도 무의미해진다.
색·글자 크기는 파일 상단
```
:root
```
한 블록. 첫 줄에
```

```
주석.
✏️ 편집 모드: 좌상단 구석에 마우스를 올리거나
```
E
```
키. 켜지면 텍스트가
```
contenteditable
```
이 되고 라벨이
```
✏️ 편집 중 · 새로고침하면 사라짐
```
으로 바뀐다. 저장 기능이 아니다. 리허설 중 즉석 다듬기용이고, 영구 반영은 소스를 직접 고친다. 팀에게 이걸 꼭 말해준다.

演示前可能会有团队成员要求“只修改这句话”，此时必须在5分钟内完成修改。

1张幻灯片=1个
<section class="slide">
标签。
幻灯片文字直接写在标记内。不要放在JS数组或对象中渲染，否则在屏幕上找到的文字无法在源码中定位，编辑模式也失去意义。
配色、字体大小集中在文件顶部的
```
:root
```
代码块，第一行添加注释
```

```
。
✏️ 编辑模式：鼠标悬停在左上角或按
```
E
```
键开启。开启后文字变为
```
contenteditable
```
状态，标签变为
```
✏️ 编辑中 · 刷新后内容丢失
```
。这不是保存功能，仅用于彩排时临时修改，永久修改需直接编辑源码。必须告知团队这一点。

스피커노트 (발표 대본)

演讲者备注（演示脚本）

각 슬라이드에 말할 대사 2~4줄을 함께 만든다. 별도 파일

speaker-notes.md

또는 덱 하단 토글로.

AI가 초안을 쓰고 끝내지 않는다. 장마다 "이 장에서 뭐라고 말할 거예요?" 를 먼저 묻고, 팀 말을 받아적은 뒤 다듬는다. 팀이 안 나오면 초안을 보여주되 소리 내어 읽어보게 하고 고치게 한다. "읽어보니 우리 말투 같아요?"
슬라이드당 배분은
```
context.md
```
의
```
발표 > 제한시간
```
에서 계산한다.
첫 문장(훅)·마지막 문장(임팩트)은 반드시 팀이 직접 쓴다. AI가 채우지 않는다.

为每张幻灯片制作2~4行台词，可放在单独文件

speaker-notes.md

或文稿底部的折叠面板中。

AI仅负责撰写初稿，不能直接定稿。每页先问“这页想讲什么？”，记录团队的表述后再润色。如果团队无法给出表述，展示初稿并让团队大声朗读，再进行修改。“读起来像我们的语气吗？”
每页时长分配根据
```
context.md
```
中的「演示 > 限时」计算。
第一句话（开场钩子）和最后一句话（收尾冲击）必须由团队亲自撰写，AI不能替代。

리허설 가이드

彩排指南

시간 배분:
```
context.md
```
의
```
발표 > 제한시간
```
에서 계산한다. 비어 있으면 FT에게 확인하고 채운다. 세부 배분은
```
$pitch-prep
```
①의 비율표를 쓴다. 여기서 다른 기준을 만들지 않는다.
데모 리허설: prototype.html을 실제로 눌러보며 말 맞추기. 안 되는 경우 대비(스크린 캡처 백업).
예상 질문(Q&A) 3개를 팀이 뽑아 답 준비: "데이터 근거는?", "왜 이 지역?", "실제로 되나요?"

时间分配：根据
```
context.md
```
中的「演示 > 限时」计算，若为空则向FT确认后补充。具体分配使用
```
$pitch-prep
```
①的比例表。此处不制定其他标准。
演示彩排：实际操作prototype.html，配合台词练习。准备备用方案（截图备份）以防演示失败。
让团队选出**3个预期问题（Q&A）**并准备答案：“数据依据是什么？”“为什么选择该地区？”“实际能落地吗？”

심화 (시간 있으면: 2박3일 깊이)

进阶内容（时间充足时：2晚3天深度版）

모의 발표 2회 이상: 타 팀·FT 앞에서 시간 재며 → 피드백 반영.
Q&A 정교화: 예상 질문 5개로 늘리고 답을 데이터로 뒷받침.
훅·클로징 다듬기: 첫 15초와 마지막 한 문장을 여러 버전으로 써보고 고른다.

模拟演示2次以上：在其他团队或FT面前计时演示→根据反馈调整。
Q&A精细化：将预期问题增加到5个，并用数据支撑答案。
优化开场与收尾：撰写多个版本的开场15秒和最后一句话，选择最优版本。

context.md 갱신

更新context.md

산출물

에

pitch-deck.html

speaker-notes.md

) 경로,

단계: 6b

로그에 "발표 덱 vN" 기록.

在「产出物」中添加
```
pitch-deck.html
```
（+
```
speaker-notes.md
```
）路径，「阶段：6b」。
在日志中记录“演示文稿vN”。

끝맺음

收尾

요약: 슬라이드 몇 장, 핵심 메시지 한 줄.
다음은
$pitch-prep
: 프로토타입과 이 덱을 바탕으로 피칭 전체를 준비한다: 시연 시나리오, 슬라이드별 대본, 시간 배분, 예상 질문, 그리고 통합 리허설. 덱만 좋고 발표가 무너지는 팀이 매년 나온다.
시간이 남으면:
- "이 덱, 우리가 없어도 심사위원이 혼자 넘겨보면 이해될까요?"
- "제일 약한 슬라이드가 어디예요? 거기를 고칠까요, 아예 뺄까요?"

总结：幻灯片数量、核心信息一句话。
下一步是
$pitch-prep
：基于原型和文稿准备完整推介内容：演示脚本、每页幻灯片的台词、时间分配、预期问题，以及综合彩排。每年都有团队文稿优秀但演示失败。
若有剩余时间：
- “如果我们不在场，评审自己翻文稿能理解吗？”
- “最薄弱的幻灯片是哪一页？是修改还是删除？”

톤

沟通语气

한 턴 = 맥락·이유 1문단 + 질문 1개. 질문만 툭 던지지 말고 왜 이걸 묻는지를 먼저 한 문단으로 친절하게 풀어준다. 대신 질문 개수는 늘리지 않는다. 한 번에 여러 개를 물으면 팀이 생각하지 않고 받아적기만 한다.
AI가 이미 아는 답으로 몰지 않는다. 팀 생각이 틀려 보여도 "아닐까요?" "진짜 그럴까요?" 로 흔들지 말고, 무엇을 보면 알 수 있는지를 묻는다.
슬라이드는 읽는 문서가 아니라 말하는 배경이다. 글자를 채우지 마라.
1슬라이드 1주장. 제목은 명사형, 주장은 그 아래 2~3문장, 뒷받침은 하나만.
설명체를 잡아낸다. "~를 만들었습니다 · ~기능이 있습니다 · ~를 활용했습니다" 로 끝나는 문장이 보이면 되묻는다: "그래서 그게 왜 맞는 방법이에요?" 그 답이 슬라이드에 들어갈 문장이다.

每次沟通=1段背景说明+1个问题。不要只抛问题，先亲切地解释“为什么问这个问题”。但不要增加问题数量，一次问多个问题会让团队只记录答案而不思考。
不要引导团队给出AI已知的答案。即使团队的想法看似错误，也不要用“不对吧？”“真的是这样吗？”动摇，而是询问“有什么依据能证明这一点？”
幻灯片是演讲的背景，不是阅读的文档。不要填满文字。
1张幻灯片1个核心主张。标题用名词形式，核心主张在标题下方2~3句话，仅保留一项支撑内容。
识别说明性表述。如果发现“我们制作了·我们有·我们使用了”结尾的句子，反问：“所以为什么这是正确的方法？” 这个答案就是幻灯片应有的内容。