mcpbeat

Ai科幻 ���台签约评估框架

lornshrimp/ai科幻-平台签约评估框架

用于【AI科幻】题材下以默认极严、保守、负面证据优先的口径评估作品在{目标平台}的签约、过稿与连载潜力。作为题材包装层与路由层,负责保留AI科幻标准入口名,并明确要求优先强制加载并使用 `通用-平台签约评估框架`。关键词:AI科幻签约评估、极严评估、签约概率评估、过稿潜力、总纲闸门预评估、分卷闸门预评估、正文准入评估、竞品威胁评估。

7k tokens
context cost
the whole folder, loaded on every use
4
files
instructions only
0
copies elsewhere
how many repositories repackaged it
148
stars on the repo
on the repository, not the skill itself

Install

one command, takes just this skill from the repository
npx skills add https://github.com/lornshrimp/Lorn.NovelWriteSkills --skill AI科幻-平台签约评估框架

The instruction itself

3 sections, as written by the author

<!-- ===== Layer 1: 永久缓存 ===== -->

AI科幻-平台签约评估框架

这是题材包装层、兼容入口与路由层。

<!-- ===== Layer 3: 场景缓存 ===== -->

对应通用 Skill

  • 通用-平台签约评估框架

强制要求

  • 不得绕过 通用-平台签约评估框架 另写一套平行共性规则。
  • 引用通用能力时只按名称引用,不写路径。

本层职责

  • 保留“AI科幻-平台签约评估框架”这一标准入口名。
  • 将签约评估的共性骨架路由到 通用-平台签约评估框架
  • 补充AI科幻题材下的赛道归类、开篇抓力、职业 / 技术 / 程序 / 长线谜团口径,以及{目标平台}下的保守裁判逻辑。
  • 各平台通用的题材基线保留在本文件;平台特定门槛由 通用-平台签约评估框架 的 "目标平台路由与动态引用" 节按目标平台加载对应 references。
  • 继续负责把"AI科幻在{目标平台}为什么能签、为什么暂时不能签"说成具体裁判语言,而不是抽象好坏判断。
  • 在AI科幻语境下,把“总纲 -> 分卷 -> 正文”的阶段闸门改写成题材化裁判:当前是否适合继续往下推进,还是必须先停留修正。

继续读取的题材 references(按目标平台加载)

  • 【起点口径】 目标平台为起点或默认回退时:
  • references/起点AI科幻审核锚点与红线.md
  • references/起点签约概率评估检查清单.md
  • references/起点签约概率评估报告模板.md
  • 其他平台:引用 通用-平台签约评估框架 中对应平台的默认审核流程;本题材层仅补充题材基线。

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

  • 帮我评估这本AI科幻能不能签
  • 起点会不会收这部作品
  • 给我做一个AI科幻签约概率评估
  • 看看黄金三章和长线供血够不够
  • 这是内投级还是只能先预评估

默认落盘要求

  • 主报告默认落盘到:审阅意见/{目标平台}/评估/
  • 同一作品默认维护一份主报告,优先覆盖更新,不随意并列新建
  • 对话中至少回执:本轮读取了哪些核心材料、报告写到哪个路径

完整模板执行要求(强制)

  • 执行本 Skill 时,必须先使用 通用-平台签约评估框架 中的 references/平台签约评估报告模板.md 作为主骨架,【起点口径】 再用 references/起点签约概率评估报告模板.md 补写AI科幻专项章节。
  • 不得只给“能不能签”的简版结论,必须完整覆盖:书名 / 简介归类效率、30 秒 / 3 分钟 / 3 万字快审判断、技术技术针脚、职业 / 数据痕迹/ 系统逻辑链、人物 / 付费价值 / 追读工程、首卷承诺与长线供血、题材专项评分项与题材化结论重点。
  • 若材料里存在人物传记、故事设定、分卷 / 总纲、前 10 章节拍或既有审阅报告,必须交叉核验,不得只看前三章就高判。

