blog-writing

name	blog-writing
description	Use when the user wants to write a blog post (技术博客或思考随笔) for their personal blog. Triggers on: 写博客、写篇文章、blog post、写一篇关于XX的文章、继续写博客系列. Not for 公众号长文 (→ khazix-writer), not for 深度研究报告 (→ hv-analysis), not for 短内容 (小红书/推特/朋友圈).

个人博客写作

从主题到成稿，按用户个人风格撰写技术博客或思考随笔，输出 Markdown 文件到 Garage 仓库。

When to Use

适用：

• 写技术博客（编程心得、工具评测、架构思考）
• 写思考随笔（行业观察、个人成长、方法论总结）
• 续写已有博客系列（如"写代码的一点心得"系列）
• 用户给出主题/素材/链接要求写博客

不适用 → reroute：

• 公众号长文（卡兹克风格）→ khazix-writer
• 深度研究报告（PDF）→ hv-analysis
• 短内容（小红书、推特、朋友圈）→ 通用能力即可
• 纯调研不含写作 → web 工具直接搜索

与相邻 skill 的区别：

• khazix-writer：固定卡兹克文风，公众号格式，无 frontmatter
• hv-analysis：横纵双轴研究，输出 PDF 报告，万字起步
• 本 skill：用户个人风格，Markdown + frontmatter，技术+思考均可

Workflow

1. 确定主题

用户的典型输入是灵感驱动、碎片化的——讲了一段经历或见闻，说了想写什么，但未必有完整结构。这一步的核心工作是：把碎片整理成清晰的写作意图。

先接收，再补全：

用户可能给的东西：

• 触发灵感的背景故事（"最近在搞XX，发现一个有意思的事"）
• 想写的方向或观点（"我觉得大家都在忽略一个问题"）
• 散乱的要点或情绪（"就是觉得不对劲，但又说不清楚"）
• 一个链接、一段对话、一个踩坑经历

需要帮用户理清的问题：

如果用户已经说得足够清楚，不要机械追问，直接进入下一步。如果信息有缺口，补问以下关键项（不要一次全问，挑最缺的问）：

• 核心观点：用一句话说，这篇文章想表达什么？
• 个人经历：有没有自己的故事/案例可以作为主轴？
• 对立面：有没有不同的声音或做法？这个对比能让文章更立体
• 系列关系：是否属于已有系列？需要衔接前文吗？
• 目标读者：写给谁看的？（默认：有编程经验的开发者）

输出：把用户的碎片输入整理成一句清晰的主题陈述，确认后再进入调研。

2. 调研素材

如果主题需要外部素材：

• 用 web 搜索收集引用、数据、案例
• 用 browser 抓取用户提供的链接内容
• 将调研结果整理为要点，不要直接拼凑进文章

调研方法（WSL 环境）：

• Brave Search API 需要 API key（可能未配置）
• DuckDuckGo HTML 版可作为搜索替代：curl "https://html.duckduckgo.com/html/?q=..."
• DDG 结果解析：class="result__a" 取链接，class="result__snippet" 取摘要，URL 需从 uddg= 参数解码
• 抓取文章内容用 curl + 去 HTML 标签，但很多网站有 JS 反爬（OpenAI、Medium、InfoQ 等）
• 网络需要代理：--proxy "http://127.0.0.1:9567"（WSL 镜像模式，Windows 代理）
• 调研结果整理为结构化摘要供写作参考，不要把原始搜索结果直接堆给用户

3. 写大纲

根据内容类型选择文章原型：

原型	适合	结构重心
经验分享型	编程心得、踩坑总结	个人经历→提炼规律→给建议
方法论型	实践方法、工作流	理论→案例→可执行步骤
观点论述型	行业观察、技术判断	现象→分析→立场
系列续写型	延续已有系列	承接前文→新维度→预告后文

确定章节结构（3-5 个大章节，带编号子节），输出大纲给用户确认后再写。

4. 初稿

严格遵循用户的写作风格（见下方 Style Guide）。

关键要求：

• 从个人经验出发：用第一人称"我"，从真实经历切入
• 每个观点配案例：抽象概念必须有具体场景支撑
• 中英自然混用：技术术语保留英文，括号补充说明
• 加粗关键原则：每篇 20-30 处粗体标记核心概念
• 引用权威：适当引用书籍/名人/论文，但自然融入
• 联系 AI 时代：适当关联当下 AI 辅助开发的实践

