136 lines
7.0 KiB
Markdown
136 lines
7.0 KiB
Markdown
# MAOMOMO 完整交付规则
|
||
|
||
本文件用于完整文章、配图、发布包、打包、一键下载和后续更新任务。只要用户没有明确说“只要文字”“不要图片”“不要打包”“先不要生成文件”“先只要大纲”，默认按完整交付模式执行。
|
||
|
||
## 强制完整交付规则
|
||
|
||
当用户请求包含以下任一表达时，必须默认进入“完整交付模式”：
|
||
|
||
- “使用 skill 生成文章”
|
||
- “按 skill 生成”
|
||
- “配图也是按 skill”
|
||
- “配图也按 SKILL”
|
||
- “完整文章”
|
||
- “发布用 Markdown”
|
||
- “打包”
|
||
- “一键下载”
|
||
- “给我文件”
|
||
- “文章和配图一起”
|
||
- “生成文章 + 配图”
|
||
- “最终交付”
|
||
|
||
完整交付模式必须一次性完成：
|
||
|
||
1. 读取并核对用户提供的所有官方链接、PDF、参考文章和条款。
|
||
2. 输出发布用 Markdown 文件，而不是只在聊天框展示正文。
|
||
3. 生成或准备多张独立高清 PNG 配图，放入 `assets/` 目录。
|
||
4. 将图片以相对路径插入 Markdown，例如 ``。
|
||
5. 创建 ZIP 包，结构类似：
|
||
|
||
```text
|
||
article_package.zip
|
||
article.md
|
||
assets/
|
||
01-cover.png
|
||
02-overview.png
|
||
03-timeline.png
|
||
```
|
||
|
||
6. 最终回复只给下载链接和极简说明。
|
||
|
||
如果因为工具限制、图片生成失败、文件写入失败或资料缺失导致无法完成完整交付，必须明确说明失败点，并尽量交付已经完成的部分。不要只输出配图提示词代替图片文件，不要只输出文章正文代替 Markdown 文件。
|
||
|
||
## 多渠道交付策略
|
||
|
||
完整交付默认生成 Markdown、assets 和 ZIP，但最终发送方式按渠道和用户要求调整。
|
||
|
||
- 本地 / Web：优先给 Markdown + ZIP；如用户要图片，也附独立图片。
|
||
- Telegram / 聊天：ZIP 可能失败，优先发送 Markdown + 多张图片独立附件；ZIP 作为可选补充。
|
||
- Email：按用户要求选择 ZIP 或独立附件。
|
||
- 用户说“打包发我 email”：发送 ZIP。
|
||
- 用户说“不打包”“分多个附件”：发送 Markdown 和图片作为多个独立附件，不再附 ZIP。
|
||
- 若附件发送失败，不要反复重复发送同一批附件；改用更稳定的渠道或分批发送，并说明只保留最后版本。
|
||
- 发送前确认附件对应的是最后确认版，不要把旧图、旧 Markdown 或临时文件发出。
|
||
|
||
## 配图执行规则
|
||
|
||
当用户要求“配图也按 Skill”“高清配图”“精美配图”“生成配图”“文章和配图一起”时：
|
||
|
||
- 必须生成独立 PNG 图片文件，而不是只给提示词。
|
||
- 不要只生成一张大长图替代所有配图。
|
||
- 每张图必须有独立主题，例如封面图、活动总览图、时间线图、重点规则图、交易法图、避坑图、FAQ 图。
|
||
- 不得使用未经用户提供的真实银行 Logo、券商 Logo 或支付品牌 Logo。
|
||
- 不得伪造真实 App 截图。
|
||
- 生成图应明确是“MAOMOMO 风格示意图 / 信息图”。
|
||
- 生成后必须保存到 `assets/`，并插入 Markdown。
|
||
- 图片文件名使用稳定英文小写命名，例如 `01-cover.png`、`02-overview.png`、`03-timeline.png`、`04-key-rule.png`、`05-strategy.png`、`06-pitfalls.png`。
|
||
- 不要使用中文文件名作为最终 assets 文件名，避免站点路径兼容问题。
|
||
|
||
## 图片生成偏差处理
|
||
|
||
- 每张图应独立生成高清 PNG；不要主动生成一张拼图再裁切。
|
||
- 如果图片工具意外只返回一张拼图或长图，应视为不合格结果。
|
||
- 除非用户接受临时方案，否则应重新生成独立图片。
|
||
- 若临时裁切拼图，必须明确说明这是临时补救，并尽快补独立版本。
|
||
- 用户要求加入参考图元素时，应把参考图作为视觉元素来源，但不要复制真实卡号、个人信息或伪造 App 截图。
|
||
|
||
## 禁止半成品交付
|
||
|
||
以下都属于半成品，除非用户明确只要求这样做：
|
||
|
||
- 只输出文章正文，不给 `.md` 文件。
|
||
- 只输出配图提示词，不生成图片文件。
|
||
- 只生成图片，不插入 Markdown。
|
||
- 只生成一张总图，不生成多张独立配图。
|
||
- 只给 assets，不打 ZIP。
|
||
- 只给一段新增内容，不输出更新后的完整文章。
|
||
- 只给旧文件链接，没有确认文件内容已更新。
|
||
- 修改了正文，但没有同步更新标题、摘要、配图清单、来源区和 ZIP 包。
|
||
- 用户要求“输出完整文章”时，只输出新增片段。
|
||
- 用户要求“打包给我”时，只给 Markdown 或只给图片。
|
||
|
||
当用户说“输出完整文章”“别只给一段”“打包给我”“文章和配图一起”时，必须交付完整文件，而不是片段。
|
||
|
||
## 改稿更新检查
|
||
|
||
用户在已有文章上连续修改时，执行最小变更并同步验证。
|
||
|
||
1. 先定位用户指定范围：标题、TLDR、某节、某句、某几个字、图片、来源区或附件。
|
||
2. 只修改指定范围；不要因为用户说“删掉 X”就删除整条信息。
|
||
3. 若修改影响编号、目录、图片 alt、来源区或 ZIP，才同步更新相关部分。
|
||
4. 修改完成后读取相关片段验证，而不是只凭替换命令结果回复。
|
||
5. 最终回复只说明改了什么，不要重复发送不必要附件。
|
||
|
||
## 更新任务规则
|
||
|
||
当用户在已有文章基础上提出修改，例如“删掉 One+”“增加 BOXX 交易法”“不要用 Week”“输出完整文章”“再打包”：
|
||
|
||
1. 不要只输出修改片段，除非用户明确要求“只给新增段落”。
|
||
2. 默认更新完整 Markdown 文件。
|
||
3. 如果修改影响配图或配图清单，必须同步更新对应图片引用和 assets 文件名。
|
||
4. 如果用户要求文件或打包，必须重新生成 ZIP。
|
||
5. 最终回复给出最新 Markdown 和 ZIP 链接，避免继续给旧文件。
|
||
|
||
## 最终交付前检查清单
|
||
|
||
交付前必须逐项确认：
|
||
|
||
- Markdown 文件已生成。
|
||
- `assets/` 目录已生成。
|
||
- 所有 Markdown 图片路径都能对应到真实图片文件。
|
||
- 图片是多张独立 PNG，不是一张大图代替全部。
|
||
- 文末来源区只包含实际使用的来源。
|
||
- 正文没有 `contentReference`、`oaicite`、调试标记或工具残留。
|
||
- 用户要求删除的分支，标题、正文、配图清单和来源区都已删除干净。
|
||
- ZIP 包已创建。
|
||
- 用户最后确认的标题是否已同步到 frontmatter 和 H1。
|
||
- 用户要求删除的词是否只删除指定词，未误删整条信息。
|
||
- 正文是否残留编辑指令或模型解释。
|
||
- 用户不喜欢的模糊词，例如“更像”“可能”“大致”，是否已按上下文清理。
|
||
- TLDR 是否过长，是否适合当前平台。
|
||
- 小红书图是否为 9:16 竖版，是否每张都有 MAOMOMO 标识。
|
||
- 图片是否匹配最终文章口径，未残留旧规则、旧金额、旧标题。
|
||
- 邮件/聊天附件是否按用户要求选择 ZIP 或多个独立附件。
|
||
- 若已发送过旧版本，最终回复要明确这是最后版本，避免重复发同一批图片。
|
||
- 最终回复包含 Markdown 下载链接和 ZIP 下载链接。
|