hitsword
/
maomomo-article-writer
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity
maomomo-article-writer/SKILL.md

27 KiB
Raw Blame History

name description
maomomo-article-writer 生成或优化符合 maomomo / 猫MOMO 风格的中文出海金融实操文章、发布用 Markdown、SEO 稿、配图规划、独立高清配图 assets、ZIP 发布包，以及小红书卡片 / 多图 / 3:4 / 9:16 竖版 PNG 交付、配图平铺水印；包含 GitHub 交付仓库和专用 KEY / token / deploy key 配置引导。适用于 maomomo.com、港卡、香港银行、香港信用卡、美股券商、数字货币、汇款、支付优化、返现活动、开户教程、保号教程、避坑经验、官方条款整理和实测攻略。用户要求使用 skill、按猫MOMO风格、完整文章、发布用 Markdown、配图、打包、一键下载、最终交付、小红书、卡片、多图、3:4、9:16、水印、平铺水印、防盗图、GitHub 交付、仓库配置或专用 KEY 配置时触发。

MAOMOMO 文章生成器

本技能用于把主题、资料、链接、PDF、截图或已有 Markdown 转成 MAOMOMO / 猫MOMO 风格的中文实操文章，并在需要时交付可发布文件包。

文章要像一手整理的出海金融攻略：结论靠前、步骤清楚、坑点明确、语气轻松但不轻浮。涉及金融、活动、合规、费用、奖励、账户规则和数字货币时，必须谨慎核查并避免承诺式表达。

使用边界

适合：

  • 银行、港卡、香港信用卡、券商、数字货币、汇款、支付、账户维护、返现和羊毛活动。
  • 活动规则整理、开户教程、转账 / 入金 / 出金教程、保号方案、用卡姿势、对比总结、避坑经验。
  • 已有文章 SEO 优化、发布用 Markdown、配图规划、独立配图、ZIP 打包和后续改稿。
  • 小红书卡片、多图信息卡、3:4 或 9:16 竖版 PNG 系列图、封面 / 内容卡 / 结尾卡分批交付。
  • 对最终配图批量或单张叠加 MAOMOMO.COM 45° 白色半透明平铺水印。

不适合：

  • 给出投资、法律、税务或合规结论。
  • 承诺一定获批、一定到账、稳赚、无风险、绝对安全。
  • 伪造真实 App 截图、账单、错误或未经核对的官方 Logo 使用场景，或用户没有提供的实测证据。

