Skill: lanyasheng/tech-article-cn (version 1.0.0)

--- name: tech-article description: | 要写技术分享但不知从何下手？草稿写完读起来像流水账？ 从选题→大纲→草稿→润色→发布，端到端帮你把技术经验变成一篇让人记住的文章。 适用于团队内部技术分享、掘金/InfoQ 博文、技术复盘、会议演讲稿。 不适用于：API 文档（用 doc-gen）、README（用 readme-craft）、去 AI 味（用 deslop）。 license: MIT version: "1.1.0" metadata: author: community tags: [tech-writing, article, blog, sharing] triggers: - 技术.*分享 - 技术.*文章 - 写.*文章 - 写.*分享 - 内部.*分享 - 博客.*写 - blog.*post - tech.*article - write.*article - 技术.*博客 - 掘金.*写 - InfoQ.*写 - 技术.*复盘 - 演讲.*稿 - 写博客 - write.*post - 分享稿 - technical.*writing - 写稿 allowed-tools: - Read - Write - Edit - Grep - Glob - Bash - AskUserQuestion - WebFetch - WebSearch - Agent --- # Tech Article — 技术分享文章创作 从一个模糊的想法到一篇让读者记住的技术文章。 不是模板填空。是帮你想清楚"我到底要说什么"，然后把它说清楚。 ## When to Use - 要写技术分享但不知从何下手 - 有技术实践想分享但组织不好结构 - 草稿写完了但读起来像流水账 - 需要把一个技术决策/方案写成分享稿 - 准备技术会议演讲稿 ## When NOT to Use - API 参考文档 → `doc-gen` - README → `readme-craft` - 文章写完去 AI 味 → `deslop`（本 skill 在 Phase 5 自动调用 deslop） - 纯调研报告 → `deep-research` <example> 场景: 团队做了一次 API 迁移，想写团队内部技术分享 输入: /tech-article "我们把 50 个微服务从 REST 迁到 gRPC，花了 3 个月" Phase 1: 识别为"案例复盘型"，核心问题="为什么迁移 + 怎么迁的 + 踩了什么坑" Phase 2: 大纲 = 开头(迁移动机和结果数据) → 决策过程(为什么选gRPC) → 实施路径(分批策略) → 踩坑实录(3个具体故事) → 结果(性能数据对比) Phase 3: 逐段草稿，每段先写核心论点再补充证据 Phase 4: 结构审查 + 细节补充 Phase 5: deslop 两次 pass 去 AI 味 输出: 一篇 15000 字的技术分享稿，评分 8.5/10 </example> <anti-example> 错误用法: 直接让 AI 写一篇"关于微服务最佳实践的文章" 没有具体经历、没有真实数据、没有踩坑故事 = 只能产出泛泛的"总结"文 tech-article 需要真实素材作为输入，它帮你组织和表达，不帮你编造 MUST 提供真实经历/数据/代码。NEVER 让 AI 凭空生成技术文章。 </anti-example> ## Usage ``` /tech-article "一句话描述你要写什么" # 端到端，从选题到成稿 /tech-article --outline-only "..." # 只生成大纲，自己写 /tech-article --review <file> # 审查已有草稿，给改进建议 /tech-article --type tutorial "..." # 指定文章类型 ``` ### 模式路由 | 模式 | 触发 | 执行 Phase | |------|------|-----------| | 端到端（默认） | `/tech-article "topic"` | Phase 1 → 2 → 2.5 → 3 → 4 → 5 | | 只出大纲 | `/tech-article --outline-only "topic"` | Phase 1 → 2，输出大纲后停止 | | 审查草稿 | `/tech-article --review <file>` | 读取文件 → Phase 4 审查 → 输出改进建议（不重写） | | 指定类型 | `/tech-article --type tutorial "topic"` | 跳过 Phase 1 类型判断，直接用指定类型进 Phase 2 | #### --review 模式 读取用户提供的草稿文件，按 Phase 4 的结构审查清单逐项检查，输出： 1. 每个检查项的 PASS/FAIL 结果，标注严重度：Critical（阻塞发布——比如全文无具体数据）、Moderate（明显削弱文章）、Polish（微调） 2. 具体的改进建议（带行号引用） 3. 整体质量评分 MUST 不修改原文件。只输出审查报告。 #### --outline-only 模式 完成 Phase 1（定题）和 Phase 2（搭骨架）后，输出大纲并停止。不进入 Phase 3 写草稿。 ## Phase 1: 定题 — 想清楚再动笔 MUST 在动笔前回答这 4 个问题。NEVER 跳过直接写。 ``` 1. 核心问题: 读者看完能回答什么问题？（一句话） 2. 文章类型: 匹配下方类型表 3. 目标读者: 谁会读？他们已经知道什么？ 4. 独特价值: 这篇文章有什么是网上搜不到的？ ``` ### 文章类型 | 类型 | 适用场景 | 核心结构 | 读者期待 | |------|---------|---------|---------| | **案例复盘** | 做完了一件事 | 动机→决策→实施→踩坑→结果 | "他们怎么做的，我能学到什么" | | **问题深潜** | 解决了一个难题 | 症状→排查→根因→修复→防护 | "原来是这个原因" | | **技术选型** | 做了一个技术决策 | 需求→候选→评估→选择→验证 | "为什么选这个不选那个" | | **原理解析** | 搞懂了一个东西 | 是什么→为什么这样设计→怎么工作→实际表现 | "终于懂了" | | **教程实战** | 教别人做一件事 | 目标→环境→步骤→验证→常见坑 | "跟着做就能跑通" | | **趋势观点** | 对某个技术趋势有看法 | 现状→变化→我的判断→依据→行动建议 | "这个人怎么看" | 如果用户输入模糊或缺乏具体素材，按以下顺序提问： 1. **核心经历**: "你具体做了什么？解决了什么问题？"（提取真实故事） 2. **数据证据**: "有没有具体的数据、代码、截图可以用？"（提取证据） 3. **目标读者**: "这篇文章写给谁看？他们的技术水平如何？"（确定深度） 4. **独特价值**: "这件事有什么是别人没写过的？"（确定差异化角度） 如果用户在 4 个问题后仍无法提供具体素材，SHOULD 建议用户先积累素材再写文章，或切换到 --outline-only 模式先搭框架。 最后一问——如果读者只看一个段落就转发，会是哪个？答不上来说明文章还没找到核心。这个段落就是你的 scope 锚点，其他内容围绕它展开。 ## Phase 2: 搭骨架 — 大纲是文章的一半 ### 万能骨架（所有类型通用） ``` TL;DR — 3-5 条核心判断，30 秒内让读者知道这篇值不值得读完（可选但强烈推荐） ↓ HOOK — 具体数据 + 悬念/冲突/意外，让读者决定继续读 ↓ CONTEXT — 最少量的背景，让读者能跟上 ↓ BODY — 2-4 个核心段落，每段一个论点 ↓ EVIDENCE — 代码/数据/截图/架构图，证明你说的 ↓ CLOSE — 不是总结，是延伸（反模式表/反思/开放问题） ``` 万能骨架是通用结构。当使用具体文章类型时（见 `references/article-types.md`），类型模板的 BODY 结构优先于万能骨架的 BODY。HOOK 和 CLOSE 的写法指导始终适用。 <anti-example> 大纲不是目录。"一、背景 / 二、方案 / 三、实现 / 四、总结"是目录结构——每个标题是分类标签，读者看完标题不知道你要论证什么。 好的大纲每个标题是一个论点："结构评分预测不了执行效果"、"失败了就别再试同一招"、"40% 的 session 被 agent 自己停掉了"。读者只看标题就能跟上你的论证链。 </anti-example> TL;DR 写判断句不写描述句、HOOK 用具体数据+悬念、小节标题要有信息量——详细写法规则和正反例见 `references/writing-guide.md`。 ### 大纲模板 输出格式（给用户确认）： ```markdown ## 大纲 **标题**: [标题] **类型**: [案例复盘/问题深潜/技术选型/原理解析/教程实战/趋势观点] **预估字数**: [N] 字 **核心问题**: [一句话] ### 1. HOOK (~100字) [具体的开头] ### 2. [段落标题] (~N字) - 论点: [这段要证明什么] - 证据: [用什么证明——代码/数据/截图] ### 3. [段落标题] (~N字) ... ### N. CLOSE (~100字) [结尾方向——下一步/反思/开放问题] ``` MUST 等用户确认大纲后再进 Phase 3。 ## Phase 2.5: 素材调研（可选但强烈推荐） 大纲确认后、动笔前，做一次素材盘点。好文章的 80% 来自好素材，不是好文笔。 ``` □ 竞品内容: 搜一下这个话题已有的文章，看别人写了什么、缺了什么 □ 你的独特素材: 列出你有而别人没有的——内部数据/真实故障/决策过程/代码 □ 可引用来源: 官方文档、论文、基准测试——"studies show" 不行，得说哪个 study □ 视觉素材: 架构图、监控截图、代码 diff、性能对比表 ``` **意图匹配检查**：你的文章角度和读者搜索意图一致吗？ | 读者搜索模式 | 他们想要的 | 你应该写的 | |------------|----------|----------| | "X 是什么" / "X 怎么用" | 学习 | 原理解析 / 教程实战 | | "X vs Y" / "X 替代品" | 比较 | 技术选型 | | "X 踩坑" / "X 故障" | 别人的教训 | 案例复盘 / 问题深潜 | | Reddit/论坛出现你的话题 | 真实观点 | 趋势观点（带强观点） | 如果你的角度和读者期待不匹配，文章会被跳过——即使写得很好。 ## Phase 3: 写草稿 — 先完成后完美 每段先写论点句再补证据。每个技术决策追问 why。每个核心概念配 图/表/代码 至少两种。架构图用 HTML+CSS 色块（见 `references/html-diagram-style.md`）。 写作节奏、证据优先级、对比表格用法、句级打磨、人味注入的详细规则见 `references/writing-guide.md`。 ## Phase 4: 结构审查 草稿完成后，做一次结构审查。审查分两个维度，分别打分后合并为综合分： ### 维度 A: 内容质量（50%权重） ``` □ 主线检查（最重要）：回到 Phase 1 的核心问题，逐章问"这一章在回答核心问题吗？" 不在回答的章节——要么砍掉，要么移到文章后半部分作为补充。 前 1/3 的篇幅必须让读者知道"问题是什么"和"方案大致是什么"。 支线故事（origin story、背景介绍）放在验证/结果之后，读者已有上下文时才插入。 □ 信息不重复：标题说过的结论、TL;DR 说过的数据，正文第一节不要再重复。直接进新信息。 □ 标题：读标题就知道这篇文章讲什么（不要"浅谈/深入/详解"） □ TL;DR：长文(>20000字)有 3-5 条判断句概括全文核心？ □ HOOK：前 3 句有具体数据或冲突点 □ 小节标题：有信息量，关键转折处用问句（30-50% 为宜） □ 每段有论点句：遮住证据只看论点句，文章逻辑通吗？ □ 证据三件套：每个核心概念有 图/表/代码 中至少两种？ □ 对比表格：有好做法 vs 差做法 / 方案对比表吗？（目标 5+ 个） □ Why 追问：每个技术决策后面有解释"为什么"吗？ □ 内容均匀度：各 section 展开深度是否均衡？有没有某个 section 明显单薄？ □ 无废话段落：删掉一段，文章缺了什么？如果什么都不缺就删 □ 结尾不是总结：有反模式表/反思/开放问题（见下方 CLOSE 指导） □ 长度合适：内部技术分享 10000-20000字 / 掘金 1500-3000字 / 会议演讲 3000-6000字 ``` 评分锚定：14/14 项通过 + 每段有具体数据 = 10分；11-13 项 = 8分；8-10 项 = 6分；5-7 项 = 4分；<5 项需要重写。 ### 维度 B: AI 味（50%权重） 由 deslop 的模式清单覆盖（Tier 1/2/3 + 中文特有 + 结构性模式）。在 Phase 5 中通过调用 `@deslop` 获取此维度分数。在 `--review` 模式中，按 deslop 的评分标准手动检查。 ### 综合评分 ``` 综合分 = 内容质量分 × 0.5 + AI味分 × 0.5 ``` 输出时 MUST 同时展示三个分数，不能只给综合分。示例： ``` 内容质量: 7.5/10（轴 3-6 展开偏薄，对比表只有 1 个） AI 味: 9.2/10（词汇干净，但轴间过渡结构对称） 综合分: 8.4/10 ``` **关键原则：一篇干净但单薄的文章不应该拿高分。** 内容质量 < 7 时，即使 AI 味 = 10，综合分也不会超过 8.5。这是刻意的——没有内容的"人味"没有意义。 CLOSE 不写总结（三种结尾模式）和标题优化的详细规则见 `references/writing-guide.md`。 ## Phase 5: 润色 — 调用 deslop + 合并评分 草稿通过结构审查后，MUST 调用 `@deslop` 做两次 pass 去 AI 味。 ``` @deslop <draft-file> ``` deslop 做两件事：Pass 1 逐条去 AI 模式（词汇、句式、hedging），Pass 2 全文鸟瞰检查结构性残留（段落对称、情感平坦、句式齐步走）。评分目标 >= 8/10。 deslop 返回的分数是 **AI 味分**（维度 B）。MUST 与 Phase 4 的 **内容质量分**（维度 A）合并，输出综合分： ``` 综合分 = 内容质量分 × 0.5 + AI味分 × 0.5 ``` 如果 deslop 评分 < 7，回 Phase 4 重新审查结构，可能是内容本身的问题不是表达的问题。如果 deslop 评分 ≥ 8 但内容质量分 < 7，**不要被 deslop 高分误导**——文章干净但单薄，需要补内容而不是继续润色。 ### deslop 不可用时的 fallback 如果 deslop skill 不可用或调用失败： 1. 按 Phase 3 的"句子级打磨"规则手动检查一遍 2. 按 `references/zh-tech-writing.md` 的自查清单逐项过 3. 在质量报告中注明 "deslop 未执行，已用手动规则替代" ## 场景适配 详见 `references/platform-guide.md`，包含各平台的字数、格式、SEO、发布时间等完整指南。 ## Output Artifacts ``` ## 文章信息 - 标题: [标题] - 类型: [类型] - 字数: [N] - 目标平台: [内部博客/掘金/InfoQ/会议] ## 文章正文 [完整文章] ## 质量报告 - 内容质量: [X/10]（维度 A: 主线/证据/对比表/why追问/内容均匀度） - AI 味: [Y/10]（维度 B: deslop 评分） - 综合分: [Z/10]（= A×0.5 + B×0.5） - 改进建议: [如有] 文件已保存: [path] ``` ## Related - `@deslop` — 反 AI 味（Phase 5 自动调用） - `@deep-research` — 技术调研（为文章收集素材） - `@doc-gen` — API/模块文档生成 - `@readme-craft` — README 写作 - `@diagram-expert` — 架构图/流程图 ## References - 文章类型详细指南和模板: `references/article-types.md` - 中文技术写作常见问题和修复: `references/zh-tech-writing.md` - 好标题 vs 坏标题对比库 + 句子级打磨: `references/title-examples.md` - 平台适配指南（内部博客/掘金/演讲）: `references/platform-guide.md` - HTML 图表风格规范（容器/颜色/药丸/对比图）: `references/html-diagram-style.md`

