codebee 0.1.71 → 0.1.73

package/app/core/skillpacks/market/release-notes.md

@@ -1,72 +1,72 @@
----
-name: 版本发布说明撰写模板
-note: 面向用户的更新公告：固定六段结构 / 写作纪律 / 破坏性变更三要素 / 可复制模板与反例
-scopes:
-- "*"
-source: market
-market_id: release-notes
----
-
-# 版本发布说明撰写模板（市场包）
-
-适用：发版时写 Release Notes / 更新公告 / changelog 的用户可读部分。
-核心立场：**写给用户看，不是写给 git log 看**——用户不关心重构了哪个模块，
-只关心「这次更新后我能多做什么、少烦什么、会坏什么」。
-
-## 一、标准结构（顺序固定）
-1. **一句话概览**：这版最值得用户知道的一件事；实在没有就写「稳定性修复」。
-2. **新功能**：能做以前做不了的事。每条 = 功能名 + 用户收益 + 入口在哪。
-3. **体验优化**：以前能做、现在更快 / 更顺 / 更省的事。
-4. **问题修复**：写用户见过的**症状**（「修复导出 PDF 中文乱码」），
-   不写内部成因（「修复字体子集化模块的编码偏移」）。
-5. **升级注意事项 / 破坏性变更**：有则紧跟概览**置顶**（不按上面的顺序排），
-   没有就省略此节。
-6. **已知问题**：带着已知问题发版必须如实列出，并给临时绕过办法。
-
-## 二、写作纪律
-- 每条只说**一个行为变化**，动词开头、面向结果：「支持按标签筛选任务」，
-  而不是「重构筛选服务并接入标签存储」。
-- 收益优先于实现：先说用户能干什么，实现细节放括号或链接里。
-- 数字具体化：「启动更快」要写成「冷启动从约 6 秒降到约 2 秒」；
-  没有数据不要编数字。
-- 不用内部术语：对用户写「登录更稳定」，不写「修复 OAuth2 refresh token 竞态」；
-  这类内容放进面向开发者的附录小节。
-- 每条尽量带出处：issue / PR / 需求单号，方便日后回溯。
-
-## 三、破坏性变更的写法（最容易写砸的部分）
-- 三要素齐全：**什么会坏**（哪个行为 / 接口 / 配置）、**影响谁**、**怎么办**
-  （迁移步骤或替代写法，给可直接复制的示例）。
-- 正面示例：
-  > **升级注意**：`/api/tasks` 返回的 `status` 字段由中文改为枚举值
-  > （`running` / `done` / `failed`）。依赖该字段的脚本需同步修改，
-  > 新旧值对照表见帮助文档「status 迁移」一节。
-- 「可能影响部分用户」这类模糊表述禁止——写清判定条件，让用户 10 秒内
-  判断自己在不在影响范围内。
-
-## 四、模板（可直接复制）
-```
-## vX.Y.Z 更新说明（YYYY-MM-DD）
-
-概览：一句话说清这版最重要的事。
-
-### 新功能
-- 支持xxx：现在可以……（入口：设置 > xxx）(#123)
-
-### 优化
-- xxx 更快 / 更省：从……到……
-
-### 修复
-- 修复「用户看到的现象」(#456)
-
-### 升级注意
-- 变更点 → 影响谁 → 迁移步骤（附示例代码或对照表链接）
-
-### 已知问题
-- ……；临时绕过：……
-```
-
-## 五、反例对照
-- 反例：「优化了底层性能。」→ 正例：「任务列表在 1 万条数据时加载时间从约 4 秒降到约 1 秒。」
-- 反例：「修复若干问题。」→ 正例：「修复搜索结果偶发重复显示；修复深色模式下按钮文字不可读。」
-- 反例：「接口升级，请注意适配。」→ 正例：按三要素写全（什么坏 / 影响谁 / 怎么办）。
-- 反例：「重构核心模块。」→ 用户视角无行为变化的重构不进用户公告，放开发者 changelog。
+---
+name: 版本发布说明撰写模板
+note: 面向用户的更新公告：固定六段结构 / 写作纪律 / 破坏性变更三要素 / 可复制模板与反例
+scopes:
+- "*"
+source: market
+market_id: release-notes
+---
+
+# 版本发布说明撰写模板（市场包）
+
+适用：发版时写 Release Notes / 更新公告 / changelog 的用户可读部分。
+核心立场：**写给用户看，不是写给 git log 看**——用户不关心重构了哪个模块，
+只关心「这次更新后我能多做什么、少烦什么、会坏什么」。
+
+## 一、标准结构（顺序固定）
+1. **一句话概览**：这版最值得用户知道的一件事；实在没有就写「稳定性修复」。
+2. **新功能**：能做以前做不了的事。每条 = 功能名 + 用户收益 + 入口在哪。
+3. **体验优化**：以前能做、现在更快 / 更顺 / 更省的事。
+4. **问题修复**：写用户见过的**症状**（「修复导出 PDF 中文乱码」），
+   不写内部成因（「修复字体子集化模块的编码偏移」）。
+5. **升级注意事项 / 破坏性变更**：有则紧跟概览**置顶**（不按上面的顺序排），
+   没有就省略此节。
+6. **已知问题**：带着已知问题发版必须如实列出，并给临时绕过办法。
+
+## 二、写作纪律
+- 每条只说**一个行为变化**，动词开头、面向结果：「支持按标签筛选任务」，
+  而不是「重构筛选服务并接入标签存储」。
+- 收益优先于实现：先说用户能干什么，实现细节放括号或链接里。
+- 数字具体化：「启动更快」要写成「冷启动从约 6 秒降到约 2 秒」；
+  没有数据不要编数字。
+- 不用内部术语：对用户写「登录更稳定」，不写「修复 OAuth2 refresh token 竞态」；
+  这类内容放进面向开发者的附录小节。
+- 每条尽量带出处：issue / PR / 需求单号，方便日后回溯。
+
+## 三、破坏性变更的写法（最容易写砸的部分）
+- 三要素齐全：**什么会坏**（哪个行为 / 接口 / 配置）、**影响谁**、**怎么办**
+  （迁移步骤或替代写法，给可直接复制的示例）。
+- 正面示例：
+  > **升级注意**：`/api/tasks` 返回的 `status` 字段由中文改为枚举值
+  > （`running` / `done` / `failed`）。依赖该字段的脚本需同步修改，
+  > 新旧值对照表见帮助文档「status 迁移」一节。
+- 「可能影响部分用户」这类模糊表述禁止——写清判定条件，让用户 10 秒内
+  判断自己在不在影响范围内。
+
+## 四、模板（可直接复制）
+```
+## vX.Y.Z 更新说明（YYYY-MM-DD）
+
+概览：一句话说清这版最重要的事。
+
+### 新功能
+- 支持xxx：现在可以……（入口：设置 > xxx）(#123)
+
+### 优化
+- xxx 更快 / 更省：从……到……
+
+### 修复
+- 修复「用户看到的现象」(#456)
+
+### 升级注意
+- 变更点 → 影响谁 → 迁移步骤（附示例代码或对照表链接）
+
+### 已知问题
+- ……；临时绕过：……
+```
+
+## 五、反例对照
+- 反例：「优化了底层性能。」→ 正例：「任务列表在 1 万条数据时加载时间从约 4 秒降到约 1 秒。」
+- 反例：「修复若干问题。」→ 正例：「修复搜索结果偶发重复显示；修复深色模式下按钮文字不可读。」
+- 反例：「接口升级，请注意适配。」→ 正例：按三要素写全（什么坏 / 影响谁 / 怎么办）。
+- 反例：「重构核心模块。」→ 用户视角无行为变化的重构不进用户公告，放开发者 changelog。

