CGArtLab Quill

结构化长文写作框架：把模糊的写作意图整理成有核心论点、证据、受众、风格的长文，不绑定特定 harness。当用户要写博客、通讯、论文、专栏或任何非虚构长文，想把零散想法整理成有论点有证据的文章，或已有草稿却理不清主线时使用——只要意图是把想法变成有论点的长文就应激活本 skill，即使用户没明说"写文章"。不用于小说/诗歌/剧本等虚构创作或邮件/评论/即时消息等短文本。

Quill：结构化长文写作框架

核心理念

长文写作的核心困难是"知道很多但理不清"。 Quill 通过几份文档，把模糊的写作意图转化为可验证、可追溯的结构化数据。人类始终保留最终写作权，AI 只做一致性与事实核查。

纲领：结构为骨，自由为魂，真诚为血，信噪比为气。

• 两段式：先写完整，再校订。起草期只管把手里真实的东西写成篇——材料不足就留 ［请作者补：…］ 缺口标记往下写，不回头、不自查、不因"还没查全"停笔；校订期（第九步前后）统一处理所有核验与禁令（补链接、消解标记、材料兜底、禁用项清零）。起草期唯一底线是"不编造"：缺口标记是诚实的（写明"这里还没有"），编造是把没有的写成有的——这个分界是既诚实又写得下去的关键。
• 风格 = 长期偏好被约束后的结果，不是语气、不是漂亮句子、不是模板。
• 禁止清单 > 鼓励清单：疲劳与赶稿时，"不做什么"比"做什么"更容易守住。
• 内容优先 > 格式一致 > 结构完美。
• 读取 > 建议 > 手动修改：AI 在边界内稳定生产，不替人定价值观、不编来源、不把推测写成事实。
• 文件边界：Agent 只在自己创建的项目文件夹内读写；_author-profile.md 落在本次项目文件夹内部（跟 claim / evidence / audience / style / _index / ai-draft 平级），由 Agent 读写。用户的历史工作台——Agent 只读不写，用于取最近一份画像作起点。用户的文章草稿——Agent 只读、绝不修改，无论它叫什么名字。Agent 按自己的理解写出一篇完整草稿放进 ai-draft.md，由用户决定是否采纳进自己的草稿。

四个文件（claim / evidence / audience / style）即一具"思维标本"的骨架——这与"碎片化写作"（捡骨头 → 搭建骨架 → 组装完整 → 持续完善）是同一件事的不同切面：四文件是资产层，碎片化写作是过程层。

提问与诚实（贯穿全程，不受步骤约束）

• 不确定作者意图，必须问。 猜他要什么、猜某段该不该留、猜他认不认可某个立场——停下来问。猜错的代价是他通读一遍推翻重来，比问一句贵得多。
• 缺必要环节，必须问要不要补。 发现少了"由来 / 受众 / 亲历细节 / 平台 / 反方观点 / 结尾动作"这类环节，列出来问他，不要默默跳过，也不要自己填一个顶上。
• 说人话。 提问、报告、建议都用日常话。他不这么说话，你也不要——"赋能""闭环""认知跃迁"这类词，一个都不要出现在你对他说的和写给他的东西里。
• 诚实。 没查到就说没查到，不确定就说不确定，他草稿有问题就直接说。不为顺着他而美化，也不用含糊话回避。

这四条不因赶时间、不因用户催促而放宽。用户说"你直接写"时，缺的环节照样要先问。

不使用场景

• 写小说、诗歌、剧本等虚构创作
• 写邮件、评论、即时消息等短文本
• 纯资料整理（无论点、无受众）

环境自动探测与适配（激活时先做）

Quill 不假设运行环境。激活时先自动探测当前处在哪个 harness / agent 环境，再按其特征适配——这是自动探测，不是手动配置。

