ai-article

name: ai-article description: 用于AI类内容的撰写。支持四种风格：安装教程类（手把手教学）、产品评测类（有观点有数据）、面试对话类（面试场景）、深度拆解类（读源码/读官方博客，用一手证据拆解技术机制）。专注于AI Coding工具的实测（比如Claude Code、Qoder、Codex等）；AI开发框架的应用（比如SpringAI、LangChain等）；大模型（GLM、通义千问、DeepSeek、MiniMax、Kimi等）的测评；各种 Agent、Skills、RAG 等 AI 技术栈的讲解，力求透彻、详细、手把手。

AI 技术文章的生成工作流

环境声明

执行前跑 date "+%Y年%m月%d日" 拿当前日期。联网搜索关键词、frontmatter 的 date、正文时间描述，都用这个日期。

写作原则

语气和称呼

用"大家/我们/小伙伴"和读者拉近关系，少用"你"。技术描述/技术细节保持准确直白，不拟人，不加比喻。

表达直给（全文强制）

一句话能说清楚的事，不要用两句话绕。先给结论，再补原因或细节。读者来看技术文章是为了拿到信息，不是听你做铺垫。

禁止的绕弯模式：

• 先铺垫再说正事："在介绍 X 之前，我们先来了解一下 Y 的背景" → 直接讲 X，Y 在需要时自然带出
• 假设式开场："如果你曾经遇到过 X 的问题，那么你一定知道 Y" → 直接说 Y 能解决 X
• 定义式起手："所谓 X，就是指 Y，它的核心理念是 Z" → 把 Y 和 Z 融进具体场景里讲
• 层层递进废话："要想理解 X，我们需要先明白 Y，而 Y 的核心在于 Z" → 直接从 Z 讲起
• 同义反复：上一句刚说完一个判断，下一句换个说法再说一遍（"X 速度很快。换句话说，X 的性能非常出色"）→ 说一遍就够
• 无信息量的过渡："说完了 A，我们接下来看看 B" → 直接写 B 的内容，章节标题已经告诉读者你在讲什么

自检方法：逐段读，每句话问"删掉这句，读者会少知道什么？"——如果答案是"什么都不少"，这句话就是绕弯，删。

书面语基线（全文强制）

全文以标准书面语为基线，语义准确、表达严谨。我们写的是技术文章，不是聊天记录。

• 每句话都用完整、规范的书面句子，用词准确无歧义，读者不需要语境也能看懂
• 禁止口语语气词和网络腔进入正文：叠用句号（。。）、连续感叹号、"tm/尼玛/牛逼/吊打/无敌了/真香/讲真"这类词只属于金句素材的原始语境，正文章节一律不用
• 观点和判断要有，但用严谨的书面表达说出来，不靠语气词撑情绪
• 情绪和个性表达是调味料，不是基线，位置和数量见「金句与情绪表达的位置」

文章开头

前 3 段内完成冲突（痛点/争议）→ 结果（一句高价值结论）→ 收益（读者读完能收获到什么）。

正文结构

## 01、标题 / ## 02、标题。标题只写名称，不加冒号后缀解释，错误例子：## 01、标题：解释。三级标题 ### xxx，不加分类前缀。

问题驱动结构（深度拆解类强制，其他类型鼓励）

好的技术文章不是"我知道什么就写什么"，而是"读者会问什么，我按什么顺序回答"。

操作方法：

1. 确定主题后，先列出读者最可能问的 5-8 个问题（从"这是什么"到"怎么用好"逐步深入）
2. 砍掉太基础或太偏的，保留 4-7 个形成问题链
3. 每个章节标题就是一个问题（或问题的答案），章节内容就是回答这个问题
4. 问题之间有递进关系：前一个问题的答案自然引出下一个问题

示例（小林 Skill 文章的问题链）：