package/app/core/skillpacks/market/weekly-report.md

@@ -1,71 +1,71 @@
----
-name: 周报晨报生成器守则
-note: 从任务与运行记录生成汇报：先取材再总结 / 晨报三段 / 周报四段 / 量化纪律与模板
-scopes:
-- "*"
-source: market
-market_id: weekly-report
----
-
-# 周报 / 晨报生成器守则（市场包）
-
-适用：为个人或团队生成晨报（昨日 / 今日 / 阻塞）与周报（本周 / 风险 / 下周）。
-第一原则：**先取材，再总结，不许凭印象编**。事实原料来自任务系统、运行记录、
-提交历史与日志；生成器的工作是把原料提炼成「能支撑决策」的信息，不是文学创作。
-
-## 一、取材清单（动笔前先收集）
-- 已完成：本周关闭的任务、成功结束的运行、合并的提交 / PR（git log --since 起止）。
-- 进行中：各任务当前状态、最近一次运行结论、卡在哪一步。
-- 信号类：评审打分、测试通过率、失败与重试次数、耗时的环比变化——量化的来源。
-- 未进系统的口头承诺 / 临时插活：单独列出并标注「口头事项」，不混进正式条目。
-
-## 二、晨报结构（10 行以内，站着读完）
-- **昨日完成**：2-4 条，每条写一个**结果**（不是动作）。
-- **今日计划**：2-4 条，每条可验证（「提测搜索分页」，而不是「继续做搜索」）。
-- **阻塞**：0-2 条，每条带「需要谁 / 需要什么」；没有就写「无」，不硬凑。
-
-## 三、周报结构
-1. **本周一句话**：本周最重要的结果或结论。上级只读这一行也能掌握大局。
-2. **关键进展**：按目标 / 项目分组，每组 1-3 条；每条 = 结果 + 量化 + 对照计划
-   （提前 / 按期 / 延期几天）。流水账禁止——「周一做了 A，周二做了 B」是日志，
-   不是汇报。
-3. **风险与阻塞**：每条 = 风险描述 + 影响面 + 需要的支持或缓解方案。
-   **只报风险不给方案 = 把问题原样上交；报喜不报忧 = 把雷埋到下周。**
-4. **下周计划**：2-5 条可验证的目标，与风险呼应，高风险项排前面。
-
-## 四、写作纪律
-- **量化**：能带数字必带数字（章数、字数、通过率、耗时、条数）；
-  「大量」「明显」「基本完成」这类模糊词出现即重写。
-- **结果导向**：写「完成了 X，达到 Y」；「在做 X」「推进中」放进计划或阻塞，不进步进展。
-- **动词开头、一条一意**：每条脱离上下文独立可懂。
-- **诚实纪律**：延期就写延期，附原因与新预计时间；数据缺失标注「缺」，不估算充数。
-- **篇幅纪律**：周报正文 ≤400 字（附录与链接不计）；超了说明没提炼。
-
-## 五、常见毛病对照（反例 → 正例）
-- 反例：「本周推进了 A 项目。」→ 正例：「A 项目完成搜索分页改造并提测，1 万条数据下翻页响应小于 200ms。」
-- 反例：「一切顺利。」→ 正例：「整体按期；联调依赖的 B 接口周三可用，已与对方确认。」
-- 反例：「风险：时间紧。」→ 正例：「风险：评审通过率低于阈值会触发返工，预计延期 2 天；已加排一轮预审。」
-- 反例：把 12 条流水账逐日列出 → 正例：归并成 3 条按目标分组的结果，逐日明细放附录链接。
-
-## 六、周报模板（可直接复制）
-```
-# 周报（MM.DD - MM.DD）
-
-一句话：完成xxx，指标y环比+z%；主要风险：xxx。
-
-## 关键进展
-- 【目标A】交付xxx（量化数据）；对照计划：按期 / 延期n天
-- 【目标B】……
-
-## 风险与阻塞
-- 风险：……；影响：……；需要：……（或已采取措施：……）
-
-## 下周计划
-- ……
-```
-
-## 七、自检
-- [ ] 每个数字都能在任务 / 运行记录 / git log 里找到出处
-- [ ] 无「继续推进」「持续优化」这类无信息量条目
-- [ ] 风险条目全部带缓解方案或明确的求助对象
-- [ ] 下周计划每条都有可验证的完成标志
+---
+name: 周报晨报生成器守则
+note: 从任务与运行记录生成汇报：先取材再总结 / 晨报三段 / 周报四段 / 量化纪律与模板
+scopes:
+- "*"
+source: market
+market_id: weekly-report
+---
+
+# 周报 / 晨报生成器守则（市场包）
+
+适用：为个人或团队生成晨报（昨日 / 今日 / 阻塞）与周报（本周 / 风险 / 下周）。
+第一原则：**先取材，再总结，不许凭印象编**。事实原料来自任务系统、运行记录、
+提交历史与日志；生成器的工作是把原料提炼成「能支撑决策」的信息，不是文学创作。
+
+## 一、取材清单（动笔前先收集）
+- 已完成：本周关闭的任务、成功结束的运行、合并的提交 / PR（git log --since 起止）。
+- 进行中：各任务当前状态、最近一次运行结论、卡在哪一步。
+- 信号类：评审打分、测试通过率、失败与重试次数、耗时的环比变化——量化的来源。
+- 未进系统的口头承诺 / 临时插活：单独列出并标注「口头事项」，不混进正式条目。
+
+## 二、晨报结构（10 行以内，站着读完）
+- **昨日完成**：2-4 条，每条写一个**结果**（不是动作）。
+- **今日计划**：2-4 条，每条可验证（「提测搜索分页」，而不是「继续做搜索」）。
+- **阻塞**：0-2 条，每条带「需要谁 / 需要什么」；没有就写「无」，不硬凑。
+
+## 三、周报结构
+1. **本周一句话**：本周最重要的结果或结论。上级只读这一行也能掌握大局。
+2. **关键进展**：按目标 / 项目分组，每组 1-3 条；每条 = 结果 + 量化 + 对照计划
+   （提前 / 按期 / 延期几天）。流水账禁止——「周一做了 A，周二做了 B」是日志，
+   不是汇报。
+3. **风险与阻塞**：每条 = 风险描述 + 影响面 + 需要的支持或缓解方案。
+   **只报风险不给方案 = 把问题原样上交；报喜不报忧 = 把雷埋到下周。**
+4. **下周计划**：2-5 条可验证的目标，与风险呼应，高风险项排前面。
+
+## 四、写作纪律
+- **量化**：能带数字必带数字（章数、字数、通过率、耗时、条数）；
+  「大量」「明显」「基本完成」这类模糊词出现即重写。
+- **结果导向**：写「完成了 X，达到 Y」；「在做 X」「推进中」放进计划或阻塞，不进步进展。
+- **动词开头、一条一意**：每条脱离上下文独立可懂。
+- **诚实纪律**：延期就写延期，附原因与新预计时间；数据缺失标注「缺」，不估算充数。
+- **篇幅纪律**：周报正文 ≤400 字（附录与链接不计）；超了说明没提炼。
+
+## 五、常见毛病对照（反例 → 正例）
+- 反例：「本周推进了 A 项目。」→ 正例：「A 项目完成搜索分页改造并提测，1 万条数据下翻页响应小于 200ms。」
+- 反例：「一切顺利。」→ 正例：「整体按期；联调依赖的 B 接口周三可用，已与对方确认。」
+- 反例：「风险：时间紧。」→ 正例：「风险：评审通过率低于阈值会触发返工，预计延期 2 天；已加排一轮预审。」
+- 反例：把 12 条流水账逐日列出 → 正例：归并成 3 条按目标分组的结果，逐日明细放附录链接。
+
+## 六、周报模板（可直接复制）
+```
+# 周报（MM.DD - MM.DD）
+
+一句话：完成xxx，指标y环比+z%；主要风险：xxx。
+
+## 关键进展
+- 【目标A】交付xxx（量化数据）；对照计划：按期 / 延期n天
+- 【目标B】……
+
+## 风险与阻塞
+- 风险：……；影响：……；需要：……（或已采取措施：……）
+
+## 下周计划
+- ……
+```
+
+## 七、自检
+- [ ] 每个数字都能在任务 / 运行记录 / git log 里找到出处
+- [ ] 无「继续推进」「持续优化」这类无信息量条目
+- [ ] 风险条目全部带缓解方案或明确的求助对象
+- [ ] 下周计划每条都有可验证的完成标志