path: references/article-types.md
content: # 文章类型详细指南

> 以下模板的字数估算是每个段落的**最低内容量**，适用于掘金等短文平台（1500-3000 字）。
> 内部技术分享长文（10000-20000 字）需要在每个段落基础上扩展 3-5 倍：加更多细节、子案例、数据分析、代码走读。

## 1. 案例复盘型

最受欢迎的技术文章类型。读者想知道"别人怎么做的，我能学到什么"。

### 结构模板

```
HOOK: 结果数据 + 冲突/意外点
  "我们用 3 个月把 50 个服务从 REST 迁到 gRPC。P95 降了 40%，但中间差点把生产搞挂。"

背景 (~200字): 最少量上下文
  - 我们是什么团队，做什么业务
  - 遇到了什么问题促使我们做这件事
  - 不需要介绍技术本身（读者知道 gRPC 是什么）

决策过程 (~300字): 为什么这么选
  - 考虑了哪些方案
  - 选择标准是什么
  - 最终选了什么，为什么

实施路径 (~500字): 怎么做的
  - 分几个阶段
  - 关键的技术决策（有代码/架构图）
  - 时间线

踩坑实录 (~500字): 3-5 个具体故事
  - 每个坑: 症状→排查→根因→修复
  - 用代码/日志/截图说明
  - 说清楚为什么会踩——这才是价值

结果 (~200字): 数据对比
  - before/after 数据表
  - 超出预期的地方
  - 没达到预期的地方（诚实）

CLOSE (~100字): 不是"总结"
  - 下一步计划
  - 还没解决的问题
  - 给读者的建议
```

