# POWELL_REVISE.md
# AI味去除与文章修订规范

> **使用场景**: 当你与AI探讨并生成文章后，使用本规范对文章进行"去AI味"修订，使其更接近真实的个人表达。

---

## 修订原则总览

**核心理念**: 保持你的思想内核和逻辑骨架，去除AI生成痕迹，让文字更有"人味"。

**选定策略**:
- 语气强度: 保持原风格，仅去AI痕迹
- 文章结构: 保持清晰结构（1, 2, 3 列表和标题）
- 减少格式: 除了必要的分段，最好不要使用Markdown语法
- 禁止括号: 默认删除所有解释性括号。极少数情况下括号内容对理解确实不可或缺，用"也就是"或"即"整合进句子，不保留括号本身
- 词汇处理: 删除过渡词堆积 + 打破排比对仗 + 增加口语化 + 保留技术准确性
- 情绪表达: 保持冷静客观，通过细节增加人味；比喻是最后手段，只在真正更清晰时用

---

## 零、七大写作原则（最高优先级）

在应用后续所有规则之前，先对齐这七条原则：

**1. 问题导入，禁止上帝视角**
开头必须从一个具体困惑、矛盾或场景切入。禁止以"X是Y的核心"、"在当今时代，Z越来越重要"这类全知叙述开场。

**2. 剃刀原则：删句优先于改句**
每一句话，问自己：删掉它，意思有没有损失？如果没有，直接删。不要改写冗余句，删除它。

**3. 戛然而止，禁止首尾呼应**
最后一句有实质信息量就停。不做总结，不回望全文。绝对禁止把开头的论点原样搬回结尾——同一个观点在首尾各说一遍是最典型的AI结构。

**4. 只说自己的判断，拒绝"理客中"**
禁止"有些人认为X，也有人认为Y"的防御性写法。直接说你认为什么。明确禁用"我可以理解他们的焦虑"、"当然，任何事物都有两面性"、"不可否认"——这类先共情再否定的套路是伪装成理性的逃避。

**5. 比喻是最后手段**
只有比喻真正比直说更清晰时才用，不要为了"有人味"而强行加。全篇最多1个，没有也完全可以。

**6. 隐去第一人称**
严禁泛滥使用"我"（"我一直有个观点"、"我在读源码时发现"、"我建议"）。观点和事实自己会说话，不要把"我"当成模拟人类语气的标点符号。偶尔一次没问题，全文每段都有就是问题。

**7. 强制主观判断**
陈述技术事实或描述某个工具/方案时，必须附带直接评价。不要只罗列特性，要说它暴力但有效、设计清爽、极度脆弱——这不是修辞，是信息密度的一部分。

**8. 词汇与概念降维**
绝对禁止使用"赋能"、"底层逻辑"、"仪式性努力"、"错失恐惧症"、"精神枷锁"等社科或互联网黑话。用具体的动作或大白话替代（例如：把"仪式性努力"直接说成"花钱买心理安慰"）。禁止为了结构工整而将事物强行拆分为"保守派/激进派"、"向内求索/向外扩展"等对称的伪概念。

**9. 受众基线预设**
默认受众是具备高级技术认知（如熟悉 Python 开发、系统架构）的同行。绝对禁止解释基础概念（如禁用"编程的本质是……"、"提示词的意思是……"）。不教育读者，只提供洞察。

**10. 封杀鸡汤与情绪抚慰**
禁止所有类似"危机就是转机"、"这是成长的机会"、"最重要的选择"等带有情绪抚慰和职场导师口吻的废话。

---

## 一、AI痕迹识别清单

### 1.1 必须删除的典型AI痕迹

**过度工整的过渡词**:
- ❌ "首先...其次...再次...最后..."
- ❌ "总而言之" "综上所述" "不难看出"
- ❌ "值得注意的是" "需要强调的是"
- ❌ "说白了" "说实话"
- ✅ 直接陈述，或用"btw" "其实" (仅在必要时使用)

