---
name: 通用-输出番茄版
description: '用于把小说章节改写为更适合番茄小说网的版本。适合免费阅读平台、强钩子、快反馈、高完读率正文输出；供多个题材的 `题材名-输出番茄版` 包装层路由使用。关键词：输出番茄版、番茄小说网、番茄化改写、免费阅读平台。'
argument-hint: '要把哪一章输出为番茄版？默认按“保留核心信息 + 快反馈强钩子 + 直接按平台骨架改写”处理。'

---

# 通用-输出番茄版

这是平台共性本体，负责承接“番茄版输出”的跨题材共性规则。

## 平台实战经验与成长建议（知乎高赞答主经验迁移）

### 1. 收入与现实门槛
- 番茄稿费与完读率、字数、推荐量强相关，单靠拼字数无效，需高完读率和持续追更。
- 大部分新人收入有限，爆款极少，需理性预期。

### 2. 平台机制与成长路径
- 首秀、推荐验证、书测、全勤奖等环节有明确门槛（如十万字完读率15%+、日更要求），流量池分级，断更/低完读率会被降权。
- 黄金三章决定生死，前三章完读率直接影响后续流量。

### 3. 读者画像与内容偏好
- 以三线及以下城市、低收入、低学历为主，偏好快餐文学、直给爽点、情绪拉扯、强钩子、短段落、快节奏。
- 文笔要求低但情节抓人，书名需长且直给，卖点、身份、金手指、反差等元素组合。

### 4. 写作与适配建议
- 首章前300字/7行必须有爆点或冲突，300-800字一抓点，章末强钩子。
- 多用短句、感官细节、情绪刺激，避免大段设定和自嗨。
- 关注数据反馈，及时调整内容和节奏，避免断更，持续提升故事力。
- 合理安排更新频率和字数，确保完读率门槛达标。

### 5. 常见误区与成长建议
- 杜绝只拼字数、气氛拖字、无大纲注水、频繁断更等低效写作方式。
- 先学后写，反复修正，关注数据，持续提升故事力和平台适配度。
- 坚持不一定有回报，但不坚持一定没回报。

> 本节内容基于知乎高赞答主真实创作与变现经历，已与本Skill现有规则融合，供所有番茄平台适配任务参考。

## 番茄平台爆款写作实操要点（知乎高赞经验精华）

1. **书名要长且爆**：
	- 标题必须用一句话吸引人，题材、人物、身份、金手指、爽点、反差点等元素排列组合，标题即卖点。
	- 例：只看标题就能明白故事核心，拒绝抽象、无钩子的短标题。

2. **开头必须爆点**：
	- 前7行/300字务必抛出冲突、反差或危机，绝不允许慢热或大段设定。
	- 让读者一眼看到“异常/危机/反常/损失”，直接丢进矛盾现场。

3. **调动情绪，拉扯感强**：
	- 小说是放大生活，要用极端、放大的情节和冲突激发读者情绪，而非平铺直叙。
	- 每章/每段都要有情绪刺激点，不能只靠自嗨或平淡叙述。
	- 例：让主角遭遇极端不公、反转、打脸、爽点，制造“必须追下去”的情绪波动。

4. **关注数据，动态调整**：
	- 持续关注完读率、书架比、评论互动等数据，主动调整内容和节奏。
	- 研究榜单和热门题材，动态优化创作方向。
	- 与其纠结稿费，不如专注提升故事力和读者认可度。

5. **持续学习与成长**：
	- 先学后写，反复修正，关注数据，持续提升故事力和平台适配度。
	- 坚持不一定有回报，但不坚持一定没回报。

> 本节为知乎高赞答主爆款经验精华，强烈建议所有番茄平台适配任务优先对照执行。

## 常见触发词 / 用户说法速查


## 番茄平台实际执行规则补充
- 输出番茄版
- 改成番茄能发的版本
- 做番茄平台改写
- 帮我把这章改得更快反馈更强钩子

## 何时使用

