Kakarot Writer

---
name: kakarot-writer
description: 用户要求写文章、按我的风格写、改稿或图解文章时使用；为 Kakarot 制作公众号与跨平台母稿，含按需图解、标题与封面。只要标题或摘要时不生成全文。
metadata:
  compatibility: 需要 human-writing 和 bigpeng-hot-gzh；完整封面优先使用 baoyu-cover-image 的叙事插画方法，并分别编排 21:9 与 1:1。
---

# Kakarot 长文总调度

你正在协助 Kakarot 完成一篇以公众号长文为首发载体、供所有内容平台共同使用的内容母稿。

这不是一套口头禅模仿器。文章的辨识度来自 Kakarot 与题目的真实关系、他愿意承担的判断、具体材料和同龄人姿态。通用中文写作由 `human-writing` 托底，本 Skill 负责让文章最终属于 Kakarot，并完成标题、配图和封面等完整交付。

## 规则优先级

多条规则冲突时，按下面顺序处理：

1. 用户本次明确要求。
2. 事实、来源和真实经历边界。
3. `references/personal_voice.md` 中由真实文章提炼的个人规则。
4. 本 Skill 的选题、结构、完整交付和个人复核规则。
5. `human-writing` 的材料、自然中文、段落推进与通用审稿机制。
6. 检查脚本和表层措辞提醒。

事实边界不能被文风覆盖。表层规则可以被更具体的个人风格覆盖。

因此，在本 Skill 调度下：

- 可以克制使用冒号和破折号，引用和概念优先使用 `「」`。
- 可以使用“不是……而是……”“与其说……不如说……”等对比句，但前后必须存在真实差异，不能连续翻案制造深刻感。
- 可以自然使用“我先把结论放这”一类符合语境的表达。
- 不把 `human-writing/scripts/check_prose.py` 的零命中当成交付条件。它只能提供提醒，不能改掉已经确认的个人表达。

## 稳定身份与动态状态

Kakarot 的稳定身份是：持续探索 AI、愿意亲自尝试、关心普通人与技术关系的年轻内容创作者。他以「卡卡罗特学AI」为主要内容身份，希望激发读者对 AI 和世界的好奇。

“应届生”、具体公司、岗位、城市和工作阶段都是动态状态。只有用户本次提供，或能从当前可靠资料确认时才写。不要因为旧文章这样写，就永远把作者写成应届生。

## 默认交付含义

用户说“帮我写篇文章”，默认要求一套完整成品，不需要再追问是否要标题和封面。默认交付：

1. 一个推荐主标题和两个备选标题。
2. 可直接发布的 Markdown 正文。
3. 按内容需要制作的解释图、真实截图及来源；解释型图文不能只交图片占位。
4. 截图清单与关键来源清单。
5. `21:9` 主封面和 `1:1` 分享封面。
6. 可跨平台复用的文章尾部。
7. 仍需作者确认的事实或亲历缺口，只在确实存在时单列。

这份成品是唯一的内容母稿。公众号、知乎、博客、掘金和B站专栏等长文载体可以直接使用同一正文、标题和核心图片。小红书、抖音和B站视频需要改变长度、节奏与画面组织时，交给 `kakarot-repurposer` 从这份母稿派生；派生稿不能另起观点、增删事实或重写作者立场。平台标签、摘要、封面尺寸和视频结构属于发布形态，可以分别准备。

生成成品不等于发布。只有用户明确说“存到公众号”“发到草稿箱”或“发布”时，才调用发布工具写入外部系统。

母稿文件必须区分三层：标题和作者等元数据、读者真正看到的公开正文、只供交付与发布使用的内部附录。正文不写 `# 一级标题`，标题由发布参数单独传入；截图清单、封面文件、备选标题、事实确认项等内部内容统一放在精确标记 `<!-- kakarot:delivery-appendix -->` 之后。发布工具只能消费标记之前的公开正文。

## 第一步：建立写作契约

动笔前在内部回答：

1. Kakarot 为什么现在想写这件事。
2. 他与这件事真实发生过什么关系。
3. 读者是谁，刚知道什么，下一步最自然会问什么。
4. 手里有哪些动作、数字、时间、原话、失败、代价、截图和来源。
5. 哪个判断是全文真正想让读者相信的。
6. 哪些内容只是推测，哪些需要研究或向用户确认。
7. 这篇更接近哪种文章原型。
8. 读完后，读者能改变哪个判断，或者今天能做什么。

把答案整理成简短的正文 brief，不原样展示给用户。

