企业官网建设流程全解析

• 人工智能
• AI 技能/插件
• 提示工程

导读

longform是 beautiful-article 技能体系中默认的文章类型，面向"完整长文、归档、深度阅读"场景：当源材料是连贯的论证 / 叙事 / 综述，且用户要求原文级保留时，它是最佳结构决策。本文以 article-types/longform.md 为骨架，结合仓库中的类型路由、组件协议、Raw 政策与工作流源码，完整讲解 longform 的典型结构、组件取舍、Raw 边界、配图与主题倾向、自检清单以及"何时不要用 longform"，让读者既能按类型清单直接套用，也能理解它为何是 beautiful-article 的默认策略。

1. 什么是 longform：默认类型的定位与适用前提

在 beautiful-article 中，文章类型是结构决策，主题是审美决策，两者完全解耦（见 article-types.md）。longform是十种已注册类型（longform / full-report / tutorial / explainer / dialogue / review / essay / briefing / interactive-explainer / visual-essay）中的第一种，也是 SKILL.md 声明的默认文章类型：

默认策略：输出 single HTML；文章类型longform；信息保留 100%。

它的适用前提非常明确：

• 源材料是连贯的论证 / 叙事 / 综述；
• 用户要原文级保留，即不打算压缩或删减信息密度。

从 information-density.md 的信息密度表看，100% 保留对应 longform，表达特征是"长文为主，Raw 增强，完整章节和细节"，适合"完整归档、原文级深度阅读"。

需要特别注意一个事实：longform 与 100% 信息保留在实践上是绑定的。article-types.md 顶部明确警告，longform + 20%这类组合是伪选项——要么类型变形，要么内容空洞（"longform 写出 8 章每章 2 段"）。因此 Phase 2 规划阶段在 plan-template.md 中只要求记录类型与标配保留比例，只有用户明确想精修（如"longform 但只要 60%" = 一篇被深度编辑的长文）时才作为非标配组合写入plan/plan.md的 Brief 段，并由主 Agent 在写每节时手动调整正文 / 视觉比例。

2. 核心参数：100% 信息保留意味着什么

longform 的推荐信息保留为100%，其执行标准是：

原文关键内容不丢；只允许删除明显的重复段落和无信息的过场句。

这定义了两个操作边界：

• 必须保留：原文的关键论证、数据、结论、引用、代码与表格；
• 允许删除：明显的重复段落、无信息的过场句（如"正如我们前面提到的……"这类纯粹衔接性废话）。

从 SKILL.md 的"成功标准"可以进一步看到这条原则的验收口径：

40% 信息时读起来像被编辑过的文章，而非缩水摘要；100% 信息时像被精修过的长文，而非原文搬运。

也就是说，100% 保留不等于照抄原文——它要求用 beautiful-article 的结构与视觉手段对原文做"精修"，让信息量一点不少，但阅读体验从线性的 Markdown 变成有节奏、可定位、可交互的网页文章。这是 longform 自检清单（见第 7 节）中"100% 信息是否读起来像被精修过的长文（而非原文搬运）"这条的根本原因。

3. 典型结构：Hero → Lead → Summary → Sections → Raw → Conclusion

longform 的典型结构（来自 article-types/longform.md）：

Hero → Lead（导语，框定主题）→ 可选 Summary（TL;DR / 结论先行） → 多个 Section（必要时 Subsection）→ 关键概念处 Raw 增强 → Conclusion

逐段的职责如下：

TOC 的开启条件也是 longform 特有的：当长文超过 10 个小节、或预估阅读时间超过 15 分钟时，开启TOC。这与 layout.md 中"本 Skill 默认开启 TOC（长文有导航更易读）"的策略一致——<Article toc>会渲染左侧目录，从Section/Subsection自动派生，最多三级、带滚动高亮；窄视口（<1000px）自动回落为单栏。

在 section-build.md 中可以看到这一结构的落地形态：每个 Section 必须是独立组件文件（article/sections/NN-*.tsx），Article.tsx只做组装（assembler），例如：

<Article toc width="regular"> <Hero ... /><Lead>…</Lead> <SectionOpening /> <SectionContext /> <Conclusion>…</Conclusion> </Article>

4. 组件选择：正文是绝对主体，别把连贯段落拆成卡片堆

longform 的组件策略第一条是正文段落为绝对主体，应占文章绝大部分篇幅。其余语义组件只在内容"确实是"那个结构时才用（component-policy.md 的 litmus test：若一句话 / 一个列表 / 一张表 / 一块 Raw 读起来更好，就用那个）：

