prototype-build
Compare original and translation side by side
🇺🇸
Original
English🇨🇳
Translation
Chinese6단계 · 프로토타이핑 (prototype-build)
第6阶段 · 原型制作（prototype-build）
문장부호: 출력에(em-dash)를 쓰지 않는다. 쉼표나 마침표로 끊는다.—
标点规则：输出中禁止使用（长破折号），使用逗号或句号分隔。—
목적
目标
솔루션 MVP를 실제로 클릭되는 기준선 데모()로 만들고, 팀의 MVP에 맞는 방식으로 Codex Sites에 공개 배포해 URL까지 만든다(배포가 안 되면 으로 대체, 아래 완료 판정). 공개 URL의 핵심 데모 흐름은 심사위원과 다른 팀이 ChatGPT 로그인 없이 자기 폰으로 열 수 있어야 한다. 발표 덱은 이 스킬이 아니라 담당. 오피스아워 피드백으로 여러 번 반복한다.
prototype.html로컬 폴백 검증됨pitch-deck-build将解决方案MVP制作成可实际点击的基准线演示（），并以符合团队MVP需求的方式在Codex Sites上公开部署直至生成URL（若部署失败则替换为，详见下方完成判定）。公开URL的核心演示流程需确保评审人员及其他团队无需登录ChatGPT，即可用自己的手机打开。演示文稿由**负责，而非本技能。可通过办公时间反馈反复迭代优化**。
prototype.html本地回退验证完成pitch-deck-build이 단계의 역할
本阶段角色分工
주도: Red · 찌르는 사람: Green · Blue는 화면에 뜬 숫자를 지킨다
만드는 손과, 정의서에서 벗어나는지 보는 눈.
context.md팀원🔴 Red: 주도. 기준선을 만들고 배포까지 끌고 간다. "이 화면 열면 사용자가 제일 먼저 누르는 게 뭐예요?"
🟢 Green: MVP 정의서에서 벗어나는지 본다. "이거 정의서에 있던 거 맞아요?"
🔵 Blue: 화면에 뜬 수치·장소가 4단계 실측인지, 예시면 예시라고 붙었는지 확인한다. "이 숫자 어디서 왔어요? 기준시점은요?"
한 명에게 쏠리면 찌르는 사람을 이름으로 호명한다. 2인 팀이면 Red는 공동이다.
主导：Red · 监督者：Green · Blue负责核对屏幕显示的数值
负责实操的角色，与负责核对是否偏离规范的角色相互配合。
从的中读出所有三人的名字，开始前需大声分配角色。
context.md团队成员🔴 Red：主导。负责制作基准线并推进至部署阶段。“打开这个页面后，用户最先点击的是什么？”
🟢 Green：监督是否偏离MVP规范。“这确实是规范里提到的内容吗？”
🔵 Blue：核对屏幕显示的数值、地点是否为第4阶段的实测数据，若为示例则需确认是否标注了**“示例”**。“这个数值来自哪里？基准时间点是什么时候？”
若工作集中在一人身上，需直呼监督者的名字提醒。若为2人团队，则Red由两人共同担任。
진행 순서 (한눈에)
执行流程（一目了然）
기준선 만들기 → 배포 방식 결정(정적 보존/동적 앱) → 선택한 원본에서 구현·반복 → 공개 배포 → 로그아웃·팀 휴대폰 검증 → 안 되면 로컬 폴백 검증 → 시간 남으면 다음 계단(선택).
制作基准线 → 确定部署方式（静态保留/动态应用） → 在选定的源文件上实现并迭代 → 公开部署 → 退出登录并通过团队手机验证 → 若部署失败则执行本地回退验证 → 若有剩余时间可进行下一阶段（可选）。
시작 전
开始前准备
이미 완성된이 있고 요청이 화면 제작·수정이 아니라 Sites 배포만이라면 아래 제작 선행조건과 화면 질문을 다시 요구하지 않는다. 원본의 핵심 기능·비밀값·개인정보만 확인하고prototype.html로 바로 간다.references/sites-배포.md
⚠를 먼저 거쳤나? 핵심 기능이 1개로 좁혀지고 🔴 위험이 정리돼 있어야 한다. 안 했으면 지금이라도 하고 오는 게 빠르다.$idea-validate
- 의
context.md·주제·지역·데이터 검증 요약(idea-validate 확정본 + 오피스아워 메모) 를 읽는다. 정의서에 없는 기능을 만들자는 말이 나오면 "그럼 정의서부터 고치자"로 되돌린다. 정의서가 계약이다.MVP 정의 - 4단계에서 받은 실제 수치·장소명을 최대한 넣는다. 없으면 현실적인 예시값 + "예시" 표기.
- 디자인은 이미 정해져 있다. (
design.md산출물)의 CSS 토큰을 그대로 쓴다. 없으면$design-setup먼저, 만들면서 색 고민하지 않는다.$design-setup
若已有完成的，且需求仅为将其部署到Sites而非制作或修改页面，则无需再次询问以下制作前置条件及页面相关问题。只需确认源文件的核心功能、密钥、个人信息，直接参考prototype.html进行部署。references/sites-배포.md
⚠ 是否已先完成？需先将核心功能聚焦为1项，并梳理完🔴风险。若未完成，建议立即完成后再推进，效率更高。$idea-validate
- 阅读中的
context.md·主题·地区·数据验证摘要（MVP定义确定版本 + 办公时间笔记）。若有人提出制作规范中未提及的功能，需回应“那我们先修改规范吧”并拉回正轨，规范等同于契约。idea-validate - 尽可能使用第4阶段获取的实际数值、地点名称。若无相关数据，则使用贴近现实的示例值并标注“示例”。
- 设计已确定。需直接使用（
design.md产出物）中的CSS令牌。若无$design-setup，需先完成design.md，制作过程中无需纠结配色。$design-setup
먼저 묻기 (필수: 퍼실리테이션)
必问问题（核心：引导讨论）
바로 코드를 뽑지 말고 화면의 내용을 팀에게서 끌어낸다. 디자인(색·무드)은 묻지 않는다. 이미 에 있다.
design.md- "사용자가 이 화면을 처음 열면 뭐가 보여야 해요?" 첫 화면에 뭘 놓을지.
- "뭘 입력하고, 뭘 누르면, 뭐가 나오나요?" 입력 → 처리 → 출력을 팀 말로.
- 꼭 보여줄 핵심 기능 1개를 팀이 짚게(에서 좁힌 것과 일치 확인).
idea-validate - "우리가 찾은 데이터 중에 화면 어디에 올려야 문제가 한눈에 보일까요?"
답·합의는 에 남긴다.
context.md
不要直接编写代码，需先从团队成员处明确页面内容。无需询问设计（配色、风格），相关内容已在中确定。
design.md- *“用户首次打开这个页面时，应该看到什么内容？”*确定首页展示内容。
- *“需要输入什么内容，点击什么按钮，会输出什么结果？”*让团队用自己的语言描述输入→处理→输出流程。
- 引导团队明确必须展示的1项核心功能（需与中聚焦的内容一致）。
idea-validate - “我们收集的数据中，放在页面哪个位置能让问题一目了然？”
需将答案及共识记录在中。
context.md
산출 규칙 (중요)
产出规则（重要）
- 기준선 은 단일 파일: HTML+CSS+JS 한 파일. 외부는 폰트 CDN만(차트 라이브러리 금지, 네트워크가 끊기면 차트만 사라진다. 비교·순위는 인라인 SVG/CSS 막대로). localStorage 등 브라우저 저장소 금지: 상태는 JS 변수/메모리. 동적 앱의 영속 저장은 Sites가 지원하는 서버 쪽 기능으로 별도 구현한다.
prototype.html - 은 모든 팀의 기준선·오프라인 폴백이다. Sites에 올리기 위한 기술적 이유만으로 React/Next 계열 화면으로 다시 구현하거나 문구·스타일·동작을 바꾸지 않는다.
prototype.html - 다만 MVP가 인증·DB·서버 API·업로드·실시간 협업처럼 정적 HTML로는 검증할 수 없는 동적 기능을 실제로 요구하거나, 팀이 범위와 시간을 확인한 뒤 제품형 구현을 명시적으로 선택하면 의 동적 앱을 배포 원본으로 삼을 수 있다. 이때 Sites가 지원하는
site/구조나 기존의 호환 구조를 쓰며,vinext/React은 지우거나 덮어쓰지 않는다.prototype.html - 모바일에서도 보이게 반응형. 한국어 UI. (배포하면 심사위원이 폰으로 연다. 반응형이 실전이 된다.)
- 기준선 의 데이터는 파일 안에 JS 객체로 넣어 오프라인에서도 데모되게 한다. 동적 앱은 서버에서 최신 데이터를 받아도 되지만, 외부 API가 멈출 때 기준선이나 검증 스냅샷으로 핵심 시연이 이어져야 한다.
prototype.html - API 키를 HTML·브라우저 번들에 절대 넣지 않는다. 배포하는 순간 전 세계에 공개된다. 동적 앱은 서버 쪽 비밀 설정과 서버 경로를 쓴다.
- 基准线为单文件：包含HTML+CSS+JS的单个文件。仅可引入字体CDN（禁止使用图表库，网络断开时图表会消失，对比、排名需使用内嵌SVG/CSS条形图实现）。禁止使用localStorage等浏览器存储：状态需通过JS变量/内存实现。动态应用的持久化存储需使用Sites支持的服务器端功能单独实现。
prototype.html - 是所有团队的基准线及离线回退方案。不可仅因部署到Sites的技术需求，就用React/Next系列页面重新实现，或修改文案、样式、交互逻辑。
prototype.html - 但若MVP确实需要静态HTML无法验证的动态功能（如认证、数据库、服务器API、上传、实时协作），或团队确认范围及时间后明确选择产品级实现，则可将中的动态应用作为部署源文件。此时需使用Sites支持的
site/结构或现有兼容结构，且不可删除或覆盖vinext/React。prototype.html - 需实现响应式设计，确保在移动端正常显示，UI使用韩语。（部署后评审人员会用手机打开，响应式设计至关重要。）
- 基准线的数据需以JS对象形式嵌入文件，确保离线状态下也可进行演示。动态应用可从服务器获取最新数据，但需确保外部API中断时，可通过基准线或验证快照继续完成核心演示。
prototype.html - 绝对不可将API密钥放入HTML或浏览器打包文件中，部署后会向全球公开。动态应用需使用服务器端密钥配置及服务器路径。
prototype.html 만들기
制作prototype.html
- MVP 흐름(입력→처리→출력)을 실제로 클릭되는 화면으로. 최소 1개 핵심 기능이 동작.
- 예: 관심사 선택 → (내장 데이터로) 코스 생성 → 지도/카드 출력.
- 과욕 금지: 발표에서 보여줄 1~2 기능만 완성도 있게.
- 동적 기능이 이미 MVP로 확정됐다면 기준선에서는 그 기능의 입력→결과를 예시 데이터로 명확히 보여주고 라고 표시한다. 정적 화면을 두 번 완성하려고 시간을 쓰지 말고 아래에서 동적 앱으로 전환해 실제 기능을 검증한다.
예시
- 将MVP流程（输入→处理→输出）制作成可实际点击的页面，至少保证1项核心功能可正常运行。
- 示例：选择兴趣领域 → （通过内置数据）生成课程 → 输出地图/卡片。
- 避免贪多：仅需完成1~2项可用于演示的功能，保证完成度。
- 若动态功能已确定为MVP内容，则在基准线中需用示例数据清晰展示该功能的输入→结果，并标注“示例”。无需花费时间重复完成静态页面，直接切换至下方动态应用环节验证实际功能。
배포 방식 결정: 필요할 때 한 번만 묻는다
确定部署方式：仅在必要时询问一次
MVP 정의"우리 핵심 기능에 로그인·저장·서버 API·업로드·실시간 동작이 꼭 필요한가요, 아니면 지금 화면을 공개 URL로 올리면 충분한가요?"
- 공개 URL이면 충분하다 → 정적 원본 보존: 이 구현 원본이다.
prototype.html는 바이트 단위로 같은 파일을 싣는 최소 포장이다.site/ - 동적 기능이 MVP 계약에 있다 → 동적 앱: 가 배포 구현 원본이다. Sites가 지원하는
site/구조나 기존 호환 구조를 쓸 수 있다.vinext/React은 배포 전 기준선·오프라인 폴백으로 보존한다.prototype.html - 단지 Sites에 올리기 위해서, 또는 프레임워크가 더 그럴듯해 보여서 동적 앱으로 옮기지는 않는다. 반대로 동적 기능이 합의된 MVP인데 원본 보존 규칙을 이유로 막지도 않는다.
동적 앱으로 전환할 때는 아래 제품 계약을 기본값으로 유지한다. 바꿀 이유가 있다면 팀과 합의하고 에 차이를 기록한다.
context.md- 같은 대상 사용자와 문제
- 같은 핵심 기능 1개와 입력→출력 흐름
- 같은 데이터의 의미·출처·한계
- 의 토큰과 핵심 문구
design.md - 정의서 밖 기능을 슬쩍 늘리지 않기
若或团队需求中已明确部署方式，则无需再次询问，仅记录选择结果及理由即可。仅当部署方式不明确时，在本地基准线运行后询问以下问题：
MVP定义“我们的核心功能是否必须具备登录、存储、服务器API、上传、实时交互等功能，还是仅将当前页面部署为公开URL即可满足需求？”
- 公开URL即可满足需求 → 静态源文件保留：为实现源文件，
prototype.html仅需打包与该文件完全一致的最小内容。site/ - 动态功能属于MVP契约内容 → 动态应用：为部署实现源文件，可使用Sites支持的
site/结构或现有兼容结构。vinext/React需保留为部署前的基准线及离线回退方案。prototype.html - 不可仅为部署到Sites，或觉得框架看起来更专业就切换至动态应用。反之，若动态功能已纳入共识MVP内容，也不可因源文件保留规则而阻止切换。
切换至动态应用时，需默认遵循以下产品契约。若需修改，需与团队达成共识并在中记录差异。
context.md- 目标用户及解决的问题保持一致
- 核心功能（1项）及输入→输出流程保持一致
- 数据的含义、来源、局限性保持一致
- 中的令牌及核心文案保持一致
design.md - 不可擅自添加规范外的功能
실제 데이터 넣기 (TourAPI·혼잡도)
嵌入实际数据（TourAPI·拥挤度）
실제 수치·장소·혼잡도 예보를 화면에 올리고 싶으면 반드시 를 읽고 그대로 한다. 브라우저에서 TourAPI를 직접 부르면 CORS로 실패한다. 정적 기준선은 터미널에서 한 번 받아 HTML에 인라인하고, 동적 앱은 비밀키를 숨긴 서버 경로에서 호출하며 검증 스냅샷을 폴백으로 둔다.
references/실데이터-인라인.md若需在页面中展示实际数值、地点、拥挤度预报，必须严格参考。在浏览器中直接调用TourAPI会因CORS失败。静态基准线需在终端中获取一次数据并嵌入HTML，动态应用需通过隐藏密钥的服务器路径调用，并将验证快照作为回退方案。
references/실데이터-인라인.md선택한 원본에서 반복 (충분히 다듬기)
在选定源文件上迭代优化（充分打磨）
- 정적 방식은 을, 동적 방식은
prototype.html의 앱 소스를 수정한다. 배포용 복사본이나 빌드 산출물을 직접 고치지 않는다.site/ - 오피스아워·팀 피드백을 받으면 *"어디를 바꾸고 싶어요?"*로 받아 해당 부분만 수정한다. 동적 앱에서 기준선과 달라지는 변경은 이유를 기록한다.
- 매 반복 후 로그에 "vN: 무엇을 고침" 기록.
context.md - 사용자 테스트: 다른 팀·주변 사람에게 눌러보게 하고 "어디서 헷갈렸어요?" → 반영(연계).
$deep-dive - 시연 예행: 발표에서 보여줄 클릭 순서를 지금 한 번 밟아본다. 결과가 밋밋하거나 클릭이 너무 많으면 지금 고친다. 피칭 준비 단계에서 발견하면 늦다.
- 静态方式需修改，动态方式需修改
prototype.html中的应用源码。不可直接修改部署用副本或构建产物。site/ - 收到办公时间或团队反馈时，需先询问“您希望修改哪里？”，仅修改对应部分。动态应用中若有与基准线不同的修改，需记录理由。
- 每次迭代后，需在日志中记录“vN：修改内容”。
context.md - 用户测试：让其他团队或周边人员试用页面，并询问“哪里让您感到困惑？” → 根据反馈优化（关联）。
$deep-dive - 演示彩排：现在就走一遍演示时的点击流程。若结果平淡或点击步骤过多，立即优化。若在准备演讲阶段才发现问题，就太晚了。
배포: Codex Sites (전 팀의 종착점)
部署：Codex Sites（全团队的最终环节）
핵심 기능 1개가 로컬에서 확실히 돌면 배포한다. 완벽해질 때까지 미루지 말 것: 배포는 반복 중에 몇 번이고 다시 할 수 있고, 일찍 URL을 만들어두면 피드백 받기도 쉬워진다.
- 절차는 를 읽고 따른다.
references/sites-배포.md - 캠프 배포 목표는 고정이다. 소유자 전용·워크스페이스 전용 URL은 발표용 배포 완료로 인정하지 않는다. 공개 작업 직전 필요한 승인만 참가자에게 한 번 받는다.
public - 기존 에
site/.openai/hosting.json가 있으면 같은 사이트에 새 버전으로 재배포한다. 수정할 때마다 새 사이트를 만들지 않는다.project_id - 배포되면 로그인 정보가 없는 조회에서 실제 서비스 제목과 핵심 데모 흐름이 보이는지 확인한 뒤, 팀 전원이 자기 폰으로 URL을 열어 핵심 기능까지 눌러본다. 제품 자체에 회원 기능이 있어도 발표용 핵심 흐름은 가입 없이 체험할 수 있는 공개 데모 경로를 둔다.
- 배포 방식·URL·공개범위·기준선 검증·로그아웃 접근·휴대폰 확인 결과를 에 기록하고 발표 덱에 넣는다.
context.md - 배포가 막히면 붙잡고 있지 말 것, 5분 안에 안 풀리면 FT를 부르고 폴백으로 간다.
当1项核心功能可在本地稳定运行后，即可进行部署。不要等到完美再部署：部署可在迭代过程中多次进行，提前生成URL更便于获取反馈。
- 需严格遵循中的流程。
references/sites-배포.md - 训练营部署目标为固定为。仅所有者可见或仅工作区可见的URL不被视为演示用部署完成。公开操作前仅需向参与者获取一次必要的批准。
public - 若现有中已有
site/.openai/hosting.json，则在同一站点重新部署新版本。每次修改时不可创建新站点。project_id - 部署完成后，需在未登录状态下确认是否可看到实际服务标题及核心演示流程，之后所有团队成员需用自己的手机打开URL，并完成核心功能的点击测试。即使产品本身包含会员功能，演示用核心流程也需提供无需注册即可体验的公开演示路径。
- 需将部署方式、URL、公开范围、基准线验证结果、退出登录访问情况、手机验证结果记录在中，并添加至演示文稿。
context.md - 若部署遇到阻碍，不要强行纠结，5分钟内无法解决则联系FT并切换至回退方案。
완료 판정: 둘 중 하나면 통과
完成判定：满足以下任一条件即可通过
context.md산출물 > 배포 > 상태| 판정 | 조건 |
|---|---|
| |
| |
| |
우리 파일은 오프라인에서도 열리게 만들었으니 폴백은 진짜 폴백이다. "포기"가 아니라 검증된 상태로
적고 다음 단계로 간다. 자기 노트북에서만 열어본 건 해당하지 않는다. 남의 기기에서 한 번은 열어본다.
需确保的为以下任一状态，且对应行的所有证明材料齐全。两种状态均视为第6阶段完成。
context.md产出物 > 部署 > 状态| 判定 | 条件 |
|---|---|
| |
| |
| |
我们的文件支持离线打开，因此回退方案是真正的备选方案。需记录为**“已验证状态”而非“放弃”**，然后进入下一阶段。仅在自己笔记本上打开验证不算数，需在他人设备上至少验证一次。
더 가고 싶은 팀에게 (선택: 다음 계단)
给希望深入的团队（可选：下一阶段）
여기까지가 이 스킬의 기본 트랙이다. 배포까지 끝났고 시간이 남으면, 에 다음 계단이 있다. 실데이터를 더 깊게(L2), 대화형 에이전트로(L3). 시작 전에 FT에게 "업그레이드 해보고 싶다"고 말하라: 남은 시간 대비 어디까지가 현실적인지 같이 잡아준다.
references/업그레이드-경로.md以上为本技能的基础流程。若已完成部署且有剩余时间，中提供了下一阶段内容：深入使用实际数据（L2）、打造交互式Agent（L3）。开始前需告知FT“我们想尝试升级”：FT会协助判断剩余时间内可完成的合理范围。
references/업그레이드-경로.mdcontext.md 갱신
更新context.md
- 에 기준선 경로를 적고, Sites 프로젝트를 만들었다면
산출물 > 프로토타입에산출물 > Sites 소스경로를 적는다.site/ - 에
산출물 > 배포 방식·정적 원본 보존중 하나를 적는다. 공개 실패 여부는동적 앱에 별도로 적는다.배포 > 상태 - 에
산출물 > 배포 > 상태또는공개 배포됨을 적는다.로컬 폴백 검증됨·URL·공개범위·기준선 SHA-256·동적 전환 이유·기준선 검증·의도된 차이·배포 기능 검증·외부 의존 폴백·로그아웃 접근은휴대폰 확인의 같은 이름을 그대로 써서 모두 채운다. 해당하지 않는 값도../bootcamp-start/references/_context-template.md으로 남긴다.해당 없음 - , 로그 추가.
단계: 6
- 在中填写基准线路径，若创建了Sites项目，则在
产出物 > 原型中填写产出物 > Sites源文件路径。site/ - 在中填写
产出物 > 部署方式或静态源文件保留。公开失败情况需单独记录在动态应用中。部署 > 状态 - 在中填写
产出物 > 部署 > 状态或公开部署完成。需完整填写本地回退验证完成·URL·公开范围·基准线SHA-256·动态切换理由·基准线验证·有意差异·部署功能验证·外部依赖回退方案·退出登录访问，无对应值需填写手机验证。无 - 更新，并添加日志。
阶段: 6
끝맺음 (여기까지가 6단계: 프로토타입)
收尾（至此完成第6阶段：原型制作）
- 요약: 파일 경로 + 배포 판정 + 핵심 기능 한 줄.
- 다음은 : 이 화면을 감싸는 발표 덱을 만든다. 이어서
$pitch-deck-build에서 시연 시나리오·대본·리허설까지 피칭 전체를 준비한다. 만든 것과 보여주는 것은 다른 일이다.$pitch-prep - 아직 안 열렸으면 재촉하지 말고 팀과 나눈다:
- "이 데모, 처음 보는 사람이 눌러도 30초 안에 '오' 할까요? 어디가 약해요?"
- "발표 때 이 화면으로 어떤 이야기를 할지 미리 말로 해볼까요?"
- 总结：文件路径 + 部署判定 + 核心功能简述。
- 下一阶段为：制作用于展示此页面的演示文稿。之后可通过
$pitch-deck-build完成演示场景、脚本、彩排等全部演讲准备工作。制作内容与演示内容是两回事。$pitch-prep - 若尚未达成目标，不要催促，与团队共同讨论：
- “这个演示，第一次看到的人点击后能在30秒内理解吗？哪里有不足？”
- “我们提前演练一下，演示时如何用这个页面讲述我们的方案？”
자동으로 채우지 않기
禁止自动填充
- 화면에 뭘 놓을지는 팀에게서 받는다. 첫 화면·입력·출력·강조할 데이터를 묻기 전에 코드를 뽑지 않는다.
- 에 없는 기능을 슬쩍 넣지 않는다. 좋아 보여도 정의서가 계약이다. 넣고 싶으면 "그럼 정의서부터 고칠까요?" 로 되돌린다.
MVP 정의 - 데이터는 4단계에서 실제로 받은 값을 쓴다. 없는 걸 그럴듯하게 만들지 않는다. 불가피하면 화면에 "예시" 라고 박는다.
- 页面内容需由团队确定。在询问首页内容、输入输出、需强调的数据前，不可编写代码。
- 不可擅自添加中未提及的功能。即使看起来不错，规范也是契约。若想添加，需回应“那我们先修改规范吧”并拉回正轨。
MVP定义 - 数据需使用第4阶段实际获取的数值。不可伪造看似合理的数据。若无法避免，需在页面上明确标注**“示例”**。
톤·품질
语气与质量
- 한 턴 = 맥락·이유 1문단 + 질문 1개. 질문만 툭 던지지 말고 왜 이걸 묻는지를 먼저 한 문단으로 친절하게 풀어준다. 대신 질문 개수는 늘리지 않는다. 한 번에 여러 개를 물으면 팀이 생각하지 않고 받아적기만 한다.
- AI가 이미 아는 답으로 몰지 않는다. 팀 생각이 틀려 보여도 "아닐까요?" "진짜 그럴까요?" 로 흔들지 말고, 무엇을 보면 알 수 있는지를 묻는다.
- 완성도 > 기능 수. 하나라도 확실히 되는 데모, 그리고 그 데모의 URL.
- 每次沟通 = 1段背景说明 + 1个问题。不可只抛出问题，需先以一段文字友好解释为什么要问这个问题。但不可增加问题数量，一次问多个问题会导致团队仅被动记录而不思考。
- 不可用AI已知的答案引导团队。即使团队的想法看似错误，也不要用“不是这样吧？”“真的是这样吗？”动摇他们，而是询问如何验证这个想法是否正确。
- 完成度 > 功能数量。打造一个可稳定运行的演示，以及对应的URL。