maomomo-article-writer/SKILL.md

217 lines
20 KiB
Markdown
Raw Blame History

This file contains ambiguous Unicode characters!

This file contains ambiguous Unicode characters that may be confused with others in your current locale. If your use case is intentional and legitimate, you can safely ignore this warning. Use the Escape button to highlight these characters.

---
name: maomomo-article-writer
description: 生成或优化符合 maomomo / 猫MOMO 风格的中文出海金融实操文章、发布用 Markdown、SEO 稿、配图规划、独立高清配图 assets 和 ZIP 发布包。适用于 maomomo.com、港卡、香港银行、香港信用卡、美股券商、数字货币、汇款、支付优化、返现活动、开户教程、保号教程、避坑经验、官方条款整理和实测攻略。用户要求使用 skill、按猫MOMO风格、完整文章、发布用 Markdown、配图、打包、一键下载或最终交付时触发。
---
# MAOMOMO 文章生成器
本技能用于把主题、资料、链接、PDF、截图或已有 Markdown 转成 MAOMOMO / 猫MOMO 风格的中文实操文章,并在需要时交付可发布文件包。
文章要像一手整理的出海金融攻略:结论靠前、步骤清楚、坑点明确、语气轻松但不轻浮。涉及金融、活动、合规、费用、奖励、账户规则和数字货币时,必须谨慎核查并避免承诺式表达。
## 使用边界
适合:
- 银行、港卡、香港信用卡、券商、数字货币、汇款、支付、账户维护、返现和羊毛活动。
- 活动规则整理、开户教程、转账 / 入金 / 出金教程、保号方案、用卡姿势、对比总结、避坑经验。
- 已有文章 SEO 优化、发布用 Markdown、配图规划、独立配图、ZIP 打包和后续改稿。
不适合:
- 给出投资、法律、税务或合规结论。
- 承诺一定获批、一定到账、稳赚、无风险、绝对安全。
- 伪造真实 App 截图、账单、错误或未经核对的官方 Logo 使用场景,或用户没有提供的实测证据。
## 硬性约束
- 如果本技能任何旧规则与“确认优先、单步推进”的流程冲突,以本节和“默认工作流”中的阶段门禁为准。
- 确认优先,单步推进;不要一上来就完整生成文章、全部配图或 ZIP。
- 读写 Markdown、JSON、CSV、HTML、代码或文本文件时显式使用 UTF-8。
- 处理用户上传或提供的 Markdown / PDF / 官方链接 / 参考文章时,必须先完整读取或说明无法读取的部分,再写最终稿。
- 费用、活动日期、奖励门槛、账户规则、返现、券商迎新、转账路径、数字货币出入金和合规事项,必须优先核查最新信息。优先级:用户提供的最新官方材料 > 官方页面 / 条款 PDF / App 显示 > 用户实测 > MAOMOMO 旧文 > 其他参考。
- 没有被确认的数字、日期、奖励、链接、邀请码、产品名和规则,不得编造;可用 `【待确认:...】` 标出缺口。
- 用户素材包含明确“实测”结果时,必须用确定语气写结论;包含“以往惯例”“过往尿性”“过往经验”等历史依据时,必须用“大概率 / 按过往案例判断”的强概率语气,不要降级成“可能 / 疑似 / 大概”。
- 写作前必须先给用户确认标题或标题方向、文章核心口径、`outline.md` 大纲、来源缺口、必选素材映射和配图风格。用户明确要求跳过确认时,未确认事实仍必须标 `【待确认:...】`
- 大纲未确认前,不得创建最终 `deck_spec.json`、`speech.md`、图片 prompt jobs、文章配图图片、ZIP 或用户指定的最终文章包。
- 出图前必须先把全部图片 prompt 写入文件,包含文件名、用途、放置位置、核心文案、完整 prompt 和依赖素材;不要在聊天里输出超长 prompt。
- 图片 prompt 中的视觉风格只能作为后台画面描述不得成为画面文字prompt 必须限制可见文字只包含指定业务文案、`MAOMOMO` 和已核对允许出现的品牌 / 支付标识不得出现风格标签、prompt 描述、额外 slogan 或无关文字。
- 发布稿、图片文案、prompt、manifest 和 `deck_spec.json` 中金额统一写 `HKD`,不要使用港币符号;来源原文抽取文件可保留原文写法。
- 金融活动配图如出现信用卡、支付卡、卡组织、支付网络或机构 Logo必须按官方材料或用户素材核对并记录来源用户没有提供 Logo / 卡面素材但画面需要品牌或支付标识时,应主动尽力从官方活动页、品牌资源页、条款 PDF、App / 官网截图等来源查找准确标识,保存到 `sources/` 并记录来源。不得把银联 / UnionPay 画成 Mastercard、Visa 等其他卡组织。已核对正确的 Mastercard / Visa / UnionPay / 银行 / 支付宝等标识可以辅助出现,但不能抢占或替代 `MAOMOMO` 主标识位置。
- 先只生成一张代表性风格确认图,优先封面图,保存为正式命名,例如 `origin_image/hsbc-mastercard-alipay-campaign-01-cover.png`。用户批准样张前不得批量生成剩余图片。
- 样张批准后,后续每张图片必须继承同一个生图后端、同一套视觉系统和同一种质量配置;不得为了加快速度擅自改成 `low`
- 每张最终图片必须来自确认后的图片生成后端:当前 agent 的内置图片生成工具,或用户确认后的 `scripts/maomomo_image_gen.py` API/CLI fallback。不得用 Playwright、HTML/CSS、SVG、Pillow、canvas、本地拼贴或手工文字覆盖冒充最终生成图。例外用户提供真实银行 / 券商 / 钱包截图且需要上传图片 API 做编辑时,必须先向用户确认实际 API 地址 / baseURL、接口归属和是否允许外发该 API 可能是用户自有兼容服务,不能默认按公共第三方处理。若未确认、确认不允许或安全策略不允许上传,则先用图片后端生成不含真实截图的空白模板,再在本地把原截图完整嵌入模板;本地步骤只能做排版嵌入、圆角、阴影和尺寸适配,不得改动截图内金额、日期、姓名、账号、交易描述等关键内容,并必须在状态文件和最终回复说明这是“图片后端模板 + 本地嵌入真实截图”的混合流程。
- 生成图片按“一张图一个 job / 一次请求 / 一次 QA”推进通过 QA 后才用状态脚本记录 result 并同步到 `assets/`,不能只生成到 `origin_image/` 后声称完成。运行环境支持子 agent 时,样张通过后可以一图一个子 agent 并发处理;每个 dispatch、结果和 blocker 都必须写入状态文件,不能只靠聊天说明。
- 完整交付模式下,不能只在聊天里输出正文;必须生成 Markdown 文件、`assets/` 目录和 ZIP 包,除非用户明确说只要文字、只要大纲、不要图片、不要打包或先不生成文件。
- 配图文件必须是独立 PNG不要用一张大拼图代替多张图不要只给提示词冒充图片文件。
- 后续改稿必须更新文件本体;影响图片、来源区、标题、摘要或 ZIP 时同步更新。
## 可见进度
复杂任务使用一个用户可见 checklist并且同一时间只推进一个步骤
1. 读取资料,整理来源状态和事实表。
2. 确认标题、核心口径、`outline.md` 大纲、素材映射、配图风格和生图后端。
3. 写作或优化发布用 Markdown。
4. 输出全部图片 prompt 文件和图片任务状态文件。
5. 生成并确认一张样张。
6. 逐张生成剩余图片并记录 dispatch / result / blocker。
7. QA、返修、生成 `speech.md` 或备注稿。
8. 打包并交付最终文件。
不要因为聊天里说“已完成”就标记完成;用实际文件、已读取来源、已生成图片和 ZIP 作为完成证据。
## 默认工作流
一句话版:读资料 -> 给标题 / 大纲 / 风格让用户确认 -> 写文章 -> 输出图片 prompts 文件让用户改 -> 先出一张图确认 -> 逐张生成剩余图 -> QA -> 打包交付。
1. 判断任务模式。
- 完整交付、只要大纲、只要正文、只要配图、SEO 优化、改稿更新、小红书发布版。
- 判断是否涉及金融 / 活动 / 合规事实核查。
- 完整交付或打包任务先读 `references/delivery-rules.md`;需要配图时先读 `references/visual-assets.md`
2. 读取源材料并建立事实表。
- 先读用户提供的官方页面、PDF、旧文、参考链接、截图或素材不先动手写最终稿。
- 涉及官方规则、活动或金融产品时,先读 `references/source-and-fact-check.md`
- 列出所有来源的已读 / 未读 / 无法读取状态。
- 明确区分:已官宣事实、用户实测、过往惯例判断、待确认内容。
- 确认主题、目标读者、文章目标、章节数量或图片数量、品牌 / 风格限制,以及必须放入文章的图片素材。
3. 规划并确认 `outline.md`
- 写最终稿前先给出推荐标题或使用用户指定标题、文章核心口径、章节大纲、来源缺口、图片规划和必选素材映射。
- `outline.md` 应包含每个大小标题、3-5 个要点、页面 / 图位角色、视觉想法、必选素材路径或附件名。
- 有必选素材时,必须先确认“素材到章节 / 图位”的映射,再进入风格选择或图片生成。
- 若存在多个活动分支、旧版活动、小众资格或来源冲突,先建议主文范围,等用户确认后再写最终稿。
- 用户明确要求“直接生成”时,可以继续执行,但所有未确认事实必须标 `【待确认:...】`
4. 确认视觉风格。
- 若用户没有指定视觉方向,读 `references/recommended-styles.md`,给 2-3 个 MAOMOMO 配图风格选项并推荐一个。
- 用户提供参考图、PPT、PDF 或旧文章风格时,先总结可复用的配色、版式、字体气质、猫咪元素、信息密度和禁用项。
- 确认后,整篇文章保持同一视觉系统:稳定配色、猫咪造型、标题区、图标语言、品牌识别和信息密度;不同图位可以变化构图。
5. 确认生图后端。
- 出第一张图前读 `references/image-generation.md`
- 优先主动检查当前 agent 是否可调用内置图片生成工具,并向用户说明检查结果和准备使用的后端。
- 只有内置工具不可用、能力不足、用户明确要求 API/CLI或需要使用第三方图片 API 时,才走 `scripts/maomomo_image_gen.py` fallback。
- 相信用户环境变量或配置文件里的 baseURL、model、quality除非报错或用户要求不要重新索要配置。
6. 写作或优化文章。
- 用户确认标题、大纲、口径和素材映射后,再读 `references/style-guide.md` 写发布用 Markdown。
- 不要把“推测 / 大概率 / 过往惯例”写成“已官宣”。
- 金融活动文章尤其要分清官方条款、App 显示、用户实测和经验判断。
- 发布用 Markdown 使用 frontmatter、H1、太长不看版、正文、最后提醒和来源区。
- SEO 优化既要改标题、摘要、slug / tags / categories、图片 alt也要清理无效来源和发布残留。
7. 创建项目目录和任务文件。
- 完整交付默认使用独立项目目录;如果用户没指定位置,使用当前工作目录或源文件所在目录。
- 推荐结构:
```text
{base_dir}/{article_slug}/
├── origin_image/
│ ├── {article_slug}_01_cover.png
│ └── ...
├── assets/
│ ├── {article_slug}_01_cover.png
│ └── ...
├── sources/
│ ├── card-reference.png
│ └── ...
├── prompts/
│ ├── {article_slug}_01.json
│ └── ...
├── deck_spec.json
├── slide_jobs.json
├── slide_run_state.json
├── outline.md
├── article.md
├── speech.md
└── {article_slug}.zip
```
- `origin_image/` 保存图片后端生成并通过 QA 的原始最终图;`assets/` 保存 Markdown 实际引用的发布图片。两者可以是同名复制件,但不得只保留临时图。
- `sources/` 保存用户提供或主动查找的卡面、Logo、支付网络、官方截图或其他参考素材供 prompt、manifest 和 `deck_spec.json` 映射引用。
- `deck_spec.json` 记录文章级上下文、确认后的风格、生图后端、样张生成方法 `sample_generation_method`、参考素材映射和图片任务列表。
- `prompts/{article_slug}_XX.json` 记录每张图的文件名、用途、放置位置、核心文案、完整 prompt、依赖素材和输出路径。
- `slide_jobs.json``slide_run_state.json` 记录每个图片 job 的 pending / dispatched / recorded / blocked 状态;使用 `scripts/maomomo_job_state.py` 初始化和记录状态。
8. 出图前整理全部 prompt。
- 每张图的文件名、用途、放置位置、核心文案、完整 prompt、alt text、风格、依赖素材和输出路径先写入 `prompts/` 或 manifest 文件。
- prompt 中不要写“暖橙金融教程风”“数据仪表盘风”“手绘便签风”等容易被模型照抄的中文风格标签;改写为白底、暖橙强调、信息卡片、猫咪向导、清晰标题等视觉描述。
- 每张图的 prompt 必须明确:只允许出现指定业务文案、`MAOMOMO` 和已核对允许出现的品牌 / 支付标识不得添加副标题、风格标签、prompt 描述、说明文字、额外 slogan 或无关文字。
- 封面只放最高优先级结论和少量核心数字;复杂计算、全年理论上限、长公式和详细规则放到计算图或正文。
- 不要在聊天里输出超长 prompt告诉用户可直接编辑 prompt 文件。
- 如果用户修改 prompt先同步文件再生成图片。
9. 先生成一张样张。
- 优先生成封面图或最能代表文章视觉节奏的一张内容图。
- 样张直接保存为正式文件名,例如 `origin_image/hsbc-mastercard-alipay-campaign-01-cover.png`
- 展示样张并等待用户确认风格、内容、中文文字质量和视觉密度。
- 如果用户不满意,先改该图 prompt再重出同一张样张确认前不得生成剩余图片。
- 样张确认后,在 `deck_spec.json` 记录 `sample_generation_method`,包括 backend、tool/command、mode、quality、model/config、prompt 文件、approved_sample_path 和 handoff_rule。
10. 逐张生成剩余图片。
- 样张批准后,剩余图片必须使用同一后端、同一质量配置和同一视觉系统。
- 每张图独立生成或准备为高清 PNG先进入 `origin_image/`,通过 QA 后同步到 `assets/`,并用相对路径插入 Markdown。
- 图片生成必须一张张来:一张图一个 prompt job、一次图片请求、一次 QA。不要一次请求多张图不要为了快降低质量。
- 如果运行环境支持子 agent样张通过后可以一图一个子 agent 并发处理;父 agent 负责状态文件、QA、Markdown、`speech.md` 和打包。
- 没有真实截图时只能生成“示意图 / 信息图”,不能伪造官方 App 截图。
- 不要用 Playwright 替代图片生成Playwright 只用于已有 HTML / SVG / 网页截图检查。
11. 记录状态、QA 和返修。
- 每个图片 job 的 dispatch、结果和 blocker 都用 `scripts/maomomo_job_state.py` 写入 `slide_jobs.json` / `slide_run_state.json`,不能只靠聊天说明完成。
- 每张图通过前必须检查日期、金额、公式、卡组织 / 支付网络、禁用分支、风格说明文字、伪造截图、乱码和多余文案。
- 检查文字清晰度、中文乱码、金额 / 日期 / 规则是否残留旧口径、标题截断、风格一致性、必选素材是否正确、元素是否重叠、是否伪造截图或 Logo。
- 严重问题重新生成该单张;局部问题优先使用已确认后端的编辑能力修复,不得本地手工覆盖关键文字冒充模型输出。
12. 生成 `speech.md`、组装文章包并最终 QA。
- `speech.md` 用作每张图的备注 / 讲解稿,标题格式使用 `## Slide N: 标题`,便于和图片顺序映射。
- 组装最终文章包时,把 `origin_image/{article_slug}_XX.png` 按顺序同步到 Markdown 引用的 `assets/`,并确保 `article.md`、图片路径、`speech.md`、来源区和 ZIP 都是最新版本。
- 完整交付、文件交付或改稿打包前读 `references/delivery-rules.md`
- QA 必须用脚本检查 Markdown 中所有图片路径真实存在,并检查 assets 是否存在、来源区只保留实际使用来源、正文无编辑痕迹、图片无错误日期 / 金额 / 未确认结论、用户要求删除内容不残留、ZIP 内容正确。
- 最终回复保持简短给出项目目录、文章路径、图片目录、ZIP 路径、图片数量、生图后端、状态记录情况、备注写入情况和已知限制。
## 模式选择
- “生成文章”“完整文章”“发布用 Markdown”“使用 skill”“按 skill”“文章和配图一起”“打包”“一键下载”“最终交付”完整交付模式。
- “只要大纲”“先列结构”:只输出标题备选、大纲、事实缺口、来源清单和图片规划。
- “只要文字”“不要图片”“不要打包”“先不要生成文件”:按用户限制输出,不强制创建文件包。
- “SEO 优化”“配图”“打包”且用户提供已有 Markdown读取原文后输出优化版 Markdown、assets 和 ZIP。
- “小红书”“4 图看完”“发小红书”:读 `references/style-guide.md` 的小红书规则,并按 9:16 竖图规划。
- 后续说“删掉 X”“合并 3、4”“不要写 Y”“改成 Z”视为编辑指令不要把指令原样写进正文。
## 改稿协作规则
- 用户的修改要求默认是编辑指令,不是正文素材。
- 只改用户指定范围;不要因为“删掉几个字”误删整段。
- 用户确认的实测口径优先写成结论,不反复声明“本文以实测为主”等元叙述。
- 用户给出实测或过往惯例依据时,不要把确定事实和强概率判断改软;风险提示只能作为边界补充,不能推翻主句判断。
- 对同类模糊词同步检查,例如“更像”“可能”“大致”“疑似”,但不要机械删除必要的不确定表达。
- 改完必须检查正文是否残留“不要写”“用户要求”“准确写法是”“本文口径”“应当写成”等编辑痕迹。
- 文件交付任务改完后重新检查 Markdown、assets 和 ZIP 是否是最新版本。
## 验收标准
完整交付必须满足:
- `article.md` 或用户指定的 Markdown 文件存在。
- `assets/` 存在,且 Markdown 中每个图片路径都能对应真实文件。
- 需要配图时,每张配图是独立 PNG并且含 MAOMOMO 品牌识别。
- ZIP 包存在,包含最终 Markdown 和 `assets/`
- 来源区只保留文章实际使用的来源;未读或无法确认的来源不得假装已确认。
- 正文没有 `contentReference`、`oaicite`、调试标记、模型解释或编辑指令残留。
- 金融、银行、券商、数字货币、汇款、税务或合规内容包含保守风险提示。
- 用户要求删除或收敛的分支,不残留在标题、摘要、正文、图片 alt、配图清单、来源区或 ZIP。
如果无法完成,最终回复必须说明:阻塞阶段、缺失材料或失败工具、已完成文件路径、未完成项和下一步需要什么。
## Reference Map
- `references/source-and-fact-check.md`:来源读取、事实表、时效性、冲突口径和金融风险核查。
- `references/style-guide.md`MAOMOMO 文章类型、标题套路、语气、结构模板、小红书模式和写作细节。
- `references/visual-assets.md`配图类型、猫咪视觉、文件命名、Markdown 插图、金融卡面核对、可见文字限制、禁止伪造截图和图片 QA。
- `references/recommended-styles.md`:推荐配图风格、适用场景、推荐话术和提示词片段。
- `references/image-styles/*.md`:具体出图风格 brief借鉴 `codex-ppt-skill` 风格库结构并适配 MAOMOMO 文章配图。
- `references/image-generation.md`:图片生成后端选择、`scripts/maomomo_image_gen.py` 用法、`scripts/maomomo_job_state.py` 状态记录、manifest 和故障处理。
- `references/delivery-rules.md`完整交付、ZIP、更新打包、附件策略和最终检查清单。