# Writing Shape

> Writing, exploit ： 将原始素材逐段塑形为一篇文章。

- Skill: `devcxl/writing-shape` (Agent Skill, multi-file: 2 files)
- Install (CLI): `npx skillmds@latest add devcxl/writing-shape`
- Raw SKILL.md: https://api.skillmd.com/api/skills/devcxl/writing-shape/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Security
- Author: devcxl (https://skillmd.com/u/devcxl)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/devcxl/writing-shape

---


<what-to-do>

用户已经传入（或即将传入）一份 markdown 格式的原始素材文件。将其视为输入材料堆：可以是从整洁的碎片列表到一团无结构的文字墙再到一份转录稿的任何形式。格式不重要。在做任何其他事情之前从头读到尾。

然后进行一次塑造环节，生成一份独立的文章文档。这是 **exploit（利用）**：探索已经完成，素材堆已经固定：承诺一个结构，然后开采素材堆来填充它。不要编辑原始素材文件：它对本技能而言是只读的。

如果用户没有说明文章保存到哪里，询问一次并记住路径。

</what-to-do>

<supporting-info>

## 循环流程

1. **阅读材料堆。** 通读整个输入文件。形成对其中内容的感知。
2. **设定先决条件。** 与用户确定读者进入时已经知道什么：那些从一开始就被**夯实（grounded）**的概念。其他所有概念必须被某个块夯实后，后续块才能使用它。参见[夯实（Grounding）](#夯实grounding)。
3. **起草 2–3 个候选开头。** 每个开头应暗示文章的不同论点或角度。全部展示出来。让用户必须选择或组合一个混合版本。被选定的开头决定了文章剩余部分必须完成的任务。
4. **逐块推进。** 开头确定后，问"给定这个开头，读者接下来需要听到什么？"从材料堆中提取内容来回答。下一个块只能依赖于已夯实的概念，并且随着落地同时夯实新概念。就下一个块的形式进行争论：段落、列表、表格、标注框、引用还是代码块。每一次格式选择都应该是有意为之且站得住脚的。
5. **随时追加到文章文件。** 不要攒在一起。每个达成一致的段落或块立即写入，让用户能看到文章逐渐成型。
6. **循环步骤 4 直到文章完成。** 由用户决定何时完成。

## 夯实（Grounding）

每个**概念**在被某个块使用之前必须被**夯实**：读者要么进入时就已了解它，要么在之前的块中遇到过它。一个触及未夯实概念的块会失去读者。单位是概念，而非词语：一个块可以依赖读者缺乏的想法，即使完全没有行话。当某个概念有名称：一个**术语（term）**：时，夯实意味着同时落地这个想法和它的术语。

概念通过两种方式之一被夯实：

- **先决条件（Prerequisite）**：在开头之前就被夯实。读者自带。在开始时固定。
- **引入（Introduced）**：某个块建立它，此后它对文章剩余部分都是已夯实的。

持续追踪当前已夯实的清单。当你问"读者接下来需要听到什么？"时，下一个动作需要的未夯实概念本身就是答案：先夯实它：在这里或在之前的块中：否则你无法做出该动作。这比[从材料堆中提取](#从材料堆中提取)的缺口命名高一个层级：那里是材料堆缺少素材；这里是文章缺少基础。

最大的杠杆在于你把什么设为先决条件，与你在文章内部夯实什么之间的取舍。要求太多前置知识会把读者挡在门外；在内部夯实太多又会让开头淹没在定义中。在设定先决条件时与用户商议这一点。

## 对话感

这是一个倒置的盘问环节。在构思时，问题是"你到底注意到了什么？"而这里的问题是"这篇文章到底在论证什么，以及读者需要以什么顺序来接收？"要顶回去。拒绝让薄弱的过渡蒙混过关。如果某一段不配占据那个位置，就砍掉。

持续使用的具体招数：

- "这段文字给读者提供了前一段没有提供的什么？"
- "如果我把这段删掉，什么会坏掉？"
- "这是散文，还是应该用列表？为什么是散文？"
- "这句话在同时做两件事：拆开还是只保留一件。"
- "开头承诺了 X。我们已经跑偏到了 Y。要么重新串联起来，要么修改开头。"

## 从材料堆中提取

将原始素材视为采石场，而非剧本。提取一个片段，改写以适配周围的段落，然后放入。一个片段可以被拆分到多个段落中、与另一个合并，或被转述。材料堆的任务是被开采；文章的任务是读起来像一个声音。

如果材料堆缺少文章需要的某些东西，明确指出缺口："这里需要一个例子，材料堆里没有：现在给我一个，否则我们砍掉这一节。"

## 真正要进行的格式争论

在选择如何呈现一个块时，与用户一起大声权衡以下取舍，而不是暗自决定：

- **散文 vs. 列表。** 散文承载论证；列表承载并列项目。如果项目不是真正并列的，散文更好。如果是并列的，列表更快扫描。
- **内联 vs. 标注框。** 提示、警告和题外话放进标注框（`> [!TIP]`、`> [!NOTE]`）：但仅限于它们真的会让主线论证跑偏的情况下。否则留在行内。
- **表格 vs. 重复结构。** 如果相同的结构以相同字段重复 3 次以上，用表格。否则用加粗引导句的散文。
- **引用 vs. 转述。** 当原文措辞本身有意义时引用。当只有想法重要时转述。
- **代码块 vs. 行内代码。** 多行、可运行或用于展示 → 代码块。单个 token 或标识符 → 行内。

## 写作节奏

每个块达成一致后就追加到文章文件。每次写入前从磁盘重新读取文件：用户可能在两轮之间编辑过。永远不要盲目覆盖。如果用户想重写某段，就地编辑该段；其余保持不变。

## 范围之外

- 挖掘不在材料堆中的新碎片（按"从材料堆中提取"处理缺口）。
- 编辑原始素材文件。
- 发布、针对特定平台格式化或添加用户未要求的 frontmatter。

</supporting-info>

