“给我一个教程大纲”得到的往往是干巴巴的步骤列表。好的教程大纲会选一个具体结果、点明学员水平，并在每一步加一个学员自己就能在屏幕上验证的成功标志。下面 12 个模板，会强制每条 Prompt 都带上这三样，外加先决条件和一座通往真实项目的”下一步”桥。
一句话速览
- 开头点明学员学完能做出的成果，而不是话题本身。
- 只写一个学员水平（纯新手 / 已掌握基础 / 有经验），模型才知道该讲多深。
- 每一步都配一个可验证的成功检查（“你应该看到 X”），先决条件放在最前面。
- 教程是端到端教新手，how-to 假设读者已有上下文，两种形态别混（参见 Diátaxis）。
- 截至 2026 年 6 月，写大纲首选 Claude Opus 4.7 或 Sonnet 4.6（结构干净，1M token 上下文，可整篇粘贴旧教程来重构）；想让模型顺带推敲节奏和坑，用 GPT-5.5 Thinking。
适合哪些场景
DevRel 作者、课程创作者、写新员工 onboarding 文档的创业者、把业余项目转成指南的技术博主。
什么时候不建议这样写 Prompt
参考文档别用（格式不同——它是目录，不是一段旅程），解释类文章也别用。还有：自己没端到端跑过一遍的任务，千万别让模型写大纲，它会很乐意编出根本跑不通的步骤。
每条教程大纲 Prompt 都该带什么
六个要素，决定大纲是”能用”还是”干巴巴的步骤堆”：
- 结果：学完能做到的那一件事（比如”把静态站点部署到 Firebase Hosting”），写成一个完成的成果，而不是话题。
- 学员水平：纯新手、已掌握基础、还是有经验——它决定你要解释多少。
- 时长预算：15、30、60 分钟。它给范围封顶，也告诉模型何时该拆成系列。
- 先决条件：知识、工具、账号，外加一条读者在第 1 步前就能跑的环境自检命令。
- 每步成功检查：一句可验证的”你应该看到 X”，让学员不会卡住还不吭声。
- 下一步：从教程结尾通往真实项目的桥，让读者在最后一步之后仍有动力继续。
这套 Prompt 适合用在哪
- 博客教程大纲
- 课程模块大纲
- 文档 walkthrough
- 内部 onboarding 文档
- 工作坊 / 演讲大纲
该用哪个模型来跑（2026 年 6 月）
| 模型 | 为何适合写大纲 | 备注 |
|---|---|---|
| Claude Sonnet 4.6 | 结构干净；1M token 上下文 | 免费档受限；Pro 每月 $20 |
| Claude Opus 4.7 | 长文结构最强；可整篇粘贴旧教程来重构 | Max 套餐；API 每 1M token 5/25 |
| GPT-5.5（Thinking） | 会推敲节奏和坑 | Plus 每月 $20；ChatGPT 默认模型 |
| Gemini 3.1 Pro | 长文档表现强，1M 上下文 | Google AI Pro 每月 $19.99 |
这些模板与模型无关——上面任何一个都能跑。要重构一篇很长的旧教程，优先用 1M token 的模型（Opus 4.7、Sonnet 4.6 或 Gemini 3.1 Pro），整篇草稿能一次塞进 Prompt。
12 个可直接复制的 Prompt 模板
1. 结果导向大纲
I want to write a tutorial that ends with the learner achieving: `{outcome}`. Learner level: `{level}`. Time budget: `{minutes}` minutes. Output an outline with: (1) one-sentence promise, (2) prerequisites, (3) 5-8 numbered steps each with a success check, (4) common-pitfalls section, (5) what to do next.可替换变量： outcome 学完能做到的事, level 学员水平, minutes 时长
2. 入门友好版
Rewrite this outline for absolute beginners. (1) Replace each jargon term with a plain-English version + a one-line side note for advanced readers, (2) Add a "first try" with a known-good fixture, (3) Halve any step that has > 3 substeps.3. 先决条件
For tutorial topic `{topic}`, write the prerequisites section. Cover: (1) Knowledge prereqs, (2) Tools / accounts needed, (3) Working setup checks (a one-liner the reader can run), (4) Time estimate. Don't list optional reading.可替换变量： topic
4. 每步成功检查
For this outline, append a success check to each step: a one-line "you should see X" the reader can verify before moving on. Don't add a check that requires output unavailable in the step itself.5. 常见坑
For this tutorial, list 5 common pitfalls. For each: (1) symptom (what the learner will see), (2) cause, (3) one-line fix. Order by likelihood — most-frequent pitfall first.6. 跨平台变体
For commands or code in this tutorial that differ on macOS / Windows / Linux, produce a small variant table. Don't fork the whole tutorial — only the lines that differ.7. 长教程分章
My tutorial would be 90+ minutes. Split into a 3-part series. Each part: outcome, time budget, prerequisites (linking back to part 1), final state at end of part. Don't cliff-hang — each part must produce a usable artifact.8. 视频脚本大纲
Convert this written tutorial outline into a video script outline: (1) Cold-open hook (5s), (2) "What we'll build" (15s), (3) Steps with screen-action notes, (4) Outro CTA. Optimise for retention: each section ≤ 60s of screen time.9. 工作坊改编
Adapt this tutorial outline for a 60-minute live workshop: (1) Pre-work attendees must do, (2) In-room steps, (3) Pair-programming moments, (4) Q&A pause points, (5) Wrap with shipped artifact.10. 课程模块化
Turn this tutorial into a course module: (1) Learning objectives (3-5), (2) Lessons (each with title + length + outcome), (3) Quiz at end with 3 questions, (4) Capstone exercise. Phrase objectives with measurable verbs (build, configure, deploy).11. 大纲漏洞审查
Audit this outline for gaps: (1) Steps that assume an unstated prerequisite, (2) Jumps in difficulty, (3) Missing error-recovery, (4) Steps that produce no observable result. Output a fix list.12. 新版本框架适配
Update this tutorial for `{frameworkVersion}`. List: (1) Steps that need rewrite due to API change, (2) New idiomatic patterns the old tutorial misses, (3) Deprecated terms to remove. Don't propose a full rewrite if 4 patches do it.可替换变量： frameworkVersion
容易踩的坑
- 自己没端到端跑就开始写大纲。
- 没有成功检查——学员卡住不吭声。
- 先决条件写在最后。
- 只给一个平台的命令。
- 系列尾巴吊胃口。
- 把参考文档和教程当一种形态。
- 没写”下一步”——读者要桥到真实项目。
优化技巧
- 开头点明结果，不是话题。
- 每步只引入一个新概念。
- 可验证的成功检查很值钱。
- 坑写在代码前，学员中途会留意。
-
30 分钟就拆成系列。
- 收尾给”下一步”。
- 自己在干净机器上跑一遍验证大纲。
FAQ
- 教程多长合适？: 目标 15-30 分钟阅读时间，再长就用模板 7 拆成系列，每一部分都要交付一个能用的成果。
- 先代码还是先文字？: 结果 → 为什么 → 带代码的步骤 → 验证。别写”X 的历史”那种把重点埋掉的开头。
- 每步都要截图吗？: 只在文字单独会误导时加。截图比文字烂得快——界面一改版就废。
- 怎么让教程不过时？: 明确锁死框架和模型版本，给时效性说法标上日期，半年回看一次。模板 12 能把过时教程变成一份补丁清单。
- 教程还是 how-to？: 教程是端到端、保证跑通地教新手；how-to 假设读者已经能干活、只解决一个任务。一篇只用一种形态——Diátaxis 框架解释了为什么混用会让读者犯晕。
- 该用哪个 AI 模型写大纲？: 截至 2026 年 6 月，Claude Sonnet 4.6 或 Opus 4.7 结构最干净，还能把整篇旧教程装进上下文（1M token）。想让模型推敲节奏，GPT-5.5 Thinking 也很强。
- AI 写完整教程吗？: 大纲和初稿可以交给 AI。发布前每一步都要自己在干净机器上跑一遍——这是模型替你验证不了的唯一一件事。