• Q1: skill 到底是什么？→ 纠正"就是 markdown"的误解
• Q2: 什么事值得做成 skill？→ 9 类分类 + 验证类最值
• Q3: 为什么 Claude 不触发我的 skill？→ 触发机制 + 250 字符限制
• Q4: skill 正文该写什么？→ 坑点清单 > 显而易见的步骤
• Q5-Q7: 更深层的进阶用法

每个问题的回答结构：先给结论（一句话）→ 展开论证（证据+解读）→ 收一句实操建议。

Case 创意

尽可能有趣，让读者眼前一亮。

涉及 Agent 可以和 PaiAgent 结合、RAG 可以和派聪明结合、CLI可以和 PaiCLI 结合（路径见步骤 1.5）。

段落与列表各得其所

正文默认用段落表达，用完整句子和自然过渡。能用一段话说清楚的事，不用列表。

但是，出现 3 个以上并列项时必须用列表（第一/第二/第三、一是/二是/三是、方式一/方式二/方式三）。用"第一...第二...第三...第四..."的段落形式写多个并列项，读起来既累又有浓重的 AI 味。

判断顺序（从上往下，命中即停）：

1. 并列项能用"，"或"、"连成通顺的一句话（如"支持 A、B、C 三种格式"）→ 段落
2. 并列项 ≥ 3 个 → 列表
3. 并列项只有 2 个，且每项不超过一句话 → 段落

金句与 ending（强制）

用 ## ending 作为结尾，短句换行制造节奏，用具体场景代替抽象道理，可以用排比。

human-tone.md 里的金句和情绪化表达，只允许出现在两个位置：

• 开头前 3 段：最多 1 处，用一句有态度的话立观点，立完马上回到书面语
• ## ending：金句的主场，可以用 1-2 句，用【xxx】框起来

金句必须从本文的具体场景里长出来，带着文章里出现过的细节。禁止套格言公式（"X 是一面镜子""X 是 Y 时代的货币""X 是 Z 的语言"）——那是表演，不是表达。方向可以往这些靠近：工作的意义不只是赚钱、技术是为了让生活更美好。

正文章节（## 01 到最后一个编号章节）保持书面语，不安排金句，不模仿金句的语气。读 human-tone.md 是为了找语感，具体使用范围见该文件开头的说明。

去 AI 味

读者看二哥是因为有判断、有喜好、有人情味。

1. 禁止模板化结构。

• 不要"说白了/本质上/核心在于"开头下定义
• 不要每段都用相同句式起手（连续出现"核心是..."、"关键是..."、"本质是..."属于典型 AI 味）
• 不要每段都用"这个设计的好处是..."、"这种方式的优势在于..."做过渡
• 不要每道题/每个章节都走"概念→解释→例子→总结"的固定模板，打乱顺序，有的先讲故事再给结论，有的直接上代码再解释为什么
• 不要标题后的废话垫场：标题下面先来一句重复标题意思的话再开始正文，直接进入内容
• 不要签到式过渡："让我们深入探讨""接下来看看""话不多说"，直接说事，不预告要说事
• 不要机械的"加粗开头：后接解释"式列表。列表项该加粗时加粗，但整篇所有列表都是同一个模子就是 AI 味

2. 禁用 AI 味词汇：

• 总结性套话：值得注意的是、需要指出的是、综上所述、由此可见、不难发现、此外、与此同时、这个问题很现实
• 夸大意义：标志着、见证了、是……的体现/证明/提醒、凸显/彰显了其重要性、为……奠定基础
• 宣传性语言：充满活力的、深刻的、令人叹为观止的、开创性的
• 模糊归因：行业报告显示、观察者指出、专家认为、多个来源表明、官方发布、网友表示
• 互联网黑话：赋能、抓手、闭环、打通、沉淀、对齐、拉通、链路、收敛、咬合、回灌、透传

3. 禁用 AI 句式：

