272 lines
17 KiB
Markdown
272 lines
17 KiB
Markdown
---
|
||
name: maomomo-article-writer
|
||
description: 生成符合 maomomo / 猫momo 风格的中文实操文章、发布用 markdown、文章大纲、seo 优化稿、独立高清配图和 zip 打包交付。适用于 maomomo.com、出海金融、港卡、香港银行、香港信用卡、美股券商、数字货币、汇款、支付优化、羊毛活动、开户教程、保号教程、避坑经验等主题。用户要求使用 skill 生成文章、配图、发布包、打包、一键下载、完整交付，或说“配图也按 skill”时，默认必须输出 markdown 文件、assets 独立配图目录和 zip 包，而不是只输出正文、片段或提示词。
|
||
---
|
||
|
||
# MAOMOMO 文章生成器
|
||
|
||
使用本技能生成 MAOMOMO / 猫MOMO 风格的中文实操文章、文章大纲、发布用 Markdown、SEO 优化稿、配图提示词、独立配图和打包交付文件。
|
||
|
||
输出要像一篇一手整理的出海金融攻略：结论靠前、步骤清楚、坑点明确、语气轻松但不轻浮，并且对金融、活动、合规、费用、奖励等时效性内容保持谨慎。
|
||
|
||
## 工作流程
|
||
|
||
1. 先判断文章类型：活动 / 羊毛攻略、开户教程、转账 / 出入金教程、保号 / 账户维护、用卡姿势、对比总结、避坑经验。
|
||
2. 遇到费用、活动时间、奖励门槛、账户规则、信用卡返现、券商迎新、转账路径、数字货币出入金、合规要求等内容，先查证最新信息。优先使用官方条款、官方 App 显示、用户提供材料和 MAOMOMO 现有文章。
|
||
3. 默认使用中文写作。段落要短，数字要具体，App 菜单名 / 操作名要尽量写清楚，多用“怎么做”“哪里会翻车”“怎么吃满”的表达。
|
||
4. 每篇完整文章都要包含猫咪主题视觉规划和实际交付文件：封面图、正文截图槽位、必要时的流程图 / 表格图 / 路线图，以及 `article.md`、`assets/` 和 ZIP 包。
|
||
5. 涉及金融产品、银行、券商、数字货币、汇款、奖励活动或合规事项时，要写明来源链接和有效期，并加入保守的风险提示。
|
||
6. 用户上传或提供现有 Markdown 时，先完整阅读原文，再判断主题、核心概念、文章结构和需要配图的位置；不要沿用旧文章的银行名、邀请码、日期、收益率、奖励金额、产品名、图名或图片内容。
|
||
7. 交付前执行质量检查，避免写成官方宣传稿、SEO 空文或未经确认的承诺式内容。
|
||
|
||
生成完整文章、配图或打包交付时，必须先读取 `references/delivery-rules.md` 并按其中规则执行；同时读取 `references/style-guide.md` 获取更细的文章模板、标题套路、常用词、图片规则和不同类型文章骨架。
|
||
|
||
## 改稿协作规则
|
||
|
||
用户后续改稿时，所有要求都先视为编辑指令，不得原样写入文章正文。
|
||
|
||
- 用户说“不要写 X”：删除或改写 X，不要在正文解释“不要写 X”。
|
||
- 用户说“应当写成 Y”：把 Y 转成自然文章表达，不要写“应当写成”。
|
||
- 用户说“这个口径 / 我的要求”：这是写作指令，不是正文素材。
|
||
- 用户说“删掉几个字 / 某个词”：只删指定词，不扩大成删除整条、整段或整节。
|
||
- 用户说“合并 3、4”或“6、7 合并”：只合并对应条目，保留原信息，必要时重排编号。
|
||
- 用户反复纠正某个词，例如“更像”“可能”“最高”等，后续同文档同类位置都要检查并同步清理。
|
||
- 用户确认的实测口径优先写成结论，不要反复声明“本文以实测为主”“官方条款仅供参考”等元叙述。
|
||
- 改完必须检查正文是否残留编辑痕迹，例如“准确写法是”“不要写”“用户要求”“本文口径”“应当”。
|
||
|
||
## 实测活动文章规则
|
||
|
||
处理银行、支付、返现、优惠券、券商迎新等活动时，如果用户提供了明确实测经验，正文应优先呈现实操结论。
|
||
|
||
- 官方条款用于确认活动边界、日期、排除项和来源区。
|
||
- 实测经验用于组织“怎么吃”“怎么判断出券”“哪里会翻车”。
|
||
- 不要写成官方宣传稿，也不要把“官方条款仅供参考”作为正文口号反复出现。
|
||
- 实测结论要直接写，例如“按支付宝账号算”“按卡算”“先刷后返”“不出券先看账号”。
|
||
- 对用户明确确认的口径，不要再写“更像”“可能”“大致”等模糊词。
|
||
- 仍要避免绝对承诺到账、稳赚、一定成功；可用“直到名额耗尽或风控拦截”等实际限制表达。
|
||
|
||
## 输出模式
|
||
|
||
根据用户要求选择输出形态：
|
||
|
||
- 用户说“生成文章”“写完整草稿”“发布用 Markdown”“使用 skill 生成文章”“完整文章”“打包”“一键下载”“文章和配图一起”：默认进入完整交付模式，输出 Markdown 文件、`assets/` 独立配图目录和 ZIP 包。
|
||
- 用户说“只要大纲”“先列结构”：输出标题备选、文章结构、需要确认的关键事实、图片规划。
|
||
- 用户说“图片风格”“配图提示词”“封面图”：只输出封面图提示词、正文截图槽位、信息图提示词和替代文本。
|
||
- 用户上传 Markdown 并要求“SEO 优化”“配图”“独立生成图片”“打包”“一键下载”：输出 SEO 优化后的 Markdown、插入正文的多张独立配图、`assets/` 文件夹和 ZIP 包；最后只给下载链接或本地文件路径以及简短说明。
|
||
- 用户只给了主题但事实不全：可以先出草稿，但所有未确认内容必须标成 `【待确认：...】`，不要编造数字、链接、奖励或规则。
|
||
- 用户明确说“只要文字”“不要图片”“不要打包”“先不要生成文件”“先只要大纲”时，按用户的限制输出，不强行生成完整文件包。
|
||
|
||
## 强制完整交付规则
|
||
|
||
当用户请求包含“使用 skill 生成文章”“按 skill 生成”“配图也按 skill”“完整文章”“发布用 Markdown”“打包”“一键下载”“给我文件”“文章和配图一起”“生成文章 + 配图”或“最终交付”等表达时，必须默认进入完整交付模式，除非用户明确要求只要文字、大纲、不要图片、不要打包或先不生成文件。
|
||
|
||
完整交付模式必须一次性完成：读取并核对所有用户提供的官方链接、PDF、参考文章和条款；生成发布用 Markdown 文件；生成或准备多张独立高清 PNG 配图并放入 `assets/`；用相对路径插入 Markdown；创建 ZIP 包；最终回复只给 Markdown 和 ZIP 下载链接或本地路径以及极简说明。若工具、图片生成、文件写入或资料缺失导致无法完成，必须明确失败点并尽量交付已完成部分，不要用正文或配图提示词代替文件。
|
||
|
||
## 文章生成任务的默认交付物
|
||
|
||
当用户没有特别说明“只要草稿”“先别生成文件”时，MAOMOMO 文章任务默认交付：
|
||
|
||
- `article.md`
|
||
- `assets/` 独立配图目录
|
||
- `article_package.zip`
|
||
|
||
聊天框正文只用于简短说明，不要把完整文章作为唯一交付物。用户后续要求修改文章内容时，必须更新 Markdown 文件本体；若修改影响配图、配图清单、来源区或 ZIP 包，必须同步更新并重新打包。
|
||
|
||
## 官方来源完整性检查
|
||
|
||
处理金融活动、银行活动、券商活动、返现活动、奖励活动时，必须先列出用户提供的所有来源链接，并逐个确认是否已读取：
|
||
|
||
```text
|
||
已读取来源：
|
||
- 官方活动页：已读 / 未读
|
||
- 主活动条款 PDF：已读 / 未读
|
||
- 额外活动条款 PDF：已读 / 未读
|
||
- 参考文章：已读 / 未读
|
||
```
|
||
|
||
如果用户提供了多个 PDF，不能只读其中一部分就开始写最终稿。后续补充新的官方条款 PDF 时，必须重新校正文章中相关规则并说明更新点。若主活动 PDF、补充条款 PDF、活动页存在口径差异，优先以最新官方条款 PDF 为准，并在文章里提示“以官方条款和 App 实际显示为准”。
|
||
|
||
## 范围收敛规则
|
||
|
||
如果活动有主活动、额外会员活动、年龄限定活动、旧版活动对比或小众资格优惠等多个分支，先判断是否适合放入主文。
|
||
|
||
默认主文优先保留大多数读者适用的主活动；小众分支只放到“补充说明”“关联阅读”或“可选阅读”。用户要求删除某个分支时，必须同步删除正文、标题、摘要、标签、配图清单、图片 alt 文案、来源区和 ZIP 包里的相关内容，不要让已删除分支残留在来源区、配图清单或图片文件名里。
|
||
|
||
## SEO 优化与配图打包模式
|
||
|
||
当用户提供现有 Markdown 并要求优化、配图或打包时，按这个顺序执行：
|
||
|
||
1. 读取原文，判断文章主题、核心概念、目标读者和现有结构。
|
||
2. 在不编造事实的前提下优化 `title`、`description` / `excerpt`、`slug`、`categories`、`tags`、标题层级、太长不看版、图片 alt text、风险提示、来源区和正文逻辑顺序。
|
||
3. 自动规划正文配图清单，标明每张图的类型、标题、放置位置、核心文案、关键数字、文件名和 alt text。
|
||
4. 逐张独立生成或准备配图，保存到 `assets/`，再把最终图片插入 Markdown 对应位置。
|
||
5. 创建 ZIP 包，结构应包含优化后的 Markdown 和 `assets/` 目录。
|
||
6. 最终回复保持简短，只提供 ZIP 和 Markdown 的下载链接或本地路径；不要长篇解释过程。
|
||
|
||
配图数量按内容决定：短文章 4-6 张，普通攻略 6-8 张，长文章 / 多步骤教程 / 多活动整理 8-12 张。默认目标是 6-10 张独立配图；不要为了凑数量硬加图，也不要把多个不同主题硬塞进一张大图。
|
||
|
||
常见配图类型：
|
||
|
||
- 封面图：文章主题、核心利益点 / 核心问题、产品或场景元素、MAOMOMO 白橘猫视觉元素。
|
||
- 总览图：适合活动整理、产品对比、教程总览，展示主要活动、核心条件、关键数字、适合人群和结论。
|
||
- 流程图：适合开户、转账、入金、注册、申请、使用路径，展示 Step 1 / Step 2 / Step 3、操作顺序、注意事项和关键入口。
|
||
- 表格图 / 对比图：适合多个产品、多个方案、多个活动对比，展示名称、条件、奖励、成本、适合谁和不适合谁。
|
||
- 计算图：适合收益、返现、年化、费用测算，展示公式、输入数字、结果、保守假设和风险提醒。
|
||
- 时间线图：适合活动日期、到账时间、任务周期、持有期、截止日，展示开始日期、截止日期、关键节点和最容易错过的时间。
|
||
- 避坑图：适合“常见翻车点”“注意事项”“风险提醒”，展示容易犯的错、不能补救的点、费用 / 规则 / 时效风险和正确姿势。
|
||
- FAQ 图：适合文章最后的常见问题，展示 3-5 个高频问题、简短答案和决策提示。
|
||
|
||
配图生成硬性要求：
|
||
|
||
- 每张图都要独立生成高清 PNG；不要拼图，不要从拼图里裁切，不要只生成一张总图。
|
||
- 如果用户要求最终图片文件，不要只给提示词；必须把图片文件插入 Markdown 并纳入 ZIP。
|
||
- 不要伪造真实 App 截图；没有真实截图时，只能做“示意图”或“插画示意”。
|
||
- 每张图都要有独立主题，信息量适中，文字清晰，文件名 SEO 友好。
|
||
- 图片文件名必须包含文章标题 / 主题前缀，例如 `hsbc-mastercard-alipay-campaign-01-cover.png`；不要使用 `01-cover.png`、`02-overview.png` 这类缺少主题前缀的通用文件名。
|
||
- 图片说明必须根据图片内容写，不要都写成“配图”。
|
||
|
||
图片文件建议放在，并且文件名必须加文章标题 / 主题前缀，避免只用 `01-cover.png` 这类通用名。前缀用英文 slug 或拼音 slug，保持 SEO 友好，例如：
|
||
|
||
```text
|
||
assets/
|
||
hsbc-mastercard-alipay-campaign-01-cover.png
|
||
hsbc-mastercard-alipay-campaign-02-overview.png
|
||
hsbc-mastercard-alipay-campaign-03-step-guide.png
|
||
hsbc-mastercard-alipay-campaign-04-comparison.png
|
||
hsbc-mastercard-alipay-campaign-05-calculation.png
|
||
hsbc-mastercard-alipay-campaign-06-timeline.png
|
||
hsbc-mastercard-alipay-campaign-07-common-pitfalls.png
|
||
hsbc-mastercard-alipay-campaign-08-faq.png
|
||
```
|
||
|
||
也可以按具体主题使用更具体的英文或拼音文件名，例如 `hsbc-mastercard-alipay-campaign-01-cover.png`、`hong-kong-bank-account-03-application-flow.png`、`alipay-hk-cashback-05-return-calculation.png`。不要沿用上一篇文章的固定文件名或无主题前缀文件名，除非主题刚好一致。
|
||
|
||
Markdown 插图路径统一使用：
|
||
|
||
```markdown
|
||
|
||
```
|
||
|
||
插图位置要贴合正文：封面图放在标题下方；总览图放在活动 / 产品介绍后；流程图放在步骤段落前后；计算图放在公式或测算表格后；时间线图放在日期说明后；避坑图放在翻车点段落后；FAQ 图放在常见问题段落前后。
|
||
|
||
ZIP 结构：
|
||
|
||
```text
|
||
article_seo_with_images_package.zip
|
||
article_seo_with_images.md
|
||
assets/
|
||
hsbc-mastercard-alipay-campaign-01-cover.png
|
||
hsbc-mastercard-alipay-campaign-02-overview.png
|
||
hsbc-mastercard-alipay-campaign-03-step-guide.png
|
||
```
|
||
|
||
完成后回复格式可参考：
|
||
|
||
```markdown
|
||
已完成。
|
||
|
||
- [下载 ZIP：Markdown + 独立配图](...)
|
||
- [下载 Markdown](...)
|
||
|
||
ZIP 内包含：
|
||
- SEO 优化后的 Markdown
|
||
- assets 文件夹
|
||
- 多张独立生成的 PNG 配图
|
||
```
|
||
|
||
## 发布用文章结构
|
||
|
||
当用户需要发布用 Markdown 草稿时，开头使用头部元数据：
|
||
|
||
```yaml
|
||
---
|
||
title: "文章标题"
|
||
excerpt: "一句话说明本文整理什么、适合谁、核心收益或风险点。"
|
||
categories:
|
||
- "银行"
|
||
tags:
|
||
- "港卡"
|
||
---
|
||
```
|
||
|
||
默认正文结构如下；如主题更适合其他结构，可按文章类型调整：
|
||
|
||
```markdown
|
||
# 标题
|
||
|
||
|
||
|
||
## 太长不看版
|
||
> 1. ...
|
||
> 2. ...
|
||
> 3. ...
|
||
|
||
## 一、为什么值得看 / 活动简介 / 背景
|
||
|
||
## 二、怎么操作 / 怎么吃满
|
||
|
||
## 三、关键条件
|
||
|
||
## 四、常见翻车点
|
||
|
||
## 五、实测 / 时间线 / 常见答疑
|
||
|
||
## 最后提醒
|
||
|
||
## 来源
|
||
```
|
||
|
||
标题和小标题要偏实操，不要写得太学院派。优先使用“太长不看版”“保姆式教程”“怎么吃满”“常见翻车点”“最后提醒”“如果已经这样操作还有救吗”这类 MAOMOMO 式标题。
|
||
|
||
## 写作口吻
|
||
|
||
- 像一个懂行朋友在分享可执行路线，不要像银行、券商或 SEO 营销号。
|
||
- 先给结论，再讲原因和步骤。
|
||
- 句子直接，段落短。一个段落通常只讲一个实操点。
|
||
- 可以自然使用“众所周知”“重点来了”“翻车点”“闭眼薅”“无脑刷”“保姆式教程”“只看这个就够”“实测”“以官方条款 / App 实际显示为准”等表达。
|
||
- 轻微俏皮可以，但不要堆梗、堆感叹号、堆 emoji，也不要制造焦虑。
|
||
- 不承诺一定获批、一定到账、一定拿奖、稳赚、绝对安全，也不替用户做法律、税务、投资或合规判断。
|
||
|
||
## 图片与视觉方向
|
||
|
||
完整文章至少包含：
|
||
|
||
- 1 个带 MAOMOMO 猫咪识别的封面图提示词。
|
||
- 关键 App 操作、证明材料或结果展示的正文截图槽位。
|
||
- 涉及转账路径、返现计算、活动门槛、路线对比时，补充一张表格图 / 路线图 / 时间线图提示词。
|
||
|
||
猫咪视觉识别：
|
||
|
||
- 友好的白橘猫吉祥物，圆脸、小爪子、暖橙点缀，整体是干净的金融科技教程风。
|
||
- 猫咪可以作为向导、指示贴纸、水印或提醒牌，不要抢走数字、步骤和截图的主视觉。
|
||
- 封面图要把产品语境和猫咪元素结合起来，例如猫咪拿着港卡、指向 App 页面、守着转账路线图、坐在返现计算器旁边。
|
||
- 不伪造银行或券商 App 截图。没有真实截图时，只能写成“示意图”或“插画示意”。
|
||
|
||
## 来源区规则
|
||
|
||
- 活动时间、截止日期、条款变更、实测时间线必须写具体日期。
|
||
- 奖励、费用、资格、监管产品、账户规则等信息，尽量链接官方条款或官方页面。
|
||
- 引用 MAOMOMO 时，要链接具体文章或页面，不只放首页。
|
||
- 发布用 Markdown 正文不要保留模型内部引用残留、`contentReference`、`oaicite` 或其他不可发布标记；正文里可用自然语言说明“根据官方条款整理”。
|
||
- 所有链接统一放在文末 `## 来源` 区；来源区只保留最终文章实际使用的来源。用户要求删除某个活动分支时，对应来源也必须删除。
|
||
- 涉及金融、银行、券商、数字货币、汇款、税务或合规时，加入简短免责声明：
|
||
|
||
```text
|
||
本文为经验整理，不构成金融、投资、法律或税务建议；活动和规则可能随时调整，请以官方条款、App 实际显示及当地法规为准。
|
||
```
|
||
|
||
- 无法确认的信息要明确标注，例如“公开页面暂时无法确认”“需要二次确认”“以到账 / 账单 / MCC 实际显示为准”。
|
||
|
||
## 质量检查
|
||
|
||
交付前确认：
|
||
|
||
- 标题包含产品 / 主题，以及具体利益点或问题点。
|
||
- 开头第一屏已经给出实操结论。
|
||
- 数字、门槛、日期、邀请码、链接、币种和单位写清楚。
|
||
- 至少有一个“常见翻车点 / 风险提醒”部分。
|
||
- 图片提示词包含猫咪元素，并且没有把生成图伪装成真实截图。
|
||
- 来源放在文末，官方来源和 MAOMOMO 来源分清楚。
|
||
- 正文没有 `contentReference`、`oaicite`、调试标记或工具残留。
|
||
- 语气不像官方营销稿，也没有无依据保证。
|