强制要求

  • 命中本技能时,必须优先强制加载当前题材 Skill 与 通用-平台签约评估框架
  • 【起点口径】 若按起点口径评估,默认继承 通用-平台签约评估框架TopN 候选池 → 3–5 本主压制样本 → 四层竞对拆解 方法;题材层不再平行维护第二套竞对流程。
  • 【起点口径】 起点评估中的榜单位次、均订 / 首订 / 收订比代理信号、本章说 / 书友圈活跃度、老白读者接受度等术语,默认以通用层定义为准;本题材层只补AI科幻专项裁判。
  • 评估时必须检查“都市技术抓手 + 异常触发 + 技术代价 + 长线谜团”的咬合度。
  • 必须把“都市真实职业 + 执念 / 缺陷 + 主动调查能力”作为主角过线判断的重要锚点。
  • 必须检查前三万字是否具备持续钩子密度与至少一次单元闭环,而不是只看首章炸点。
  • 必须显式判断:书名 / 简介 / 首屏能否在 30 秒内完成平台归类;前三章是否已经给出一次有效回报;首卷是否存在清晰承诺与阶段闭环。
  • 若涉及超自然或民俗资源,必须检查是否完成了“科学对冲玄学”的包装,以及是否踩到封建迷信 / 暴力血腥 / 敏感内容红线。
  • 缺正文时不得假装正式评估失败,而应切到总纲闸门预评估或分卷闸门预评估口径。
  • 概率必须给区间,且默认按低签约率现实保守输出。

题材分阶段准入要求

总纲闸门预评估

  • 必须回答:这条总纲能否稳定读成"{目标平台}AI科幻追读型长篇",而不是纸媒慢悬疑 / 氛围文学稿。
  • 必须回答:都市技术抓手、异常入口、技术代价、长线谜团是否已经形成可拆卷驱动。
  • 必须回答:若继续推进分卷,最可能爆掉的是赛道归类、主角抓手、首卷承诺还是长线供血。

分卷闸门预评估

  • 必须回答:首卷承诺、前 10 章节拍、第一次有效回报是否已经落实到分卷与开篇方案。
  • 必须回答:前三章是否已经预埋职业链、数据链、系统摩擦与章末接棒。
  • 必须回答:如果现在开写正文,最容易逼着作者回改的是总纲、分卷还是正文执行。

正文准入评估

  • 必须回答:正文是否已经把都市职业、异常事件、调查推进、技术代价写到可追读层。
  • 必须回答:当前问题属于总纲级、分卷级还是正文级。
  • 若要求回改上游,必须明确写出是总纲级还是分卷级,不得笼统写“回去改大纲”。

通用层优先边界

  • 材料完整度判断、评分骨架、概率区间、封顶与一票否决规则,以 通用-平台签约评估框架 为准。
  • 【起点口径】起点竞对对照时的 TopN 候选池 → 3–5 本主压制样本 → 四层深拆 方法,以及相关起点术语口径,也以 通用-平台签约评估框架 为准。
  • 默认极严保守口径通用-平台签约评估框架 统一管辖,题材层直接继承;不需要用户额外说"严苛"或"保守",也不需要题材层重复定义。
  • 本文件继续保留的内容,只用于补充AI科幻题材在{目标平台}下的赛道判断、黄金三章、主角抓手、长线供血与低签约率口径。
  • 若本文件与通用层出现表述重复,应以"通用层管评估骨架与严苛口径、题材层管平台适配裁判"的方式理解。

题材补充边界

  • AI科幻包装层继续负责:赛道归类、黄金三章、主角抓手、长线供血、现实低签约率口径下的{目标平台}判断。
  • 不能把本技能误抽成抽象的"平台感受评估";它仍是{目标平台}AI科幻的严格概率评估入口。

默认执行口径

  • 支持 总纲闸门预评估分卷闸门预评估正文准入评估完整评估缺材快筛 五种模式。
  • 若用户明确说“正文还没写 / 先看大纲值不值得写 / 别等写完再评”,默认切到总纲闸门预评估或分卷闸门预评估,而不是强行要求正文。
  • 结论必须落到:建议现在内投|建议先修后内投|建议先直发观察|暂不建议投稿|建议先改纲后开写正文。
  • 若当前仍处总纲或分卷阶段,必须额外落到:允许直接推进下一层|补 1 轮后推进|暂不放行。

题材加权重点

  • 【起点口径】 AI科幻在起点评估时,默认更看:开篇抓力、技术抓手、现实代入、逻辑闭环、长线供血,而不是单纯氛围感或文学气质。其他平台评估时参照对应平台的题材加权口径。
  • 若项目更像豆瓣 / 盐选 / 纸媒慢悬疑,而不是{目标平台}追读型长篇,必须在报告中显眼写出平台错配风险。
  • 若主打“民俗 / 诡异 / 异常”,但没有把它压回都市日常场景、职业链路和科学解释框架,应视为重大降分项。
  • 若已有章节 / 人物 / 设定 / 分卷审阅信号,应把这些信号吸回签约评估,而不是把签约评估做成与审阅链脱节的平行判断。

How to use it

Copy the folder

Take lornshrimp/ai科幻-平台签约评估框架 from the repository into ~/.claude/skills for personal use, or into .claude/skills inside a project.

Check the name does not clash

The agent identifies a skill by the name field in its header. Two skills with the same name cannot sit side by side — one of them will be ignored.