package/app/core/skillpacks/market/worldview-consistency.md

@@ -1,70 +1,70 @@
----
-name: 世界观设定一致性台账守则
-note: 设定台账五件套 / 设定变更三步流程 / 高频吃书场景 / 章前查章后记闭环
-scopes:
-- novel
-- serial_novel
-source: market
-market_id: worldview-consistency
----
-
-# 世界观设定一致性台账守则（市场包）
-
-适用：连载与长篇的设定管理。吃书（前后矛盾）是长篇差评第一来源，且几乎全部
-源于**「没有台账」而不是「记性差」**——几十万字跨度下，任何人都记不住自己写过的
-每个数字与专名。本包给出一套零工具依赖的台账纪律。
-
-## 一、台账五件套（开书第一天建立，一个文件即可）
-1. **规则体系**：力量 / 能力等级、代价与限制、禁忌（什么绝对做不到）。
-   **限制比能力更重要**——能赢只是爽，不能做什么才产生剧情。
-2. **地理与组织**：地名 / 势力名清单（含从属关系）。一地一名，写法逐字固定
-   （定了「云州」就不能又写「云洲」）。
-3. **时间线**：故事内历法 + 大事件年表（含「现在」的锚点日期）；每章推进了
-   多长时间记一笔，跨章对表。
-4. **专有名词表**：自造词、称谓、咒语、物品名，逐字锁定。
-5. **数字台账**：金额、距离、年龄、队伍人数、库存——正文出现过的每个数字。
-   数字是最容易吃书的类别，因为最枯燥、最没人记。
-
-## 二、铁律
-- **设定一经正文确认，不可静默更改。**要改，走三步：登记「改了什么 / 从哪章起
-  生效」→ 排查并修订前文旧描述（或用剧情解释）→ 更新台账。三步缺一不可。
-- 设定揭示分层：世界观全貌不必第一章交底，但**已揭示的部分永不反悔**。
-  未揭示的可以随时丰富——区分「未揭示」与「矛盾」：读者无从知晓的不算吃书。
-- 新设定入正文前先对台账查重：与既有规则冲突吗？冲突就要么改新、要么改旧，
-  不许「先写上再说」。
-- 跨书 / 跨卷沿用设定时，以台账为准重读一遍，不凭上一本的记忆。
-
-## 三、高频吃书场景（评审时重点排查）
-- 时间线对不上：上一段还是「昨天」，三天后又被称作「昨天」；旅程三天的两头
-  都只过了一夜。
-- 能力凭空升级 / 降级：前面明确做不到的事，后面无解释做到了（或反之）。
-- 称谓漂移：同一人物 / 势力的称呼前后不一；称呼随剧情需要临时变化。
-- 死人复活 / 物品复用：已确认死亡的角色、已消耗或损毁的物品再次登场。
-- 年龄与亲缘错位：年龄推算矛盾、辈分关系前后颠倒。
-
-## 四、闭环纪律：章前查、章后记
-- **章前查**：写 / 审每一章前，读一遍本章涉及的台账条目（出场地名、势力、规则、
-  上次时间锚点）。30 秒的事，防 30 万字后的大返工。
-- **章后记**：本章产生的任何新设定、新专名、新数字、时间推进，**当章写入台账，
-  不过夜**。攒三章再补 = 必漏。
-- 一致性评审给出的矛盾项，当轮修复并回填台账；同类矛盾出现第二次 = 台账结构
-  要补一类条目，而不是「下次更小心一点」。
-
-## 五、台账文件模板（可直接复制）
-> ## 规则体系
-> - 等级：……；代价：……；禁忌（绝对做不到的事）：……
-> ## 地理与组织
-> - 云州（州）＞ 落霞城（城）；青岚宗（宗门，驻落霞城）
-> ## 时间线
-> - 第 1 章：启程日（春三月初七）；第 2 章：+3 日 → 三月十一
-> ## 专有名词表
-> - 破妄瞳（术法名，逐字锁定）；称「宗主」不写「掌门」
-> ## 数字台账
-> - 主角 16 岁；启程盘缠 3 两银；落霞城至云州城 700 里
-
-## 六、交稿前自检
-- [ ] 本章新设定已查重并入台账，未与既有规则冲突
-- [ ] 时间推进已记账，与上一章锚点衔接无误
-- [ ] 数字（金额 / 距离 / 人数 / 年龄）与台账一致，新数字已登记
-- [ ] 专名写法与名词表逐字一致
-- [ ] 若改过既有设定：三步流程（登记 / 排查前文 / 更新台账）已走完
+---
+name: 世界观设定一致性台账守则
+note: 设定台账五件套 / 设定变更三步流程 / 高频吃书场景 / 章前查章后记闭环
+scopes:
+- novel
+- serial_novel
+source: market
+market_id: worldview-consistency
+---
+
+# 世界观设定一致性台账守则（市场包）
+
+适用：连载与长篇的设定管理。吃书（前后矛盾）是长篇差评第一来源，且几乎全部
+源于**「没有台账」而不是「记性差」**——几十万字跨度下，任何人都记不住自己写过的
+每个数字与专名。本包给出一套零工具依赖的台账纪律。
+
+## 一、台账五件套（开书第一天建立，一个文件即可）
+1. **规则体系**：力量 / 能力等级、代价与限制、禁忌（什么绝对做不到）。
+   **限制比能力更重要**——能赢只是爽，不能做什么才产生剧情。
+2. **地理与组织**：地名 / 势力名清单（含从属关系）。一地一名，写法逐字固定
+   （定了「云州」就不能又写「云洲」）。
+3. **时间线**：故事内历法 + 大事件年表（含「现在」的锚点日期）；每章推进了
+   多长时间记一笔，跨章对表。
+4. **专有名词表**：自造词、称谓、咒语、物品名，逐字锁定。
+5. **数字台账**：金额、距离、年龄、队伍人数、库存——正文出现过的每个数字。
+   数字是最容易吃书的类别，因为最枯燥、最没人记。
+
+## 二、铁律
+- **设定一经正文确认，不可静默更改。**要改，走三步：登记「改了什么 / 从哪章起
+  生效」→ 排查并修订前文旧描述（或用剧情解释）→ 更新台账。三步缺一不可。
+- 设定揭示分层：世界观全貌不必第一章交底，但**已揭示的部分永不反悔**。
+  未揭示的可以随时丰富——区分「未揭示」与「矛盾」：读者无从知晓的不算吃书。
+- 新设定入正文前先对台账查重：与既有规则冲突吗？冲突就要么改新、要么改旧，
+  不许「先写上再说」。
+- 跨书 / 跨卷沿用设定时，以台账为准重读一遍，不凭上一本的记忆。
+
+## 三、高频吃书场景（评审时重点排查）
+- 时间线对不上：上一段还是「昨天」，三天后又被称作「昨天」；旅程三天的两头
+  都只过了一夜。
+- 能力凭空升级 / 降级：前面明确做不到的事，后面无解释做到了（或反之）。
+- 称谓漂移：同一人物 / 势力的称呼前后不一；称呼随剧情需要临时变化。
+- 死人复活 / 物品复用：已确认死亡的角色、已消耗或损毁的物品再次登场。
+- 年龄与亲缘错位：年龄推算矛盾、辈分关系前后颠倒。
+
+## 四、闭环纪律：章前查、章后记
+- **章前查**：写 / 审每一章前，读一遍本章涉及的台账条目（出场地名、势力、规则、
+  上次时间锚点）。30 秒的事，防 30 万字后的大返工。
+- **章后记**：本章产生的任何新设定、新专名、新数字、时间推进，**当章写入台账，
+  不过夜**。攒三章再补 = 必漏。
+- 一致性评审给出的矛盾项，当轮修复并回填台账；同类矛盾出现第二次 = 台账结构
+  要补一类条目，而不是「下次更小心一点」。
+
+## 五、台账文件模板（可直接复制）
+> ## 规则体系
+> - 等级：……；代价：……；禁忌（绝对做不到的事）：……
+> ## 地理与组织
+> - 云州（州）＞ 落霞城（城）；青岚宗（宗门，驻落霞城）
+> ## 时间线
+> - 第 1 章：启程日（春三月初七）；第 2 章：+3 日 → 三月十一
+> ## 专有名词表
+> - 破妄瞳（术法名，逐字锁定）；称「宗主」不写「掌门」
+> ## 数字台账
+> - 主角 16 岁；启程盘缠 3 两银；落霞城至云州城 700 里
+
+## 六、交稿前自检
+- [ ] 本章新设定已查重并入台账，未与既有规则冲突
+- [ ] 时间推进已记账，与上一章锚点衔接无误
+- [ ] 数字（金额 / 距离 / 人数 / 年龄）与台账一致，新数字已登记
+- [ ] 专名写法与名词表逐字一致
+- [ ] 若改过既有设定：三步流程（登记 / 排查前文 / 更新台账）已走完