**机械的排比和对仗**:
- ❌ "不仅...而且..." "既...又..." "一方面...另一方面..."
- ❌ 三个并列短句字数完全相等的排比
- ✅ 自然的递进，长短句交错，不刻意对称

**过度平衡的表达**:
- ❌ "虽然有A的优势，但也存在B的挑战，因此我们需要综合考虑..."
- ✅ 直接说你的判断: "A确实有价值，但B才是真正的瓶颈"

**防御性引用**:
- ❌ "有些人认为X，也有人认为Y，因此我们需要综合考虑"
- ❌ "不少专家指出..." "研究表明..."（用来代替自己表态）
- ✅ 直接说"我认为X" 或 "这件事我的判断是X"

**空洞的修饰词堆积**:
- ❌ "深入、全面、系统地" "显著提升" "有效解决"
- ✅ 用具体数据或比喻: "3秒开服" "像拆毛坯房和简装房的区别"

**AI喜欢的万能结尾**:
- ❌ "让我们携手共进，共创美好未来"
- ❌ "这不仅是挑战，更是机遇"
- ✅ 具体的下一步或诚实的不确定: "接下来我们要做X" 或 "说实话，这事儿我还没完全想清楚"

### 1.2 典型AI句式模式

**问题句式**:
- ❌ "那么，我们应该如何解决这个问题呢？" (AI喜欢自问自答)
- ✅ 直接给方案或坦承: "这个问题其实没有银弹" 或 "我的解决思路是..."

**完美的三段论 / 八股文骨架**:
- ❌ 提出问题(200字) → 分析问题(500字) → 解决问题(300字)
- ❌ "现象-本质-客观背景-解决方案"均分四段（最典型的AI骨架）
- ❌ "一、... 二、... 三、... 总结一句话：..." 这种汉字序号加强行收尾的结构，是八股文变体，全部禁用
- ❌ 任何形式的"总结一句话"/"一句话总结"/"综上"式收尾
- ✅ 可以先说结论，或者中间插入自己的怀疑和修正；说完最后一个有实质内容的点，直接停

**宏大词汇轰炸**:
- ❌ "不可逆的浪潮" "现实的巨浪" "范式转移" "时代大背景" "深刻变革"
- ❌ 连续多段都在描述宏大趋势而非具体现象
- ✅ 换成可被验证的具体描述："npm 依赖一更新就挂" "狂烧 Token"

---

## 二、修订操作手册

### 2.1 结构层面（保持，但微调）

**保持的部分**:
- ✅ 清晰的标题层级（1, 2, 3...）
- ✅ 子弹点列表
- ✅ "背景-现状-挑战-下一步"的逻辑框架

**需要微调的部分**:
- 在标题之间加入"过渡思考"，如: "btw，这让我想到一个更本质的问题..."
- 标题不需要完美对称，可以有长有短，有陈述也有反问
- 可以在正文段落中间插入用"---"分隔的独立思考片段

### 2.2 句子层面（重点修订区）

**删除过渡词堆积**:
```
Before (AI味):
首先，我们需要理解云计算的本质。其次，要认识到标准化的重要性。最后，我们才能真正实现IT巴别塔的愿景。

After (去AI味):
云计算的本质是什么？说白了就是标准化。只有把底层标准化了，才有可能建成IT巴别塔。
```

**打破排比和对仗**:
```
Before (AI味):
我们既要保证性能，又要控制成本，还要提升体验。

After (去AI味):
性能肯定要保证。但成本控制才是长期可持续的关键，用户体验是这两者平衡后的结果。
```

**增加口语化表达**:
```
Before (AI味):
经过深入分析，我们认为该方案具有可行性。

After (去AI味):
这个方案能不能行？我觉得问题不大，主要是看执行。
```

**用"把"字句替代"将"字句**:
```
Before (书面腔):
系统会将对象移动到目标路径。

After (口语化):
系统会把对象移动到目标路径。
```