5. 润色

对初稿执行三级检查并修改：

L1 硬性规则：

• 无 AI 套话（"综上所述"、"值得注意的是"、"不难发现"、"首先…其次…最后"）
• 无空洞形容词堆砌（"赋能"、"抓手"、"打造闭环"）
• 无教科书式开头（"在当今…的时代"、"随着…的发展"）
• 每个提到的工具有具体名称，非空泛表述

L2 风格一致性：

• 第一人称叙事，有"过来人"语气
• 有自嘲/谦逊表达
• 有隐喻/类比（至少 3 处）
• 有对仗/对比结构（至少 2 处）
• 段落有节奏：长短交替，关键句独立成段
• 每个大章节结尾有格言式总结
• 加粗精简：初稿往往加粗过多（100+处）。精简到 20-30 处，只保留格言式洞察和核心原则。去掉：结构标签（"第一代/第二代"）、术语名（"Harness Engineering"）、列表头（"分解问题/判断质量"）、描述性语句。用 sed 脚本批量去加粗比 patch 逐个操作更可靠

加粗精简的技术陷阱：

• read_file 有缓存机制——如果文件被 write_file 写坏后再 git checkout -- 恢复，read_file 可能仍返回缓存的坏内容。解法：用带 offset 参数的调用强制重新读取，或直接用 terminal("grep ...") 操作
• 用 execute_code + write_file 做批量文本替换风险极高（一次替换错误可能清空所有加粗）。优先用 sed -i 脚本批量处理，出错后 git checkout -- 即可恢复

L3 内容质量：

• 每个核心观点有案例支撑
• 引用自然融入，不像"下面我来科普"
• 理论→实践→哲学的递进感
• 二元对立/多角度分析，不是单向输出

L4 Humanizer-zh 去AI味检查（推荐）：

L1-L3 通过后，用 humanizer-zh skill 对全文做一轮扫描，重点关注：

• "不是…而是"对仗过量：全文控制在 5-6 处以内，只保留格言级的核心对比。超出的改写为其他表达（"谈不上什么X，就是Y"、"X不行，Y也不行，得Z"、"先A再B"等）
• AI高频词："洞察"→"发现"、"格局"→换具体词、"此外"→删掉或改连接
• 破折号密度：一行内不超过 2 个——
• 三段式列举：连续三个顿号分隔的项目可以保留（中文正常用法），但"X、Y和Z"式的刻意三件套要打破
• 扫描方法：用 execute_code 跑正则扫描，按类别统计，报告给用户后批量修改

5.5 评分报告修订（可选）

如果通过子代理或外部评审拿到了量化评分报告（如 humanizer-zh 的 5 维度评分），按以下流程修订：

1. 创建优先级 TODO：

• 🔴 高优先：结构性问题（章节合并、核心段落重写、关键句式修改）
• 🟡 中优先：风格密度调整（某类修辞过多、类比降频、填充句删除）
• 🟢 低优先：小幅度精简（bullet list 压缩、去重观点、措辞微调）

2. 批量指标修订用 execute_code，不用逐个 patch：

• 破折号/类比/句式等"数量指标"类修改，先统计全文现状，再用 Python 脚本批量替换
• 先激进减到目标以下，再手动恢复关键保留项——比逐个判断"这个要不要删"快得多
• 替换后立即验证数量，如果低于目标就恢复部分

3. 结构性合并直接用 patch：

• 小节合并（如 2.4→2.3）：把被合并节的内容压缩为 1-2 段，拼接到目标节末尾，删除原节标题
• 观点去重：保留首次出现的完整表达，后续重复处只保留结论句

4. 每轮修订后统计关键指标：

# 字数
python3 -c "import re; text=open('FILE').read(); cn=len(re.findall(r'[\u4e00-\u9fff]',text)); en=len(re.findall(r'[a-zA-Z]+',text)); print(f'~{cn+en}字')"
# 破折号
grep -o '——' FILE | wc -l
# "不是…而是"
grep -o '不是.*而是' FILE | wc -l

经验教训：

