把任意素材，编辑成一篇值得分享的文章
你手里有一堆想分享的东西：一个讲得很好的网页、一份塞满干货的 PDF、一篇自己写的长文。可它们读起来累、发出去丑，别人点开就想关。beautiful-article 把这件事当”编辑活”来干 —— 先把素材读懂、拆解、重排，再设计成一份离线能打开、随手能分享的精美 HTML 文章。它的注意力永远在”文章”本身，而不是”网页”。
一分钟看懂
- 它是什么：一个编辑型 harness Skill —— 把任意素材编辑成比原文更易读、更好分享的精美文章。
- 为谁而做：手里有 URL / PDF / 长文、想做成可传播网页文章的开发者与创作者。
- 怎么用：一行
npx skills add装上，喂素材，它带你走完抽取 → 规划 → 生成 → 交付。 - 你说了算：3 个硬 checkpoint 逐项确认文章类型 / 主题 / 版式 / 配图 / 封面，AI 推荐但绝不替你静默做主。
- 交付什么：一份自包含的单文件 HTML（CSS + JS 内联，断网也能打开），可选导出 PDF。
01 · 它到底是什么
把一段素材丢给一个通用 AI，让它”做成网页”，你多半会拿到一个：能跑、但没人想读第二遍的页面 —— 信息按原样堆着，标题是加粗的第一句话，配色是模型的默认审美，读起来跟原文一样累，只是换了个壳。beautiful-article 想解决的正是这件事。
它把自己定位成一个编辑型 harness Skill：不是”套个模板生成网页”，而是像一位真正的编辑那样工作 —— 先把素材通读、理解，判断哪些是主干、哪些可以删，为它选一种合适的文章类型和视觉气质，再逐节写作、逐节校对，最后交付一份比原文更值得读的文章。所谓 harness，是说它不是一次性把活儿全干完，而是走一条有章法的流程，并在关键处停下来问你的意见。
它的第一性原理：首先是一篇文章。
注意力永远在”文章”本身 —— 更好的阅读、更好的节奏、更好的美学。交付物是一份自包含的 HTML 文件（可选 PDF），但那只是交付细节，不是目标。
这条原则听起来朴素，却决定了它和”网页生成器”的根本差别。下面这张对照，是同一份素材在两种思路下的不同命运：
换句话说，通用生成器给你的是”把文字放进网页”，beautiful-article 给你的是”把文字编辑成一篇文章，再顺手做成网页”。它做的减法和加法 —— 删掉旁枝、保住主干、补上视觉、控住节奏 —— 才是让成品”值得读”的地方。
02 · 六步工作流，与三次交给你拍板
beautiful-article 不是一次性把素材吐成网页，而是走一条小型 harness 流程。它把”写文章”这件事拆成六步：先把素材抽成统一的 Markdown，再形成编辑方案；确认之后先做出首屏样张定调，再逐节生成；最后终审、修复、交付。整条线里，有三个硬 checkpoint 必须停下来，把决定权交到你手里 —— AI 可以推荐，但绝不替你静默选择。
为什么非得停这三处？因为一篇文章的”编辑判断”只能由人来下：选什么类型、保留多少信息、用哪种版式气质、首屏调性对不对、最终交付什么格式。这三个暂停点，正是 beautiful-article 区别于普通生成器的关键。
上图把整条流程压缩成一条时间线。前两个步骤属于”编辑准备”：Source 把任意输入统一成 Markdown，Plan 决定这篇文章该怎么写、为谁写、删什么。接下来进入”双确认” —— 先确认方案，再做首屏样张给你看效果；你点头之后，才进入完整生成。终审与第三次确认保证交付物符合预期。
| Checkpoint | 确认内容 | 为什么必须停在这里 |
|---|---|---|
| Checkpoint 1 · 方案确认 | 文章类型（含信息保留比例）、主题、版式宽度、配图策略、封面。逐项独立确认，AI 推荐但不替用户选。 | 这些选择决定文章”怎么被读”：是 100% 归档长文，还是 50% 决策摘要？是书卷气的 press，还是海报感的 bayer？版式宽度和配图策略也必须在动笔前定调。 |
| Checkpoint 2 · 首屏验收 | 首屏样张（Hero + Lead + 第一节 + 一个代表性视觉块）的观感，以及后续开发模式：单 Agent 顺序推进，或多 Agent 并行生成。 | 首屏定下全篇的”视觉语气”。若此时不纠偏，后面每一节都会沿用错误基调。选择开发模式则是在质量与速度之间做权衡。 |
| Checkpoint 3 · 交付确认 | 导出 HTML（可选 PDF）作为最终交付物。 | 交付格式直接决定别人怎么使用：HTML 是自包含网页，可离线打开、随处分享；PDF 则适合打印与归档。需由人最终拍板。 |
注意，Checkpoint 1 的确认是逐项独立的，不是一张”总表让你打勾”。文章类型和保留比例、主题气质、版式宽度、配图策略、封面是否启用 —— 每一项都可以单独改。这种独立性防止了 AI 用”推荐方案”的名义悄悄替你做了打包决策。
流程背后的原则：把编辑判断权交给人。
beautiful-article 可以替你抽取、规划、写作、排版、修复，但它不能替你决定”这篇文章应该长什么样”。三个硬 checkpoint 不是流程装饰，而是把”你觉得对不对”这个环节真正嵌入到生成路径里。
说到底，这条流程的迷人之处在于：它把 AI 的生成能力当成一支高效的编辑团队，而把你当成主编。AI 做粗剪、做排版、做校对；你来拍板方向、气质和交付形态。
03 · 10 种文章类型：按你要的「精修程度」来选
上一节走完了六步流程。而流程里你要拍板的第一件事，既不是选颜色也不是排版式，而是先回答一个更根本的问题：这份素材，你想要多「精修」？ beautiful-article 把这个问题设计成了一个很省心的选择 —— 选一种文章类型。因为每一种类型，都自带一个推荐的信息保留比例，选了类型，就等于顺手定下了精修程度。这个设计避免了最常见的扯皮：你脑中「一篇好文章」的标准，终于和 AI 脑中的标准对齐了。
保留比例说的是：成品里保住了原素材多少信息量。它不是一把「删掉多少字」的裁纸刀，而是一位编辑的取舍尺度。100% 像一篇被精修过、但内容一句没少的长文 —— 只重排、不删减；而 40% 更像一篇被编辑认真删改过的文章，而不是一份缩水的摘要 —— 砍掉的是旁枝末节，留下的主干反而更立得住、更好读。比例越低，编辑的手就下得越重。
| 类型 | 推荐保留比例 | 适合场景 |
|---|---|---|
longform |
~100% | 完整长文 / 归档 |
tutorial ← 本文 |
~90% | 教学步骤 / 上手指南 |
full-report |
~80% | 研究报告 / 正式分析 |
explainer |
~80% | 概念 / 系统解释 |
dialogue |
~80% | 对话 / 访谈 / 播客 |
review |
~70% | PR / 方案 / 事故审阅 |
essay |
~70% | 观点 / 评论 / 叙事 |
briefing |
~50% | 决策摘要 / 给忙人看 |
visual-essay |
~40% | 图文为主 / 传播展示 |
interactive-explainer |
~25% 摘录 + 75% 重构 | 围绕核心知识点重构 |
把这张表沿着比例铺开，就是一条信息保留光谱：左端是几乎原样保留的长文，一路向右，编辑的手越下越重，成品越来越短、越来越精。
大多数类型落在光谱的中段：full-report、explainer、dialogue 都保留约 80%，review 与 essay 约 70% —— 够完整地承载论证，又替读者滤掉了原文的啰嗦。再往右，briefing 只留约 50%，专给没空读全文的忙人看；visual-essay 约 40%，让位给图和版式，主打传播。
光谱最右端的 interactive-explainer 是个特例，别被那个 25% 吓到：它不是把原文删掉了 75%，而是只摘录约 25% 的原文，再围绕核心知识点用 75% 的篇幅重新构建成一份可交互的解释。换句话说，别的类型是「保留多少」，它是「重写多少」—— 同一根尺子上，它衡量的其实是另一件事。
回到你手里这篇：它选的是 tutorial、保留约 **90%**。所以你读到的，是一份把原始 README 里关于 beautiful-article 的每个要点都保住、只做了重排与精修的上手指南 —— 这，正是 90% 该有的样子。
04 · 主题是一份契约，组件是一套语义
选完文章类型，接下来就是给文章选气质。beautiful-article 不让你在 CSS 里调颜色，而是提供11 套主题 authoring profile，每套都是一份给 Agent 看的 Markdown 契约 —— 它告诉 Agent 这篇文章该用什么语气、什么视觉节奏、Raw 该克制还是活泼、颜色该怎么用。你选的不是 CSS，而是一套”编辑共识”。
4.1 · Reacticle 组件协议：prose-first
所有文章都基于底层组件库 ConardLi/reacticle。它定义了一套语义组件协议：你写的不是 CSS 类名，而是”这是一段引言”、”这是一条警告”、”这是一张表”。
协议分三层。最底层是结构组件：Article、Hero、Lead、Section、TOC。中间层是语义组件：Aside（旁注/判断/警告）、Quote、Table、CodeBlock、Formula。最上面一层是 Raw：任意 HTML / CSS / JS / React 的自由层，可以写交互、自定义布局、动效、SVG / canvas 图解。
组件表达语义，不表达布局。
你不会说”蓝卡片 24px 边距”，而会说”这是一条 principle”。视觉长什么样由主题决定，你只管内容”是什么”。
Raw 是整个协议的”自由层”，但它不是乱写。两条铁律：第一，必须服务具体段落 —— 每块 Raw 都要回答”它让这一段更好理解了，还是只是为了好看”。第二，只能用主题 token —— 颜色、字体、间距必须走 --ra-* 变量，这样 Raw 才能随主题切换而不破相。
4.2 · 11 套主题：每套都是一种编辑气质
下面是全部 11 套主题。它们不是 11 种 CSS，而是 11 种”读这篇文章的方式”。例如：同样是讲数据，tufte 让你凑近读证据，press 请你从一臂之外读一本书，shannon 像在暗纸上看工程仪表。你正在读的这篇，用的就是 press。
| 主题 | 气质 |
|---|---|
tufte |
证据、数据、克制、低装饰 |
press |
书卷、编辑、叙事、温暖（本文所用） |
bayer |
包豪斯几何、三原色、响亮理性 |
bodoni |
报刊、Didone 高反差、戏剧黑白 |
vignelli |
瑞士国际主义、sans、网格、系统化 |
sottsass |
孟菲斯、80s 撞色、叛逆好玩 |
freddie |
暖黄、友善、机灵有人味 |
andy |
静谧、温柔、治愈、柔软奶油 |
fuller |
蓝图、工程制图、冷峻技术 |
knuth |
学术预印本、公式、严谨编号 |
shannon |
暗色工程证据、仪表信号、克制 |
为什么把”主题”设计成给 Agent 看的 Markdown 契约，而不是普通 CSS 文件？因为这里的关键读者不是浏览器，而是写文章的 Agent。它要先读懂”这套主题喜欢什么、禁止什么”，才能在每一节里做出一致的选择 —— 从正文节奏到 Raw 视觉，都围着同一套气质展开。
05 · 它的边界：一篇文章，不是一个应用
介绍一个工具时，光说它”能做什么”容易让人产生过高的期待。beautiful-article 的 Skill 文档用很大的篇幅划了一条清晰的边界线：它首先是一篇文章，最终主产物是一份单文件 HTML 文章，不是网页应用。
这个边界不是能力限制，而是目标声明。它的核心使命是”让阅读更好” —— 更好的节奏、更好的信息密度、更好的视觉秩序、更好的分享体验。只要还在服务这个目标，它可以非常灵活：允许 HTML/CSS/JS/React 的 Raw 自由层，允许交互控件、自定义排版、动效、SVG 图解。但这些自由层都必须服务于阅读、解释、论证、节奏或审美。
不做什么。
beautiful-article 不生成：后台、表单、拖拽工作台、完整 dashboard、产品原型、通用 Web App。如果你要的是这类产物，Skill 会停下来澄清，不会硬接。
为什么这条线很重要？因为”网页”是一个比”文章”宽得多的概念。一旦你把 beautiful-article 当成通用网页生成器，很快就会发现它不会替你设计后台、不会连数据库、不会做 CRUD 表单 —— 那不是它存在的理由。但反过来看，正因为目标窄，它才能把”把一篇文章做到极致”这件事做得更深。
另外一条隐性边界是信息密度由用户确认。默认它保留 100% 信息、生成长文式网页文章；但只要你选了 briefing 或 visual-essay，它就会按你确认的比例大刀阔斧地编辑。AI 不替你决定”该删多少”，而是在 Checkpoint 1 把这个问题交给你。
所以，判断 beautiful-article 适不适合你的最简单标准就是：你要的是不是”一篇更好读、更好分享的文章”？如果是，它大概率是对的；如果你要的是”一个能交互的工具”或”一个后台系统”，那它从一开始就会告诉你：这不属于本 Skill 的边界。
06 · 上手：一行装，喂素材就走
beautiful-article 属于 Garden Skills 集合，安装沿用整套 Skill 的通用方式。最快的一条路是社区标准的 skills CLI —— 它会自动识别你在用哪个 Agent（Claude Code / Cursor / Codex …），把 Skill 放到对的目录：
1 | # 一次装上整个 garden-skills 仓库 |
除了 CLI，还有另外四种安装方式：Claude Code 插件市场、GitHub Releases 里的钉版本 .zip（带 SHA-256 校验，适合 CI / 内网）、git clone 后手动拷贝、以及 Git Submodule。选哪种取决于你要”永远拿最新”还是”钉死某个版本”。
| Agent / Runtime | Skill 路径 |
|---|---|
| Claude Code | .claude/skills/<name>/ |
| Claude.ai（网页端） | Settings → Capabilities → Skills |
| Cursor | .agents/skills/<name>/ |
| Codex CLI | .codex/skills/<name>/ |
| Gemini CLI | extension manifest |
| OpenCode | .opencode/skills/<name>/ |
装好之后，用法非常朴素：把素材丢给它。可以是一个网页 URL、一份 PDF 或 DOCX、一段 Markdown、一大块粘贴的文字，甚至一张截图。它会先把素材抽成统一的 Markdown，然后带你走完前面讲过的那条流程 —— 规划、双确认、生成、终审，最后交付一份 article.html。
它会主动激活。
Skill 靠 SKILL.md 里的 description 与 Agent 达成契约。当你说出「把这篇做成网页文章」「生成一篇可分享的 HTML 长文」这类意图时，Agent 会自动判断该不该激活它，你不必记住任何咒语。
整个过程里，你唯一需要”上心”的就是三个 checkpoint 的几次拍板；其余的抽取、排版、写作、校对，都交给它。这也正是它想给你的体验：把素材交出去，把主编的判断留下来。
把素材交出去，把主编的判断留下来
回头看，beautiful-article 真正的巧思不在”能生成漂亮网页”，而在它把自己约束成一位编辑：先读懂素材，再按你选的类型和气质做取舍，最后交付一份自包含、可离线、可分享的文章。它把 AI 的生成力用在了粗剪、排版和校对上，把最重要的编辑判断权留给了你。
想试试的话，装上它，然后随手拿一篇你收藏很久却一直没读完的长文、或一份塞满干货的 PDF 喂给它 —— 看它能不能把那份”想分享却拿不出手”的素材，变成一篇你愿意转发的文章。
底层组件库在 github.com/ConardLi/reacticle，Skill 本体在 github.com/ConardLi/garden-skills。
Made with beautiful-article · press theme