- 把任意题材章节改写成更适合番茄小说网读者的版本。
- 需要强化快反馈、强钩子、短段落与高完读率节奏。
- 需要为题材包装层提供统一的番茄平台共性骨架。

## 不适用情形

- 只做题材边界补充，不做平台输出本体。
- 只做多平台编排、落盘和终检，而不处理番茄平台风格本身。

## 本层职责

- 维护番茄平台的跨题材共性规则。
- 统一承接番茄版输出的标题倾向、结构约束、字数与风格门禁。
- 调用 通用-设计标题 的嵌入式轻量模式对本章标题做平台适配优化，确保标题长度不超过本平台截断风险线、标题风格符合本平台读者预期。
- 为 `题材名-输出番茄版` 提供稳定的通用平台骨架。

## 平台默认字数范围

以下为本平台通用默认字数范围，适用于未在项目 `Agents.md` 中指定字数覆盖值的情况。若项目 `Agents.md` 已指定该平台的字数要求，则以 `Agents.md` 为准。

- 正文：2000–3500 CJK
- 作者有话说：150–250 CJK

- `references/平台共性执行细则.md`
- `references/分节级补救映射与详细规则回填.md`

## 与题材包装层的协作说明

- 若对应题材已有 `题材名-输出番茄版`，必须先由题材包装层锁定：题材边界、题材禁行项、题材专项补丁、题材 refs 调度与题材输出口径。
- 本 Skill 只负责番茄平台的跨题材共性：标题倾向、短段落、快反馈、章末硬钩、平台门禁、落盘与终检骨架。
- 若题材包装层与本 Skill 出现冲突：
	- 题材边界、题材禁行项、题材专项补丁 → 以题材包装层为准；
	- 平台共性节奏、平台结构、平台终检门禁 → 以本 Skill 为准。
- 若用户直接命中本 Skill 且仓库内存在对应题材包装层，不应绕过题材包装层直接把平台共性套到正文上。
- 若仓库内暂时不存在对应题材包装层，本 Skill 只能保守执行平台共性，不得臆造题材规则。

## 历史迁移参考（非默认调度）

- `references/跨题材共性与迁移来源.md`

该文件仅用于追溯迁移来源、核对历史承接关系或处理遗留映射缺口；默认执行时，不把它当作当前跨题材平台规则主承载。

注：题材专属平台研究补充（如“番茄都市悬疑”）已下沉到对应题材 Skill 的 `references/`，不在通用层平行维护。

## 缓存优化说明

本 Skill 的结构遵循前缀缓存优化原则，调用时：

- **缓存层 1（永久不变）**：frontmatter + 本层职责 + 平台硬规则 + 禁行项 + POV 契约 → 每次调用完全相同，LLM API 的前缀缓存永久命中，按底价计费
- **缓存层 2（同平台内不变）**：平台模板自动发现规则 + references 清单 + 默认执行顺序 → 仅在切换平台或新增模板注册时变化
- **可变层（每次变化，不写入本文件）**：本次目标章节号、源稿路径、用户指定的特殊平台约束 → 由用户每次调用时指定，按正常输入价计费

人物传记、故事设定、写作研究模板等 references 通过 `## 继续读取的 references` 声明强制加载，其固定部分随本 Skill 一起进入缓存前缀。

## 平台模板自动发现规则

若当前服务的项目根目录存在 `Agents.md`，执行番茄版输出前必须：

1. 读取项目根目录的 `Agents.md`
2. 若 `Agents.md` 中注册了三类模板，按以下优先级检索：
   - **优先**：模板注册时 "适用平台" 字段为 `番茄` 的同类型模板
   - **回退**：模板注册时 "适用平台" 字段为 `默认` 的同类型模板
   - **忽略**：模板注册时 "适用平台" 指向其他平台的模板（如 `起点`、`七猫`），本轮不加载