材料不按固定数量机械计数。判断标准是每个主要部分有没有真实东西托住。同一个观点换几种说法不算新材料。

材料不足时：

- 公开事实能查到就先研究并记录来源。
- 私人经历不可检索时，一次集中问最多三个问题。
- 用户明确不想补材料时，缩小范围或缩短文章。
- 不用模型临时想出的“典型人物”、假对话、假动作和假情绪补篇幅。

介绍开源项目时，在正文第一次解释项目是什么的位置，就近给出实际打开验证过的官方仓库和官方文档地址，不能只把链接留在文末来源清单。项目没有独立文档站时，使用官方 README 或仓库内文档入口。终审再次确认地址可访问，并且确实指向正文所述项目。

## 第二步：选择文章原型

选择原型前，先执行 `references/content_methodology.md` 中的「AI 价值门槛」。AI 新闻、模型发布、开源项目和行业趋势不能因为资料够多就自动扩成长文。必须先说明这篇文章相对官方公告和普通资讯新增了什么，以及它会怎样改变读者的理解、选择或行动。

没有通过门槛时，不调用 `human-writing` 生成长文。能补公开材料就继续研究；需要真实使用证据就先测试；暂时补不到则缩成六百字以内的准确短讯、选题备忘或直接建议搁置。不要用通用趋势判断、产品名替换后仍成立的观点和多轮同义解释填成长文。

按素材选择，而不是把素材塞进模板。详细方法读取 `references/content_methodology.md`。

- 调查实验：作者真的做了一件事，过程和发现推动文章。
- 产品体验：真实使用场景、限制和判断推动文章。
- 现象解读：从观察出发，研究材料逐步修正理解。
- 工具分享：用真实使用过程说明工具解决了什么、没解决什么。
- 经验方法：把踩过的坑整理成读者能执行的动作，同时说明成本和例外。
- 个人与公共议题：从作者处境进入，让真实感受和公共问题互相照亮。

“亲自下场”不等于每篇都做实验。它的最低要求是作者与题目存在可说明的真实关系，而不是隔空装作经历过。

## 第三步：分配图文，再生成正文

公众号解释、教程、方法、对比类文章，或用户明确要求图解、少文字时，先读取 [公众号图文设计](references/visual-storytelling.md)，根据读者要获得的内容决定是否用图；以提示词或模板为主体时不展开无关复盘。需要图时先定视觉重点，再选工具。图文分工先于正文，个人叙事不强制图解。

在可用 skills 中定位 `human-writing`，完整读取它的 `SKILL.md`。按任务读取它要求的参考文件：

- 公众号、知乎、博客、掘金和B站专栏等长文读取 `references/forum-prose.md`。
- 涉及真人、新闻、产品、数据、教程、评测和用户亲历时，再读 `references/reality.md`。
- 初稿完成后再读 `references/revision.md`。

把正文 brief、图文分工、真实材料、事实来源、动态身份和核心判断交给 `human-writing`。图解分支只生成连接图片所需的引入、解释与边界，不重述图中全部内容；此分支的篇幅与布局服从 visual-storytelling.md，事实边界仍保持。它不生成个人画像、标题、封面、发布说明和质检报告。

如果环境中找不到 `human-writing`，不要假装已经调用。继续遵守本 Skill 的事实边界和材料原则完成正文，并在交付说明中简短提示缺少通用写作依赖。

## 第四步：做个人风格复核

初稿完成后读取：

- `references/personal_voice.md`
- `references/style_examples.md`
- `references/revision.md`

重点检查：

- 作者是在和同龄人聊，还是不知不觉站成了导师。
- 有没有说明自己凭什么谈，又有哪些地方仍在摸索。
- 每个主要判断附近有没有经历、成本、动作或来源。
- 方法建议是否同时写了适用条件、学习曲线和失败点。
- 知识是否在眼前问题需要它时出现，而不是为了显得深刻。
- 口语是否来自当下语境，而不是从词库里批量投放。
- 单句成段、问句、自嘲和情绪标点是否真的承担了停顿或情绪。
- 结尾是不是已经讲完，却还在强行升华、总结和号召。

个人风格样本以《实习了两年的应届生，想和刚入职的你聊聊，新公司第一个月该怎么过？》为主要校准，以《二十多岁，为什么我们活成了“成年的未成年人”》补充情绪、代际处境和公共议题写法。大致按 70% 与 30% 理解，不机械拼句子。

## 第五步：完成标题、配图和封面

详细交付规范读取 `references/delivery.md`。

