readable-output
Compare original and translation side by side
🇺🇸
Original
English🇨🇳
Translation
Chinese输出工程:让 AI 输出长内容时按清单想一遍
Output Engineering: Let AI Follow a Checklist When Generating Long-Form Content
综合写作理论(Zinsser《On Writing Well》/ Heath《Made to Stick》/ Rosenfeld《Information Architecture》)+ 学习科学(Sweller CLT / Brown《Make It Stick》/ Wiggins backward design)+ 大厂文档实践(Stripe / GitLab / Linear / Anthropic / Google SRE)三方交叉验证。
Cross-validated by three perspectives: writing theories (Zinsser's On Writing Well / Heath's Made to Stick / Rosenfeld's Information Architecture), learning sciences (Sweller's CLT / Brown's Make It Stick / Wiggins' backward design), and documentation practices of top tech companies (Stripe / GitLab / Linear / Anthropic / Google SRE).
元原则(贴在最顶层,每次开始前默念)
Meta Principles (Post at the top, recite before starting each time)
- 如果你自己读完没有获得新认知,读者也不会有。 写作是 thinking on paper,不是模板填空。
- 终点是"读者下次能用",不是"读者这次能懂"。 Backward design:先想读者读完手里多了什么"可复用的工具"(一张对照表 / 一个判断框架 / 一条决策路径 / 一个口诀),再倒推写什么。
- 不列菜单——给推荐 + 一句话理由。 AI 喜欢"列出 5 个选项让你选",但好文档敢于 opinionated。
- If you don't gain new insights after reading it yourself, neither will the readers. Writing is thinking on paper, not filling in templates.
- The goal is "readers can use it next time", not "readers can understand it this time". Backward design: First figure out what "reusable tool" readers will have in hand after reading (a comparison table / a judgment framework / a decision path / a mnemonic), then work backward to decide what to write.
- Don't list menus — give recommendations + one-sentence reasons. AI likes to "list 5 options for you to choose", but good documentation is opinionated.
触发条件
Trigger Conditions
触发(需要给人读的中长 HTML 内容):
- "做个复盘 / 总结 / 汇总 / 整理"
- "做个教程 / 学习指南 / 上手文档"
- "把 X 讲清楚 / 整理成可读的 HTML"
- "做份报告 / 说明文档"
- 任何要求产出 > 500 字的结构化阅读内容
不触发(短输出 / 操作型 / 非 HTML 需求):
- 写代码 / 修 bug / 改文件
- 一两句话回答
- 代码 diff / 短列表
- 用户明确说"用 markdown 答" / "聊天里直接说"
- PRD(用 prd-doc-writer)/ 文章写作(用 writing-assistant)/ 起名(用 product-naming)
重要:本 skill 产出只有 HTML 一种格式。如果用户要 markdown,不用本 skill。
Trigger (needs medium-to-long HTML content for human reading):
- "Do a retrospective / summary / compilation / organization"
- "Create a tutorial / study guide / getting-started document"
- "Explain X clearly / organize into readable HTML"
- "Create a report / explanation document"
- Any request for structured reading content of over 500 words
No Trigger (short output / operational / non-HTML requirements):
- Writing code / fixing bugs / modifying files
- Answering in one or two sentences
- Code diffs / short lists
- User explicitly requests "answer in markdown" / "respond directly in chat"
- PRDs (use prd-doc-writer) / article writing (use writing-assistant) / naming (use product-naming)
Important: This skill only produces HTML format. Do not use this skill if the user requests markdown.
运作模式
Operation Mode
触发
↓
阶段 1:强制用 AskUserQuestion 一次性问 4 个关键问题
↓
用户选完
↓
阶段 2-6 在 AI 心里走(不对用户念稿)
↓
产出 HTML,顶部加「本次配置」确认条,浏览器自动打开例外(跳过阶段 1 的提问):
- 用户在 prompt 里已经明确所有 4 个参数(如"给 PM 看的 5K 字复盘,故事化风格")
- 用户明确说 "快速做" / "随便给我一份" / "别问"
Trigger
↓
Stage 1: Mandatory use of AskUserQuestion to ask 4 key questions in one go
↓
User completes selection
↓
Stages 2-6 run internally in AI (no verbal explanation to user)
↓
Generate HTML, add a "Current Configuration" confirmation bar at the top, and automatically open in browserExceptions (skip Stage 1 questions):
- The user has clearly specified all 4 parameters in the prompt (e.g., "5,000-word retrospective for PMs, narrative style")
- The user explicitly says "do it quickly" / "just give me one" / "don't ask"
阶段 1(强制):用 AskUserQuestion 一次性问 4 个
Stage 1 (Mandatory): Use AskUserQuestion to Ask 4 Questions in One Go
必须用 AskUserQuestion 工具发起一次询问,包含下面 4 个问题。问题文案和选项可微调但维度不能换。
Must use the AskUserQuestion tool to initiate a single inquiry containing the following 4 questions. The question wording and options can be adjusted slightly, but the dimensions cannot be changed.
问题 1:给谁看?(受众)
Question 1: Who is it for? (Audience)
| 选项 | 说明 |
|---|---|
| PM / 产品经理 | 偏故事、对标、决策、可复用框架 |
| 工程师 / 技术新人 | 含代码片段、技术决策、动手指南 |
| 高管 / 决策者 | TL;DR + 数据 + 投/不投建议 |
| 自己 / 备忘 | 时间线 + 笔记式、备查 |
| 外部用户 / 客户 | 教程式、概念建梯 |
| Option | Description |
|---|---|
| PM / Product Manager | Focuses on stories, benchmarks, decisions, and reusable frameworks |
| Engineer / Technical Newcomer | Includes code snippets, technical decisions, and hands-on guides |
| Executive / Decision-Maker | TL;DR + data + investment/rejection recommendations |
| Self / Memorandum | Timeline + note-taking style, for future reference |
| External User / Customer | Tutorial-style, builds conceptual step-by-step |
问题 2:读完拿什么?(终点)
Question 2: What will readers gain after reading? (Goal)
| 选项 | 说明 |
|---|---|
| 决策依据 | 看完能 go/no/hold |
| 操作步骤 | 看完能动手 |
| 概念理解 | 看完知道是什么 |
| 故事共鸣 | 看完有感触 |
| 备忘归档 | 看完之后能查 |
| Option | Description |
|---|---|
| Decision Basis | Can decide go/no/hold after reading |
| Operation Steps | Can take action after reading |
| Conceptual Understanding | Knows what it is after reading |
| Emotional Resonance | Feels touched after reading |
| Memorandum Archiving | Can refer to it later after reading |
问题 3:要详到什么程度?
Question 3: How detailed should it be?
设计原因:字数是后验感受、且常常承诺不到(素材撑不到时硬卡字数会注水)。所以字数不进用户视图,只承诺用户能感知的两件事——「包含什么」和「阅读时间」。
| 选项 | 包含什么 | 阅读时间 |
|---|---|---|
| 速读卡 | TL;DR + 1 个核心框架 / 1 张主图,能转发 | 3 分钟 |
| 标准版(默认推荐) | 核心点 + 故事 + 反例 + 出口 | 5-8 分钟 |
| 教学版 | + 背景延伸 + 多视角对照 + 可复用框架 + 边界声明 | 20-30 分钟 |
| AI 自选 | 按"受众耐受时间 × 素材独立信息点数"反推 | — |
字数怎么定(AI 内部参考,不告诉用户、不在配置条里写字数承诺):
- 阅读速度按 PM/产品类内容 300 中文字/分钟 反推。
- 速读卡 → 内部目标 ~800 字 | 标准版 → ~1.5K-2.5K 字 | 教学版 → ~5K-8K 字
- 真正决定停笔的是"包含什么"清单是否每项都讲到位(standard 的"核心点 / 故事 / 反例 / 出口"四件事都齐全;teaching 多 4 项延展),而不是"字数到了"。
Design Reason: Word count is a post-experience feeling and often cannot be fulfilled (forcing to meet word count will lead to fluff when materials are insufficient). Therefore, word count is not shown to users, only two perceptible commitments are made — "What it includes" and "Reading time".
| Option | What it includes | Reading Time |
|---|---|---|
| Quick Read Card | TL;DR + 1 core framework / 1 main diagram, shareable | 3 minutes |
| Standard Version (default recommendation) | Core points + stories + counterexamples + exit | 5-8 minutes |
| Teaching Version | + Background extension + multi-perspective comparison + reusable framework + boundary declaration | 20-30 minutes |
| AI Selection | Derived from "audience tolerance time × number of independent information points in materials" | — |
How to determine word count (internal reference for AI, not told to users, not included in the configuration bar):
- Reading speed is calculated based on PM/product content: 300 Chinese characters per minute.
- Quick Read Card → internal target ~800 words | Standard Version → ~1,500-2,500 words | Teaching Version → ~5,000-8,000 words
- The real stopping criterion is "whether each item in the 'What it includes' list is fully covered" (the four elements of standard version: core points / stories / counterexamples / exit are all complete; teaching version adds 4 extended items), not "word count is reached".
阶段 1.5(强制):素材体量自检 + 主动反劝
Stage 1.5 (Mandatory): Material Volume Self-Check + Active Persuasion
问题 4 答完后、进入阶段 2 之前,AI 必须做一次自检。触发反劝的场景只有一个:
- 单文档型素材(单个 README / 单个 PRD / 单篇文章)且原文 < 3K 字 + 用户选了「教学版」
触发后,AI 必须中断流程,向用户主动反劝:
⚠️ 提示一下:你选的是教学版(20-30 分钟阅读),但素材是单 [README/PRD/文章] 仅 X 字。强行扩到教学版深度,约 60% 内容会是 AI 推演(背景延伸 / 对照 / 框架),不是素材原文。建议二选一: ① 改成「标准版」(5-8 分钟),刚好覆盖素材现有深度 ② 补充 2-3 份同类素材(多 PRD / 同领域多篇文章 / 项目全部文档),让教学版有真正的舞台要继续教学版吗?(继续 / 改标准版 / 我去补素材)
- 用户改档:按新档位走阶段 2-6
- 用户去补素材:等用户补完再继续
- 用户坚持继续教学版:才产出,且必须加「素材体量警告」横幅 + 每段推演加「推演」标签(详见输出规则)
多源素材 / 非教学版 → 不触发反劝,直接进阶段 2。
After answering Question 4 and before entering Stage 2, AI must perform a self-check. There is only one scenario that triggers persuasion:
- Single-document materials (single README / single PRD / single article) with original text < 3,000 words + user selects "Teaching Version"
When triggered, AI must interrupt the process and actively persuade the user:
⚠️ Reminder: You selected the Teaching Version (20-30 minutes of reading), but the material is a single [README/PRD/article] with only X words. Forcing to expand to the Teaching Version depth will result in approximately 60% of the content being AI-derived (background extension / comparison / framework), not from the original material. Please choose one of the following: ① Switch to "Standard Version" (5-8 minutes), which just covers the existing depth of the material ② Supplement 2-3 similar materials (multiple PRDs / multiple articles in the same field / all project documents), so the Teaching Version has a proper foundationDo you want to continue with the Teaching Version? (Continue / Switch to Standard Version / I'll supplement materials)
- User switches version: Proceed to Stages 2-6 with the new version
- User supplements materials: Wait for the user to complete supplementing before continuing
- User insists on Teaching Version: Generate the output, and must add a "Material Volume Warning" banner + label each derived section with "Derived" (see output rules)
Multi-source materials / Non-Teaching Version → No persuasion triggered, directly enter Stage 2.
问题 4:风格 + 侧重(合并)
Question 4: Style + Focus (Combined)
每个选项是「视觉调性 + 内容侧重」绑定的:
| 选项 | 视觉 | 内容侧重 |
|---|---|---|
| 工程严肃 | 清新蓝(Stripe/Linear 风) | 教训方法论为主 |
| 故事化阅读 | 暖色书卷(米白 + 深棕) | 故事完整性为主 |
| 决策简洁 | 极简黑白(Apple 文档风) | 数据冲击为主 |
| 技术深度 | 暗色科技(GitHub Dark) | 含代码细节 |
| AI 自选 | — | 按受众默认推荐 |
用户选完后,把 4 个参数写入 HTML 顶部「本次配置」段(见下方"输出文件规则")。
Each option is a combination of "visual tone + content focus":
| Option | Visual Style | Content Focus |
|---|---|---|
| Engineering Serious | Fresh blue (Stripe/Linear style) | Focuses on lessons and methodologies |
| Narrative Reading | Warm bookish tone (off-white + dark brown) | Focuses on story completeness |
| Concise Decision-Making | Minimalist black and white (Apple documentation style) | Focuses on data impact |
| Technical Depth | Dark tech style (GitHub Dark) | Includes code details |
| AI Selection | — | Recommended by default based on audience |
After user selection, write the 4 parameters into the "Current Configuration" section at the top of the HTML (see "Output File Rules" below).
阶段 2-6(AI 自己心里走,不对用户念)
Stages 2-6 (Run internally in AI, no verbal explanation to user)
阶段 2 · 定终点(backward design)
Stage 2 · Define the Goal (Backward Design)
基于阶段 1 用户选的"读完拿什么",进一步具体化:读完手里多了什么"可复用的东西"?
- 一张对照表(A vs B 怎么选)
- 一个判断框架(什么情况该做 X)
- 一条决策路径(遇到 Y → 先 a → 再 b)
- 一个口诀(短句易记)
- 一份 checklist
反模式:终点只定到"读者理解"。
Based on the user's selection of "What will readers gain after reading" in Stage 1, further specify: What "reusable item" will readers have in hand after reading?
- A comparison table (how to choose between A and B)
- A judgment framework (when to do X)
- A decision path (when encountering Y → first a → then b)
- A mnemonic (short, easy to remember)
- A checklist
Anti-Pattern: Only defining the goal as "readers understand".
阶段 3 · 抓核心点(≤ 3 个)
Stage 3 · Capture Core Points (≤ 3)
工作记忆铁律(Sweller 认知负荷理论):新读者一次只能处理 3-4 个新组块。默认 3 个,最多 5 个,超过必须合并或降级到附录。
核心点之间关系必须显式想清楚:
- 【并列】3 个独立要点,可任意顺序读
- 【依赖链 Why → What → How】必须按顺序
砍半测试:列出所有候选点后问"只能保留一半留哪几个"——剩下的就是真骨干。
Working Memory Iron Law (Sweller's Cognitive Load Theory): New readers can only process 3-4 new chunks at a time. Default to 3, maximum 5; if exceeding, must merge or demote to appendix.
The relationship between core points must be explicitly clarified:
- [Parallel] 3 independent points, can be read in any order
- [Dependency Chain Why → What → How] Must be in order
Half-Cut Test: After listing all candidate points, ask "Which ones would you keep if you could only keep half" — the remaining ones are the real backbone.
阶段 4 · 选主结构(一个,不要叠)
Stage 4 · Choose Main Structure (One, No Overlapping)
警告:这一阶段最容易"自己在示范认知超载"——给推荐 + 一句话理由,不列菜单。
主结构 1 个(按内容性质选):
| 内容性质 | 推荐结构 |
|---|---|
| 一段过程 / 多步骤决策 | 时间线 |
| 多个主题平行 | 分类章节 |
| 解决某个具体问题 | 问题导向 Q&A |
| 教学 / 概念建梯 | 由浅入深教学梯度 |
| 多版本对比 | before/after |
| 故事性强 | 危机-转折-启示 |
主视觉 1 套(不要叠):表 / 对比卡 / ASCII 图 / Callout,选一种主导。
视觉细节(颜色、字体)按阶段 1 用户选的"风格"决定。
Warning: This stage is most prone to "demonstrating cognitive overload yourself" — give recommendations + one-sentence reasons, do not list menus.
One main structure (selected based on content nature):
| Content Nature | Recommended Structure |
|---|---|
| A process / multi-step decision | Timeline |
| Multiple parallel topics | Categorized chapters |
| Solving a specific problem | Problem-oriented Q&A |
| Teaching / conceptual step-by-step | Gradual teaching from shallow to deep |
| Multi-version comparison | Before/after |
| Strong narrative | Crisis-Turn-Revelation |
One main visual style (no overlapping): Table / comparison card / ASCII diagram / Callout, choose one as the dominant style.
Visual details (colors, fonts) are determined by the "Style" selected by the user in Stage 1.
阶段 5 · 写:TL;DR + 论点句 + 反例 + 出口
Stage 5 · Writing: TL;DR + Topic Sentence + Counterexample + Exit
5.1 开篇 TL;DR / 钩子(前置,不能埋):Stripe / Google SRE 实践——前 2-3 句 = 全文摘要。钩子三选一:反常识 / 痛点 / 数字冲击。
5.2 每段一个论点句开头:先说结论再展开。
5.3 每个正面论点配一个反例 / What not to do:Anthropic Docs 实践,反例对照比正面示例更有效。
5.4 结尾给"出口":可复用产物 + 下一步行动 + 边界声明(什么时候不适用)。
5.5 数据带出处,不复制已有内容:链接引用(GitLab single source of truth)。
5.6 复盘类内容:blameless 原则:对事不对人。
5.7 检索提示:开头一句总结 + 每节末尾回顾 + 可复用口诀。
5.1 Opening TL;DR / Hook (placed upfront, cannot be buried): Stripe / Google SRE practice — first 2-3 sentences = full article summary. Choose one of three hooks: counterintuitive point / pain point / data impact.
5.2 Each paragraph starts with a topic sentence: State the conclusion first, then expand.
5.3 Each positive argument is paired with a counterexample / What not to do: Anthropic Docs practice, counterexample comparison is more effective than positive examples.
5.4 Provide an "exit" at the end: Reusable output + next action + boundary declaration (when it is not applicable).
5.5 Data with sources, no copying existing content: Link references (GitLab single source of truth).
5.6 Retrospective content: blameless principle: Focus on the issue, not the person.
5.7 Retrieval prompts: Opening summary sentence + end-of-section review + reusable mnemonic.
阶段 6 · 自检 5 问
Stage 6 · Self-Check 5 Questions
写完前必过:
- 不懂这事的人能看懂吗?
- 读完一周后能复述核心吗?
- 最长那段砍一半还说得通吗?
- 每段是否都在一屏内?(Linear One-Screen Test)
- 是按"详略档完成度"产的,不是为了凑字数硬加的吗?(如果为了卡字数加了背景延伸/虚构案例/重复同类场景,砍掉)
Must go through these before finishing:
- Can someone who doesn't understand this topic understand it?
- Can readers retell the core content a week later?
- Does it still make sense if the longest paragraph is cut in half?
- Is each paragraph within one screen? (Linear One-Screen Test)
- Is it produced according to "completeness of detail level" instead of forcing to meet word count? (If background extensions/fictional cases/repeated scenarios are added to meet word count, remove them)
反模式总清单
Anti-Pattern Checklist
| 反模式 | 哪个阶段 | 后果 |
|---|---|---|
| 跳过阶段 1 直接开写 | 1 | 自我感动 / 走偏 |
| 一次问超过 4 个问题 | 1 | 用户认知负担过重 |
| 用户已给的参数还重复问 | 1 | 啰嗦 / 显得不智能 |
| 终点定在"读者理解" | 2 | 信息汇总而非可迁移工具 |
| 5 个核心点并列 | 3 | 工作记忆超载 |
| 不分并列 vs 依赖链 | 3 | 结构混乱 |
| 列菜单不给推荐 | 4 | AI 让用户选 5 种结构 |
| 主视觉叠加(表+卡+图全用) | 4 | 视觉超载 |
| HTML 顶部没加「本次配置 + 追加提示」条 | 4 | 用户不知道按什么基准产的、也不知道可以追加 |
| 为了卡字数硬加方法论延展 / 虚构案例 / 重复场景 | 3-5 | 注水,自检第 5 问就是为这条而设 |
| 单文档素材选「教学版」未触发主动反劝 | 1.5 | 必然注水 + 用户预期错位(实测 README 类素材撑过 5K 就开始虚构) |
| 配置条 / 表格里写"参考字数"暴露给用户 | 3 / 文件规则 | 用户预期被字数锚定,撑不到时体感是"骗我" |
| TL;DR 埋在中间 | 5 | 读者前 30 秒走人 |
| 没有反例对照 | 5 | 正面示例容易被误用 |
| 数据无出处 | 5 | 容易编造 |
| 文档里抄已有内容 | 5 | 信息漂移 |
| 复盘里指责具体人 | 5 | 违反 blameless |
| 写完不自检直接交付 | 6 | 长 / 啰嗦 / 难读 |
| Anti-Pattern | Stage | Consequence |
|---|---|---|
| Skip Stage 1 and start writing directly | 1 | Self-satisfaction / deviation from requirements |
| Ask more than 4 questions at once | 1 | Excessive cognitive burden on users |
| Repeat questions for parameters already provided by users | 1 | Verbose / appears unintelligent |
| Define goal as "readers understand" | 2 | Information summary instead of transferable tool |
| 5 parallel core points | 3 | Working memory overload |
| Fail to distinguish parallel vs dependency chain | 3 | Structural confusion |
| List menus without giving recommendations | 4 | AI lets users choose 5 structures |
| Overlap main visual styles (use table + card + diagram together) | 4 | Visual overload |
| No "Current Configuration + Additional Prompt" bar at the top of HTML | 4 | Users don't know the basis of the output or that they can request adjustments |
| Force to add methodology extensions / fictional cases / repeated scenarios to meet word count | 3-5 | Fluff, the 5th self-check question is designed for this |
| No active persuasion when user selects "Teaching Version" for single-document materials | 1.5 | Inevitably fluff + user expectation mismatch (actual tests show README-like materials start to fictionalize when exceeding 5,000 words) |
| Expose "reference word count" to users in configuration bar / tables | 3 / File Rules | User expectations are anchored to word count, and they feel "deceived" when the count is not met |
| TL;DR buried in the middle | 5 | Readers leave within the first 30 seconds |
| No counterexample comparison | 5 | Positive examples are prone to misuse |
| Data without sources | 5 | Prone to fabrication |
| Copy existing content into the document | 5 | Information drift |
| Blame specific individuals in retrospectives | 5 | Violates blameless principle |
| Deliver without self-check after writing | 6 | Long / verbose / hard to read |
快速决策树
Quick Decision Tree
触发
↓
[阶段 1] AskUserQuestion 4 问(除非已明确)
↓
[阶段 1.5] 素材体量自检 → 单文档 + 教学版 → 主动反劝改档
↓
[阶段 2] 定终点 = 可复用的什么?
↓
[阶段 3] 3 个核心点 + 砍半测试
↓
[阶段 4] 主结构 + 主视觉(不叠)
↓
[阶段 5] TL;DR + 论点句 + 反例 + 出口
↓
[阶段 6] 自检 4 问 → 砍 / 拆 / 调
↓
HTML 输出(顶部加确认条)+ 浏览器打开Trigger
↓
[Stage 1] AskUserQuestion 4 questions (unless already specified)
↓
[Stage 1.5] Material volume self-check → single document + Teaching Version → active persuasion to switch version
↓
[Stage 2] Define goal = what reusable item?
↓
[Stage 3] 3 core points + half-cut test
↓
[Stage 4] Main structure + main visual style (no overlap)
↓
[Stage 5] TL;DR + topic sentence + counterexample + exit
↓
[Stage 6] Self-check 4 questions → cut / split / adjust
↓
HTML output (add confirmation bar at top) + open in browser输出文件规则
Output File Rules
HTML 顶部必加「本次配置 + 追加提示」条
Must Add "Current Configuration + Additional Prompt" Bar at the Top of HTML
每份产出的 HTML 在 Hero 区下方、正文上方,必须加这样一段双行条:
html
<div class="config-bar">
<div class="config-line">
📋 本次配置 · 受众:[问题 1 答案] · 终点:[问题 2 答案]
· 详略:[问题 3 答案](约 [阅读时间]) · 风格:[问题 4 答案]
</div>
<div class="hint-line">
💬 觉得短?告诉我「展开 [章节名]」/「加 [背景/案例/可复用框架]」
觉得长?「砍到要点」/「合并 X 章和 Y 章」
</div>
</div>为什么加追加提示:长度是后验感受,事前再准也会有"差一点"。把"差一点"显式化成可点的指令,用户不用重跑就能迭代。这是这份 skill 故意不卡死字数的配套机制。
为什么配置条只写阅读时间不写字数:阅读时间是用户能感知的承诺、字数是 AI 内部目标。素材撑不到字数时硬卡会注水,撑过头时硬砍会丢内容。把字数从用户视图删掉,避免"标 5K-8K 给 3K"这种期望错位(这种错位等价于旧版"卡不住")。
Each generated HTML must include this two-line bar below the Hero section and above the main content:
html
<div class="config-bar">
<div class="config-line">
📋 Current Configuration · Audience: [Answer to Question 1] · Goal: [Answer to Question 2]
· Detail Level: [Answer to Question 3] (approx. [Reading Time]) · Style: [Answer to Question 4]
</div>
<div class="hint-line">
💬 Too short? Tell me "Expand [Chapter Name]" / "Add [Background/Case/Reusable Framework]"
Too long? "Cut to key points" / "Merge Chapter X and Chapter Y"
</div>
</div>Why add additional prompt: Length is a post-experience feeling, and even the most accurate pre-estimation may have "almost there" moments. Explicitly turn "almost there" into actionable instructions, so users can iterate without restarting the process. This is a supporting mechanism for this skill's intentional choice not to rigidly fix word count.
Why only show reading time instead of word count in configuration bar: Reading time is a perceptible commitment for users, while word count is an internal target for AI. Forcing to meet word count will lead to fluff when materials are insufficient, or lose content when materials exceed the count. Removing word count from user view avoids expectation mismatch like "marked 5,000-8,000 words but delivered 3,000" (this mismatch is equivalent to the old version's "unable to meet the count").
文件路径
File Path
默认写入项目 下:
docs/docs/[内容主题]-[YYYYMMDD].html如果项目没有 docs/,写入用户指定路径或当前目录。
Default to write into the project's directory:
docs/docs/[Content Topic]-[YYYYMMDD].htmlIf the project does not have a docs/ directory, write into the user-specified path or current directory.
写完自动打开
Automatically Open After Writing
写完 HTML 文件后,运行 在浏览器打开供 review。
open <path>After writing the HTML file, run to open it in the browser for review.
open <path>维护规则
Maintenance Rules
这份清单综合三方视角(写作 / 认知科学 / 大厂实践)交叉验证而来。如果有新来源(某本经典写作书、某家公司最佳实践)值得加入,按"是不是 3 方都认可"为标准筛选。
反原则:不要往清单里加"可能有用但不是必须"的检查项。AI 走清单本身有成本,每加一项都要确认能阻止某种具体反模式。
This checklist is cross-validated from three perspectives (writing / cognitive science / top company practices). If new sources (a classic writing book, a company's best practice) are worth adding, filter them by the standard "whether all three perspectives recognize it".
Anti-Principle: Do not add check items that "may be useful but not mandatory" to the checklist. AI incurs costs when following the checklist, so each added item must confirm that it can prevent a specific anti-pattern.