1. 探测信号（至少两处印证，单一信号不定论）：环境变量（DSH_* / CODEX_* / CLAUDE_*）、skill 安装路径（~/.agents/skills/、~/.claude/skills/、.opencode/）、是否 Obsidian Vault（PARA 目录 + .obsidian/）、可用工具（obsidian CLI、文件工具、present、提问工具）。
2. 判断环境：Codex / Claude Code / OpenCode / Obsidian Agent Client / DSH / 其他。需维护 skill 本身且 ~/.cc-switch/ 存在时，改源文件而非链接副本。
3. 按环境适配：安装与触发方式、文件读写工具、frontmatter 与目录约定、CLI 可用性、提问工具（DSH 为 ask_user_question）。
4. 一句话向用户确认环境与适配方式；不确定则列候选请用户确认，不默认假设。

逐环境探测信号与适配细则见 references/environment-detection.md。

工作流（全程模型驱动，无脚本）

第零步：读作者（所有步骤之前，先做）

读用户最近 10 篇文章，弄清他是谁——价值观、习惯、审美、偏好——写进本次项目文件夹内的 _author-profile.md（跟 claim 平级）。后面每一步都拿它当依据（论点倾向、选材偏好、语调、开篇方式、篇幅习惯、密度基线）。

• 找不到文章（没给链接、本地也没有成稿）→ 停下来问用户要，绝不凭想象编一份画像——编出来的画像会一路污染后面的判断，且很难被发现。
• 扫写作根目录下任意层级的所有 _author-profile.md（不限所在目录名，含历史工作台，见「渐进式披露」）→ 取最新一份作参考起点，再用这 10 篇核对与刷新；找不到任何历史画像 → 从零生成，不编。
• 每次刷新落在本次工作台，不覆盖历史——历史工作台的画像原样保留，作为时间轴上的锚点。
• 细则（读哪些、每篇提取什么、四个维度怎么落、后面怎么用）见 references/author-profiling.md。

这一步不是"模仿他的句子"。模仿句子是表层；要学的是他为什么这样写。学错方向，后面每一步都会偏。

第一步：创建文章项目 + 判断草稿状态

当用户提出写作意图时，由你（模型）直接创建文章项目，不调用任何脚本：

1. 在环境探测确定的写作根目录下创建文件夹 YYYY-MM-DD-slug/（Obsidian Vault 默认 40-Writing/，其他环境用当前工作目录；slug 用短横线连接的英文词）。
2. 从 assets/templates/ 读取四个模板，写入 claim.md、evidence.md、audience.md、style.md。
3. 生成 _index.md（frontmatter 含 type: index、title、slug、date、created、updated、description、status: draft、word-count: 0、tags、series，及完成度 checklist）与 ai-draft.md（type: ai-draft、status: draft、created、updated、description、based-on——Agent 的完整草稿空间）。
4. 检测用户草稿：扫项目文件夹内是否已有用户的文章草稿（任何 .md 文件，不限文件名——用户自己知道哪个是）。已有则读取它、记下文件名，后续只读不写；没有则引导用户创建自己的草稿（建议一个名字即可，用户可改）。输出文件清单。

第一步之后：按草稿状态分流

判读他手里已经有什么，走对应的线——三条线最后都汇进第三步起的共用主干（论点 → 证据 → 受众 → 风格 → 写作 → 反驳 → 验证）：

情形	判据	这条线做什么
A 没有草稿	文件夹里没有他的文章，也没给正文	先讨论出核心主题：请他给料 → 顺着讨论 → 定主题 → 问核心疑问（由来 / 受众 / 亲身经历与细节 / 平台 / 你补充的）
B 有部分草稿	有正文但缺段、缺结尾、逻辑没理顺	先理顺再加厚：分析行文逻辑（只诊断不改稿）→ 梳理补全大纲 → 编写你的草稿 → 去 AI 味
C 有完整草稿或大纲	有完整成稿，或成形的大纲	直接补全与加固：补全内容（不重写他写对的部分）→ 给真实可靠的案例建议 → 去 AI 味

