# 写作系统改造方案 ## 目标 当前项目已经具备三条基础链路： - `writing/`：文章探索、结构、成稿的写作辅助流程 - `wurank-blog/`：Hugo 博客内容管理与静态站点生成 - `wurank-blog/publish.py`：将 Hugo Markdown 同步到掘金、知乎、少数派草稿 本方案的目标不是把项目改造成公众号运营系统，也不是照搬 WeWrite 的热点、SEO、视觉生成和微信发布能力，而是吸收其中真正适合当前项目的部分： - 作者风格可结构化描述 - 人工修改可沉淀为长期规则 - 发布前检查可标准化 - 写作流程可以持续贴近作者本人 最终形成一条更稳定的个人博客生产链路： ```text 想法/草稿 ↓ 写作流程 ↓ 作者画像 + 修改学习 + 发布前检查 ↓ Hugo 文章 ↓ 多平台草稿同步 ``` ## 设计原则 ### 保持个人博客定位 当前项目的文章更偏个人思考、经验沉淀、产品/技术理解，不以追热点、标题点击率或公众号增长为第一目标。 因此不引入以下能力： - 热点抓取 - SEO 评分 - 标题点击率优化 - AI 检测规避 - 多 persona 写作人格 - 微信 API 草稿箱发布 ### 只借鉴长期有效的部分 WeWrite 中最值得借鉴的是三类机制： - `style.yaml`：结构化表达账号/作者定位 - `learn-edits`：从人工修改里学习偏好 - `check/review`：发布前按固定标准检查文章 这些机制可以服务当前项目的根本问题：每次写作不从零开始理解风格，历史修改能变成未来写作的约束。 ### 先轻量落地，再逐步自动化 第一阶段优先新增文档和规则文件，不急于写复杂脚本。 只有当规则稳定、流程跑通后，再实现 diff 学习、发布检查、配置化发布等自动化能力。 ## 目标目录结构 建议在 `writing/` 下新增长期维护文件： ```text writing/ ├── author-profile.yaml ├── playbook.md ├── review-checklist.md ├── lessons/ │ └── 2026-xx-xx-xxx.yaml ├── scripts/ │ ├── learn_edits.py │ ├── review_article.py │ └── sync_article_pair.py └── skills/ └── blog-writing/ ├── SKILL.md └── references/ ├── context.md └── style.md ``` 建议在 `wurank-blog/` 下新增发布配置： ```text wurank-blog/ └── publish-config.yaml ``` ## 模块一：作者画像 ### 文件 `writing/author-profile.yaml` ### 作用 把作者长期稳定的写作偏好从提示词中抽离出来，变成写作、检查、学习都能读取的结构化配置。 ### 建议内容 ```yaml author: name: "wurank" site: "https://blog.wurank.top" writing_position: core_themes: - 自我认知 - 思考 - 产品思维 - AI 编程 default_voice: "第一人称，克制，经验先于判断" article_goal: "把一个真实困惑写清楚，而不是给读者提供标准答案" style_rules: opening: "从具体场景或轻微不适开始，不从概念定义开始" structure: "段落之间必须有因果推进，不做并列补充" conclusion: "结论从经验里长出来，不提前亮明" headings: "优先使用 一、二、三 这类自然分节" quote_blocks: "只用于值得停下来的句子" avoid: phrases: - "本质上" - "综上所述" - "不是...而是..." patterns: - "替读者下判断的我们句" - "概念先行" - "漂亮但过早的总结句" ``` ### 使用方式 `blog-writing` skill 在以下阶段读取该文件： - 阶段一探索：判断选题是否贴合长期主题 - 阶段二结构：检查结构是否从具体经验推进 - 阶段三成稿：约束语气和表达 - 阶段四生成文件：辅助选择 tags 和 description ## 模块二：修改学习 ### 文件 - `writing/playbook.md` - `writing/lessons/*.yaml` - `writing/scripts/learn_edits.py` ### 作用 把用户对文章的人工修改沉淀为长期规则，让系统下一次写作时提前避开同类问题。 ### 数据来源 当前项目已经天然有两类材料： - `wurank-blog/base/*.txt`：原始草稿 - `wurank-blog/content/posts/*.md`：发布稿 可以对比这两类文件，提取修改模式。 ### lesson 记录格式 ```yaml date: "2026-04-27" draft: "wurank-blog/base/自由是可以选择在意.txt" final: "wurank-blog/content/posts/2026-04-23-freedom-to-care.md" patterns: - key: "concrete_before_concept" type: "structure" description: "发布稿把抽象判断后移，先补了具体场景" rule: "先写具体动作或场景，再写抽象判断" - key: "avoid_early_summary" type: "tone" description: "删除或后移了前三段中过早总结全文的句子" rule: "不要在前三段给出全文结论" ``` ### playbook 规则格式 ```yaml rules: - key: "concrete_before_concept" type: "structure" rule: "先写具体动作或场景，再写抽象判断" confidence: 6 occurrences: 4 last_seen: "2026-04-27" - key: "avoid_early_summary" type: "tone" rule: "不要在前三段给出全文结论" confidence: 5 occurrences: 3 last_seen: "2026-04-27" ``` ### 触发方式 用户说： ```text 学习这次修改 ``` 系统执行： 1. 找到对应的草稿和发布稿 2. 对比正文差异 3. 提取修改模式 4. 写入 `lessons/` 5. 更新 `playbook.md` ### 规则强度 - `confidence >= 5`：硬规则，写作时必须遵守 - `confidence 3-5`：软规则，优先参考 - `confidence < 3`：暂不强制，避免一次性偏好污染长期风格 ## 模块三：发布前检查 ### 文件 `writing/review-checklist.md` ### 作用 在文章进入 `content/posts/` 或同步外部平台前，用固定标准检查质量，减少每次临场判断。 ### 检查维度 #### 结构检查 - 每一节是否被上一节逼出来？ - 是否存在只是“补充说明”的并列段？ - 是否提前给出最终结论？ - 是否有段落可以删除而不影响主线？ #### 风格检查 - 开头是否从具体经验、动作、物件或轻微不适出发？ - 是否从概念定义开始？ - 是否有抽象名词堆砌？ - 是否有替读者下判断的“我们/你”句？ - 是否有“不是 A 而是 B”的对仗句？ #### 材料检查 - 是否至少有一个具体时间、地点、物件、动作或身体感？ - 抽象判断前是否有经验支撑？ - 关键结论是否从前文自然长出来？ - 结尾是否回到开头的问题，而不是口号式总结？ #### 发布检查 - front matter 是否完整？ - `title`、`date`、`description`、`tags` 是否符合 Hugo 格式？ - slug 是否稳定、可读？ - 外部平台后缀是否会正确加入？ ### 输出格式 ```text 通过： - ... 需要改： - 第 X 段：问题是什么，建议怎么改 阻塞发布： - ... ``` ## 模块四：写作 skill 改造 ### 文件 `writing/skills/blog-writing/SKILL.md` ### 改造目标 让写作流程不再只依赖静态提示词，而是读取项目内的作者画像、历史规则和检查清单。 ### 阶段读取规则 #### 阶段一：探索 读取： - `writing/author-profile.yaml` - `writing/skills/blog-writing/references/context.md` 目标： - 判断输入是否贴合长期主题 - 找出核心张力 - 判断是否缺具体经验 #### 阶段二：确认结构 读取： - `writing/author-profile.yaml` - `writing/playbook.md` - `writing/skills/blog-writing/references/style.md` 目标： - 确认结构是否有因果推进 - 避免历史上反复出现的问题 - 删除只是补充说明的章节 #### 阶段三：成稿 读取： - `writing/author-profile.yaml` - `writing/playbook.md` - `writing/skills/blog-writing/references/style.md` 目标： - 按作者声音写完整文章 - 确保段落从经验生长 - 不提前给出结论 #### 阶段四：生成发布文件 读取： - `writing/author-profile.yaml` - `writing/review-checklist.md` 目标： - 生成 Hugo front matter - 建议 slug - 选择 tags - 输出可放入 `wurank-blog/content/posts/` 的 Markdown ### 新增口令 建议在现有口令基础上增加： ```text 检查一下 ``` 执行发布前检查。 ```text 学习这次修改 ``` 对比草稿和终稿，更新 playbook。 ## 模块五：发布配置化 ### 文件 `wurank-blog/publish-config.yaml` ### 作用 把 `publish.py` 中的硬编码配置外置，降低后续调整成本。 ### 建议内容 ```yaml blog: base_url: "https://blog.wurank.top" browser: cdp_url: "http://localhost:9222" platforms: enabled: - juejin - zhihu - sspai external_suffix: enabled: true template: | 原文链接：{source_url} 更多文章见个人博客：{blog_url}/ ``` ### 改造要求 - 缺少配置文件时直接报错 - 配置字段缺失时直接报错 - 不自行猜默认值 - 保持现有命令兼容 示例： ```bash python publish.py content/posts/xxx.md --platforms juejin,zhihu ``` ## 实施阶段 ### 阶段一：文档化和规则化 目标： 先建立最小闭环，不改发布脚本。 交付： - `writing/author-profile.yaml` - `writing/playbook.md` - `writing/review-checklist.md` - 改造 `writing/skills/blog-writing/SKILL.md` 验收： - 新写文章时能读取作者画像 - “检查一下”能按固定标准输出问题 - 现有 Hugo 和发布流程不受影响 ### 阶段二：修改学习 目标： 从历史草稿和发布稿中提取风格偏好。 交付： - `writing/scripts/learn_edits.py` - `writing/lessons/` - `playbook.md` 更新机制 验收： - 输入一组草稿和发布稿，能输出修改模式 - 能区分一次性修改和反复偏好 - 不把低置信度规则写成硬约束 ### 阶段三：发布前自动检查 目标： 将发布前检查从人工判断变成稳定流程。 交付： - `writing/scripts/review_article.py` - front matter 检查 - 风格检查 - 发布后缀检查 验收： - 对已有文章运行检查，能指出具体问题 - 格式错误直接失败 - 不用默认值兜底 ### 阶段四：发布配置化 目标： 降低 `publish.py` 后续维护成本。 交付： - `wurank-blog/publish-config.yaml` - `publish.py` 读取配置 - 原命令兼容 验收： - 原有发布命令仍可运行 - 配置缺失时错误清楚暴露 - 平台列表、博客地址、后缀文案可通过配置调整 ### 阶段五：可选增强 以下能力不是第一优先级： - 自动生成英文 slug - 自动建议 tags - 自动生成发布日志摘要 - 检查外部平台草稿是否真实写入标题和正文 - 迁移 `cose` 中更成熟的平台适配思路 ## 推荐执行顺序 1. 新增 `author-profile.yaml` 2. 新增 `playbook.md` 3. 新增 `review-checklist.md` 4. 改造 `blog-writing/SKILL.md` 5. 实现 `learn_edits.py` 6. 实现 `review_article.py` 7. 新增 `publish-config.yaml` 8. 改造 `publish.py` ## 验收标准 ### 写作侧 - 能从一句想法进入探索流程 - 能根据作者画像判断选题是否偏离 - 能按 playbook 避免历史高频问题 - 能输出符合 Hugo 格式的 Markdown ### 学习侧 - 能建立草稿和发布稿的对应关系 - 能提取结构、语气、表达、删改偏好 - 能累计规则置信度 - 低置信度规则不会污染长期约束 ### 发布侧 - 发布配置集中管理 - CDP 地址、平台列表、博客地址、外部后缀可配置 - 配置错误直接暴露 - 原有发布命令兼容 ## 风险和处理 ### 风险一：规则过多导致写作变僵 处理： - `playbook.md` 只放反复出现的偏好 - 一次性修改只进入 `lessons/` - 低置信度规则不作为硬约束 ### 风险二：过度学习旧文章风格 处理： - 规则保留 `last_seen` - 长期未出现的低置信度规则可以衰减 - 用户可以手动删除不再适用的规则 ### 风险三：检查脚本变成泛泛建议 处理： - 输出必须定位到具体段落 - 每条建议必须说明删掉或保留会发生什么 - 没有具体问题就写“无”，不强行挑刺 ### 风险四：发布配置化破坏现有流程 处理： - 最后阶段再改 `publish.py` - 保持原命令兼容 - 改造前先用现有文章做回归测试 ## 不做事项 本方案明确不做： - 公众号热点选题系统 - SEO 自动优化 - 微信 API 发布 - 标题党生成 - 视觉封面生成 - AI 检测绕过 - 多账号矩阵管理 这些能力和当前个人博客目标不一致，会增加复杂度并稀释作者声音。 ## 最小可行版本 如果只做一版，建议只做以下四件事： 1. `writing/author-profile.yaml` 2. `writing/playbook.md` 3. `writing/review-checklist.md` 4. 改造 `writing/skills/blog-writing/SKILL.md` 这一版不需要脚本，也不影响发布流程，但已经能让写作助手从“静态提示词”变成“读取项目规则的协作者”。 ## 最终效果 改造完成后，完整工作流如下： ```text 用户：我有个想法 ↓ 读取 author-profile，判断主题和核心张力 ↓ 用户：确认结构 ↓ 读取 playbook，避免历史结构问题 ↓ 用户：开始成稿 ↓ 按作者画像和历史规则写正文 ↓ 用户：检查一下 ↓ 按 review-checklist 做发布前检查 ↓ 用户：生成发布文件 ↓ 生成 Hugo Markdown ↓ 用户：学习这次修改 ↓ 从人工终稿更新 playbook ↓ 运行 publish.py ↓ 同步到外部平台草稿 ``` 长期看，系统每次都能从真实修改中积累一点偏好，下一篇文章就少犯一点旧问题。