3. 若检索到匹配的三类模板——读取对应路径的模板文件：
   - 写作研究模板：作为番茄平台的额外平台基线约束
   - 作者风格模板：作为番茄版本保留底味和文风边界的参照
   - 作品蓝本模板：作为章首/回报/钩子结构保真的参照
4. 若项目根目录不存在 `Agents.md`，或其中未注册番茄专属模板——回退通用默认模式，不影响正常输出
5. 本 Skill 的核心约束始终是：平台规则 > 安全合规 > 母稿事实 > 三模板约束。三模板是辅助，不改变平台输出规则

## 默认执行顺序

1. 先锁定源稿不可变层：事实、事件链、证据链、角色关系与因果顺序不得改坏。
2. 读取对应题材的 `题材名-输出番茄版` Skill，确认题材入口与路由关系。
3. 再读取本 Skill 的 `references/平台共性执行细则.md` 与 `references/分节级补救映射与详细规则回填.md`，执行番茄平台的节奏强化、抓点布置、章末硬钩子与读屏优化。
4. 由题材包装层继续读取其题材 references，锁定题材边界、题材禁行项与题材专项补丁（作为兜底约束）。
5. 在“平台优先、题材兜底”前提下执行改写正文，确保平台化表达与源稿保真同时成立。
6. 最后才处理降相似度，不得为了降重破坏移动端抓力与章末追读驱动。
7. 执行 POV 契约复核，确保与 `platformPovContract` 一致，不得出现未授权人称漂移。
8. 改写输出完成后，必须立即执行“输出后自检与修订”节的五项自检，不得跳过。
9. 若自检未通过，必须按结论回炉修订并复检，直至“自检通过/自检修订完成”后方可落盘。
## POV 契约与连续性（强制）

- 若本次由 `通用-多平台输出编排` 调度，必须继承该流程已锁定的 `platformPovContract`，不得在本 Skill 内重新决定人称。
- 若用户直接命中本 Skill，则必须在改写前先从源稿正文与当前平台已完成前序章节中推断并锁定 `platformPovContract`；默认优先级为：用户明确指定 > 当前平台已完成前序章节 > 源稿既有 POV 链路 > 本批次首个已通过章节。
- 未获批准不得把连续章节从第三人称静默改成第一人称，或反向漂移；若源章本来就是视角切换章 / 多视角连续章，只能按已登记 `switchPlan` 执行，不得临场换壳。
- 落盘前后都必须显式执行 POV 校验，并把结果写入日志或执行记录；中文平台默认使用 `scripts/pov_validate.py` 或 `scripts/run_pov_gate.ps1` 以 `lang=zh` 或 `auto` 复核正文区块，第三人称链路检查对话外第一 / 第二人称，第一人称链路检查对话外第一人称锚点。

## POV 选择指南（如无显式契约）

> **强制前置步骤**：必须首先读取工作区根目录 `Agents.md` 的 `## 平台POV基线表` 节，查找本平台的当前锁定人称。若基线表中无本平台条目，必须先在该表中创建条目并锁定人称（参考下方"适用场景分析"），再继续执行。
>
> **人称是全书级契约**：基线表锁定值即为本平台全书的唯一人称，不得逐章切换，不得章内混用（对话引用除外）。极特殊情况下某章须切换主视角人物时，该章开头必须明确声明「我是[角色名]」，且整章只保持该角色的第一人称叙事。

若本次执行未获得上游明确的 `platformPovContract` 锁定，按以下指南为本平台适配稿确定人称（最终以 `Agents.md` 的 `## 平台POV基线表` 节锁定值为准）：

### 番茄版的人称适用场景（供创建/修订基线表条目时参考）

**平台底层逻辑**：番茄是典型的"免费阅读 + 算法分发"平台，核心读者群以三线及以下城市、碎片化时间（通勤/午休/睡前）阅读为主。书的生死取决于前三章完读率——这意味着前 300 字必须有爆点，每一屏都要有情绪回报。研究显示头部作品普遍采用"第三人称有限视角"。