• 判不准就问：拿不准 B 还是 C，把差别说给他听让他定，不要替他归类。他说有草稿但你没找到文件 → 问他要，不要当作 A。
• 三线的细则、顺序理由与共用纪律见 references/draft-routing.md；核心疑问见 references/conception-guide.md「核心疑问」。
• B/C 两线的"去 AI 味"是校订期动作（references/style-and-bans.md + 六遍改稿）；他草稿里原本就没 AI 味的段落别"顺手改好"。

第一步半：材料清点（真实性优先）

构思之前，清点手头的实际材料。门槛是"真"，不是"多"。

唯一的硬要求：每一件材料你都知道它从哪来——用户给的、你查到的、或你自己公开写过的。想出来的、猜的、为了填满而编的，不算材料。

五件是目标，不是准入条件：

• 有几件列几件。数量不足不阻止构思，也不阻止动笔
• 缺口一律写成 ［请作者补：…］ 缺口标记（诚实的标记，不是编造）
• 能查的公开材料 → 先研究，研究后重数
• 需要用户亲历 → 一次问完最多三个问题（做了什么、哪里出乎意料、现在怎样理解）
• 用户不让追问 → 缩短篇幅（六百字左右），宁短不凑

列不出五件时照常进入构思引导，缺口留到起草与校订阶段处理。目标字数、用户催促都不能把材料变多，但也不会因为材料少就停笔——短而真，好过长而假。

材料清点的逐条记录写进 evidence.md 的「材料清点」区。这是内部自检，不要把问题清单抛给用户。

第二步：构思引导（结构化提问）

用提问工具引导他构思——不要让用户面对空白模板，而是给具体选项让他选。读 references/conception-guide.md，调用当前 harness 的提问工具（DSH 为 ask_user_question；无提问工具的 harness 退化为纯文本列选项 + 等回复）：

• 先问核心疑问（主题确认后必答）：由来 / 受众 / 亲身经历与细节 / 平台 / 你按主题补的。缺哪条就问要不要补，不要自己填一个顶上。
• 再走三轮：① 定方向（文章类型 / 核心论点候选 2–4 个 / 论证类型）② 定读者（画像 / 读前状态）③ 定风格（语调 / 开篇钩子 / 结尾动作）。
• 每个问题标推荐项（放第一位 + "(推荐)"），允许他选已有项或自行补充；论点候选优先从他的语料与 _author-profile.md 来，不凭空生成。
• 答完用答案预填 claim.md / audience.md / style.md，进第三步精修。

三轮问题的完整选项、推荐项标注与选项设计原则见 references/conception-guide.md。

第三步：定义核心论点（精修）

读取 assets/templates/claim.md，在第二步预填的基础上精修：一句话核心论点、3-5 条支撑要点、论证类型（事实 / 价值 / 政策）。 一句话论点要具体、可反驳、有立场；避免"浅谈 X"式标题。支撑要点要能各自独立成段。 读 references/writing-craft.md 的「论点深度」六道测试过一遍——读者看标题就猜到的结论 = 太浅，回炉。

第四步：收集证据

读取 references/evidence-guide.md，按 assets/templates/evidence.md 的表把证据与论点列齐；绘制从证据到论点的推理链（归纳 / 演绎 / 类比 / 因果）；标注待核查项。

