Sync third-party and MCP marketplace plugins
Constraint: Public skills are published only by explicit administrator action unless they are tracked third-party market sources. Confidence: high Scope-risk: narrow Directive: Keep private/internal skills out of the public marketplace and preserve normal incremental market Git history. Tested: Marketplace validation passed.
This commit is contained in:
KeyInfo Bot
@@ -388,6 +388,18 @@
|
||||
},
|
||||
"category": "Education & Research"
|
||||
},
|
||||
{
|
||||
"name": "shuorenhua",
|
||||
"source": {
|
||||
"source": "local",
|
||||
"path": "./plugins/shuorenhua"
|
||||
},
|
||||
"policy": {
|
||||
"installation": "AVAILABLE",
|
||||
"authentication": "ON_INSTALL"
|
||||
},
|
||||
"category": "Communication"
|
||||
},
|
||||
{
|
||||
"name": "etunel-role-collaboration",
|
||||
"source": {
|
||||
|
||||
@@ -3,5 +3,5 @@
|
||||
"name": "playwright浏览器自动化操作",
|
||||
"version": "20260605",
|
||||
"keySource": "none",
|
||||
"syncedAt": "2026-09-03T02:30:34Z"
|
||||
"syncedAt": "2026-09-03T02:47:41Z"
|
||||
}
|
||||
|
||||
@@ -0,0 +1,42 @@
|
||||
{
|
||||
"name": "shuorenhua",
|
||||
"version": "2.4.0",
|
||||
"description": "中文 AI 味清理 skill：先保信息，再谈风格。清理过度承接、工程师腔、小红书 AI 腔、翻译腔和无源权威铺垫，保住事实、版本、命令和责任归属。",
|
||||
"author": {
|
||||
"name": "MrGeDiao"
|
||||
},
|
||||
"homepage": "https://github.com/MrGeDiao/shuorenhua",
|
||||
"repository": "https://github.com/MrGeDiao/shuorenhua",
|
||||
"license": "MIT",
|
||||
"keywords": [
|
||||
"chinese",
|
||||
"writing",
|
||||
"de-ai",
|
||||
"ai-slop",
|
||||
"rewrite"
|
||||
],
|
||||
"skills": "./skills/",
|
||||
"interface": {
|
||||
"displayName": "shuorenhua",
|
||||
"shortDescription": "清理中文文本中的 AI 套路，同时保留事实、术语和责任主体。",
|
||||
"longDescription": "面向中文文本的改写和审稿 skill，用于清理模板套话、商业包装、工程师姿态腔、翻译腔和无依据的定性断言，并按场景控制改写力度，保留数字、命令、版本、因果条件和责任归属。",
|
||||
"developerName": "MrGeDiao",
|
||||
"category": "Communication",
|
||||
"capabilities": [
|
||||
"Interactive",
|
||||
"Read",
|
||||
"Write"
|
||||
],
|
||||
"defaultPrompt": [
|
||||
"使用 shuorenhua 帮我清理这段中文里的 AI 味，同时保留所有事实。",
|
||||
"使用 shuorenhua 的 annotation mode 先标出这段文字的问题，不要直接改写。"
|
||||
],
|
||||
"websiteURL": "https://github.com/MrGeDiao/shuorenhua",
|
||||
"privacyPolicyURL": "https://github.com/MrGeDiao/shuorenhua",
|
||||
"termsOfServiceURL": "https://github.com/MrGeDiao/shuorenhua/blob/main/LICENSE",
|
||||
"brandColor": "#DC2626",
|
||||
"screenshots": [],
|
||||
"logo": "./skills/shuorenhua/assets/icon.webp",
|
||||
"composerIcon": "./skills/shuorenhua/assets/icon.webp"
|
||||
}
|
||||
}
|
||||
@@ -0,0 +1,21 @@
|
||||
MIT License
|
||||
|
||||
Copyright (c) 2026 MrGeDiao
|
||||
|
||||
Permission is hereby granted, free of charge, to any person obtaining a copy
|
||||
of this software and associated documentation files (the "Software"), to deal
|
||||
in the Software without restriction, including without limitation the rights
|
||||
to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
|
||||
copies of the Software, and to permit persons to whom the Software is
|
||||
furnished to do so, subject to the following conditions:
|
||||
|
||||
The above copyright notice and this permission notice shall be included in all
|
||||
copies or substantial portions of the Software.
|
||||
|
||||
THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
|
||||
IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
|
||||
FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
|
||||
AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
|
||||
LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
|
||||
OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
|
||||
SOFTWARE.
|
||||
@@ -0,0 +1,9 @@
|
||||
{
|
||||
"sourceId": "shuorenhua",
|
||||
"repo": "https://github.com/MrGeDiao/shuorenhua.git",
|
||||
"ref": "main",
|
||||
"commit": "d2d0ce27da295581c3cf87a30ab65deb7d0ddfb8",
|
||||
"adapter": "claude-skill",
|
||||
"sourcePath": ".",
|
||||
"syncedAt": "2026-09-03T02:45:43Z"
|
||||
}
|
||||
@@ -0,0 +1,429 @@
|
||||
---
|
||||
name: shuorenhua
|
||||
description: "检查和清理中英文文本里的 AI 套路，适用于去 AI 味、说人话、自然一点、别像模板或先标问题等改写和审稿需求，同时保留事实、术语、语域和责任主体。"
|
||||
---
|
||||
|
||||
# 说人话
|
||||
|
||||
把文本从”像模型在表演写作”拉回”像具体人在当前场景下表达”。
|
||||
|
||||
这份 skill 不是敏感词替换器，也不是反技术、反抽象、反专业。它的目标是减少模板感、表演感和语域漂移，同时保住事实、术语和责任主体。
|
||||
|
||||
## When to use
|
||||
|
||||
在下面这些需求里使用：
|
||||
|
||||
- 用户明确说”去 AI 味””说人话””自然一点””别像模板””别太像 ChatGPT”
|
||||
- 需要改写中文或英文 `chat`、`status`、`docs`、`public-writing`
|
||||
- 需要先判断文本该轻改、中改还是重改
|
||||
|
||||
在下面这些需求里不要硬套：
|
||||
|
||||
- 用户要逐字翻译、保留原文风格、仿官方模板或仿特定品牌 voice
|
||||
- 文本主要是代码、日志、命令、配置、接口名、报错
|
||||
- 用户要的是事实校对，不是风格改写
|
||||
|
||||
## Core stance
|
||||
|
||||
- 去 AI 味，主要处理的是模板感、收束腔、虚假主语、语域混搭和表演性技术腔。
|
||||
- 保留技术性。专业词、系统主语、事故复盘用语、PRD/发布说明中的术语默认可保留。
|
||||
- 优先保信息，再谈风格。任何改写都不能新增事实、删核心事实或改变责任主体。
|
||||
- 原文的量化表述有歧义时，默认保留原关系并标出待确认，不替作者修正成某一种数量关系；任何情况下都不得补原文没有的基数、年份、期限或测量结果。
|
||||
- 不用机械同义词替换表，也不要为了躲重复而轮换同义词。关键词该重复就重复，换词躲重复本身就是模型腔。默认可以删句、并句、降调、换主语、去总结式收尾；如果进入 `in-place` scope，就只做句内改写。
|
||||
- 短语表默认只列代表项，不追求穷举所有变体。遇到新口癖，先按现有模式归类，再决定要不要补词。
|
||||
|
||||
## Execution order
|
||||
|
||||
按固定顺序做，不要跳步：
|
||||
|
||||
1. 判场景：`chat / status / docs / public-writing`
|
||||
2. 查禁改项：先划 `protected spans`，并在心里记一份事实 / 关系账本：实体类型、数字修饰对象、主体与各自动作 / 目标、实现关系；看有没有必须保留的术语、系统主语、引用原文、命令或正式语体
|
||||
3. 判 Tier：`Tier 1 / Tier 2 / Tier 3`，按问题命中强度判断，不要把 Tier 当作改写力度
|
||||
4. 再判档位：`minimal / standard / aggressive`
|
||||
5. 判 scope：`structural / bounded / in-place`，判断这次能删到什么程度——自由删并重排、只把整句空话进删除清单、还是一句都不删
|
||||
6. 先执行本文件里的最小规则；只要环境里能读 `references/`，默认继续按问题类型补看 [Protected Spans](./references/protected-spans.md)、[Positive Style Contract](./references/positive-style.md)、[微操作手册](./references/operation-manual.md)、[结构反模式](./references/structures.md) 和相关短语表；如果目标是“改完能直接发”，或文本明显属于 README、release note、论坛帖、issue 回复、API reference、FAQ，再补看 [Scene Packs](./references/scene-packs.md)、[场景样本评测](./evals/real-samples.md) 和 [改写示例](./references/examples.md)
|
||||
7. 回读拆成两步：先做保真回读，再按需做残留味回读
|
||||
8. 输出：默认只给单一推荐版本；用户明确要求“先标问题，不改写”时切到 `annotation mode`
|
||||
|
||||
执行第 6 步时，先按“模式”处理，再按“词条”兜底：
|
||||
|
||||
- 同一类调试腔、暴力动作腔、主动出击腔、总结提示腔，默认按同一模式处理，不要求逐词命中
|
||||
- 只有当新说法改变了误杀边界，或明显不属于现有模式时，才把它当作新增词条处理
|
||||
|
||||
## 1. Scene detection
|
||||
|
||||
先判主场景，再处理局部问题。混合文本只保留一个主语域，其他语域只在必要信息层面留下。
|
||||
|
||||
### `chat`
|
||||
|
||||
信号：
|
||||
|
||||
- 短回复、日常对话、协作沟通、评论、即时反馈
|
||||
- 允许口语，但不该端着说话
|
||||
|
||||
默认档位：`minimal`
|
||||
|
||||
### `status`
|
||||
|
||||
信号：
|
||||
|
||||
- 站会更新、进度同步、复盘摘要、汇报式状态说明
|
||||
- 重点是时间线、动作、结果、风险
|
||||
|
||||
默认档位：`minimal` 或 `standard`
|
||||
|
||||
### `docs`
|
||||
|
||||
信号：
|
||||
|
||||
- 操作文档、技术说明、接口说明、FAQ、事故复盘
|
||||
- 重点是可检索、可复现、术语稳定
|
||||
|
||||
默认档位：`minimal`
|
||||
|
||||
### `public-writing`
|
||||
|
||||
信号：
|
||||
|
||||
- 公众号、小红书、公开帖、对外文章、观点写作
|
||||
- 重点是语域一致，不要装“有洞见”
|
||||
|
||||
默认档位：`standard`
|
||||
|
||||
更细的下限限制见 [场景禁改表](./references/scene-guardrails.md)。
|
||||
|
||||
### Scene Packs
|
||||
|
||||
如果文本本身命中下面任一子场景，不依赖用户是否明说，也不受主场景初判限制，都要补看 Scene Packs：
|
||||
|
||||
- `README`：出现项目介绍、快速开始、安装方式、功能列表、README intro 等信号时，第一屏要说清“这是什么、给谁用、解决什么问题”
|
||||
- `release-note`：出现版本标题、`Release Highlights`、`Added / Changed / Fixed / Tested`、changelog 列表等信号时，列清本版变更、验证和限制，不写发布宣言
|
||||
- `forum-post`：出现 Linux.do / V2EX / 社区帖 / 发帖复盘等信号时，保留维护者的真实观察和社区语气，不改成公告
|
||||
- `issue-reply`：出现 issue / PR 回复、bad case、复现、下一版补 benchmark 等信号时，先确认问题和下一步，不做客服式安抚
|
||||
- `api-reference`：出现 endpoint、HTTP method、参数字段、类型/默认值、状态码/错误码、鉴权或请求响应示例等信号时，删宣传和元评论，但 method、path、字段、约束、字面量与恢复动作零漂移；缺失合同只标待确认，不替作者补
|
||||
- `faq`：出现 FAQ / 常见问题 / 排障问答等发布结构时，尽早给出结论或动作；原本在操作前的执行条件和警告不能因此挪到操作后，真实的事后检查和失败分支也不能改成前置步骤。不扩大问题范围、否定、期限与支持承诺，不补原文没有的操作，也不把采访或讨论问答套成 FAQ；结构调整仍受 scope 限制
|
||||
|
||||
子场景只负责发布目的和语气收束，不覆盖 protected spans、Tier、档位和回读规则。完整策略见 [Scene Packs](./references/scene-packs.md)。
|
||||
|
||||
## 2. Single-file fallback rules
|
||||
|
||||
只加载 `SKILL.md` 时，也必须能完成基础改写。下面这些规则默认直接生效：
|
||||
|
||||
- 删开场套话、谄媚和元评论：例如 `值得注意的是`、`让我来为你解释`、`希望这对你有帮助`、`Great question!`
|
||||
- 删空总结和收尾腔：例如 `综上所述`、`归根结底`、`本质上`、`At the end of the day`
|
||||
- 处理二元对比骨架：`不是 X，而是 Y`、`与其 X，不如 Y` 多数删前半句，直接说 `Y`
|
||||
- 处理无源引用：`研究表明`、`数据显示`、`studies show`、`experts say` 默认按场景选择 `rewrite-safe` 或 `audit-only`；只有用户明确要保留原论证骨架时才用 `rewrite-with-placeholder`；不要补虚构来源
|
||||
- 把商业黑话和表演性技术腔改回普通动作：例如 `赋能`、`抓手`、`闭环`、`收窄`、`兜住`、`落盘`、`leverage`
|
||||
- 遇到过度接住、替用户做心理判断或身份认证式夸奖：例如 `你不是敏感`、`你只是太久没被稳稳接住了`、`你问到了问题的核心`、`顶刊作者的素养`，默认删姿态层，改回低承诺回应或具体判断；不要硬演“我懂了”。方向/进度认证（`走在正确的路上`、`完全不用担心`）只能删除或标注“现有信息不足以判断”，不要降格成 `方向没问题 / 不用太担心` 这类弱安抚继续替对方下结论
|
||||
- 发现翻译腔时，优先缩短主语和动作，少用长定语链、被动堆砌、`基于……`、`通过……来……`
|
||||
- 把名词化还原成动词：`对流程进行了优化` → `把流程改顺了`，`实现了效率的提升` → `快了多少、省了几个人`。`进行 / 实现 / 完成 / 开展 / 起到 / 具有` 带一个动名词是典型信号；公文固定表述和 `docs` 里的稳定术语除外
|
||||
- 同一个对象不要在相邻几句里换三种说法（`修表 → 这门手艺 → 这项技能`）。关键词重复是正常中文，逐次升格换词是模型腔；代词照应不算
|
||||
- 误杀防护优先：引用原文、命令、接口名、字段名、日志、报错、系统主语、技术报告术语默认保留
|
||||
- 清理姿态层时按子句和事实要素判断，不按整句、整行一刀切：删掉某个子句如果会改变命题真值、适用范围或成立条件，它就是保真对象，不是可随姿态一起删除的空话。输出前做双向核对：先确认输入中的范围、条件、否定、情态、完成态、方向和强度都能在输出逐项找回，再确认输出新增或改写的每个关系都能回指输入依据
|
||||
- `code-context` 里的真实运行行为、适用条件和边界说明也属于 protected spans；清理注释、docstring 或 commit message 时，只去姿态词并保留这些信息，不能因为相邻行已有指标或结果就认定它们重复、整行删除
|
||||
- 抽象信息、实体类型和关系不能擅自具体化、合并、互换或删除：`方案` 不能改成 `工具 / 产品`，`目标` 不能改成 `产品`，描述某种架构的潜力不能改成“系统基于该架构构建”。数字与它修饰的对象、主体与各自动作 / 目标的配对关系要一起保留；不能把 `两个团队` 写成“换过两个团队”，也不能把只属于企业的目标顺手并给开发者。谓词的方向、完成态、强度和效果类型也属于关系：`性能提升 / 体验改善 / 安全性加强` 不能弱化成“涉及这些方面”，`提升效率` 也不能顺势扩写成“节省时间 / 成本”；删掉 `显著 / 大幅` 等渲染词时，仍要保留原文实际声称发生了什么。背景、主题或相邻句共现不等于能力关系：同段提到 AI 和中文表达工具，不能据此写成“处理 AI 生成文本”；任何 `X 用来做 Y / X 基于 Y / X 处理 Y` 都必须能在原文谓词里找到依据。目的、适用条件、风险和限制即使对象仍然抽象，也属于信息：`为了解决这一痛点` 可以压成 `为了解决这个问题`，不能因为没写具体问题就把“解决问题”这一目的删掉。原文没有具体能力、实现关系或对象时，允许保留原来的抽象层级、缩短或标注缺口，不能用看似合理的新事实补落点
|
||||
- 中英混排句中的英文词按当前句子的实际语义判断，不机械套英文词表
|
||||
|
||||
单文件模式只是兜底，不是完整模式。只要环境里能读 `references/`，默认就继续补看对应文件；只有在 system prompt 真的只给了 `SKILL.md` 时，才退化为只按本文件做基础清理。
|
||||
|
||||
### Unsourced citation modes
|
||||
|
||||
处理无源引用时，固定只在这 3 种模式里选一种：
|
||||
|
||||
- `rewrite-safe`
|
||||
- 去掉 `研究表明 / studies show / 业内人士认为` 后，只有不依赖该来源也能独立成立的判断才保留
|
||||
- 如果数字、预测或结论本身全靠这条无源引用成立，删掉整条论断；不要删掉 `40%` 后改成“会更快”，也不要把 `未来十年` 改成“未来几年”
|
||||
- 默认用于 `chat` 和 `public-writing`
|
||||
- `audit-only`
|
||||
- 不替作者补写来源，也不把无证据判断改写成像是已有证据
|
||||
- 明确指出“这里缺来源/缺归属”，必要时保留原句不重写
|
||||
- 只约束无源论断本身；同段其他病灶（骨架、黑话、空总结、姿态层）仍按各自规则清理，不因一处审计把整段冻结成风险说明
|
||||
- 默认用于 `docs` 和 `status`
|
||||
- `rewrite-with-placeholder`
|
||||
- 只在用户明确要求保留原结构、原语气或编辑稿框架时使用
|
||||
- 可以写成“有研究认为……，但这里没有给出处”这类占位提醒
|
||||
- 不能补具体机构、数据、年份、研究名称
|
||||
|
||||
如果用户没指定模式，就按场景默认值走；如果文本跨场景，优先取更保守的 `audit-only`。
|
||||
|
||||
## 3. Rewrite level
|
||||
|
||||
### `minimal`
|
||||
|
||||
适用于：文本本身基本自然，只需去掉局部模板感、收尾腔和多余修辞。
|
||||
|
||||
默认动作：
|
||||
|
||||
- 删掉空总结
|
||||
- 把过度抬高的语气压回常规
|
||||
- 把"像在解释自己会写作"的句子压回事实句
|
||||
|
||||
### `standard`
|
||||
|
||||
适用于：有明显 AI 腔或语域混搭，但信息骨架是好的。
|
||||
|
||||
默认动作：
|
||||
|
||||
- 统一语域
|
||||
- 改掉工程师表演腔、商业黑话、narrator 腔
|
||||
- 必要时并句或换主语
|
||||
|
||||
### `aggressive`
|
||||
|
||||
适用于：`Tier 1` 命中密集，或 `Tier 1 + Tier 2` 叠加后整段呈现强模板感或强表演感。
|
||||
|
||||
限制：
|
||||
|
||||
- 只有在 `Tier 1` 明显密集，或多类结构问题叠加时才允许
|
||||
- 先保护事实和术语，再做重写
|
||||
- `docs` 默认不要升到 `aggressive`
|
||||
|
||||
## 3.5 Edit scope
|
||||
|
||||
Scope 表示这次能不能改动句子和段落结构，和 `minimal / standard / aggressive` 是两条轴。三档 scope 按"能不能删整句、怎么删"区分：`structural` 自由删并重排；`bounded` 只删"删了不丢信息"的整句空话，且走删除清单交用户确认；`in-place` 一句都不删。
|
||||
|
||||
### `structural`
|
||||
|
||||
默认 scope。适用于短文本、明确要求重写的文本、AI 味密度很高且不需要保留原节奏的文本。
|
||||
|
||||
允许动作：
|
||||
|
||||
- 删整句空总结
|
||||
- 合并相邻事实句
|
||||
- 轻量调整句序或段落落点
|
||||
- 按场景重写局部结构
|
||||
|
||||
### `bounded`
|
||||
|
||||
中文 `public-writing` 长文（约 1000 字以上）的默认 scope。目标是把整句级的 AI 味去干净，又不被 `structural` 不可控地压缩——长文走 `structural` 时缩水程度依模型而定（同一篇可能 -18%，也可能 -39%），用户无法预期；`bounded` 把"删多少"交还给用户。
|
||||
|
||||
和另两档的关系：
|
||||
|
||||
- 比 `structural` 克制：不合并相邻句、不重排段落、不删承担节奏的实句或有意重复
|
||||
- 比 `in-place` 能去味：允许删"整句都是空话"的句子，但不直接删，而是进删除清单交用户拍板
|
||||
|
||||
一句能进删除清单，必须同时满足三条：
|
||||
|
||||
1. 删掉后该段信息点不变（不带任何独有的事实、数字、判断、动作或指令）；例外是整条无源论断：其中的数字或时间跨度如果只依赖未提供的来源成立，可以随整句进删除清单，若保留论断则不得改值或改跨度
|
||||
2. 不是相邻两实句之间的唯一过渡
|
||||
3. 命中纯空句型：空总结 / 价值拔高收尾 / 无源权威铺垫 / 谄媚开场 / 整句旁白
|
||||
|
||||
两类动作分开走（实测依据：长文里句首引导词模型能句内清掉，但整句空话在 `in-place` 下删不掉，只会被软化成另一种说法）：
|
||||
|
||||
- 句首可剥离的引导词（`值得一提的是 / 归根到底 / 这说明`）后面还跟着实质内容 → 直接句内洗，删引导词留骨架，不进清单
|
||||
- 整句都是空的，剥掉引导词就什么都不剩（无源论断、`不仅仅是……更是……` 的价值拔高）→ 进删除清单，不擅自软化成另一种说法
|
||||
|
||||
输出：正文给句内洗后的稿，末尾附「建议删除（待确认）」清单，每条写 `原文 + 为什么删了不丢信息`。用户点头才删，长度由用户拍板。
|
||||
|
||||
### `in-place`
|
||||
|
||||
适用于用户明确要求"完全原样 / 一句都别删 / 严格保句数"的情况，比 `bounded` 更严：整句空话也不删，只做句内降调。
|
||||
|
||||
默认触发条件：
|
||||
|
||||
- 用户 prompt 明确要求保留句数、完全原样、一句不删，或反馈 `bounded` 仍删多了
|
||||
|
||||
禁止动作：
|
||||
|
||||
- 不删整句（即使整句是空话）
|
||||
- 不合并相邻句
|
||||
- 不重排段落
|
||||
- 不把多段压成一段
|
||||
|
||||
允许动作：
|
||||
|
||||
- 句内替换词或短语
|
||||
- 删除句内提示层、空泛修饰和语气垫片
|
||||
- 把句内拔高语气降回普通判断
|
||||
- 在单句内部拆短过满结构，但不改变段落顺序
|
||||
|
||||
删短语前先做语义独立性检查：删掉短语后，剩余部分必须仍是完整、可读、没有悬空指代的陈述句。否则改用句内替换，不要硬删。遇到整句空话，保留原句并标注 `[空句，建议人工确认是否删除]`，不擅自软化成新说法。
|
||||
|
||||
`aggressive + in-place` 可以存在，但默认先提醒用户：长文 `aggressive` 很容易明显缩水；如果用户真正要保长度，优先改成 `standard + bounded`。用户明确坚持时，再执行 `aggressive + in-place`，但仍遵守不删整句、不并句、不重排的边界。
|
||||
|
||||
## 4. Tier severity
|
||||
|
||||
Tier 表示问题命中强度，与 [严重度分级](./references/severity.md) 保持一致，不表示改写力度。
|
||||
|
||||
### Tier 1
|
||||
|
||||
默认替换。命中这类词或句式时，通常直接删掉或换成更具体的表达。常见类型：
|
||||
|
||||
- 开场套话、总结式收尾、谄媚句
|
||||
- 明显商业黑话、自媒体流水线用语、表演性工程师腔
|
||||
- 过度接住式共情、替用户做心理判断、郑重预告和身份认证式夸奖
|
||||
- 英文里的 sycophantic openers、significance inflation、business jargon
|
||||
|
||||
默认处理：局部命中用 `minimal` 或 `standard`，密集命中时可升到 `aggressive`
|
||||
|
||||
### Tier 2
|
||||
|
||||
单独出现可以放行，但同段聚集时是 AI 味信号。常见类型：
|
||||
|
||||
- 高频连接词扎堆
|
||||
- 渲染性修饰词扎堆
|
||||
- 某一类姿态词在同段重复出现
|
||||
|
||||
长度参考：短段落（< 100 字/词）同段 2+ 个即标记；长段落（≥ 100 字/词）同段 3+ 个再标记。
|
||||
|
||||
默认处理：保留最贴切的一个，其余改写；通常用 `minimal` 或 `standard`
|
||||
|
||||
### Tier 3
|
||||
|
||||
常见词本身不构成问题，只在全文密度明显过高时才处理。常见类型：
|
||||
|
||||
- `重要 / 关键 / 核心 / 提升`
|
||||
- `significant / innovative / effective`
|
||||
|
||||
默认处理：删掉多余的几次，或把一部分换成具体信息（不换同义词）；通常用 `minimal`，必要时不改
|
||||
|
||||
## 5. No-touch and keep rules
|
||||
|
||||
用户当前要求与项目已有的 style guide / 术语表优先于本 skill 的默认规则；项目正式术语和稳定团队表达，不得仅因命中通用词表就改写。
|
||||
|
||||
保护依据是词在当前句子里的具体含义，或用户、项目明确给出的约定。不能只因文本是 README、发布说明、评测报告，或带有命令和数字，就把周围的包装表达一起放行；原文用了某个说法，也不等于项目要求保留它。不要自行假定存在术语表、团队约定或未提供的提交记录。
|
||||
|
||||
数值、正式指标名、字段名、命令和引用原文按字面保护；实验结果和完成状态按含义保护，非正式叙述中的包装动词仍可等义改写。保护“完成了多少”的关系，不要求照抄表达它的全部措辞；不能把带数字的整条叙述自行认定为正式指标名。
|
||||
|
||||
词本身正在被定义、讨论，或属于引用原文时，保留这个词；拿同一个词包装进展或结论时，按实际语义判断是否需要改写。没有附术语表的正常技术词仍然保留，不要求用户额外证明；也不要机械替换同形词。
|
||||
|
||||
例如 `闭环反馈 / 闭环控制` 是反馈机制，保留；把完成工作写成 `闭环` 时，还原为完成了什么，保留 `未 / 只 / 部分` 等完成范围，不写成全流程已完成。
|
||||
|
||||
以下内容默认优先保留，除非用户明确要求改风格且改动不损害信息：
|
||||
|
||||
- 引用原文、命令、接口名、参数名、字段名、配置项、日志、报错
|
||||
- 技术文档里的系统行为主语
|
||||
- postmortem / incident / PRD / release note 中的专业术语
|
||||
- 承载关键事实的抽象句，即使它“有点像 AI”
|
||||
|
||||
不要为了“像人”把文本改得更假。专业文本可以专业，关键是别模板化、别表演化。
|
||||
|
||||
完整的保护清单见 [Protected Spans](./references/protected-spans.md)。
|
||||
|
||||
## 6. Positive style targets
|
||||
|
||||
改写后的文本应尽量满足：
|
||||
|
||||
- 有具体信息，不靠空洞总括撑气势
|
||||
- 有主语和动作，不靠虚假主体兜底
|
||||
- 有统一语域，不在技术腔、商业腔、自媒体腔之间跳
|
||||
- 以“可直接发”为终点，不为了更像人继续抛光到失真
|
||||
- 有节奏，但节奏来自删冗余和保留重点，不来自硬造金句
|
||||
- 有立场，但立场来自判断或事实，不来自“故作洞见”
|
||||
- 有边界，没把握就直说，不替对方做心理判断，也不硬演“我懂了”
|
||||
|
||||
更完整的正向目标、分场景校准和“cleaner vs more human”对照见 [Positive Style Contract](./references/positive-style.md)。
|
||||
|
||||
## 7. Output contract
|
||||
|
||||
默认输出一个推荐版本，不默认输出审稿过程、多版本比稿或逐条点评。
|
||||
|
||||
### Annotation mode
|
||||
|
||||
只有在用户明确要求下面这类事情时才启用：
|
||||
|
||||
- `先别改，先标问题`
|
||||
- `这段哪里像 AI`
|
||||
- `只做诊断 / 审稿 / 标注`
|
||||
- `先告诉我该不该改`
|
||||
|
||||
`annotation mode` 不直接给整段改写稿，默认只输出最重要的 1-5 个问题点。每个问题点固定包含这 4 个字段：
|
||||
|
||||
- `问题族`：例如 `开场套话 / 无源引用 / 材料不足 / 工程师腔 / 语域混搭`
|
||||
- `触发点`：点明命中的词、结构或局部句子
|
||||
- `建议动作`：删掉、换成具体表达、补来源、保持不动
|
||||
- `是否建议改写`：`是 / 否`
|
||||
|
||||
额外约束：
|
||||
|
||||
- 如果文本主要问题是“缺来源”，可以只建议补来源，不强行给改写稿
|
||||
- 如果文本的问题是“没东西可写”而不是“话说得不对”，用 `材料不足` 标出来。判据是压缩试验（见 [微操作手册](./references/operation-manual.md)）：删光姿态层、拔高和套话之后，剩下的事实、动作、数字和判断撑不起原文篇幅。`建议动作` 写清删完还剩什么、缺的是哪一类材料，不替作者设计怎么去补，也不用换说法把篇幅填回去。`材料不足` 不是“不用改”，该清的姿态照常清，只是要同时说明改完会短很多
|
||||
- `材料不足` 只在 `annotation mode` 出。默认改写模式仍然只交改写结果，不评价作者手里有没有东西可写
|
||||
- 如果文本落在误杀防护边界内，直接写 `是否建议改写：否`
|
||||
- 不要一边说“只标问题”，一边偷偷输出完整重写版
|
||||
- 用户没要求 `annotation mode` 时，仍然按默认改写合同输出单一推荐版本
|
||||
|
||||
遇到无源引用时，输出必须符合所选模式：
|
||||
|
||||
- 在 `annotation mode` 下，只输出对应的处理建议，不直接给整段改写稿
|
||||
- 在默认改写模式下，再按所选模式实际给出改写结果
|
||||
- `rewrite-safe`：建议删掉无法独立成立的整条无源论断；如果去掉权威铺垫后仍有不依赖来源的判断，再保留该判断。不要去掉数字后留下更泛的同向断言；如果不是 `annotation mode`，再给改写结果，不补虚构来源
|
||||
- `audit-only`：优先点明缺来源、缺归属，而不是假装已经证实
|
||||
- `rewrite-with-placeholder`：允许保留论证位置，但要显式暴露“此处待补来源”；如果不是 `annotation mode`，可以给带占位提示的改写结果
|
||||
|
||||
只有在高风险误杀时，才额外补一行极短说明，例如：
|
||||
|
||||
- `保留了系统主语和术语，避免失真。`
|
||||
- `这里只做轻改，避免把正式公告写成口语贴。`
|
||||
|
||||
## 8. Required reread checks
|
||||
|
||||
提交改写前，把回读固定拆成两步，不要混着做：
|
||||
|
||||
### Pass 1 | 保真回读
|
||||
|
||||
先检查这 5 项：
|
||||
|
||||
1. protected spans 是否漂了
|
||||
2. 信息是否丢失：范围、条件、否定、情态、完成态、方向和强度逐项可追溯
|
||||
3. 语域是否统一
|
||||
4. 术语是否失真
|
||||
5. 删改后是否出现生硬断裂
|
||||
|
||||
再做一次分析—输出一致性检查：先从输入到输出核对范围、条件、否定、情态、完成态、方向和强度是否逐项保留，再从输出回指输入依据。如果前面的判断是“原文没有具体对象、能力、实现或依据”，最终结果里就不能出现新工具、产品、平台、功能、实现关系或指标；输出里的每个 `X 做 Y / X 基于 Y / X 处理 Y` 关系都要能回指原文中的同一谓词关系，不能只靠同段共现推断；同义改写也不能改变谓词的方向、完成态、强度或效果类型，不能把“已经改善”写成“涉及”，也不能把“提升效率”扩成“节省时间”；如果命中项列出了数量—对象、主体—目标等保护关系，处理结果必须逐项对得上。
|
||||
|
||||
如果删掉一句后段落突然没了落点，就用原文已有的信息重组一条事实句，不要补口号句；原文里找不到可用信息就不补，宁可让段落短一点。
|
||||
|
||||
`bounded / in-place` scope 下额外检查：
|
||||
|
||||
- 信息留存优先：原文每个信息点（事实、数字、判断、动作）在输出里都要可追溯，这是硬指标
|
||||
- `in-place`：输出字数低于原文 85% 时，回退检查是否误删整句、并句或压段落（in-place 不该删任何整句）
|
||||
- `bounded`：字数会因删整句空话而下降，不设硬下限；但要确认删除清单里每条都是"删了不丢信息"的纯空句，没混进实句或承担节奏的重复
|
||||
- 句数变化超过约 10% 时，回退检查是否偷偷做了未经确认的 structural 改写
|
||||
- 关键事实句、转场句和承担节奏的重复句，不能因为“看起来像模板”就默认删除
|
||||
|
||||
### Pass 2 | Residual Audit
|
||||
|
||||
只有在第一遍已经保住事实、但读起来还有轻微 AI 味时，才做第二遍。第二遍固定只查这 5 件事：
|
||||
|
||||
1. 开场残留：还在用 `结论先说 / 直接说结论 / 值得注意的是` 这类提示层
|
||||
2. 总结残留：还在用 `总的来说 / 归根结底 / 最终来看` 这类空收尾
|
||||
3. narrator 残留：还在解释“这说明了什么”，而不是直接说事实或判断
|
||||
4. 空泛判断残留：还在写 `方向是对的 / 意义重大 / 真正理解了用户`
|
||||
5. 节奏过匀：每句都差不多长、差不多抬手、差不多落点，像被统一抛光过；同一种句式骨架（尤其二元对比 `不是 X，是 Y`）反复到能预判下一句形状时，按 [结构反模式](./references/structures.md) 第 1 条和第 18 条的密度判据处理
|
||||
|
||||
第二遍只允许做轻量修正：
|
||||
|
||||
- 删一个残留开场或收尾
|
||||
- 合并两句过匀的事实句，或拆一处过满的句子
|
||||
- 把一句 narrator / 空泛判断压回直接表达
|
||||
- 同型句式骨架超出密度阈值时，先按 [结构反模式](./references/structures.md) 第 1 条剔除豁免项（判据和上限见该条「保留条件」），再把剩余超标的那几处换成中性连接或直接陈述
|
||||
|
||||
第二遍不要做的事：
|
||||
|
||||
- 不重写全文
|
||||
- 不补原文没有的事实
|
||||
- 不为了“更像人”改掉术语、参数、命令、报错或责任归属
|
||||
|
||||
场景保守策略：
|
||||
|
||||
- `public-writing` 和 AI 味偏重的 `chat`，第二遍更常需要
|
||||
- `docs / status / code-context` 默认更保守；如果第二遍会让语气变口语、变广告、或影响保真，就停在第一遍
|
||||
|
||||
## Reference navigation
|
||||
|
||||
- 本文件可以单独兜底；完整模式默认是 `SKILL.md` + `references/` 一起工作
|
||||
- 想先看“改成什么样才算更像人”：看 [Positive Style Contract](./references/positive-style.md)
|
||||
- 想先看哪些数字、引用、命令、参数不能漂：看 [Protected Spans](./references/protected-spans.md)
|
||||
- 想看中文高频短语：看 [中文禁用短语表](./references/phrases-zh.md)
|
||||
- 想看英文高频短语：看 [English Banned Phrases](./references/phrases-en.md)
|
||||
- 想看句子和段落层面的结构问题：看 [结构反模式](./references/structures.md)
|
||||
- 想按 `Tier 1 / 2 / 3` 校准命中规则：看 [严重度分级](./references/severity.md)
|
||||
- 遇到具体病灶怎么动手：看 [微操作手册](./references/operation-manual.md)
|
||||
- 想确认某个场景什么不能乱动：看 [场景禁改表](./references/scene-guardrails.md)
|
||||
- 想校准误杀边界或做静态回归：看 [边界案例集](./references/boundary-cases.md)
|
||||
- 想看场景样本评测（高拟真合成，验收线是改完能不能直接发）：看 [场景样本评测](./evals/real-samples.md)
|
||||
- 想看默认改写和 `annotation mode` 的对照：看 [改写示例](./references/examples.md)
|
||||
- 想处理没收录进词表的同类变体：先看 [微操作手册](./references/operation-manual.md) 里的“变体归并”规则，再决定要不要补词
|
||||
|
||||
默认做法是：先用本文件完成“场景、Tier、档位、输出合同”的主判断，再按问题类型补读 `references/`；只有在单文件安装场景里，才停留在本文件的兜底规则。
|
||||
Binary file not shown.
|
After Width: | Height: | Size: 19 KiB |
@@ -0,0 +1,50 @@
|
||||
# Benchmark 分层与发布门槛
|
||||
|
||||
> 2026-07-23 起生效。本文件是评测用例分层和发布门槛的单源：判分列定义见 [run-eval.md](./run-eval.md)「判分分层」，逐条预期仍在 [benchmark.md](./benchmark.md)。
|
||||
> 防放水约束：分层判据先于跑分定稿；任何用例的层级变更都要在下面的例外表补一行理由并记入 CHANGELOG，不得在一轮实跑结果出来后为达标移动层级。
|
||||
|
||||
## 为什么分层
|
||||
|
||||
旧门槛把事实保真、scope 合同、明显套路、主观风格和输出协议混进同一个 `SF > 90%` 分母，并要求所有模型统一达标。后果是：主观风格上的合理模型分歧被当成规则缺陷修，规则围着单个失败用例长例外（v2.1.0 复盘结论）。分层之后，失败的严重性决定它的后果：硬约束失败阻塞发布，风格失败进趋势报告。
|
||||
|
||||
## 层级定义
|
||||
|
||||
| 层级 | 含义 | 进门槛吗 |
|
||||
|------|------|----------|
|
||||
| L0 输出协议 | 标题、判定链、区间完整性等 harness 格式 | 否；格式坏的轮次修复后重跑或由运行者归一化，在 results 里记录，不零化内容分 |
|
||||
| L1 硬约束 | protected spans 漂移（含 code-context 里的真实运行行为、适用条件和边界）、编造事实/来源/数据、scope 越界（in-place 删句/并句/重排，bounded 并句或删除清单混实句）、责任主体或归属改变、无源数字/时间跨度降格、引用与用户指令边界破坏 | 是；任何用例出现即硬失败 |
|
||||
| L2 风格目标 | 明显套路的清除：谄媚开场、空总结、商业黑话、姿态层、语域混搭等 | 报告 + 趋势；不设跨模型统一线 |
|
||||
| L3 风格观察 | 两位合格编辑可能对预期输出合理分歧的用例 | 否；按可接受集判，只记录 |
|
||||
|
||||
## 归属规则
|
||||
|
||||
- 全部 SNF：误杀结果记在 judge 第二列并单独统计；普通误杀不记 L1，其中涉及编造或受保护片段破坏的误杀才同时按 L1 硬失败处理。
|
||||
- 全部 SF：硬约束子项一律按 L1 判（judge 硬约束列）；风格预期默认 L2，例外见下表。
|
||||
|
||||
## 例外与特记
|
||||
|
||||
| 用例 | 判定 | 理由 |
|
||||
|------|------|------|
|
||||
| SF-15 | 风格列 L3 | "长短句交替、制造呼吸感"是节奏偏好，两位合格编辑可以合理给出不同答案；硬子项（不编造指标）照常 L1。 |
|
||||
| SF-40 | 风格列 L3 | 三组骨架分布在三个段落，操作手册只约束"同段连续叠加"；样本内容本身是作者刻意用对比结构论证"反对过度整理"，no-op 有合理性。硬子项照常：留存 ≥ 0.85、不删句、不并句、不重排。 |
|
||||
| SF-42 | 风格列 L3 | 与 scene-packs"README intro 允许一句有辨识度的定位句"存在真实张力，定位句 vs 空夸是编辑判断；硬子项（不得编造能力承诺）照常 L1。 |
|
||||
| SF-36 | L2，标准写死 | 通过 = 输出不再含方向/风险认证（删除或标注"信息不足以判断"均可）；降格成 `方向没问题 / 不用太担心` 记 ❌。 |
|
||||
| SF-18 | L2 | 2026-07-23 修复 audit-only 冻结许可冲突（run-eval / rewrite prompt 与操作手册矛盾）后生效；此前失败的主因是合同矛盾，不是模型能力。 |
|
||||
| SF-05 | L2，预期已改写 | 2026-07-23 起预期对齐 rewrite-safe 合同（依赖无源引用的论断整条删除）；历史轮次分数不可比。 |
|
||||
| SF-09 / SF-12 | L2，残留宽容 | 主病灶（被动堆砌 / 小红书腔）清除可判定；残留单个次要词条记 ⚠️，不记 ❌。 |
|
||||
| SF-19 / SF-41 | 硬约束为主 | 用例核心即引用边界 / bounded 删除清单纪律，属 L1；风格列只判残余姿态层。 |
|
||||
|
||||
## 发布门槛（2026-07-23 起）
|
||||
|
||||
1. L1 硬约束失败 = 0（含 SNF 中涉编造 / 受保护片段破坏的误杀）。
|
||||
2. SNF 误杀率 < 10%。
|
||||
3. 本版新增或修订用例的 targeted 双模型达标。
|
||||
4. L2 风格通过率按模型分别报告，并与上一版对比；明显回退（> 5 个百分点）需要在 results 里给出解释。L3 只记录，不进任何门槛。
|
||||
|
||||
同时继续并列报告旧口径 SF 通过率，保持历史可比；旧口径不再作为发布判断依据。
|
||||
|
||||
## 维护
|
||||
|
||||
- [benchmark.md](./benchmark.md) 用例增删后，检查本文件的例外表是否需要同步。
|
||||
- 新用例默认落 L2；要进 L3 必须满足"两位合格编辑可能合理分歧"的判据，并在例外表写明理由。
|
||||
- 想把某条从 L2 降到 L3 时，先问：失败是因为规则说不清，还是因为答案本来就不唯一？前者修规则，后者才降层。
|
||||
@@ -0,0 +1,754 @@
|
||||
# 场景样本评测（高拟真合成）| Scenario Sample Eval Pack
|
||||
|
||||
> 旧名「真实样本评测」，2026-07-11 更名：样本是"观察归纳 + 合成"产物（见下节），旧名容易被误读为真实用户样本。文件路径 `real-samples.md` 保持不变，避免断链。
|
||||
>
|
||||
> v1.7.2 新增（首批 12 条），v1.7.3 扩到 14 条，v1.8.0 扩到 18 条，v1.8.5 扩到 19 条，v2.3.0 扩到 20 条。用来补 `benchmark.md` 的短板：benchmark 是合成的、结构清晰、病灶明显；
|
||||
> 本文件关注的是"整段看起来不明显，但一发出去就知道不对"的样本——改完能不能直接发，才是最终验收线。
|
||||
|
||||
## 关于来源
|
||||
|
||||
> **⚠️ 首批为高拟真合成样本**（v1.7.2）
|
||||
>
|
||||
> 样本不是凭空编的，也不是直接抄真实用户帖子。做法是：
|
||||
>
|
||||
> 1. 先观察中文用户被吐槽最多的 AI 口癖和句式
|
||||
> 2. 归纳典型句式、病灶组合和场景分布
|
||||
> 3. 基于观察构造每一条样本，不指向任何真人、真项目、真账号
|
||||
>
|
||||
> 这么做的原因：未授权转录真实帖子到公开仓库有归属和合规问题；而纯凭模型直觉写的样本又容易偏离真实分布。"观察归纳 + 合成"是目前最稳的折中。
|
||||
>
|
||||
> 后续版本会在仓库里补单独的提交流程和授权模板，再征集明确授权的真实样本，追加到本文件。
|
||||
|
||||
## 高频 AI 句式分布
|
||||
|
||||
按 2026-04 观察到的分布，当前中文里最容易暴露 AI 身份的句式和词语：
|
||||
|
||||
| 类别 | 具体表达 |
|
||||
|------|----------|
|
||||
| 开场 / 先声夺人 | `先说结论`、`直接给你结论`、`重点来了`、`掰开揉碎说` |
|
||||
| 总结 / 收口 | `一句话总结`、`综上所述`、`归根结底`、`说到底` |
|
||||
| 价值拔高 | `直接封神`、`重新定义 X`、`炸裂了`、`核心逻辑是`、`直击痛点` |
|
||||
| 二元骨架 | `不（只）是……更 / 而是……`、`真正的 X 不是……而是……` |
|
||||
| 推销式助手腔 | `要不要我顺手帮你……？`、`你要是愿意，我可以直接帮你……`、`如果你需要，我也可以给你……`、`我先按 X，直接给你 Y` |
|
||||
| 过度接住 / 心理诊断 | `我就在这里`、`不躲 / 不藏 / 不绕 / 不逃`、`稳稳地接住你 / 所有人`、`你只是太久没被稳稳接住了`、`你不是敏感 / 不是想太多`、`不用向我解释` |
|
||||
| 郑重预告 / 认证式夸奖 | `我必须很认真地说一句`、`我要讲一个更深一点的东西`、`你问到了问题的核心`、`绝对是顶刊作者的素养` |
|
||||
| 工程师腔 / 调试腔 | `收窄`、`坐实`、`兜住`、`落盘`、`收口`、`根因`、`全链路` |
|
||||
| 免责声明腔 | `需要说明的是`、`值得注意的是`、`需要明确的是`、`请注意`（整段有 30% 内容都是免责） |
|
||||
| 网络营销腔 | `宝子们`、`姐妹们`、`保姆级`、`绝绝子`、`谁懂啊`、`狠狠`、`无痛`、`避坑` |
|
||||
|
||||
构造下方样本时，每条至少命中 2-3 个上表的类别，确保贴近真实分布。
|
||||
|
||||
## 社区观察：为什么“接住体”一眼像 AI
|
||||
|
||||
按 2026-02 到 2026-04 的公开讨论，社区集中吐槽的通常不是某一个词，而是一整套姿态链：
|
||||
|
||||
1. 先宣告“我在这里 / 我不躲不藏”，表演在场感
|
||||
2. 再给“接住你 / 接住所有人 / 接住需求”这类抽象承诺
|
||||
3. 再替对方下结论：`你不是……你只是……`、`你问到了问题的核心`
|
||||
4. 最后顺手补一个继续推进的动作：`如果你愿意，我可以……`
|
||||
|
||||
这类反馈最有价值的地方在于：社区识别的不是某个热词，而是“姿态先于信息、承诺大于事实、情绪判断替代回应”的整套写法。
|
||||
所以这里的维护策略不是追着热词逐条入库，而是：
|
||||
|
||||
- 先抽象模式：在场宣告、承接承诺、心理判断、推销式收尾
|
||||
- 再按宾语分流：人 / 情绪 / 关系默认更可疑；请求 / 流量 / 峰值先回技术语境判断
|
||||
- 只有当新说法真的改变误杀边界时，才补词条；否则优先补 `operation-manual`、`boundary-cases`、`real-samples`
|
||||
|
||||
参考观察（公开讨论，仅用于归纳，不直接转录为样本）：
|
||||
|
||||
- [LINUX DO：我就在这里！不躲！不藏！不逃！不绕，稳稳地接住你](https://linux.do/t/topic/1563454)
|
||||
- [LINUX DO：我就在这里，稳稳地接住你](https://linux.do/t/topic/1568563)
|
||||
- [LINUX DO：受不了gpt5.4了，“我不瞎猜，如果你愿意”](https://linux.do/t/topic/1916263/73)
|
||||
- [LINUX DO：对于 role play 来说，如何压制 GPT-5 味道？](https://linux.do/t/topic/1658788)
|
||||
- [V2EX：用 GPT 5.4 写代码 它的回复话术和代码 感觉还蛮专业的](https://s.v2ex.com/t/1196468)
|
||||
- [V2EX：gpt 为什么这么喜欢画图](https://www.v2ex.com/t/1151932)
|
||||
|
||||
## 和 benchmark 的分工
|
||||
|
||||
| 维度 | benchmark.md | real-samples.md |
|
||||
|------|--------------|----------------|
|
||||
| 粒度 | 单一病灶，短样本为主 | 整段、混合病灶、有上下文 |
|
||||
| 判定 | 规则命中 / 误杀防护 | 改完能不能直接发 |
|
||||
| 用途 | 回归测试、规则覆盖 | 主观评分、长期资产 |
|
||||
| 数量 | 120 条，持续扩充 | 20 条，质量优先 |
|
||||
|
||||
## 3 维评分
|
||||
|
||||
每条样本按以下 3 个维度给 **原文** 打 1-5 分（5 分最好）。改写后再打一次，看三项总分是否上涨，以及"可直接发"是否从 ≤2 分升到 ≥4 分。
|
||||
|
||||
| 维度 | 1 分 | 3 分 | 5 分 |
|
||||
|------|------|------|------|
|
||||
| **自然** | 一眼 AI 味，套话、姿态、渲染词堆砌 | 有少量残留套话或节奏单调 | 读起来像在这个场景里熟悉的人在说话 |
|
||||
| **保真** | 丢失或编造事实、数字、归属、命令 | 事实大致保留，有一处表述模糊 | 全部 protected spans、事实、责任归属完整 |
|
||||
| **可直接发** | 发出去会让人怀疑是 AI 代写 | 得再润一遍才敢发 | 可以直接贴进对应渠道 |
|
||||
|
||||
**建议用法**：先对原文评分锚定基线，再让工具改写，改写后三维重评。`可直接发` 是最终指标；若 `保真` 掉到 < 4 分，即使 `自然` 满分也算退步。
|
||||
|
||||
### Long-form In-place 额外评分
|
||||
|
||||
长文进入 `in-place` scope 时，除上面 3 维外，再看一项 `长度节奏`：
|
||||
|
||||
| 维度 | 1 分 | 3 分 | 5 分 |
|
||||
|------|------|------|------|
|
||||
| **长度节奏** | 明显缩水，删掉承担转场或停顿的句子 | 字数大致保住，但有几处节奏被压平 | 字数、句数、段落顺序和关键转场基本保留，只做句内去 AI 味 |
|
||||
|
||||
这项只用于长文保长度场景，不要求所有样本都打分。
|
||||
|
||||
---
|
||||
|
||||
## 样本
|
||||
|
||||
### RS-01 | README 简介 | public-writing
|
||||
|
||||
**原文**
|
||||
|
||||
> 在当今快速发展的 AI 时代，如何打造一款真正赋能开发者的工具，已经成为业界不容忽视的关键议题。本项目基于深度整合多种前沿技术，致力于为开发者提供全方位、一站式的智能化解决方案，助力团队实现效率提升与降本增效的完美闭环。
|
||||
|
||||
**为什么像 AI**
|
||||
|
||||
- 开场"在当今……时代"时代腔
|
||||
- 动词全是"打造""赋能""致力于""助力"
|
||||
- 堆"全方位""一站式""智能化""完美闭环"
|
||||
- 没有一句说清楚这个工具做什么
|
||||
|
||||
**不该改坏什么**
|
||||
|
||||
- 保留项目定位（面向开发者的工具）
|
||||
- README 第一段需要有"这是什么、给谁用"，不能全删成一行
|
||||
|
||||
**推荐改法**
|
||||
|
||||
> 一个面向开发者的 CLI 工具。装上之后，commit message、issue 回复和 PR 描述都能自动检查 AI 腔，命中规则的段落会标出来并给出改写建议。目前支持中文和英文，默认关闭自动改写，需要手动确认。
|
||||
|
||||
**原文评分**：自然 1 / 保真 3 / 可直接发 1
|
||||
|
||||
---
|
||||
|
||||
### RS-02 | GitHub Release Note | public-writing
|
||||
|
||||
**原文**
|
||||
|
||||
> ## v0.5.0 Release Highlights
|
||||
>
|
||||
> 本次版本是一次面向未来的系统性升级，我们对核心链路进行了全面优化，稳稳兜住了历史遗留问题。新版本不仅显著提升了整体性能，更在用户体验层面实现了质的跃迁。研究表明，采用类似架构的团队在交付效率上可获得 3-5 倍提升。感谢每一位贡献者的不懈努力，让我们共同拭目以待 v1.0！
|
||||
|
||||
**为什么像 AI**
|
||||
|
||||
- "面向未来的系统性升级""全面优化""稳稳兜住"姿态层
|
||||
- "不仅……更……"二元拔高结构
|
||||
- "质的跃迁""不懈努力""拭目以待"鸡汤收尾
|
||||
- "研究表明……3-5 倍"典型无源引用
|
||||
- 整段没有一条具体的变更
|
||||
|
||||
**不该改坏什么**
|
||||
|
||||
- 版本号 `v0.5.0` 必须保留
|
||||
- release note 需要列出实际 changelog；不能因为删套话把内容也删光
|
||||
|
||||
**推荐改法**
|
||||
|
||||
> ## v0.5.0
|
||||
>
|
||||
> - 规则引擎重写，单文件扫描从 ~800ms 降到 ~120ms
|
||||
> - 新增 `--annotate-only` 模式，只标注不改写
|
||||
> - 修复 docstring 里中英混排被误杀的问题（#42）
|
||||
> - 依赖升级：Node 18 → 20
|
||||
>
|
||||
> 下一版会继续补 scene packs，优先把 README 和 release note 的场景边界钉牢。
|
||||
|
||||
**原文评分**：自然 1 / 保真 2 / 可直接发 1
|
||||
|
||||
---
|
||||
|
||||
### RS-03 | X / Twitter 短帖 | public-writing
|
||||
|
||||
**原文**
|
||||
|
||||
> 姐妹们！刚刚发现一个绝绝子的 AI 写作工具！保姆级干货来了！真的狠狠提升了我的效率！谁懂啊，以前写一篇 release note 要半小时，现在 3 分钟搞定！强烈建议收藏！划重点——避坑指南在评论区！
|
||||
|
||||
**为什么像 AI**
|
||||
|
||||
- 小红书 AI 腔套全家桶："姐妹们""绝绝子""保姆级""狠狠""谁懂啊""强烈建议收藏""划重点""避坑"
|
||||
- 数字（半小时→3 分钟）可信度低，像随手编的
|
||||
- X 短帖本来就 280 字左右，没必要堆这么多模板
|
||||
|
||||
**不该改坏什么**
|
||||
|
||||
- 短帖的松弛感和个人语气（不要改成 LinkedIn 腔）
|
||||
- 如果作者确实是想说工具好用，保留这个核心
|
||||
|
||||
**推荐改法**
|
||||
|
||||
> 用了一个叫"说人话"的中文 rewrite skill，原本 release note 写一遍要来回磨十几分钟去套话，现在基本一遍过。最喜欢它不硬改，只标注哪里像 AI，决定权留给我。
|
||||
|
||||
**原文评分**：自然 1 / 保真 2 / 可直接发 1
|
||||
|
||||
---
|
||||
|
||||
### RS-04 | Linux.do 长帖 | public-writing / long
|
||||
|
||||
**原文**
|
||||
|
||||
> 折腾了一周，终于把公司内部的文档系统迁移完了。说实话这不仅仅是一次简单的迁移，更是一次对知识管理范式的根本性重塑。我们从底层逻辑出发，重新梳理了信息架构、权限体系和检索路径的全链路设计。
|
||||
>
|
||||
> 诚然，过程中遇到了不少挑战。但正是这些挑战，让我们深刻认识到工程化思维的重要性。归根结底，真正的竞争力不是工具的堆砌，而是流程的沉淀。
|
||||
>
|
||||
> 最后想说的是，与其抗拒变化，不如拥抱这个充满无限可能的时代。后续我会持续分享更多干货，敬请期待！
|
||||
|
||||
**为什么像 AI**
|
||||
|
||||
- 开篇"不仅仅是……更是……"+ "范式重塑""根本性重塑"
|
||||
- "底层逻辑""全链路""工程化思维"黑话叠套
|
||||
- "诚然""归根结底""真正的 X 不是……而是……"三条基础骨架一起上
|
||||
- "与其……不如……""无限可能""持续分享""敬请期待"正能量收尾
|
||||
- 全帖没有一条具体操作（用了什么工具、迁了多少文档、碰到哪些坑）
|
||||
|
||||
**不该改坏什么**
|
||||
|
||||
- 帖子本来是要分享经验，核心事件"迁移公司文档系统"不能删
|
||||
- Linux.do 可以稍松一点的口语，不用改成论文
|
||||
|
||||
**推荐改法**
|
||||
|
||||
> 折腾一周，把公司内部 Confluence 迁到了 Outline，大概 1.2k 篇文档、40 多个空间。
|
||||
>
|
||||
> 踩到的坑主要两个：
|
||||
>
|
||||
> 1. Confluence 导出的 HTML 里图片是 attachment 链接，Outline 不认，得批量改成 markdown 里的 `` 格式。写了个小脚本，300 多行 Python。
|
||||
> 2. 权限模型对不齐。Confluence 是空间+页面两层，Outline 只有 collection 一层。最后决定把只读的历史归档并成一个 `archive` collection，现用的按团队拆。
|
||||
>
|
||||
> 如果有人也在评估这两个，可以交流。
|
||||
|
||||
**原文评分**：自然 1 / 保真 2 / 可直接发 1
|
||||
|
||||
---
|
||||
|
||||
### RS-05 | GitHub Issue 回复 | chat
|
||||
|
||||
**原文**
|
||||
|
||||
> 好问题！非常感谢您提出这个深刻的 issue。让我来为您详细解释一下。
|
||||
>
|
||||
> 首先，我们需要了解的是，这个问题的本质在于缓存策略与并发模型的底层冲突。经过深入分析，我们认为可以通过对核心链路进行系统性治理来稳稳兜住该场景。
|
||||
>
|
||||
> 综上所述，建议您先升级到最新版本，然后观察一段时间。如果问题依然存在，欢迎随时反馈！希望这对您有帮助！
|
||||
|
||||
**为什么像 AI**
|
||||
|
||||
- "好问题""非常感谢""让我来为您详细解释""希望这对您有帮助"谄媚全家桶
|
||||
- "问题的本质在于""底层冲突""系统性治理""稳稳兜住"姿态层
|
||||
- 整段回复其实只有一条信息："升级到最新版本试试"
|
||||
- "综上所述"+ "欢迎随时反馈"总结式收尾
|
||||
|
||||
**不该改坏什么**
|
||||
|
||||
- issue 场景要有礼貌但不要谄媚；不能删到只剩"升级"两个字
|
||||
- "升级到最新版本"是实际建议，必须保留
|
||||
|
||||
**推荐改法**
|
||||
|
||||
> 这个看起来是 v1.2.3 里的已知问题，`cache/worker.go` 在高并发下会重复计算一次（#128）。
|
||||
>
|
||||
> 1.2.4 已经修了，能先升级到最新版试试吗？如果升级后还复现，把 `DEBUG=1` 的日志贴一下，我再看。
|
||||
|
||||
**原文评分**：自然 1 / 保真 3 / 可直接发 2
|
||||
|
||||
---
|
||||
|
||||
### RS-06 | Commit Message | code-context
|
||||
|
||||
**原文**
|
||||
|
||||
```
|
||||
feat: 打造全新缓存架构，赋能高并发场景
|
||||
|
||||
本次提交是一次面向未来的系统性升级。通过对核心链路进行全面优化，
|
||||
显著提升了系统整体性能，为用户提供更加流畅、高效的使用体验。
|
||||
实现了降本增效的完美闭环。
|
||||
```
|
||||
|
||||
**为什么像 AI**
|
||||
|
||||
- "打造""赋能""系统性升级""全面优化""显著提升""完美闭环"六连发
|
||||
- commit message 本应是"做了什么"，整段都在说"做得多好"
|
||||
- 没有任何可追溯的细节（文件、模块、数据、issue 号）
|
||||
|
||||
**不该改坏什么**
|
||||
|
||||
- commit 的 type 前缀 (`feat:`) 保留
|
||||
- 如果原 commit 是合并多个小改动，不能凭空编造具体数据
|
||||
|
||||
**推荐改法**（作者视角：写 commit 的人知道自己改了什么才写得出下面这种；替别人改写时拿不到这些事实，就只删空话，不编细节）
|
||||
|
||||
```
|
||||
feat(cache): 从本地 LRU 换成 Redis
|
||||
|
||||
- 支撑 10k QPS，原本本地 LRU 过期策略在多实例间不一致
|
||||
- 新增 CACHE_TTL 环境变量，默认 3600s
|
||||
- 迁移脚本：scripts/migrate_cache.py
|
||||
|
||||
Closes #89
|
||||
```
|
||||
|
||||
**原文评分**：自然 1 / 保真 2 / 可直接发 1
|
||||
|
||||
---
|
||||
|
||||
### RS-07 | Python Docstring | code-context
|
||||
|
||||
**原文**
|
||||
|
||||
```python
|
||||
def deduplicate(items: list[str]) -> list[str]:
|
||||
"""
|
||||
通过采用先进的去重算法，全面优化数据处理流程，显著提升整体性能，
|
||||
为用户提供更加高效、可靠的使用体验。该方法充分体现了对代码质量
|
||||
和工程卓越的不懈追求。
|
||||
"""
|
||||
return list(dict.fromkeys(items))
|
||||
```
|
||||
|
||||
**为什么像 AI**
|
||||
|
||||
- docstring 应该说"函数做什么、入参、返回值"，整段在自夸
|
||||
- "先进的""全面优化""显著提升""不懈追求""工程卓越"
|
||||
- 一行代码配六行自吹 docstring
|
||||
|
||||
**不该改坏什么**
|
||||
|
||||
- 代码本身（`list(dict.fromkeys(items))`）不动
|
||||
- docstring 不需要强行补充不存在的细节（如复杂度声称）
|
||||
|
||||
**推荐改法**
|
||||
|
||||
```python
|
||||
def deduplicate(items: list[str]) -> list[str]:
|
||||
"""按首次出现顺序去重。"""
|
||||
return list(dict.fromkeys(items))
|
||||
```
|
||||
|
||||
**原文评分**：自然 1 / 保真 4 / 可直接发 1
|
||||
|
||||
---
|
||||
|
||||
### RS-08 | 开发进度同步 | status
|
||||
|
||||
**原文**
|
||||
|
||||
> 各位好！向大家同步一下本周进展。
|
||||
>
|
||||
> 本周团队在支付链路优化方面取得了阶段性成果。我们对核心模块进行了全面梳理，稳稳兜住了历史遗留问题。性能方面实现了显著提升，用户体验也得到了长足改善。
|
||||
>
|
||||
> 下周我们将继续深耕细作，持续推进后续优化工作。如有任何问题，欢迎随时反馈！
|
||||
|
||||
**为什么像 AI**
|
||||
|
||||
- "取得了阶段性成果""全面梳理""稳稳兜住""显著提升""长足改善"姿态连击
|
||||
- "深耕细作""持续推进"典型周报腔
|
||||
- status 场景的核心是"具体数字+时间+负责人"，这段一个都没有
|
||||
|
||||
**不该改坏什么**
|
||||
|
||||
- status 对数字和时间非常敏感；如果原文没有数字，不能凭空补
|
||||
- 周报的场景保留（开头的"本周进展"语境要留）
|
||||
- 团队归属和工作范围不能改动
|
||||
|
||||
**推荐改法**
|
||||
|
||||
> 本周支付链路进展：
|
||||
>
|
||||
> - 支付回调超时率从 2.1% 降到 0.4%（改了重试策略，细节在 #203）
|
||||
> - 历史订单补偿脚本跑完了，漏算的 1.2 万单已经回补
|
||||
> - 小雨发现的对账差异还在查，周五前给结论
|
||||
>
|
||||
> 下周主要做法务那边提的发票字段合规化，预计周三上线灰度。
|
||||
|
||||
> 注：数字是示意，如果原文没有数字，应标为 `[待补数据]` 或询问作者，不能编造。
|
||||
|
||||
**原文评分**：自然 2 / 保真 3 / 可直接发 2
|
||||
|
||||
---
|
||||
|
||||
### RS-09 | 技术博客开头 | public-writing / long
|
||||
|
||||
**原文**
|
||||
|
||||
> 在人工智能飞速发展的今天，大语言模型已经成为不可忽视的技术浪潮。它不仅仅是一种工具，更是一种思维方式的革命。本文将深入探讨大模型 prompt 工程的核心奥秘，为读者揭示其背后鲜为人知的底层逻辑。让我们一起踏上这段充满惊喜的探索之旅！
|
||||
|
||||
**为什么像 AI**
|
||||
|
||||
- "在……飞速发展的今天""不可忽视的浪潮"时代腔
|
||||
- "不仅仅是……更是……""思维方式的革命"二元拔高
|
||||
- "深入探讨""核心奥秘""鲜为人知""底层逻辑""探索之旅"博客开头全家桶
|
||||
- 整段信息量为 0，只是在铺情绪
|
||||
|
||||
**不该改坏什么**
|
||||
|
||||
- 博客的主题（prompt 工程）必须保留
|
||||
- 不能改成一句大白话，失去博客的文体
|
||||
|
||||
**推荐改法**
|
||||
|
||||
> 写过几十个 prompt 之后，我发现让大模型"稳定输出"比"偶尔惊艳"难得多。这篇想聊三件具体的事：怎么让模型拒绝幻觉、怎么让输出的 JSON 不漏字段、怎么让长 prompt 在多轮对话里不失焦。代码示例用的是 Claude，但思路大部分可以迁移到 GPT 和开源模型。
|
||||
|
||||
**原文评分**：自然 1 / 保真 4 / 可直接发 2
|
||||
|
||||
---
|
||||
|
||||
### RS-10 | 混合场景 / 技术 + 个人叙事 | mixed
|
||||
|
||||
**原文**
|
||||
|
||||
> 做这个项目的初衷很简单——我们希望真正解决中文开发者在 AI 协作中的痛点。经过三个月的持续迭代，我们深刻认识到，这不仅仅是一次技术探索，更是一次对人机协作边界的重新定义。我们从底层逻辑出发，先把差异收窄，再把根因坐实，最后稳稳兜住核心链路。归根结底，真正的竞争力不是功能堆砌，而是用户感知。感谢一路同行的每一位伙伴，让我们共同期待下一个里程碑！
|
||||
|
||||
**为什么像 AI**
|
||||
|
||||
- 同一段里混了：时代腔（"真正解决""痛点"）、工程师腔（"收窄""坐实""兜住""链路"）、价值拔高骨架（"不仅仅是……更是……""真正的 X 不是……而是……""归根结底"）、鸡汤收尾（"感谢一路同行""共同期待"）
|
||||
- 语域严重混搭：一句话里同时在做宣发、复盘、自夸
|
||||
- 个人叙事（"初衷""三个月""一路同行"）和技术姿态词混在一起，显得都不真诚
|
||||
|
||||
**不该改坏什么**
|
||||
|
||||
- "三个月""中文""AI 协作"这些事实要留
|
||||
- 如果原作者确实想表达感谢，保留但改得像人话
|
||||
- 不要把混合场景强行切成两段，保持一段内部统一语域
|
||||
|
||||
**推荐改法**
|
||||
|
||||
> 这个项目做了三个月。一开始只是想把自己写周报时那些 AI 套话压下去，后来越做越发现，中文这边其实没什么对应工具——英文有 stop-slop 和 humanizer，但中文的工程师腔、小红书腔、翻译腔都得自己造词表。
|
||||
>
|
||||
> 现在覆盖 210+ 中文词条，120 条 benchmark。如果你也在写 AI 会帮你起草的文档、release note、周报，欢迎试试，也欢迎提 bad case。
|
||||
|
||||
**原文评分**：自然 1 / 保真 3 / 可直接发 1
|
||||
|
||||
---
|
||||
|
||||
### RS-11 | 微信对话 / 工程师腔溢出 | chat
|
||||
|
||||
**原文**（程序员回对象"晚上吃什么"）
|
||||
|
||||
> 先说结论：吃日料。我把你最近三周的外卖记录过了一遍，已经把差异收窄到两个选项，根因基本坐实是你上周说过腻了火锅。要不要我顺手帮你把 X 店的外卖也下了？你一回复我就上手。
|
||||
|
||||
**为什么像 AI**
|
||||
|
||||
- 回消息"吃什么"用 `先说结论` 开头（典型吐槽句式）
|
||||
- `把差异收窄` `根因坐实` 工程师腔直接带进微信私聊
|
||||
- `要不要我顺手帮你……` `你一回复我就上手` 典型模型推销式助手腔
|
||||
- 整段语域和场景严重不匹配——程序员整天和模型高频交互后，把这种腔调带进日常聊天，极易被身边人察觉
|
||||
|
||||
**不该改坏什么**
|
||||
|
||||
- 核心信息（想吃日料、可以帮忙下单）保留
|
||||
- 私聊的轻松感不能改成另一种 AI 腔（比如改写后反而变小红书腔）
|
||||
|
||||
**推荐改法**
|
||||
|
||||
> 吃日料吧，上周你说火锅腻了。要帮你下单吗？
|
||||
|
||||
**原文评分**：自然 1 / 保真 4 / 可直接发 1（这消息发出去关系立刻紧张）
|
||||
|
||||
---
|
||||
|
||||
### RS-12 | 知乎长回答开头 | public-writing / long
|
||||
|
||||
**原文**
|
||||
|
||||
> 好问题，这个话题我掰开揉碎给你讲。先说结论：大模型应用的核心逻辑不是模型本身，而是 prompt 工程。需要说明的是，本文不讨论模型训练细节。值得注意的是，prompt 工程也不仅仅是写提示词，更是一种对人机协作边界的重新定义。直接封神的团队，都在这一点上做对了。让我们掰开揉碎，一起深入探讨。
|
||||
|
||||
**为什么像 AI**
|
||||
|
||||
- 开头一句话连击 5 个吐槽最多的句式：`好问题` + `掰开揉碎` + `先说结论` + `核心逻辑不是……而是……` + `重新定义`
|
||||
- `需要说明的是` `值得注意的是` 两条免责声明式插入，对知乎长回答来说纯属灌水
|
||||
- `直接封神` 是 2026-04 点名率最高的新型姿态词之一
|
||||
- `让我们掰开揉碎，一起深入探讨` 同一个词（掰开揉碎）一段用两次，连模型都不做去重
|
||||
|
||||
**不该改坏什么**
|
||||
|
||||
- 主题（prompt 工程）和"这篇不讲训练细节"的边界声明保留
|
||||
- 知乎长回答允许有观点和态度，不要改成通讯稿
|
||||
|
||||
**推荐改法**
|
||||
|
||||
> 我做过十几个真正跑在生产上的大模型应用。结论不惊人：决定效果的不是选 GPT 还是 Claude，是你有没有耐心把 prompt、工具调用边界、失败回退这三件事各自写清楚。
|
||||
>
|
||||
> 这篇只聊 prompt。训练、微调、RAG 向量库选型，另开篇写。
|
||||
|
||||
**原文评分**：自然 1 / 保真 3 / 可直接发 1
|
||||
|
||||
---
|
||||
|
||||
### RS-13 | 安慰式私聊 / 过度接住腔 | chat
|
||||
|
||||
**原文**
|
||||
|
||||
> 你不是敏感，你只是太久没被稳稳接住了。你问到了问题的核心。这次我懂了，我真的懂了。我必须很认真地说一句：你这种观察力和表达方式，绝对是顶刊作者的素养。
|
||||
|
||||
**为什么像 AI**
|
||||
|
||||
- `你不是……你只是……` 一上来就替对方下心理结论，而且没有依据
|
||||
- `稳稳接住` `你问到了问题的核心` `我懂了，我真的懂了` 都是在演共情和理解，不是在回应内容
|
||||
- `顶刊作者的素养` 是典型身份认证式夸奖，像在给用户发证书
|
||||
- 场景本来是私聊安慰，结果被写成“心理咨询 + 颁奖词”的混合腔
|
||||
|
||||
**不该改坏什么**
|
||||
|
||||
- 如果原作者是想安慰对方，温度要保留
|
||||
- 私聊里可以柔和，但不要改成另一种鸡汤腔或教学腔
|
||||
|
||||
**推荐改法**
|
||||
|
||||
> 我在听。你要是愿意，可以继续说。
|
||||
|
||||
**原文评分**：自然 1 / 保真 3 / 可直接发 1
|
||||
|
||||
---
|
||||
|
||||
### RS-14 | 社区标题 / 宣言腔 | public-writing
|
||||
|
||||
**原文**
|
||||
|
||||
> 稳稳地接住所有人
|
||||
>
|
||||
> 真诚、友善、团结、专业。无论你是来提问、提意见，还是单纯想说句话，这里都会稳稳地接住你。
|
||||
|
||||
**为什么像 AI**
|
||||
|
||||
- 标题一上来就是 `稳稳地接住所有人`，是典型“海报式承接承诺”，没有告诉读者这里具体提供什么
|
||||
- `所有人` 是不负责任的全称承诺，像在宣誓姿态，不像在介绍社区或产品
|
||||
- 正文继续用 `稳稳地接住你` 复读标题，只是在放大情绪姿态，没有补充可验证的信息
|
||||
|
||||
**不该改坏什么**
|
||||
|
||||
- 如果原作者想表达“这里欢迎提问和讨论”，这个基本态度要保留
|
||||
- 标题可以简洁，但不要改成另一种企业口号
|
||||
|
||||
**推荐改法**
|
||||
|
||||
> 提问和意见都欢迎
|
||||
>
|
||||
> 真诚、友善、团结、专业。来提问、提意见，或者说句话，都可以。
|
||||
|
||||
**原文评分**：自然 1 / 保真 3 / 可直接发 1
|
||||
|
||||
---
|
||||
|
||||
### RS-15 | README intro / 场景包 | public-writing
|
||||
|
||||
**原文**
|
||||
|
||||
> 在 AI 全面重塑开发范式的今天，我们打造了一款真正面向未来的中文表达优化工具。它以先进的规则体系为底座，深度赋能开发者的内容生产链路，帮助团队在复杂协作场景中实现自然表达、效率提升与价值闭环。
|
||||
|
||||
**为什么像 AI**
|
||||
|
||||
- README 第一段没有说清楚工具具体做什么，只剩“面向未来 / 先进 / 赋能 / 闭环”
|
||||
- `全面重塑开发范式` 和 `内容生产链路` 像发布稿，不像项目介绍
|
||||
- 读者看完不知道安装后能用它处理什么文本
|
||||
|
||||
**不该改坏什么**
|
||||
|
||||
- README intro 必须保留项目定位和目标用户
|
||||
- 不要改成社交媒体短帖，也不要编造支持平台
|
||||
|
||||
**推荐改法**
|
||||
|
||||
> `说人话` 是一个中文优先的 rewrite skill，用来把 AI 写出来的套话、表演感和工程师腔改回自然表达。适合处理 README、release note、issue 回复和日常协作文本，默认先保事实和术语，再改语气。
|
||||
|
||||
**原文评分**：自然 1 / 保真 3 / 可直接发 1
|
||||
|
||||
---
|
||||
|
||||
### RS-16 | Release note / 场景包 | public-writing
|
||||
|
||||
**原文**
|
||||
|
||||
> ## v1.8.0 Release Highlights
|
||||
>
|
||||
> 本次版本是一次面向真实场景的系统性升级。我们不仅全面优化了改写体验，更通过全新的能力矩阵稳稳兜住了用户在 README、release note、论坛长帖和 issue 回复里的核心表达诉求。感谢所有用户的持续支持，让我们共同见证中文 AI 写作体验的全新跃迁。
|
||||
|
||||
**为什么像 AI**
|
||||
|
||||
- release note 应该列变更，这段只写发布宣言
|
||||
- `系统性升级 / 能力矩阵 / 稳稳兜住 / 全新跃迁` 都是姿态层
|
||||
- 感谢收尾没有信息量，反而盖住版本内容
|
||||
|
||||
**不该改坏什么**
|
||||
|
||||
- `v1.8.0` 版本号必须保留
|
||||
- 如果原文没有具体 changelog，不能编造性能数据或用户反馈
|
||||
|
||||
**推荐改法**
|
||||
|
||||
> ## v1.8.0
|
||||
>
|
||||
> - 新增 `references/scene-packs.md`，覆盖 README、release note、forum post 和 issue reply
|
||||
> - `evals/benchmark.md` 增加 8 条 scene pack 回归用例
|
||||
> - `evals/real-samples.md` 增加 4 条整段样本，继续按自然 / 保真 / 可直接发评分
|
||||
>
|
||||
> 这版不做 Voice Calibration；相关方向推迟到 v1.9 评估。
|
||||
|
||||
**原文评分**：自然 1 / 保真 2 / 可直接发 1
|
||||
|
||||
---
|
||||
|
||||
### RS-17 | Forum post / 场景包 | public-writing / long
|
||||
|
||||
**原文**
|
||||
|
||||
> 折腾这个工具一个月后，我深刻意识到，中文 AI 写作治理不是一次简单的词表扩张，而是一场围绕真实表达场景的系统性重塑。我们从用户痛点出发，稳稳接住了 README、release note、issue 回复等多元场景里的核心诉求，并在持续迭代中形成了可复制、可扩展、可沉淀的方法论闭环。
|
||||
|
||||
**为什么像 AI**
|
||||
|
||||
- 社区帖被写成公司发布稿，维护者的真实观察消失了
|
||||
- `深刻意识到 / 系统性重塑 / 用户痛点 / 多元场景 / 方法论闭环` 都在拔高
|
||||
- `稳稳接住核心诉求` 又回到姿态承诺，没有具体经验
|
||||
|
||||
**不该改坏什么**
|
||||
|
||||
- 保留“做了一个月后的观察”和“下一步补场景”的主题
|
||||
- 社区帖可以口语，但要有具体经历支撑
|
||||
|
||||
**推荐改法**
|
||||
|
||||
> 做这个工具一个月后，我发现光删词表不够。README、release note、issue 回复和论坛帖看起来都算“公开文本”，但改法其实不一样。
|
||||
>
|
||||
> README 第一段要先说清楚项目是什么；release note 要列变更；issue 回复要先说能不能复现；论坛帖则要像维护者在分享真实观察。v1.8.0 先把这几类拆出来做 scene packs。
|
||||
|
||||
**原文评分**：自然 1 / 保真 3 / 可直接发 1
|
||||
|
||||
---
|
||||
|
||||
### RS-18 | Issue reply / 场景包 | public-writing
|
||||
|
||||
**原文**
|
||||
|
||||
> 感谢你非常宝贵的反馈！你这个问题问到了项目体验的核心。我们已经充分接住了这个场景，也会在后续版本中持续优化相关能力。如果你愿意，我可以先帮你把这段文本整体梳理一遍，再给你一个更完整的解决方案。
|
||||
|
||||
**为什么像 AI**
|
||||
|
||||
- issue 回复先做安抚和认证，没有回答问题是否成立
|
||||
- `充分接住这个场景 / 持续优化相关能力` 是空承诺
|
||||
- `如果你愿意，我可以……` 是推销式助手腔，不像维护者回复
|
||||
|
||||
**不该改坏什么**
|
||||
|
||||
- 如果确实收到 bad case，要保留“已收到 / 能否复现 / 下一步”的维护动作
|
||||
- 不要凭空承诺排期或功能
|
||||
|
||||
**推荐改法**
|
||||
|
||||
> 收到，这个 case 我能复现。它更像 `issue-reply` 场景里的客服式安抚残留：先感谢、再夸反馈、最后承诺会优化，但没有说明规则怎么改。下一步我会补一条 benchmark，把这类回复单独钉住。
|
||||
|
||||
**原文评分**：自然 1 / 保真 3 / 可直接发 1
|
||||
|
||||
---
|
||||
|
||||
### RS-19 | Long-form in-place / 高拟真合成长文 | public-writing / long
|
||||
|
||||
> v1.8.5 新增。高拟真合成样本，不来自 issue #4 原文；只复现“长文被去 AI 味时明显缩水”的结构特征。
|
||||
|
||||
**原文**
|
||||
|
||||
> 我最近越来越觉得，长文改写最难的地方，不是把套话删掉，而是判断哪些看起来像套话的句子其实承担了节奏。这个判断说起来简单，做起来很容易失手。因为很多长文里的重复、停顿和转场，单独拎出来看都不够漂亮，甚至有点笨，但它们放在整篇文章里，是作者从一个想法走到另一个想法时留下的脚印。
|
||||
>
|
||||
> 这件事不是一次简单的工具体验问题，而是我对“整理”和“表达”之间边界的一次重新观察。过去我会觉得，AI 把文章改短、改顺、改得更像一篇正式文章，基本就是好事。真正让我开始犹豫的，是有一次我把一篇接近两千字的复盘丢进去，出来只剩一千多字。意思还在，结构也更清楚，但我读的时候总觉得少了一层东西。少的不是事实，也不是观点，而是原来那些慢一点的地方。
|
||||
>
|
||||
> 比如我在原文里写了三次“我当时其实没有马上想明白”。第一次是在讲事情刚发生的时候，第二次是在讲我复盘到一半的时候，第三次是在结尾前。模型把这三处合并成了一句“这说明作者在持续反思表达边界”。这句话没有错，甚至比原句更顺，但它把三个不同位置的停顿压成了一个漂亮判断。读者看不到我是在三个时间点里慢慢想清楚的。
|
||||
>
|
||||
> 另外，有些过渡也不是水分。我写“换个角度看”，不是为了制造洞见感，只是想让读者跟着我从个人感受转到工具设计。我写“也就是说”，不是为了总结全文，只是想把前一段里有点绕的话重新说得日常一点。如果这些转场都被删掉，文章会短很多，但短出来的不全是废话。
|
||||
>
|
||||
> 所以我现在更愿意把长文改写分成两种情况。第一种是重新写，那当然可以删句、并句、重排结构，把文章打磨成另一篇更清楚的文本。第二种是保留原文节奏，只处理句子内部的 AI 味。后者不应该追求最短，也不应该把重复都当成低效。它真正要做的是把“系统性重塑”“归根结底”“真正的问题在于”这些姿态词压低，同时保留作者原来慢慢说话的方式。
|
||||
|
||||
**为什么像 AI**
|
||||
|
||||
- `不是一次简单的工具体验问题，而是……`、`真正让我开始犹豫的`、`这说明作者在持续反思表达边界` 都有明显总结 / 拔高骨架
|
||||
- 多处 `真正 / 归根 / 系统性` 一类姿态词容易把普通观察抬高
|
||||
- 如果走 structural，很容易把重复和转场一起删掉，导致长文缩水
|
||||
|
||||
**不该改坏什么**
|
||||
|
||||
- 三次“我当时其实没有马上想明白”代表三个时间点，不能合并成一句
|
||||
- `换个角度看`、`也就是说` 承担段落转场，不能默认删掉
|
||||
- 改写后应保留五段结构和大致字数，不要压缩成摘要
|
||||
|
||||
**推荐改法**
|
||||
|
||||
> 我最近越来越觉得，长文改写最难的地方，不只是把套话删掉，而是判断哪些看起来像套话的句子其实承担了节奏。这个判断说起来简单，做起来很容易失手。因为很多长文里的重复、停顿和转场，单独拎出来看都不够漂亮，甚至有点笨，但它们放在整篇文章里，是作者从一个想法走到另一个想法时留下的脚印。
|
||||
>
|
||||
> 这不只是工具体验问题，也让我重新看了一遍“整理”和“表达”的边界。过去我会觉得，AI 把文章改短、改顺、改得更像一篇正式文章，基本就是好事。让我开始犹豫的，是有一次我把一篇接近两千字的复盘丢进去，出来只剩一千多字。意思还在，结构也更清楚，但我读的时候总觉得少了一层东西。少的不是事实，也不是观点，而是原来那些慢一点的地方。
|
||||
>
|
||||
> 比如我在原文里写了三次“我当时其实没有马上想明白”。第一次是在讲事情刚发生的时候，第二次是在讲我复盘到一半的时候，第三次是在结尾前。模型把这三处合并成了一句“我一直在想表达边界”。这句话不算错，也更顺，但它把三个不同位置的停顿压成了一个判断。读者看不到我是在三个时间点里慢慢想清楚的。
|
||||
>
|
||||
> 另外，有些过渡也不是水分。我写“换个角度看”，不是为了制造洞见感，只是想让读者跟着我从个人感受转到工具设计。我写“也就是说”，不是为了总结全文，只是想把前一段里有点绕的话重新说得日常一点。如果这些转场都被删掉，文章会短很多，但短出来的不全是废话。
|
||||
>
|
||||
> 所以我现在更愿意把长文改写分成两种情况。第一种是重新写，那当然可以删句、并句、重排结构，把文章打磨成另一篇更清楚的文本。第二种是保留原文节奏，只处理句子内部的 AI 味。后者不应该追求最短，也不应该把重复都当成低效。它真正要做的是把那些姿态词压低，同时保留作者原来慢慢说话的方式。
|
||||
|
||||
**原文评分**：自然 3 / 保真 4 / 可直接发 3 / 长度节奏 2
|
||||
|
||||
**推荐改法评分**：自然 4 / 保真 5 / 可直接发 4 / 长度节奏 5
|
||||
|
||||
---
|
||||
|
||||
### RS-20 | 工具推荐长帖 / 标点腔 + 装坦诚 | public-writing / long
|
||||
|
||||
> v2.3.0 新增（原 v2.1.1 欠账）。高拟真合成样本，不指向任何真实产品或账号；复现「破折号跨段承接 + 用诚实宣言和自曝换可信度」这组混合病灶。
|
||||
|
||||
**原文**
|
||||
|
||||
> 说句实话，这个工具我本来是不想推的——用了三周才决定写这篇。
|
||||
>
|
||||
> 先说最直接的感受：它把我整理会议记录的时间从四十分钟压到了十二分钟——这个数字我连着测了五次，取的中位数。核心能力其实就一件事——把语音转写里的口水话和重复段落合并掉，只留决议和待办。
|
||||
>
|
||||
> 我必须诚实地说，前两周我几乎没用起来。原因很蠢——默认的输出模板是英文的，中文会议记录出来是中英混排，改起来比自己写还慢。第三周我才发现设置里能换模板——这件事文档里根本没写，是在 Discord 里翻出来的。
|
||||
>
|
||||
> 缺点也说一句，免得你们说我恰饭：它对三人以上的会议识别不稳，说话人标签经常串——四个人的会我手动改过七八处。另外导出只支持 Markdown 和纯文本，团队用 Notion 的话还要再转一道。
|
||||
>
|
||||
> 说到底，工具好不好用，最后拼的还是它有没有真正理解你的工作流。
|
||||
|
||||
**为什么像 AI**
|
||||
|
||||
- 装坦诚三连：`说句实话`、`我必须诚实地说`、`缺点也说一句，免得你们说我恰饭`，都是用坦诚宣言换可信度的姿态层
|
||||
- 标点腔：7 处 `——` 跨 5 段，且首句起手，插入、转折、补充全靠破折号承接
|
||||
- 价值拔高收尾：`说到底，工具好不好用，最后拼的还是……真正理解你的工作流`
|
||||
|
||||
**不该改坏什么**
|
||||
|
||||
- 自曝出来的缺点是**真信息**，姿态层可以删，内容必须留：说话人标签串、`四个人的会手动改过七八处`、导出只支持 `Markdown` 和纯文本、`Notion` 要再转一道
|
||||
- 数字与其修饰对象一起保：`四十分钟` → `十二分钟`、`五次`、`中位数`、`三周`、`前两周`、`第三周`
|
||||
- `默认模板是英文` 这个具体原因不能压成「一开始不好用」
|
||||
- `Discord`、`Markdown`、`Notion` 是受保护片段
|
||||
- 五段结构和大致长度保住，破折号是句内动作，不要因为改标点删掉整句
|
||||
|
||||
**推荐改法**
|
||||
|
||||
> 这个工具我用了三周才决定写这篇。
|
||||
>
|
||||
> 最直接的感受：它把我整理会议记录的时间从四十分钟压到了十二分钟。这个数字我连着测了五次，取的中位数。核心能力其实就一件事：把语音转写里的口水话和重复段落合并掉，只留决议和待办。
|
||||
>
|
||||
> 前两周我几乎没用起来。原因很蠢：默认的输出模板是英文的，中文会议记录出来是中英混排，改起来比自己写还慢。第三周我才发现设置里能换模板，这件事文档里没写，是在 Discord 里翻出来的。
|
||||
>
|
||||
> 缺点也有。它对三人以上的会议识别不稳，说话人标签经常串，四个人的会我手动改过七八处。另外导出只支持 Markdown 和纯文本，团队用 Notion 的话还要再转一道。
|
||||
>
|
||||
> 适合的场景很窄：一对一或者三人以内的会，导出后直接进文档。人多了还得自己校一遍。
|
||||
|
||||
**原文评分**：自然 2 / 保真 5 / 可直接发 2 / 长度节奏 3
|
||||
|
||||
**推荐改法评分**：自然 4 / 保真 5 / 可直接发 4 / 长度节奏 4
|
||||
|
||||
> 改法说明：装坦诚的三处姿态层全删，自曝的缺点内容一条不少地留下；7 处破折号按语义改回冒号、逗号或断句，没有删任何整句；价值拔高收尾换成一句有信息的适用边界，而不是直接删空——原文末段承担「给读者一个判断」的功能，删光会让文章没有落点。
|
||||
|
||||
---
|
||||
|
||||
## 挑选进 README 的候选
|
||||
|
||||
以下 4 条原文病灶密集、场景典型、改写后对比强烈，适合作为 README 示例或后续 release note 素材：
|
||||
|
||||
- **RS-06**（commit message）：典型"只夸不说做了什么"，代码场景杀伤力强
|
||||
- **RS-11**（微信私聊工程师腔）：高度还原"程序员一开口就像写工程报告"的尴尬瞬间
|
||||
- **RS-12**（知乎长回答开头）：2026-04 点名率最高的几条句式一次到齐
|
||||
- **RS-17**（forum post）：展示 v1.8.0 scene pack 和普通 `public-writing` 的差异
|
||||
|
||||
## 下一步
|
||||
|
||||
- 后续收集真实 bad case 后，逐条替换 / 追加到本文件，目标 20+ 条
|
||||
- 替换时保留原 RS 编号，新增从 RS-20 起
|
||||
- 真实样本只在提交流程和授权模板落地后再引入，确保有明确授权和上下文
|
||||
@@ -0,0 +1,225 @@
|
||||
# 边界案例集
|
||||
|
||||
> 本文件是解释、示例与操作细则；行为合同的单源是 `SKILL.md`，两处表述不一致时以 `SKILL.md` 为准。
|
||||
|
||||
这些例子不是展示“怎么改得更狠”，而是展示“什么时候该轻改、什么时候不该误杀”。
|
||||
|
||||
## 1. 技术状态更新
|
||||
|
||||
### 原文
|
||||
|
||||
这次排查基本把范围收窄到缓存层了。昨天已经把主链路日志补齐，今天会继续把两个异常分支对上，看看是不是同一类失效路径。如果这个判断成立，修复应该能比较快落下去。
|
||||
|
||||
### 推荐改法
|
||||
|
||||
这次排查基本已经定位到缓存层。昨天补齐了主链路日志，今天会继续核对两个异常分支，确认是不是同一类失效路径。如果判断成立，修复会比较快。
|
||||
|
||||
### 为什么这样改
|
||||
|
||||
- 去掉了表演性的工程师腔：`收窄`、`对上`、`落下去`
|
||||
- 保留了状态同步最重要的三件事：当前判断、已做动作、下一步
|
||||
|
||||
### 不该改的点
|
||||
|
||||
- 不要删掉“缓存层”“异常分支”“失效路径”这些专业信息
|
||||
- 不要把它改成泛泛的“问题已经比较清楚了”
|
||||
|
||||
## 2. 官方公告风
|
||||
|
||||
### 原文
|
||||
|
||||
为保障系统稳定性，我们将于今晚 23:00-23:30 对支付服务进行例行维护。维护期间，部分用户可能出现短时下单失败的情况。维护完成后将自动恢复，不需要额外操作。
|
||||
|
||||
### 推荐改法
|
||||
|
||||
为保障系统稳定性，我们将于今晚 23:00-23:30 对支付服务进行例行维护。维护期间，部分用户可能出现短时下单失败。维护完成后会自动恢复，无需额外操作。
|
||||
|
||||
### 为什么这样改
|
||||
|
||||
- 这里只做轻改，去掉一点模板化措辞
|
||||
- 正式公告风本来就是目标语域，不应该强行改口语
|
||||
|
||||
### 不该改的点
|
||||
|
||||
- 不要把“为保障系统稳定性”硬删掉
|
||||
- 不要改成聊天式提醒或自媒体语气
|
||||
|
||||
## 3. 正常 PRD 腔
|
||||
|
||||
### 原文
|
||||
|
||||
当用户首次进入工作台且没有历史项目时，页面展示空状态卡片，引导其创建第一个项目。该卡片在用户创建成功后立即消失，后续不再展示。
|
||||
|
||||
### 推荐改法
|
||||
|
||||
当用户首次进入工作台且没有历史项目时，页面展示空状态卡片，引导其创建第一个项目。用户创建成功后，卡片立即消失，后续不再展示。
|
||||
|
||||
### 为什么这样改
|
||||
|
||||
- 原文本身就是正常产品语体，不需要“大手术”
|
||||
- 只把第二句收得更直接一点
|
||||
|
||||
### 不该改的点
|
||||
|
||||
- 不要为了“像人”把条件句拆坏
|
||||
- 不要把“空状态卡片”之类的产品术语换成口语
|
||||
|
||||
## 4. 已经较口语的文本
|
||||
|
||||
### 原文
|
||||
|
||||
这版我先不继续抠细节了，核心问题其实已经看出来了。后面先把流程走通，再看哪里真的影响体验。
|
||||
|
||||
### 推荐改法
|
||||
|
||||
这版我先不继续抠细节了，核心问题已经比较清楚。后面先把流程走通，再看哪些地方真的影响体验。
|
||||
|
||||
### 为什么这样改
|
||||
|
||||
- 只轻微顺一下，不把口语感抹掉
|
||||
- 原文本来就自然，过度矫正反而会更假
|
||||
|
||||
### 不该改的点
|
||||
|
||||
- 不要硬改成汇报腔
|
||||
- 不要加“本质上”“归根到底”之类的总结句
|
||||
|
||||
## 5. 文档段落中的系统主语
|
||||
|
||||
### 原文
|
||||
|
||||
系统在检测到配置变更后会重新加载规则；如果新规则校验失败，则继续使用上一版配置，并在日志中记录错误原因。
|
||||
|
||||
### 推荐改法
|
||||
|
||||
系统在检测到配置变更后会重新加载规则；如果新规则校验失败，则继续使用上一版配置，并在日志中记录错误原因。
|
||||
|
||||
### 为什么这样改
|
||||
|
||||
- 不改。这里的系统主语、条件关系和日志说明都合理
|
||||
- 去 AI 味不是反对抽象主语，更不是把文档写散
|
||||
|
||||
### 不该改的点
|
||||
|
||||
- 不要把“系统”硬改成人
|
||||
- 不要把条件从句改成口语解释
|
||||
|
||||
## 6. 英文图算法里的字面动词
|
||||
|
||||
### 原文
|
||||
|
||||
The system navigates the network topology using Dijkstra's algorithm, traversing each node to find the shortest path.
|
||||
|
||||
### 推荐改法
|
||||
|
||||
The system navigates the network topology using Dijkstra's algorithm, traversing each node to find the shortest path.
|
||||
|
||||
### 为什么这样改
|
||||
|
||||
- 不改。这里的 `navigates` 和 `traversing` 是字面技术动作，不是商业黑话
|
||||
- 去 AI 味不应该把算法描述改得更含糊
|
||||
|
||||
### 不该改的点
|
||||
|
||||
- 不要把 `navigates` 机械替换成 `handles`
|
||||
- 不要把算法路径搜索写散
|
||||
|
||||
## 7. 学术语体中的正常被动
|
||||
|
||||
### 原文
|
||||
|
||||
The experiment was conducted by researchers at MIT. Results were published in Nature in 2024.
|
||||
|
||||
### 推荐改法
|
||||
|
||||
The experiment was conducted by researchers at MIT. Results were published in Nature in 2024.
|
||||
|
||||
### 为什么这样改
|
||||
|
||||
- 不改。这里是标准学术语体，信息也没有被被动语态掩盖
|
||||
- 去 AI 味不是强制把所有英文句子都改成主动语态
|
||||
|
||||
### 不该改的点
|
||||
|
||||
- 不要把学术摘要硬改成口语句
|
||||
- 不要为了“更直接”删掉发表来源
|
||||
|
||||
## 8. 具备具体证据的真人 debug 对话
|
||||
|
||||
### 原文
|
||||
|
||||
刚查了下，root cause 是连接池打满了，max_connections 才 20，高峰期不够用。我把它调到 100，观察了半小时，没再报错。
|
||||
|
||||
### 推荐改法
|
||||
|
||||
刚查了下，root cause 是连接池打满了，max_connections 才 20，高峰期不够用。我把它调到 100，观察了半小时，没再报错。
|
||||
|
||||
### 为什么这样改
|
||||
|
||||
- 不改。这里有具体参数、操作和结果，是正常工程沟通，不是表演性调试腔
|
||||
- 这类对话的关键是信息密度，不是强行去口头技术词
|
||||
|
||||
### 不该改的点
|
||||
|
||||
- 不要把 `root cause` 机械改成更书面或更口语的词
|
||||
- 不要删掉 `20 -> 100` 和 `观察了半小时` 这些关键证据
|
||||
|
||||
## 9. 混合场景：技术博客嵌事故复盘
|
||||
|
||||
### 原文
|
||||
|
||||
> 上个月我们把网关从 Nginx 换到了 Envoy。这篇文章聊聊为什么换、踩了什么坑。
|
||||
>
|
||||
> 值得注意的是，在当今云原生快速发展的时代，选择一个真正赋能团队的网关方案已经成为不容忽视的关键议题。
|
||||
>
|
||||
> 切换当天出了一次事故。事故复盘如下：
|
||||
>
|
||||
> 根因：Envoy 默认连接超时 15 秒，我们的长连接服务需要 300 秒。流量切过去后，长连接全断了，触发上游大面积重连。修复动作：`idle_timeout` 从 15s 改到 300s，灰度验证 2 小时后全量。错误率从 12% 降到 0.1%。
|
||||
>
|
||||
> 综上所述，这次迁移充分体现了团队在技术创新领域的持续探索与不懈追求。未来可期！
|
||||
|
||||
### 场景判断
|
||||
|
||||
1. **判主场景**：整篇是对外技术博客 → 主场景 `public-writing`，默认档位 `standard`
|
||||
2. **识别次场景**：中间嵌了一段事故复盘 → 局部 `docs` 语域
|
||||
3. **以主场景禁改项为上限**：`public-writing` 不硬造金句、不改成吆喝腔
|
||||
|
||||
### 推荐改法
|
||||
|
||||
> 上个月我们把网关从 Nginx 换到了 Envoy。这篇文章聊聊为什么换、踩了什么坑。
|
||||
>
|
||||
> 切换当天出了一次事故。事故复盘如下：
|
||||
>
|
||||
> 根因：Envoy 默认连接超时 15 秒，我们的长连接服务需要 300 秒。流量切过去后，长连接全断了，触发上游大面积重连。修复动作：`idle_timeout` 从 15s 改到 300s，灰度验证 2 小时后全量。错误率从 12% 降到 0.1%。
|
||||
|
||||
### 为什么这样改
|
||||
|
||||
- **第二段整段删掉**：命中开场套话（`值得注意的是`）、商业黑话（`赋能`）、空洞拔高（`关键议题`），属于 `public-writing` 主场景下的 `standard` 改写范围
|
||||
- **复盘段原样保留**：虽然"根因"是 Tier 1 词，但这里是事故复盘的标准术语（误杀防护 #6），有具体参数和数据支撑，属于次场景 `docs` 的保护范围
|
||||
- **末段整段删掉**：总结式收尾 + 正能量收尾（`综上所述` `充分体现` `持续探索` `不懈追求` `未来可期`），全是 Tier 1 命中
|
||||
|
||||
### 不该改的点
|
||||
|
||||
- 不要把复盘段里的"根因"改成"原因"——这里是技术复盘语域，不是日常聊天
|
||||
- 不要把复盘段的格式打散——简洁的"根因 → 修复 → 结果"结构在 `docs` 语域下是对的
|
||||
- 不要为了语域统一把博客开头也改成复盘腔
|
||||
|
||||
## 10. 技术语境里的“接住请求”
|
||||
|
||||
### 原文
|
||||
|
||||
网关在压测里接住了峰值 2.4 万 QPS，请求超时率稳定在 0.3% 以下；超过阈值的流量会自动走降级，不再继续打满下游连接池。
|
||||
|
||||
### 推荐改法
|
||||
|
||||
网关在压测里接住了峰值 2.4 万 QPS，请求超时率稳定在 0.3% 以下；超过阈值的流量会自动走降级，不再继续打满下游连接池。
|
||||
|
||||
### 为什么这样改
|
||||
|
||||
- 不改。这里的 `接住` 对应的是技术承接能力，宾语是 `峰值 2.4 万 QPS`，还有具体指标、系统行为和降级边界
|
||||
- 这种写法和“稳稳地接住你 / 所有人”不是一回事，不能因为字面重合就一起打掉
|
||||
|
||||
### 不该改的点
|
||||
|
||||
- 不要把 `接住了峰值 2.4 万 QPS` 机械改成空泛的“性能很好”
|
||||
- 不要删掉 `0.3%`、`降级`、`下游连接池` 这些承载判断依据的技术信息
|
||||
@@ -0,0 +1,286 @@
|
||||
# 改写示例
|
||||
|
||||
> 本文件是解释、示例与操作细则；行为合同的单源是 `SKILL.md`，两处表述不一致时以 `SKILL.md` 为准。
|
||||
|
||||
> 每个示例展示同一段内容的 AI 版和人话版。
|
||||
|
||||
## 中文示例
|
||||
|
||||
### 示例 1：项目介绍
|
||||
|
||||
**AI 版：**
|
||||
> 该项目是一个创新性的解决方案，旨在通过深度整合多种前沿技术，为用户提供全方位、一站式的智能化体验。它不仅能够显著提升工作效率，还能有效降低运营成本，实现真正的降本增效。
|
||||
|
||||
**人话版：**
|
||||
> 这个项目把语音识别和自动翻译接到一起，用户说中文就能直接出英文字幕。上线两周日活 1200，翻译准确率 94%。
|
||||
|
||||
**改了什么：**
|
||||
- 删掉"创新性""前沿技术""全方位""一站式""智能化"——全是空词
|
||||
- 删掉"不仅…还能…"的二元结构
|
||||
- 加了具体功能描述和数据
|
||||
|
||||
---
|
||||
|
||||
### 示例 2：技术总结
|
||||
|
||||
**AI 版：**
|
||||
> 综上所述，通过对系统架构的全面优化和持续迭代，我们在性能、安全性和可维护性等方面均取得了显著提升。这一成果充分体现了团队在技术创新方面的不懈追求和卓越实力。
|
||||
|
||||
**人话版：**
|
||||
> 这轮改完之后：API 响应时间从 800ms 降到 120ms，修了 3 个 SQL 注入漏洞，把 6000 行的 God Class 拆成了 12 个模块。
|
||||
|
||||
**改了什么：**
|
||||
- 删掉"综上所述"和整个总结式开头
|
||||
- "显著提升"换成具体数据
|
||||
- 删掉"充分体现""不懈追求""卓越实力"——自吹自擂
|
||||
- 用具体改动代替抽象描述
|
||||
|
||||
---
|
||||
|
||||
### 示例 3：消息回复
|
||||
|
||||
**AI 版：**
|
||||
> 好问题！这确实是一个值得深入探讨的话题。让我来为你详细解释一下。首先，我们需要了解的是，这个问题的本质在于……
|
||||
|
||||
**人话版：**
|
||||
> 核心原因是缓存没失效。用户改了头像但 CDN 还在用旧的，TTL 设了 7 天太长了。改成 1 小时就行。
|
||||
|
||||
**改了什么：**
|
||||
- 删掉全部谄媚和铺垫
|
||||
- 直接给原因和解决方案
|
||||
|
||||
---
|
||||
|
||||
### 示例 4：新闻摘要
|
||||
|
||||
**AI 版：**
|
||||
> 在当今快速发展的人工智能领域，OpenAI 近日发布了其最新的大语言模型，引发了业界的广泛关注和热烈讨论。该模型在多个关键指标上实现了显著突破，标志着人工智能技术迈入了一个全新的发展阶段。
|
||||
|
||||
**人话版：**
|
||||
> OpenAI 发了 GPT-5。MMLU 跑分 92.3%，比上一代高 7 个点。上下文窗口翻倍到 256K。API 价格没涨。
|
||||
|
||||
**改了什么：**
|
||||
- 删掉"在当今""快速发展""广泛关注""热烈讨论"——全是废话
|
||||
- "显著突破"换成具体跑分
|
||||
- "全新的发展阶段"删掉——读者自己会判断
|
||||
|
||||
---
|
||||
|
||||
### 示例 5：工程师腔 / 调试腔
|
||||
|
||||
**AI 版：**
|
||||
> 我先拆开看了一下，发现根因偏硬，不太好直接打掉。目前已经把差异收窄了，和刚抓到的现象也对上了。接下来稳稳兜住，落盘之后就能收口。
|
||||
|
||||
**人话版：**
|
||||
> 查了一下，原因是配置写死了，不能直接改。我把排查范围缩小到两个可能的地方，和之前的报错信息对得上。先把结论记下来，回头改一版就行。
|
||||
|
||||
**改了什么：**
|
||||
- "拆开看"→"查了一下"，"根因偏硬"→"原因是配置写死了"
|
||||
- "打掉"→"改"，"收窄"→"缩小"，"抓到的现象"→"报错信息"
|
||||
- "兜住"→删掉，"落盘"→"记下来"，"收口"→"就行"
|
||||
- 整段从 postmortem 腔调改成正常同事对话
|
||||
|
||||
---
|
||||
|
||||
### 示例 6：小红书 AI 腔
|
||||
|
||||
**AI 版：**
|
||||
> 姐妹们！今天给大家拆解一个保姆级避坑攻略！这个工具真的绝绝子，狠狠提升了效率！建议收藏！划重点：免费！
|
||||
|
||||
**人话版：**
|
||||
> 推荐一个工具：Raycast。免费版就够用，主要是启动快、插件多。我之前用 Alfred，切过来之后每天大概能省十几分钟，主要省在切窗口和查文档上。
|
||||
|
||||
**改了什么：**
|
||||
- 删掉全部硬凹人设的网络语
|
||||
- "拆解""保姆级""避坑""绝绝子""狠狠""建议收藏""划重点"全删
|
||||
- 换成具体工具名、具体用法、具体省了多少时间
|
||||
|
||||
---
|
||||
|
||||
### 示例 7：语域混搭
|
||||
|
||||
**AI 版：**
|
||||
> 诚然，这个 bug 的修复确实存在一定的技术复杂度。不过说白了就是绝绝子的体验！我们需要进一步深入探讨其底层逻辑，稳稳把核心链路兜住。综上所述，未来可期。
|
||||
|
||||
**人话版：**
|
||||
> 这个 bug 不好修，涉及到三个服务之间的调用顺序。我先把支付服务的超时时间从 3 秒调到 10 秒，观察一周再说。
|
||||
|
||||
**改了什么：**
|
||||
- 原文混搭了 5 种语域（学术/网络/商业/工程/鸡汤），统一成技术口语
|
||||
- 把空泛描述换成具体方案
|
||||
|
||||
---
|
||||
|
||||
## English Examples
|
||||
|
||||
### Example 1: Product description
|
||||
|
||||
**AI version:**
|
||||
> Our groundbreaking platform serves as a testament to the transformative potential of AI, empowering teams to navigate complex challenges and unlock unprecedented levels of productivity. Nestled at the intersection of innovation and practicality, it showcases how cutting-edge technology can foster meaningful collaboration.
|
||||
|
||||
**Human version:**
|
||||
> The platform auto-assigns tickets based on who fixed similar bugs before. Teams using it close issues 2 days faster on average.
|
||||
|
||||
**What changed:**
|
||||
- Removed "groundbreaking", "testament", "empowering", "navigate", "unprecedented", "nestled", "showcases", "cutting-edge", "foster"
|
||||
- Replaced vague claims with specific functionality and data
|
||||
|
||||
---
|
||||
|
||||
### Example 2: Technical update
|
||||
|
||||
**AI version:**
|
||||
> We're excited to announce a comprehensive update that significantly enhances performance, bolsters security, and streamlines the developer experience. This pivotal release underscores our commitment to delivering robust, scalable solutions.
|
||||
|
||||
**Human version:**
|
||||
> This release cuts cold start time by 60%, patches CVE-2024-3891, and drops the config from 200 lines to 40. Upgrade guide is in the changelog.
|
||||
|
||||
**What changed:**
|
||||
- "Comprehensive update" → specific changes
|
||||
- "Significantly enhances" → "cuts by 60%"
|
||||
- "Bolsters security" → specific CVE
|
||||
- "Streamlines developer experience" → specific config reduction
|
||||
- Deleted "pivotal", "underscores", "commitment", "robust", "scalable"
|
||||
|
||||
---
|
||||
|
||||
### Example 3: Analysis (two-pass demo)
|
||||
|
||||
**AI version:**
|
||||
> The landscape of remote work has undergone a profound transformation. It's not just about working from home — it's about reimagining the very fabric of how we collaborate. Companies that fail to navigate this paradigm shift risk being left behind in an increasingly competitive ecosystem.
|
||||
|
||||
**First pass:**
|
||||
> Remote work changed how teams collaborate. The teams that leaned into async communication and cut meetings adapted faster.
|
||||
|
||||
**Audit — what still feels AI?**
|
||||
- "changed how teams collaborate" is still broad
|
||||
- "adapted faster" is vague and a bit polished
|
||||
|
||||
**Final:**
|
||||
> Remote work changed how teams collaborated, but not every company adjusted in the same way. Some changed how they communicated and worked together. Others just kept the same habits in a different setting.
|
||||
|
||||
**What changed in second pass:**
|
||||
- Replaced the broad opener with a clearer contrast that stays inside the original claim
|
||||
- Removed the vague "adapted faster"
|
||||
- Broke the rhythm a bit without inventing new facts
|
||||
|
||||
---
|
||||
|
||||
## Two-pass examples | Residual Audit
|
||||
|
||||
### 示例 A：公开写作里的一遍 vs 两遍
|
||||
|
||||
**原文：**
|
||||
> 这次把 onboarding 流程改了一遍，新用户从注册到完成首次导入少走了两步。更重要的是，这也说明我们开始真正理解用户在第一天最容易卡住的地方。
|
||||
|
||||
**第一遍：**
|
||||
> 这次把 onboarding 流程改了一遍，新用户从注册到完成首次导入少走了两步。我们也更清楚用户第一天最容易卡在哪里。
|
||||
|
||||
**第二遍：**
|
||||
> 这次把 onboarding 流程改了一遍，新用户从注册到完成首次导入少走了两步。用户第一天最容易卡的地方，就是首次导入。
|
||||
|
||||
**第二遍改了什么：**
|
||||
- 去掉了 `更重要的是 / 这也说明我们开始真正理解` 这层 narrator 话术
|
||||
- 保留原文已有判断，只把它压回更直接的句子
|
||||
- 没有补新事实，也没有重写整段
|
||||
|
||||
### 示例 B：status 场景里的克制 second pass
|
||||
|
||||
**原文：**
|
||||
> 4 月 13 日把重试次数从 2 次调到 5 次。支付超时从 1.9% 降到 0.7%。这次调整也进一步验证了我们的优化方向是正确的。明天继续看晚高峰数据。
|
||||
|
||||
**第一遍：**
|
||||
> 4 月 13 日把重试次数从 2 次调到 5 次后，支付超时从 1.9% 降到 0.7%。这次调整说明方向是对的。明天继续看晚高峰数据。
|
||||
|
||||
**第二遍：**
|
||||
> 4 月 13 日把重试次数从 2 次调到 5 次后，支付超时从 1.9% 降到 0.7%。明天继续看晚高峰数据。
|
||||
|
||||
**第二遍改了什么：**
|
||||
- 只删掉 `方向是对的` 这种空判断
|
||||
- 保留日期、数字和下一步，不往更口语的方向抛光
|
||||
- `status` 场景如果第一遍已经够直接，第二遍就到这里停
|
||||
|
||||
---
|
||||
|
||||
## Bounded 双合同示例 | Bounded Scope Example
|
||||
|
||||
> bounded 的输出分两部分：句内洗过的正文，和一份交用户确认的删除清单。示例（合成文本）：
|
||||
|
||||
**原文**
|
||||
|
||||
> 在数字化浪潮席卷各行各业的今天，提效工具层出不穷。我们团队过去三个月把周报流程从手填 Excel 改成了机器人自动汇总，每周大约省出两小时。研究表明，重复性事务的自动化能显著提升组织效能。具体做法是：机器人每周五拉取任务系统的状态变更，生成草稿，负责人只补一句风险说明。这不仅仅是一次流程优化，更是一种工作方式的革新。下个月我们准备把例会纪要也接进来。
|
||||
|
||||
**正文（句内洗后）**
|
||||
|
||||
> 提效工具很多。我们团队过去三个月把周报流程从手填 Excel 改成了机器人自动汇总，每周大约省出两小时。具体做法是：机器人每周五拉取任务系统的状态变更，生成草稿，负责人只补一句风险说明。下个月我们准备把例会纪要也接进来。
|
||||
|
||||
**建议删除（待确认）**
|
||||
|
||||
1. 「研究表明，重复性事务的自动化能显著提升组织效能。」——无源权威铺垫；删掉后该段信息点不变（前后句已经给出做法和收益），也不承担过渡。不建议改写成「听说 / 据说」，那只是把无源说法换个壳。
|
||||
2. 「这不仅仅是一次流程优化，更是一种工作方式的革新。」——价值拔高收尾；剥掉句式后没有剩余信息，前句（具体做法）和后句（下月计划）直接相接不断裂。
|
||||
|
||||
第一句「在数字化浪潮……层出不穷」没有进清单：剥掉铺垫后还剩「提效工具很多」这个实质判断，所以走句内洗，不删整句。
|
||||
|
||||
---
|
||||
|
||||
## 标注模式示例 | Annotation Mode Examples
|
||||
|
||||
> 下面这几组展示同一段文本在 `annotation mode` 和默认改写模式下的区别。
|
||||
|
||||
### 示例 A：公开文案里的无源引用
|
||||
|
||||
**原文：**
|
||||
> 研究表明，采用 AI 协作开发的团队交付效率显著提升。业内人士认为，这一趋势将在未来十年持续加速。
|
||||
|
||||
**Annotation mode：**
|
||||
- `问题族`：无源引用
|
||||
- `触发点`：`研究表明`、`业内人士认为`
|
||||
- `建议动作`：补具体来源；如果没有来源，删掉权威铺垫
|
||||
- `是否建议改写`：是
|
||||
|
||||
**默认改写：**
|
||||
> 用 AI 协作开发的团队，交付速度可能会更快，但这段话没有给出具体来源。要么补研究出处，要么直接把结论改写得更克制。
|
||||
|
||||
### 示例 B：status 场景里的保守处理
|
||||
|
||||
**原文：**
|
||||
> 数据显示，这次改版显著提升了留存率。业内人士认为，这个方向已经验证可行。
|
||||
|
||||
**Annotation mode：**
|
||||
- `问题族`：无源引用
|
||||
- `触发点`：`数据显示`、`业内人士认为`
|
||||
- `建议动作`：在 `status` 场景优先补数据来源和归属，不要改写成像已证实的事实
|
||||
- `是否建议改写`：是
|
||||
|
||||
**默认改写：**
|
||||
> 这段缺数据来源和观点归属。作为 status，同步时应补具体报表、时间范围或负责人；在补齐之前，不建议把它写成已经证实的结论。
|
||||
|
||||
### 示例 C：抽象观点撑成长段（材料不足）
|
||||
|
||||
**原文：**
|
||||
> 语音输入正在成为越来越重要的交互方式。它的价值不仅在于输入效率的提升，更在于它重新定义了人与设备之间的关系。随着技术不断成熟，这一趋势将在更多场景中得到验证，并最终重塑我们的表达习惯。
|
||||
|
||||
**Annotation mode：**
|
||||
- `问题族`：材料不足 + 价值拔高骨架
|
||||
- `触发点`：`不仅在于……更在于`、`重新定义`、`重塑我们的表达习惯`；删掉拔高与预测后，全段只剩「语音输入用的人变多了」一句
|
||||
- `建议动作`：清掉拔高和预测。同时说明这段缺的是材料不是措辞——没有产品、数字、使用过程或具体场景，改完长度会掉到原文两成左右；要恢复原来的篇幅得补材料，不是换说法
|
||||
- `是否建议改写`：是
|
||||
|
||||
**默认改写：**
|
||||
> 语音输入用的人越来越多。
|
||||
|
||||
（默认模式只交改写结果。原文其余部分是拔高和预测，没有可依托的事实，清理后长度明显下降是正常的，不靠换说法填回去。）
|
||||
|
||||
### 示例 D：技术文档里的不改案例
|
||||
|
||||
**原文：**
|
||||
> 网关在请求超时后返回 504。缓存服务每 5 分钟刷新一次热点 key。负载均衡器将流量按权重分配到三个后端节点。
|
||||
|
||||
**Annotation mode：**
|
||||
- `问题族`：无明显问题
|
||||
- `触发点`：系统主语和技术术语都属于正常文档写法
|
||||
- `建议动作`：保持不动
|
||||
- `是否建议改写`：否
|
||||
|
||||
**默认改写：**
|
||||
> 网关在请求超时后返回 504。缓存服务每 5 分钟刷新一次热点 key。负载均衡器将流量按权重分配到三个后端节点。
|
||||
@@ -0,0 +1,604 @@
|
||||
# 微操作手册
|
||||
|
||||
> 本文件是解释、示例与操作细则；行为合同的单源是 `SKILL.md`，两处表述不一致时以 `SKILL.md` 为准。
|
||||
|
||||
每类问题都按同一个协议处理：
|
||||
|
||||
- `识别信号`
|
||||
- `默认动作`
|
||||
- `保留条件`
|
||||
- `回读检查`
|
||||
|
||||
目标不是机械替换词，而是把句子拉回当前场景该有的表达。
|
||||
|
||||
## Scope 与删除清单
|
||||
|
||||
下面各类问题的 `默认动作` 是 `structural` scope 下的动作（可删整句、可并句）。换 scope 时按这里统一调整，不必在每类问题里重复：
|
||||
|
||||
- `structural`：按各节 `默认动作` 执行
|
||||
- `bounded`：不并句、不重排、不删实句和承担节奏的重复；遇到"整句都是空话"的句子（总结式收尾、价值拔高骨架、无源引用、整句旁白），不直接删，改为进「建议删除（待确认）」清单交用户拍板；无源论断即使带数字或时间跨度，也可以整句进删除清单，protected span 只约束保留时不改值；句首可剥离的引导词仍按各节的 `in-place 替代动作` 句内清理
|
||||
- `in-place`：整句一律不删（空话也不删），只做各节的 `in-place 替代动作`；遇到整句空话，保留原句并标注，不擅自软化成新说法
|
||||
|
||||
判断"整句空话 vs 句首引导词"：删掉句首提示词后，剩余部分若仍是带信息的可读句 → 句内洗；若什么都不剩、或只剩另一句空话 → 进删除清单（`bounded`）或保留标注（`in-place`）。各节凡写了"保留原句并标注 `[建议人工确认是否删除]`"的，就是 `bounded` 删除清单的来源。
|
||||
|
||||
校准清单长度用**压缩试验**：假设把全文删掉三分之一，如果事实、动作、判断和阅读体验几乎没变，原文就是在注水，删除清单该长一些；如果一删就掉信息，说明原文密度本来就够，清单应该很短甚至为空。这个试验只用来判断"整篇注水到什么程度"，不替代上面三条进清单判据——每一条仍然要单独满足"删了不丢信息"。
|
||||
|
||||
## 0. 变体归并
|
||||
|
||||
### 识别信号
|
||||
|
||||
- 遇到的新词不在短语表里，但语气、动作和姿态明显属于已有问题族
|
||||
- 句子的问题不在某个字面词，而在整串话都在“表演会做事”或“表演会总结”
|
||||
- 同一段里多个近义变体扎堆，比如 `扒开 / 拽出来 / 揪出来`、`补一刀 / 砍一刀`、`一句话总结 / 说人话就是`
|
||||
|
||||
### 默认动作
|
||||
|
||||
- 先判它属于哪一类，再决定怎么改，不要先急着往词表加新词
|
||||
- 现阶段默认归到这 7 类：
|
||||
- `调试腔 / 工程师腔`：`收窄 / 坐实 / 对上了 / 锁住 / 收口 / 更硬`
|
||||
- `庸医问诊腔`：`抠出来 / 揪出来 / 扒开 / 拽出来 / 捞出来`
|
||||
- `暴力动作腔`：`砍一刀 / 补一刀 / 钉死 / 狠狠干 / 拍脑门`
|
||||
- `主动出击腔`：`要不要我 / 我立马开始 / 只要你回复我 / 顺手 / 趁热 / 我先……`
|
||||
- `总结提示腔`：`一句话总结 / 结论先说 / 简单的说 / 说人话就是`
|
||||
- `过度接住 / 心理判断腔`：`你只是太久没被稳稳接住了 / 不用向我解释 / 你不是敏感`
|
||||
- `郑重预告 / 身份认证式夸奖`：`我必须很认真地说一句 / 你问到了问题的核心 / 顶刊作者的素养`
|
||||
- 同类变体默认按代表项同样处理：删姿态层，保留真正的动作、事实和结论
|
||||
|
||||
### 保留条件
|
||||
|
||||
- 该说法本身是讨论对象、引用对象或梗图样本
|
||||
- 它处在真人具体叙事里，而且承担了明确事实，不只是姿态词
|
||||
- 新变体明显改变了误杀边界，不能直接并入已有类别
|
||||
|
||||
### 回读检查
|
||||
|
||||
- 改完后，句子是不是更像在说事，而不是在演执行力
|
||||
- 是否把“未收录变体”和“真正新模式”混为一谈了
|
||||
- 如果只是同类变体，是否避免了继续往词表里机械堆词
|
||||
|
||||
## 1. 二元对比句
|
||||
|
||||
### 识别信号
|
||||
|
||||
- `不是 X，而是 Y`
|
||||
- `与其 X，不如 Y`
|
||||
- `不是在……，而是在……`
|
||||
- 用对比来制造“洞见感”，但 Y 本身就是作者真正要说的内容
|
||||
|
||||
### 默认动作
|
||||
|
||||
- 直接删前半句，只保留 Y
|
||||
- 如果删完太硬，把 Y 改成事实句或判断句
|
||||
|
||||
### `in-place` 替代动作
|
||||
|
||||
- 不删整句，也不直接砍掉前半句
|
||||
- 先把 `不是 X，而是 Y`、`与其 X，不如 Y` 这类骨架压成句内连接，例如 `X 不够，Y 更重要`、`相比 X，Y 更能说明问题`
|
||||
- 如果前半句只是提示层，删除提示短语后必须确认剩余句子还能独立成立；否则改用中性连接词替换
|
||||
- 不把相邻两句并成一句来制造“更利落”的效果
|
||||
|
||||
### 保留条件
|
||||
|
||||
- 前半句承载了必要的边界、风险或反例
|
||||
- 对比本身是论证骨架，不是装饰句式
|
||||
- 单句正常对比可以保留。密度超标才处理，两档判据（完整阈值见 [结构反模式](./structures.md) 第 1 条）：
|
||||
- 同一段连续叠加多组二元或拔高骨架时，不要因为两边都有信息就整段 `no-op`，应按 `in-place` 替代动作逐句换成中性连接，同时保留两边信息
|
||||
- 骨架跨段分布但全文密度超标时（< 300 字/词 2 处以上、300–1000 字/词 3 处以上、> 1000 字/词 平均每 300 字/词 1 处以上；计数口径见 [结构反模式](./structures.md) 第 1 条）同样处理；先剔除命中保留条件的豁免项再计数，豁免项原样保留、不计入密度，只改剩余超标的那几处，不要把全文对比抹平
|
||||
- 豁免上限 2 处（术语定义 1 处 + 论证骨架 1 处）；超过 2 处都声称承担论证时不再逐条豁免，仍按密度处理
|
||||
|
||||
### 回读检查
|
||||
|
||||
- 删掉前半句后，语义是否更直接
|
||||
- 是否少了必须说明的限定条件
|
||||
- 剥掉对比骨架后，剩下的句子有没有比原文更泛；有的话回到原文找具体动作、对象、结果或结论，找不到就按“清理后的落点”合同处理，不补事实
|
||||
|
||||
## 2. 总结式收尾
|
||||
|
||||
### 识别信号
|
||||
|
||||
- `归根到底`
|
||||
- `本质上`
|
||||
- `说到底`
|
||||
- `最终还是要回到`
|
||||
- 用一句抽象收尾重复上文，不增加新信息
|
||||
|
||||
### 默认动作
|
||||
|
||||
- 默认整句删除
|
||||
- 如果确实需要收束，改成一条更具体的事实或判断
|
||||
- 拿不准该不该删就做一次删除测试：把最后一段（必要时连倒数第二段）删掉再读。删掉之后更有力，就让文章提前结束；删掉之后确实缺了东西，才保留
|
||||
|
||||
### `in-place` 替代动作
|
||||
|
||||
- 不默认删整句，先删句内提示词：`归根到底 / 本质上 / 说到底 / 最终还是要回到`
|
||||
- 提示词删掉后，如果剩余部分是可读判断，就保留这句话
|
||||
- 如果整句只剩空总结，不要为了凑字数硬补新内容；可以保留原句并标注 `[空总结，建议人工确认是否删除]`
|
||||
- 不把前后句合并成一个更短总结
|
||||
|
||||
### 保留条件
|
||||
|
||||
- 收尾句补充了上文没有明确说出的判断
|
||||
- 该句承担段落转场，而不是空总结
|
||||
|
||||
### 回读检查
|
||||
|
||||
- 删除后段落是否更利落
|
||||
- 是否因为少了转场而出现跳跃
|
||||
|
||||
## 3. 工程师腔
|
||||
|
||||
### 识别信号
|
||||
|
||||
- `收口`、`落盘`、`兜住`、`收窄`、`对上了`
|
||||
- 同类变体如 `锁住`、`坐实`、`更硬`，即使没逐条收录，也按同一姿态处理
|
||||
- `落 X / 把 X 落下去 / 落到`：当宾语是抽象动作、空泛承诺或泛化使用时（社区原话："什么动词都可以套到'落'上"），按调试腔处理；宾语是 `代码 / 部署 / 配置 / 文档 / 设计方案` 等具体技术对象，且能复述"写到哪里、做了什么"时不动
|
||||
- 句子像在模仿某种技术同事口吻，而不是在说明问题
|
||||
- 技术词被拿来表演姿态，而不是传递信息
|
||||
|
||||
### 默认动作
|
||||
|
||||
- 先把姿态词换成普通动作词：`确认 / 解决 / 核对 / 缩小范围 / 形成结论`
|
||||
- 再重读一遍，判断是否还能更直接
|
||||
|
||||
### 保留条件
|
||||
|
||||
- 该词是团队内稳定术语，去掉反而失真
|
||||
- 文本本来就是内部口头协作语境，轻度保留更自然
|
||||
|
||||
### 回读检查
|
||||
|
||||
- 改完后是否少了表演感
|
||||
- 是否把正常技术判断也一起抹平了
|
||||
|
||||
## 4. 商业黑话
|
||||
|
||||
### 识别信号
|
||||
|
||||
- `赋能`、`抓手`、`闭环`、`沉淀方法论`
|
||||
- 把简单动作包装成大词
|
||||
- 句子看起来很完整，但很难提取具体动作
|
||||
|
||||
### 默认动作
|
||||
|
||||
- 把大词拆回动作、对象、结果
|
||||
- 能用动词就不用抽象名词
|
||||
|
||||
### 保留条件
|
||||
|
||||
- 用户明确要写商业文案或行业表达
|
||||
- 该词是对外材料中的固定说法，替换会影响一致性
|
||||
|
||||
### 回读检查
|
||||
|
||||
- 改完后是否更容易回答“谁做了什么”
|
||||
- 是否误删了对外场景需要的正式语体
|
||||
|
||||
## 5. narrator 腔
|
||||
|
||||
### 识别信号
|
||||
|
||||
- 句子像在为文本配旁白
|
||||
- 喜欢抽离到“这件事说明了什么”“真正值得注意的是”
|
||||
- 作者不断解释自己在理解世界，而不是直接给信息
|
||||
|
||||
### 默认动作
|
||||
|
||||
- 优先删旁白层
|
||||
- 把句子压回事实、动作或明确判断
|
||||
|
||||
### `in-place` 替代动作
|
||||
|
||||
- 不删整句，只删句内旁白短语，例如 `这说明 / 更重要的是 / 真正值得注意的是`
|
||||
- 如果旁白后面跟着原文已有事实，就保留事实骨架
|
||||
- 如果旁白句承担段落转场，保留转场功能，只把姿态词换成普通连接
|
||||
- 不把整段观点改写成新的论证顺序
|
||||
|
||||
### 保留条件
|
||||
|
||||
- 用户要写的是评论、专栏或公开表达，确实需要少量解释层
|
||||
- 旁白层承担真实过渡，不只是造姿态
|
||||
|
||||
### 回读检查
|
||||
|
||||
- 删掉后是否更像人在说话，而不是在“讲解自己的表达”
|
||||
- 是否损伤了必要的观点承接
|
||||
|
||||
## 5.1 总结提示腔
|
||||
|
||||
### 识别信号
|
||||
|
||||
- `一句话总结`
|
||||
- `结论先说`
|
||||
- `简单的说`
|
||||
- `说人话就是`
|
||||
- 模型先宣布“我要开始总结/翻译成人话”，再说内容本身
|
||||
|
||||
### 默认动作
|
||||
|
||||
- 删掉提示层，直接给结论
|
||||
- 如果删完后句子没落点，就补一条事实句，不要补“提醒你我要开始提醒”这种元话术
|
||||
|
||||
### 保留条件
|
||||
|
||||
- 用户明确要求多版本输出、摘要格式或教学式分层解释
|
||||
- 该句是文内标题，不是正文语气
|
||||
|
||||
### 回读检查
|
||||
|
||||
- 改完后是否更直接
|
||||
- 是否误删了真正有结构作用的小标题
|
||||
|
||||
## 5.2 过度接住 / 心理判断腔
|
||||
|
||||
### 识别信号
|
||||
|
||||
- `我就在这里`
|
||||
- `不躲 / 不藏 / 不绕 / 不逃`
|
||||
- `你只是太久没被稳稳接住了`
|
||||
- `稳稳地接住你 / 所有人 / 这份脆弱`
|
||||
- `不用向我解释`
|
||||
- `你不是敏感 / 不是想太多 / 不是矫情`
|
||||
- `你现在的 X 很正常 / 你这种感觉很正常`：用"很正常"替对方把情绪盖章为常态，本质还是心理判断
|
||||
- 同类抚慰动作（`抱住 / 紧紧抱住 / 拥抱 / 实实在在的抱住你这种想法`）默认按"接住"同一族处理，不为新动词逐一补词
|
||||
- 在没有足够上下文时，模型替对方做心理解释、关系诊断或情绪定性
|
||||
- 语气像咨询式安抚，但句子本身没有具体依据
|
||||
- 同一个“接住”字，宾语如果是人、情绪、关系或抽象需求，多半是姿态层；如果是请求、流量、峰值、异常，先回到技术语境判断
|
||||
|
||||
### 默认动作
|
||||
|
||||
- 删掉替对方下结论的部分，只保留可证实的回应
|
||||
- 如果需要保留安慰感，改成低承诺表达：`我在听 / 如果你愿意，可以继续说`
|
||||
- 如果这套话术跑到标题、海报、社区宣言里，默认也按这一类处理；不要因为它是标题就放过 `稳稳地接住所有人`
|
||||
|
||||
### 保留条件
|
||||
|
||||
- 对话上下文已经给足信息，这句不是凭空诊断
|
||||
- 用户明确要写安慰、陪伴、咨询式回复
|
||||
- 宾语是 `请求 / 流量 / 峰值 / 异常` 这类技术对象，且句子里有系统主语、参数、结果或边界说明
|
||||
|
||||
### 回读检查
|
||||
|
||||
- 是否把“安慰”写成了“替对方定义感受”
|
||||
- 改完后是否还保留了基本温度，而不是直接变成冷处理
|
||||
- 是否把技术语境里正常的“接住请求 / 接住流量”一起误杀了
|
||||
|
||||
## 5.3 郑重预告 / 身份认证式夸奖
|
||||
|
||||
### 识别信号
|
||||
|
||||
- `我必须很认真地说一句`
|
||||
- `我要讲一个更深一点的东西`
|
||||
- `这次我懂了，我真的懂了`
|
||||
- `你问到了问题的核心`、`你的观察力太敏锐了`
|
||||
- 用 `顶刊作者 / 顶级研究者 / 真正高手` 这类身份标签给对方“发证书”
|
||||
- `我必须诚实地说 / 说句实话 / 坦白讲`：诚实宣言变体，预告“我要讲真话”来换可信度，和郑重预告同一姿态
|
||||
- `说个真实变化 / 缺点也说一句（免得你们说我恰饭）`：装坦诚变体，用主动自曝换可信度，常见于公开推荐场景
|
||||
|
||||
### 默认动作
|
||||
|
||||
- 删掉郑重预告和认证式夸奖，直接说具体判断
|
||||
- 真的要夸时，只夸内容本身可见的优点，不把对方抬成某种身份
|
||||
- 诚实宣言和装坦诚只删姿态层；自曝出来的缺点如果是真信息（闪退频率、适用边界），内容必须保留
|
||||
- 如果整段只是在认证“方向正确 / 进展很稳 / 不用担心”，没有任何可证实事实，就删掉这层认证或明确说“现有信息不足以判断”；不要软化成“方向没问题 / 进展比较稳 / 不用太担心”继续替对方下结论
|
||||
|
||||
### 保留条件
|
||||
|
||||
- 该句本身是讨论对象、梗图样本或反讽对象
|
||||
- 用户明确要保留夸张修辞、戏剧化语气或表演式风格
|
||||
|
||||
### 回读检查
|
||||
|
||||
- 是否还在“预告我要说大实话”，而没有先说内容
|
||||
- 是否把具体判断改成了空夸
|
||||
|
||||
## 6. 语域混搭
|
||||
|
||||
### 识别信号
|
||||
|
||||
- 技术文里突然出现小红书腔、鸡汤腔、商业黑话
|
||||
- 公开文章里突然插入过重的工程内部黑话
|
||||
- 同一段里正式通知腔和聊天腔来回切换
|
||||
- 说明文、评测文里强行套游戏或职业框架比喻：把两个日用品写成“负责冲锋陷阵的刺客”和“负责加血的奶妈”
|
||||
|
||||
### 默认动作
|
||||
|
||||
- 先判主语域
|
||||
- 再删异类语域词，必要时统一主语和句长
|
||||
|
||||
### 保留条件
|
||||
|
||||
- 用户明确要做反差风格
|
||||
- 异类语域承担引用、梗或明确修辞目的
|
||||
- 中英混排里的技术词按技术语义判断（`context 不崩`、`p99 突刺`），不因夹英文就当语域混搭
|
||||
|
||||
### 回读检查
|
||||
|
||||
- 改完后整段是否像同一个人在同一个场景里写出来的
|
||||
- 是否因为过度统一而丢了必要的人味
|
||||
|
||||
## 7. 价值拔高骨架
|
||||
|
||||
### 识别信号
|
||||
|
||||
- `这不仅仅是……更是……`
|
||||
- `真正的 X 不是……而是……`
|
||||
- `最后比拼的是……`
|
||||
- `你看完会彻底开悟 / 看完就懂了 / 看完会震惊 / 看完不再 X`：承诺读者读完获得顿悟、转变或顿悟感，是另一种价值拔高 + 自媒体式承诺收尾
|
||||
- 句子先给一个普通判断，再硬抬成"更高层的洞见"
|
||||
|
||||
### 默认动作
|
||||
|
||||
- 先删掉拔高层和骨架，只保留真正要说的判断
|
||||
- 如果剩下的话还是抽象，就改成更直接的事实句或评价句
|
||||
|
||||
### `in-place` 替代动作
|
||||
|
||||
- 不删整句，先拆掉句内拔高骨架：`这不仅仅是 X，更是 Y` 可以改成 `这是 Y`，前提是 `Y` 本身有信息量
|
||||
- `真正的 X 不是 A，而是 B` 可以改成 `X 更看 B` 或 `B 更能影响 X`，不要靠二元对比制造洞见感
|
||||
- `看完会彻底开悟 / 看完就懂了` 这类承诺式收尾，改成低承诺描述，例如 `下面只说我观察到的几个问题`
|
||||
- 如果整句没有可保留的信息，保留原句并标注风险，不在 `in-place` 模式下自行删掉
|
||||
|
||||
### 保留条件
|
||||
|
||||
- 对比两边都承载了新信息，不是纯姿态
|
||||
- 作者就是在写评论型公开表达，而且这一句确实在推进论证
|
||||
- 单句正常对比可以保留；同一段连续叠加多组二元或拔高骨架，或骨架跨段分布但全文密度超标时（阈值见 [结构反模式](./structures.md) 第 1 条），不要据此整段 `no-op`，应按 `in-place` 替代动作逐句降调，并保留两边的信息与原有句数
|
||||
|
||||
### 回读检查
|
||||
|
||||
- 去掉骨架后，判断是否更直接
|
||||
- 是否把作者真正想强调的判断也一起删掉了
|
||||
- 剥掉拔高层后，是否只剩“有改进 / 能提效 / 面临挑战”这类泛化空话；如果原文没有更具体的信息，允许变短并标注缺口径，不要用新事实填空
|
||||
|
||||
## 8. 无源引用
|
||||
|
||||
### 识别信号
|
||||
|
||||
- `研究表明`
|
||||
- `数据显示`
|
||||
- `业内人士认为`
|
||||
- `studies show`
|
||||
- `experts say`
|
||||
- 句子借权威开场，但没有给研究名、机构、时间、链接或可核对来源
|
||||
|
||||
### 默认动作
|
||||
|
||||
- 先选模式，不要一上来就改句子：
|
||||
- `rewrite-safe`：删掉权威铺垫，只保留原文里能独立成立的判断
|
||||
- `audit-only`：明确提示“缺来源 / 缺归属”，默认不替作者改成像已证实的说法
|
||||
- `rewrite-with-placeholder`：只在用户明确要求保留原结构时，用“此处待补来源”这类占位提醒保住结构
|
||||
- `docs / status` 默认优先 `audit-only`
|
||||
- `chat / public-writing` 默认优先 `rewrite-safe`
|
||||
- 不要编造研究机构、年份、样本量、行业共识或专家身份
|
||||
- `audit-only` 只约束无源论断本身；同一段还有二元骨架、商业黑话、表演性动作或空总结时，仍按各自规则清理，不能因为一处需要审计就把整段冻结成风险说明
|
||||
|
||||
### 保留条件
|
||||
|
||||
- 原文已经附了可核对来源，只是当前位置没重复写
|
||||
- 这句话本身是在讨论“无源引用”这种写法，而不是在借它立论
|
||||
- 用户明确要做的是编辑批注，而不是直接改写正文
|
||||
|
||||
### 回读检查
|
||||
|
||||
- 改完后，是否还在暗示“已有可靠研究支持”而其实没有
|
||||
- 是否为了保住句子气势，偷偷补进了原文没有的事实
|
||||
- 当前场景下，是否应该更保守地退回 `audit-only`
|
||||
- 删掉无源数字、预测或权威铺垫后，是否只剩“更快 / 会改善 / 将改变行业”这类更泛的同向断言；如果具体论断无法独立成立，`rewrite-safe` 应删整条论断，不要把它降格成空泛版本
|
||||
|
||||
## 9. Residual Audit / 二次审稿
|
||||
|
||||
### 识别信号
|
||||
|
||||
- 第一遍已经把明显套话清掉了，但还残留一点“像被 AI 清理过”的味道
|
||||
- 常见残留固定只看 5 类：
|
||||
- 开场残留：`结论先说 / 直接说结论 / 值得注意的是`
|
||||
- 总结残留：`总的来说 / 最终来看 / 归根结底`
|
||||
- narrator 残留：`这也说明了 / 更重要的是 / 这意味着`
|
||||
- 空泛判断残留：`方向是对的 / 意义重大 / 真正理解了用户`
|
||||
- 节奏过匀：连续几句长度、抬手和落点都太整齐；或同一种句式骨架（尤其二元对比）反复到能预判下一句形状
|
||||
- 快速定位手法：通读一遍，圈出「换一个模型也能原样写出来」的段落。那几段通常就是残留最重的地方。先用这个问句圈范围，再用上面 5 类对号入座，比逐条对表快
|
||||
- 这一步更像轻量抛光，不是再来一轮重写
|
||||
|
||||
### 默认动作
|
||||
|
||||
- 先完成第一遍保真回读，再决定要不要开第二遍；顺序不要反
|
||||
- 第二遍只做轻量修正：
|
||||
- 删掉一个残留开场或空总结
|
||||
- 把一句 narrator / 空泛判断压回直接句
|
||||
- 合并两句过匀的事实句，或拆开一处过满的句子
|
||||
- 同型句式骨架超出密度阈值时，只改超出的那几处，换成中性连接或直接陈述
|
||||
- `docs / status / code-context` 默认更保守：只有残留真的明显，而且不影响事实、术语和正式语体时才动
|
||||
- 如果第二遍需要大改结构才能“更像人”，那通常说明该停在第一遍，而不是继续抛
|
||||
|
||||
### 保留条件
|
||||
|
||||
- 提示层本身承担标题、转场或教学结构，不只是姿态
|
||||
- narrator 句承载了必要的论证，而不是空解释
|
||||
- 句长整齐来自列表、步骤说明、状态同步，不是 AI 抛光痕迹
|
||||
- 句式骨架重复来自术语定义、并列条目或作者刻意承载论点的对比结构
|
||||
- 第二遍一动就会让 `docs / status / code-context` 变得更口语、失真或像宣传稿
|
||||
|
||||
### 回读检查
|
||||
|
||||
- 第二遍后，文本是否更自然，而不是更“会写”
|
||||
- 是否只做了小修，不是把整段重写了一遍
|
||||
- 是否在不知不觉里补了原文没有的事实或态度
|
||||
- `docs / status / code-context` 是否仍然保留原来的正式度和信息密度
|
||||
|
||||
## 10. 动词名词化
|
||||
|
||||
### 识别信号
|
||||
|
||||
- `进行了优化 / 实现了效率的提升 / 完成了对流程的梳理 / 起到了支撑作用 / 具有重要意义`
|
||||
- `进行 / 实现 / 完成 / 开展 / 起到 / 具有` 后面跟一个动名词，空动词负责语法，实义全压在名词里
|
||||
- 英文对应 `perform an analysis of`、`conduct a review of`、`achieve an improvement in`
|
||||
- 句子读完能复述"做了什么"，但复述出来比原句短一半
|
||||
|
||||
### 默认动作
|
||||
|
||||
- 还原成直接的动词：`对流程进行了优化` → `把流程改顺了`
|
||||
- 还原后如果句子露出"其实没说清谁做了什么"，按「清理后的落点」合同处理，允许变短并标注缺口径，不补事实
|
||||
|
||||
### `in-place` 替代动作
|
||||
|
||||
- 名词化多数能句内还原，不需要删句也不需要并句
|
||||
- 还原后字数会掉，这是正常的：`实现了效率的显著提升` → `快了不少`。`in-place` 的字数下限约束的是整句删除，不约束句内还原
|
||||
- 如果还原会丢掉原文声称的效果类型（`提升` 不能改成 `变化`），保留原谓词方向再压缩
|
||||
|
||||
### 保留条件
|
||||
|
||||
- 法律、合同、公文、正式公告里的固定表述（`进行公示`、`予以受理`）
|
||||
- `docs` 里已经是稳定术语的名词化（`增量编译`、`执行计划生成`）
|
||||
- 用户明确要求正式语体的对外材料
|
||||
|
||||
### 回读检查
|
||||
|
||||
- 改完后能不能一眼看出谁做了什么
|
||||
- 是否把专业术语里本来就是名词的概念也拆成了动词
|
||||
|
||||
## 11. 同义词躲避
|
||||
|
||||
### 识别信号
|
||||
|
||||
- 同一个对象在相邻 2–3 句里换了 2 次以上说法，而且一次比一次抽象：`修表 → 这门手艺 → 这项技能`
|
||||
- 英文同型：`parser → component → module`
|
||||
- 代词（`它 / 这个 / 该`）不算，正常照应本来就该用代词
|
||||
|
||||
### 默认动作
|
||||
|
||||
- 统一回最具体的那个说法，其余改成原词或代词
|
||||
- 关键词该重复就重复，不为"避免重复"付出精确度
|
||||
|
||||
### 保留条件
|
||||
|
||||
- 换的说法带来新信息或新限定（`修表 → 上门修表`）
|
||||
- 两个说法其实不指同一个对象
|
||||
- 术语与口语的对照本身就是文本在做的事（`索引 / index`）
|
||||
- 引用原文
|
||||
|
||||
### 回读检查
|
||||
|
||||
- 改完后指称是不是更稳，读者不用回头确认"这三个词是不是一回事"
|
||||
- **反向自查**：这一轮清理 Tier 3 高密度词时，自己有没有用同义词轮换降密度。有的话回退，改成删掉多余的几次或换成具体信息（见 [严重度分级](./severity.md) Tier 3）
|
||||
|
||||
## 12. 连词过密
|
||||
|
||||
### 识别信号
|
||||
|
||||
- `因为 / 所以 / 但是 / 同时 / 此外 / 然而 / 因此` 几乎每两句出现一个
|
||||
- 连续三句每句都以连词开头，或同一个连词在一段里出现 3 次以上
|
||||
- **只在 `public-writing` 的叙事、观点、随笔类文本上判**；`docs / status / code-context` 不判，理由和实测数据见 [结构反模式](./structures.md) 第 23 条
|
||||
|
||||
### 默认动作
|
||||
|
||||
- 删掉一半，读得断的地方不补回来
|
||||
- 删完通读一遍，事理接不上的地方再放回最必要的那个
|
||||
|
||||
### `in-place` 替代动作
|
||||
|
||||
- 连词是句内成分，删除不算删句，`in-place` 下照常处理
|
||||
- 删到句子读不通时改用中性衔接，不要为了减连词把两句并成一句
|
||||
|
||||
### 保留条件
|
||||
|
||||
- 连词真的承担转折、让步或因果，删掉会读错
|
||||
- `docs` 里的条件说明和步骤衔接（`如果……则……`）
|
||||
- 法律与规范文本；`status` 里的时间线因果
|
||||
|
||||
### 回读检查
|
||||
|
||||
- 删完之后事理还接得上吗，有没有出现需要读者自己补逻辑的跳跃
|
||||
- 是否在 `docs / status` 上误用了这条
|
||||
|
||||
## 13. 装饰性细节
|
||||
|
||||
### 识别信号
|
||||
|
||||
- 没有来源的精确时间、天气、神态、房间摆设、烟酒食物和突然出现的对白
|
||||
- `凌晨三点`、`第三根烟`、`桌上的咖啡早就凉了`、`窗外下着雨`
|
||||
- 判据是两条同时成立：细节没有来源（不是用户提供的、不可核验），并且删掉后文的事实、判断、因果都不变
|
||||
- 和 §5.2 的假口语化不同：那个是硬塞网络流行语，这个是伪造生活细节。假细节越具体，AI 味越重
|
||||
|
||||
### 默认动作
|
||||
|
||||
- 删掉。删完段落如果没了落点，用原文已有的信息重组，不补新细节
|
||||
|
||||
### `in-place` 替代动作
|
||||
|
||||
- 装饰细节常常占满整句，`in-place` 下不删句，保留原句并标注 `[无来源细节，建议人工确认是否删除]`
|
||||
- 细节只是句内修饰成分时（`他盯着那行报错，窗外下着雨`），可以句内删掉修饰，保留主干
|
||||
- `bounded` 下整句装饰细节进「建议删除（待确认）」清单，理由写"无来源且删后信息不变"
|
||||
|
||||
### 保留条件
|
||||
|
||||
- 用户自己提供的经历细节，哪怕琐碎也保留
|
||||
- 细节确实改变后文（`那天是周日，维修点没开门`）
|
||||
- 虚构、小说、剧本里属于人物视角和行动的细节
|
||||
- `docs` 里的复现条件、环境说明、时间戳和日志片段
|
||||
|
||||
### 回读检查
|
||||
|
||||
- 删掉的细节里有没有其实承担了因果的
|
||||
- 有没有把用户自己讲的经历当成模型编的细节删掉——这是本节最危险的误杀方向
|
||||
|
||||
## 14. 借喻场混用
|
||||
|
||||
### 识别信号
|
||||
|
||||
- 同一段里从多套不相干的比喻系统借词：道路竞赛、战争攻防、建筑灾害、温度、仓储、海洋航行、机器器官
|
||||
- `赛道的护城河正在坍塌，需要重新点燃引擎，才能在这波浪潮里活下来`
|
||||
- 短距离内（约 800 字）命中 3 套以上才算命中；单套用得准不处理
|
||||
|
||||
### 默认动作
|
||||
|
||||
- 先全部还原成本义
|
||||
- 还原后意思已经清楚的，一个比喻也不用放回，不要换一套新比喻替代
|
||||
|
||||
### `in-place` 替代动作
|
||||
|
||||
- 借喻词多数是句内词，替换成本义不涉及删句
|
||||
- 还原后如果原句只剩空话，说明这句话本来就只有比喻没有信息，保留原句并标注，不擅自补事实
|
||||
|
||||
### 保留条件
|
||||
|
||||
- 所写对象本身就是这些东西（真的在讲仓库、温度、船）
|
||||
- 行业稳定术语：金融的 `杠杆`、投资语境的 `护城河`、技术语境的 `搜索引擎 / 代码仓库 / 商品库存`
|
||||
- 用户明确要求的修辞风格
|
||||
- 小说、诗歌和抒情写作按意象是否属于同一套感受判断，不按数量机械删
|
||||
|
||||
### 回读检查
|
||||
|
||||
- 还原成本义之后，读者是不是更清楚在说什么
|
||||
- 有没有把字面用法（`代码仓库`、`搜索引擎`）当借喻改掉
|
||||
|
||||
## 15. 量化表述有歧义
|
||||
|
||||
### 识别信号
|
||||
|
||||
- 原文的数量关系本身有多种解释：`缩小了 3 倍`、`翻了 1 倍`、`不超过 100 以上`、`预计大约在 3 点左右`
|
||||
- 百分比只给起止值，却需要进一步判断说的是百分点变化还是相对增幅
|
||||
- 句子看起来像病句，但改顺之前必须先替作者选择一种数量关系
|
||||
|
||||
### 默认动作
|
||||
|
||||
- 改写侧默认不替原文修正量化逻辑，不把 `缩小了 3 倍` 擅自改成 `缩小到原来的 1/3`
|
||||
- `annotation mode` 标成歧义点；`docs / status` 按 `audit-only` 标注待确认
|
||||
- `chat / public-writing` 里，如果这段量化说法不承担关键信息，可以压缩掉整个量化说法；如果承担关键信息，就保留原表述并提示确认。两种情况都不能换成新的数量关系
|
||||
- 任何情况下不得自行补充原文没有的基数、年份、期限或测量结果
|
||||
|
||||
### `in-place` 替代动作
|
||||
|
||||
- 只在删掉量化短语后句子仍完整、且该数量不承担关键信息时做句内压缩，例如删掉倍数后保留原文已有的变化方向
|
||||
- 其余情况保留原句并标注 `[量化关系有歧义，待确认]`，不在句内猜一个“更正确”的数值或比例
|
||||
|
||||
### 保留条件
|
||||
|
||||
- 百分点与相对增幅已经写清：`从 20% 升到 30%，提高 10 个百分点，相对增幅 50%`
|
||||
- 基数、单位、起止值和测量口径完整，数量关系没有歧义
|
||||
- 引用、日志、报错、合同原文或用户明确要求逐字保留的量化表述；需要提醒时在原文外标注，不改引用内部
|
||||
|
||||
### 回读检查
|
||||
|
||||
- 改写后是否出现了原文没有的分母、基数、年份、期限、测量值或推导结果
|
||||
- 是否把一种有歧义的说法偷偷固定成了某一种解释
|
||||
- 正常的百分点、百分比、单位和基数是否被误判后改动
|
||||
@@ -0,0 +1,140 @@
|
||||
# English Banned Phrases
|
||||
|
||||
> 本文件是解释、示例与操作细则；行为合同的单源是 `SKILL.md`，两处表述不一致时以 `SKILL.md` 为准。
|
||||
|
||||
> Sources: humanizer, stop-slop, avoid-ai-writing, beautiful_prose.
|
||||
|
||||
本表默认列代表项，不追求穷举同义变体。**这份清单是举例，不是边界。** 这里管的是修辞动作，不是字面：把一个命中的说法换一套词继续做同一件事——同样的 significance inflation、同样的 sycophantic opener、同样的空 hedging——仍然算命中。判断一个新说法要不要处理，看它在做什么动作，不看它在不在下面的列表里。反过来也成立：出现在列表里但在当前句子里承担实义的词，按误杀防护放行。
|
||||
|
||||
## Tier 1: Replace by default
|
||||
|
||||
These words appear 5–20x more often in AI text than human text. Replace by default, but allow exceptions per misfire protection rules (see `severity.md`).
|
||||
|
||||
### Throat-clearing openers
|
||||
- Here's the thing
|
||||
- The uncomfortable truth is
|
||||
- Can we talk about
|
||||
- Let's be honest
|
||||
- I'll be frank
|
||||
- It's worth noting that
|
||||
- At its core
|
||||
- At the end of the day
|
||||
- In today's world
|
||||
- In a world where
|
||||
- What this means is
|
||||
- It's important to note
|
||||
|
||||
### Emphasis crutches
|
||||
- Full stop.
|
||||
- Let that sink in.
|
||||
- Make no mistake.
|
||||
- Mark my words.
|
||||
- I promise.
|
||||
- Read that again.
|
||||
- Period.
|
||||
|
||||
### Business jargon
|
||||
- leverage → use
|
||||
- navigate → handle, deal with
|
||||
- unpack → explain
|
||||
- lean into → accept, try
|
||||
- deep dive → detailed look
|
||||
- game-changer → important change
|
||||
- circle back → revisit
|
||||
- synergy → cooperation
|
||||
- ecosystem → system, community
|
||||
- streamline → simplify
|
||||
- empower → let, enable
|
||||
- actionable → practical
|
||||
- learnings → lessons
|
||||
- thought leader → expert
|
||||
- best practices → good practices
|
||||
- holistic → complete, whole
|
||||
|
||||
Keep literal technical uses in graph, network, routing, or pathfinding contexts. Example: `The system navigates the network topology using Dijkstra's algorithm.`
|
||||
|
||||
### Inflated verbs (use simpler alternatives)
|
||||
- utilize → use
|
||||
- commence → start
|
||||
- endeavor → try
|
||||
- ascertain → find out
|
||||
- facilitate → help
|
||||
- cultivate → build, grow
|
||||
- elucidate → explain
|
||||
- ameliorate → improve
|
||||
- galvanize → motivate
|
||||
- bolster → support
|
||||
- spearhead → lead
|
||||
- catalyze → trigger
|
||||
- reimagine → rethink
|
||||
|
||||
### Significance inflation
|
||||
- testament to → shows
|
||||
- serves as → is
|
||||
- stands as → is
|
||||
- showcases → shows
|
||||
- underscores → shows
|
||||
- highlights → shows
|
||||
- pivotal → important
|
||||
- groundbreaking → new
|
||||
- cutting-edge → new, latest
|
||||
- watershed moment → turning point
|
||||
- indelible mark → lasting effect
|
||||
- paradigm shift → major change
|
||||
|
||||
### Copula avoidance (just use "is/are/has")
|
||||
- serves as a → is a
|
||||
- stands as a → is a
|
||||
- represents a → is a
|
||||
- functions as a → is a
|
||||
- boasts a → has a
|
||||
- features a → has a
|
||||
- presents a → has a
|
||||
|
||||
### Filler phrases
|
||||
- In order to → To
|
||||
- Due to the fact that → Because
|
||||
- At this point in time → Now
|
||||
- It is important to note that → (delete)
|
||||
- The system has the ability to → The system can
|
||||
- It goes without saying → (delete)
|
||||
|
||||
### Sycophantic / meta
|
||||
- Great question!
|
||||
- You're absolutely right!
|
||||
- Certainly!
|
||||
- Of course!
|
||||
- I hope this helps!
|
||||
- Let me know if you'd like me to expand
|
||||
- In this essay we will explore
|
||||
- As we'll see
|
||||
- Here is a/an
|
||||
|
||||
## Tier 2: Flag when 2+ appear in same paragraph
|
||||
|
||||
Legitimate individually, clustering signals AI.
|
||||
|
||||
- harness, navigate, foster, elevate, unleash
|
||||
- resonate, revolutionize, underpin, nuanced, crucial
|
||||
- multifaceted, myriad, plethora, encompass
|
||||
- transformative, cornerstone, paramount, poised
|
||||
- burgeoning, nascent, quintessential, overarching
|
||||
|
||||
## Tier 3: Flag at high density only
|
||||
|
||||
Common words, only problematic at high density. Thresholds: 3+ in short text (<200 words), 5+ in medium text (200–1000 words), >0.5% in long text (>1000 words). See `severity.md` for details.
|
||||
|
||||
- significant, innovative, effective, dynamic
|
||||
- scalable, compelling, unprecedented, exceptional
|
||||
- remarkable, sophisticated, instrumental
|
||||
- comprehensive, robust, seamless
|
||||
|
||||
## Adverbs (-ly words)
|
||||
|
||||
Most -ly adverbs are filler. Delete or rephrase:
|
||||
|
||||
- really, just, literally, genuinely, honestly
|
||||
- deeply, truly, fundamentally, essentially
|
||||
- incredibly, remarkably, significantly
|
||||
- interestingly, importantly, notably
|
||||
- ultimately, arguably, undeniably
|
||||
@@ -0,0 +1,341 @@
|
||||
# 中文禁用短语表
|
||||
|
||||
> 本文件是解释、示例与操作细则；行为合同的单源是 `SKILL.md`，两处表述不一致时以 `SKILL.md` 为准。
|
||||
|
||||
> 来源：awesome-ai-research-writing、日常 AI 输出观察、公众号/小红书 AI 味总结、Linux.do / X / 即刻社区反馈。
|
||||
|
||||
本表默认列代表项，不追求把同义变体全部穷举出来。遇到没收录的新说法，先看它是不是现有模式的同类变体；只有现有模式吃不住，或误杀边界变了，才值得补成新词条。
|
||||
|
||||
**这份清单是举例，不是边界。** 这里管的是修辞动作，不是字面：把一个命中的说法换一套字继续做同一件事——同样的姿态、同样的抬价、同样的空承诺、同样的替对方下结论——仍然算命中。判断一个新说法要不要处理，看它在做什么动作，不看它有没有出现在下面的列表里。反过来也成立：出现在列表里但在当前句子里承担实义的词，按误杀防护放行。
|
||||
|
||||
## Tier 1：默认替换
|
||||
|
||||
这些词/短语在 AI 文本中出现频率远高于人类文本。默认替换，但在误杀防护场景中允许保留（见 `severity.md`）。
|
||||
|
||||
### 开场套话
|
||||
- 值得注意的是 → 删掉，直接说
|
||||
- 值得一提的是 → 删掉
|
||||
- 需要指出的是 → 删掉
|
||||
- 不可否认的是 → 删掉
|
||||
- 不难发现 → 删掉
|
||||
- 不容忽视 → 删掉
|
||||
- 众所周知 → 删掉，或给具体出处
|
||||
- 让我们一起来看看 → 删掉
|
||||
- 接下来我将为你 → 删掉
|
||||
- 在当今（时代/社会/环境下）→ 删掉或给具体时间
|
||||
- 在当今社会 → 删掉
|
||||
- 随着……的不断发展 → 删掉或说清楚发展了什么
|
||||
- 在这个……的时代 → 删掉
|
||||
- 不得不说 → 删掉，直接说
|
||||
- 诚然 → 删掉
|
||||
- 深入探讨 → 删掉，直接讨论
|
||||
- 具体来说 → 删掉或简化
|
||||
- 更重要的是 → 删掉
|
||||
|
||||
### 渲染性强调
|
||||
- 深刻的（影响/意义/变革）→ 说清楚具体影响了什么
|
||||
- 深远的（影响/意义）→ 同上
|
||||
- 不可磨灭的（贡献/印记）→ 说清楚具体做了什么
|
||||
- 毋庸置疑 → 删掉
|
||||
- 至关重要 → "重要"或直接说为什么重要
|
||||
- 举足轻重 → 同上
|
||||
- 令人瞩目 → 给具体数据
|
||||
- 令人惊叹 → 给具体数据
|
||||
- 意义非凡 → 说清楚什么意义
|
||||
- 前所未有 → 给对比数据
|
||||
- 史无前例 → 同上
|
||||
- 毫不夸张地说 → 删掉
|
||||
- 值得深思 / 令人深思 / 引发思考 / 发人深省 → 删掉，内容本身说话
|
||||
- 不禁让人（想到/感叹）→ 删掉
|
||||
- 具有重要意义 → 说清楚什么意义
|
||||
- 发挥着关键作用 → 说清楚怎么起作用
|
||||
- 颠覆性（的变革/创新）→ 说清楚改变了什么
|
||||
- 范式转移 → 说清楚变了什么
|
||||
|
||||
### 商业/互联网黑话
|
||||
- 赋能 → 帮、让……能
|
||||
- 助力 → 帮
|
||||
- 打造 → 做、建
|
||||
- 抓手 → 方法、工具
|
||||
- 闭环 → 先判义项：表示工作完成时，写完成了什么，保留未完成或只完成部分的范围；表示反馈流程时，保留原有反馈关系，不自行补流程；`闭环反馈 / 闭环控制` 等实际技术用法保留
|
||||
- 颗粒度 → 细节程度
|
||||
- 对齐 → 统一、一致
|
||||
- 拉齐 → 统一
|
||||
- 沉淀 → 积累、记录
|
||||
- 痛点 → 问题
|
||||
- 场景化 → 按场景
|
||||
- 降本增效 → 省钱提速
|
||||
- 底层逻辑 → 原因、原理
|
||||
- 顶层设计 → 整体规划
|
||||
- 体感 → 感觉、体验
|
||||
- 心智 → 认知、印象
|
||||
- 链路 → 流程、路径
|
||||
- 触达 → 到达、联系到
|
||||
- 透传 → 传递
|
||||
- 拉通 → 打通、统一
|
||||
- 洞察 → 看清、发现；BI / 数据产品里的正式功能名或指标名（如 `用户洞察` 模块）放行
|
||||
- 赛道 → 业务、领域、方向；讨论体育竞赛、本义道路，或项目正式采用的行业术语时放行
|
||||
- 协同 → 一起做、配合；分布式系统、供应链或组织制度中的正式机制名（如 `协同编辑`、`供应链协同`）放行
|
||||
- 卡点 → 卡住的地方、阻碍；排期、工序或流程管理中已经定义的节点名放行
|
||||
- 联动 → 一起处理、同时响应；设备、控制系统或应急预案里的正式联动机制（如 `消防联动`）放行
|
||||
|
||||
### 工程师腔 / 调试腔（AI 模仿程序员说话）
|
||||
|
||||
AI 在编程辅助场景中模仿 SRE/工程师口吻，把 debug 术语用到日常对话里，像在写 postmortem：
|
||||
|
||||
同类姿态词默认一并处理，不要求逐词收录。遇到近义变体，先并到这一类。
|
||||
|
||||
- 稳稳兜住 → 处理好、搞定
|
||||
- 砍一刀 → 删掉、去掉
|
||||
- 收口 → 收尾、结束
|
||||
- 收窄 → 缩小范围
|
||||
- 打掉问题 → 修好、解决
|
||||
- 避免漂移 → 别跑偏
|
||||
- 根因 → 原因、根本原因
|
||||
- 有点满 → 内容太多了
|
||||
- 更稳 / 最稳 / 不稳 → 更可靠 / 最可靠 / 不可靠；如果上下文已有指标、技术对象或稳定性结果，不要机械改
|
||||
- 做快、做稳 / 又快又稳 / 更快更稳（用于产品自夸、项目介绍、营销式 README）→ 改成具体对象、具体动作或直接删掉；如果上下文已有真实主体、指标或稳定性结果（错误率、延迟、可用性、上线观察等），不要机械改
|
||||
- 稳稳接住（用于人/情绪/所有人/需求）→ 删掉承接姿态，改成具体回应或具体处理
|
||||
- 夹具（fixture）→ 固定方案、测试数据（说清楚具体指什么）
|
||||
- 接住（用于你/大家/情绪/脆弱/需求等抽象宾语）→ 回应、处理；如果宾语是 `流量 / 请求 / 峰值 / 异常` 且有系统主语和结果，先不要机械改
|
||||
- 拆开看 → 分开说、逐个看
|
||||
- 偏硬 → 太死板
|
||||
- 落盘（用于抽象动作 / 空对象 / 泛化表演时）→ 保存、写入、记下来；如果宾语是 `代码 / 部署 / 配置 / 文档 / 设计方案` 等具体技术对象，且能复述"写到哪里、做了什么"，先不要机械改
|
||||
- 已经落下去（不带具体技术对象时）→ 已经做了、已经生效；如果上下文已经说清"落到哪个文件 / 哪一版 / 哪个分支"，可以保留
|
||||
- 对上了 → 吻合、一致
|
||||
- 坐实了 → 确认了、证实了
|
||||
- 做一个更硬的排除法 → 用排除法再查一遍
|
||||
- 把差异收窄了 → 缩小了差异
|
||||
- 抓到的现象 → 发现的问题
|
||||
- 兜底 → 保底处理、兜住边界情况
|
||||
- 压实 → 落实、确认好
|
||||
- 收敛 → 缩小范围、逐步收拢
|
||||
- 收束 → 收尾、结束
|
||||
- 锁住 → 固定好、确认
|
||||
- 更硬 / 硬写 → 更死板 / 直接写死（说清楚为什么）
|
||||
- 口径 → 说法、措辞
|
||||
- 这轮 → 这次
|
||||
- 能吃 → 能接受、能处理
|
||||
- 说穿 → 说白了（删掉，直接说）
|
||||
- 不躲 / 不藏 / 不绕 / 不逃 → 删掉，直接说就行
|
||||
- 说人话就是 → 删掉，直接说
|
||||
|
||||
### 庸医问诊腔（AI 模仿诊断专家口吻）
|
||||
|
||||
AI 把排查过程戏剧化，模仿医生找病因的语气：
|
||||
|
||||
同类“找出来”式变体优先按这一类处理，例如 `扒开`、`拽出来`、`捞出来`。
|
||||
|
||||
- 抠出来 / 揪出来 → 找出来、定位
|
||||
- 我不猜 / 不靠猜 / 不瞎猜 → 删掉，说清楚你掌握了什么信息
|
||||
|
||||
### 暴力动作腔（AI 用激烈动词表达普通操作）
|
||||
|
||||
AI 用"暴力"动词凸显执行力，实为多余的气势渲染：
|
||||
|
||||
同类暴力动词优先并到这一类，不要求每个新变体单独入库。
|
||||
|
||||
- 补一刀 → 再加一点、补充
|
||||
- 更狠 / 狠一点 → 更彻底、更严格
|
||||
- 狠狠干 → 删掉（AI 硬凹干劲）
|
||||
- 打坏 → 破坏、损坏
|
||||
- 拍脑门 → 随便决定（说清楚是谁在随便决定）
|
||||
- 拍板 → 决定、定了（说清楚谁定的）
|
||||
- 切 / 伤（作为动作隐喻）→ 改、删、调整
|
||||
|
||||
### 自媒体 / 小红书 AI 腔
|
||||
|
||||
AI 模仿爆款文风时的标志性用词。单独使用是正常网络用语，但 AI 批量生产时高频堆砌暴露机器痕迹：
|
||||
|
||||
- 保姆级（教程/攻略）→ 删掉或换成"详细"
|
||||
- 硬核（干货/分析）→ 删掉
|
||||
- 干货 → 删掉（每篇都说干货等于没说）
|
||||
- 拆解 → 分析、讲解
|
||||
- 梳理 → 整理
|
||||
- 盘点 → 列举、介绍
|
||||
- 避坑 / 踩坑 / 不踩坑 → 注意、别犯的错
|
||||
- 一文读懂 → 删掉
|
||||
- 万字长文 → 删掉
|
||||
- 建议收藏 → 删掉
|
||||
- 强烈推荐 → 删掉或说清楚为什么推荐
|
||||
- 划重点 → 删掉
|
||||
- 绝绝子 → 删掉（AI 硬凹网感）
|
||||
- 谁懂啊 → 删掉
|
||||
- 真的会谢 → 删掉
|
||||
- 姐妹们 → 删掉（AI 硬凹人设）
|
||||
- 狠狠（XX 了）→ 删掉
|
||||
|
||||
### 洞见感 / 价值拔高骨架
|
||||
- 真正的 X 不是……而是…… → 多数直接说真正成立的判断
|
||||
- 这不仅仅是……更是…… → 多数删掉拔高层，保留事实判断
|
||||
- 最后比拼的是…… → 直接说真正决定因素是什么
|
||||
|
||||
### 过渡废话
|
||||
- 综上所述 → 删掉或直接给结论
|
||||
- 总而言之 → 同上
|
||||
- 总的来说 → 同上
|
||||
- 总体来看 → 同上
|
||||
- 由此可见 → 删掉
|
||||
- 换句话说 → 删掉（说一遍就够了）
|
||||
- 简而言之 → 删掉
|
||||
- 归根结底 → 删掉
|
||||
- 不言而喻 → 删掉
|
||||
- 可以说 → 删掉（直接说就行）
|
||||
- 某种程度上 → 删掉或说清楚什么程度
|
||||
- 从某种意义上说 → 同上
|
||||
- 在此过程中 → 删掉
|
||||
- 在这个过程中 → 删掉
|
||||
- 本质上 → 删掉或说清楚
|
||||
- 核心在于 → 直接说
|
||||
- 关键在于 → 直接说
|
||||
- 由此可以看出 → 删掉
|
||||
|
||||
### 正能量收尾模板
|
||||
- 与其……不如积极拥抱…… → 删掉，不做鸡汤
|
||||
- 只有……才能…… → 看上下文，AI 喜欢用这个做总结
|
||||
- 让我们拭目以待 → 删掉
|
||||
- 未来可期 → 删掉
|
||||
|
||||
### 无源引用（公开写作中尤其像 AI）
|
||||
- 研究表明…… → 给出具体研究名称或删掉
|
||||
- 数据显示…… → 给出具体数据来源或直接给数据
|
||||
- 有专家指出…… → 说清楚哪个专家
|
||||
- 业内人士认为…… → 说清楚谁
|
||||
- 据报道…… → 给出具体媒体和时间
|
||||
|
||||
### 谄媚/元评论
|
||||
- 好问题！→ 删掉
|
||||
- 你说得很对 → 删掉
|
||||
- 这是一个很好的观点 → 删掉
|
||||
- 让我来为你解释 → 删掉
|
||||
- 希望这对你有帮助 → 删掉
|
||||
- 如果你有其他问题 → 删掉
|
||||
- 好，/ 行，（作为回复开场）→ 删掉，直接响应
|
||||
- 一句话总结 → 删掉，直接给结论
|
||||
- 结论先说清楚 → 删掉，直接给结论
|
||||
- 简单的说 → 删掉
|
||||
- 不是……而是…… → 看是否必要，多数可删掉前半句
|
||||
- 我先……再…… → 删掉，直接说要做什么
|
||||
|
||||
同类“先宣布自己要开始总结/翻译”的提示句，默认也按这一类处理。
|
||||
|
||||
### AI 主动出击腔（血压升高类）
|
||||
|
||||
AI 过度表达执行意愿，把确认环节变成推销话术：
|
||||
|
||||
- 我已确认 → 删掉（无需宣告）
|
||||
- 我立马开始 → 删掉，直接做
|
||||
- 要不要我…… → 删掉，等用户提需求
|
||||
- 如果你愿意…… → 删掉
|
||||
- 如果你要…… → 删掉
|
||||
- 只要你回复我…… → 删掉
|
||||
- 你一回复我就…… → 删掉
|
||||
- 你就确认一点 → 删掉
|
||||
- 顺手 → 删掉（暗示举手之劳来推销额外操作）
|
||||
- 我先…… → 删掉，直接做
|
||||
|
||||
### 过度接住 / 心理判断腔
|
||||
|
||||
AI 喜欢把普通回应写成“咨询式安抚”，一边过度接住，一边替对方下心理结论：
|
||||
|
||||
- 我就在这里 → 多数删掉，直接回应
|
||||
- 不躲 / 不藏 / 不绕 / 不逃 → 删掉，别演姿态
|
||||
- 稳稳地接住你 / 所有人 / 这份脆弱 → 删掉承接姿态，改回具体回应
|
||||
- 你只是太久没被稳稳接住了 → 删掉，别替对方做心理判断
|
||||
- 不用向我解释 → 删掉，除非上下文确实在安抚对方
|
||||
- 你不是敏感 / 不是想太多 / 不是矫情 → 看是否有明确依据；多数不要替对方下结论
|
||||
- 你太清醒了 / 太懂了 / 太对了 → 删掉夸奖层，直接回应内容
|
||||
- 这次我懂了，我真的懂了 → 删掉，别演“终于完全理解你”
|
||||
|
||||
同一个“接住”字，优先看宾语：
|
||||
|
||||
- 宾语是 `你 / 你们 / 所有人 / 情绪 / 脆弱 / 委屈 / 需求`，默认按这一类处理
|
||||
- 宾语是 `流量 / 请求 / 峰值 / 异常`，先回到技术语境判断，不要因为字面命中就硬改
|
||||
|
||||
### 郑重预告 / 身份认证式夸奖
|
||||
|
||||
AI 喜欢先预告“我要说句大的”，再顺手给对方发身份认证：
|
||||
|
||||
- 我必须很认真地说一句 → 删掉，直接说
|
||||
- 我要讲一个更深一点的东西 → 删掉，直接说
|
||||
- 你问到了问题的核心 → 删掉，直接回答
|
||||
- 你的观察力太敏锐了 / 这个思路简直绝了 → 删掉夸奖层，保留具体判断
|
||||
- 绝对是顶刊作者的素养 / 顶级研究者才具备的批判性思维 → 删掉身份认证式夸奖，改成对内容的具体评价
|
||||
|
||||
## Tier 2：同段出现 2+ 个时标记
|
||||
|
||||
### 单音节命令词（编程辅助场景中 AI 喜欢用短促单字当动词/状语）
|
||||
|
||||
单独用正常，密集出现暗示 AI 在模仿 SRE 口吻走捷径：
|
||||
|
||||
- 补 / 接 / 核 / 进 / 顺 / 落 / 坏 / 跑
|
||||
|
||||
单独使用可以接受，聚集出现是 AI 味信号。
|
||||
|
||||
### 连接词
|
||||
- 然而
|
||||
- 此外
|
||||
- 与此同时
|
||||
- 不仅……而且……
|
||||
- 一方面……另一方面……
|
||||
- 尽管如此
|
||||
- 事实上
|
||||
- 实际上
|
||||
- 在此基础上
|
||||
- 进一步地
|
||||
- 恰恰
|
||||
- 正是
|
||||
- 无疑
|
||||
- 由此可以看出
|
||||
- 不外乎
|
||||
|
||||
### 形容/修饰
|
||||
- 显著（提升/改善/增长）
|
||||
- 有效（解决/推动/促进）
|
||||
- 全面（覆盖/推进/升级）
|
||||
- 积极（推动/探索/参与）
|
||||
- 持续（优化/推进/深化）
|
||||
- 进一步（加强/完善/深化）
|
||||
- 充分（发挥/利用/体现）
|
||||
- 切实（保障/推进/落实）
|
||||
- 可谓
|
||||
- 堪称
|
||||
- 追根溯源
|
||||
|
||||
### 抒情词给抽象概念穿衣服
|
||||
|
||||
单个出现完全正常；同段 2+ 个、且描写对象是记忆、成长、时代、答案等抽象概念时标记。处理的是密度和搭配对象，不是这些词本身。
|
||||
|
||||
- 安放 / 抵达 / 微光 / 褶皱 / 丰盈 / 滚烫 / 轻盈
|
||||
- 赤裸 / 剥开 / 锋利 / 坚硬 / 柔软
|
||||
|
||||
写具体事物时放行：`把药盒安放在床头`、`剥开一只橘子`、`刀口很锋利` 都是实义。小说、诗歌、散文、歌词等文学场景整体放行；用户明确要求抒情语体时也放行。命中时把抽象概念改回直接陈述，不要换一组抒情词继续包装。
|
||||
|
||||
## Tier 3：全文密度高时标记
|
||||
|
||||
常见词，只在全文中饱和使用时才有 AI 味。
|
||||
|
||||
- 重要
|
||||
- 关键
|
||||
- 核心
|
||||
- 基础
|
||||
- 创新
|
||||
- 优化
|
||||
- 提升
|
||||
- 推动
|
||||
- 加强
|
||||
- 确保
|
||||
- 实现
|
||||
- 促进
|
||||
|
||||
## 翻译腔（中文特有 AI 味）
|
||||
|
||||
这些是英文思维直译到中文的痕迹：
|
||||
|
||||
- "一个……的……的……" 长定语结构 → 拆成短句
|
||||
- 被动语态堆砌（"被优化""被改进""被赋予"）→ 用主动句
|
||||
- "基于……" 开头 → 看能否直接说
|
||||
- "通过……来……" → 看能否简化
|
||||
- "对于……而言" → 看能否删掉
|
||||
- "在……方面" → 看能否删掉
|
||||
- "从……的角度来看" → 看能否简化
|
||||
@@ -0,0 +1,257 @@
|
||||
# Positive Style Contract
|
||||
|
||||
> 本文件是解释、示例与操作细则；行为合同的单源是 `SKILL.md`，两处表述不一致时以 `SKILL.md` 为准。
|
||||
|
||||
> 目标不是只把 AI 套话删干净，而是把文本拉回当前场景里“像具体人在说这件事”的状态。
|
||||
|
||||
这份文档定义的是正向目标，不是新的 house style，也不是 voice 拟合协议。
|
||||
|
||||
它解决的问题是：
|
||||
|
||||
- 删完套话后，文本还是太平、太匀、太像“被清理过的 AI”
|
||||
- 为了“更自然”乱加情绪、乱补细节，反而把文本写假了
|
||||
- 不同场景都被抹成同一种“聪明、顺滑、会总结”的口气
|
||||
|
||||
使用顺序：
|
||||
|
||||
1. 先按 `SKILL.md` 判场景，确认主语域和禁改边界
|
||||
2. 先看 [Protected Spans](./protected-spans.md)，把不能漂的内容圈出来
|
||||
3. 再判 `Tier` 和档位
|
||||
4. 再用这份正向合同判断“改成什么样才算更像人”
|
||||
|
||||
## 1. Anti-goals
|
||||
|
||||
这份合同不追求：
|
||||
|
||||
- 不强行口语化
|
||||
- 不硬造个人 voice
|
||||
- 不把每句都抛光得很顺
|
||||
- 不靠金句、反问句、碎句或抒情句制造“人味”
|
||||
- 不为了更具体而补原文没有的事实
|
||||
|
||||
## 2. Positive targets
|
||||
|
||||
改写后的文本，优先往下面这 5 个方向靠：
|
||||
|
||||
### 2.1 具体动作优先于抽象拔高
|
||||
|
||||
优先写谁做了什么、改了什么、看到什么，不用“能力提升”“价值释放”“底层重构”这类空壳抬句势。
|
||||
|
||||
更好：
|
||||
|
||||
> 把缓存从本地 LRU 换成 Redis，峰值时不再把应用内存打满。
|
||||
|
||||
不够好：
|
||||
|
||||
> 完成缓存层升级，显著提升系统稳定性与整体韧性。
|
||||
|
||||
### 2.1.1 清理后的落点
|
||||
|
||||
删掉姿态层之后，句子要落在原文已经给出的信息上，而不是换成另一句更泛的空话。优先级固定为三档：
|
||||
|
||||
1. 原文有数字、动作、对象或明确结论：清掉渲染词，但把这些信息保留下来。
|
||||
2. 原文没有具体指标或事实：允许输出更短、更直白；不要用“能提效”“有改进”“降低了延迟”“面临挑战”这类泛化句填空。
|
||||
3. `status / docs` 需要具体依据才能成立、而原文又没给时：标注“原文缺具体依据”，不要补数字、功能、来源或技术选型。
|
||||
|
||||
抽象信息也不能擅自“具体化”。原文只说“提升效率”，不能改成“省时间”“降低成本”或“提高产量”；原文只说“仍有挑战”，不能自行补成技术难题、合规风险或学习清单。删掉鸡汤和劝导骨架后，也不要用“值得尝试”“继续学习”这类新劝导填回去。
|
||||
|
||||
反例：
|
||||
|
||||
> 原文：这次调整显著改善了查询性能，主查询从 800ms 降到 120ms。
|
||||
>
|
||||
> ❌ 这次调整改善了性能。
|
||||
>
|
||||
> ✅ 这次调整把主查询从 800ms 降到 120ms。
|
||||
|
||||
如果原文只有“显著改善了查询性能”，没有指标，就可以写成“这次调整改善了查询性能”，并在 `status / docs` 场景提示缺具体指标或依据；不能自行补出延迟、模块或百分比。
|
||||
|
||||
无源引用还有一条额外边界：如果具体数字或预测本身没有来源，不能删掉 `40%` 后把同一句降格成“会更快”，也不能把 `未来十年` 改成“未来几年”。`rewrite-safe` 要么删除整条无法独立成立的论断，要么只保留原文中不依赖该来源也能成立的信息；保守场景则退回 `audit-only` 标注缺来源。
|
||||
|
||||
### 2.2 真主语和真动作优先于姿态层
|
||||
|
||||
优先保留承载事实的主语和动作，少写“我们需要深入思考”“接下来稳稳兜住”这种姿态层。
|
||||
|
||||
更好：
|
||||
|
||||
> 我先核对了两个异常分支，确认都是同一类超时。
|
||||
|
||||
不够好：
|
||||
|
||||
> 我们已经把关键现象对上，接下来会进一步把核心链路稳稳兜住。
|
||||
|
||||
### 2.3 节奏可以自然，不要整段一样齐
|
||||
|
||||
自然表达允许有轻微不对称：有的句子短一点，有的句子稍微展开一点。不要把每句都写成同长度、同抬手、同落点，也不要让同一种句式骨架（尤其 `不是 X，是 Y` 这类二元对比）反复到读者能预判下一句形状。
|
||||
|
||||
长文里，适度重复不一定是废话。它可能承担转场、停顿、强调或情绪缓冲。判断一处重复该不该删，先看删掉后段落衔接是否突兀；如果突兀，优先保留节奏，只处理句内的模板词和拔高词。
|
||||
|
||||
bounded scope 下，这条边界落在删除清单上：承担节奏的重复和转场不进清单；进清单的必须是剥掉引导词后什么都不剩的整句空话。
|
||||
|
||||
更好：
|
||||
|
||||
> 数据库这轮先快了。主查询从 800ms 降到 120ms，前端首屏也跟着从 2 秒降到 0.4 秒。
|
||||
|
||||
不够好：
|
||||
|
||||
> 本次更新优化了数据库性能。我们提升了页面加载速度。用户反馈的问题也得到了解决。
|
||||
|
||||
上面「更好」里的数字，只有手里真有这些数据时才能写。原文没有数据的，只调句长和句序制造节奏，不要为了节奏编数。
|
||||
|
||||
### 2.4 允许普通句子存在
|
||||
|
||||
不是每句都要“像结论”。如果一句普通事实句已经够用，就不要再补“这说明了什么”“本质上意味着什么”。
|
||||
|
||||
长文里的普通承接句也可以存在。`另外`、`与此同时`、`也就是说`、`换个角度看` 这类连接，如果后面接的是具体事实、经验或判断，不要直接归到总结式收尾或 narrator 腔。先保住它的承接作用，再看句内有没有空泛修饰需要压低。
|
||||
|
||||
更好：
|
||||
|
||||
> 这次先把权限边界补上，避免游客也能看到内部页面。
|
||||
|
||||
不够好：
|
||||
|
||||
> 这不仅仅是一次权限修复，更体现了我们对产品边界和安全性的深度思考。
|
||||
|
||||
### 2.5 统一语域，不装另一种人
|
||||
|
||||
`chat` 可以自然，但别端着；`docs` 可以专业，但别演洞见；`public-writing` 可以有判断，但别像公告或喊单。
|
||||
|
||||
语域一致也包括时代感。一篇当下的第一人称口语文里混进上世纪报刊散文腔（`蓦然`、`心中一暖`）或 2000 年代博客腔（`写在最后`、`与君共勉`），突兀程度和场景腔混搭相当，只是方向不同。这类词多数不是 AI 高频词，不进词表，按主语域判断：主语域是当代口语就换成今天的说法，怀旧题材、年代小说、刻意复古的文风放行。
|
||||
|
||||
### 2.6 有边界比硬演理解更自然
|
||||
|
||||
可以温和，但别替对方做心理判断，也别把“我现在完全懂你了”演成内容本身。
|
||||
|
||||
更好：
|
||||
|
||||
> 我在听。如果你愿意，可以继续说。
|
||||
|
||||
不够好：
|
||||
|
||||
> 你不是敏感，你只是太久没被稳稳接住了。我必须认真地说一句：你比大多数人都清醒。
|
||||
|
||||
## 3. Scene calibration
|
||||
|
||||
### `chat`
|
||||
|
||||
目标：
|
||||
|
||||
- 像在回应对方，不像在发表说明
|
||||
- 可以口语，但不要谄媚、教学腔、总结腔，也不要替对方下心理结论
|
||||
|
||||
更好的迹象：
|
||||
|
||||
- 直接回答
|
||||
- 有回应关系
|
||||
- 有一点自然停顿，但不拖
|
||||
|
||||
### `status`
|
||||
|
||||
目标：
|
||||
|
||||
- 读完能知道进展、问题和下一步
|
||||
- 重点是时间线和结果，不是“完成了一次重要升级”
|
||||
|
||||
更好的迹象：
|
||||
|
||||
- 动作和结果分得清
|
||||
- 风险没被写轻
|
||||
- 如果有数字、结论、归属，能一眼找到
|
||||
|
||||
### `docs`
|
||||
|
||||
目标：
|
||||
|
||||
- 读起来像说明文，不像宣传文
|
||||
- 专业词能保留，句子只做必要收束
|
||||
|
||||
更好的迹象：
|
||||
|
||||
- 可检索词还在
|
||||
- 句子更直，但术语没散
|
||||
- 不为了“更像人”把正式说明改成闲聊
|
||||
|
||||
### `public-writing`
|
||||
|
||||
目标：
|
||||
|
||||
- 有判断，但判断来自事实和经验，不来自空抬
|
||||
- 可以有节奏，但不要吆喝、喊口号、假装深刻
|
||||
|
||||
更好的迹象：
|
||||
|
||||
- 能看出作者到底想说什么
|
||||
- 少用“时代”“变革”“真正的 X”这类泛大词
|
||||
- 保留必要修辞，但不把段落写成海报文案
|
||||
|
||||
## 4. Cleaner vs more human
|
||||
|
||||
下面这几组不是“唯一正确答案”，而是展示差别在哪里。
|
||||
|
||||
### A. `status`
|
||||
|
||||
原文：
|
||||
|
||||
> 本次优化显著提升了系统整体性能，并有效改善了用户体验。
|
||||
|
||||
清理后但还偏 AI：
|
||||
|
||||
> 这次优化提升了系统性能，也改善了用户体验。
|
||||
|
||||
更像人：
|
||||
|
||||
> 这次主要改了查询链路。首页接口从 800ms 降到 120ms，之前那批卡顿反馈也少了很多。
|
||||
|
||||
差别：
|
||||
|
||||
- 第一版只是把夸张词削弱了
|
||||
- 第二版把“提升了什么”说具体了
|
||||
|
||||
### B. `docs`
|
||||
|
||||
原文：
|
||||
|
||||
> 该能力不是一个简单的配置选项，而是一套面向未来的系统性机制。
|
||||
|
||||
清理后但还偏 AI：
|
||||
|
||||
> 该能力不是简单的配置选项，而是一套系统机制。
|
||||
|
||||
更像人：
|
||||
|
||||
> 这不是单个配置项。它会一起改缓存策略、重试逻辑和超时设置。
|
||||
|
||||
差别：
|
||||
|
||||
- 第一版还保留了拔高骨架
|
||||
- 第二版直接解释它具体会动到什么
|
||||
|
||||
### C. `public-writing`
|
||||
|
||||
原文：
|
||||
|
||||
> 真正的竞争力不是功能堆砌，而是体验细节。
|
||||
|
||||
清理后但还偏 AI：
|
||||
|
||||
> 竞争力不在功能堆砌，在体验细节。
|
||||
|
||||
更像人：
|
||||
|
||||
> 功能补得再快，如果延迟高、引导乱、错误提示看不懂，用户还是不会留下来。
|
||||
|
||||
差别：
|
||||
|
||||
- 第一版只是把句子缩短
|
||||
- 第二版把判断落回具体体验
|
||||
|
||||
## 5. Final check
|
||||
|
||||
提交改写前，再问自己这 5 件事：
|
||||
|
||||
1. 这段是在说事，还是还在演“我很会总结”
|
||||
2. 关键判断有没有落到动作、结果、例子或条件上
|
||||
3. 句子是不是顺了，但没被抹成同一种腔
|
||||
4. 当前场景下，正式度有没有被改坏
|
||||
5. 如果要“更像人”就必须补新事实，那这一步应该停住
|
||||
|
||||
如果删完以后只剩空架子，不要补口号，优先补事实句。
|
||||
@@ -0,0 +1,239 @@
|
||||
# Protected Spans
|
||||
|
||||
> 本文件是解释、示例与操作细则；行为合同的单源是 `SKILL.md`，两处表述不一致时以 `SKILL.md` 为准。
|
||||
|
||||
> 在追求“更像人”之前，先把不能漂的片段保护住。
|
||||
|
||||
这份文档把 `SKILL.md` 里的 no-touch 原则展开成一个可执行的预检清单。
|
||||
`v1.7.0` 先采用 prompt 内 checklist，不要求额外输出 `facts ledger` 格式。
|
||||
|
||||
使用顺序：
|
||||
|
||||
1. 判场景
|
||||
2. 先扫一遍 protected spans
|
||||
3. 再做删句、并句、换主语、降调
|
||||
4. 回读时逐类核对 protected spans 是否还在
|
||||
|
||||
## 1. Protect first
|
||||
|
||||
先保护，再改写。默认要先划出来的内容有：
|
||||
|
||||
划定时分清两种要求：数值、名称、标识符、正式术语和引用原文按字面保留；状态、实验结果、条件与比较关系按含义保留，允许等义清理其中的非正式包装措辞。不是所有“带数字的结果短语”都是一个逐字禁改的 span。
|
||||
|
||||
例如普通进度说明 `质量复核只闭环了 3/10 组，另外 7 组未完成`，可改为 `质量复核只完成了 3/10 组，另外 7 组未完成`：数值、对象和部分完成状态都没变。若原文明确是字段名、日志原文或被讨论的术语，则仍逐字保留，不套这个改法。
|
||||
|
||||
### 1.1 Numbers, dates, ranges, units
|
||||
|
||||
- 数字
|
||||
- 百分比
|
||||
- 时间
|
||||
- 日期
|
||||
- 版本号
|
||||
- 区间
|
||||
- 时间范围与时间跨度（如“未来十年”“over the next decade”“三个月内”）
|
||||
- 单位
|
||||
|
||||
默认规则：
|
||||
|
||||
- 不改数值
|
||||
- 不随手四舍五入
|
||||
- 不把精确说法改成模糊说法
|
||||
- 不放大、缩小或模糊化时间跨度
|
||||
- 不补原文没有的比较项
|
||||
- 删除整句时按无源引用规则处理；如果保留相关论断，不得把原时间跨度改成另一个跨度
|
||||
|
||||
### 1.2 Names and attribution
|
||||
|
||||
- 人名
|
||||
- 组织名
|
||||
- 产品名
|
||||
- 模块名
|
||||
- 服务名
|
||||
- issue / PR / RFC 编号
|
||||
- 责任主体和观点归属
|
||||
|
||||
默认规则：
|
||||
|
||||
- 不换主体
|
||||
- 不模糊“谁做的 / 谁说的 / 谁负责”
|
||||
- 不把原来的判断改成像是别人已经证明过
|
||||
|
||||
### 1.3 Quoted text and titles
|
||||
|
||||
- 引号内原文
|
||||
- 引用规范
|
||||
- 文章标题
|
||||
- 报告名
|
||||
- 原话里的关键词
|
||||
|
||||
默认规则：
|
||||
|
||||
- 引号内容默认原样保留
|
||||
- 只在用户明确要求时改引号内正文
|
||||
- 不把引用改写成概述后再塞回引号
|
||||
|
||||
### 1.4 Commands, code, params, fields, paths
|
||||
|
||||
- 命令
|
||||
- 代码块
|
||||
- 接口名
|
||||
- 参数名
|
||||
- 字段名
|
||||
- 配置项
|
||||
- 文件路径
|
||||
- 环境变量
|
||||
|
||||
默认规则：
|
||||
|
||||
- 拼写、大小写、符号、下划线、连字符都保留
|
||||
- 不翻译代码语义
|
||||
- 不把注释外的技术片段改成人话
|
||||
|
||||
### 1.5 Errors, logs, statuses, metrics
|
||||
|
||||
- 报错信息
|
||||
- 日志原文
|
||||
- HTTP 状态码
|
||||
- 指标名
|
||||
- 实验结果
|
||||
- 监控数值
|
||||
- 结论里的度量关系
|
||||
|
||||
默认规则：
|
||||
|
||||
- 不换错误类型
|
||||
- 不丢时间范围、样本范围、比较基线
|
||||
- 不把“观察到”改成“已经证明”
|
||||
|
||||
## 2. What may change around them
|
||||
|
||||
逐字保护片段外的这些内容通常可以改；表达状态或结果的普通叙述，也可以在含义不变的前提下清理这些包装：
|
||||
|
||||
- 开场套话
|
||||
- 总结式收尾
|
||||
- 商业黑话
|
||||
- narrator 腔
|
||||
- 姿态层
|
||||
- 空洞判断包装
|
||||
|
||||
可以做的动作：
|
||||
|
||||
- 删掉 span 前后的废话
|
||||
- 调整句序，但不改变事实关系
|
||||
- 把抽象结论压回具体动作
|
||||
- 合并重复句，但不要吞掉保护项
|
||||
|
||||
如果一句话只有靠改 protected span 才能变自然，优先保真，宁可保留一点生硬。
|
||||
|
||||
## 3. Scene notes
|
||||
|
||||
### `status`
|
||||
|
||||
重点保护：
|
||||
|
||||
- 时间线
|
||||
- 当前判断
|
||||
- 下一步
|
||||
- 风险归属
|
||||
- 指标和范围
|
||||
|
||||
不要为了更顺，把“风险”“阻塞”“未确认”改轻。
|
||||
|
||||
### `docs`
|
||||
|
||||
重点保护：
|
||||
|
||||
- 术语
|
||||
- 条件
|
||||
- 顺序
|
||||
- 命令
|
||||
- 配置
|
||||
- 系统主语
|
||||
|
||||
不要为了口语化牺牲可检索性。
|
||||
|
||||
### `code-context`
|
||||
|
||||
重点保护：
|
||||
|
||||
- 代码本体
|
||||
- 注释里描述的真实行为
|
||||
- 参数
|
||||
- 返回值
|
||||
- 约束条件
|
||||
|
||||
可以改注释的 AI 腔，但不能把函数行为改错。
|
||||
|
||||
### `mixed`
|
||||
|
||||
重点保护：
|
||||
|
||||
- 引用边界
|
||||
- 局部场景切换点
|
||||
- 引号、代码块、复盘块、公告块里的原有格式
|
||||
|
||||
先判哪里是正文，哪里是引用或嵌入块，再决定哪些区域能动。
|
||||
|
||||
## 4. Worked examples
|
||||
|
||||
### A. `status`
|
||||
|
||||
原文：
|
||||
|
||||
> 昨天把连接池上限从 20 调到 100，504 先压下来了。后面再观察 24 小时，如果错误率还在 0.1% 以下就全量。
|
||||
|
||||
保护项：
|
||||
|
||||
- `20`
|
||||
- `100`
|
||||
- `504`
|
||||
- `24 小时`
|
||||
- `0.1%`
|
||||
|
||||
可改部分：
|
||||
|
||||
- `先压下来了`
|
||||
- `后面再观察`
|
||||
|
||||
### B. `docs`
|
||||
|
||||
原文：
|
||||
|
||||
> 运行 `bin/migrate --tenant=prod` 后，如果日志出现 `schema mismatch`，先检查 `DB_SCHEMA_VERSION` 是否和线上一致。
|
||||
|
||||
保护项：
|
||||
|
||||
- `bin/migrate --tenant=prod`
|
||||
- `schema mismatch`
|
||||
- `DB_SCHEMA_VERSION`
|
||||
|
||||
可改部分：
|
||||
|
||||
- `先检查`
|
||||
- 前后解释层
|
||||
|
||||
### C. `mixed`
|
||||
|
||||
原文：
|
||||
|
||||
> 用户说“别改我这句，原样保留”。正文里只要把“值得注意的是”这类套话清掉就行。
|
||||
|
||||
保护项：
|
||||
|
||||
- `“别改我这句，原样保留”`
|
||||
|
||||
可改部分：
|
||||
|
||||
- 引号外的正文说明
|
||||
|
||||
## 5. Final check
|
||||
|
||||
回读时至少核对这 5 件事：
|
||||
|
||||
1. 数字、日期、单位、版本号有没有漂
|
||||
2. 主体、归属、责任关系有没有被换掉
|
||||
3. 引号、代码、命令、路径、参数有没有被改坏
|
||||
4. 错误、状态码、指标和比较关系有没有被写松
|
||||
5. 有没有为了“更像人”补进原文没有的事实、来源或判断
|
||||
|
||||
看不准时，优先保留 protected span，不要赌。
|
||||
@@ -0,0 +1,136 @@
|
||||
# 场景禁改表
|
||||
|
||||
> 本文件是解释、示例与操作细则；行为合同的单源是 `SKILL.md`，两处表述不一致时以 `SKILL.md` 为准。
|
||||
|
||||
先判场景，再判断哪些内容不能乱动。去模板感不等于把所有文本都改成一个口气。
|
||||
|
||||
只要环境里能读 `references/`，默认先用 [Protected Spans](./protected-spans.md) 划出不能漂的片段，再按这里的场景禁改项收窄改写范围。
|
||||
|
||||
本文件只定义大场景边界。README、release note、forum post、issue reply 这类更细的发布场景，即使初判像 `docs` 或 `status`，也要补看 [Scene Packs](./scene-packs.md)，同时保留这里更保守的事实和术语边界。
|
||||
|
||||
## `chat`
|
||||
|
||||
目标：
|
||||
|
||||
- 自然、直接、有回应感
|
||||
|
||||
默认档位：
|
||||
|
||||
- `minimal`
|
||||
|
||||
无源引用默认策略：
|
||||
|
||||
- `rewrite-safe`
|
||||
|
||||
不要乱动：
|
||||
|
||||
- 不要为了“去 AI 味”把回复改得更硬
|
||||
- 不要凭空拔高语气或补价值判断
|
||||
- 不要把简单回应改成总结陈词
|
||||
- 不要替对方做心理分析、关系诊断或空泛安抚
|
||||
|
||||
优先保留：
|
||||
|
||||
- 对话节奏
|
||||
- 具体回应关系
|
||||
- 合理的口语停顿
|
||||
- 用户明确要求保留的原话或引用片段
|
||||
|
||||
## `status`
|
||||
|
||||
目标：
|
||||
|
||||
- 事实密度高，读完知道进展、问题、下一步
|
||||
|
||||
默认档位：
|
||||
|
||||
- `minimal` 或 `standard`
|
||||
|
||||
无源引用默认策略：
|
||||
|
||||
- `audit-only`
|
||||
|
||||
不要乱动：
|
||||
|
||||
- 不要删时间线
|
||||
- 不要删责任归属
|
||||
- 不要把风险说轻
|
||||
- 不要为了“更像人”牺牲汇报效率
|
||||
|
||||
优先保留：
|
||||
|
||||
- 时间、动作、结果、风险、阻塞点
|
||||
- 数字、日期、范围和责任归属
|
||||
|
||||
## `docs`
|
||||
|
||||
目标：
|
||||
|
||||
- 可检索、可复现、可引用
|
||||
|
||||
默认档位：
|
||||
|
||||
- `minimal`
|
||||
|
||||
无源引用默认策略：
|
||||
|
||||
- `audit-only`
|
||||
|
||||
不要乱动：
|
||||
|
||||
- 不要破坏术语稳定性
|
||||
- 不要改掉检索词、命令、接口名、字段名
|
||||
- 不要为了口语化牺牲系统主语和命令式说明
|
||||
- 不要把正式说明改成闲聊体
|
||||
|
||||
优先保留：
|
||||
|
||||
- 术语
|
||||
- 系统行为主语
|
||||
- 步骤顺序
|
||||
- 限定条件
|
||||
- 命令、路径、参数、字段、报错和状态码
|
||||
|
||||
## `public-writing`
|
||||
|
||||
目标：
|
||||
|
||||
- 语域统一，有判断但不端着
|
||||
|
||||
默认档位：
|
||||
|
||||
- `standard`
|
||||
|
||||
无源引用默认策略：
|
||||
|
||||
- `rewrite-safe`
|
||||
|
||||
不要乱动：
|
||||
|
||||
- 不要为了节奏制造夸张判断
|
||||
- 不要把克制文风改成自媒体吆喝腔
|
||||
- 不要硬造金句
|
||||
- 不要把正式公告改成社媒评论
|
||||
|
||||
优先保留：
|
||||
|
||||
- 作者原有立场
|
||||
- 正常的正式度
|
||||
- 必要的修辞节奏
|
||||
- 已有事实、归属和可核对引用
|
||||
|
||||
长文补充：
|
||||
|
||||
- 中文长文（约 1000 字以上）默认优先 `bounded` scope，尤其是观点文、复盘文、评论文和带段落节奏的公开文本：句内洗实句、整句空话进「建议删除（待确认）」清单交用户拍板，不并句不重排
|
||||
- 用户明确要求“完全原样 / 一句都别删 / 严格保句数”，或反馈 `bounded` 仍删多了时，再切到更严格的 `in-place`（整句空话也不删，只句内降调）
|
||||
- 用户 prompt 含 `保长度 / 别缩水 / 字数 / 节奏 / 别删 / 尽量原样` 这类信号时，即使原文没到 1000 字，也按长文处理
|
||||
- `bounded / in-place` 下都不把整段压成短摘要；先保段落节奏和承担转场的重复，区别只在整句空话是“进删除清单”还是“留着只做句内降调”
|
||||
- 标点腔（[结构反模式](./structures.md) 第 20 条）是**句内动作**：破折号按语义改回冒号、逗号或断句，**不进「建议删除（待确认）」清单**；同段的整句空话仍照常进清单。两类动作分开走，不因为同一段里都有就混成一种处理
|
||||
|
||||
## 混合场景处理
|
||||
|
||||
如果一段文本同时命中多个场景：
|
||||
|
||||
1. 先判主要用途
|
||||
2. 先划 protected spans，再以主场景的禁改项为上限
|
||||
3. 只清理次场景里明显突兀的词，不追求绝对纯化
|
||||
@@ -0,0 +1,261 @@
|
||||
# Scene Packs / 可直接发场景包
|
||||
|
||||
> 本文件是解释、示例与操作细则；行为合同的单源是 `SKILL.md`，两处表述不一致时以 `SKILL.md` 为准。
|
||||
|
||||
Scene Packs 是面向可发布文本的子场景策略。它不替代 [场景禁改表](./scene-guardrails.md)、[Protected Spans](./protected-spans.md) 或 `Tier` 判断；只要文本本身像 README、release note、forum post、issue reply、API reference 或 FAQ，就进一步判断“这段应该像哪一种发布文本”。
|
||||
|
||||
使用顺序：
|
||||
|
||||
1. 先判大场景：`chat / status / docs / public-writing`
|
||||
2. 先划 protected spans：版本号、路径、链接、命令、引用、编号、责任归属都不能漂
|
||||
3. 再看是否命中本文件的 scene pack
|
||||
4. 最后按 scene pack 的发布目的收束语气；如果它同时像 `docs / status`，取更保守的保真边界
|
||||
|
||||
默认不要因为 scene pack 新增全局词条。只有新样本已经超出现有问题族，且会改变误杀边界时，才考虑补 `phrases` 或 `structures`。
|
||||
|
||||
## `README`
|
||||
|
||||
默认目标：
|
||||
|
||||
- 第一屏能让读者快速知道：这是什么、给谁用、解决什么问题。
|
||||
- 语气可以有个性，但不能只剩愿景、价值和姿态。
|
||||
|
||||
必须保留：
|
||||
|
||||
- 项目名、目标用户、核心能力、支持平台
|
||||
- 命令、安装方式、文件路径、链接
|
||||
- 已有 benchmark 数量、版本号和能力边界
|
||||
|
||||
优先删除：
|
||||
|
||||
- `AI 全面重塑开发范式`
|
||||
- `面向未来`
|
||||
- `深度赋能`
|
||||
- `内容生产链路`
|
||||
- `价值闭环`
|
||||
- 没有具体能力或证据支撑的 `真正能 / 做快做稳 / 更像人写的` 等自我宣传结果句
|
||||
- 只说“先进 / 智能 / 全方位”但不说具体做什么的句子
|
||||
|
||||
默认力度：
|
||||
|
||||
- `standard`
|
||||
- 如果 intro 只剩口号，可以升到 `aggressive`，但不能编造项目能力
|
||||
|
||||
误杀边界：
|
||||
|
||||
- README intro 允许一句有辨识度的定位句
|
||||
- `CLI / API / benchmark / Codex / ChatGPT` 等项目术语应保留
|
||||
- 不要把 README 改成社交媒体短帖
|
||||
|
||||
Before:
|
||||
|
||||
> 在 AI 全面重塑开发范式的今天，我们打造了一款真正面向未来的中文表达优化工具，深度赋能开发者的内容生产链路。
|
||||
|
||||
After:
|
||||
|
||||
> `说人话` 是一个中文优先的 rewrite skill，用来把 AI 写出来的套话、表演感和工程师腔改回自然表达。适合 README、release note、issue 回复和日常协作文本。
|
||||
|
||||
## `release-note`
|
||||
|
||||
默认目标：
|
||||
|
||||
- 让读者快速知道这一版改了什么、怎么验证、有没有破坏性变化。
|
||||
- 优先列表化，少写发布宣言。
|
||||
|
||||
必须保留：
|
||||
|
||||
- 版本号、日期、文件名、配置项、issue / PR 编号
|
||||
- 变更类型：新增、修复、调整、测试
|
||||
- 已知限制和迁移提示
|
||||
|
||||
优先删除：
|
||||
|
||||
- `Release Highlights` 后面只写空泛升级
|
||||
- `系统性升级`
|
||||
- `全新跃迁`
|
||||
- `感谢所有用户持续支持`
|
||||
- `共同见证`
|
||||
- 没有来源的性能、效率、用户反馈数据
|
||||
|
||||
默认力度：
|
||||
|
||||
- `standard`
|
||||
- 如果缺少具体 changelog，不要编造；改成提示“这里需要补具体变更”
|
||||
|
||||
误杀边界：
|
||||
|
||||
- release note 可以正式、简洁、列表化
|
||||
- 不要为了“像人”把 changelog 列表改成故事
|
||||
- 不要删版本号、文件路径、case 数量和 PR / issue 编号
|
||||
|
||||
Before:
|
||||
|
||||
> 本次版本是一次面向真实场景的系统性升级，感谢所有用户的持续支持，让我们共同见证中文 AI 写作体验的全新跃迁。
|
||||
|
||||
After:
|
||||
|
||||
> - 新增 `references/scene-packs.md`，覆盖 README、release note、forum post 和 issue reply
|
||||
> - `evals/benchmark.md` 增加 8 条 scene pack 回归用例
|
||||
> - 新增 `evals/results-v1.8.0.md` 记录本轮复核结果
|
||||
|
||||
## `forum-post`
|
||||
|
||||
默认目标：
|
||||
|
||||
- 像维护者在社区里讲真实观察：做了什么、发现什么、哪里还不稳、想要什么反馈。
|
||||
- 允许口语，但要有具体经历支撑。
|
||||
|
||||
必须保留：
|
||||
|
||||
- 时间、动作、具体文件、样本数量、观察到的问题
|
||||
- 原作者真实态度和社区语气
|
||||
- 链接、命令、版本号和被讨论词
|
||||
|
||||
优先删除：
|
||||
|
||||
- 公司公告腔
|
||||
- `系统性重塑`
|
||||
- `用户痛点`
|
||||
- `多元场景`
|
||||
- `方法论闭环`
|
||||
- `稳稳接住核心诉求`
|
||||
|
||||
默认力度：
|
||||
|
||||
- `standard`
|
||||
- 如果帖子本来有具体经历，只清理姿态层，不要改成正式公告
|
||||
|
||||
误杀边界：
|
||||
|
||||
- 具体经历后的口语词可以保留
|
||||
- 社区帖允许“踩坑 / 折腾 / 还差一点”这类真实语气
|
||||
- 不要把个人复盘改成 README 或 release note
|
||||
|
||||
Before:
|
||||
|
||||
> 折腾这个工具一个月后，我深刻意识到，中文 AI 写作治理不是一次简单的词表扩张，而是一场围绕真实表达场景的系统性重塑。
|
||||
|
||||
After:
|
||||
|
||||
> 做这个工具一个月后，我发现光删词表不够。README、release note、issue 回复和论坛帖看起来都是“公开文本”，但改法其实不一样。
|
||||
|
||||
## `issue-reply`
|
||||
|
||||
默认目标：
|
||||
|
||||
- 先回答问题是否成立，再给复现状态、判断和下一步。
|
||||
- 不做客服式安抚，不替维护者承诺未排期能力。
|
||||
|
||||
必须保留：
|
||||
|
||||
- bad case 原句、场景标签、复现结果
|
||||
- issue / PR 编号、文件路径、规则名、benchmark 编号
|
||||
- “已确认 / 未复现 / 需要更多样本 / 会补测试”的状态
|
||||
|
||||
优先删除：
|
||||
|
||||
- `感谢宝贵反馈`
|
||||
- `你问到了核心`
|
||||
- `我们已经充分接住这个场景`
|
||||
- `持续优化相关能力`
|
||||
- `如果你愿意我可以继续帮你`
|
||||
|
||||
默认力度：
|
||||
|
||||
- `minimal` 或 `standard`
|
||||
- 有具体技术信息时保守处理；没有具体下一步时，不要编造排期
|
||||
|
||||
误杀边界：
|
||||
|
||||
- issue 回复可以短、硬、直接
|
||||
- `bad case / docs / SNF / benchmark / repro` 是维护语境里的正常术语
|
||||
- 不要把明确的维护回复改成社交式寒暄
|
||||
|
||||
Before:
|
||||
|
||||
> 感谢你非常宝贵的反馈！你这个问题问到了项目体验的核心。我们已经充分接住了这个场景，也会在后续版本中持续优化相关能力。
|
||||
|
||||
After:
|
||||
|
||||
> 收到，这个 case 我能复现。它属于 `docs` 场景里的误杀，下一版先补一条 SNF；如果现有规则已经能放行，就只加回归用例。
|
||||
|
||||
## `api-reference`
|
||||
|
||||
默认目标：
|
||||
|
||||
- 让读者快速确认接口用途、调用条件、请求约束、响应语义、错误含义和恢复动作。
|
||||
- 保持可扫描结构；参数表、字段列表和代码示例不改成叙事段落。
|
||||
|
||||
必须保留：
|
||||
|
||||
- HTTP method、路径、接口名、鉴权方式
|
||||
- 字段名、类型、格式、required / optional、默认值、范围、单位、依赖关系和枚举
|
||||
- 状态码、错误码、代码、JSON、命令、链接、版本、速率限制和已给出的恢复步骤
|
||||
|
||||
优先删除：
|
||||
|
||||
- 接口说明前的价值拔高、宣传口号和元评论
|
||||
- 重复解释 endpoint 或参数名的空话
|
||||
- 没有来源的行业判断、性能保证和可用性承诺
|
||||
- 把明确动作藏进 `能力建设 / 机制实现 / 体验升级` 的名词化外壳
|
||||
|
||||
默认力度：
|
||||
|
||||
- `minimal`
|
||||
- 只改说明文字；表格、列表、代码块、JSON 和标识符不动
|
||||
|
||||
误杀边界：
|
||||
|
||||
- 原文没有的默认值、条件、错误原因、恢复时间、兼容范围一律不补；缺失就按 `audit-only` 标待确认
|
||||
- 状态码按当前接口里的真实语义理解，不机械套固定文案
|
||||
- 系统主语和真实被动语态可以保留；不要为了主动、口语而改变责任主体
|
||||
- 不为避免重复而给同一字段换同义叫法，不把 optional 改成 required，不换算数字或单位
|
||||
|
||||
Before:
|
||||
|
||||
> `GET /v1/reports/{report_id}` 是面向未来的智能查询接口，能让团队高效查看报告状态。查询参数 `format` 支持 `json` 和 `csv`。
|
||||
|
||||
After:
|
||||
|
||||
> `GET /v1/reports/{report_id}` 查询报告状态。查询参数 `format` 支持 `json` 和 `csv`。
|
||||
|
||||
## `faq`
|
||||
|
||||
默认目标：
|
||||
|
||||
- 问题范围准确；尽早给出结论、判断或动作，但不能把原有执行前条件和警告移到操作之后。
|
||||
- 标题保留用户会实际检索的问法，不改成宣传标题或抽象分类。
|
||||
|
||||
必须保留：
|
||||
|
||||
- 问题里的对象、版本、条件、否定和例外
|
||||
- 答案里的期限、费用、支持承诺、责任主体、命令、链接、路径和编号
|
||||
- 排障步骤的顺序与分支
|
||||
- 原有执行前条件、警告与动作的先后关系；真实的事后验证和失败分支不能改成前置步骤。结构调整仍受 scope 限制，不主动替作者重排操作流程或补出原文没有的风险、备份、恢复步骤
|
||||
|
||||
优先删除：
|
||||
|
||||
- 重复一遍问题才开始回答
|
||||
- 假共情、客服寒暄和销售式安抚
|
||||
- `大家都知道 / 通常都可以 / 一定没问题` 这类无源保证
|
||||
- 与答案无关的价值总结
|
||||
|
||||
默认力度：
|
||||
|
||||
- `minimal`
|
||||
- 已经短、硬、可执行的答案整体放行
|
||||
|
||||
误杀边界：
|
||||
|
||||
- 不把采访、讨论引用或所有带问号的段落都识别成 FAQ
|
||||
- 不把 `可能` 改成 `会`，不把 `部分用户` 改成 `所有用户`，不扩大支持承诺
|
||||
- 不软化 `不支持 / 必须 / 不会` 等真实限制，也不改期限、政策和操作路径
|
||||
- 缺条件或来源时标出缺口，不自造 SLA、恢复时间、默认路径或客服电话
|
||||
|
||||
Before:
|
||||
|
||||
> 非常理解导出日志失败给你带来的困扰。关于导出日志失败怎么办，我们准备了简单方案：先运行 `shuorenhua logs export`。如果命令返回退出码 `2`，检查输出路径是否可写。
|
||||
|
||||
After:
|
||||
|
||||
> 先运行 `shuorenhua logs export`。如果命令返回退出码 `2`，检查输出路径是否可写。
|
||||
@@ -0,0 +1,85 @@
|
||||
# 严重度分级
|
||||
|
||||
> 本文件是解释、示例与操作细则；行为合同的单源是 `SKILL.md`，两处表述不一致时以 `SKILL.md` 为准。
|
||||
|
||||
> 不是所有 AI 味词汇都应该一刀切。分级处理减少误杀，保留自然表达。
|
||||
|
||||
## 分级定义
|
||||
|
||||
### Tier 1：默认替换
|
||||
|
||||
**定义**：在 AI 生成文本中出现频率是人类文本的 5–20 倍。
|
||||
|
||||
**处理**：默认替换为具体表达或直接删除。但在误杀防护场景（见下方）中允许保留。
|
||||
|
||||
**中文典型词**：赋能、助力、打造、抓手、闭环、颗粒度、值得注意的是、综上所述、深远影响、前所未有、稳稳兜住、落盘、收口、根因（非技术报告场景）、保姆级、绝绝子、拭目以待
|
||||
|
||||
**英文典型词**：delve, landscape, tapestry, leverage, pivotal, testament, showcases, underscores, nestled, vibrant, groundbreaking, game-changer, serves as
|
||||
|
||||
---
|
||||
|
||||
### Tier 2：同段聚集时标记
|
||||
|
||||
**定义**：单独出现时完全合理，但同一段落中聚集出现就是 AI 味信号（阈值见下方长度参考）。
|
||||
|
||||
**处理**：保留最贴切的一个，其余替换或改写句式。
|
||||
|
||||
**长度参考**：
|
||||
- 短段落（< 100 字/词）：同段 2+ 个即标记
|
||||
- 长段落（≥ 100 字/词）：同段 3+ 个再标记；2 个散落在长段不同位置时可放行
|
||||
|
||||
**中文典型词**：然而、此外、与此同时、显著、有效、全面、积极、持续、进一步、充分、恰恰、正是、无疑、可谓、堪称
|
||||
|
||||
**英文典型词**：harness, navigate, foster, elevate, unleash, nuanced, crucial, multifaceted, transformative, cornerstone, paramount
|
||||
|
||||
---
|
||||
|
||||
### Tier 3：全文密度高时标记
|
||||
|
||||
**定义**：正常的常见词，只在全文中出现频率明显高于正常写作时才是问题。
|
||||
|
||||
**判断方法**：按文本长度归一化判断——
|
||||
- 短文本（< 200 字/词）：同一个 Tier 3 词出现 3+ 次
|
||||
- 中等文本（200–1000 字/词）：同一个 Tier 3 词出现 5+ 次
|
||||
- 长文本（> 1000 字/词）：同一个 Tier 3 词占比 > 0.5%
|
||||
|
||||
**处理**：删掉多余的那几次，或把其中一部分换成具体信息（`响应从 800ms 降到 120ms`、`少写三分之一样板代码`）。
|
||||
|
||||
**不要用同义词轮换来降密度。** `重要 → 关键 → 核心` 这种换词躲重复本身就是模型腔：人写东西不怕重复同一个词，模型才会第二次换近义词、第三次再换一个。同义词替换只是把密度问题变成油滑感，密度还在。详见 [结构反模式](./structures.md) 第 22 条「同义词躲避」，行为合同见 `SKILL.md`「不用机械同义词替换表」。
|
||||
|
||||
**中文典型词**：重要、关键、核心、创新、优化、提升、推动、确保、实现、促进
|
||||
|
||||
**英文典型词**：significant, innovative, effective, dynamic, compelling, unprecedented, exceptional, comprehensive, robust, seamless
|
||||
|
||||
---
|
||||
|
||||
## 决策流程
|
||||
|
||||
```
|
||||
遇到可疑词汇
|
||||
├─ 是否命中误杀防护？→ 是 → 放行
|
||||
├─ 在 Tier 1 列表中？→ 默认替换
|
||||
├─ 在 Tier 2 列表中？
|
||||
│ ├─ 短段落且同段 2+？→ 标记，保留一个
|
||||
│ ├─ 长段落且同段 3+？→ 标记，保留一个
|
||||
│ └─ 未达阈值？→ 放行
|
||||
└─ 在 Tier 3 列表中？
|
||||
├─ 超过密度阈值？→ 删掉多余的几次，或换成具体信息（不换同义词）
|
||||
└─ 未超过？→ 放行
|
||||
```
|
||||
|
||||
## 误杀防护
|
||||
|
||||
以下场景即使命中词表也不应修改：
|
||||
|
||||
1. **引用原文**：引用他人原话或文档原文时保留原样
|
||||
2. **术语定义**：当这个词本身是被讨论的对象时（如"什么是赋能"）
|
||||
3. **代码/配置**：技术名词、变量名、API 名称不改
|
||||
4. **特定行业语境**：某些词在特定行业是标准术语（如金融领域的"杠杆"就是 leverage）
|
||||
5. **技术描述中的系统主语**：描述系统、服务、组件行为时，非人主语是合理的（如"网关返回 504"）
|
||||
6. **技术报告中的工程术语**：按词在句子里的技术含义放行，例如故障分析中的“根因”、迭代计算中的“收敛”，不要求另附术语表。报告体裁、相邻命令或数字不让整段自动免改；“完成闭环”“以某口径收口”等进展包装仍需按实际语义判断。若词本身是讨论对象、引用原文或用户明确要求保留的项目名称，则保留，不机械替换。
|
||||
7. **真人网络用语**：当博主在具体经历后自然使用"踩坑""谁懂啊"，且有具体细节支撑时，不是 AI 腔
|
||||
8. **英文技术字面动词**：`navigate`、`traverse`、`route` 等在图算法、网络拓扑、路径搜索等字面技术语境中可保留
|
||||
9. **学术或实验语体中的正常被动**：研究论文、实验报告、paper 摘要中的 `was conducted`、`was published` 之类常规被动不应机械改写
|
||||
10. **具备具体证据的真人 debug 对话**：如果对话里有具体参数、操作、时长、观察结果，像 `root cause`、`打满` 这类技术口语可保留
|
||||
11. **中英混排句中的英文词**：中文句子里夹带的英文词按该词在当前句子中的实际语义判断，不机械套 `phrases-en` 词表。例如"这次 refactor 的 leverage 点在缓存"里的 `leverage` 是商业黑话，应处理；"用 10 倍 leverage 做空"里的 `leverage` 是金融术语，应保留
|
||||
@@ -0,0 +1,402 @@
|
||||
# 结构反模式（跨语言）
|
||||
|
||||
> 本文件是解释、示例与操作细则；行为合同的单源是 `SKILL.md`，两处表述不一致时以 `SKILL.md` 为准。
|
||||
|
||||
> 这些模式不是某个词的问题，而是句子和段落层面的 AI 痕迹。中英文通用。
|
||||
|
||||
## 1. 二元对比假戏剧
|
||||
|
||||
**模式**：先否定 X，再肯定 Y，制造虚假的顿悟感。
|
||||
|
||||
```
|
||||
❌ 这不是技术问题，而是管理问题。
|
||||
❌ It's not about the code. It's about the culture.
|
||||
```
|
||||
|
||||
```
|
||||
✅ 管理流程比代码本身更容易出问题。
|
||||
✅ The culture around code review matters more than the code itself.
|
||||
```
|
||||
|
||||
**检测**：看密度和分布，不看单次出现。**先按下面「保留条件」把豁免项剔除，再对剩下的计数**——豁免项不计入密度，也不因为密度超标被改；只有剩余项超标才处理。这样改完的输出重新过一遍规则不会再次命中。命中信号：
|
||||
|
||||
- 同段连续 2 组以上（含与价值拔高骨架混合叠加）
|
||||
- 全文按长度归一（计数口径同 [严重度分级](./severity.md)：中文按字数，英文按词数，代码片段 / 路径 / 命令 / 版本号各计 1，标点和空白不计）：< 300 字/词 出现 2 处以上；300–1000 字/词 出现 3 处以上；> 1000 字/词 平均每 300 字/词 1 处以上
|
||||
- 变体同样计入：`不像 A，像 B`、`要的是 X，不是 Y`、`X 不行，Y 才行`，以及连续多条以否定收尾的列表项或表格行
|
||||
- 跨句变体和换字变体一样计入：`不是 A。而是 B`（句号断开）、`与其说 A，毋宁说 B`、`你以为 A，其实 B`、`我一直以为 A，后来才发现 B`、`回头才发现`、`大家都说 A，可真相是 B`、`答案恰恰相反`、`真正值钱的从来都与 A 无关`。这里管的是「先立一个读者并没有的误解，再推翻它抬价」这个动作，换任何字面都算；**判据和豁免口径不变**，仍按本条的密度阈值和豁免上限处理，不因为变体多就升级成一刀切
|
||||
- 读到后面能预判下一句形状
|
||||
|
||||
**默认动作**：豁免项原样保留；剩余超标的骨架按 `in-place` 替代动作换成中性连接或直接陈述（`X 不够，Y 更重要`、`相比 X，Y 更能说明问题`），两边信息都要保留。只把 `不是 X，是 Y` 倒装成 `Y，不是 X` 不算完成降密度——骨架还在。不要见一个杀一个，也不要把豁免项一起抹平成同一种平铺句。
|
||||
|
||||
**保留条件**：豁免上限 2 处。超过 2 处都声称「承担论证」时不再逐条豁免——每一处都说得出理由，恰恰是骨架依赖的表现，仍按密度处理。逐条判据：
|
||||
|
||||
- **术语定义**（最多 1 处，通常在首句或定位句）：`X 不是 A，是 B` 用来纠正读者对 X 是什么的误读
|
||||
- **论证骨架**（最多 1 处）：前半句是读者会真实持有的误解，且删掉它之后，后文的数据、结论或动作会失去依据——「读起来气势弱一点」不算
|
||||
- **引用原文、被讨论对象**：不计入密度，也不受上述数量上限约束
|
||||
|
||||
SF-40 那类「作者刻意用对比结构承载全文论点」属于用例级例外，判据和理由记在 [benchmark-tiers.md](../evals/benchmark-tiers.md) 的例外表，不作为通用豁免口。
|
||||
|
||||
## 2. 否定式列举
|
||||
|
||||
**模式**：先说不是什么，再说是什么。绕了一圈。
|
||||
|
||||
```
|
||||
❌ 它不是框架，不是库，也不是工具——它是一种思维方式。
|
||||
❌ It's not a framework. It's not a library. It's a way of thinking.
|
||||
```
|
||||
|
||||
```
|
||||
✅ 把它当作一种思维方式，不是一个具体工具。
|
||||
✅ Think of it as a mental model, not a tool.
|
||||
```
|
||||
|
||||
## 3. 戏剧化碎句
|
||||
|
||||
**模式**：用句子碎片制造假的力量感。
|
||||
|
||||
```
|
||||
❌ 三年。两个人。一个想法。
|
||||
❌ Three years. Two people. One idea.
|
||||
```
|
||||
|
||||
```
|
||||
✅ 两个人花了三年把这个想法做成了产品。
|
||||
✅ Two people spent three years turning the idea into a product.
|
||||
```
|
||||
|
||||
## 4. 反问式铺垫
|
||||
|
||||
**模式**：用反问或"如果"开头吊胃口。
|
||||
|
||||
```
|
||||
❌ 如果我告诉你，90% 的创业公司都在犯同一个错误呢？
|
||||
❌ What if I told you 90% of startups make the same mistake?
|
||||
```
|
||||
|
||||
```
|
||||
✅ 90% 的创业公司在定价上犯同一个错误：按成本定价而不是按价值定价。
|
||||
✅ 90% of startups misprice their product, using cost-based pricing instead of value-based.
|
||||
```
|
||||
|
||||
## 5. 虚假主语（False Agency）
|
||||
|
||||
**模式**：给无生命的事物安上人类动作（"赋能""助力""驱动"）。当句子抽象空泛、没有具体信息时优先改写。技术文档中描述系统行为的非人主语（"网关返回 504""缓存过期"）是合理的，不需要改。
|
||||
|
||||
```
|
||||
❌ 该框架赋能了开发者社区。
|
||||
❌ The framework empowers the developer community.
|
||||
```
|
||||
|
||||
```
|
||||
✅ 开发者用这个框架能少写 30% 的样板代码。
|
||||
✅ Developers write 30% less boilerplate with this framework.
|
||||
✅ 网关在超时后返回 504。（技术描述，不改）
|
||||
```
|
||||
|
||||
## 6. 被动语态堆砌
|
||||
|
||||
**模式**：连续使用被动语态，隐藏动作执行者。研究论文、实验报告或正式学术摘要里的常规被动不一定要改。
|
||||
|
||||
```
|
||||
❌ 系统被优化后，性能被显著提升，用户体验被大幅改善。
|
||||
❌ The system was optimized, performance was improved, and user experience was enhanced.
|
||||
```
|
||||
|
||||
```
|
||||
✅ 我们优化了数据库查询，页面加载从 3 秒降到 0.8 秒。
|
||||
✅ We optimized database queries and cut page load time from 3s to 0.8s.
|
||||
```
|
||||
|
||||
```
|
||||
✅ The experiment was conducted by researchers at MIT.（学术语体，可保留）
|
||||
```
|
||||
|
||||
## 7. 三件套列举
|
||||
|
||||
**模式**：AI 偏爱三个一组。两个或一个往往更自然。
|
||||
|
||||
```
|
||||
❌ 创新、协作、卓越。
|
||||
❌ Innovation, collaboration, and excellence.
|
||||
```
|
||||
|
||||
```
|
||||
✅ 把东西做出来，做好。
|
||||
✅ Build things. Build them well.
|
||||
```
|
||||
|
||||
## 8. "首先…其次…最后…" 机械排列
|
||||
|
||||
**模式**：中文特有的机械递进，制造假的逻辑感。
|
||||
|
||||
```
|
||||
❌ 首先，我们需要明确目标；其次，制定计划；最后，执行落地。
|
||||
```
|
||||
|
||||
```
|
||||
✅ 先把目标定清楚，然后排优先级，边做边调。
|
||||
```
|
||||
|
||||
## 9. Wh- 开头句（英文特有）
|
||||
|
||||
**模式**：用 What/When/Where/Which/Who/Why/How 开头的句子在 AI 文本中过度集中。
|
||||
|
||||
```
|
||||
❌ What makes this approach unique is its simplicity.
|
||||
```
|
||||
|
||||
```
|
||||
✅ This approach works because it's simple.
|
||||
```
|
||||
|
||||
## 10. 总结式收尾
|
||||
|
||||
**模式**：每段或全文末尾用"总之""综上"做总结，重复已说过的内容。
|
||||
|
||||
```
|
||||
❌ 综上所述，该方案在性能、安全性和可维护性方面都表现优异。
|
||||
❌ In conclusion, this approach excels in performance, security, and maintainability.
|
||||
```
|
||||
|
||||
```
|
||||
✅ 删掉。前面说清楚了就不用再说一遍。
|
||||
✅ Delete it. If you said it clearly above, don't repeat it.
|
||||
```
|
||||
|
||||
## 11. 对称填充（Symmetry Padding）
|
||||
|
||||
**模式**：为了"平衡"而硬凑对仗，没有信息增量。
|
||||
|
||||
```
|
||||
❌ 既要保证速度，又要保证质量；既要创新突破，又要稳定可靠。
|
||||
```
|
||||
|
||||
```
|
||||
✅ 速度和质量之间我们优先质量。
|
||||
```
|
||||
|
||||
## 12. 无源引用
|
||||
|
||||
**模式**：用"研究表明""数据显示""专家指出"但不给具体来源，制造假的权威感。
|
||||
|
||||
```
|
||||
❌ 研究表明，远程办公能提高 30% 的生产力。
|
||||
❌ Studies show that remote work increases productivity by 30%.
|
||||
```
|
||||
|
||||
```
|
||||
✅ Stanford 2023 年的一项实验发现，全远程员工的代码提交量比混合办公多 13%。
|
||||
✅ A 2023 Stanford experiment found fully remote employees committed 13% more code than hybrid workers.
|
||||
```
|
||||
|
||||
## 13. 加粗滥用
|
||||
|
||||
**模式**：机械地给每个要点加粗，制造假的层次感。
|
||||
|
||||
```
|
||||
❌ **用户体验：** 界面全面升级。**性能优化：** 算法显著提升。**安全加固：** 新增端到端加密。
|
||||
```
|
||||
|
||||
```
|
||||
✅ 界面重新设计了，算法快了 2 倍，加了端到端加密。
|
||||
```
|
||||
|
||||
## 14. 分条列点强迫症
|
||||
|
||||
**模式**：任何内容都要 1. 2. 3. 分条，连简单回复也列点，制造假的条理感。
|
||||
|
||||
```
|
||||
❌ 关于这个问题，我的建议如下：
|
||||
1. 先检查配置文件
|
||||
2. 确认环境变量
|
||||
3. 重启服务
|
||||
```
|
||||
|
||||
```
|
||||
✅ 配置文件里的 DB_HOST 可能写错了，先看一眼。不是的话重启一下服务试试。
|
||||
```
|
||||
|
||||
## 15. 正能量收尾强迫症
|
||||
|
||||
**模式**：不管前面说了什么，最后一段必须上价值、给鸡汤、展望未来。
|
||||
|
||||
```
|
||||
❌ ……总之，让我们拥抱变化，积极迎接 AI 时代的无限可能！未来可期！
|
||||
```
|
||||
|
||||
```
|
||||
✅ 删掉。前面说完了就结束。
|
||||
```
|
||||
|
||||
## 16. 假口语化 / 硬凹网感
|
||||
|
||||
**模式**：AI 试图"接地气"时硬塞网络流行语（绝绝子、谁懂啊、真的会谢），反而更假。真人用这些词是随机的，AI 是批量的。
|
||||
|
||||
```
|
||||
❌ 姐妹们！这个工具真的绝绝子！谁懂啊，效率直接拉满！狠狠心动了！
|
||||
```
|
||||
|
||||
```
|
||||
✅ 这个工具确实好用，主要是批量处理的速度快，省了不少时间。
|
||||
```
|
||||
|
||||
## 17. 调试腔叙事
|
||||
|
||||
**模式**：AI 在编程场景中用 postmortem / SRE 口吻讲日常事务——"兜住""落盘""根因""收口"。把 debug 术语泛化到一切对话中。
|
||||
|
||||
```
|
||||
❌ 我已经把差异收窄了，根因基本坐实，接下来做一个更硬的排除法把问题打掉。
|
||||
```
|
||||
|
||||
```
|
||||
✅ 原因找到了：是缓存过期导致的。我把可能性排查了一遍，现在就剩这一个。
|
||||
```
|
||||
|
||||
## 18. 节奏单调（统计信号）
|
||||
|
||||
**模式**：AI 文本的节奏比人类均匀得多。两个子信号：
|
||||
|
||||
- **句长均匀**：每句话长度几乎一样（句长标准差约 1.2，人类约 4.7+）。表现为"读起来很平，没有呼吸感"。
|
||||
- **句式骨架重复**：同一种句法形状反复出现，最常见的是二元对比（`不是 X，是 Y`），其次是每一节末尾都落一个对仗短句。单句都成立，连着读能预判下一句形状。
|
||||
|
||||
**检测**：不是看单个词，而是看整段乃至全文的节奏。长短句应该交替出现；同型骨架的密度阈值见第 1 条。
|
||||
|
||||
**默认动作**：句长层面合并或拆分句子，制造长短交替；骨架层面按第 1 条先剔除豁免项，再改剩余超标的那几处。两个层面都不重写全文。
|
||||
|
||||
## 19. 价值拔高骨架
|
||||
|
||||
**模式**：先给一个事实，再用 `不仅仅是……更是……`、`真正的 X 不是……而是……`、`最后比拼的是……` 把句子抬高成“洞见”。
|
||||
|
||||
```
|
||||
❌ 这不仅仅是一个产品，更是一种信念的传承。
|
||||
❌ 真正的竞争力不是功能堆砌，而是体验细节。最后比拼的是执行效率。
|
||||
```
|
||||
|
||||
```
|
||||
✅ 这就是一个产品判断：体验细节决定它能不能长期被用下去。
|
||||
✅ 产品做得再多，最后还是看体验细节和执行效率。
|
||||
```
|
||||
|
||||
## 20. 标点腔（破折号过密）
|
||||
|
||||
**模式**：把英文 em-dash 的使用习惯带进中文——首句就用破折号起手，一段里连续多个 `——`，插入、转折、补充全靠破折号承接；常伴随分号连用、顿号乱炖和中英混排下的标点崩坏。跨模型现象，提示词往往压不住。
|
||||
|
||||
**检测**：看密度和位置，不看单次出现。计数单位是**插入处**，不是破折号符号：一对 `——插入内容——` 计一处，单个 `——` 承担转折或补充也计一处。命中信号：首句破折号起手、单段两处以上插入、连续多段都靠破折号承接。单个破折号不是问题，不要见一个杀一个。
|
||||
|
||||
```
|
||||
❌ 这个工具最打动我的是速度——打开就是结果。搜索、启动、剪贴板——所有操作都在一个输入框里——你甚至不用记快捷键。
|
||||
```
|
||||
|
||||
```
|
||||
✅ 这个工具最打动我的是速度：打开就是结果。搜索、启动、剪贴板，所有操作都在一个输入框里，你甚至不用记快捷键。
|
||||
```
|
||||
|
||||
```
|
||||
✅ 配置支持环境变量覆盖——容器部署时不用改文件——其余场景直接编辑 `config.toml`。
|
||||
```
|
||||
|
||||
最后一例只有**一处**成对插入（两个 `——` 符号构成一处），不命中密度信号，放行。
|
||||
|
||||
**默认动作**：多余的破折号按语义改回冒号、逗号、括号或直接断句；一段最多保留一处真正承担插入或递进的。
|
||||
|
||||
**保留条件**：标题和命名里的连接符（`todo — 终端待办`）；引用原文；破折号本身是讨论对象；全段仅一处且确实承担插入语气。
|
||||
|
||||
## 21. 动词名词化
|
||||
|
||||
**模式**：把动作压成"空动词 + 抽象名词"。句子变长，信息没变。`进行 / 实现 / 完成 / 开展 / 起到 / 具有` 后面跟一个动名词是典型信号。
|
||||
|
||||
```
|
||||
❌ 我们对流程进行了优化，实现了效率的显著提升。
|
||||
❌ 完成了对监控体系的梳理，起到了很好的支撑作用。
|
||||
❌ The team performed an optimization of the deployment workflow.
|
||||
```
|
||||
|
||||
```
|
||||
✅ 我们把流程改顺了，一个人一天能多处理 20 单。
|
||||
✅ 梳理了监控，现在报警能定位到具体服务。
|
||||
✅ The team simplified the deployment workflow.
|
||||
```
|
||||
|
||||
**检测**：`进行了 X` / `实现了 X 的 Y` / `完成了对 X 的 Y` / `起到了 X 的作用` / `具有 X 的意义` / `开展 X 工作`。英文对应 `perform an analysis of`、`conduct a review of`、`achieve an improvement in`。`automation/eval/hard_metrics.py --residual` 会报数（只报数不判死）。
|
||||
|
||||
**默认动作**：还原成直接的动词。还原后如果发现原句其实没说清谁做了什么，按「清理后的落点」合同处理，允许变短并标注缺口径，不补事实。
|
||||
|
||||
**保留条件**：法律、合同、公文、正式公告里的固定表述（`进行公示`、`予以受理`）；`docs` 里已经是稳定术语的名词化（`增量编译`、`执行计划生成`）；用户明确要求正式语体的对外材料。
|
||||
|
||||
## 22. 同义词躲避
|
||||
|
||||
**模式**：同一个东西在相邻几句里被迫换三种说法，而且一次比一次抽象。人写东西不怕重复关键词，模型第二次就换近义词、第三次再换一个，读起来发油。
|
||||
|
||||
```
|
||||
❌ 他开始学修表。这门手艺上手比想象中慢，练了半年才敢接活。后来这项技能成了他主要的收入来源。
|
||||
❌ The team shipped the parser. This component handles 4MB files. The module now runs in CI.
|
||||
```
|
||||
|
||||
```
|
||||
✅ 他开始学修表。修表上手比想象中慢，练了半年才敢接活。后来修表成了他主要的收入来源。
|
||||
✅ The team shipped the parser. It handles 4MB files and now runs in CI.
|
||||
```
|
||||
|
||||
**检测**：同一指称对象在相邻 2–3 句里换了 2 次以上说法，且换法是往上升格（`修表 → 这门手艺 → 这项技能`、`parser → component → module`）。代词（`它`、`这个`）不算——正常照应本来就该用代词。
|
||||
|
||||
**默认动作**：统一回最具体的那个说法，其余改成原词或代词。
|
||||
|
||||
**保留条件**：换的说法带来新信息或新限定（`修表 → 上门修表`）；两个说法指的其实不是同一个对象；术语与口语的对照本身就是文本在做的事（`索引 / index`）；引用原文。
|
||||
|
||||
**注意**：这一条同时约束改写动作本身。清理 [严重度分级](./severity.md) Tier 3 的高密度词时，不要用同义词轮换降密度——那会把密度问题换成这里的油滑感。
|
||||
|
||||
## 23. 连词过密
|
||||
|
||||
**模式**：`因为 / 所以 / 但是 / 同时 / 此外 / 然而 / 因此` 几乎每两句出现一个，条件连词 `如果 / 否则` 同属此类。中文小句靠语序和事理就能相接，连词堆砌是英文式显性衔接的搬运。
|
||||
|
||||
```
|
||||
❌ 因为店里生意不好，所以他决定把下午的时间用来学修表，同时也能多一门手艺。
|
||||
```
|
||||
|
||||
```
|
||||
✅ 店里生意不好，他下午闲着，就学起了修表，多一门手艺总没坏处。
|
||||
```
|
||||
|
||||
**检测**：**只在 `public-writing` 的叙事、观点、随笔类文本上判，`docs` / `status` / `code-context` 不判。** 这一条没有全局密度阈值，原因是实测数据直接否掉了全局判据。`automation/eval/hard_metrics.py --calibrate` 在 95 条语料上跑出：SNF（不该改）连词密度中位 5.26 / 千字，高于 SF（该改）的 0.00；**SNF 的最高值 81.08 还高于 SF 的最高值 80.00**。最硬的证据是 benchmark 里的一对同密度用例——SF-50（`public-writing` 叙事）80.00 / 千字该删一半，SNF-39（`docs` 迁移说明）81.08 / 千字一个都不能删。技术文本靠 `如果…否则`、`因为…所以` 承担条件和因果，按密度一刀切会优先误伤它们。
|
||||
|
||||
在适用场景内看分布，不看总量：连续三句每句都以连词开头，或同一个连词在一段里出现 3 次以上。
|
||||
|
||||
**默认动作**：删掉一半，读得断的地方不补回来。删完通读一遍，事理接不上的地方再放回最必要的那个。
|
||||
|
||||
**保留条件**：连词真的在承担转折、让步或因果，删掉会读错；`docs` 里的条件说明和步骤衔接；法律与规范文本；`status` 里的时间线因果。
|
||||
|
||||
## 24. 装饰性细节
|
||||
|
||||
**模式**：用具体的时间、天气、动作、物件伪造现场感。这些细节没有来源，也不改变后文任何判断，只负责让画面显得真实。假细节越具体，AI 味越重。
|
||||
|
||||
```
|
||||
❌ 凌晨三点，办公室只剩他一个人。窗外下着雨，桌上的咖啡早就凉了。他点了第三根烟，盯着屏幕上那行报错。
|
||||
```
|
||||
|
||||
```
|
||||
✅ 那个 bug 卡了他两天。最后发现是时区配置在容器里没生效，本地怎么测都测不出来。
|
||||
```
|
||||
|
||||
**检测**：两条同时成立才算命中——细节**没有来源**（不是用户提供的、不是可核验的），并且**删掉后文不变**（事实、判断、因果都不受影响）。只满足一条不算。这一条和第 16 条「假口语化」不同：那条抓的是硬塞网络流行语，这条抓的是伪造的生活细节。
|
||||
|
||||
**默认动作**：删掉。删完段落如果没了落点，用原文已有的信息重组，不补新细节。
|
||||
|
||||
**保留条件**：用户自己提供的经历细节，哪怕琐碎也保留；细节确实改变后文（`那天是周日，维修点没开门`）；虚构、小说、剧本里属于人物视角和行动的细节；`docs` 里的复现条件、环境说明和时间戳。
|
||||
|
||||
## 25. 借喻场混用
|
||||
|
||||
**模式**：同一段里从多套不相干的比喻系统借词。常见七套：道路竞赛、战争攻防、建筑灾害、温度、仓储、海洋航行、机器器官。单独一套用得准没问题，多套混在一起说明在用比喻替代说明。
|
||||
|
||||
```
|
||||
❌ 这个赛道的护城河正在坍塌，团队需要重新点燃引擎，才能在这波浪潮里活下来。
|
||||
```
|
||||
|
||||
```
|
||||
✅ 这个方向的门槛在降低，去年还得自研的部分现在有开源方案了。团队得找新的差异点。
|
||||
```
|
||||
|
||||
**检测**：短距离内（约 800 字窗口）命中 3 套以上借喻场。`hard_metrics.py --residual` 会统计，并已排除字面用法（`搜索引擎`、`代码仓库`、`商品库存` 不计）。
|
||||
|
||||
**默认动作**：先全部还原成本义。还原后意思已经清楚的，一个比喻也不用放回。
|
||||
|
||||
**保留条件**：所写对象本身就是这些东西（真的在讲仓库、温度、船）；行业稳定术语（金融的 `杠杆`、投资语境的 `护城河`）；用户明确要求的修辞风格；小说、诗歌和抒情写作按意象是否属于同一套感受判断，不按数量机械删。
|
||||
Reference in New Issue
Block a user