• Aside：点出关键直觉 / 历史注 / 反方观点；
• Quote：引用名言或原话；
• Table：承载二维数据；
• CodeBlock/Formula：技术内容专用（写代码只用CodeBlock，不直接用其底层HighlightedCode）；
• Raw：自由层，任意 HTML / CSS / JS / React。

longform 最常见的走样形态，在文档中被明确定义为卡片堆——把连贯段落拆成一堆Aside/ 卡片式的视觉块，让论证断裂、文章变得零碎。规避方法就是坚持 prose-first：普通段落写成Section的 children，组件是"点睛"而非"装饰"。

从仓库的默认主题档案也可以印证这条纪律：tufte.md（Data-Ink 主题，longform 技术 / 证据型的首选）要求"页面上每一滴墨水都承载信息，去除卡片、填色、阴影、圆角、装饰色"；knuth.md（学术 / 论文型）同样禁止"卡片、面板、填色块、投影、圆角"。两个主题的禁止项恰好与"卡片堆是 longform 最常见的走样形态"形成互证。

5. Raw 边界：增强而非主体，用--ra-*token 约束

longform 对 Raw 的使用给出了清晰的边界：

在关键概念、数据趋势、机制处插入 Raw 自由层（轻交互 / 自定义排版 / 动效 / 按需 SVG），给长文节奏与呼吸；每块服务具体段落，用--ra-*token。Raw 是增强而非主体——如果开始让 Raw 承载主要信息，说明你应该考虑explainer或interactive-explainer。

结合 raw-policy.md 可以理解这一边界的执行细则：

Raw 是完整的 Web 平台，不是"画 SVG"。可以写任意 HTML / CSS / JS / React，选择标准只有一个："哪种媒介最能讲清这一段"——例如：

• 交互：拖动条 / 切换 / 折叠 / 步进器 / 计算器 / 小型可调模型；
• 布局排版：并排对比、时间线、卡片网格、分栏、引文大字；
• 动效：CSS transition /@keyframes/ 滚动揭示；
• 数据可视：HTML/CSS 条形与热度、<canvas>、需要时才用<svg>折线 / slopegraph；
• 嵌入与组合：表格 + 控件 + 文本拼成的一次性小工具。

自由但一致：用 token。Raw 内部的颜色 / 字体 / 间距必须取自主题变量（var(--ra-color-accent)、var(--ra-font-body)、var(--ra-space-4)…），这样每块都独一无二却又随主题切换。示例（来自 raw-policy.md）：

// 需要曲线时，才为这个数据点手画一条内联 SVG <Raw title="构建体积走势"> <svg viewBox="0 0 300 80" width="100%"> <polyline points={pts} fill="none" stroke="var(--ra-color-accent)" strokeWidth="2" /> </svg> </Raw>

禁止项包括：复杂表单、拖拽工作台、完整 dashboard、产品原型、和文章无关的动画、独立于主题的配色、复用固定小组件冒充自由表达。Raw 自检四问（raw-policy.md结尾）：

1. 这块 Raw 删掉后，文章理解是否会变差？
2. 它服务哪一个段落 / 论点？
3. 它是否使用--ra-*token？是否符合主题 md？
4. 它是否让文章更像应用？（如果是，砍掉或收敛成服务阅读的解释性视觉 / 排版）

在 longform 中，Raw 是给密集文本"节奏与呼吸"的手段，是点亮关键概念的局部增强，而不是信息的主要载体。

6. 配图与主题倾向：none/placeholders优先，tufte / knuth / press / bodoni

配图倾向

longform 的配图倾向为：

none/placeholders优先；技术 / 证据型可用真实数据图（tufte风）；叙事型可加少量press风氛围图。

这与 asset-policy.md 定义的四种配图来源（none/user-assets/placeholders/ai-generated）对应。注意一个关键正交关系：配图与 Raw 正交，不是二选一——Raw始终默认存在、照常使用；Image是否使用、用哪种来源由 Plan Checkpoint 的配图策略决定。选配图none只表示不用外部图片，Raw不受影响。

主题倾向

longform 的主题倾向（来自 article-types/longform.md）：

这与 SKILL.md 的默认策略一致："技术 / 证据优先tufte，叙事 / 评论优先press"。版式上，longform 默认配合regular阅读宽度（约 46rem）+ 开 TOC，见 layout.md 的宽度表。

7. 自检清单：longform 的验收口径

longform 自检（article-types/longform.md）包含五个问题，可以作为 Section Reviewer 与终审的引用依据：

