# 场景剧本行文规则（去 AI 味） 内部参考，不作为 catalog 入口。编写、审阅、修复场景剧本正文时以本文件为统一的行文约束。 ## 密度原则 单独出现不算问题，短段落内反复堆叠、脱离具体内容、空转才是问题。按出现次数机械 替换会把正常表达误改成翻译腔。风格类发现必须附密度判断。 ## 规则 - 删空洞词：显著、有效、充分、极大、赋能、抓手、全方位、无缝、落地（滥用时）。 - 不用"首先/其次/再次/最后"排队；不用"不仅…而且…"凑对仗；禁三连排比和四字短语堆砌。 - 句子长短交错、多用短句；具体名词+具体动词；数字只在真实时写。 - 禁"总而言之/综上所述/值得注意的是/换句话说"；破折号不当万能连接词；不喊口号、 不拟人煽情。 ## 词汇可懂性纪律 根因说明：术语表中文名 ≠ 用户语言。项目术语表服务的是"机器标识 ↔ 中文名"的对齐 一致性，其中的中文名（以及设计文档、ADR 里的工程师词汇）不得未经翻译直接进入 场景正文。 - 用户视角测试：场景正文每句话必须能回答"用户看到什么、做到什么"。系统内部动作 动词（物化、收束、密封、栅栏、编排、物化最终裁决这类）不得直接用于用户视角叙述； 要么改写成可观察事实（"系统给出最终结论""任务如实停住"），要么首次出现时跟一句 大白话解释。 - 术语双轨制：项目术语表是"机器标识 ↔ 中文名"的对照表，服务文档一致性，不是用户 语言的免解释通行证。业务/机器术语在场景中首次出现，用一句独立的话给出大白话定义 （示例："项目委托包是把口头要求写成的正式委托单，后续验收以它为准"），不用 "概念（大白话解释）"式括注；读者已懂的词连定义都不用写；之后可沿用中文名，机器 标识放反引号。 - slug 最小露面：技能名、命令这类 slug 只在字段块（入口编号）出现，正文用"入口技能" "该命令"指代。 - 评审检查法：评审者对每个生造词/内部黑话做"外行三问"——是什么、谁在做、我看到 什么；答不上来的词判发现。 ## 写作惯性约束（BDD 正文） 以下八条针对 Given/When/Then 正文的写作惯性，与"规则"节同级执行；违反即判发现 （`SS-F-017`），finding 的 `message` 须含问题句字面引用。 - 视角锁定：全篇单一称呼，不在"用户/你"之间切换。 - 语体一致：既然用了 Given/When/Then 框架，全篇保持书面简洁体，不插口语；判断 标准——一句话放进微信聊天不违和，就不该出现在 BDD 用例里。 - 不做括号翻译：禁止"术语A（术语A的大白话解释）"写法；概念首次出现时用一句独立的 话定义，读者已懂的词连定义都不用写。机器标识、枚举值首次出现给中文名的写法保留， 例如"无变更接受（`NOOP_ACCEPTED`）"——这是术语表纪律，不算括号翻译。 - 一句一事：不在一句内用顿号、逗号并列三个及以上同级概念，改用列表。 - 信任读者推理：不写正反各说一遍的双保险，不写"这属于XX阶段"式的元分类。 - Then 写正向状态：最多用一条否定句划边界，禁止连续两条"没有发生XX"。 - 不提前道歉、不预防性解释：禁用"需要注意的是""值得一提"这类插入语（"规则"节已禁 "值得注意的是""换句话说"，本节把预防性解释整体列入）。 - 完稿自检：检查语体、人称各只剩一个值。 ## 结构化场景约束 - Given 写可构造的状态：路径、记录、配置、环境条件，不写"系统运行正常"这类空话。 - When 写具体动作：命令、点击、输入，步骤编号，每步一个动作。 - Then 写可观察的事实：输出文本、退出码、状态、记录。每条都能被检查真伪， 不写口号，不写"用户体验良好""流程顺畅"这类不可验证表述。 - 不写设计理由、不写宣传、不写观点。 - 不写本机绝对路径：路径用项目相对形式或占位符（如 ``）， 不出现机器私有路径，改用项目相对路径或占位符。 - 机标识（文件名、命令、枚举值）保持英文原样并放反引号；术语表之外的概念用日常 说法，不生造术语。 ## 交付前快速检查 - 有没有空洞词或口号？删。 - 有没有排队连接词或对仗凑句？改成正常叙述。 - 每句的名词和动词是否具体？数字是否真实？ - Then 的每条结果是否能被检查真伪？不能就改写成可观察事实。 - 语体、人称是否各只剩一个值？Then 是否写正向状态（否定句至多一条划边界）？