package/app/core/skillpacks/qimao-signing.md

@@ -1,61 +1,69 @@
 # 七猫签约标准与写作规范（内置经验包）
 
-来源：七猫作家交流区专栏《拒稿到签约：过稿经验分享》（26 篇，含女频编辑满星官方拒稿模板拆解）
-+ 签约作者（玄弈、竹简听雪、安澜瀧王、苝薇等）方法论。完整原文见
+来源：七猫作家交流区专栏《拒稿到签约：过稿经验分享》（26 篇，含女频编辑满星官方拒稿模板拆解及作者方法论）；
+可复查入口：[bbs.qimao.com/column/6859f2539995c](https://bbs.qimao.com/column/6859f2539995c)（经验帖，不等同当前政策）。
+签约作者（玄弈、竹简听雪、安澜瀧王、苝薇等）方法论。完整原文见
 `C:\Users\HP\.zcode\skills\qimao-signing-guide\SKILL.md`（含《不周山守村人》两次拒稿复盘）。
 
 > 这是写作参考与自检清单，不是平台官方规则或过签预测；按当前频道与后台要求核实。
 
-## 〇、平台底层逻辑（先懂平台再动笔）
-- 七猫 = **免费阅读**平台：收入靠广告分成 + 保底，读者要"即时爽"，不是付费站的"大悬念勾追读"。
-- 调性叫**"无线风"**：节奏比起点快、情绪比新媒体文稳、全程围绕爽。错配文扫开头 300 字就被 pass。
-- 主收题材——女频：总裁、宅斗、种田、年代、玄幻；男频：都市、玄幻、历史、系统文。
-- 核心公式：**网文本质是提供情绪价值（爽/虐/共情），以期待感为导向**。过稿 = 抓住主流读者情绪，
-  让读者代入、爽、乃至共情。
-- 工作观："你不是在写一本书，而是在经营一个产品。""方向>努力，结构>文笔，情绪>逻辑。"
-
-## 一、黄金一章（一章定生死）
-老编辑看第一章就能定过不过——**黄金三章已进化为黄金一章**：一章内展现以前三章的信息量。
-- **前 100 字**：主角登场，读者知道故事围绕谁。
-- **前 200 字**：已出现值得关心的异常、欲望或冲突。
-- **前 600 字**：眼前困境具体（退婚/背叛/陷害/侮辱/破产/误会/灾难/生死危机），不再铺垫。
-- **前 2000 字**：核心吸引点已实际展示（字数位置本身不证明吸引力）。
-- **第三章前**：主线明确（主角要干什么，像"鸣人要当火影"一样清楚）。
-- 第一章具名人物尽量少（五人可作阅读负担参考）；前三章要有实质局面变化；
+## 证据等级与使用边界（2026-09-30 更新）
+
+- **A级：当前平台事实**：只接受作家助手/合同/官方公告中当前可见的规则；投稿、独家、更新和内容红线必须回到原页面核对，历史材料不能代替政策。
+- **B级：多篇经验或明确拒稿原文**：可作为质量诊断假设，必须同时指出正文位置、读者/编辑反馈和可验证的下一步实验；不能写成“满足即过签”。
+- **C级：单个作者口诀或未给证据的数字**：只保留为待验证问题，不注入硬门禁，不据此推断签约率、推荐权重或收入。
+- 报告按“稿件质量 → 平台适配 → 当前政策”分层。每条结论都写清证据范围、未知项和风险；确定性字数/格式检查只能提示复查，不能替代文学判断。
+
+### 跨平台质量底线
+
+先检查首个故事单元是否有**具体事件、主角主动选择、可见后果、阶段性兑现和新的可追问问题**，再看爽点密度。人物动机、因果连续性、前后设定、文风锚、手机阅读段落和内容安全是独立维度；任何一项未读、未测或仅凭摘要得出，都标为“未证实”。
+
+## 〇、平台定位（经验假设，先核对当前频道）
+- 七猫的免费阅读、广告/保底和即时反馈，是选题与节奏的**定位假设**；不同频道、时期和合同可能不同，不能从定位直接推出收入或签约结果。
+- “无线风”、热门题材带和“开头很快给到情绪价值”来自历史经验帖，适合拿来设计对照实验；榜单与后台数据优先于口诀。
+- 核心问题不是套公式，而是：读者是否迅速知道主角、处境、目标和下一步；本章的承诺是否在正文兑现。
+- 工作观可保留为复盘提示：“方向、结构、情绪”分别写成可验证的事件、选择、后果，不把口号当质量结论。
+
+## 一、黄金一章（历史经验观察点，不是“一章定生死”）
+资料建议把第一章作为高信息密度取样点；以下位置是阅读负担观察参考，不代表编辑统一标准。逐项记录证据，未满足不等于质量不合格。
+- **前 100 字**：观察主角何时登场，读者是否知道故事围绕谁展开。
+- **前 200 字**：观察是否已有值得关心的异常、欲望或冲突。
+- **前 600 字**：观察眼前困境是否具体（退婚/背叛/陷害/侮辱/破产/误会/灾难/生死危机），而非只铺垫。
+- **前 2000 字**：观察核心吸引点是否实际展示（字数位置本身不证明吸引力）。
+- **第三章前**：观察主线是否明确（主角要干什么，像“鸣人要当火影”一样清楚）。
+- 第一章具名人物尽量少（五人只是阅读负担参考，不是硬门槛）；前三章要有实质局面变化；
   反转必须由前文条件引发，不为口诀机械加死亡/背叛。
-- 标准开篇节奏：**第一章立冲突+结尾小钩子 → 第二章亮金手指+明确短期目标 → 第三章第一次爽点/打脸**。
-- 三幕式开头：开端（置于巨大危机）→ 发展（金钥匙出现，开始反杀）→ 反转（幕后推手/新一轮追杀/新功能/好友捅刀）。
-- **开篇禁忌**：不堆设定、不铺世界观、不大段环境描写、不集中抛人物关系；不写无用剧情；
-  不玩倒叙花样；配角戏份不得压过主角。
-- 用对话开场最有效（悬念式/劲爆式/仇恨式）；行文"短平快"，写小说不是说明文。
+- 可复用的一种开篇节奏：**第一章建立冲突并留后续问题 → 第二章让核心能力/设定影响行动 → 第三章完成第一次阶段性兑现**；具体次序服务于本稿题材与因果。
+- 三幕式可以作为结构草图：开端（危机/目标）→发展（行动/代价）→转折（新信息/选择），不要求每稿套“金手指/背叛”等桥段。
+- 历史经验帖常提醒检查设定、世界观、环境和人物关系是否挤占事件；倒叙、群像或配角戏份本身不是禁写项，重点是读者能否跟住主线。
+- 部分经验帖推荐用对话开场（悬念式/劲爆式/仇恨式）；可检查开场是否尽快进入人物行动，不能据此规定所有题材都用对话。
 
 ## 二、爽点、期待感与钩子
-- **每章至少 1 个爽点或情绪爆点**，过渡章也要有小冲突小爽点；**三章一小爆，十章一大爆**。
-- 爽点要及时：忌主角第一章 1 级第十章还是 1 级。最简公式：**定个目标 → 完成它**。
-- 爽点 = 欲扬先抑：**"不是主角因为要被欺负而被欺负，而是主角为了爆发而被欺负。"**
-  打压必须有明确动机；打脸爽不爽取决于**反派心理变化**的描写。
-- **期待感三源**（掌握一种就够用）：① 信息差（读者知道、主角/对手不知道）；
+- 建议复查每章是否有可感知的变化、情绪或兑现；“三章一小爆，十章一大爆”是作者口诀，不能替代逐章判断。
+- 部分作者强调及时兑现：可检查目标是否持续推进、阶段结果是否可见，不以等级或固定章节位置判断有效性；"定个目标 → 完成它"可作构思起点。
+- 欲扬先抑是可选结构：打压应有情境动机，反击应有铺垫；反派心理变化可作为效果观察点，不要求每个故事都用打脸。
+- **三类期待构造方式**（构思工具，不是充分条件）：① 信息差（读者知道、主角/对手不知道）；
   ② 目标预告（"三年之约"式，读者等着看那一幕）；③ 悬念伏笔（小伏笔=断章钩子；大伏笔有伏必应）。
-- **每章结尾必留钩子**：断章、说话说一半、章尾挖坑、反转预告。免费站**章尾小爽点比大悬念更管用**。
-- 前期不断挖坑：神秘人暗中观察、有人准备下套、看似好人实则利用。
+- 建议复查章末是否留下可兑现的下一步问题：断章、说话说一半、挖坑或反转预告均可；“章尾小爽点更管用”只是部分作者经验，需结合读者反馈验证。
+- 伏笔不以数量取胜：记录前文铺设、当前承诺和后续回收；神秘人、陷阱或关系反转只有在符合因果并服务本稿时才加入。
 
 ## 三、主线与节奏
 - 一句话主线 + 主角目标细化；目标不细化 = 过程流水账。
-- **与当前重点无关的一律不写**；每章自问："这章结束，剧情有没有往前挪一步？"没有就删改。
-- 书的循环本质："起承转合无限循环，一波未平一波又起，**主角永远处于麻烦之中**。"
-- 小剧情单元：目标→行动→阻碍→反转；大剧情链：起因→发展→转折→高潮→结局。
+- 复查段落是否推动目标、关系、信息或情绪；若没有可辨认的作用，再考虑删改。休整章节也应有清楚的阅读功能。
+- 一种连载经验强调持续制造新局面；可用"起因→行动→阻碍→转折→结果"检查因果，但不要求主角永远处于危机。
+- 小剧情单元可用目标→行动→阻碍→结果检查；大剧情链可用起因→发展→转折→高潮→结局规划。
 - 同一件事不重复叙述；背景设定拆散夹在剧情里带出。
 - 分清剧情流/感情流，笔墨按类型分配。
 
-## 四、人物（红线）
-- **主角主观能动性是红线**：必须主动触发、推动剧情；全程被推着走 = 拒稿级致命伤。
-- 男频毒点：优柔寡断、不杀伐；不能当舔狗（舔必须有原因有好处且写出暗爽）。
-- **反派要有心机有手段，不能无脑**；配角要有动机。
+## 四、人物（经验复查维度）
+- 多篇拒稿复盘关注主角是否作出选择并推动事件；检查“目标 → 行动 → 后果”，但不把单一人物类型写成通用过稿红线。
+- 部分男频经验偏好果断与强反馈；是否适用取决于题材/人设，避免把复杂人物统一改成“杀伐果断”模板。
+- 对手和配角应有可理解的动机与行动；他们不必都强势或聪明，关键是冲突因果成立。
 - 人设四要素：基础设定、个性化标签（口头禅/小习惯）、反差萌、人物弧光。
 - **人设不崩是底线**；人设变化需要铺垫。
 
 ## 五、视角与文笔
-- **故事必须从主角视角展开**；上帝视角 = 读者找不到重点。
+- 开篇视角应让读者容易定位人物、信息来源和情绪距离；第三人称全知等视角不是禁项，需看执行是否清楚。
   例：×"昏暗的房间里，一个男人把南笙按在沙发上" → √"好痒……南笙迷迷糊糊苏醒，感觉腿上一阵瘙痒，
   随后一只粗糙的大手便摸上了她的大腿"。
 - 开篇即入主角视角，不用旁白自我介绍；读者未对主角产生好感前，不铺大篇幅受伤/惨状。
@@ -64,7 +72,7 @@
 - 段落短，适配手机阅读；少错别字病句。
 
 ### 编辑高频驳回话术拆解（实测复盘，动笔/改稿时逐条对照）
-以下三条是免费站签约评估最常见的"文笔类"驳回理由，本质都指向可自查的问题：
+以下三条是所汇编材料中反复出现的"文笔类"反馈，可转成自查问题；不代表所有频道或拒稿的完整原因：
 
 - **"风格不够统一"**：叙述语域/句式长短/人称距离在一章内忽高忽低（半文半白 + 网络梗 + 书面长句混用），
   或切场景/切视角时文风跟着变。**修法**：全篇定一个文风锚（如"短句 + 白描 + 口语但不过火"），
@@ -75,7 +83,7 @@
 - **"细节刻画力度稍弱"**：核心冲突/情绪爆点被一句话带过（该"放慢给特写"的地方按了快进），
   打压—反击缺生理与环境反应，爽点"打不满"。**修法**：每个爽点/反转标记为"特写镜头"，
   用五感 + 微动作 + 环境反馈把这几秒写"厚"（心跳、指节、周围人的呼吸与目光），
-  铺垫在前、放大在中、余波在后；过渡章才可一笔带过。**三章一小爆的"小爆"必须配特写，否则等于没爆。**
+  铺垫在前、放大在中、余波在后；场景篇幅按叙事重要性调整，不把"特写"固定套给每个爽点。
 
 ## 六、题材、书名、简介
 - 题材 = 个人兴趣 × 市场需求的最大公约数；风格要匹配题材。
@@ -83,23 +91,26 @@
 - 书名带情绪、有看点、有关键词；忌文艺含蓄无信息量。
 - 简介三要素：背景（身份+处境）+ 冲突（核心矛盾+情绪爆发）+ 悬念（埋钩子）。
 
-## 七、投稿与签约（流程约束）
-- 直发（推荐新人）：**满 2 万字申请签约评估**，满 3 万字可发布上架；3-5 个工作日出结果。
-- 一稿一投，不海投；超 7 天未果主动跟进一次；三个编辑都拒 = 写新稿。
-- 签约模式：纯分成 / 保底+超保底分成 / 超级纯分成。
-- 红线：涉政涉军涉敏低俗、抄袭洗稿、双男主双女主、非独家（外站内容必须全部下架）。
-
-## 八、签约自检清单（写完逐项过）
-**开篇（第一章）**
-- [ ] 前 100 字主角登场　[ ] 前 200 字出现冲突　[ ] 前 600 字冲突明确
-- [ ] 前 2000 字有大悬念或核心矛盾　[ ] 第一章具名人物 ≤ 5
-- [ ] 无世界观/环境/背景堆砌　[ ] 主角视角、无上帝视角旁白
-- [ ] 开场用冲突/悬念/对话　[ ] 章末有钩子
-**前三章**
-- [ ] 第二章亮金手指 + 短期目标明确　[ ] 第三章完成第一次打脸/爽点
-- [ ] 三章内有反转　[ ] 主线清晰（目标/障碍/要做什么）　[ ] 每章至少 1 个爽点
+## 七、投稿与签约（历史流程，提交前必须回后台核实）
+- 经验材料常见“2 万字/3 万字/3-5 个工作日”等节点，只能作为项目排期提示；当前频道的字数、审核时长和可投稿状态以作家助手页面为准。
+- 一稿一投、跟进节奏和签约模式是作者经验，不是过签条件；拒稿后保留原文、版本、编辑原话和修改范围，再决定重修、重立项或换稿。
+- 红线需按当前公告、合同和频道规则核对：涉政涉军涉敏低俗、抄袭洗稿、版权/独家义务等不能靠内部自检替代平台判断。
+
+## 八、投稿前质量与证据清单（逐项过；非签约保证）
+先给每个结论标注“当前规则 / 多源经验 / 待验证”，并记录实际读过的章节范围；没有证据的项目不标“通过”。
+
+**开篇（第一章；字数位置仅作观察点）**
+- [ ] 观察主角是否尽早登场、读者能否辨认主角　[ ] 观察异常/欲望/冲突何时出现
+- [ ] 观察困境是否具体、核心吸引点是否兑现　[ ] 复查具名人物是否过密（“五人”仅为阅读负担参考）
+- [ ] 复查设定/环境/背景是否挤占事件　[ ] 主角视角是否清楚、旁白距离是否符合本稿选择
+- [ ] 开场与题材承诺是否匹配　[ ] 章末是否有可兑现的后续问题
+**前三章（随题材调整，不强制套章纲）**
+- [ ] 核心设定或能力是否改变人物行动　[ ] 是否完成一个有因果的阶段性兑现
+- [ ] 是否有局面变化　[ ] 主线目标/障碍/下一步是否可复述
 **全书通用**
-- [ ] 主角主动推动剧情　[ ] 本章剧情比上章往前挪一步
-- [ ] 打压有动机、反击有铺垫　[ ] 反派有脑子有心理变化
-- [ ] 人设未崩、主角果断　[ ] 无重复叙述、无与主线无关描写
-- [ ] 细节用动作/神态替代直白情绪词　[ ] 段落短，适配手机阅读
+- [ ] 主角是否作出改变局面的选择　[ ] 本章事件是否推进目标或关系
+- [ ] 打压/阻碍有动机、反击/解决有铺垫　[ ] 对手与配角有各自目标
+- [ ] 人物变化有铺垫　[ ] 重复信息和与主线无关内容是否影响阅读
+- [ ] 情绪表达是否具体且适合本稿文风　[ ] 段落长度是否适配目标阅读场景
+- [ ] 每个故事单元都能指出事件、选择、后果、兑现和后续问题
+- [ ] 文风锚、因果链、连续性和内容安全分别复核，未把字数/格式当文学评分