1. 正文是否仍是绝对主体？没有把段落拆成卡片堆？
2. 章节衔接是否自然？读者读完一节会自然想读下一节？
3. Raw 是点亮关键概念还是打断阅读节奏？
4. 100% 信息是否读起来像被精修过的长文（而非原文搬运）？
5. 长文有没有TOC+Summary帮助读者定位？

从 review-checklist.md 可以看到这条清单如何落到质检流程中：Phase 5 的每个 Section 都要过 Section Reviewer（以消息返回 pass/fail，不写文件），检查"完成 outline 任务 / 符合信息保留比例 / 与前后衔接 / 不过度组件化 / 正文充足 / Raw 与配图有明确目的 / 本节序号自洽"；Phase 6 终审的 Technical Reviewer 还要核查章节序号全篇自洽（01 / 02 / 03 …连续单调，Subsection序号前缀对齐父Section）——这些在并行开发模式 B 下尤其容易出错，因为 subagent 看不到自己在全篇的位置。

8. 何时不要用 longform：类型路由的关键判据

longform 文档明确给出了四类"不要用"的判定，这正是 article-types.md 类型路由的实战判据：

选择 longform 的核心判据（article-types.md 选型提示）：源材料信息密度高、要完整归档 → longform。其它类型各有定位：tutorial是教学上手、review是工程审阅、essay是观点叙事、dialogue是对话整理、visual-essay是图文传播展示。

9. 在完整工作流中的位置：从 Phase 2 选型到 Phase 5 落地

longform 不是孤立的一个文档，它嵌在 beautiful-article 的 8 阶段 harness 流程中（SKILL.md）：

Phase 0 Intake → Phase 1 Source→Markdown → Phase 2 Editorial Planning → Phase 3 Plan Checkpoint（★必须停）→ Phase 4 First Spread → Phase 5 Full Article Build → Phase 6 Final Review → Phase 7 Repair → Phase 8 Delivery

longform 在其中的具体作用：

1. Phase 2：读article-types.md完成类型路由后，若选中 longform，就读article-types/longform.md拿结构 / 组件 / Raw 边界 / 配图倾向 / 自检，写入 plan-template.md 四段式plan/plan.md（Brief / Outline / Theme / Assets）。
2. Phase 3 Checkpoint 1：文章类型（含标配保留比例 100%）作为五个独立决策项之一让用户确认，且"比例已绑进类型选项，不再单独成题"——避免出现longform + 20%伪选项。
3. Phase 4 First Spread：首屏（Hero / Lead）写进article/Article.tsx，第一个 Section 写成独立组件article/sections/01-*.tsx。
4. Phase 5：按"一个 Section = 一个组件文件"铁律顺序或并行生成全部 Section，每节过 Section Reviewer。
5. Phase 8：构建为自包含单页article/article.html（CSS + JS 内联，断网可打开），这是主交付物；PDF 导出为可选（用户明确选择时运行bash <skill>/scripts/html-to-pdf.sh）。

整条流程的质检协议强调：Plan 自查用主 Agent 内联（禁开 SubAgent、不写文件），First Spread 与 Final 用 SubAgent 并写 review 文件，Section 用 SubAgent 但只以消息返回——这是 beautiful-article 的性能纪律，longform 作为默认类型同样遵守。

10. 落地建议：把 longform 用对的四个要点

综合以上全部内容，在 garden-skills 的 beautiful-article 技能下实践 longform 时，最值得记住的四条：

1. 确认源材料形态：连贯论证 / 叙事 / 综述 + 用户要原文级保留，才选 longform；否则按第 8 节的判据换类型。
2. 守 100% 信息保留：只删明显重复与无信息过场句，其余全部保留，但要用结构、组件与 Raw 把原文"精修"出网页文章的阅读节奏，而不是搬运。
3. 正文主体、组件点睛、Raw 增强：别拆卡片堆；Raw 只服务具体段落且用--ra-*token；一旦 Raw 开始承载主要信息，就考虑换explainer/interactive-explainer。
4. 长文必备定位手段：>10 小节或预估阅读 >15 分钟时开TOC，并给出Summary帮助读者定位；技术 / 证据型配tufte/knuth，叙事 / 综述型配press/bodoni。

若想继续深入，可对照阅读仓库中的 article-types.md（全部十种类型路由）、component-policy.md（组件协议与最小骨架）、raw-policy.md（Raw 允许 / 禁止 / 示例）、section-build.md（一节一文件与并行模式）以及 SKILL.md 的完整工作流，即可在任意一次"把长文做成网页文章"的任务中稳定复现 longform 的正确形态。

• 人工智能
• AI 技能/插件
• 提示工程