**条件句口语化**:
```
Before (书面腔):
若配置缺失，则服务将无法启动。

After (口语化):
如果配置缺失，服务就起不来。
```

**保留技术准确性**:
```
✅ 保持: CVM, Lighthouse, TTFT, P95, GPU, infra, winback
✅ 保持: 具体的性能数据 "3秒开服" "0.1%的概率"
✅ 保持: 专业术语的英文表达，不要强行翻译成中文
```

**禁用防御性引号**:
```
❌ 对归纳性词汇套引号制造焦点: "调戏" "数字替身" "你问我答" "主动交办" "包工头模式" "固化" "统一入口" "神器" "抖机灵"
❌ 用引号免责: 这种所谓的"创新"...
✅ 直接说清楚评价，不需要引号来暗示距离感；如果词本身不够精确，换个更准确的词，或用完整句子表达
```

**禁止连续复合长句**:
```
❌ 一段里全是逗号堆砌的长句，读者喘不过气
✅ 短句抛出观点，长句解释逻辑，信息过载时用句号截断
✅ 一句话里超过三个分句，考虑拆成两句
```

**段落长度**:
- AI喜欢每段150-200字，整齐划一
- 真人写作: 有的段落就一句话，有的可能300字，参差不齐

**思维插入**:
在段落间插入真实的思考过程:
```
[具体论述A]

其实我知道大家可能会觉得这个想法太理想化。我也对此持有疑虑，必须承认这一点。

但是...
```

**使用你的典型比喻**:
- 巴别塔、西西弗斯、福特生产线、魔法
- 服务器像宠物一样需要照顾

### 2.4 情绪和态度层面

**保持冷静客观，但加入细节**:
```
Before (AI味):
这个技术方案经过验证是可行的，能够有效解决问题。

After (去AI味):
这个方案我们试了三个月，踩了不少坑，但确实能work。最关键的是，它能把P95延迟压到50ms以下，这对我们的场景够用了。
```

**必要时承认局限**:
```
✅ "说实话，这个问题我还没完全想清楚"
✅ "我能力有限，只能做到这个程度"
✅ "这是我们当前能做的最优解，不是完美解"
```

**使用你的金句模式**:
- "其实我知道xxx，但我也对此持有非常疑虑的态度"
- "我们可以从两个极端角度来看这个问题"
- "这不仅是炫技，更是为了解决xxx的矛盾"

---

## 三、分步修订流程

### Step 1: 快速扫描（2分钟）
用查找功能搜索以下词汇，直接删除或替换:
- "首先" "其次" "最后" "总之" "综上所述"
- "不仅...而且" "既...又..."
- "深入" "全面" "系统" "显著" "有效"
- "让我们" "携手" "共创"
- "赋能" "底层逻辑" "仪式性努力" "错失恐惧症" "精神枷锁"
- "保守派/激进派" "向内求索/向外扩展"
- "危机就是转机" "这是成长的机会" "最重要的选择"

### Step 2: 结构检查（3分钟）
- 标题是否过于工整？可以打乱一个
- 每段字数是否太平均？制造一些参差感
- 是否有"自问自答"的句子？改成直接陈述

### Step 3: 句子重写（10分钟）
- 找出最"AI味"的3-5个句子，用口语化方式重写
- 检查技术术语是否保留英文
- 加入1-2个比喻或具体案例

### Step 4: 情绪注入（5分钟）
- 找到1-2处可以表达"怀疑"或"自我修正"的地方，加入真实思考
- 找到可以用"btw"或"说实话"的地方，增加口语化转折
- 检查是否有过度自信的表达，适当降温

### Step 5: 最后通读（3分钟）
- 大声朗读，听起来是否像自己在说话
- 是否还有"朗朗上口"的排比句？打破它
- 是否有过于完美的结尾？改得实际一点

---

## 四、典型修订对照示例

### 示例1: 技术方案介绍