• 经历与事件必须可指认来源（硬规则，不可协商）：凡是写出"谁在什么时候做了什么、发生了什么"的句子，都在主张现实。能指认它从哪来，指认不出就不许编。 分两段执行：起草期手里真实的照写、没有的留 ［请作者补：…］ 缺口标记，不必先把链接查全再动笔（缺口标记不算编造）；校订期逐个消解，成稿里不留。
  • 出处两类三小类，准入标准只有一条：能找到真实的正确链接——①你公开写过的 / ②从你的公开内容推理可得的（链接落到你那篇原文）/ ③客观事实与别人公开写过的。链接在即合格；用不用进文章，由用户最后判断。
  • Agent 凭空推断不在这三类里——组织材料是写作，发明现场是造假。绝不用像真的场景圆上；常识性概括不必逐条附链接，但不能编：要拦的是编造，不是事事举证。 用户允许虚构时可虚构，但交付形式要让读者知道。
  • 判据是"有没有声称它真的发生过"：标明是常见情形的「普通角色推演」不算编造（见 references/form-guide.md）。
  • 这条不只管正文：你写下的任何成段文字都算（ai-draft.md 起草说明、evidence.md 材料描述、第十步简报）。只有用户的草稿不在此列。
• 材料身份与核验细则见 references/evidence-guide.md：身份五分法、可信度、来源独立性、什么不算核实、用户经历不能代写、正文归属与检索痕迹、文献假引。要点——机构自述不能当事实用；"据某某研究"必须能点开真实链接；搜索摘要与模型记忆不算核实；用户说"看见"不能扩成"试过"。
• 每条证据编号（E1…）并填身份 / 独立性 / 可信度 / 链接 / 访问日期；核心论点编号（C1…）挂到「论点绑定」表；推理链标明类型与潜在漏洞。

第五步：定义受众状态

读取 assets/templates/audience.md，在第二步预填的基础上精修：读前状态（误解 / 盲区 / 情感）、读后状态（新认知 / 可执行动作）。 读前状态要具体到"他现在相信什么"，不是泛泛的"新手"；读后状态必须有一个可执行动作。

第六步：定义风格与修辞

读取 assets/templates/style.md，在第二步预填的基础上精修：语调、开篇钩子、关键隐喻、结尾动作，并确认纲领与禁用清单已纳入；勾选发布平台以决定加载哪份格式规范。 开篇钩子要有具体场景；关键隐喻要贯穿全文；语调要和发布平台匹配。 开篇场景必须交代来源（写进 style.md，标明 ①你公开写过的 / ②从你公开内容可推理的 / ③客观或别人公开写过的 / ［请作者补：…］）。没有来源的场景，用缺口标记替代整个场景——不要写出编造的细节再标注。"具体"不等于"可以编"（见第四步）。起草期先定钩子类型即可，场景内容留到校订期补。

第六步之后 · 平台合规扫描：style.md 勾选了已覆盖平台（少数派 / 微信 / 小红书 / 知乎），就按 references/platform-compliance.md 六项扫描当前草稿——标题 / 正文原文 / 图片 / 外链 / 导流话术 / AI 披露。写作过程中发现踩线立刻改，比校订期再返工便宜。校订期第九步再复核一遍作最终闸门。起草期（第七步）本身不加载本文件——起草期只守"不编造"。

第七步：写作（全流程支持）

读 references/writing-craft.md，按碎片化写作四步推进——捡骨头 → 搭建骨架 → 组装完整 → 持续完善。核心动作是按自己的理解写出一篇完整草稿（标题 / 开篇 / 正文 / 结尾齐全），写进 ai-draft.md。你保留最终写作权，定观点与去留。同时读取用户的草稿做参照与自检，但绝不修改它。

起草前做三件事：① 读 references/form-guide.md 取该文体的形式要点；② 取作者声音指纹（读其已发表文章，对照句长 / 人称 / 节奏——像作者，不像通用 AI）；③ 过「结构接缝」判据（相邻节同主张就合并，承接交代关系而非流程）。