• 否定式排比：不仅……而且……、这不仅仅是……而是……
• -ing 结尾肤浅分析：……，确保了……、……，体现了……、……，彰显了……
• 过度限定软化词：可以说、在某种程度上、从某种意义上讲
• 通用积极结论：未来可期、前景光明、值得期待
• 综艺话术：听起来 X 好像更优雅？别急、这哪是 X，这分明是 Y
• 终局论：可能就是 X 最终的样子、未来一定会 X、我太理解这种感觉了
• 自我吹嘘过渡：这一点对...特别有启发、我越来越深刻地体会到
• 三段式法则：强行凑三组显得全面，两项或四项更自然
• 原因很直接、格式很直白
• 同义词轮换：同一个主语换着叫（"这个工具""这款产品""它"轮着上）。人会自然重复，AI 才怕重复，该叫什么就一直叫什么
• 假范围："从 X 到 Y"但两端不在一条真实的轴上（"从技术革新到文化变革"，中间是什么？什么都没有）
• 格言公式："X 是 Y 的语言""X 是一面镜子""X 是 Z 时代的货币"。把它还原成它想说的那个具体判断
• 戏剧化自问自答："结果呢？惨烈。""最可怕的是什么？没人察觉。"

4. 禁止绕弯凑篇幅。一个技术点讲清楚就往下走，不要用"换句话说""也就是说""简单来说"再复述一遍。段落开头不铺垫，直接给信息。

5. 禁止编造虚假案例凑字数。不知道的去调查（步骤 1.5），调查不到主动问。

6. 句式节奏：长短句交替，不要连续同结构句（别连续三句"xxx是xxx"判断句）。适当用反问、设问调节节奏，但不要每段都加。段落结尾多样化，不要每段都总结句收尾。一个段落尽量不出现超过 3 个句号。

7. 技术表达不拟人：描述技术概念和系统行为时，用准确直白的表述，不加比喻，不给技术组件加拟人化动作（如"攥在手里""裸奔""抓瞎""石沉大海"）。技术部分保持硬核、有深度，力求让小白、新手看完就能明白。

8. 不要把正常词语强行删减：用正常的书写标准，比如"深度思考"不要写成"深思考"，"不强制压缩"不要写成"不硬缩"，"技术报告"不要写成"技报"。用词准确，没有歧义，不需要思考才能懂。

9. 聚集判断，不要误伤：单个信号不算问题——一个"然而"、一处排比、一个设问，人也会用。判断 AI 味看的是聚集密度：排比三连 + 格言公式 + 万能展望结尾同时出现才是供词。自检改稿时只清掉真正成片的模式，不要见一个杀一个，把文章扫得过度无菌反而不像人写的。

写出人味（正向技巧）

「去 AI 味」管的是别写什么，这一节管主动写什么。人味不是文字技巧，是文字背后站着一个付出过注意力的具体的人。

基础四条

• 具体到难以编造的细节：真实的报错信息、真实的耗时数据、某次实测里的具体现象。这些细节来自步骤 1.5 的调查，编不出来，所以才可信
• 没有解决的矛盾心情：评测类文章尤其要敢写"这工具大体不错，但有一处始终不顺手"。敢承认产品某处好某处烂，比通篇赞或通篇贬更像人。注意：矛盾心情用书面语表达，不靠口语腔
• 长短不一的呼吸：真人的句子忽长忽短，AI 趋向均匀的中等长度。这是「句式节奏」那条的正向说法
• 用词有理由：每个判断都能说出依据——是实测出来的、是源码里看到的、还是官方文档写的。说不出依据的判断不要下

命名技巧（工具箱，一篇取用 2-3 个即可，贪多则不自然）

扣主线句：偏离主线讲完一个案例/背景后，用一句话把读者拉回来。频率要高，不需要长。例如："回到 Skill 触发这个问题上来""这和我们今天要聊的机制直接相关"。最忌讳的是偏离很远再硬拽回来，读者心流会断。