• 破折号密度：6000-8000字文章建议 25-35 个（约每 250 字一个），太少会失去节奏感
• 摄影类比/隐喻：全文保留 3-5 处核心类比即可，过多会让主题模糊
• 填充悬念句（"这个问题我想了很久"、"有一天突然想通了"、"说了这么多"、"洋洋洒洒写了这么多"）：全部删除，直接进入内容
• 评分报告的"精炼度"维度通常暗示字数可砍 20-30%，优先砍重复观点和过度展开的类比

V3→V4 迭代的关键教训（精炼度仍是最大短板时）：

当破折号和结构已优化但精炼度分数仍没提升时，问题出在语义层面的重复而非表面修辞。这类修改更大胆：

1. 整段删除而非修修补补：如果一个小节的核心观点已在其他地方表达过（如"不是凭感觉拼的"已在全文主旨中隐含），直接删整个小节，不要压缩重写
2. 小节合并：§4.4"跟着你一起长"只有一句金句有价值→删除小节标题，把金句附到4.3末尾
3. 总结段只保留增量信息：总结段的 bullet list（回顾系列）是有信息量的，但总结段后面的"回到焦虑→重述论点→摄影类比收尾"几乎都是前面说过的。砍掉后半截，只留一句收束
4. 核心论点去重要狠：同一个论点（如"约束很重要"、"方法论没过时"）出现4-6次是正常的写作节奏，但精炼度评分会因此扣分。保留首次提出+数据支撑+落地实践三处，其余全删
5. 批量修改用 execute_code 而非逐个 patch：当修改项超过8条时，用 Python 脚本一次性替换所有内容，避免行号偏移和上下文不匹配的问题
6. 替换后必须全文通读：批量替换容易产生重复段落（如"我做的不是发明新轮子"出现两次）、断裂的过渡、或丢失的章节编号重排。替换后从头到尾读一遍

V1→V4 全流程迭代经验（第5篇博客实战）：

版本	分数	核心改动	教训
V1 初稿	—	5800字	初稿不必追求完美，先出骨架
V2	37	扩展到7600字，丰富案例	字数膨胀不等于质量提升
V3	36	破折号73→29，章节合并	表面修辞优化对精炼度帮助有限
V4 定稿	35	删§5.1整段、删§4.4整段，字数7200→6700	整段删除比修修补补更有效，但精炼度仍卡在6
V5 融合	33	借鉴卡兹克版亮点融合进V4	风格融合不解决精炼度，反而引入新问题
V5+对齐	—	骑马→摄影器材、成就拆散、术语中文化	风格一致性验证是定稿前必做步骤

核心结论：

• 精炼度是最难突破的维度：V2→V4 三轮迭代都没突破6分。根因是核心论点以不同变体重复出现（8-10次），需要结构级合并才能解决，但改动太大
• 用户判断"不改了"就停：当迭代收益递减（每轮-1分）且改动越来越大时，用户选择V4定稿是合理的决策。不要无限迭代
• 评分用子代理做：delegate_task + glm-5.1，传入5维度×10分框架，效果稳定
• read_file 缓存陷阱：read_file 返回带行号的内容，用 Python open() 直接读才不会匹配失败。文件被写坏后 git checkout -- 恢复，但 read_file 可能返回缓存旧内容

6. 生成 frontmatter

---
title: "文章标题"
date: YYYY-MM-DD
tags: [tag1, tag2]
series: "系列名称"  # 如果属于系列
series_index: N     # 系列中的第几篇
draft: true         # 初稿默认 draft
---

7. 写入文件

将 frontmatter + 正文写入 Garage 仓库的 .garage/blog/ 目录。

文件命名：YYYY-MM-DD-标题slug.md

路径示例：/mnt/e/workspace/Garage/.garage/blog/2026-04-17-ai-coding-workflow.md

如果目录不存在，先创建。

写完后把文件发给用户审阅（飞书发文件）：

1. 读取 ~/.hermes/.env 获取 FEISHU_APP_ID 和 FEISHU_APP_SECRET
2. 调用飞书 API 获取 tenant_access_token：POST https://open.feishu.cn/open-apis/auth/v3/tenant_access_token/internal
3. 上传文件：POST https://open.feishu.cn/open-apis/im/v1/files（file_type=stream）
4. 发送文件消息：POST https://open.feishu.cn/open-apis/im/v1/messages?receive_id_type=chat_id（msg_type=file）
5. 飞书 API 不需要代理，国内直连

