Build latest book artifacts / build (push) Canceled after 0s
dependency resolution / resolve (3.11) (push) Canceled after 0s
dependency resolution / resolve (3.13) (push) Canceled after 0s
deploy-pages / build (push) Canceled after 0s
deploy-pages / deploy (push) Canceled after 0s
i18n consistency check / check (push) Canceled after 0s
provider adoption tests / test (chapter2/context-compression) (push) Canceled after 0s
provider adoption tests / test (chapter2/prompt-injection) (push) Canceled after 0s
provider adoption tests / test (chapter2/system-hint) (push) Canceled after 0s
provider adoption tests / test (chapter3/log-sanitization) (push) Canceled after 0s
web-search-agent tests / test (push) Canceled after 0s
web-search-agent tests / agentbook (push) Canceled after 0s
129 lines
12 KiB
Markdown
129 lines
12 KiB
Markdown
---
|
||
name: ai-style
|
||
description: 中文文案去「AI 味」检查清单,由用户纠正反馈持续提炼而来
|
||
---
|
||
|
||
# 去 AI 味写作 Skill
|
||
|
||
## 何时加载
|
||
|
||
当任务是用中文撰写或改写面向读者的文案(产品发布稿、公众号文章、邮件、README 等),
|
||
或用户反馈文字「AI 味太重」「不像人写的」时,加载本 Skill。
|
||
|
||
## 使用方式
|
||
|
||
起草或改写时逐条对照下面的规则自查。每条规则都给出定义、可检查的检测方法、
|
||
坏例与好例;规则只在声明的作用域内生效,作用域之外的文体不要套用。
|
||
|
||
## 规则清单(共 11 条)
|
||
|
||
### 规则 1:避免用连续破折号代替常规断句(`rule-excessive-em-dash-separators`)
|
||
|
||
- **定义**:当一句或一段中连续使用多个破折号来串联普通并列信息、步骤或分句,导致层次不清、阅读节奏拖长时命中。应改用句号、逗号、冒号或分句。若破折号只偶尔用于插入说明、语意转折或强调,且前后关系明确,则不命中。
|
||
- **检测方法**:LLM judge 语义判定(上线前须通过独立人工金标集校准)
|
||
- **坏例**:关于季度复盘会议——时间定于本周五下午三点——地点在三号会议室——请提前准备数据报表——如有冲突请及时告知——谢谢配合。
|
||
- **好例**:季度复盘定在这周五下午三点,三号会议室。请提前准备好数据报表,时间冲突的话提前跟我说。
|
||
- **改写建议**:先判断各部分是并列信息还是独立句意;并列项用逗号,完整意思用句号,只在确有插入或强调作用时保留破折号。
|
||
- **作用域**:产品发布稿、公众号文章、邮件
|
||
- **来源反馈**:fp-001, fp-008, fp-017
|
||
|
||
### 规则 2:避免反复使用“不是……而是……”对仗(`rule-avoid-repeated-not-but-contrast`)
|
||
|
||
- **定义**:当“不是……而是……”被连续用于定义产品、解释概念或制造升华,尤其连续出现两次以上并形成整齐对仗时命中。这类写法常以否定铺垫代替直接说明。若上下文确实需要纠正一种明确误解,并且只使用一次来表达真实对立,则不命中。
|
||
- **检测方法**:LLM judge 语义判定(上线前须通过独立人工金标集校准)
|
||
- **坏例**:这不是一次简单的版本更新,而是一次体验的全面革新;不是功能的堆砌,而是对用户需求的深度回应。
|
||
- **好例**:这次版本更新改动很大:界面重做,核心流程缩短了两步,都来自上一版用户反馈里最高频的问题。
|
||
- **改写建议**:删去否定式铺垫,直接说明对象是什么、具体改了什么,并用事实或例子支撑判断。
|
||
- **作用域**:README 段落、产品发布稿、公众号文章
|
||
- **来源反馈**:fp-002, fp-009, fp-015
|
||
|
||
### 规则 3:避免连用“让我们”式号召口号(`rule-avoid-repeated-let-us-slogans`)
|
||
|
||
- **定义**:当邮件、README 或产品稿连续以“让我们”开头,使用“共同见证”“携手并进”等口号来代替具体通知、邀请或行动说明时命中。若只出现一次,且确实是在自然地发出明确、可执行的共同邀请,则不命中。
|
||
- **检测方法**:LLM judge 语义判定(上线前须通过独立人工金标集校准)
|
||
- **坏例**:让我们共同见证这个激动人心的时刻!让我们一起开启数字化转型的全新篇章。让我们携手并进,共创辉煌明天。
|
||
- **好例**:新版本今天上线了,期待大家试用之后多提意见。
|
||
- **改写建议**:直接交代发生了什么,以及希望读者采取什么具体行动,如试用、反馈、提 issue 或提交 PR。
|
||
- **作用域**:README 段落、产品发布稿、邮件
|
||
- **来源反馈**:fp-003, fp-010, fp-018
|
||
|
||
### 规则 4:避免机械堆叠顺序连接词(`rule-avoid-mechanical-sequence-markers`)
|
||
|
||
- **定义**:当短段落逐句套用“首先、其次、再次、然后、最后、总而言之”等连接词,实际内容本可自然串联,因而呈现模板化或公文腔时命中。若步骤顺序严格、跳步会造成错误,或连接词确实用于澄清复杂层级,则不命中。
|
||
- **检测方法**:LLM judge 语义判定(上线前须通过独立人工金标集校准)
|
||
- **坏例**:首先,克隆本仓库到本地。其次,安装所需依赖。再次,配置环境变量。然后,运行初始化脚本。最后,启动开发服务器即可。
|
||
- **好例**:克隆仓库后安装依赖,把 .env.example 复制为 .env 并填好密钥,再运行 init.sh 初始化,最后 make dev 启动服务。
|
||
- **改写建议**:删除不提供额外信息的序号套话,改用动作之间的真实关系连接;必要时只保留少量“再”“最后”,或改成清晰的步骤列表。
|
||
- **作用域**:README 段落、产品发布稿、邮件
|
||
- **来源反馈**:fp-004, fp-012, fp-019
|
||
|
||
### 规则 5:删除空泛的“在……时代”开场(`rule-remove-generic-era-openings`)
|
||
|
||
- **定义**:当文章以“在……的今天”“在这个……的时代”等宏大背景开头,但该背景没有提供具体时间、事件或因果信息,只用于烘托气氛时命中。若时代或日期本身是论证所需的关键背景,并有具体事实支撑,则不命中。
|
||
- **检测方法**:LLM judge 语义判定(上线前须通过独立人工金标集校准)
|
||
- **坏例**:在这个快节奏的时代,高效的沟通显得尤为珍贵。在这个充满变化的时代,稳定的协作关系更值得珍惜。
|
||
- **好例**:最近项目节奏快,咱们沟通尽量简短高效;也希望协作关系保持稳定,有问题随时同步。
|
||
- **改写建议**:直接写当前发生的具体变化、影响和要求,用“最近”“这两年”等可核实时间范围替代泛化时代判断。
|
||
- **作用域**:产品发布稿、公众号文章、邮件
|
||
- **来源反馈**:fp-005, fp-010, fp-016
|
||
|
||
### 规则 6:控制 emoji 的使用密度与场合(`rule-control-emoji-density`)
|
||
|
||
- **定义**:当正式产品稿中使用 emoji,或公众号段落中几乎每个信息点都附带表情,造成视觉干扰、削弱专业感时命中。正式稿件应去除 emoji;轻松社交场景中少量、与语义直接相关且不妨碍阅读的 emoji 不应一概判定为问题。
|
||
- **检测方法**:LLM judge 语义判定(上线前须通过独立人工金标集校准)
|
||
- **坏例**:🎉 重磅来袭!🔥 全新智能手表正式发布!⌚ 超长续航 14 天 🔋,心率血氧全天候监测 ❤️,50 米防水 🏊,现在下单立减 200 元 💰,错过再等一年 ⏰!
|
||
- **好例**:新款智能手表发布:续航 14 天,支持心率血氧监测和 50 米防水,首发价立减 200 元。
|
||
- **改写建议**:正式文本删除全部 emoji;其他场景先去掉装饰性表情,只在确有语气或分类作用时保留极少量。
|
||
- **作用域**:产品发布稿、公众号文章
|
||
- **来源反馈**:fp-006, fp-011
|
||
|
||
### 规则 7:避免刻意堆叠同构排比(`rule-avoid-forced-parallelism`)
|
||
|
||
- **定义**:当三句或更多分句反复使用完全相同的开头和句法框架,如“读书可以……”“它让……”“每一次……都是……”,且内容多为抽象赞美、缺少信息增量时命中。若排比用于必要的结构对照、篇幅适度且每项都有实质信息,则不命中。
|
||
- **检测方法**:LLM judge 语义判定(上线前须通过独立人工金标集校准)
|
||
- **坏例**:读书可以拓宽视野,读书可以沉淀心灵,读书可以启迪智慧,读书可以点亮人生。
|
||
- **好例**:读书的好处很多:视野会变宽,心能静下来,看问题也会多几个角度。
|
||
- **改写建议**:保留一个总述,将各项改成不同句式或合并为并列成分;删去重复、空泛或意义相近的项。
|
||
- **作用域**:README 段落、公众号文章
|
||
- **来源反馈**:fp-007, fp-014, fp-017
|
||
|
||
### 规则 8:用具体事实替代空洞抒情比喻(`rule-replace-empty-metaphors-with-facts`)
|
||
|
||
- **定义**:当“智者、屏障、明灯、灯塔”等比喻只负责抬高语气,却没有说明产品效果、处理进度或实际价值,甚至替代了读者需要的关键信息时命中。若比喻准确、简洁,并能帮助理解陌生概念或符合文学性场景,则不命中。
|
||
- **检测方法**:LLM judge 语义判定(上线前须通过独立人工金标集校准)
|
||
- **坏例**:您的建议宛如一盏明灯,照亮了我们产品改进的前路;您的信任仿佛一座灯塔,指引着我们不断前行。
|
||
- **好例**:您提的建议很具体,我们已经记进需求池,下个版本会先改其中两条。谢谢您的信任。
|
||
- **改写建议**:删除装饰性喻体,补上可验证的信息,如实际体验、使用场景、已采取的动作和后续安排。
|
||
- **作用域**:公众号文章、邮件
|
||
- **来源反馈**:fp-013, fp-020
|
||
|
||
### 规则 9:拆分承载过多层次的长句(`rule-split-overloaded-sentences`)
|
||
|
||
- **定义**:当一句话同时塞入背景、原因、条件、多个动作、结果和要求,主要依靠“且、并、同时、为了、让”等连续连接,读者难以一次识别主干时命中。句子较长但主干清楚、修饰关系单一且不存在理解负担时不命中。
|
||
- **检测方法**:LLM judge 语义判定(上线前须通过独立人工金标集校准)
|
||
- **坏例**:这次更新在保留原有工作台布局的基础上通过重新组织导航层级并合并重复入口同时优化首次加载和列表刷新策略让用户从打开应用到完成一次记录的整个过程都比以前更连贯也更省时间。
|
||
- **好例**:这次更新保留了原有工作台布局,同时重新组织导航层级、合并重复入口。首次加载和列表刷新也做了优化,从打开应用到完成记录会更连贯。
|
||
- **改写建议**:先提取背景、改动、要求和结果,再按层次拆成两到三句;每句只保留一个主要动作或判断。
|
||
- **作用域**:产品发布稿、邮件
|
||
- **来源反馈**:fp-021, fp-024
|
||
|
||
### 规则 10:删除反复出现的提醒性套话(`rule-remove-repeated-attention-prefaces`)
|
||
|
||
- **定义**:当连续句子都用“值得注意的是”“需要特别注意的是”“更值得注意的是”等元话语开头,只是重复强调而没有建立新的信息层级时命中。若只在关键风险首次出现时使用一次,且确实需要提示读者改变注意焦点,则不命中。
|
||
- **检测方法**:LLM judge 语义判定(上线前须通过独立人工金标集校准)
|
||
- **坏例**:值得注意的是,本周五是最终截止时间。需要特别注意的是,逾期提交将影响下游联调。还值得注意的是,附件命名必须统一。
|
||
- **好例**:最终截止时间是本周五,逾期会影响下游联调。附件请按统一格式命名。
|
||
- **改写建议**:删掉“值得注意的是”等前缀,直接写结论、截止时间、后果或操作要求;需要突出时依靠信息顺序而非重复提醒。
|
||
- **作用域**:公众号文章、邮件
|
||
- **来源反馈**:fp-022, fp-025
|
||
|
||
### 规则 11:避免连续使用“被”字被动句(`rule-avoid-passive-voice-chains`)
|
||
|
||
- **定义**:当多个相邻分句都采用“对象被执行者处理”的结构,且执行者明确、适合直接充当主语时命中。若执行者未知、不重要,或文本确实需要突出受影响对象,则单个被动句不命中。
|
||
- **检测方法**:LLM judge 语义判定(上线前须通过独立人工金标集校准)
|
||
- **坏例**:配置文件会被启动器读取,依赖会被安装脚本自动下载,数据库会被迁移工具初始化,服务会被进程管理器拉起。
|
||
- **好例**:启动器读取配置文件,安装脚本自动下载依赖,迁移工具初始化数据库,进程管理器随后拉起服务。
|
||
- **改写建议**:把工具、模块或责任方移到主语位置,改写为“谁做什么”;只有确需突出承受结果的对象时才保留被动表达。
|
||
- **作用域**:README 段落、产品发布稿
|
||
- **来源反馈**:fp-023, fp-026
|