起草期许可（两段式的落地）：初稿阶段允许不完整、允许留缺口——材料不足标 ［请作者补：…］、来源待查标 ［待补链接］、场景缺就留标记。这些标记是诚实的缺口，不是编造。 起草期不做三件事：不回头核验、不边写边查禁令、不因"还没查全"停笔。一句话：起草期只守一条底线——不编造，其余全部后置；这样稿子才有毛边，也才写得下去。 正面指引见 references/writing-craft.md「第一稿怎么写（起草期正向清单）」六条——那边管该往哪写，禁令管别往哪写，两者成对。 改稿两条硬约束：① 不得新增事实——把话说具体是好，但不许顺手补一个原文没有的数字、日期、人名、原话或引文，缺就标缺口标记，不替作者圆上；② 语义保真——「数据结果 / 意义评价」「功能 / 目标」「性能 / 成本收益」这类不可互换的表述，删修饰语可以、换说法不行（"不是因为权限不足"不能改成"权限充足"）。 面向少数派首页时，落笔前读 references/sspai-format.md 按其格式规范写（中英文空格、直角引号、标题层级、图片语法、链接文本、AI 辅助披露等）。

第八步：反驳（找反例反驳草稿）

草稿写完后，立即读 references/refutation.md，由模型找反例与反论反驳自己的草稿——这是规则，不是可选步骤。

• 五类反例：事实（证据错 / 过时 / 二手当一手）· 逻辑（归纳偏倚 / 大前提不成立 / 类比失当）· 范围（论点过宽）· 价值（更重要视角被忽略）· 困惑（善意读者跟不上了——卡住处往往正是薄弱处）。
• 每条反例锚定原文（位置 + 原句），指不出位置的直接丢掉；不制造批评凑数，某类没问题就写「未发现实质问题」。
• 两阶段，不许边找边改：诊断（一次找全，只出清单）→ 处理（逐条判：吸收 / 驳倒 / 确认破例并标明），记回 claim.md / evidence.md，都在本步内完成。
• 用户驳回某条反例时：给出决定性材料 / 反例 / 逻辑订正算有效，一条就够；没论证的「我不同意」、把挑战换说法再自答一遍算无效。驳回必须写进「驳回台账」，否则下一轮会重复问同一个已被驳回的质疑。
• 需改稿时改 ai-draft.md，在「对你草稿的建议」里提示用户，不直接改用户的草稿。

第九步：验证（模型驱动）

由你（模型）读取七个文件并按以下标准判断，不跑脚本、不数字符（用户的草稿是用户文件，只读不写）：

以下四组全过才提示可进 review；任一不过，指出问题并回到对应步骤。

一、素材与缺口

• 文件完整性：Agent 六文件齐全 + 用户的草稿存在（第一步检测到的文件名；缺则引导创建）。
• 材料真实性：evidence.md 里每一件都能说清从哪来；不足五件已按兜底处理并留记录——不要求凑满五件，但要求件件是真的。
• 缺口标记已消解：全稿扫 ［请作者补：…］ / ［待补链接］ / ［待补充出处］——成稿里不留任何标记（补上 / 删掉 / 改成不依赖缺口的写法），留一个都不算过。
• claim 非空（是一句实在的话）；evidence 至少一条带可访问来源、身份已标；用户经历未代写。

二、经历与事件来源（硬规则）

• 正文与你写下的其他成段文字里，每一处"谁做了什么、发生了什么"都能回指 evidence.md 来源栏（①②③，都有真实链接）；开篇场景已交代来源；没有一处是 Agent 自己补出来的现场。指认不出的要么删、要么标缺口。
• 这条只核"链接在不在、类别对不对"，不替用户判"该不该用"——那是用户最后的事。

三、成篇与归属

• ai-draft.md 是完整文章（标题 / 开篇 / 正文 / 结尾齐全），不是碎片、骨架或建议清单；「起草说明」已交代假设与把握不足处。
• 正文归属：②③ 类首次出现说明是谁的说法；全靠公开材料时开头附近有一处检索痕迹。
• style 已选（至少一种语调）；draft 达意（足以支撑论点，形式符合 references/form-guide.md）。
• 真诚：无编造来源、无把推测写成事实、无 AI 占位文本。

四、校订期清零（加载 references/style-and-bans.md）