硬性约束

  • 如果本技能任何旧规则与“确认优先、单步推进”的流程冲突，以本节和“默认工作流”中的阶段门禁为准。
  • 确认优先，单步推进；不要一上来就完整生成文章、全部配图或 ZIP。
  • 用户提到“小红书”“卡片”“多图”“3:4”“9:16”任一触发词时，默认进入“小红书卡片模式”：不默认走完整文章 + Markdown + ZIP 流程，输出重点改为多张独立 PNG、统一视觉风格、适合小红书发布。只有用户明确要求文章、Markdown 或 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。
  • 小红书卡片模式出图前必须先让用户确认视觉方向：2D 扁平风 或 3D 轻拟物风。用户没指定时，默认推荐 2D 扁平风，因为小红书信息图更稳、更不容易文字翻车；一旦确认，整组图片必须保持同一种视觉方向，不能中途混用。
  • 小红书竖图必须按原生竖版重新构图，禁止把横版设计硬塞进 3:4 或 9:16。每个小红书图片 prompt 必须包含英文约束：native portrait composition、no squeezed elements、no stretched card / logo / text、vertical layout redesigned for Xiaohongshu。
  • 图片 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 包，除非用户明确说只要文字、只要大纲、不要图片、不要打包或先不生成文件。
  • 图片交付完成后必须生成或更新 final_manifest.json，最终推送、打包或链接交付只能读取 final_manifest.json 或状态文件里明确标记为 final 的 assets；不得把 draft、v2、旧比例、失败图或未通过 QA 的图一起交付。
  • 面向 Telegram / 聊天渠道的大文件交付默认改为 GitHub 分批推送：例如 batch-01-cover、batch-02-content-cards、batch-03-final-assets。Telegram 只负责通知进度和给 GitHub 文件路径、commit、release 或下载链接，不承载大 ZIP 或大图片包。
  • 需要 GitHub 分批交付，或用户提到 GitHub 仓库、专用 KEY、token、PAT、deploy key 时，必须先读 references/github-delivery.md，引导配置专用私有交付仓库和最小权限凭据；不得要求用户在聊天里粘贴密钥，不得把 token / 私钥写入 prompt、manifest、状态文件、README、日志或提交记录。
  • 用户要求“水印”“平铺水印”“防盗图”“打水印”时，先读 references/visual-assets.md 的平铺水印规则；水印只处理最终 QA 通过的交付图或交付副本，默认保留无水印原图。水印必须用 uv run python scripts/maomomo_tile_watermark.py 生成，不得手工覆盖。
  • 每张图都必须在状态文件记录：prompt 文件、生成结果、QA 状态、是否进入 assets/、是否已推送 GitHub。中断恢复时先读状态文件和 final_manifest.json，不要依赖聊天记忆。
  • 配图文件必须是独立 PNG；不要用一张大拼图代替多张图，不要只给提示词冒充图片文件。
  • 后续改稿必须更新文件本体；影响图片、来源区、标题、摘要或 ZIP 时同步更新。

可见进度

复杂任务使用一个用户可见 checklist，并且同一时间只推进一个步骤：

  1. 读取资料，整理来源状态和事实表。
  2. 确认标题、核心口径、outline.md 大纲、素材映射、配图风格和生图后端。
  3. 写作或优化发布用 Markdown。
  4. 输出全部图片 prompt 文件和图片任务状态文件。
  5. 生成并确认一张样张。
  6. 逐张生成剩余图片并记录 dispatch / result / blocker。
  7. QA、返修、生成 speech.md、小红书发布文案或备注稿。
  8. 写入 final_manifest.json，按渠道打包或 GitHub 分批推送最终文件。

不要因为聊天里说“已完成”就标记完成；用实际文件、已读取来源、已生成图片、final_manifest.json、ZIP 或 GitHub 批次记录作为完成证据。

默认工作流