Output Contract

• 写什么：完整 Markdown 文件（frontmatter + 正文）
• 写哪：/mnt/e/workspace/Garage/.garage/blog/ 目录
• 命名：YYYY-MM-DD-标题slug.md
• 状态同步：告知用户文件路径、字数、所属系列
• next action：用户确认后可修改初稿，或标记 draft: false

风格融合写法（Style Fusion）

当用户想借鉴另一种写作风格（如 khazix-writer）的亮点来改进自己的定稿时，用「风格融合」而非整体重写。

用户喜欢用不同写作 skill 生成同一篇文章的多个版本进行对比。同一主题不同风格的文件用后缀区分（如 -khazix），放在同一目录。

适用场景：

• 用户说「借鉴卡兹克版的亮点融合进 V4」
• 用户想对比两种风格后取长补短
• 已有定稿（V4），另有风格对比版（如 khazix版），想融合但不破坏原文

操作步骤：

1. 读取两个版本，识别对比版的亮点（通常是前 100-200 行最好）
2. 提炼可借鉴元素清单（具体到写法技巧，不是抽象评价）：
   • 情绪标点（。。。/？？？/= =）及其克制使用频率
   • 短句独立成段的断裂式节奏
   • 自嘲口吻的具体句式
   • 「」引号 vs ""引号的使用效果
   • 段落呼吸感的制造方式
3. 以定稿为主干，逐章将借鉴元素融入（不是重写，是点缀）
4. 写入独立文件（如 -v5.md），不覆盖原定稿
5. 总结列明：借鉴了什么、保留了什么、文件在哪

关键约束：

• 保留定稿的章节结构和技术内容不变
• 借鉴是「点缀」不是「替换」——情绪标点全文控制在 3-5 处
• 避免借鉴版的问题（如公众号腔、预告式过渡、论点重复）
• 字数应与定稿接近，不要因融合而膨胀

风格融合的实际教训（V5 实验）：

V5 融合版评分 33/50，比 V4 定稿（35/50）反而低了 2 分。原因：

• V5 在 V4 骨架上贴了卡兹克的脸，但骨架里的水没挤掉反而多了
• 融合引入的亮点（情绪标点、自嘲）本身是好的，但不解决精炼度问题
• 精炼度从 V4 的 6 分降到 5 分——因为核心论点重复次数不减反增

结论：风格融合解决的是「真实性/信任度」维度，不解决「精炼度」。如果定稿的精炼度已经卡在瓶颈，融合不会提升总分，反而可能引入新问题。

风格对比验证（Style Consistency Check）

当博客属于已有系列时，初稿完成后应与前文做风格一致性对比。这是 L2 风格检查的补充步骤，特别适合系列续写。

方法： 用子代理抓取前文内容，逐维度对比一致性。

10 个对比维度：

维度	检查要点
开头风格	是否延续系列惯用开场（自嘲/轶事/他人视角）？
自嘲谦逊度	自嘲是否"同一味道"——不回避失败、带点苦笑？
成就引用	是否"顺带一提"而非"集中检阅"？不要在同一段亮出多个资历
隐喻类比	是否只用自己真正懂的领域做类比？不要用个人经验外的隐喻
三层递进	理论→实践→哲学的结构是否保持？
格言式总结	金句风格是否一致——短句、反转、实用主义底色？
中英混用	英文术语密度是否与前文一致？首次出现中文注释，后续用中文
章节结构	编号+描述性副标题的模式是否一致？
交叉引用	"之前聊过的"式回扣是否自然、贯穿全文？
结尾风格	是否延续"一句话留白"而非过度总结？

评分判断标准：

• ✅ 一致（6/10以上通过）→ 可定稿
• ⚠️ 部分一致（3-5个维度有偏差）→ 按优先级修改
• ❌ 偏离（6个以上维度不一致）→ 需要结构性重写

最关键的 3 个 AI 痕迹检测点：

1. 综述式科普段落：前文从不用数据堆砌论证，如果某段像"文献综述"就是 AI 腔
2. 隐喻领域不匹配：前文只用作者真实的个人爱好/经验领域做类比（如摄影、建筑），跨领域隐喻是AI选的
3. 结尾过度总结：前文结尾的精髓是"一句话定格"，信息量过大的结尾是AI腔

