Improve revision and multi-channel delivery rules

SKILL.md

@@ -21,6 +21,30 @@ description: 生成符合 maomomo / 猫momo 风格的中文实操文章、发布
 
 生成完整文章、配图或打包交付时，必须先读取 `references/delivery-rules.md` 并按其中规则执行；同时读取 `references/style-guide.md` 获取更细的文章模板、标题套路、常用词、图片规则和不同类型文章骨架。
 
+## 改稿协作规则
+
+用户后续改稿时，所有要求都先视为编辑指令，不得原样写入文章正文。
+
+- 用户说“不要写 X”：删除或改写 X，不要在正文解释“不要写 X”。
+- 用户说“应当写成 Y”：把 Y 转成自然文章表达，不要写“应当写成”。
+- 用户说“这个口径 / 我的要求”：这是写作指令，不是正文素材。
+- 用户说“删掉几个字 / 某个词”：只删指定词，不扩大成删除整条、整段或整节。
+- 用户说“合并 3、4”或“6、7 合并”：只合并对应条目，保留原信息，必要时重排编号。
+- 用户反复纠正某个词，例如“更像”“可能”“最高”等，后续同文档同类位置都要检查并同步清理。
+- 用户确认的实测口径优先写成结论，不要反复声明“本文以实测为主”“官方条款仅供参考”等元叙述。
+- 改完必须检查正文是否残留编辑痕迹，例如“准确写法是”“不要写”“用户要求”“本文口径”“应当”。
+
+## 实测活动文章规则
+
+处理银行、支付、返现、优惠券、券商迎新等活动时，如果用户提供了明确实测经验，正文应优先呈现实操结论。
+
+- 官方条款用于确认活动边界、日期、排除项和来源区。
+- 实测经验用于组织“怎么吃”“怎么判断出券”“哪里会翻车”。
+- 不要写成官方宣传稿，也不要把“官方条款仅供参考”作为正文口号反复出现。
+- 实测结论要直接写，例如“按支付宝账号算”“按卡算”“先刷后返”“不出券先看账号”。
+- 对用户明确确认的口径，不要再写“更像”“可能”“大致”等模糊词。
+- 仍要避免绝对承诺到账、稳赚、一定成功；可用“直到名额耗尽或风控拦截”等实际限制表达。
+
 ## 输出模式
 
 根据用户要求选择输出形态：

references/delivery-rules.md

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

references/style-guide.md

@@ -171,6 +171,41 @@ MAOMOMO 是偏实操的出海经验平台。公开站点标语是：“打破信
 - 核心结论可以放在引用块里。
 - 结尾提醒政策变化风险，例如“直至另行通知”“随时可能取消”。
 
+### 6. 小红书发布版 / 4 图看完
+
+用户说“小红书”“发小红书”“4图看完”“超短文字”“20字内标题”时，进入小红书模式。
+
+交付物：
+
+- 20 字内标题。
+- 超短正文，适合直接复制发布。
+- 3-6 个话题标签。
+- 4 张 9:16 竖版 PNG 图，不复用文章横版图。
+- 每张图加入 MAOMOMO logo / 猫咪水印。
+- 如果用户要求 email，按用户要求打包或多附件发送。
+
+文字规则：
+
+- 标题短、有钩子，但不要夸大。
+- 正文只写核心结论、操作路径、避坑点。
+- 不堆官方条款，不写长来源区。
+- 数字必须准确，例如每号多少、按卡还是按账号、先刷后返。
+
+4 图默认结构：
+
+1. 封面：主题 + 最大钩子 + 3 个标签。
+2. 核心拆解：两条线 / 三个数字 / 最重要规则。
+3. 操作流程：3-5 步即可。
+4. 避坑总结：先看什么、哪里会翻车、不要做什么。
+
+视觉规则：
+
+- 纵向 9:16，手机端可读，大字少字。
+- 每张图独立，不要拼图。
+- 每张图有 MAOMOMO 标识。
+- 文章横图不能直接当小红书图；需要重新设计。
+- 如果用户提供卡片、截图或 Logo 参考，只做原创示意，不复制敏感信息，不伪造真实 App 页面。
+
 ### 5. 避坑经验
 
 用于“不要浪费时间试了”、DCC、支付失败、转账姓名顺序问题、线下网点提醒等。