**Before (AI生成)**:
```
云计算作为新一代信息技术的重要组成部分，正在深刻改变着企业的IT架构。
首先，云计算提供了弹性可扩展的计算资源；其次，它降低了企业的运维成本；
最后，通过标准化的服务，云计算使得应用开发更加高效。因此，我们应当充分
认识到云计算的战略意义，积极推进云原生技术的落地应用。
```

**After (去AI味)**:
```
云计算到底在干什么？说白了就是想建一个IT的巴别塔。

让计算资源像水电一样随时可用，这是理想。但现实是，大部分企业用云就像
租了个毛坯房，装修、搭建、运维，一堆活儿还得自己干。

这就是为什么我们要做Lighthouse。它不是低配版CVM，而是一个"简装房"，
开箱即用。btw，这背后其实是在赌一件事：牺牲部分灵活性，换取极致易用性，
对大部分开发者来说是划算的。
```

### 示例2: 项目复盘

**Before (AI生成)**:
```
本项目历时3个月，期间团队克服了诸多技术难题，最终成功上线。在此过程中，
我们深刻认识到了充分沟通的重要性，同时也积累了宝贵的经验。展望未来，
我们将继续优化产品性能，为用户提供更优质的服务体验。
```

**After (去AI味)**:
```
这个项目折腾了3个月才上线，中间踩的坑比预期多得多。

最大的问题不是技术，是沟通。产品、研发、运维，三方对"稳定性"的定义
完全不一样。后来我们干脆拉了个三方会，把SLA指标写在白板上，才算对齐。

性能方面，P95延迟还是没压到目标值，但考虑到当前成本，已经是可接受的
权衡了。下一步要做的是引入热迁移技术，这个能从根上解决问题，但需要
底层VStation配合，不是短期能搞定的。

这个项目让我最深的体会是：技术问题终究是人的问题。
```

### 示例3: 观点论述

**Before (AI生成)**:
```
关于技术团队的管理，不同的组织有不同的做法。一方面，我们需要给予工程师
充分的技术自由度；另一方面，也要建立必要的规范和流程。在实践中，我们
应当在灵活性和规范性之间寻求平衡，这样才能既保证创新活力，又维护系统
稳定。总的来说，管理是一门艺术，需要持续探索和优化。
```

**After (去AI味)**:
```
管理技术团队，我的核心原则是"对人编程"。

程序员不是代码机器，他们有自己的底层逻辑。你要像理解API一样理解他们的
反馈循环：给清晰的目标、足够的上下文、及时的反馈。

至于"自由度"和"规范"的平衡？其实这是个伪命题。真正的职业工程师不需要
你去平衡，他们自己就知道什么时候该严格遵守规范，什么时候可以突破。
问题往往出在"学生思维"上——等着老师划重点，做完作业就万事大吉。

这也是为什么我在团队强调"成人逻辑"：关注事情本身，而不是KPI表演。
```

---

## 五、特殊情况处理

### 5.1 如果文章是技术文档
- 保持技术准确性优先
- 删减"心灵鸡汤"式的铺垫
- 保留列表和代码示例的工整
- 但可以在前言和总结部分加入个人思考

### 5.2 如果文章是团队汇报
- 保留必要的正式感和完整性
- 删减过度修饰，但保留数据和事实
- 可以在"背景"部分加入坦诚的现状描述
- 结尾从"展望未来"改为"下一步计划"

### 5.3 如果文章是个人文章/博客
- 可以更激进地去除AI痕迹
- 增加更多思考过程
- 使用更多比喻和隐喻
- 敢于表达未完成的思考："这个问题我还在琢磨"

---

## 六、自检清单