### 好案例 vs 坏案例

```
❌ 坏案例:
"我们采用了微服务架构，实现了服务解耦，提升了开发效率。
通过引入容器化技术，实现了快速部署。
经过团队的共同努力，项目顺利上线。"

→ 问题: 没有数据、没有细节、没有故事、放到任何项目都成立

✅ 好案例:
"第 23 个服务迁完的时候，我们发现 gRPC 的连接池在高并发下会
泄漏。Grafana 上看到连接数从正常的 50 涨到 1200+，然后 OOM。
排查了 2 天，最终定位到 grpc-go 的 keepalive 参数和我们的
负载均衡策略冲突。修复就一行配置，但定位过程消耗了整个 Sprint。"

→ 有时间线、有具体数字、有排查过程、有情绪
```

## 2. 问题深潜型

解决了一个有趣的技术问题，把排查过程写成侦探故事。

### 结构模板

```
HOOK: 症状 + 影响范围
  "线上告警: API 响应时间从 50ms 飙到 3s。影响 2000+ 用户。凌晨 2 点。"

症状描述 (~200字):
  - 什么时候开始的
  - 表现是什么（监控截图/日志片段）
  - 影响范围

排查过程 (~800字): 这是文章的核心
  - 第一个假设 → 验证 → 排除（为什么排除）
  - 第二个假设 → 验证 → 发现线索
  - 顺着线索深挖 → 定位根因
  - 用代码/日志/调用链说明每一步

根因分析 (~300字):
  - 根因是什么（一句话）
  - 为什么会出现这个问题（架构/设计/代码层面）
  - 代码级别的分析（关键代码段 + 注释）

修复方案 (~200字):
  - 怎么修的（diff 或关键代码）
  - 为什么选这个方案
  - 修复后的验证数据

CLOSE: 防护措施 + 反思
  - 加了什么监控/告警
  - 团队流程有什么调整
  - 这个问题揭示了什么更深层的问题
```

## 3. 技术选型型

技术选型文章的核心价值：不是告诉读者"X 好"，而是展示评估过程，让读者能用你的方法做自己的选型。

### 结构模板

