113 lines
6.6 KiB
Markdown
113 lines
6.6 KiB
Markdown
# 来源与事实核查规则
|
||
|
||
写最终稿前，只要涉及费用、活动、返现、奖励、账户规则、开户资格、转账路径、数字货币出入金、税务、法律或合规事项，就先读本文件。
|
||
|
||
## 来源读取顺序
|
||
|
||
优先级从高到低：
|
||
|
||
1. 用户提供的最新官方材料：活动页、条款 PDF、App 截图、邮件、公告、客服记录。
|
||
2. 官方网站、官方 App、官方 PDF 或官方公告。
|
||
3. 用户提供的实测记录、账单截图、到账记录和社群反馈。
|
||
4. MAOMOMO 现有文章或用户指定参考文章。
|
||
5. 其他公开资料。
|
||
|
||
如果用户要求“最新”“当前”“今天还能不能用”等时效性判断，必须联网或读取用户提供的新材料确认。不要只依赖旧文章或模型记忆。
|
||
|
||
## 已读来源清单
|
||
|
||
涉及活动、金融产品或官方规则时，先向用户列出来源读取状态：
|
||
|
||
```text
|
||
已读取来源：
|
||
- 官方活动页：已读 / 未读 / 无法读取
|
||
- 主活动条款 PDF：已读 / 未读 / 无法读取
|
||
- 补充条款 PDF：已读 / 未读 / 无法读取
|
||
- App / 邮件 / 客服截图：已读 / 未读 / 无法读取
|
||
- 用户实测记录：已读 / 未读 / 无法读取
|
||
- 参考文章：已读 / 未读 / 无法读取
|
||
```
|
||
|
||
如果有多个 PDF 或多个官方页面，不能只读其中一部分就写最终稿。无法读取时要说明影响，例如“无法确认活动截止日，只能标待确认”。
|
||
|
||
## 事实表
|
||
|
||
写稿前整理这些字段，缺失就标 `【待确认：...】`：
|
||
|
||
| 字段 | 要确认的内容 |
|
||
|---|---|
|
||
| 时间 | 活动开始日、截止日、登记日、交易日、入账日、奖励发放日 |
|
||
| 对象 | 地区、年龄、账户类型、新老客户、卡种、会员等级、邀请渠道 |
|
||
| 门槛 | 单笔 / 累计金额、交易次数、入金金额、持有期、任务顺序 |
|
||
| 奖励 | 比例、金额、封顶、名额、是否先到先得、是否可叠加 |
|
||
| 排除项 | 不支持渠道、排除 MCC、转账 / 充值 / 现金类交易、退款规则 |
|
||
| 成本 | 年费、汇款费、点差、交易费、税费、潜在机会成本 |
|
||
| 实测 | 用户实测是否成功、按账号还是按卡、多久到账、账单怎么显示 |
|
||
| 风险 | 风控、活动变更、资格审核、投资波动、汇率、税务和合规限制 |
|
||
|
||
## 口径冲突处理
|
||
|
||
- 最新官方条款优先于旧活动页。
|
||
- App 实际显示优先于旧文章截图。
|
||
- 官方条款用于确定边界、日期、排除项和资格；用户实测用于组织“怎么吃”“哪里会翻车”。
|
||
- 用户确认的实测口径必须直接写成结论，不要写成模棱两可的“可能”“疑似”“大概”。例如素材写“实测 CPF 现场办理成功立即生效”，正文应写“实测 CPF 现场办理成功后立即生效”，不要写“可能立即生效”。
|
||
- 用户素材包含“以往惯例”“过往尿性”“过往经验”“按之前案例”“历史上很多人这样成功”等表达时，正文要写成强概率判断，而不是弱猜测。推荐写法是“按过往案例判断，大概率仍然可以...”“从以往执行口径看，本次大概率还是...”。不要降级成“可能可以”“或许可以”。
|
||
- 当官方条款和用户实测 / 过往经验冲突时，写法要分层：先交代官方条款，再给实测或惯例判断。例如“官方写明合资格消费不包含支付宝 / 微信，但按照建亚 Travo 过往案例，很多人仍然用支付宝 / 微信消费达标并拿到 4% 返现和迎新奖励；所以本次活动大概率仍可用支付宝 / 微信消费达标，最终以银行系统入账和奖励判定为准。”
|
||
- 如果主活动、额外会员活动、年龄限定活动或旧版活动混在一起，先建议主文只保留大多数读者适用内容，小众分支放“补充说明”或删去。
|
||
- 来源差异无法解决时，在正文用保守表达，并在来源区说明以官方条款和 App 实际显示为准。
|
||
|
||
## 实测和惯例语气规则
|
||
|
||
用户给出的素材里，如果明确包含以下证据类型，按对应语气写：
|
||
|
||
| 素材类型 | 正文语气 | 示例 |
|
||
|---|---|---|
|
||
| 明确实测成功 | 确定语气，直接写结果 | “实测现场办理成功后立即生效。” |
|
||
| 明确实测失败 | 确定语气，直接写不能用 / 不生效 / 不计入 | “实测这条路径不会计入任务。” |
|
||
| 用户确认的账单 / 到账 / 出券结果 | 确定语气，说明观察到的结果 | “账单显示按支付宝账号计算。” |
|
||
| 过往惯例 / 过往尿性 / 历史案例 | 强概率判断 | “按过往案例判断，本次大概率仍可用支付宝 / 微信消费达标。” |
|
||
| 只有猜测、没有实测或历史依据 | 保守语气 | “这部分需要二次确认。” |
|
||
|
||
禁止把强证据写弱：
|
||
|
||
- 不要把“实测立即生效”写成“可能立即生效”。
|
||
- 不要把“很多人过往用支付宝 / 微信达标成功”写成“也许可以用支付宝 / 微信”。
|
||
- 不要把“用户确认按账号算”写成“更像是按账号算”。
|
||
|
||
允许保留的风险尾巴：
|
||
|
||
- “最终以银行系统记录和奖励入账为准。”
|
||
- “如果这次银行调整后台判定，结果可能变化。”
|
||
- “操作前仍建议看一眼 App 活动页是否有新增限制。”
|
||
|
||
风险尾巴不能推翻主句。主句应先给明确判断，再补边界。例如写“本次大概率仍可用支付宝 / 微信消费达标，最终以银行系统判定为准”，不要写“可能可以用支付宝 / 微信”。
|
||
|
||
## 风险表达
|
||
|
||
禁止：
|
||
|
||
- “稳赚”“无风险套利”“一定到账”“一定获批”“闭眼稳赚”“保证拿满”。
|
||
- 把股票、ETF、基金、数字货币、汇率敞口说成存款或保本产品。
|
||
- 替用户给出法律、税务、投资或合规结论。
|
||
|
||
推荐：
|
||
|
||
- “适合本来就有相关消费 / 入金 / 交易需求的人。”
|
||
- “最终是否计入活动，以银行 / 券商系统记录为准。”
|
||
- “活动可能随时调整，操作前建议二次确认 App 和官方条款。”
|
||
- “股票 / ETF / 数字货币存在价格波动、汇率、买卖差价、成交滑点、交易成本和税务风险。”
|
||
|
||
默认免责声明：
|
||
|
||
```text
|
||
本文为经验整理，不构成金融、投资、法律或税务建议；活动和规则可能随时调整，请以官方条款、App 实际显示及当地法规为准。
|
||
```
|
||
|
||
## 来源区
|
||
|
||
- 所有链接统一放在文末 `## 来源` 区。
|
||
- 来源区只保留最终文章实际使用的来源。
|
||
- 引用 MAOMOMO 时链接具体文章或页面，不只放首页。
|
||
- 用户要求删除某个活动分支时，对应来源也要删除。
|
||
- 发布用 Markdown 不保留 `contentReference`、`oaicite`、模型内部引用或工具残留。
|