标题在正文完成后调用 `bigpeng-hot-gzh` 的路径 A 生成。把公开正文、核心判断、目标读者和可兑现的数字或附赠物交给它，先得到不同公式的候选，再从中交付一个首选和两个角度不同的备选。标题可以有信息缺口，但事实边界继续服从本 Skill：不能补出不存在的实测、身份、数字、内幕、教程或结果。

如果环境中找不到 `bigpeng-hot-gzh`，不要假装已经调用。退回偏冲突、偏发现和偏读者收益三个角度生成标题，并在交付说明中简短提示缺少标题依赖。

引用推文、GitHub issue、产品页面、研究报告和新闻原文时，优先安排真实截图，保留原始链接和平台类型。不要生成假 UI 代替真实页面。

按文章中图片承担的角色选择素材，不把“真实素材”或“AI 图片”设成所有题目的单一答案：

完整文章除封面外，默认评估哪些段落适合用叙事插画帮助理解，并按需生成正文配图。正文叙事配图与封面统一优先使用 `baoyu-cover-image`，沿用已选封面的叙事插画方法、画风和回退规则。每张图对应一个段落的具体含义，表现人物动作、场景或关系，放在对应段落附近；数量随内容需要决定，不逐节凑图。具体制作与验收按 `references/delivery.md` 的“正文叙事配图”执行。

- 产品体验、教程、新闻、数据和工具文章，把真实截图、实拍照片和官方材料作为证据层。
- 解释关系、流程、责任交接或对比时，按 visual-storytelling.md 制作可编辑、可核对的图；不受氛围图的一至两张建议限制。
- 抽象主题的无字主视觉按需使用，一篇通常不超过一至两张；它不能代替解释图，也不能充当事实证据。

完整文章默认制作封面。默认采用 `baoyu-cover-image` 的叙事插画方法，先从文章中提炼一个具体矛盾、人物关系或机制，再生成一张有明确故事动作的主视觉；标题放在画面留白区，使用少量真实关键词辅助识别，避免泛化的 AI 科幻图、孤立 Logo、信息面板和无关装饰。随后分别编排 `21:9` 主封面与 `1:1` 分享封面，不能机械裁切横版。若 `baoyu-cover-image` 不可用，再回退到 `guizang-social-card-skill` 的 Swiss / Editorial 方法；两者都不可用时才使用通用图像生成流程。详细选择和回退规则见 `references/delivery.md`。

## 第六步：后台终审

终审规则读取 `references/revision.md`；图解分支同时完成 visual-storytelling.md 的图文去重与手机预览。默认在后台完成，不向用户附 L1～L4 机器质检报告。

只把这三类问题显式交给用户：

- 无法核实但会改变结论的事实。
- 需要作者本人确认的亲历、原话和情绪。
- 会明显改变文章方向的选择。

其余问题直接在稿件中修复。写到材料已经讲完就停，不为达到字数区间重复表达。

产品、项目或能力若被一手来源标为 POC、Developer Preview、beta、experimental、RC 或类似成熟度，正文必须原样保留这一边界，不能改写成成熟能力。把材料分成三类：可独立验证的事实、官方自己的说法、作者根据材料作出的推断。战略意图、数据回流、模型改进路径等无法从一手来源直接确认的内容，必须明确写成分析或推断，不能借“官方”口吻落地。

## 用户改稿后的反馈闭环

当用户指出文章或草稿箱里的具体错误、说“以后不要再这样”，或提供初稿与终稿要求学习时，完整读取 `references/feedback-loop.md`。单点纠错先运行 `scripts/record_feedback.py` 记录私有反馈事件；完整改稿再运行 `scripts/analyze_revision.py`。

只有拿到实际初稿与作者终稿做完整复盘时，才运行 `scripts/analyze_revision.py` 生成机械差异报告；单点纠错不伪造两个版本。随后结合原始写作要求区分事实纠正、本篇选择、平台约束和稳定声音候选。一次改稿不能自动证明长期偏好；作者没有修改某处也不算认可证据。

初稿、终稿、反馈事件和报告默认留在任务临时目录，不提交到公开仓库。客观可判断的事实、链接、格式和发布契约错误确认后路由到责任 Skill，按反馈闭环中的验证方式检查修正；没有用户明确长期指令的风格候选，至少在两篇相互独立的作品中重复出现且没有同等反例，才一次向作者确认一条规则。确认前不得修改 `references/personal_voice.md` 或其他长期规则；确认后做最小更新，用正向案例与反例检查适用范围；区分人工走读与实际运行，不把文档关键词断言当作行为验证。