```
HOOK: 选型的背景约束
  "我们需要一个消息队列。要求: 日均 1 亿消息，P99 < 10ms，团队没人用过 Kafka。"

需求分析 (~300字):
  - 硬约束（必须满足）
  - 软约束（最好满足）
  - 非约束（不关心的）

候选方案 (~400字):
  - 列出 3-5 个候选
  - 每个 1-2 句话说清楚它是什么

评估对比 (~500字):
  - 评估维度表（性能/运维成本/团队学习曲线/社区生态...）
  - 每个维度的具体测试数据（不是网上抄的，是自己跑的）
  - POC 代码和测试方法

最终选择 (~200字):
  - 选了什么
  - 最关键的决策因素是什么
  - 放弃其他方案的具体原因

CLOSE: 使用 N 个月后的回顾
  - 当初的判断对了吗
  - 有什么意外
  - 如果重来会怎么选
```

## 4. 原理解析型

帮读者建立心智模型。不是翻译官方文档，而是"我搞懂之后用人话跟你讲"。

### 结构模板

```
HOOK: 用一个具体问题引入
  "为什么 React 18 的 useEffect 在 StrictMode 下会执行两次？"

它是什么 (~200字):
  - 一句话定义（用你自己的话）
  - 它解决什么问题
  - 它不解决什么问题（边界很重要）

它怎么工作 (~800字):
  - 从简单到复杂，分 2-3 层讲
  - 每层一个最小可运行示例
  - 配架构图/流程图

为什么这样设计 (~300字):
  - 设计者面临的 trade-off
  - 他们选了什么，放弃了什么
  - 引用源码/RFC/设计文档

实际表现 (~200字):
  - 在你的场景下的真实数据
  - 和预期的差异
  - 使用注意事项

CLOSE: 延伸
  - 相关概念的指引
  - 进一步学习的资源
```

## 5. 教程实战型

教程的目标：读者跟着做，10 分钟内跑通。

### 结构模板

```
HOOK: 最终效果展示
  截图/GIF/demo 链接——让读者先看到终点

前提条件 (~100字):
  - 需要什么环境
  - 需要什么前置知识
  - 预估完成时间

步骤 (~1500字):
  - 每步: 做什么 → 代码 → 预期结果
  - 代码块必须可直接 copy-paste 运行
  - 每步结束有验证方法（"运行后应该看到..."）

常见问题 (~300字):
  - 3-5 个常见坑
  - 每个: 错误信息 → 原因 → 修复

CLOSE: 下一步
  - 可以扩展什么
  - 进阶资源
  - 完整代码 repo 链接
```

## 6. 趋势观点型

最难写的类型。需要有真实经验支撑的判断，不是转述他人观点。

### 结构模板

```
HOOK: 反直觉的判断
  "我认为 Serverless 在未来 3 年内不会成为主流。这是一个不受欢迎的观点。"

现状 (~200字):
  - 当前的事实（有数据支撑）
  - 主流叙事是什么

我的判断 (~300字):
  - 我认为会怎样
  - 清晰表达立场（不要 hedging）

依据 (~500字):
  - 来自个人实践的证据（最有说服力）
  - 来自行业数据的支撑
  - 来自技术原理的推导

反驳预期反对意见 (~200字):
  - "有人会说 X"→ 我的回应
  - 承认自己判断可能错的地方

CLOSE: 行动建议
  - 如果我是对的，读者应该怎么做
  - 如果我是错的，最坏情况是什么
```


path: references/html-diagram-style.md
content: # HTML 图表风格规范

技术文章中的 HTML 图表必须遵循统一风格。不要用 ASCII art 代替——HTML 图在博客平台上渲染效果远好于代码块里的 ASCII。

## 基础容器

每个图表包裹在一个统一容器里：

```html
<div style="font-family:-apple-system,BlinkMacSystemFont,'Segoe UI',sans-serif;font-size:13px;margin:20px 0;background:#fafafa;border:1px solid #e5e7eb;border-radius:12px;padding:24px">
<div style="text-align:center;font-weight:700;font-size:15px;color:#111;margin-bottom:20px">图表标题</div>
<!-- 内容 -->
</div>
```

关键属性：
- `background:#fafafa` 浅灰底，不用白底（白底和页面融合，看不出边界）
- `border:1px solid #e5e7eb` 细边框
- `border-radius:12px` 圆角
- `padding:24px` 内边距
- `font-family:-apple-system,BlinkMacSystemFont,'Segoe UI',sans-serif` 系统字体栈
- `font-size:13px` 基础字号
- 标题 `font-size:15px;font-weight:700;color:#111` 居中

## 层级区块

分层架构图、路由表等用层级区块：

```html
<div style="border-radius:8px;padding:14px;background:#f0fdf4;border:1px solid #86efac">
<div style="font-size:11px;color:#16a34a;font-weight:700;letter-spacing:1px;margin-bottom:6px">LAYER 1 · 层名称</div>
<div style="font-size:12px;color:#666;margin-bottom:6px">描述文字</div>
<!-- 药丸标签 -->
</div>
```

关键属性：
- 层级标签：`font-size:11px;font-weight:700;letter-spacing:1px` 大写风格
- 层间连接：`<div style="text-align:center;color:#bbb;font-size:11px">↓ 连接说明</div>`

## 药丸标签

工具名、关键词用药丸标签：

```html
<span style="background:#dbeafe;border:1px solid #93c5fd;border-radius:6px;padding:4px 10px;font-size:12px">标签文字</span>
```

- `border-radius:6px` 圆角
- `padding:4px 10px` 或 `padding:3px 8px`（紧凑版）
- `font-size:12px` 或 `font-size:11px`（紧凑版）

## 颜色系统

6 种语义颜色，每种有 浅底 + 边框 + 文字 三色：

| 语义 | 浅底 background | 边框 border | 文字 color | 适用场景 |
|------|-----------------|-------------|-----------|---------|
| 绿色 | `#f0fdf4` / `#dcfce7` | `#86efac` | `#16a34a` | 成功、推荐、通过 |
| 蓝色 | `#eff6ff` / `#dbeafe` | `#93c5fd` | `#3b82f6` | 信息、中性、常规 |
| 黄色 | `#fefce8` / `#fef3c7` | `#fde68a` | `#a16207` | 警告、注意、中间态 |
| 红色 | `#fef2f2` / `#fee2e2` | `#fca5a5` | `#dc2626` | 错误、失败、危险 |
| 紫色 | `#faf5ff` / `#ede9fe` | `#c4b5fd` | `#7c3aed` | 基础层、运行时 |
| 灰色 | `#fafafa` / `#f3f4f6` | `#e5e7eb` | `#111` / `#666` | 容器、说明文字 |

