--- name: maomomo-article-writer description: 生成或优化符合 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. 创建项目目录和任务文件。 - 完整交付默认使用独立项目目录；如果用户没指定位置，使用当前工作目录或源文件所在目录。 - 推荐结构： ```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 ├── 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`。 8. 出图前整理全部 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，先同步文件，再生成图片。 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`，不能只靠聊天说明完成。 - 每张图的状态必须记录 prompt 文件、生成结果、QA 状态、是否进入 `assets/`、是否已推送 GitHub；缺失记录时不得进入最终交付。 - 每张图通过前必须检查日期、金额、公式、卡组织 / 支付网络、禁用分支、风格说明文字、伪造截图、乱码和多余文案。 - 检查文字清晰度、中文乱码、金额 / 日期 / 规则是否残留旧口径、标题截断、风格一致性、必选素材是否正确、元素是否重叠、是否伪造截图或 Logo。 - 小红书 3:4 / 9:16 图额外检查：比例正确、竖版原生构图、元素没有被压扁、卡片 / Logo / 文字没有拉伸、不是横图硬塞进竖版。 - 严重问题重新生成该单张；局部问题优先使用已确认后端的编辑能力修复，不得本地手工覆盖关键文字冒充模型输出。 12. 生成 `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 分批推送、更新打包、附件策略和最终检查清单。