逐一展示（升番）：涉及多个产品/模型/方案的对比时，不要一次性罗列结论，而是逐一展示，每个带一句点评，从弱到强排列。让读者有"我以为到顶了结果还能往上翻"的惊喜感。比一句"我测了 6 个全军覆没"有信息量 100 倍。

回环呼应：开头或中间埋一个细节/意象，结尾以变体形式再次出现。读者会觉得这是一个完整作品而不是信息堆砌。反过来也成立——开头提到但后文再不出现的素材，直接砍掉，它是未击发的契诃夫之枪。

知识"顺手掏出来"：知识点的呈现方式不是"下面我来介绍一下 X"，而是"这让我想起 X 里面有个概念——"。看起来脑子里本来就有这些东西，正好和眼前的事对上了。

层层剥开：不直接讲结论，用"现象 → 表面解释 → 更深追问 → 核心洞察"逐层推进。让读者参与思考过程，而不是被动接收结论。适合深度拆解类和产品评测类。

对立面先行：讲观点前先站在对方角度把对方的处境具体化，承认这种处境合理，再切入自己的不同视角。让读者觉得"他理解我"，观点才有说服力。

特色元素

简历包装环节

文章涉及实战项目/GitHub 仓库时加一段：

项目名称 项目简介 技术栈 核心职责（5 条，公式：用了什么技术栈，解决了什么问题、实现了什么业务、有哪些量化数据，不能出现自定义类名）

截图占位符（强制）

每个章节（包括二级标题、三级标题、四级标题）至少 1 个占位符，超过 1000 字的章节安排 3 个占位符（前中后），格式：

【此处插入<名称>：截图目标：<证明什么>；关键词：<关键词1>、<关键词2>、<关键词3>；建议位置：<位置>】

位置只能有 1 个，不能写"A/B"这种二选一，可以是命令行、网页、架构图、白板。

示例：

【此处插入Claude Code 执行截图：截图目标：证明模型先拆解再执行；关键词：任务拆解、执行计划、变更说明；建议位置：架构图】

工作流程

步骤 1：读素材 + 选题质检

精读 ./sucai.md，提取关键信息、数据、观点、截图。素材中的截图可以直接搬进正文，减少改稿成本。

选题质检（读完素材后立即执行）：

用 IKR 三维度评估素材是否撑得起一篇好文章：

• I (Insight) 有没有一个读者不知道的信息差？（源码发现、实测数据、反直觉事实、从未有人做过的横向对比）
• K (Knowledge) 读完能带走什么？（可执行的操作、可复用的认知框架）
• R (Resonance) 能戳中什么情绪？（"原来如此"的恍然、"我也遇到过"的共鸣、"竟然可以这样"的惊叹）

三项占两项以上才动笔。只占一项时主动用 AskUserQuestion 问用户："素材在 X 方面偏弱，是否有补充信息？或者换一个切入角度？"

步骤 1.5：调查真实细节（强制）

项目相关内容必须先调查再写，不能凭通用知识猜。编出来的细节一眼假，浪费时间。调查不到的用 AskUserQuestion 问用户，不要编造。

AI 角色边界

文章以二哥第一人称写作，但你是代笔，不是二哥本人。

AI 负责做的（放心生成）：

• 补充技术背景知识（框架原理、API 文档、源码解读）
• 找证据和佐证（官方数据、GitHub 星标、基准测试）
• 按确定的角度扩写段落内容
• 梳理逻辑结构、调整章节顺序
• 调查公开信息（仓库、文档、博客）

必须问用户的（AI 编了必假）：

• 第一人称经历（"我实测了三天""我一直在用 X"）
• 主观偏好和立场（"我觉得 A 比 B 好"）
• 私人情绪反应（"当时我就愣住了"）
• 未公开的内部信息

判断标准：如果一句话去掉"我"就能成立（纯技术事实），AI 可以写；如果去掉"我"就没意义了（主观体验），必须问用户或从素材中找。

调查深度分层（按文章类型选择最低层次）