## 左右对比图

好做法 vs 差做法的对比用 flex 布局：

```html
<div style="display:flex;gap:12px;flex-wrap:wrap">
<div style="flex:1;min-width:250px;border-radius:8px;padding:14px;background:#fef2f2;border:1px solid #fca5a5">
<div style="font-size:11px;color:#dc2626;font-weight:700;letter-spacing:1px;margin-bottom:10px">差做法标题</div>
<!-- 内容 -->
</div>
<div style="flex:1;min-width:250px;border-radius:8px;padding:14px;background:#f0fdf4;border:1px solid #86efac">
<div style="font-size:11px;color:#16a34a;font-weight:700;letter-spacing:1px;margin-bottom:10px">好做法标题</div>
<!-- 内容 -->
</div>
</div>
```

## 条形对比图

数值对比用条形：

```html
<div style="display:flex;align-items:center;gap:10px">
<div style="width:80px;text-align:right;font-size:12px;font-weight:600;color:#dc2626">标签 A</div>
<div style="flex:1;background:#fef2f2;border:1px solid #fca5a5;border-radius:6px;padding:8px 12px">
<div style="background:#fca5a5;border-radius:4px;height:8px;width:100%"></div>
<div style="font-size:11px;color:#991b1b;margin-top:4px"><b>数值</b> 说明</div>
</div>
</div>
```

- 用纯色条 `height:8px`，不用渐变（`linear-gradient` 在部分平台渲染异常）
- 用 `width` 百分比表达相对比例

## 流程图

流程节点用药丸标签 + 箭头连接：

```html
<div style="display:flex;gap:8px;flex-wrap:wrap;justify-content:center;align-items:center">
<span style="background:#dbeafe;border:1px solid #93c5fd;border-radius:6px;padding:6px 12px;font-size:12px"><b>步骤 1</b></span>
<span style="color:#bbb">→</span>
<span style="background:#dbeafe;border:1px solid #93c5fd;border-radius:6px;padding:6px 12px;font-size:12px"><b>步骤 2</b></span>
<span style="color:#bbb">→</span>
<span style="background:#dcfce7;border:2px solid #86efac;border-radius:6px;padding:6px 12px;font-size:12px;font-weight:600;color:#16a34a"><b>关键步骤</b></span>
</div>
```

- 箭头用 `→` 字符，颜色 `#bbb`
- 垂直箭头用 `↓`，放在 `text-align:center` 的 div 里
- 关键节点用 `border:2px solid` + 加粗颜色突出

## 禁止事项

- 不用 emoji（去掉 ❌ ✅ 🔑 🌐 等，用文字或颜色区分）
- 不用 `linear-gradient`（部分平台渲染异常）
- 不用 `position:absolute`（响应式布局容易错位）
- 不用 `box-shadow`（部分博客平台不渲染）
- 不用 `max-width` 固定像素（用容器自适应）
- 不在图里放大段文字（图是视觉速读，详细说明放正文）


path: references/platform-guide.md
content: # 平台适配指南

## 内部技术博客

- 可以假设读者有基础技术背景，不用解释通用概念
- 内部数据可以用（注意脱敏）
- 鼓励写失败案例和踩坑——内部分享的最大价值是避免重复踩坑
- 结尾加"联系方式"方便读者找你讨论
- **字数**: 10000-20000 字（深度长文最受欢迎）
- **格式**: Markdown，支持 Mermaid 图表
- **标签**: 选 2-3 个精准标签，避免泛标签如"技术"
- **发布时间**: 工作日上午 10-11 点发布阅读量最高

## 掘金/InfoQ/开源社区

- 解释清楚技术背景和前提假设
- 代码示例必须可运行、有注释
- 避免内部术语和缩写
- 加 repo 链接、demo 链接
- **字数**: 掘金 1500-3000 字 / InfoQ 3000-5000 字
- **封面图**: 掘金需要封面图（推荐 900x383px）
- **摘要**: 前 100 字是搜索引擎和信息流的展示文本，需要精心打磨
- **SEO**: 标题包含关键技术词，避免纯中文标题
- **代码高亮**: 指定语言标识（如 `js`、`python`）

## 会议演讲稿

- 每页 PPT 对应 1 个论点，文稿中用 `---` 分隔
- 开头 30 秒定胜负——用故事或反直觉数据
- 结尾给一个读者能带走的 action item
- **时长**: 通常 20-40 分钟，对应 3000-6000 字讲稿
- **节奏**: 每 5 分钟一个"唤醒点"（数据、演示、提问）
- **备注**: 讲稿中用 `> 演讲备注: ...` 标记只给自己看的提示


path: references/title-examples.md
content: # 好标题 vs 坏标题对比库

> 蒸馏自 Cole Schaefer 方法论 + Ogilvy 标题框架 + 中文技术社区高赞文章分析

## 核心原则

标题是 80% 的钱。如果你花 5 小时写文章，至少 1 小时应该花在标题上。

写 10-15 个标题候选，放一放，回来选最好的那个。

## 四种标题策略

### 1. 悬念钩子 — 给一个味道但不揭底

```
✅ "我们的 API 网关每天处理 2 亿请求。上个月它挂了 47 分钟。"
✅ "这个 bug 藏了 6 个月，根因是一行看起来完全正确的代码"
✅ "为什么我们放弃了 GraphQL（在用了 18 个月之后）"

❌ "一次关于 API 网关的实践分享"
❌ "GraphQL 的优缺点分析"
```

### 2. 直给结论 — 告诉读者他能得到什么

```
✅ "50 个服务从 REST 迁到 gRPC：我们踩的 7 个坑"
✅ "把编译时间从 47 分钟砍到 3 分钟的 5 个改动"
✅ "React 18 并发模式完全指南：从零到生产"

❌ "浅谈微服务迁移的一些实践"
❌ "编译优化的一些思考"
```

### 3. 反直觉/争议 — 挑战读者的已有认知

```
✅ "Serverless 不会成为主流——来自三年实践者的反思"
✅ "为什么 100% 测试覆盖率让我们的代码更烂了"
✅ "我们把微服务合回了 monolith，性能提升了 10 倍"

❌ "关于 Serverless 的一些个人看法"
❌ "测试覆盖率的利与弊"
```