一句话版：判断模式 -> 读资料 -> 给标题 / 大纲 / 卡片结构 / 风格让用户确认 -> 写文章或小红书文案 -> 输出图片 prompts 文件让用户改 -> 先出一张图确认 -> 逐张生成剩余图 -> QA -> 写 final_manifest.json -> 打包或 GitHub 分批交付。

  1. 判断任务模式。

    • 完整交付、只要大纲、只要正文、只要配图、SEO 优化、改稿更新、小红书卡片模式。
    • 判断是否涉及金融 / 活动 / 合规事实核查。
    • 完整交付、打包、GitHub 分批推送或小红书卡片任务先读 references/delivery-rules.md；需要配图时先读 references/visual-assets.md；需要 GitHub 推送或仓库 / KEY 配置时先读 references/github-delivery.md。

  2. 读取源材料并建立事实表。

    • 先读用户提供的官方页面、PDF、旧文、参考链接、截图或素材，不先动手写最终稿。
    • 涉及官方规则、活动或金融产品时，先读 references/source-and-fact-check.md。
    • 列出所有来源的已读 / 未读 / 无法读取状态。
    • 明确区分：已官宣事实、用户实测、过往惯例判断、待确认内容。
    • 确认主题、目标读者、文章目标、章节数量或图片数量、品牌 / 风格限制，以及必须放入文章的图片素材。

  3. 规划并确认 outline.md。

    • 写最终稿前先给出推荐标题或使用用户指定标题、文章核心口径、章节大纲、来源缺口、图片规划和必选素材映射。
    • outline.md 应包含每个大小标题、3-5 个要点、页面 / 图位角色、视觉想法、必选素材路径或附件名。
    • 有必选素材时，必须先确认“素材到章节 / 图位”的映射，再进入风格选择或图片生成。
    • 若存在多个活动分支、旧版活动、小众资格或来源冲突，先建议主文范围，等用户确认后再写最终稿。
    • 用户明确要求“直接生成”时，可以继续执行，但所有未确认事实必须标 【待确认：...】。
    • 小红书卡片模式的 outline.md 可以简化为卡片结构：图片数量、比例、每张卡片角色、核心文案、话题标签、必选素材映射和分批交付计划。

  4. 确认视觉风格。

    • 小红书卡片模式必须先确认比例 3:4 或 9:16，以及视觉方向 2D 扁平风 或 3D 轻拟物风。
    • 小红书卡片模式用户没指定视觉方向时，推荐 2D 扁平风：清爽、信息卡片、适合教程 / 规则说明，文字更稳；3D 轻拟物风 更有质感，适合封面 / 活动感 / 金融产品展示。
    • 小红书卡片模式一旦确认 2D / 3D，所有 prompt、样张、剩余图片和 final manifest 都必须记录同一 visual_direction，不得混用。
    • 若用户没有指定视觉方向，读 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. 创建项目目录和任务文件。

    • 完整交付默认使用独立项目目录；如果用户没指定位置，使用当前工作目录或源文件所在目录。
    • 推荐结构：
{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
├── final_manifest.json
├── github_batches.json
├── watermarked_assets/        # 可选，最终图的 MAOMOMO.COM 平铺水印版本
├── 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 初始化和记录状态。
  • final_manifest.json 只记录通过 QA 且进入 assets/ 的最终交付文件；github_batches.json 记录每批 GitHub 推送的 batch id、文件路径、commit、release 或下载链接。
  • 用户要求水印时，使用 uv run python scripts/maomomo_tile_watermark.py --input assets --output watermarked_assets 生成水印副本；水印图可进入 GitHub 批次中的 watermarked/，但无水印原图仍保留。
  • 小红书卡片项目没有文章正文时，可以省略 article.md 和 ZIP，但仍必须保留 origin_image/、assets/、prompts/、slide_jobs.json、slide_run_state.json、final_manifest.json 和 github_batches.json。

  1. 出图前整理全部 prompt。

    • 每张图的文件名、用途、放置位置、核心文案、完整 prompt、alt text、风格、依赖素材和输出路径先写入 prompts/ 或 manifest 文件。
    • prompt 中不要写“暖橙金融教程风”“数据仪表盘风”“手绘便签风”等容易被模型照抄的中文风格标签；改写为白底、暖橙强调、信息卡片、猫咪向导、清晰标题等视觉描述。
    • 每张图的 prompt 必须明确：只允许出现指定业务文案、MAOMOMO 和已核对允许出现的品牌 / 支付标识；不得添加副标题、风格标签、prompt 描述、说明文字、额外 slogan 或无关文字。
    • 小红书 3:4 / 9:16 prompt 必须明确原生竖版重构，并包含 native portrait composition、no squeezed elements、no stretched card / logo / text、vertical layout redesigned for Xiaohongshu。
    • 封面只放最高优先级结论和少量核心数字；复杂计算、全年理论上限、长公式和详细规则放到计算图或正文。
    • 不要在聊天里输出超长 prompt；告诉用户可直接编辑 prompt 文件。
    • 如果用户修改 prompt，先同步文件，再生成图片。

  2. 先生成一张样张。

    • 优先生成封面图或最能代表文章视觉节奏的一张内容图。
    • 样张直接保存为正式文件名，例如 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。

  3. 逐张生成剩余图片。

  • 样张批准后，剩余图片必须使用同一后端、同一质量配置和同一视觉系统。
  • 每张图独立生成或准备为高清 PNG，先进入 origin_image/，通过 QA 后同步到 assets/，并用相对路径插入 Markdown。
  • 图片生成必须一张张来：一张图一个 prompt job、一次图片请求、一次 QA。不要一次请求多张图，不要为了快降低质量。
  • 如果运行环境支持子 agent，样张通过后可以一图一个子 agent 并发处理；父 agent 负责状态文件、QA、Markdown、speech.md 和打包。
  • 没有真实截图时只能生成“示意图 / 信息图”，不能伪造官方 App 截图。
  • 不要用 Playwright 替代图片生成；Playwright 只用于已有 HTML / SVG / 网页截图检查。
  1. 记录状态、QA 和返修。
  • 每个图片 job 的 dispatch、结果和 blocker 都用 scripts/maomomo_job_state.py 写入 slide_jobs.json / slide_run_state.json，不能只靠聊天说明完成。
  • 每张图的状态必须记录 prompt 文件、生成结果、QA 状态、是否进入 assets/、是否已推送 GitHub；缺失记录时不得进入最终交付。
  • 每张图通过前必须检查日期、金额、公式、卡组织 / 支付网络、禁用分支、风格说明文字、伪造截图、乱码和多余文案。
  • 检查文字清晰度、中文乱码、金额 / 日期 / 规则是否残留旧口径、标题截断、风格一致性、必选素材是否正确、元素是否重叠、是否伪造截图或 Logo。
  • 小红书 3:4 / 9:16 图额外检查：比例正确、竖版原生构图、元素没有被压扁、卡片 / Logo / 文字没有拉伸、不是横图硬塞进竖版。
  • 严重问题重新生成该单张；局部问题优先使用已确认后端的编辑能力修复，不得本地手工覆盖关键文字冒充模型输出。
  1. 生成 speech.md、final_manifest.json、组装文章包或 GitHub 批次并最终 QA。
  • speech.md 用作每张图的备注 / 讲解稿，标题格式使用 ## Slide N: 标题，便于和图片顺序映射。
  • 组装最终文章包时，把 origin_image/{article_slug}_XX.png 按顺序同步到 Markdown 引用的 assets/，并确保 article.md、图片路径、speech.md、来源区和 ZIP 都是最新版本。
  • 最终交付只能读取 final_manifest.json 或状态文件中 qa_status=passed、entered_assets=true、final=true 的文件，不扫描整个目录交付。
  • 若交付水印版，在最终 QA 后用 uv run python scripts/maomomo_tile_watermark.py 对 final assets 生成 watermarked_assets/，并在 final_manifest.json 记录 watermark 字段：text、angle、color、alpha、output_dir。
  • 需要 GitHub 分批交付时，先按 references/github-delivery.md 确认交付仓库、认证方式、目标路径和仓库隐私级别；缺配置时先给用户本机配置步骤并暂停 push。配置就绪后按 batch-01-cover、batch-02-content-cards、batch-03-final-assets 等批次推送；每批推送后记录 GitHub 文件路径、commit、release 或下载链接，并写入 github_batches.json / 状态文件。
  • 完整交付、文件交付或改稿打包前读 references/delivery-rules.md。
  • QA 必须用脚本检查 Markdown 中所有图片路径真实存在，并检查 assets 是否存在、来源区只保留实际使用来源、正文无编辑痕迹、图片无错误日期 / 金额 / 未确认结论、用户要求删除内容不残留、ZIP 内容正确。
  • 小红书卡片模式最终回复固定包含：GitHub 链接、图片数量、风格：2D / 3D、比例：3:4 / 9:16、批次数量、QA 是否完成、已知限制。
  • 完整文章模式最终回复保持简短：给出项目目录、文章路径、图片目录、ZIP 或 GitHub 链接、图片数量、生图后端、状态记录情况、备注写入情况和已知限制。

模式选择

  • “生成文章”“完整文章”“发布用 Markdown”“使用 skill”“按 skill”“文章和配图一起”“打包”“一键下载”“最终交付”：完整交付模式。
  • “只要大纲”“先列结构”：只输出标题备选、大纲、事实缺口、来源清单和图片规划。
  • “只要文字”“不要图片”“不要打包”“先不要生成文件”：按用户限制输出，不强制创建文件包。
  • “SEO 优化”“配图”“打包”且用户提供已有 Markdown：读取原文后输出优化版 Markdown、assets 和 ZIP。
  • “小红书”“卡片”“多图”“4 图看完”“发小红书”“3:4”“9:16”：小红书卡片模式；读 references/style-guide.md 和 references/visual-assets.md 的小红书规则，按 3:4 或 9:16 原生竖版规划，不默认生成完整文章、Markdown 或 ZIP。
  • 后续说“删掉 X”“合并 3、4”“不要写 Y”“改成 Z”：视为编辑指令，不要把指令原样写进正文。

改稿协作规则

  • 用户的修改要求默认是编辑指令，不是正文素材。
  • 只改用户指定范围；不要因为“删掉几个字”误删整段。
  • 用户确认的实测口径优先写成结论，不反复声明“本文以实测为主”等元叙述。
  • 用户给出实测或过往惯例依据时，不要把确定事实和强概率判断改软；风险提示只能作为边界补充，不能推翻主句判断。
  • 对同类模糊词同步检查，例如“更像”“可能”“大致”“疑似”，但不要机械删除必要的不确定表达。
  • 改完必须检查正文是否残留“不要写”“用户要求”“准确写法是”“本文口径”“应当写成”等编辑痕迹。
  • 文件交付任务改完后重新检查 Markdown、assets 和 ZIP 是否是最新版本。

验收标准

完整交付必须满足：

  • article.md 或用户指定的 Markdown 文件存在。
  • assets/ 存在，且 Markdown 中每个图片路径都能对应真实文件。
  • 需要配图时，每张配图是独立 PNG，并且含 MAOMOMO 品牌识别。
  • ZIP 包存在，包含最终 Markdown 和 assets/。
  • 来源区只保留文章实际使用的来源；未读或无法确认的来源不得假装已确认。
  • 正文没有 contentReference、oaicite、调试标记、模型解释或编辑指令残留。
  • 金融、银行、券商、数字货币、汇款、税务或合规内容包含保守风险提示。
  • 用户要求删除或收敛的分支，不残留在标题、摘要、正文、图片 alt、配图清单、来源区或 ZIP。

小红书卡片模式必须满足：

  • 每张最终图是独立 PNG，比例为用户确认的 3:4 或 9:16。
  • 已确认 2D 扁平风 或 3D 轻拟物风，且全组一致。
  • prompt、状态文件和 QA 记录包含原生竖版构图、防压扁和防拉伸约束。
  • final_manifest.json 只包含通过 QA 且进入 assets/ 的最终图片。
  • GitHub 分批推送记录已写入状态文件或 github_batches.json；Telegram 只发送进度和链接。
  • GitHub 交付仓库和专用 KEY / token / deploy key 已按 references/github-delivery.md 配置或明确记录为阻塞项。
  • 最终回复包含 GitHub 链接、图片数量、风格、比例、批次数量、QA 是否完成和已知限制。

如果无法完成，最终回复必须说明：阻塞阶段、缺失材料或失败工具、已完成文件路径、未完成项和下一步需要什么。

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 状态记录、final manifest、GitHub 批次记录和故障处理。
  • references/github-delivery.md：GitHub 交付仓库、专用 KEY / token / deploy key、环境变量、隐私边界和分批推送前置检查。
  • references/delivery-rules.md：完整交付、ZIP、GitHub 分批推送、更新打包、附件策略和最终检查清单。