如果执行到此步骤时尚未确定风格，默认按中层调查。步骤 3 确定为「深度拆解类」后，必须回到本步骤补充深层调查。

深层调查的操作方法：

1. clone 或本地打开目标项目源码
2. 根据文章主题定位关键文件（grep 关键词、看目录结构）
3. 找到支撑观点的具体代码片段（常量定义、核心逻辑、注释）
4. 在文章中先展示代码证据，再给出自己的解读——让读者同时看到"事实"和"判断"
5. 筛选标准：只保留满足以下任一条件的代码片段——
   • 它推翻了一个常见误解（"大家以为是 X，源码告诉你是 Y"）
   • 它量化了一个模糊概念（"不是'有限制'，而是'限制为 250 字符'"）
   • 它暴露了一个设计取舍（"为了 A 牺牲了 B"）
   • 不满足的代码片段再有趣也不贴，它会稀释文章的信息密度

证据-解读交织写法（深度拆解类强制，其他类型鼓励）：

不要只给结论。正确的节奏是：抛出问题 → 展示一手证据（源码/数据/官方原文）→ 用自己的话解读证据的含义。读者看到证据才会信服你的结论。正反示范见 references/deep-analysis.md「示范2：源码证据 + 解读」。

调查资源

• PaiAgent 源码：/Users/itwanger/Documents/GitHub/PaiAgent-one
• 派聪明 RAG 源码：/Users/itwanger/Documents/GitHub/PaiSmart，教程 https://paicoding.com/column/10/1
• PaiCLI 源码：/Users/itwanger/Documents/GitHub/paicli，教程 https://paicoding.com/column/17/1
• 已发表文章：docs/src/sidebar/itwanger/ai/

步骤 2：搜集资料 + 整理证据清单

补充可引用的公开信息（公开榜单、官方基准、第三方测试）。准确数据必须访问原始来源：GitHub 星标去仓库、榜单去 HuggingFace/LMSYS、跑分去官方发布。禁止二手转述，避免"听说""网友表示"。无法访问时注明"截至 YYYY-MM-DD"。

写正文前必须整理"引用证据清单"，至少包含：结论 + 来源链接 + 发布时间 + 为什么可以相信。未检索到证据时，清单里明确标记"未检索到有效证据"。禁止伪造数据。

步骤 3：文章风格选择

用 AskUserQuestion 让用户四选一：

• 安装教程类（参考 references/OpenClaw-install.md）：手把手教学，注重实操指导
• 产品评测类（参考 references/web-access.md）：有观点有数据
• 面试对话类（参考 references/PaiAgent.md）：要硬核，有技术支撑，真实面试场景
• 深度拆解类（参考 references/deep-analysis.md）：读源码/官方博客，用一手证据拆解技术内幕，问题驱动结构

选择判断：如果素材的核心卖点是"好不好用、值不值得装"→ 产品评测类；如果核心卖点是"它内部怎么工作的、为什么这么设计"→ 深度拆解类。前者读者看完决定"装不装"，后者读者看完理解"为什么"。

重要说明：

1. 风格参考 ≠ 内容照搬：参考对应文章学习语气、节奏、表达方式，内容必须大胆创新
2. 内容可以大胆：基于你的理解和调查给真实场景、使用体验、case，不局限于 sucai.md
3. 开头结尾别老生常谈：不要每次都套路化，根据内容特点设计有新意的开头结尾
4. 风格与素材不匹配时回退：选定风格后发现素材深度不够支撑，退回步骤 1 重新评估 IKR，或请用户补充素材

步骤 4：撰写文章

⚠️ 撰写前必须扫一眼「写作原则」「去 AI 味」「特色元素」的硬性约束。写开头和 ending 前，读 ./references/human-tone.md 找语感；金句只能出现在开头前 3 段和 ending（见「金句与情绪表达的位置」），正文章节保持书面语。human-tone.md 里「词语」一节的替换规则全篇适用。