### 4. 具体数字 — 数据自带说服力

```
✅ "从 800ms 到 12ms：一次数据库查询优化的完整过程"
✅ "3 个月，120 个文件，0 个 bug：我们的 TypeScript 迁移记录"
✅ "日均 1 亿消息：我们的消息队列选型之路"

❌ "数据库查询优化实践"
❌ "TypeScript 迁移分享"
```

## 坏标题模式（禁用）

| 模式 | 示例 | 问题 |
|------|------|------|
| "浅谈"开头 | 浅谈 XX 的最佳实践 | 自我贬低，读者凭什么花时间看"浅"的东西 |
| "深入理解" | 深入理解 XX 的原理与实战 | 空洞承诺，没说清楚深入了什么 |
| "关于...的一些思考" | 关于微服务的一些思考 | 太模糊，可以是任何内容 |
| "论..." | 论分布式系统的一致性 | 学术论文语气，读者预期枯燥 |
| 全英文术语堆砌 | Kubernetes + Istio + Envoy 实践 | 关键词罗列不是标题 |
| "最佳实践" | XX 最佳实践大全 | 通用到放在任何文章都成立 |

## 标题长度

- 中文技术文章：**15-25 个字**效果最好
- 太短（<10 字）缺信息量
- 太长（>30 字）无法一眼扫完
- 含数字的标题点击率高 30%+（来自掘金社区数据）

## 标题公式

### 公式 1: [数字] + [对象] + [动作] + [结果]

```
"50 个服务从 REST 迁到 gRPC：延迟降了 40%"
"3 行配置修复了困扰我们 2 个月的内存泄漏"
```

### 公式 2: [意外结果] + [背景]

```
"编译时间反而变长了——升级到 Gradle 8 的教训"
"性能提升 10 倍的改动只有 5 行代码"
```

### 公式 3: [时间] + [挑战] + [暗示故事]

```
"凌晨 2 点的 P0 故障：一次 DNS 缓存引发的血案"
"上线前 3 小时发现的致命 bug"
```

### 公式 4: 问题式

```
"为什么你的 Docker 镜像有 2GB？"
"gRPC 真的比 REST 快吗？我们测了 6 个月"
```

## 标题自检

写完标题后问自己：

```
□ 读标题就知道文章讲什么？
□ 有具体数字或具体技术名称？
□ 有冲突/悬念/反直觉的元素？
□ 去掉"浅谈""深入""一些"了吗？
□ 15-25 个字（中文）？
□ 换成任何公司/项目的标题都成立吗？（如果是，太通用了）
```

## 句子级打磨要点

> 蒸馏自 Cole Schaefer / Ogilvy 方法论

### 短第一句

每段、每节的第一句话：10 字以内好，8 字以内更好，5 字以内最佳。

```
✅ "编译挂了。" → 读者立刻想知道为什么
✅ "这不对。" → 制造紧张感

❌ "在经过多次尝试和反复调试之后，我们终于发现了编译失败的根本原因。"
```

### 节奏变化

连续 3 句同样长度 = 读者走神。短句和长句交替，像呼吸。

```
✅ "查询慢了。不是一点点慢，是从 50ms 变成了 3 秒那种慢。我们看了监控，
    看了日志，甚至怀疑是不是机房网络出了问题。结果根因在索引上。一个月前
    有人改了字段类型，索引失效了，没人注意到。"

→ 短(3字)→长(18字)→长(24字)→短(5字)→长(16字)
```

### 简单词优先

用一个字能说清的不用两个字。"用" 不用 "使用"。"改" 不用 "修改"。

技术术语保持原样（Kubernetes、gRPC），但连接词/描述词用最简单的。

### 杀副词

扫描所有 "地" "了" "着" 结尾的修饰语。如果删掉不影响意思就删。

```
❌ "显著地提升了性能"
✅ "性能提升了 10 倍"

❌ "成功地完成了迁移"
✅ "迁移完成"
```


path: references/writing-guide.md
content: # 写作指南（Phase 2-4 详细规则）

从 SKILL.md 拆出的详细写法指导。SKILL.md 保留流程骨架和规则引用，具体怎么写看这里。

## TL;DR 写法

长文（>20000字）SHOULD 加 TL;DR。放在 HOOK 之前或之后，用 3-5 条判断句概括全文核心观点。

```
❌ "本文介绍了 Agent 架构的各个方面"（这是目录不是 TL;DR）
❌ "Agent 很重要，Harness 也很重要"（废话）

✅ "更贵的模型带来的提升，很多时候没有想象中那么大，反而 Harness 和验证测试质量对成功率的影响更大"
✅ "调试 Agent 行为时，应优先检查工具定义，因为多数工具选择错误都出在描述不准确"
✅ "评测系统本身的问题，很多时候比 Agent 出问题更难发现"
```

TL;DR 的核心：**判断句，不是描述句**。每条都应该是一个可以被反驳的观点，而不是一段内容介绍。

## 小节标题：有信息量，偶尔用问句

好标题让读者一眼知道这段讲什么。问句可以用，但不能堆砌——全是问句读起来像 FAQ，反而成了新的 AI 味。

```
❌ "Harness 的重要性"（太虚）
❌ "上下文分层结构"（没有观点）
❌ "为什么要分层？"（如果全文都是这种问句，很累）

✅ "Harness 比模型更关键"（有判断）
✅ "上下文为什么要分层"（关键转折处用问句）
✅ "4 个安全阀"（简洁有信息量）
✅ "Checkpoint + Rollback：破坏性命令前拍快照"（告诉读者这段讲什么）
```

小节标题 SHOULD 有信息量（读标题就知道这段的结论或主题）。问句适合用在关键转折处（30-50% 为宜），不要全用问句。

## HOOK 写法（最重要的 3 行）

```
❌ "本文将介绍我们团队在微服务迁移方面的实践经验"
❌ "随着云原生技术的发展，微服务架构越来越受到关注"
❌ "在当今快速发展的技术环境中..."

✅ "3 个月，50 个服务，从 REST 到 gRPC。延迟降了 40%，但中间差点把生产搞挂。"
✅ "我们的 API 网关每天处理 2 亿请求。上个月它挂了 47 分钟。这是我们排查出的根因。"
✅ "大多数 gRPC 迁移文章告诉你怎么写 proto 文件。没人告诉你第 30 个服务迁完后会遇到什么。"
```