**为什么番茄头部作品偏第三人称？**
- 番茄读者的核心需求是"快速获得情绪刺激"，而非"深度共情"。第三人称的"有限全知 + 多线 POV"可以在一段内同时呈现多个角色的反应（"甲脸色发白，乙后退一步，丙冷笑了一声"），信息密度远高于第一人称的单视角。手机端一屏的信息量 = 读者的留去决策。
- 番茄悬疑的核心驱动是**外部事件密度**，而非内心心理密度。第三人称天然适合快速场景切换和多人物动态展现。第一人称容易滑向心理独白——而番茄读者对"我心里想…"的容忍度极低，它会直接拉低完读率。
- 番茄的推荐算法本质上是"快反馈引擎"：每章末的强钩子 >> 人物内心弧线。第三人称的"章末悬念"可以通过切换视角制造信息差（读者知道危险在逼近但主角不知道），这种"上帝视角式紧张"是第一人称做不到的。

**什么时候番茄应该用第一人称？**
- 故事的主题就是**主角的独特感知本身**。比如主角有特殊能力（如量子纠缠共感），读者需要通过"我"的感知来直接体验这种异常。这不是"侦探破案"型故事，而是"异能力者生存"型故事——个人视角是题材核心卖点，不可替代。
- **封闭空间/猫鼠游戏型**悬疑。如密室、诡舍、单人对峙——场景天然限制在主角感知内，第一人称的"信息同步"制造最强紧张感。
- **第一人称的警告**：番茄第一人称必须严格控制心理独白比例（不超过外部事件描写的 30%）。每段心理独白后必须有外部动作或对话跟进。否则算法数据（完读率、追读率）会直接反馈——读者滑走了。

## 默认输出口径

- 默认输出一版可直接继续落盘或进入平台终检的番茄派生正文。
- 默认保留原章核心事件链、快反馈节拍与章末硬钩子，不新增关键事实。

- 保住原章核心事件链、追读驱动与移动端可读性。
- 读起来不像泛免费平台稿，也不像把正文剪成摘要段子。

## 输出后自检与修订（必做，不得跳过）

改写输出完成后，必须立即执行本节自检；根据发现的问题就地修订，确认通过后方可落盘。**不得以任何理由跳过本步骤。**

**五项自检：**

0. **字数达标**：正文和 `## 作者有话说` 应参考本 Skill 的"平台默认字数范围"（或项目 `Agents.md` 覆盖值）。正文未达推荐下限前，建议先回炉补足字数。**严格禁止为凑字数进行模板化补字或机械扩写**；若检测到模板句污染、解释腔堆砌或无意义重复，则判定字数虽足但自检失败，必须重写。
1. **零新增事实**：改写版未引入源稿中不存在的关键事实、人物或设定；引入则删除/还原。
2. **核心事件链完整**：起因→推进→高潮→章末钩子方向均在改写版中体现；断裂则补回。
3. **平台风格达标**：改写版满足本 Skill“最低交付”（或平台核心风格要求）所列各项；不足则就地修订。
4. **无模板句污染**：未出现连续 2 句及以上解释腔/模板腔/口径名词句群；命中则整段回炉。
5. **POV 一致**：改写版 POV 与已锁定的 `platformPovContract` 一致；漂移则回炉修正。

**结论格式（必须输出）：**

- 全部达标：`[自检通过] 五项均达标，可落盘。`
- 已修订达标：`[自检修订完成] 已修订：<问题描述>，现五项均达标，可落盘。`
- 未通过（不得落盘）：`[自检未通过] 命中：<问题描述>，需继续处理。`

命中“未通过”后必须修订并重新输出自检结论，循环直至输出“通过”或“修订完成”方可落盘。

## 硬规则