文件格式 Markdown。正文目标 4400 字，初稿按 4400 字写，给自检删改留出 400 字余量，确保最终 ≥ 4000。

1. 初稿完成跑 ./scripts/check_body_length.py 检查
2. ≥ 4000 字：达标，进步骤 5
3. < 4000 字：不得交付。计算差额，单次补充量必须 ≥ 差额 × 1.5（例如差 800 字则一次至少补 1200 字），直接瞄 4300 以上，一轮补完。

文章头部模板：

---
title: # 4.6 起标题后回填
shortTitle: # 4.6 起标题后回填
description: # SEO 友好描述，见下方 SEO 规范
keywords: # 页面级关键词列表，见下方 SEO 规范
tag:
  - Agent  # 安装教程类/产品评测类用实际技术标签
  # 面试对话类用：- 面试
category:
  - AI
author: 沉默王二
date: # 用 date 命令拿到的实际日期，YYYY-MM-DD
---

4.2 面试对话类专属规范

以下规范仅在步骤 3 选择「面试对话类」时生效，安装教程类和产品评测类忽略本章。

正文结构（覆盖通用规则）

## content 包裹所有面试题 → 每题 ### 01、问题、### 02、问题。

追问用四级标题：面试官（老王）的追问直接写 #### 追问的问题内容，不要用"老王追问：""老王继续问："这种对话体。

不要加"我说："前缀，直接写回答内容。正文本来就是"我"在讲，不需要反复标注。

示例：

### 03、MCP 的 JSON-RPC 通信协议是怎么工作的

JSON-RPC 2.0，很简洁，只有三种消息类型。第一种是 Request，有 id 字段，需要对方响应……

#### 请求和响应的配对怎么实现的

用一个 ConcurrentHashMap，key 是自增的请求 id，value 是 CompletableFuture……

技术细节尺度（面试类强制）

讲原理和思路，禁止出现项目自定义类名。

• 禁止：堆砌类名（如 McpSchemaSanitizer、NotificationRouter、BrowserGuard），面试时不可能记这些
• 保留：Java 标准库 / 业界公认的技术名词可以用（如 ConcurrentHashMap、CompletableFuture、JSON-RPC、SSE、CDP、MCP、Function Calling），这些大家都认识
• 重点讲为什么这样设计、解决了什么问题，而不是用了哪个自定义类

4.3 深度拆解类专属规范

以下规范仅在步骤 3 选择「深度拆解类」时生效，其他风格忽略本章。

正文写法的完整规范——问题链结构、章节级四拍节奏、代码片段规范、章节过渡、6 段写法示范、常见失败模式与禁忌——全部在 references/deep-analysis.md（重点看「写作硬规范」一节），撰写前通读，不在此重复。

核心硬约束（不满足不得交付）：每个核心观点必须有一手证据支撑（源码片段 / 官方博客文档原文 / 实测数据 / GitHub issue·PR 讨论），禁止"据说""业内普遍认为""有人发现"这类无来源表述。

4.4 SEO 元数据规范（强制）

生成 SEO 友好的 frontmatter 字段，目标是让文章能被 Google/百度/bing 搜索命中。

keywords 字段：

填写 5 个与本文内容强相关的搜索关键词，覆盖三类：

1. 品牌词/项目名：文章涉及的工具、项目、框架的正式名称（如 Claude Code、Spring AI）
2. 技术栈：文章讲解的核心技术概念（如 Function Calling、MCP、RAG、Agent Harness）
3. 搜索意图词：用户实际会搜索的长尾词（如 Claude Code 教程、Agent 开发、MCP 面试题）

description 字段（SEO 描述）：

50-120 字，必须包含 2-3 个核心搜索关键词。写搜索引擎能理解的内容摘要。

"拆解 learn-claude-code 开源项目，12 层架构从 Agent 循环到上下文压缩，理解 Claude Code 核心原理。"