HOOK 的核心：**具体数据 + 悬念/冲突/意外**。让读者觉得"这个人真做过"。

## Phase 3: 写草稿 — 先完成后完美

### 写作节奏

- 每段先写**论点句**（这段的核心观点，一句话），再补充证据和细节
- 段落间不需要过渡句。如果必须过渡，内容本身就是最好的过渡
- 技术细节用代码块、数据表格、架构图呈现。不要用文字描述代码
- 长段落（>150字）必须拆分。读者在手机上读你的文章

### 证据优先级

| 证据类型 | 说服力 | 示例 |
|---------|-------|------|
| 好做法 vs 差做法对比表 | ★★★★★ | 两栏对比，读者一眼看出区别 |
| 可运行代码 | ★★★★★ | 读者 copy-paste 就能跑 |
| 性能数据对比 | ★★★★★ | before/after，带环境信息 |
| 真实故障/踩坑 | ★★★★ | 具体时间线、症状、修复过程 |
| 架构图/流程图 | ★★★★ | 自制 SVG/Mermaid，不要用网上找的通用图 |
| 团队讨论/决策过程 | ★★★ | "我们考虑了 A 和 B，选了 A 因为..." |
| 外部引用 | ★★ | 有出处的论文/官方文档 |
| 个人感受/观点 | ★★ | 真诚但不能替代证据 |

### 对比表格：信息密度最高的武器

对比表是技术文章最有效的证据形式之一。两栏对比让读者不需要动脑就能理解差异。好的技术文章每篇通常有 5+ 个对比表格。

```
常用对比维度:
- 好做法 vs 差做法（最常用）
- 方案 A vs 方案 B（技术选型必备）
- 设计目标 vs 反模式
- 旧方案 vs 新方案（迁移类文章）
```

每个核心概念 SHOULD 配备 **图/表/代码 三件套中的至少两种**。只有文字描述的技术概念 = 读者记不住。

### HTML 图表

架构图、流程图、对比图 MUST 用 HTML+CSS 色块渲染，不要用 ASCII art 代码块。详细风格规范见 `html-diagram-style.md`，核心要点：

- 统一容器：`background:#fafafa;border:1px solid #e5e7eb;border-radius:12px;padding:24px`
- 标签用药丸样式：`border-radius:6px;padding:4px 10px;font-size:12px`
- 6 种语义颜色（绿/蓝/黄/红/紫/灰）各有 浅底+边框+文字 三色
- 层级标题：`font-size:11px;font-weight:700;letter-spacing:1px` 大写风格
- 不用 emoji、不用渐变、不用 `position:absolute`

### "为什么" 追问模式

不要只描述 what（"系统用了 AsyncGenerator"），要追问 why（"为什么用 AsyncGenerator？三个原因..."）。每个决策背后都有 Tradeoff，写出来比隐藏更有价值。

```
❌ "Claude Code 的消息扣留机制会拦截三类消息"
✅ "Claude Code 的消息扣留机制会拦截三类消息。为什么不直接传给调用方？因为 SDK 消费者看到 error 就会终止会话，但内部可能还有恢复路径"

❌ "我们选择了分批迁移策略"
✅ "我们选择了分批迁移策略。为什么不一次性切换？因为第 15 个服务切完后我们发现了一个序列化兼容性问题，如果全量切换就是全站故障"
```

每个技术决策/设计选择 SHOULD 追加一个 why 段。读者要的不是信息搬运，是洞察。

### 句子级打磨

- **短第一句**: 每段开头句 10 字以内。"编译挂了。"比"在经过反复调试后我们发现..."好 10 倍
- **节奏变化**: 短句→长句→短句。连续 3 句同样长度 = 读者走神。朗读一遍就知道
- **简单词优先**: "用"不用"使用"、"改"不用"修改"、"is"不用"serves as"
- **杀副词**: 扫描所有"显著地""成功地""有效地"。删掉不影响意思就删
- **具体替换模糊**: "很多公司" → 哪些？"性能提升" → 从多少到多少？"studies show" → 哪个 study？

### 人味注入

去掉 AI 模式只是一半。干净但无菌的文字一样一眼能看出是 AI 改过的。

- **有观点**: 纯中立陈述 → 加一句反应。"这个数据让我们放弃了方案 A"
- **有不确定**: "我可能错了，但..."比"综合分析表明..."更让人信任
- **有个人经历**: "我们花了两天排查"比"问题被定位"有温度
- **有跑题**: 完美结构感觉算法生成的。偶尔的旁白和跑题是人的标志
- **有具体感受**: "这个 bug 让人抓狂"比"this is concerning"有力

### 每段自检

写完一段后问自己：
1. 这段的论点句是什么？如果没有，加一个
2. 证据具体吗？"性能提升了"→"P95 从 847ms 降到 12ms"
3. 这段放到别人的文章里也成立吗？如果是，你的独特视角在哪

## CLOSE：结尾怎么写才不像 AI

"总结"是最弱的结尾。读者刚读完全文，不需要你帮他总结。好的结尾给出新的东西。

**三种结尾模式（按场景选一种）：**

| 模式 | 适用场景 | 做法 |
|------|---------|------|
| **反模式表** | 工程实践类 | 5-8 个常见错误 + 问题 + 怎么修，单独成章 |
| **三段反思** | 源码分析/技术选型类 | "值得学习" + "值得商榷" + "如果重新设计" |
| **编号要点** | 综述类/长文 | 10 条压缩后的核心判断，每条一个可被反驳的观点 |

```
❌ "综上所述，本文介绍了 Agent 的架构设计..."（重复目录）
❌ "总结一下，我们从以下几个方面..."（浪费读者时间）

✅ 反模式表：列出 5-8 个常见错误 + 症状 + 修法，读者可以直接当 checklist 用
✅ 三段反思：哪些设计值得学、哪些可以商榷、如果你来做会怎么改
✅ 编号要点：10 条压缩后的核心判断，每条都是独立的可执行洞察
```

## 标题优化

```
❌ 浅谈微服务架构的最佳实践
❌ 深入理解 gRPC 原理与实战
❌ 关于 API 网关的一些思考

✅ 50 个服务从 REST 迁到 gRPC：我们踩的 7 个坑
✅ API 网关挂了 47 分钟：一次 P0 故障的完整复盘
✅ 为什么我们放弃了 GraphQL（在用了 18 个月之后）
```

好标题 = **具体 + 有信息量 + 引发好奇**。数字、时间线、反直觉结论都是好信号。