发现偏差后的修改原则：

• 隐喻替换：换成作者真实经验领域的类比
• 成就拆散：集中出现的资历引用分散到不同段落自然带出
• 术语中文化：首次出现加中文注释，后续只用中文简称
• 结尾一刀收：保留最强金句，删除后续解释
• 用词去重复：同义词替换过度使用的词（如"驾驭"→"用好"、"核心"→换具体词）

实际验证案例（第5篇 vs 前4篇）：

对齐修改实例（17处替换，从33分偏差回升）：

• ❌ "AI 是一匹千里马，但你得会骑" → ✅ "AI 是一台顶级相机，但构图得你来"（换回作者真实爱好领域）
• ❌ "被缰绳拴住了" → ✅ "被框在了正确的轨道里"（去掉不属于自己的隐喻）
• ❌ "驾驭 AI 的缰绳" → ✅ "用好 AI 的基本功"（去马术化，换朴素表达）
• ❌ "在华为做了五年工程实践，在 ICT 软件大会上分享过"（一段亮两个资历）→ ✅ 拆散到不同段落，且去掉与论证无关的资历
• ❌ "Spec-Driven Development（SDD）" → ✅ "规格驱动开发（Spec-Driven Development，简称 SDD）"
• ❌ "用 ADR 记录架构决策" → ✅ "用架构决策记录（ADR）来记录架构决策"

Red Flags

• 写着写着变成论文语气 → 回到对话式第一人称
• 案例不够硬开始编造 → 标注"此处需用户补充真实案例"
• 全是观点没有案例 → 每个观点必须配具体场景
• 段落越来越长像教科书 → 拆短，加粗独立成段
• 偏离用户个人风格变成通用 AI 输出 → 重读 Style Guide
• 加粗超过 40 处 → 太多了，精简到只保留格言式核心原则
• 第5章（实践展示）变成框架文档/功能列表 → 回到"方法论的设计故事"视角

用户对内容方向的典型反馈模式

• "不是想讲 X，想讲 Y"：说明偏离了用户的核心意图。不要试图修补，直接按 Y 重写对应章节
• "这一版更差"：说明改动方向完全错了。用 git checkout -- 回退到上一版，从那个版本重新改，不要在错误基础上继续改
• "先在之前的版本上改"：用户明确指示回退基准。立即恢复指定版本再改
• "标题/小标题还可以改一改，我们先围绕标题改一轮"：先列所有标题给用户看（带编号），等反馈后再批量改。不要自作主张改完再问

写技术框架/方法论的注意事项

当文章涉及介绍自己做的框架、工具或工作流时，不要列功能清单或分层架构。那是 README 干的事，不是博客该写的。

核心原则：讲"在什么方法论指引下设计出来的"和"怎么把经典方法封装进框架"，而不是讲框架本身的约束机制、结构细节。

正确做法：讲方法论的设计故事。

• 在什么经典方法论的指引下设计的？（SDD、TDD、Fagan 审查、PMBOK……）
• 每个阶段选了什么方法？为什么选这个方法？（方法跟着职责走）
• 怎么把方法"装"进框架里的？（封装思路：方法不是操作手册，是决策框架）
• 踩了哪些坑？教训是什么？

素材来源优先级：

• README 的方法论表格/分层图 > 设计原则文档（anatomy）> 代码
• README 里有"哪些方法分配给了哪些节点"的完整映射，最适合博客引用
• anatomy 文件偏"怎么写 Skill 的结构约束"，是给 skill 作者看的，不是博客读者要的
• 用 anatomy 文件理解设计哲学，但写博客时讲的是方法论选型和封装思路，不是 anatomy 细节

反面模式：

• ❌ 列六层方法论（意图层、执行层、验证层……），每层一段解释——这是文档，不是文章
• ❌ 讲 Skill 的 anatomy 细节（description 是分类器、骨架结构、evals 机制）——这是给 skill 作者看的
• ❌ "这不是我发明的，是 XX 的智慧"后面直接贴架构图——像在做技术分享 PPT
• ✅ "hf-specify 用了 EARS 句式和 BDD，因为这些是需求工程的方法，不是架构设计的方法"——讲方法选型的逻辑
• ✅ "方法论不是操作手册，是决策框架——你要告诉 AI 的不是步骤，而是在这个节点哪些纪律必须被遵守"——讲封装思路