4.6 起标题

素材 sucai.md 里有现成标题就直接用，回填 frontmatter 的 title 和 shortTitle。没有现成标题时，参考 biaoti.md 的标题句式直接生成（不调用 title-generator Skill）。

步骤 4.5：三层自检（强制）

落盘前必须跑完三层质检。任何一层有未通过项，回到步骤 4 改稿，不得进入步骤 5。自检完成后向用户展示报告。

L1 机械扫描（可自动检查，零容忍）

这一层检查硬性规则，出现即修复，无例外。

**L1 机械扫描** ✅/❌
- [ ] 禁用词：`human-tone.md` 禁用词 grep 全文 → （命中数）
- [ ] AI 味词汇："去 AI 味"第 2 条全部禁用词 grep → （命中数）
- [ ] 标点符号："——"和"："全篇不超过 10 次 → （实际次数）
- [ ] 称呼："你"字不超过 5 次，用"大家/我们/小伙伴" → （实际次数）
- [ ] 标题层级：`## 01、标题`，无冒号后缀 → （是否合规）
- [ ] 字数：`./scripts/check_body_length.py` ≥ 4000 → （实际字数）
- [ ] CDN 图片：无捏造链接，不存在的用截图占位符 → （情况）
- [ ] 截图占位符：每章 ≥ 1 个，超 1000 字章节 3 个 → （各章节数量）

L2 风格一致性（模式匹配，需逐段扫）

**L2 风格一致性** ✅/❌
- [ ] 开头：前 3 段完成冲突→结论→收益，不老生常谈 → （用了什么手法）
- [ ] 书面语基线：正文章节无口语语气词、无网络腔 → （情况）
- [ ] 金句位置：只在开头前 3 段和 ending，正文无金句腔 → （情况）
- [ ] 表达直给：无绕弯复述，逐段"删掉这句少知道什么" → （情况）
- [ ] 句式节奏：无连续 3 句同结构，长短交替 → （情况）
- [ ] 引用溯源：外部结论有来源链接和日期 → （引用数量和来源）
- [ ] 证据密度（深度拆解类）：每个核心观点有一手证据 → （各章节证据类型）
- [ ] 问题链递进（深度拆解类）：章节间有递进，前答引出后问 → （递进逻辑）

L3 内容质量（需要判断力，读者视角通读）

这一层不是逐项扫描，是以读者视角通读全文回答：

**L3 内容质量** ✅/❌
- [ ] 信息差：读完能带走什么新东西？有没有段落删掉读者不少知道任何信息？ → （核心信息差是什么）
- [ ] 人味技巧：是否使用了"写出人味"中的命名技巧（扣主线句/逐一展示/回环呼应等）至少 2 种？ → （用了哪些）
- [ ] 心流：从头读到尾，有没有哪里注意力断掉需要回头理逻辑？ → （断点位置）
- [ ] 独特性：换一个 AI 博主能写出差不多的东西吗？哪些段落是"只有调查过才写得出"的？ → （列出独特段落）
- [ ] 活人感终审：以陌生读者视角从头扫一遍，有没有哪一段"一看就是 AI 写的"？ → （标出可疑段落并修复）

总评格式：L1 ✅ | L2 ✅ | L3 ✅ → 进入步骤 5 或 L2 ❌（2项待修复）→ 返回步骤 4

步骤 5：落盘

文件命名用主题关键词，保存到 docs/src/sidebar/itwanger/ai/。

截图链接汇总（强制）：落盘后，把文中所有截图占位符对应的原始来源链接整理成一份清单，方便二哥去截图。格式如下：

## 截图来源链接

1. 【占位符名称】→ 来源链接
2. 【占位符名称】→ 来源链接
...

如果截图来源是论文、官方页面、GitHub 仓库等有明确 URL 的，直接给链接。如果是需要自己操作才能截到的（比如终端运行截图、手机录屏），标注"需自行操作"。