# Kakarot Writer > 用户要求写文章、按我的风格写、改稿或图解文章时使用；为 Kakarot 制作公众号与跨平台母稿，含按需图解、标题与封面。只要标题或摘要时不生成全文。 - Skill: `zhangs-11/kakarot-writer` (Agent Skill, multi-file: 17 files) - Install (CLI): `npx skillmds@latest add zhangs-11/kakarot-writer` - Raw SKILL.md: https://api.skillmd.com/api/skills/zhangs-11/kakarot-writer/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: Coding & Dev Tools - Author: Zhangs-11 (https://skillmd.com/u/zhangs-11) - Updated: 2026-09-17 - Page: https://skillmd.com/skills/zhangs-11/kakarot-writer --- # 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` 从这份母稿派生；派生稿不能另起观点、增删事实或重写作者立场。平台标签、摘要、封面尺寸和视频结构属于发布形态，可以分别准备。 生成成品不等于发布。只有用户明确说“存到公众号”“发到草稿箱”或“发布”时，才调用发布工具写入外部系统。 母稿文件必须区分三层：标题和作者等元数据、读者真正看到的公开正文、只供交付与发布使用的内部附录。正文不写 `# 一级标题`，标题由发布参数单独传入；截图清单、封面文件、备选标题、事实确认项等内部内容统一放在精确标记 `` 之后。发布工具只能消费标记之前的公开正文。 ## 第一步：建立写作契约 动笔前在内部回答： 1. Kakarot 为什么现在想写这件事。 2. 他与这件事真实发生过什么关系。 3. 读者是谁，刚知道什么，下一步最自然会问什么。 4. 手里有哪些动作、数字、时间、原话、失败、代价、截图和来源。 5. 哪个判断是全文真正想让读者相信的。 6. 哪些内容只是推测，哪些需要研究或向用户确认。 7. 这篇更接近哪种文章原型。 8. 读完后，读者能改变哪个判断，或者今天能做什么。 把答案整理成简短的正文 brief，不原样展示给用户。 材料不按固定数量机械计数。判断标准是每个主要部分有没有真实东西托住。同一个观点换几种说法不算新材料。 材料不足时： - 公开事实能查到就先研究并记录来源。 - 私人经历不可检索时，一次集中问最多三个问题。 - 用户明确不想补材料时，缩小范围或缩短文章。 - 不用模型临时想出的“典型人物”、假对话、假动作和假情绪补篇幅。 ## 第二步：选择文章原型 选择原型前，先执行 `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 图片”设成所有题目的单一答案： - 产品体验、教程、新闻、数据和工具文章，把真实截图、实拍照片和官方材料作为证据层。 - 解释关系、流程、责任交接或对比时，按 visual-storytelling.md 制作可编辑、可核对的图；不受氛围图的一至两张建议限制。 - 抽象主题的无字主视觉按需使用，一篇通常不超过一至两张；它不能代替解释图，也不能充当事实证据。 完整文章默认制作封面。若 `guizang-social-card-skill` 可用，调用它分别制作 `21:9` 主封面和 `1:1` 分享封面。AI 路线默认使用“图像生成工具生成无字、无 Logo、无假 UI 的主题主视觉，再由 HTML/CSS 独立排版两个比例”，不要让图像模型一次性生成带中文标题的成品海报，也不要把横版机械裁成方形。详细选择和回退规则见 `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` 或其他长期规则；确认后做最小更新，用正向案例与反例检查适用范围；区分人工走读与实际运行，不把文档关键词断言当作行为验证。