Style Guide（用户个人风格）

以下风格特征提取自用户"写代码的一点心得"系列，写作时必须贯穿。

重要补充：本节是初稿写作指南，但初稿和用户真正发布稿之间还有一道"人味儿"鸿沟，详见下方「发布前定稿（用户改稿规律）」章节，那里有从第5篇博客「初稿 → 茶思屋发布稿」对比中提炼的 12 条具体改稿清单。生成初稿时就应主动按那套清单写。

语气

• "过来人"的第一人称：像一个有经验的同事在茶歇时聊天。"说实话，当时拿金码奖的时候，我啥高级算法也不懂"
• 谦逊但不卑微：频繁自嘲（"买书如山倒，读书如抽丝"、"技术菜鸟"），但观点坚定
• 有感染力：用情感化表达（"屎山代码"、"数字考古"），让人感到作者的热情

结构

• 引言用个人轶事开场：一段对话、一个回忆、一个意外发现
• 编号章节 + 编号子节：大章用编号（1、2、3…），子节也带编号（1.1、1.2…），方便用户审阅时按编号指修改
• 标题文字要有态度：虽然带编号，但标题文字要像聊天时起的绰号，不要像目录
• 每个子节 = 一个具体要点 + 案例支撑
• 章节结尾格言式总结：朗朗上口的口号，如"重构不是技术，是一种态度"

标题风格（重要）

• 小标题必须是自然的、有态度的，不能像 AI 生成的结构性标题
• ✅ 好："充了钱，然后呢？"、"等一下……"、"越约束，越自由"、"穿别人的鞋，总不太合脚"、"是AI不行吗"、"熟悉的配方"
• ❌ 差："充值使我更强大？"、"顿悟时刻"、"约束的悖论"、"别人的框架用起来别扭"——这些要么太"标题党"，要么太 AI 腔
• 自检方法：如果一组小标题读起来像教科书目录，就太死了；如果读起来像朋友圈标题，就对了

标题修改工作流

1. 先列所有标题给用户审阅（用编号方便指认），等用户逐条反馈
2. 用户确认后批量修改，然后 commit + push 方便用户在 GitHub 上查看
3. 不要猜标题——用户对标题的品味很具体，让用户说了算

系列内引用

• 提到前文内容时，用随意的"之前聊过/之前提过"，不要写"我在第X篇里聊过"——太刻意、太 AI
• 总结部分可以例外，那里逐篇回顾是合理的结构需要

节奏

• 短段落为主（1-3 句），关键句独立成段
• 长短交替：连续 3 段以上句式长度相近 = 节奏呆板，必须调整
• 空行制造呼吸感
• 加粗标记关键原则（每篇 20-30 处）

论述手法

• 二元对立：新手 vs 专家、抽象 vs 实现、理论 vs 实践——用对比推进论述
• 隐喻丰富：盖房子、城市改造、医生诊断、武术——把软件概念映射到生活
• 引用自然融入：Martin Fowler、Uncle Bob、Kent Beck、吴军——"聊着聊着想到的"，不是"下面我来引用"
• 从理论到实践再到哲学：每个主题都经历这三层递进
• 括号旁白：用 () 补充说明或自嘲（"当然，也可能是我太菜了"）

语言

• 中英混用：技术术语保留英文（Big Ball of Mud, Trade-off, Entropy, YAGNI）
• 对仗句式："时间换空间"、"代码轻，数据重"
• 口语化但不随意：自然但不失专业感

系列特征

• 开头链接系列前文
• 结尾预告后文
• 统一标签（如 #代码心得）
• 前文概念在后文中反复出现并深化
• "做好每一件小事"作为贯穿主题

发布前定稿（用户改稿规律 / Pre-publish Pass）

AI 初稿和用户最终发布稿之间，永远有一道"人味儿"的鸿沟。下面是从第5篇博客的「初稿 → 茶思屋发布稿」对比中提炼出的用户改稿规律，生成初稿时就应主动按这套规律写，避免等用户大改。

总体方向