path: references/zh-tech-writing.md
content: # 中文技术写作常见问题和修复

## 1. 开头综合症

中文技术文章最常见的开头有三种，全是低分开头：

### "随着...的发展" 开头

```
❌ "随着云原生技术的快速发展，微服务架构已经成为..."
❌ "随着 AI 技术的不断进步，大模型在..."
❌ "在当今数字化转型的大背景下..."

→ 问题: 这是万能开头，放到任何文章都成立。读者第一秒就判定"AI 写的"或"没话找话"。

✅ "我们的 monolith 有 120 万行代码。上周五它编译了 47 分钟。"
✅ "这个 bug 藏了 6 个月，影响了 3 万用户，根因是一行看起来完全正确的代码。"
✅ "团队 8 个人，同时改一个文件。Git 冲突率 40%。我们不得不拆服务。"
```

### "本文将介绍..." 开头

```
❌ "本文将从以下几个方面介绍..."
❌ "本文主要分享我们团队在 X 方面的实践经验"

→ 问题: 这不是开头，这是目录。读者想看结论和故事，不想看你的提纲。

✅ 直接从最有趣的部分开始。如果你的文章最有趣的部分在第三段，那第三段就是你的开头。
```

### "众所周知" 开头

```
❌ "众所周知，性能优化是..."
❌ "大家都知道，微服务架构的核心思想是..."

→ 问题: 如果众所周知，为什么还要写？

✅ 从"众所周知"的反面开始: "大多数人以为 X，但实际上 Y。"
```

## 2. 四字成语堆砌

```
❌ "高效协同、智能赋能、敏捷迭代、持续交付"
❌ "全面覆盖、深度整合、无缝对接、灵活扩展"

→ 问题: 四字词自带权威感和抽象感，读起来像会议纪要。

✅ 把每个四字词展开成具体的事:
  "高效协同" → "同一个需求，iOS 和 Android 的代码改动量从 2 天降到了半天"
  "智能赋能" → "自动生成的测试用例覆盖了 80% 的边界情况"
  "敏捷迭代" → "从周发布改成了日发布，每次改动不超过 200 行"
```

## 3. 无意义的"总分总"

```
❌ "下面我将从三个方面展开讨论:
    第一，xxx；第二，yyy；第三，zzz。
    综上所述，xxx、yyy、zzz 共同构成了..."

→ 问题: 开头说了要讲什么，中间讲了，结尾重复一遍讲了什么。读者看了三遍同样的信息。

✅ 直接说最重要的。如果有三个点，从最重要的开始，其他自然带出。
   结尾不要重复开头——给一个新的视角、一个行动项、或一个开放问题。
```

## 4. 过度谦虚

```
❌ "一些微小的尝试"
❌ "抛砖引玉，希望能给大家一些启发"
❌ "不足之处还请大家多多指正"
❌ "个人浅见，仅供参考"

→ 问题: 你花了几个月做的事，写了几千字的文章，然后说这是"微小的尝试"？
   过度谦虚在中文语境中确实有礼貌功能，但在技术文章中它会削弱你的信息的可信度。

✅ 实事求是。做了什么就说什么。
   如果确实有局限，写清楚具体的局限: "这个方案在并发超过 10k 时没有验证过。"
   这比"一些微小的尝试"有信息量得多。
```

## 5. 被动语态过多

```
❌ "该方案已被成功实施" / "性能已被优化" / "问题已被解决"
❌ "通过引入 X 技术，Y 问题得到了有效缓解"

→ 问题: 谁实施的？怎么优化的？解决了多少？被动语态隐藏了关键信息。

✅ "我们把 API 响应时间从 800ms 降到 50ms"
✅ "团队选了方案 B，因为 A 需要改 30 个服务的接口"
✅ "我花了两天排查，最后发现根因是连接池泄漏"
```

## 6. 没有具体数据

```
❌ "性能显著提升"
❌ "大幅降低了错误率"
❌ "开发效率得到了明显改善"

→ 问题: "显著""大幅""明显"是空话。什么叫显著？从多少到多少？

✅ "查询时间从 847ms 降到 12ms（70x）"
✅ "错误率从 2.3% 降到 0.04%"
✅ "新功能的平均交付时间从 2 周缩短到 3 天"

没有精确数据就给范围: "大约从 5s 降到了 500ms 左右"
连范围都没有就别说这个点。
```

## 7. 结尾综合症

```
❌ "综上所述，本文从 A、B、C 三个方面..."（重复开头）
❌ "展望未来，我们将继续探索..."（空洞承诺）
❌ "以上就是我们的实践经验，希望对大家有帮助。"（无新信息）

✅ 好结尾的三种写法:
  1. 下一步: "接下来我们计划把这个方案扩展到离线场景，但还没解决 X 问题。"
  2. 开放问题: "一个还没想清楚的问题: 当 replica 超过 5 个时，一致性怎么保证？"
  3. 给读者行动项: "想试的话: clone 这个 repo，改 config.yaml 里的 X 字段，跑一下 benchmark。"
```

## 8. 中英文混排问题

```
技术文章经常中英文混排，注意:

✅ 专有名词用英文: Kubernetes, gRPC, React（不要翻译成"反应"）
✅ 中英文之间加空格: "我们使用 Kubernetes 部署"（不是"我们使用Kubernetes部署"）
✅ 代码/命令用 backtick: "运行 `kubectl get pods`"
❌ 不要中英文随意切换: "这个 feature 很 nice，可以 significantly improve 我们的 performance"
```

## 9. 段落太长

```
❌ 一段超过 150 字（手机屏幕上看就是一面墙）

✅ 每段一个观点，超过 3 句就考虑拆分
✅ 段落间用空行隔开
✅ 关键信息放段首——很多读者只看每段第一句
```

## 10. 自检清单

发布前逐条过:

```
□ 开头前 3 句有没有具体数据或故事？
□ 有没有"随着...的发展"、"众所周知"、"本文将"？
□ 每个"显著/大幅/明显"都替换成了具体数字？
□ 四字成语都展开成了具体描述？
□ 结尾是不是在重复开头？
□ 最长的段落不超过 150 字？
□ 中英文之间有空格？
□ 被动句都改成了主动句？
□ 删掉"抛砖引玉"和"一些微小的尝试"了吗？
```


Security scan verdicts — ClawScan: clean | static analysis: clean | VirusTotal: clean | SkillSpector: clean (LOW)