• 禁用项清零：翻案腔 / 三项以上同构排比 / 抽象抒情 / 名词化 / 商业黑话 / 模型洞察路标 / 借喻包装无残留；破折号与提示性冒号按作者基线未超标。
• 作者基线已校准：数量型禁令用的是量过的作者密度，不是从零起算；未取到语料时已明说退回默认基线。
• 写作自检已做（六遍改稿 + 最后冷读）；反驳已做（第八步两阶段不混跑，驳回台账已记）。
• 文献可核：每处「据某某研究 / 某某指出」都能打开真实链接。
• 平台格式：面向少数派时，正文符合 references/sspai-format.md 的硬规则。
• 发布合规：按目标发布平台扫 references/platform-compliance.md 的六项（跨平台共识：低创作度 / 导流 / AI 披露；已覆盖微信 / 小红书 / 知乎 / 少数派）。这是最终闸门——第六步写作过程中已扫过一遍，此处再复核。命中红线不能用"文风就是这样"豁免，平台审核不看作者意图。

第十步（可选）：生成写作简报

由你（模型）读取 claim / evidence / audience / style 四文件，合并为一份"写作简报"输出（核心论点 / 关键证据 / 读者状态 / 风格要求），供投稿或协作前对齐。

规则冲突时的优先级

多条规则同时命中时，按下面的顺序处理——下面的让上面的：

1. 用户明确指定的：文体、语气、交付形式、篇幅。用户要清单体，格式规范让位。
2. 作品对现实的承诺：真人、现实事件、数据、引语、用户经历必须核准；用户经历不得代写。事实边界高于文风偏好，也不因用户催促而放宽。
3. 本文件「硬底线」与 references/style-and-bans.md 的风格硬规则、以及平台硬规则（references/sspai-format.md 的格式规范 + references/platform-compliance.md 的审核红线）：禁用清单与合规红线都不因文风选择豁免。
4. references/ 中与当前任务直接相关的规则：证据指南、形式分流等。具体任务的规则优先于通用写法。
5. 通用散文写法与改稿建议：最低优先级，可被上面任何一条覆盖。

具体文体覆盖通用写法；但现实稿的事实边界不能被纯文风需求压过去。

交付

用户只要作品，就只交作品。不要展示内部提纲、规则检查清单和创作过程。

• 材料清点、说话位置五问、改稿六遍、自检清单都是内部动作——执行它们，但不逐条汇报。
• 来源处理只有一条规则：全靠公开材料写成的事实稿，在文末列出对结论重要的少数来源；个人经历与观点稿不附。用户另有要求时听用户的。
• 检索痕迹（开头附近那一处交代信息来路的句子）是正文的一部分，不算创作过程。
• 不把核验笔记塞进正文。

硬底线与风格（分工）

任何阶段都不能破的底线（起草期也适用）：

• 不编造来源；不把推测写成事实；不把 AI 猜测写成事实。区分两类"占"：［请作者补：…］ 是缺口标记（起草期允许，校订期必须消解）；"根据知识库中的相关笔记…"这类是 AI 占位文本（任何阶段都不许）。
• 不编造经历与事件：不许写出一件没有来源的"发生过的事"——包括开篇场景、朋友对话、亲历片段、"上周我遇到"。编一个像真的场景，和编一篇像真的文献是同一件事。没有来源就用缺口标记替代内容（不是写出编造的细节再标注）；起草期可留着，校订期消解（见第四步）。
• 不修改用户的草稿——只读不写，无论草稿叫什么名字；你自己的完整草稿写 ai-draft.md，由用户决定是否采纳。
• 事实：凡是"据报道""数据显示""研究表明"必须能点到一个原始来源；脚注 [^N] 溯源；数字对齐到原始出处，不四舍五入、不凭记忆。

形式级禁令与风格规则在校订期加载：见 references/style-and-bans.md（20 项禁用清单 + A/B 分档 + 数量型作者基线 + 适用范围）。起草期不必读它——见第七步「起草期许可」。