用户改稿做的就一件事：把"AI 写得规整的文章"改回"老程序员茶歇时跟同事吐槽的文章"。具体表现为四种力的叠加：松→更松、稳→更稳、狠→更狠、土→更土。

• 松：长句拆短、把"是…的"改成"…呀/啊/吧"
• 稳：删掉一切 AI 式过度强调（加粗、**核心是**式宣告）
• 狠：自嘲再狠一点、吐槽再直白一点
• 土：用网络/口语词替代书面词

12 条具体修改清单

1. 加粗几乎全删，只留 2-5 处真正的金句

• 初稿 20-30 处加粗 → 发布稿可能只剩 0-3 处
• AI 喜欢用加粗"提示读者这里重要"，但用户认为：真重要的话靠语境就够了，加粗反而像演讲稿
• ❌ 初稿："AI 是一台顶级相机，但构图得你来。"
• ✅ 发布稿："AI 是一台顶级的相机，但构图得你来。"（无加粗，靠位置和单独成段凸显）

2. 加"咱们"代替"我们/前文"

• "之前聊过的" → "咱们之前聊过的"
• "前文提到的" → "咱们以前聊过的"
• "我在第三篇说的" → "咱们之前聊过的"
• 效果：读者立刻被拉进"自己人"的对话场里

3. 网络口语词替代规范词

• "超过很多初中级工程师" → "秒杀很多初中级工程师"
• "AI 跑起来就是不对" → "AI 跑起来简直像个智障，根本不对味"
• "效率没有提升" → "把前期省下的时间全吃回去了"
• "处理 Bug" → "擦屁股的时间"
• "迭代踩坑" → "背锅踩坑熬出来"
• "被新模型超越" → "被日新月异的AI模型和应用啪啪打脸"
• 黑名单：稳健、赋能、抓手、范式、本质上、值得关注的是
• 白名单：搞、捣腾、盘算着、对味、瞎写、放水、智障、牛逼、绝活

4. 重复词强化语气（不是病句，是节奏）

• "基本功能跑起来了" → "基本功能确实跑起来了，确实快呀"
• "Tokens 消耗变多" → "Tokens的消耗明显多了……"（下一节再来一次"Tokens的消耗明显更多了……"形成回声）
• 同一段内重复用词不是要删，是节奏

5. 省略号 …… 替代部分句号

• AI 倾向句号收尾，用户倾向用 …… 表达"无奈/欲言又止/苦笑"
• 用在：踩坑后的吐槽、对成本的无奈、收尾的开放感
• ❌ "Tokens 消耗也明显增多。"
• ✅ "Tokens的消耗明显多了……"
• 全文密度：每 800-1000 字一处即可，不要滥用

6. 引用大师后立刻自己加吐槽（括号补刀）

• ❌ "代码首先是写给人看的，顺便才是给机器跑的。"
• ✅ "代码首先是写给人看的（也许将来也不看了），顺便才是给机器跑的。"
• 模式：经典金句 + (自己的小吐槽/自嘲) → 防止"科普腔"

7. 章节编号用 1. 而非 1、

• 阿拉伯数字句点，与子节 1.1 1.2 风格统一
• 标题前不加井号或图标

8. 删除全部图片占位与示意图引用（发布平台前）

• 写给 Garage 仓库的版本可以保留 ![描述](images/x.png)
• 但发布到茶思屋这类平台前，全部删除图片标记，正文要能脱离图独立成立
• 如果某段内容必须靠图才能讲清楚，说明文字本身不够好，要补回文字描述

9. 总结段不要"逐篇 bullet 回顾"

• ❌ 初稿："- 第一篇聊 X / - 第二篇聊 Y / - 第三篇聊 Z..."
• ✅ 发布稿：一段话带过"五篇文章，从「如何手写好代码」一路聊到「如何用好 AI」，其实核心从来都没变过——做好每一件小事"
• bullet 式回顾是结构化思维，但读起来像目录；用户偏好"一句话浓缩"

10. 章节末加"生活化锚点"

• 第5章末尾，用户在抽象总结后加上具体内容：
  • "项目1：摄影社区APP"
  • "项目2：garage-agent"
  • "现在感觉是AI能做出来想要的，但我想不清楚我要什么，缺少产品思维……"