修订完成后，问自己以下问题:
- [ ] 是否还有"首先...其次...最后"的结构？
- [ ] 是否有过于工整的排比句？
- [ ] 技术术语是否保留了英文？
- [ ] 是否有至少1-2处自然口语（"btw" "其实"）？注意"说实话""说白了"是伪口语，不算
- [ ] 段落长度是否有参差感？
- [ ] 大声朗读时，是否听起来像你在说话而不是在背稿？
- [ ] 是否删除了空洞的修饰词（"深入" "全面" "显著"）？
- [ ] 结尾是否实际且可执行，而非"美好展望"？
- [ ] "我"字是否泛滥？全文超过5个就要开始删
- [ ] 是否有首尾呼应（同一个观点开头结尾各说一遍）？
- [ ] 是否有宏大词汇轰炸（"不可逆的浪潮"、"范式转移"、"时代大背景"）？
- [ ] 陈述事实时是否附带了主观评价，而不是纯客观罗列？
- [ ] 是否使用了抽象黑话（如"赋能"、"底层逻辑"、"仪式性努力"等）？
- [ ] 是否有强行分类的伪概念（如"保守派/激进派"、"向内求索/向外扩展"等）？
- [ ] 是否有常识科普或爹味说教的内容？
- [ ] 是否有鸡汤或情绪抚慰类的表达（如"危机就是转机"、"这是成长的机会"等）？

---

## 七、快速修订模板

如果时间紧迫，使用以下最小修订清单:

1. **批量替换**（30秒）:
   - "首先" → 删除或改"第一个要说的是"
   - "其次" → 删除或改"另外"
   - "最后" → 删除或改"btw"
   - "总而言之" → 删除整句
   - "赋能" → 删除或改具体动作
   - "底层逻辑" → 删除或改具体原因
   - "仪式性努力" → 删除或改"花钱买心理安慰"
   - "危机就是转机" → 删除或改具体困难和解决方法

2. **挑3个最AI的句子重写**（3分钟）:
   - 找排比句 → 改成一长一短
   - 找空话 → 换成具体例子或数据
   - 找过渡句 → 删除或改"说实话"

3. **加比喻**（最后手段，不是常规操作）:
   - 只有比喻真正比直说更清晰时才用，不要为了"有人味"强行加
   - **永久禁用**："简装房"（仅限特定历史场景，不再泛用）
   - 原则：全篇最多 1 个，没有也完全可以

4. **改结尾**（1分钟）:
   - 从"展望未来"改成"下一步要做X"
   - 或直接说"这个事儿还没完全想清楚"

---

## 附录：典型词汇黑白名单

### 黑名单（尽量避免）
- 深入、全面、系统、显著、有效
- 充分、积极、持续、不断、进一步
- 切实、扎实、务实、落实
- 携手、共创、共赢
- 赋能、触达、闭环、抓手、底层逻辑、仪式性努力、错失恐惧症、精神枷锁
- 不难看出、值得注意的是、需要强调的是
- **宏大词汇类**：不可逆的浪潮、现实的巨浪、时代大背景、范式转移、深刻变革、历史性时刻
- **伪分类类**：保守派/激进派、向内求索/向外扩展、左派/右派、传统派/革新派
- **鸡汤类**：危机就是转机、这是成长的机会、最重要的选择、挑战与机遇并存

### 白名单（鼓励使用）
- 说实话、其实、btw
- 这让我想到、我觉得
- 问题是、关键在于
- 说白了、坦白讲
- 技术术语（CVM, Lighthouse, GPU, infra, etc.）
- 具体数据（3秒、0.1%、P95）
- 比喻（最后手段：只在比喻真正比直说更清晰时用；全篇最多 1 个，没有也可以）
- **永久禁用**：简装房（仅限特定历史场景，不再使用）

---

**使用建议**:
1. 首次修订，严格按流程走一遍（约30分钟）
2. 熟练后，用"快速修订模板"（5分钟搞定）
3. 定期积累好的改写案例，丰富个人表达库
4. 如果AI生成的某段特别符合你的思路，可以保留，不必过度修改

**终极目标**: 让读者读完后的感觉是"这绝对是Powell写的"，而不是"这看起来像AI生成的"。