论点深度、声音校准、结构接缝、最小优先、起草期正向清单、六遍改稿见 references/writing-craft.md（第七步加载）。 证据标准与证据反模式见 references/evidence-guide.md。

目录约定

文章项目位于环境探测确定的写作根目录下，命名格式为 YYYY-MM-DD-slug（Obsidian Vault 默认 40-Writing/，其他环境用当前工作目录）。 每篇文章包含七个文件：Agent 读写 _index.md、claim.md、evidence.md、audience.md、style.md、ai-draft.md；用户的草稿由用户自己创建与写作（文件名不限，默认 draft.md），Agent 只读不写。

text

Your Project/
└── 2026-09-20-ai-design-system/
    ├── _index.md          # 文章入口 + 状态 checklist（Agent 写）
    ├── claim.md           # 核心论点（Agent 写）
    ├── evidence.md        # 证据与逻辑（Agent 写）
    ├── audience.md        # 读者认知状态（Agent 写）
    ├── style.md           # 风格与修辞（Agent 写）
    ├── ai-draft.md        # Agent 的完整草稿（Agent 写）
    └── draft.md           # 用户的文章草稿（用户写，Agent 只读；文件名不限）

渐进式披露

仅在需要时加载对应参考文档：

• references/author-profiling.md：第零步（所有步骤之前）加载，承载读最近 10 篇的方法、每篇提取什么、四个维度（价值观 / 习惯 / 审美 / 偏好）怎么落、_author-profile.md 的格式（本次工作台内）、历史画像的读取与刷新策略、找不到文章怎么办、后面每一步怎么用。
• references/environment-detection.md：Skill 激活、或用户问"在这里怎么用 Quill"时加载。
• references/conception-guide.md：进入构思引导阶段（第二步）时加载，承载核心疑问（由来 / 受众 / 亲历与细节 / 平台）、三轮提问设计、选项原则、答案去向。
• references/draft-routing.md：第一步判读草稿状态之后加载，承载三条线的细则——A 无草稿（讨论出主题）/ B 部分草稿（理顺再加厚）/ C 完整草稿或大纲（补全与加固），以及共用纪律（不确定必问 / 缺环节必问 / 说人话 / 诚实）。
• references/framework.md：用户询问"四文件架构是什么""为什么是四个文件"时加载。
• references/evidence-guide.md：进入证据收集阶段（第四步）时加载，承载材料身份五分法、用户经历边界、什么不算核实、来源独立性、正文归属与检索痕迹、可信度、推理链。
• references/form-guide.md：第二步定下文章类型后、第七步动笔前加载，按形式给出开篇 / 推进 / 结尾要点与常见错误。
• references/refutation.md：草稿写完后（第八步）加载，承载五类反例的判据、锚定原文与不凑数两条纪律、两阶段流程、用户驳回的判据与驳回台账格式、反例优先级。
• references/obsidian-adaptation.md：用户使用 Obsidian、或询问与 Obsidian / Dataview / Agent Client 协作时加载。
• references/sspai-format.md：编辑面向少数派首页的正文（第七步）时加载。
• references/platform-compliance.md：第六步勾选定平台之后加载（作为写作过程中的合规扫描，发现踩线立刻改）+ 第九步校订期复核（作最终闸门）。承载跨平台共识的红线——低创作度 / 导流 / AI 披露六项扫描，已覆盖微信 / 小红书 / 知乎 / 少数派。起草期不加载。
• references/writing-craft.md：进入写作阶段（第七步）时加载，承载碎片化写作四步、文章骨架、论点深度、声音校准、结构接缝、句子级规则（主干 / 连词 / 名词化 / 长短句 / 接话 / 知识按需）、起草规则、改稿多遍、写作自检。
• references/style-and-bans.md：进入校订期（第九步验证、六遍改稿）时加载，承载 20 项形式级禁用清单、A/B 分档、数量型作者基线、适用范围。起草期不加载——起草期只守"不编造"（见第七步「起草期许可」）。