• 模式：方法论高潮 → 落到具体作品/具体困惑 → 用省略号留白
• 不要用方法论的金句结尾，用"接下来还要踩的坑"结尾

11. 引言后立刻加 GitHub/资源链接（"太长不想看"）

• ❌ AI 初稿：直接进第一章
• ✅ 发布稿：在引言和正文之间加一行
  • "以下文章太长不想看，那就看结果，从idea到产品落地一套工作流：https://github.com/xxx/xxx"
• 实用主义：让懒读者直接拿走干货，仔细读者再继续

12. 生活场景细节加得更密

• AI 倾向直接进入观点，用户倾向先铺生活画面
• ❌ "我开始尝试 AI 编程工具"
• ✅ "白天公司干完活，晚上回去继续AI Coding"
• ❌ "用 Cursor 和 Claude 开发"
• ✅ "Claude和Cursor 来回捣腾"
• 模式：动词具象化 + 时间地点细节 + 拟人化（让工具"捣腾"而不是"开发"）

章节级修改模式

3.x 实操路线段落：每条路线后加"成本吐槽"

• 用户在每条尝试路线后都补了一句"当然，Tokens的消耗明显多了……"
• 这种"每段重复同一句吐槽"是中文随笔的常见手法，制造苦笑节奏
• AI 不要写第一遍就过去，可以在 3.1、3.2 各放一次，第三次就别放了

5.x 框架介绍段落：避免"框架功能列表"

• ❌ 初稿："Harness Flow 包含 X 个 Skill，分为 Y 层，特性是 Z..."
• ✅ 发布稿：直接讲"我踩了什么坑"
  • "起初，我犯了个致命错误……"
  • "结果 AI 跑起来简直像个智障"
  • "改了好多轮后发现……"
• 介绍自己的框架时，用"踩坑→反思→顿悟"叙事，不要用"功能→架构→优势"叙事

1.x 现象描述段落：用"暗病/慢性消耗"等病理化词

• ❌ "存在多个 Bug"
• ✅ "用着用着就会发现各种暗病"
• ❌ "调试成本累积"
• ✅ "极其折磨人的慢性消耗"
• 把技术问题描述成身体不适，制造代入感

自检清单（发布前过一遍）

写完初稿后，按下面 6 个 grep/check 项过滤一遍：

FILE="article.md"
# 1. 加粗数量：超过 5 处就要砍
grep -o '\*\*' "$FILE" | wc -l   # 除以 2 = 加粗数量
# 2. 是否引入了"咱们"：至少 5 处
grep -c '咱们' "$FILE"
# 3. 省略号密度：每千字 1-2 处
grep -o '……' "$FILE" | wc -l
# 4. AI 套话残留
grep -nE '综上所述|不难发现|值得注意的是|首先.*其次.*最后|本质上|赋能|抓手|范式' "$FILE"
# 5. 是否还有图片占位（发布版应为 0）
grep -c '!\[' "$FILE"
# 6. 章节编号格式：应是 1. 不是 1、
grep -E '^# [0-9]+、' "$FILE"

任何一项不达标，回头改。

关键原则

如果你写的某句话，让你想象中的"用户本人"忍不住想加个括号补刀、加个"……"叹气、或者把整个加粗去掉——那这句话就还没改到位。

用户的写作不是"清晰传达观点"，是"老朋友坐你对面，端着茶杯吐槽"。每次想用 AI 式的修辞强化时，问自己：茶歇时会这么说吗？

Verification

• 主题已确认，素材已收集
• 大纲已经用户确认
• 文件已保存到指定路径
• 文件已通过飞书发给用户审阅
• frontmatter 格式正确（title, date, tags）
• 字数在目标范围内（默认 3000-6000）
• L1/L2/L3 润色检查全部通过
• 风格符合 Style Guide（非通用 AI 输出）
• 如果属于系列，前文衔接和后文预告已包含
• 已过「发布前定稿」12 条修改清单 + 6 项 grep 自检
• 加粗数量 ≤ 5 处，"咱们"出现 ≥ 5 处，省略号密度合理
• 引言后已附 GitHub/资源链接（"太长不想看"友好）
• 总结段无 bullet 式逐篇回顾
• 章节末有"生活化锚点"（具体作品/具体困惑）而非纯方法论金句