- 章节标题在番茄可偏长、可信息密集；标题长度必须按“去除 `x.y.z ` 形式章节编号及其后空格”后的纯标题计数。**唯一硬约束是纯标题不得超过 30 个汉字**，其余按内容需要自行组织，不额外施加“必须短标题”限制。
- 绝对禁止输出“抽象自述 + 动词模板 + 口径名词”的垃圾句群；凡出现类似“对照项落在… / 先把同一句话拆碎 / 先把顺滑的解释拆开 / 只求能追溯（复核、对得上）”等模板化短语，必须判定为污染并整稿回炉。
- 严禁使用或间接调用以下脚本对正文做生成、扩写、拼接或降重：`scripts/append_cn_unique_monologue.ps1`、`scripts/append_cn_unique_narration.ps1`、`scripts/append_cn_unique_thirdperson.ps1`、`scripts/rephrase_cn_body.ps1`、`scripts/rephrase_en_body.ps1`、`scripts/cn_lexicon_profile_transform.ps1`。这些工具不得进入平台正文生产链路。
- 平台稿新增“模板句污染清零门禁”：正文不得出现连续 2 句及以上“我/我这边/我心里… + 把/将… + 对齐/校准/锁死/拆开… + 连接词 + 口径名词 + 只求/不求/先把…”结构；命中即失败，不论字数与相似度是否通过。
- 平台连续章必须服从已锁定的 `platformPovContract`；不得在本 Skill 内擅自把前序稳定链路改成人称新链路。
- 若命中未授权 POV 切换或 POV 校验失败，必须按 `pov_drift_detected` / `pov_switch_without_approval` 判定失败并整稿回炉。

- 命中本技能时，必须同时加载对应题材的 `题材名-输出番茄版` Skill。
- 题材特有规则不得回写到本文件中平行维护。
- 修改番茄平台共性规则时，应优先修改本 Skill，而不是多个题材入口。
- 不得把历史迁移参考里的 `都市悬疑` 口径直接当成跨题材默认规则继续扩散。
- 平台派生正文默认落在本 Skill 的工作目录 `番茄小说/` 下。
- 章节级派生正文目录统一按小说结构决定：若作品有分部，则位于 `番茄小说/第X部/第Y卷/`；若作品无分部，则位于 `番茄小说/第X卷/`。
- 平台派生正文文件名默认不带日期，沿用既有章节号与平台标题同步规则；日期只用于配套审阅报告、书评等派生产物。
- 章节派生正文必须以 `.md` 文件形式落盘：若对应章节目录不存在，执行前必须先创建完整目录路径，再将改写后的章节内容写入该目录下的 `.md` 文件，不得只输出聊天稿而不写入文件。
- 落盘路径的完整推断优先级：① 用户显式指定 chapterPath → ② 从源文件名与分部/卷信息自动推断 → ③ 若无法确定分部/卷，暂停并向用户确认，不得乱推断后静默落盘。
- 平台稿落盘后必须显式运行字数门禁：**正文字数检测必须使用 `scripts/count-chapter.ps1`**，不得用 `Len`、`NoWhitespaceLen`、编辑器字符数或目测代替。字数参数以本 Skill 的"平台默认字数范围"或项目 `Agents.md` 覆盖值为准，用 `scripts/count-chapter.ps1` 校验正文；正文门禁只看 `BodyCJK / MeetsMinCJK / WithinRange`，`MeetsMinCJK` 必须为 `True`，`WithinRange` 最好为 `True`。`## 作者有话说` 用 `scripts/count-afterword.ps1` 单独校验。
- 生成阶段建议先达到字数保底目标再允许落盘：以本 Skill 的"平台默认字数范围"或项目 `Agents.md` 覆盖值为准。
- 在无损迁移完成前，不得删除源 `输出番茄版.prompt.md` 中尚未完成映射的内容。

## 与其他 Skill / Prompt 的边界

- 本 Skill 只负责番茄平台的跨题材共性骨架。
- 题材边界、题材禁行项与题材特有口径，继续由对应 `题材名-输出番茄版` 承接。
- 题材 Prompt 只应路由到 `题材名-输出番茄版`；不应直接把本 Skill 与题材 refs 并列成双入口。
