story-prose-style:项目专属网文文风系统
建立可执行、可复核、不会把所有书写成同一种腔调的项目文风。文风服务人物、情绪和剧情,不用漂亮句子掩盖逻辑或推进不足。
选择工作模式
- 建立文风:从用户要求、已有正文和对标样本提取规则,创建项目文风文件。
- 应用文风:在写新章或重写前加载项目文风,给正文生成提供明确约束。
- 文风校准:比较目标章节与稳定样本,定位角色声纹、句式、段落、叙述和节奏漂移。
- 维护指纹:正文形成稳定样本后,更新描述性指标,不把偶然章节当成全书新标准。
- 局部回炉:只修用户指定的文风问题;未要求改稿时只报告,不改文件。
确定项目与优先级
先解析用户点名的文本,再判断是否属于当前 story 项目。独立稿件不自动绑定当前活跃书。
项目内按以下优先级执行:
- 用户本轮明确要求。
设定/文风.md或项目等价文件中的硬约束。设定/正文文风指纹.md中的稳定描述和样章锚点。- 当前正文章节、角色档案和对标文风。
- 本 skill 的
references/prose-principles.md通用原则。
冲突时写明采用哪一级,不把低优先级的通用建议覆盖项目规则。长篇需要时读取 追踪/上下文.md和对应细纲,但不手改派生追踪文件。
与 story skills 配合
本机 $story 个人扩展路由的恢复规则见 references/story-router-integration.md。
story:负责识别写长篇、写短篇、审查、去AI味等意图;文风类请求路由到本 skill。story-long-write/story-short-write:负责剧情、大纲、正文和连续性;写正文前加载本 skill 维护的文风文件,写后执行文风校准。story-review:负责结构、人物、逻辑和一致性;本 skill 只聚焦文风契约与正文声音。story-deslop:负责清除AI痕迹;先保证人物、因果和信息不丢,再去味,去味后重新检查文风漂移。story-fanqie-compliance:负责番茄平台发布门禁;文风校准通过后再做平台合规和反水文检查。
用户只要求文风审查时,不自动续写、不改大纲、不推进追踪。文风改写改变事实、伏笔或人物状态时,交回相应写作 skill 提交 revision 事务。
建立项目文风
读取 references/style-artifacts.md,按下列顺序执行:
- 选取稳定样本:优先用户认可或已定稿的 3–10 章,排除草稿、归档、特殊实验章和被否定版本。
- 提取六个维度:叙述声音、对白声音、句段节奏、描写方式、情绪与幽默、禁止漂移。
- 分离通用规则和本书特征:角色口头禅、视角、题材比例、章节长度和特殊标点只进入项目文件。
- 写
设定/文风.md:记录硬约束、读者契约、场景切换规则、角色语言边界和交稿自检。 - 写
设定/正文文风指纹.md:记录样本来源、可量化指标、角色声纹和漂移风险;指标是参考区间,不是机械配额。 - 不覆盖用户已有文风文件;增量修订并说明变化。未获授权时不替换已锁定的项目规则。
应用正文原则
完整原则读取 references/prose-principles.md。默认执行:
- 对白说人话,符合人物身份、关系、目的和中国当代交流习惯;允许打断、改口、半句话和少量功能性废话。
- 叙述使用自然准确的现代汉语;文学性落在物件、环境、感官、动作和因果上,不能停住剧情自我欣赏。
- 剧情推进优先。每个场景至少改变行动、信息、关系、风险或结果之一。
- 爽点必须由压力、选择、行动、现场反应和收益结算形成,不由旁白宣布。
- 搞笑从人物身份、误会和现场处境中长出来;一轮交流通常只留一个有效笑点。
- 删除作者解释、抽象总结、翻译腔、模板微动作、排比答案和无功能景物。
- 章尾落到具体动作、物件、警报、伤口、奖励、选择或新问题,不做预告式升华。
量化文风指纹
对已定稿样本或目标章节运行:
python3 <skill-dir>/scripts/style_fingerprint.py <target-file-or-directory> [more targets]
与稳定样本比较:
python3 <skill-dir>/scripts/style_fingerprint.py --baseline <sample-path> <target-path>
需要机器结果时加 --json。脚本统计句长、段落、对白、标点和高频模板风险,只用于发现偏移,不单独判定文风好坏。目录输入只扫描规范正文,排除归档、追踪、设定和大纲。
写后审查
读取 references/style-review-rubric.md,按顺序检查:
- 事实、人物目的和场景因果是否仍清楚。
- 对白蒙住角色名后是否仍能区分,说话是否自然。
- 叙述是否具体、准确、长短相济,文学性是否服务场景。
- 笑点、恐怖、战斗、感情和调查是否使用对应的节奏,不互相拆台。
- 是否出现AI模板、翻译腔、作者总结、连续微动作和重复解释。
- 章首是否快速建立目标或异常,章尾是否有具体推动力。
- 运行项目已有的 AI 句式、退化和标点脚本;脚本缺失时人工检查,不编造通过记录。
交付
报告写清:检查范围、采用的文风权威文件、稳定样本、核心风格结论、BREAK/DRIFT/TUNE 证据、已修改内容、未修改内容、量化结果和仍需作者确认的边界。
不要以“更文学”“更高级”“更口语”为抽象修改理由。每项建议都要指出它如何改善人物辨识、信息传递、情绪交付、剧情推进或手机阅读体验。