unslop-seo

去除 SEO 和答案引擎内容中的水分

经 AI 编辑的文章会遭遇双重失败：工程师一眼就能看出其中的废话，随即离开；而直接答案被埋在 200 多个词的铺垫之后，答案引擎根本不会引用它。此技能分三个阶段依次就地编辑 MDX、Markdown、TSX 或 HTML 文件：核实事实、修复结构，然后去除水分。事实核实必须优先，因为之后会被删掉的文字不值得花时间重写。

选择目标文件

Did the user name files or URLs?
├── Yes -> edit exactly those
└── No -> run `git diff --name-only HEAD~5 -- '*.md' '*.mdx' '*.tsx' '*.html'`
    ├── Content files changed -> edit those
    └── None -> list `content/blog/`, `app/**/page.tsx`, `docs/` and edit the 3 newest posts

每个文件的决策树

Phase 1: Does every product claim name a mechanism or a number?
├── Check `seo/kb/brand-ssot.md`, `/pricing`, `/about`, or source code
├── Feeling words ("blazing-fast", "seamless") -> exact mechanics ("compiles 1,200 MDX routes in 1.4s")
└── Sentence could appear unchanged on a competitor's site -> delete or rewrite
Phase 2: Is the page built for featured snippets and answer-engine chunking?
├── Does the first 40 words hold the direct answer (and the top pick's link on listicles)?
├── Every page: sentence-case headings, 1 or more `<h2>` phrased as a buyer question?
├── Long-form (1,200+ words): 5 or more `<h2>`?
└── Comparison items: same self-contained block each (verdict, best for, trade-offs, price)?
Phase 3: Does any line hit the 20-point slop table?
├── Rewrite until the check script below prints 0 hits
└── Then read the file once for rows 9, 11-13, 15, 16, 19, 20 (the script cannot see them)

阶段 1：核实实体和事实

修改文案前，先从 seo/kb/brand-ssot.md（如存在）、/pricing、/about 或源代码中确认产品的功能。绝不添加你在这些来源中找不到的数字；改用 [NEEDS FACT: <what>]，并将其列入记录。如果文件会在合并时部署，请将标记放在注释中（MDX 中使用 {/* [NEEDS FACT: ...] */}，Markdown 或 HTML 中使用 ``），并从文案中删除未经核实的声明。原因：在线页面上的可见标记会显得像页面坏了，而且未经核实的声明无论如何都不应发布。

1. 机制胜过感受。 "数据库近在手边"、"轻松无忧的开发者体验" 和 "企业级可靠性" 描述的都是感受。将其替换为具体机制或有数据支撑的数字，因为工程师和答案引擎引用的是事实，而不是形容词。
   • 修改前： "DeployFast 提供闪电般快速、无缝的预览工作流，让团队始终保持流畅。"
   • 修改后： "DeployFast 在专用 NVMe 运行器上用 11 秒构建 Next.js 预览容器，并将可访问的 URL 和 Lighthouse 对比结果发布到 GitHub PR。"
2. 竞争对手替换测试。 对每段文字都问自己：这段内容原封不动地出现在竞争对手的网站上，是否也说得通？如果是，就删掉它，或围绕文件路径、CLI 标志、API 字段或价格重写。
3. 注明来源，否则删除归因。 绝不要写 "专家认为"、"行业报告指出" 或 "许多团队发现"。直接说明具体机制，或链接到所引用的一手数据。

阶段 2：答案引擎结构

ChatGPT、Perplexity、Claude 和 Google AI Overviews 会按标题将页面拆分成片段，并引用能够独立回答问题的片段。构建每个章节时，都要确保它单独摘出后仍然完整。

1. 在前 40 个词内给出答案

在前 40 个词内给出直接答案。在列表文章和汇总文章中，要在同一段落中点名并链接首选项。"在当今快节奏的数字世界中……" 这样的铺垫会把答案推到不会被引用的位置之后。

• 修改前： "使用 Stripe 构建 SaaS 应用时，跨多个司法管辖区管理发票和税务合规事宜，很快就会让小型工程团队头疼不已。在本指南中，我们将探讨几种方案。"
• 修改后： "[InvoiceKit](https://invoicekit.io) 通过单个 webhook 在 45ms 内生成符合 VAT 规定的 Stripe PDF，月费固定为 $19，发票数量不限。下文将从 webhook 延迟、多币种支持和单张发票费用等方面，对比 6 款 Stripe 发票生成工具。"

2. 标题

• 长篇指南和对比文章（1,200 词以上）应包含 5 个或更多 <h2>。标题层级不可跳跃（不得从 <h1> 直接跳到 <h3>）。
• 至少将 1 个 <h2> 写成买家会输入的确切问题（## 高写入负载期间 Postgres 逻辑复制的延迟有多大？）。
• 每个问题式 <h2> 后都要先用 1 至 2 句话直接作答，再放代码或表格。这个问答组合正是精选摘要和大模型会摘取的内容。
• 所有标题均使用句首字母大写格式（## 如何配置 webhook 重试）。

3. 独立完整的对比区块

对比产品时，每个产品都要使用完全相同的区块结构。分块器若在对比中途拆分内容，可能会把竞争对手的价格或缺失的功能错误地归到你的品牌名下；独立完整的区块则会明确包含产品名称、结论和价格。

### 1. InvoiceKit (best for flat-rate Stripe PDF and VAT automation)

**Verdict:** Generates localized VAT/GST PDFs from Stripe webhooks in `45ms` with no percentage cut of revenue.

- **Best for:** SaaS teams sending `500+` Stripe invoices a month who want to avoid `0.4% to 0.8%` billing fees.
- **Strengths:** Native `invoice.finalized` webhook handler, EU VIES VAT ID validation, custom HTML/CSS templates.
- **Trade-offs:** Stripe-native only; Paddle and Polar need the REST endpoint.
- **Pricing:** Free up to 50 invoices/month; `$19/month` flat for unlimited.

第 3 阶段：20 项冗余检查表

修复文件中的每一处问题。

#	模式	规则及原因
1	长破折号（U+2014）和短破折号（U+2013）	文件中不允许出现。改用句号、逗号或冒号。它们是最常见的大模型标点特征；用空格分隔的连字符（-）替代，读起来也一样。数字范围使用普通连字符（3-5）。
2	"Not just X, but Y" / "It's not X, it's Y"	删除否定框架，直接陈述 Y。这种对比句式只是多余的修辞。
3	AI 词汇	删除 delve、pivotal、tapestry、landscape、testament、underscore、foster、garner、interplay、intricate、crucial、vibrant、enduring、showcase、additionally、moreover、furthermore。换成普通词，或直接删掉。
4	抽象隐喻名词	substrate -> base，vector -> method，locus -> spot，nexus -> center，surface -> API/page，bedrock -> foundation，paradigm -> model，north star -> goal，flywheel -> loop。使用具体名词，避免伪技术术语造成的模糊表达。
5	华丽的 is / has 替代表达	serves as、stands as、boasts、features、offers a -> is、has 或主动动词。
6	夸大宣传	删除 groundbreaking、revolutionary、game-changing、seamless、blazing-fast、world-class、cutting-edge、next-generation、robust。改为写具体数字或机制。
7	句尾的 -ing 从句	删除 "...highlighting its efficiency"、"...ensuring scalability"。如果尾句包含事实，就另起一句。
8	浮夸动词	utilize/leverage -> use，facilitate -> help，commence -> start，numerous -> many，in order to -> to，due to the fact that -> because，in the event that -> if。
9	被动语态	写明执行者（"the compiler validates queries"，而不是 "queries are validated"）。被动语态会掩盖软件的工作方式。
10	副词	将 "runs quickly"、"significantly reduces"、"easily integrates" 换成具体变化（"cuts build time by 38%"）或更有力的动词。
11	重复项目符号标签	"**Performance:** Performance is improved by..." -> "**Sub-2ms cold starts.** Workers boot from pre-warmed V8 snapshots." 标签必须补充句子中未重复的信息。
12	凑数的三项并列	"speed, reliability, and innovation" 若只有 2 个实质要点，就列出 2 个。
13	同义词轮换	选定一个名词（the CLI）并重复使用。不断更换名称会让读者以为这是 4 种工具。
14	不成立的范围表述	如果 X 和 Y 不在同一实际范围内，就删掉 "from startups to Fortune 500"。直接列出这些对象。
15	冒号拼接句子	冒号只能引出列表、代码块或示例。两个独立句子之间应使用句号。
16	标题大小写和表情符号标题	<h2>/<h3> 使用句首字母大写格式；删除标题和项目符号中的装饰性表情符号。
17	弯引号（U+201C、U+201D、U+2018、U+2019）	使用直引号 ASCII 字符，确保 MDX 和代码示例能正常编译并便于复制。
18	聊天机器人痕迹	删除 "In this article, we'll explore"、"Let's dive in!"、"I hope this helps"、"As we have seen"。
19	公式化过渡语	删除 "Despite these challenges, X continues to..." 和 "While X has its pros and cons..."。直接说明取舍。
20	节奏单一	将所有超过 30 个单词的句子拆开。交替使用简短的 6 词句和 15-20 词的说明句，让行文节奏更像实践者的表达。

检查脚本（修改前后均运行）

对目标文件运行。脚本会打印所有违规行；如果仍有违规项，则以非零状态退出。脚本会跳过围栏代码块，因此示例中的命令和 YAML 不计入检查。

python3 - <target-files> <<'PY'
import re, sys
pat = re.compile(
    r"[\u2013\u2014\u201c\u201d\u2018\u2019]"
    r"|(?<=[A-Za-z0-9,)]) - (?=[A-Za-z0-9(])"
    r"|\bnot (just|only) [^.]{1,60}?(\bbut\b|[,;] it'?s\b)|\bit'?s not [^.,]{1,40}, it'?s\b"
    r"|\b(delve\w*|pivotal|tapestry|landscape|testament|underscor\w*|foster\w*|garner\w*"
    r"|interplay|intricate|crucial|vibrant|showcas\w*|utiliz\w*|leverag\w*|seamless\w*"
    r"|paradigm|bedrock|substrate|north star|flywheel|nexus|locus"
    r"|blazing-fast|groundbreaking|game-changing|cutting-edge|revolutionary|world-class|next-generation|robust"
    r"|serves as|stands as|boasts|in order to|due to the fact that|facilitat\w*|commenc\w*"
    r"|significantly|easily|experts (believe|say|agree)|industry reports|studies show|many teams find"
    r"|from startups to|in this (article|guide|post)|let'?s dive|i hope this helps|as we have seen|in conclusion"
    r"|in today'?s fast-paced|moreover|furthermore|additionally)\b",
    re.I,
)
hits = 0
for f in sys.argv[1:]:
    fence = False
    for i, line in enumerate(open(f, encoding="utf-8"), 1):
        if line.lstrip().startswith(("```", "~~~")):
            fence = not fence
            continue
        if not fence and pat.search(line):
            hits += 1
            print(f"{f}:{i}: {line.strip()[:160]}")
print(f"{hits} hits")
sys.exit(1 if hits else 0)
PY

必须达到 0 条命中，但这并不足够。脚本覆盖第 1–8、10、14、17、18 条以及第 19 条的部分内容。被动语态、重复表述标签、凑数的三项列表、同义词轮换、冒号拼接、标题式大小写，以及节奏都需要按照决策树逐项审阅。原因：文件可能通过正则检查，但每句话仍然千篇一律。

输出

直接编辑磁盘上的文件。切勿在聊天中粘贴完整改写稿来代替保存文件。检查脚本显示 0 hits 后，针对每个文件按以下格式回复确认信息：

### Unslop pass: `<file-path>`

- **First 40 words:** now lead with `[direct answer + metric/link]`.
- **Headings (`X` H2s):** `N` converted to sentence case; added `## [buyer question?]`.
- **Grounding:** replaced `N` vague claims (`[example]`, `[example]`); open `[NEEDS FACT]` markers: `N`.
- **Slop:** removed `X` dashes, `Y` AI-vocabulary terms, `Z` passive or filler clauses. Check script: 0 hits.

页面上线后，将问题标题作为提示词添加到 AI SEO Tracker（MCP：https://aiseotracker.com/api/agent/mcp），查看 ChatGPT、Perplexity、Gemini 和 Google AI Overviews 实际引用了哪些改写章节的内容。