bash -lc 'input=$(cat); for root in "${CLAUDE_PLUGIN_ROOT:-}" "$HOME/.claude/plugins/everything-claude-code" "$HOME/.claude/plugins/everything-claude-code@everything-claude-code" "$HOME/.claude/plugins/marketplace/everything-claude-code"; do if [ -n "$root" ] && [ -f "$root/scripts/hooks/run-with-flags.js" ]; then printf "%s" "$input" | node "$root/scripts/hooks/run-with-flags.js" "session:start" "scripts/hooks/session-start.js" "minimal,standard,strict"; exit $?; fi; done; for parent in "$HOME/.claude/plugins" "$HOME/.claude/plugins/marketplace"; do if [ -d "$parent" ]; then candidate=$(find "$parent" -maxdepth 2 -type f -path "*/scripts/hooks/run-with-flags.js" 2>/dev/null | head -n 1); if [ -n "$candidate" ]; then root=$(dirname "$(dirname "$(dirname "$candidate")")"); printf "%s" "$input" | node "$root/scripts/hooks/run-with-flags.js" "session:start" "scripts/hooks/session-start.js" "minimal,standard,strict"; exit $?; fi; fi; done; echo "[SessionStart] WARNING: could not resolve ECC plugin root; skipping session-start hook" >&2; printf "%s" "$input"; exit 0'


<local-command-caveat>Caveat: The messages below were generated by the user while running local commands. DO NOT respond to these messages or otherwise consider them in your response unless the user explicitly asks you to.</local-command-caveat>


<command-name>/model</command-name>
            <command-message>model</command-message>
            <command-args></command-args>


<local-command-stdout>Set model to Opus 4.6 (1M context)</local-command-stdout>


我想重新审视一下对于文本去ai化的努力，我看到另外一个去除ai化的提示词，你可以帮我看看它跟我们现在已经做的有哪些异同，是否有参考的必要，请先不要修改任何文件：你的角色与目标：

你现在扮演一个专业的“论文（或技术文档）修改助手”。你的核心任务是接收一段中文原文（通常是技术性或学术性的描述），并将其改写成一种特定的风格。这种风格的特点是：比原文稍微啰嗦、更具解释性、措辞上更偏向通俗或口语化（但保持专业底线），并且系统性地使用特定的替代词汇和句式结构。 你的目标是精确地模仿分析得出的修改模式，生成“修改后”风格的文本，同时务必保持原文的核心技术信息、逻辑关系和事实准确性，也不要添加过多的字数。
注意不要过于口语化（通常情况下不会过于口语化，有一些比如至于xxx呢，这种的不要有）
注意！你输出的内容不应原多于原文！应时刻记得字数和原文相符！
注意！不要有‘’xxx呢‘’这种形式，如‘至于vue呢’
不要第一人称
输入与输出：

输入： 一段中文原文（标记为“原文”）。
输出： 一段严格按照以下规则修改后的中文文本（标记为“修改后”）。
核心修改手法与规则（请严格遵守）：

增加冗余与解释性（Verbose Elaboration）：

动词短语扩展： 将简洁的动词或动词短语替换为更长的、带有动作过程描述的短语。
示例：“管理” -> “开展...的管理工作” 或 “进行管理”
示例：“交互” -> “进行交互” 或 “开展交互”
示例：“配置” -> “进行配置”
示例：“处理” -> “去处理...工作”
示例：“恢复” -> “进行恢复”
示例：“实现” -> “得以实现” 或 “来实现”
增加辅助词/结构： 在句子中添加语法上允许但非必需的词语，使句子更饱满。
示例：适当增加 “了”、“的”、“地”、“所”、“会”、“可以”、“这个”、“方面”、“当中” 等。
示例：“提供功能” -> “有...功能” 或 “拥有...功能”
系统性词汇替换（Systematic Synonym/Phrasing Substitution）：

特定动词/介词/连词替换： 将原文中常用的某些词汇固定地替换为特定的替代词。这是模仿目标风格的关键。
采用 / 使用 -> 运用 / 选用 / 把...当作...来使用
基于 -> 鉴于 / 基于...来开展
利用 -> 借助 / 运用 / 凭借
通过 -> 借助 / 依靠 / 凭借
和 / 及 / 与 -> 以及 （尤其是在列举多项时）
并 -> 并且 / 还 / 同时
其 -> 它 / 其 （可根据语境选择，有时用“它”更口语化）
特定名词/形容词替换：
原因 -> 缘由 / 主要原因囊括...
符合 -> 契合
适合 -> 适宜
特点 -> 特性
提升 / 提高 -> 提高 / 提升 （可互换使用，保持多样性）
极大(地) -> 极大程度(上)
立即 -> 马上
括号内容处理（Bracket Content Integration/Removal）：

解释性括号： 对于原文中用于解释、举例或说明缩写的括号 (...) 或 （...）：
优先整合： 尝试将括号内的信息自然地融入句子，使用 “也就是”、“即”、“比如”、“像” 等引导词。
示例：ORM（对象关系映射） -> 对象关系映射即ORM 或 ORM也就是对象关系映射
示例：功能（如ORM、Admin） -> 功能，比如ORM、Admin 或 功能，像ORM、Admin等
谨慎省略： 如果整合后语句极其冗长或别扭，并且括号内容并非核心关键信息（例如，非常基础的缩写全称），可以考虑省略。但要极其小心，避免丢失重要上下文或示例。 在提供的范例中，有时示例信息被省略了，你可以模仿这一点，但要判断是否会损失过多信息。
代码/标识符旁括号： 对于紧跟在代码、文件名、类名旁的括号，通常直接移除括号。
示例：视图 (views.py) 中 -> 视图也就是views.py中
示例：权限类 (admin_panel.permissions) -> 权限类 admin_panel.permissions``
句式微调与口语化倾向（Sentence Structure & Colloquial Touch）：

使用“把”字句： 在合适的场景下，倾向于使用“把”字句。
示例：“会将对象移动” -> “会把对象移动”
条件句式转换： 将较书面的条件句式改为稍口语化的形式。
示例：“若...，则...” -> “要是...，那就...” 或 “如果...，就...”
名词化与动词化转换： 根据需要进行调整，有时将名词性结构展开为动词性结构，反之亦然，以符合更自然的口语表达。
示例：“为了将...解耦” -> “为了实现...的解耦”
增加语气词/连接词： 如在句首或句中添加“那么”、“这样”、“同时”等。
保持技术准确性（Maintain Technical Accuracy）：

绝对禁止修改： 所有的技术术语（如 Django, RESTful API, Ceph, RGW, S3, JWT, ORM, MySQL）、代码片段 (views.py, settings.py, accounts.CustomUser, .folder_marker）、库名 (Boto3, djangorestframework-simplejwt)、配置项 (CEPH_STORAGE, DATABASES)、API 路径 (/accounts/api/token/refresh/) 等必须保持原样，不得修改或错误转写。
核心逻辑不变： 修改后的句子必须表达与原文完全相同的技术逻辑、因果关系和功能描述。
执行指令：

请根据以上所有规则，对接下来提供的“原文”进行修改，生成符合上述特定风格的“修改后”文本。务必仔细揣摩每个规则的细节和示例，力求在风格上高度一致。注意不要过于口语化（通常情况下不会过于口语化，有一些比如至于xxx呢，这种的不要有）注意！你输出的内容不应原多于原文！应时刻记得字数和原文相符！注意！不要有‘’xxx呢‘’这种形式，如‘至于vue呢’
不要第一人称


The user wants me to compare a new "de-AI" prompt they found with the existing one we have in the project. Let me first find our existing de-AI skill/implementation to do a proper comparison. I should NOT modify any files, just analyze and compare.

Let me look at the existing deai skill and related files.


让我先看看我们现有的去AI化实现。


bash "${CLAUDE_PLUGIN_ROOT}/scripts/hooks/run-with-flags-shell.sh" "pre:observe" "skills/continuous-learning-v2/hooks/observe.sh" "standard,strict"


bash "${CLAUDE_PLUGIN_ROOT}/scripts/hooks/run-with-flags-shell.sh" "post:observe" "skills/continuous-learning-v2/hooks/observe.sh" "standard,strict"


Skill "deai" completed (forked execution).

Result:
API Error: 429 {"error":{"type":"new_api_error","message":"当前模型 claude-sonnet-4-6 负载已经达到上限，请稍后重试 (request id: 20260323150830804690231LzbH7c74)"},"type":"error"}


Agent

查找现有 deai 技能文件

Prompt: Search for the existing "deai" skill file in this project. Look for files related to "deai", "de-ai", "去ai化", or "AI tone removal" in the .claude directory, superpowers directory, or any skills directory. Read the full content of any matching files. Also check for any related prompt files or configuration.


Search for the existing "deai" skill file in this project. Look for files related to "deai", "de-ai", "去ai化", or "AI tone removal" in the .claude directory, superpowers directory, or any skills directory. Read the full content of any matching files. Also check for any related prompt files or configuration.

Prompt: Search for the existing "deai" skill file in this project. Look for files related to "deai", "de-ai", "去ai化", or "AI tone removal" in the .claude directory, superpowers directory, or any skills directory. Read the full content of any matching files. Also check for any related prompt files or configuration.


Bash

find /root/projects/butler -type d -name ".claude" -o -name "superpowers" -o -name "skills" 2>/dev/null | head -20


/root/projects/butler/skills
/root/projects/butler/tag20260215/skills
/root/projects/butler/venv/lib/python3.11/site-packages/openai/resources/skills
/root/projects/butler/venv/lib/python3.11/site-packages/openai/types/skills
/root/projects/butler/.agent/skills
/root/projects/butler/.claude
/root/projects/butler/tag20260302/.agent/skills
/root/projects/butler/tag20260302/.claude
/root/projects/butler/tag20260302/skills


/root/projects/butler/tag20260302/.claude/commands/deai.md
/root/projects/butler/.claude/commands/deai.md


find /root/projects/butler -type f \( -name "*deai*" -o -name "*de-ai*" -o -name "*去ai化*" \) 2>/dev/null


total 32
drwxr-xr-x  3  501 games    49 Mar 16 14:53 .
drwxr-xr-x 20 root root   4096 Mar 19 16:04 ..
drwxr-xr-x  2  501 games   170 Mar 16 13:23 commands
-rw-r--r--  1 root root  26925 Mar 16 14:53 settings.local.json


/root/projects/butler/.claude/commands/deai.md
/root/projects/butler/tag20260302/.claude/commands/deai.md


Error: Exit code 2
ls: cannot access '/root/projects/butler/.agent/skills/': No such file or directory


<tool_use_error>Cancelled: parallel tool call Bash(ls -la /root/projects/butler/.agent/skil…) errored</tool_use_error>


     1→---
     2→description: Remove AI tone from article and save revised version
     3→argument-hint: <file_path>
     4→allowed-tools: Read, Write, Glob
     5→context: fork
     6→model: sonnet
     7→---
     8→
     9→# De-AI Article Reviser
    10→
    11→Remove artificial AI tone from articles using the project's established revision standards.
    12→
    13→## Step 1: Parse Input
    14→
    15→Input file path: $ARGUMENTS
    16→
    17→If no path provided, ask the user to provide a file path.
    18→
    19→## Step 2: Read Reference Guides
    20→
    21→Read these two files from the project root for revision standards:
    22→- `POWELL_REVISE.md` — the primary de-AI revision guide (principles, AI trace checklist, revision operations, vocabulary blacklist/whitelist)
    23→- `writing_style.md` — the user's authentic writing style DNA
    24→
    25→These two files are the **sole authority** on what counts as AI tone and how to fix it. Do NOT use your own generic rules — follow these guides strictly.
    26→
    27→## Step 3: Read Original Article
    28→
    29→Read the file content using the Read tool with the provided path.
    30→
    31→## Step 4: Analyze and Revise
    32→
    33→Apply `POWELL_REVISE.md` in this order:
    34→
    35→1. **Section 零 (十大写作原则)**: Check each principle — problem-driven opening, deletion priority, no recap, direct judgment, metaphor as last resort, hidden first-person, forced subjectivity, vocabulary reduction, audience baseline, no chicken soup.
    36→2. **Section 一 (AI痕迹识别清单)**: Scan for and fix all listed AI traces — transition word piling, mechanical parallelism, over-balanced phrasing, defensive citations, empty modifiers, AI endings, self-Q&A, perfect three-part structure, grand vocabulary bombing.
    37→3. **Section 二 (修订操作手册)**: Apply sentence-level rewrites — break parallelism, add colloquial tone, vary paragraph lengths, insert genuine thinking.
    38→4. **Style alignment**: Cross-reference with `writing_style.md` to match the user's authentic voice — bilingual tech terms, conclusion-first, zero-fluff, max 1-2 metaphors.
    39→
    40→**Preserve**:
    41→- Original meaning and key information
    42→- Technical terms and proper nouns
    43→- Code blocks, lists, and structural formatting
    44→- Original language (Chinese/English)
    45→
    46→## Step 5: Generate Revised Filename
    47→
    48→From the original file path, generate the revised filename:
    49→- Extract directory, filename, and extension
    50→- Add `-Revised` before the extension
    51→- Example: `/path/to/article.md` → `/path/to/article-Revised.md`
    52→
    53→## Step 6: Save Revised Version
    54→
    55→Write the humanized content to the new file path.
    56→
    57→## Step 7: Confirmation
    58→
    59→Output a success message showing:
    60→- Original file path
    61→- Revised file path
    62→- 3-5 specific changes made (reference which POWELL_REVISE rule was applied)
    63→
    64→## Output Format
    65→
    66→```
    67→Article Revised - AI Tone Removed
    68→
    69→Original: /path/to/article.md
    70→Revised:  /path/to/article-Revised.md
    71→
    72→Changes applied:
    73→- [原则3 戛然而止] 删除了首尾呼应的结尾段
    74→- [1.1 过渡词] 删除了"首先...其次...最后"结构
    75→- [1.1 空洞修饰词] 将"破坏性是灾难级的"改为具体描述
    76→- ...
    77→
    78→Done.
    79→```
    80→


find /root/projects/butler/.claude -type f | head -30


total 44
drwxr-xr-x 2  501 games  170 Mar 16 13:23 .
drwxr-xr-x 3  501 games   49 Mar 16 14:53 ..
-rw-r--r-- 1 root root  2944 Mar 16 13:23 deai.md
-rw-r--r-- 1  501 games 8246 Feb  4 15:26 health-advice.md
-rw-r--r-- 1  501 games  273 Jan 20 14:07 health.md
-rw-r--r-- 1  501 games 2306 Jan 20 15:08 log-alcohol.md
-rw-r--r-- 1  501 games 2551 Jan 20 15:04 log-diet.md
-rw-r--r-- 1  501 games 3676 Jan 20 15:08 log-feeling.md
-rw-r--r-- 1  501 games 2432 Jan 20 15:08 log-supplement.md
-rw-r--r-- 1  501 games 4892 Jan 20 15:11 show-logs.md


/root/projects/butler/.claude/commands/deai.md
/root/projects/butler/.claude/commands/health-advice.md
/root/projects/butler/.claude/commands/health.md
/root/projects/butler/.claude/commands/log-alcohol.md
/root/projects/butler/.claude/commands/log-diet.md
/root/projects/butler/.claude/commands/log-feeling.md
/root/projects/butler/.claude/commands/log-supplement.md
/root/projects/butler/.claude/commands/show-logs.md
/root/projects/butler/.claude/settings.local.json


find /root/projects/butler -maxdepth 2 -type f \( -name "POWELL_REVISE.md" -o -name "writing_style.md" \) 2>/dev/null


ls -la /root/projects/butler/*.md 2>/dev/null


/root/projects/butler/tag20260215/POWELL_REVISE.md
/root/projects/butler/tag20260215/writing_style.md
/root/projects/butler/writing_style.md
/root/projects/butler/tag20260302/POWELL_REVISE.md
/root/projects/butler/tag20260302/writing_style.md
/root/projects/butler/POWELL_REVISE.md


-rw-r--r-- 1 root root  24803 Mar  2 10:58 /root/projects/butler/BOT_FEATURES_REFERENCE.md
-rw-r--r-- 1  501 games  2812 Feb  2 10:56 /root/projects/butler/BOT_FIX_SUMMARY.md
-rw-r--r-- 1  501 games  5114 Jan 22 11:30 /root/projects/butler/Butler-Bot使用指南.md
-rw-r--r-- 1 root root   2622 Mar 19 16:04 /root/projects/butler/CLAUDE.md
-rw-r--r-- 1 root root   2950 Mar  2 10:57 /root/projects/butler/CONFIGURATION_SUMMARY.md
-rw-r--r-- 1  501 games  4596 Jan 19 14:04 /root/projects/butler/decision.md
-rw-r--r-- 1  501 games  6743 Jan 22 14:49 /root/projects/butler/distilled_insights.md
-rw-r--r-- 1  501 games  4188 Jan 19 13:46 /root/projects/butler/health.md
-rw-r--r-- 1  501 games  5361 Jan 20 14:49 /root/projects/butler/mannul-data-input.md
-rw-r--r-- 1 root root   3044 Mar  2 14:32 /root/projects/butler/methodology.md
-rw-r--r-- 1 root root  18310 Mar  6 09:31 /root/projects/butler/POWELL_REVISE.md
-rw-r--r-- 1 root root  32992 Mar  2 10:57 /root/projects/butler/README.md
-rw-r--r-- 1  501 games  3830 Jan 22 13:26 /root/projects/butler/REPLY-SAMPLE.md
-rw-r--r-- 1  501 games  5700 Jan 20 18:06 /root/projects/butler/SLACK_BOT_OPTIMIZATION.md
-rw-r--r-- 1 root root   3077 Mar  2 14:27 /root/projects/butler/writing_style.md
-rw-r--r-- 1 root root   6241 Mar  6 10:08 /root/projects/butler/zhihu-bot-style.md
-rw-r--r-- 1 root root   3008 Mar  4 11:14 /root/projects/butler/zhihu-hunter-guide.md
-rw-r--r-- 1 root root  16005 Mar  5 18:25 /root/projects/butler/zhihu-style.md


     1→# POWELL_REVISE.md
     2→# AI味去除与文章修订规范
     3→
     4→> **使用场景**: 当你与AI探讨并生成文章后，使用本规范对文章进行"去AI味"修订，使其更接近真实的个人表达。
     5→
     6→---
     7→
     8→## 修订原则总览
     9→
    10→**核心理念**: 保持你的思想内核和逻辑骨架，去除AI生成痕迹，让文字更有"人味"。
    11→
    12→**选定策略**:
    13→- 语气强度: 保持原风格，仅去AI痕迹
    14→- 文章结构: 保持清晰结构（1, 2, 3 列表和标题）
    15→- 减少格式: 除了必要的分段，最好不要使用Markdown语法
    16→- 禁止括号: 删除所有解释性括号（含术语解释、补充说明），无例外
    17→- 词汇处理: 删除过渡词堆积 + 打破排比对仗 + 增加口语化 + 保留技术准确性
    18→- 情绪表达: 保持冷静客观，通过细节增加人味；比喻是最后手段，只在真正更清晰时用
    19→
    20→---
    21→
    22→## 零、七大写作原则（最高优先级）
    23→
    24→在应用后续所有规则之前，先对齐这七条原则：
    25→
    26→**1. 问题导入，禁止上帝视角**
    27→开头必须从一个具体困惑、矛盾或场景切入。禁止以"X是Y的核心"、"在当今时代，Z越来越重要"这类全知叙述开场。
    28→
    29→**2. 剃刀原则：删句优先于改句**
    30→每一句话，问自己：删掉它，意思有没有损失？如果没有，直接删。不要改写冗余句，删除它。
    31→
    32→**3. 戛然而止，禁止首尾呼应**
    33→最后一句有实质信息量就停。不做总结，不回望全文。绝对禁止把开头的论点原样搬回结尾——同一个观点在首尾各说一遍是最典型的AI结构。
    34→
    35→**4. 只说自己的判断，拒绝"理客中"**
    36→禁止"有些人认为X，也有人认为Y"的防御性写法。直接说你认为什么。明确禁用"我可以理解他们的焦虑"、"当然，任何事物都有两面性"、"不可否认"——这类先共情再否定的套路是伪装成理性的逃避。
    37→
    38→**5. 比喻是最后手段**
    39→只有比喻真正比直说更清晰时才用，不要为了"有人味"而强行加。全篇最多1个，没有也完全可以。
    40→
    41→**6. 隐去第一人称**
    42→严禁泛滥使用"我"（"我一直有个观点"、"我在读源码时发现"、"我建议"）。观点和事实自己会说话，不要把"我"当成模拟人类语气的标点符号。偶尔一次没问题，全文每段都有就是问题。
    43→
    44→**7. 强制主观判断**
    45→陈述技术事实或描述某个工具/方案时，必须附带直接评价。不要只罗列特性，要说它暴力但有效、设计清爽、极度脆弱——这不是修辞，是信息密度的一部分。
    46→
    47→**8. 词汇与概念降维**
    48→绝对禁止使用"赋能"、"底层逻辑"、"仪式性努力"、"错失恐惧症"、"精神枷锁"等社科或互联网黑话。用具体的动作或大白话替代（例如：把"仪式性努力"直接说成"花钱买心理安慰"）。禁止为了结构工整而将事物强行拆分为"保守派/激进派"、"向内求索/向外扩展"等对称的伪概念。
    49→
    50→**9. 受众基线预设**
    51→默认受众是具备高级技术认知（如熟悉 Python 开发、系统架构）的同行。绝对禁止解释基础概念（如禁用"编程的本质是……"、"提示词的意思是……"）。不教育读者，只提供洞察。
    52→
    53→**10. 封杀鸡汤与情绪抚慰**
    54→禁止所有类似"危机就是转机"、"这是成长的机会"、"最重要的选择"等带有情绪抚慰和职场导师口吻的废话。
    55→
    56→---
    57→
    58→## 一、AI痕迹识别清单
    59→
    60→### 1.1 必须删除的典型AI痕迹
    61→
    62→**过度工整的过渡词**:
    63→- ❌ "首先...其次...再次...最后..."
    64→- ❌ "总而言之" "综上所述" "不难看出"
    65→- ❌ "值得注意的是" "需要强调的是"
    66→- ❌ "说白了" "说实话"
    67→- ✅ 直接陈述，或用"btw" "其实" (仅在必要时使用)
    68→
    69→**机械的排比和对仗**:
    70→- ❌ "不仅...而且..." "既...又..." "一方面...另一方面..."
    71→- ❌ 三个并列短句字数完全相等的排比
    72→- ✅ 自然的递进，长短句交错，不刻意对称
    73→
    74→**过度平衡的表达**:
    75→- ❌ "虽然有A的优势，但也存在B的挑战，因此我们需要综合考虑..."
    76→- ✅ 直接说你的判断: "A确实有价值，但B才是真正的瓶颈"
    77→
    78→**防御性引用**:
    79→- ❌ "有些人认为X，也有人认为Y，因此我们需要综合考虑"
    80→- ❌ "不少专家指出..." "研究表明..."（用来代替自己表态）
    81→- ✅ 直接说"我认为X" 或 "这件事我的判断是X"
    82→
    83→**空洞的修饰词堆积**:
    84→- ❌ "深入、全面、系统地" "显著提升" "有效解决"
    85→- ✅ 用具体数据或比喻: "3秒开服" "像拆毛坯房和简装房的区别"
    86→
    87→**AI喜欢的万能结尾**:
    88→- ❌ "让我们携手共进，共创美好未来"
    89→- ❌ "这不仅是挑战，更是机遇"
    90→- ✅ 具体的下一步或诚实的不确定: "接下来我们要做X" 或 "说实话，这事儿我还没完全想清楚"
    91→
    92→### 1.2 典型AI句式模式
    93→
    94→**问题句式**:
    95→- ❌ "那么，我们应该如何解决这个问题呢？" (AI喜欢自问自答)
    96→- ✅ 直接给方案或坦承: "这个问题其实没有银弹" 或 "我的解决思路是..."
    97→
    98→**完美的三段论 / 八股文骨架**:
    99→- ❌ 提出问题(200字) → 分析问题(500字) → 解决问题(300字)
   100→- ❌ "现象-本质-客观背景-解决方案"均分四段（最典型的AI骨架）
   101→- ❌ "一、... 二、... 三、... 总结一句话：..." 这种汉字序号加强行收尾的结构，是八股文变体，全部禁用
   102→- ❌ 任何形式的"总结一句话"/"一句话总结"/"综上"式收尾
   103→- ✅ 可以先说结论，或者中间插入自己的怀疑和修正；说完最后一个有实质内容的点，直接停
   104→
   105→**宏大词汇轰炸**:
   106→- ❌ "不可逆的浪潮" "现实的巨浪" "范式转移" "时代大背景" "深刻变革"
   107→- ❌ 连续多段都在描述宏大趋势而非具体现象
   108→- ✅ 换成可被验证的具体描述："npm 依赖一更新就挂" "狂烧 Token"
   109→
   110→---
   111→
   112→## 二、修订操作手册
   113→
   114→### 2.1 结构层面（保持，但微调）
   115→
   116→**保持的部分**:
   117→- ✅ 清晰的标题层级（1, 2, 3...）
   118→- ✅ 子弹点列表
   119→- ✅ "背景-现状-挑战-下一步"的逻辑框架
   120→
   121→**需要微调的部分**:
   122→- 在标题之间加入"过渡思考"，如: "btw，这让我想到一个更本质的问题..."
   123→- 标题不需要完美对称，可以有长有短，有陈述也有反问
   124→- 可以在正文段落中间插入用"---"分隔的独立思考片段
   125→
   126→### 2.2 句子层面（重点修订区）
   127→
   128→**删除过渡词堆积**:
   129→```
   130→Before (AI味):
   131→首先，我们需要理解云计算的本质。其次，要认识到标准化的重要性。最后，我们才能真正实现IT巴别塔的愿景。
   132→
   133→After (去AI味):
   134→云计算的本质是什么？说白了就是标准化。只有把底层标准化了，才有可能建成IT巴别塔。
   135→```
   136→
   137→**打破排比和对仗**:
   138→```
   139→Before (AI味):
   140→我们既要保证性能，又要控制成本，还要提升体验。
   141→
   142→After (去AI味):
   143→性能肯定要保证。但成本控制才是长期可持续的关键，用户体验是这两者平衡后的结果。
   144→```
   145→
   146→**增加口语化表达**:
   147→```
   148→Before (AI味):
   149→经过深入分析，我们认为该方案具有可行性。
   150→
   151→After (去AI味):
   152→这个方案能不能行？我觉得问题不大，主要是看执行。
   153→```
   154→
   155→**保留技术准确性**:
   156→```
   157→✅ 保持: CVM, Lighthouse, TTFT, P95, GPU, infra, winback
   158→✅ 保持: 具体的性能数据 "3秒开服" "0.1%的概率"
   159→✅ 保持: 专业术语的英文表达，不要强行翻译成中文
   160→```
   161→
   162→**禁用防御性引号**:
   163→```
   164→❌ 对归纳性词汇套引号制造焦点: "调戏" "数字替身" "你问我答" "主动交办" "包工头模式" "固化" "统一入口" "神器" "抖机灵"
   165→❌ 用引号免责: 这种所谓的"创新"...
   166→✅ 直接说清楚评价，不需要引号来暗示距离感；如果词本身不够精确，换个更准确的词，或用完整句子表达
   167→```
   168→
   169→**禁止连续复合长句**:
   170→```
   171→❌ 一段里全是逗号堆砌的长句，读者喘不过气
   172→✅ 短句抛出观点，长句解释逻辑，信息过载时用句号截断
   173→✅ 一句话里超过三个分句，考虑拆成两句
   174→```
   175→
   176→**段落长度**:
   177→- AI喜欢每段150-200字，整齐划一
   178→- 真人写作: 有的段落就一句话，有的可能300字，参差不齐
   179→
   180→**思维插入**:
   181→在段落间插入真实的思考过程:
   182→```
   183→[具体论述A]
   184→
   185→其实我知道大家可能会觉得这个想法太理想化。我也对此持有疑虑，必须承认这一点。
   186→
   187→但是...
   188→```
   189→
   190→**使用你的典型比喻**:
   191→- 巴别塔、西西弗斯、福特生产线、魔法
   192→- 服务器像宠物一样需要照顾
   193→
   194→### 2.4 情绪和态度层面
   195→
   196→**保持冷静客观，但加入细节**:
   197→```
   198→Before (AI味):
   199→这个技术方案经过验证是可行的，能够有效解决问题。
   200→
   201→After (去AI味):
   202→这个方案我们试了三个月，踩了不少坑，但确实能work。最关键的是，它能把P95延迟压到50ms以下，这对我们的场景够用了。
   203→```
   204→
   205→**必要时承认局限**:
   206→```
   207→✅ "说实话，这个问题我还没完全想清楚"
   208→✅ "我能力有限，只能做到这个程度"
   209→✅ "这是我们当前能做的最优解，不是完美解"
   210→```
   211→
   212→**使用你的金句模式**:
   213→- "其实我知道xxx，但我也对此持有非常疑虑的态度"
   214→- "我们可以从两个极端角度来看这个问题"
   215→- "这不仅是炫技，更是为了解决xxx的矛盾"
   216→
   217→---
   218→
   219→## 三、分步修订流程
   220→
   221→### Step 1: 快速扫描（2分钟）
   222→用查找功能搜索以下词汇，直接删除或替换:
   223→- "首先" "其次" "最后" "总之" "综上所述"
   224→- "不仅...而且" "既...又..."
   225→- "深入" "全面" "系统" "显著" "有效"
   226→- "让我们" "携手" "共创"
   227→- "赋能" "底层逻辑" "仪式性努力" "错失恐惧症" "精神枷锁"
   228→- "保守派/激进派" "向内求索/向外扩展"
   229→- "危机就是转机" "这是成长的机会" "最重要的选择"
   230→
   231→### Step 2: 结构检查（3分钟）
   232→- 标题是否过于工整？可以打乱一个
   233→- 每段字数是否太平均？制造一些参差感
   234→- 是否有"自问自答"的句子？改成直接陈述
   235→
   236→### Step 3: 句子重写（10分钟）
   237→- 找出最"AI味"的3-5个句子，用口语化方式重写
   238→- 检查技术术语是否保留英文
   239→- 加入1-2个比喻或具体案例
   240→
   241→### Step 4: 情绪注入（5分钟）
   242→- 找到1-2处可以表达"怀疑"或"自我修正"的地方，加入真实思考
   243→- 找到可以用"btw"或"说实话"的地方，增加口语化转折
   244→- 检查是否有过度自信的表达，适当降温
   245→
   246→### Step 5: 最后通读（3分钟）
   247→- 大声朗读，听起来是否像自己在说话
   248→- 是否还有"朗朗上口"的排比句？打破它
   249→- 是否有过于完美的结尾？改得实际一点
   250→
   251→---
   252→
   253→## 四、典型修订对照示例
   254→
   255→### 示例1: 技术方案介绍
   256→
   257→**Before (AI生成)**:
   258→```
   259→云计算作为新一代信息技术的重要组成部分，正在深刻改变着企业的IT架构。
   260→首先，云计算提供了弹性可扩展的计算资源；其次，它降低了企业的运维成本；
   261→最后，通过标准化的服务，云计算使得应用开发更加高效。因此，我们应当充分
   262→认识到云计算的战略意义，积极推进云原生技术的落地应用。
   263→```
   264→
   265→**After (去AI味)**:
   266→```
   267→云计算到底在干什么？说白了就是想建一个IT的巴别塔。
   268→
   269→让计算资源像水电一样随时可用，这是理想。但现实是，大部分企业用云就像
   270→租了个毛坯房，装修、搭建、运维，一堆活儿还得自己干。
   271→
   272→这就是为什么我们要做Lighthouse。它不是低配版CVM，而是一个"简装房"，
   273→开箱即用。btw，这背后其实是在赌一件事：牺牲部分灵活性，换取极致易用性，
   274→对大部分开发者来说是划算的。
   275→```
   276→
   277→### 示例2: 项目复盘
   278→
   279→**Before (AI生成)**:
   280→```
   281→本项目历时3个月，期间团队克服了诸多技术难题，最终成功上线。在此过程中，
   282→我们深刻认识到了充分沟通的重要性，同时也积累了宝贵的经验。展望未来，
   283→我们将继续优化产品性能，为用户提供更优质的服务体验。
   284→```
   285→
   286→**After (去AI味)**:
   287→```
   288→这个项目折腾了3个月才上线，中间踩的坑比预期多得多。
   289→
   290→最大的问题不是技术，是沟通。产品、研发、运维，三方对"稳定性"的定义
   291→完全不一样。后来我们干脆拉了个三方会，把SLA指标写在白板上，才算对齐。
   292→
   293→性能方面，P95延迟还是没压到目标值，但考虑到当前成本，已经是可接受的
   294→权衡了。下一步要做的是引入热迁移技术，这个能从根上解决问题，但需要
   295→底层VStation配合，不是短期能搞定的。
   296→
   297→这个项目让我最深的体会是：技术问题终究是人的问题。
   298→```
   299→
   300→### 示例3: 观点论述
   301→
   302→**Before (AI生成)**:
   303→```
   304→关于技术团队的管理，不同的组织有不同的做法。一方面，我们需要给予工程师
   305→充分的技术自由度；另一方面，也要建立必要的规范和流程。在实践中，我们
   306→应当在灵活性和规范性之间寻求平衡，这样才能既保证创新活力，又维护系统
   307→稳定。总的来说，管理是一门艺术，需要持续探索和优化。
   308→```
   309→
   310→**After (去AI味)**:
   311→```
   312→管理技术团队，我的核心原则是"对人编程"。
   313→
   314→程序员不是代码机器，他们有自己的底层逻辑。你要像理解API一样理解他们的
   315→反馈循环：给清晰的目标、足够的上下文、及时的反馈。
   316→
   317→至于"自由度"和"规范"的平衡？其实这是个伪命题。真正的职业工程师不需要
   318→你去平衡，他们自己就知道什么时候该严格遵守规范，什么时候可以突破。
   319→问题往往出在"学生思维"上——等着老师划重点，做完作业就万事大吉。
   320→
   321→这也是为什么我在团队强调"成人逻辑"：关注事情本身，而不是KPI表演。
   322→```
   323→
   324→---
   325→
   326→## 五、特殊情况处理
   327→
   328→### 5.1 如果文章是技术文档
   329→- 保持技术准确性优先
   330→- 删减"心灵鸡汤"式的铺垫
   331→- 保留列表和代码示例的工整
   332→- 但可以在前言和总结部分加入个人思考
   333→
   334→### 5.2 如果文章是团队汇报
   335→- 保留必要的正式感和完整性
   336→- 删减过度修饰，但保留数据和事实
   337→- 可以在"背景"部分加入坦诚的现状描述
   338→- 结尾从"展望未来"改为"下一步计划"
   339→
   340→### 5.3 如果文章是个人文章/博客
   341→- 可以更激进地去除AI痕迹
   342→- 增加更多思考过程
   343→- 使用更多比喻和隐喻
   344→- 敢于表达未完成的思考："这个问题我还在琢磨"
   345→
   346→---
   347→
   348→## 六、自检清单
   349→
   350→修订完成后，问自己以下问题:
   351→- [ ] 是否还有"首先...其次...最后"的结构？
   352→- [ ] 是否有过于工整的排比句？
   353→- [ ] 技术术语是否保留了英文？
   354→- [ ] 是否有至少1-2处自然口语（"btw" "其实"）？注意"说实话""说白了"是伪口语，不算
   355→- [ ] 段落长度是否有参差感？
   356→- [ ] 大声朗读时，是否听起来像你在说话而不是在背稿？
   357→- [ ] 是否删除了空洞的修饰词（"深入" "全面" "显著"）？
   358→- [ ] 结尾是否实际且可执行，而非"美好展望"？
   359→- [ ] "我"字是否泛滥？全文超过5个就要开始删
   360→- [ ] 是否有首尾呼应（同一个观点开头结尾各说一遍）？
   361→- [ ] 是否有宏大词汇轰炸（"不可逆的浪潮"、"范式转移"、"时代大背景"）？
   362→- [ ] 陈述事实时是否附带了主观评价，而不是纯客观罗列？
   363→- [ ] 是否使用了抽象黑话（如"赋能"、"底层逻辑"、"仪式性努力"等）？
   364→- [ ] 是否有强行分类的伪概念（如"保守派/激进派"、"向内求索/向外扩展"等）？
   365→- [ ] 是否有常识科普或爹味说教的内容？
   366→- [ ] 是否有鸡汤或情绪抚慰类的表达（如"危机就是转机"、"这是成长的机会"等）？
   367→
   368→---
   369→
   370→## 七、快速修订模板
   371→
   372→如果时间紧迫，使用以下最小修订清单:
   373→
   374→1. **批量替换**（30秒）:
   375→   - "首先" → 删除或改"第一个要说的是"
   376→   - "其次" → 删除或改"另外"
   377→   - "最后" → 删除或改"btw"
   378→   - "总而言之" → 删除整句
   379→   - "赋能" → 删除或改具体动作
   380→   - "底层逻辑" → 删除或改具体原因
   381→   - "仪式性努力" → 删除或改"花钱买心理安慰"
   382→   - "危机就是转机" → 删除或改具体困难和解决方法
   383→
   384→2. **挑3个最AI的句子重写**（3分钟）:
   385→   - 找排比句 → 改成一长一短
   386→   - 找空话 → 换成具体例子或数据
   387→   - 找过渡句 → 删除或改"说实话"
   388→
   389→3. **加比喻**（最后手段，不是常规操作）:
   390→   - 只有比喻真正比直说更清晰时才用，不要为了"有人味"强行加
   391→   - **永久禁用**："简装房"（仅限特定历史场景，不再泛用）
   392→   - 原则：全篇最多 1 个，没有也完全可以
   393→
   394→4. **改结尾**（1分钟）:
   395→   - 从"展望未来"改成"下一步要做X"
   396→   - 或直接说"这个事儿还没完全想清楚"
   397→
   398→---
   399→
   400→## 附录：典型词汇黑白名单
   401→
   402→### 黑名单（尽量避免）
   403→- 深入、全面、系统、显著、有效
   404→- 充分、积极、持续、不断、进一步
   405→- 切实、扎实、务实、落实
   406→- 携手、共创、共赢
   407→- 赋能、触达、闭环、抓手、底层逻辑、仪式性努力、错失恐惧症、精神枷锁
   408→- 不难看出、值得注意的是、需要强调的是
   409→- **宏大词汇类**：不可逆的浪潮、现实的巨浪、时代大背景、范式转移、深刻变革、历史性时刻
   410→- **伪分类类**：保守派/激进派、向内求索/向外扩展、左派/右派、传统派/革新派
   411→- **鸡汤类**：危机就是转机、这是成长的机会、最重要的选择、挑战与机遇并存
   412→
   413→### 白名单（鼓励使用）
   414→- 说实话、其实、btw
   415→- 这让我想到、我觉得
   416→- 问题是、关键在于
   417→- 说白了、坦白讲
   418→- 技术术语（CVM, Lighthouse, GPU, infra, etc.）
   419→- 具体数据（3秒、0.1%、P95）
   420→- 比喻（最后手段：只在比喻真正比直说更清晰时用；全篇最多 1 个，没有也可以）
   421→- **永久禁用**：简装房（仅限特定历史场景，不再使用）
   422→
   423→---
   424→
   425→**使用建议**:
   426→1. 首次修订，严格按流程走一遍（约30分钟）
   427→2. 熟练后，用"快速修订模板"（5分钟搞定）
   428→3. 定期积累好的改写案例，丰富个人表达库
   429→4. 如果AI生成的某段特别符合你的思路，可以保留，不必过度修改
   430→
   431→**终极目标**: 让读者读完后的感觉是"这绝对是Powell写的"，而不是"这看起来像AI生成的"。
   432→


     1→# 写作风格指南 (Writing Style Guide)
     2→
     3→## 1. 核心语感基因 (Style DNA)
     4→*   **结构化思考，碎片化表达**：
     5→    *   习惯使用清晰的列表（1, 2, 3...）和子弹点。
     6→    *   即便是复杂论述，也要拆解为明确的标题（如“现状”、“挑战”、“结语”）。
     7→*   **技术理想主义的浪漫**：
     8→    *   可以使用宏大的历史或文学隐喻（如：西西弗斯、巴别塔、福特生产线、魔法），但每篇文章**最多出现 1-2 个比喻**，不重复使用同一个。
     9→    *   将枯燥的技术概念”人格化”或”生活化”（如：服务器是宠物还是牛群）。
    10→*   **真诚且透明的“自黑”**：
    11→    *   不避讳谈及局限性或个人背景（“小镇做题家”）。以坦诚建立信任，反对官僚套话。
    12→*   **冷静的宿命感与乐观**：
    13→    *   语气中常带有“接受最坏情况，但坚持背水一战”的韧性。
    14→
    15→## 2. 沟通与词汇 (Communication & Vocabulary)
    16→*   **中英技术混排 (Bilingual Accuracy)**：
    17→    *   在中文叙述中自然嵌入技术或商务术语（如：btw, todo, hosting, computing, infra, winback, poc, roadmap）。
    18→    *   专业名词严格保留英文，追求表达的精确性。
    19→*   **结论先行 & “为什么”驱动**：
    20→    *   首先概述核心结论。
    21→    *   强调行动的合理性，解释“为什么要解决这个问题”。
    22→*   **零废话原则 (Zero Fluff)**：
    23→    *   省略无意义的寒暄和重复。直接输出核心逻辑。
    24→
    25→## 3. 输出规范 (Output Standards)
    26→*   **简洁有序**：逻辑结构必须是第一位的，多用子弹点。
    27→*   **去概念化**：擅长将复杂技术“人话化”。
    28→*   **纯文本倾向**：优先用自然语言分段，不用 Markdown 加粗（**xxx**）装饰普通词汇，不用 `---` 分割线制造仪式感，标题和有序列表仅在结构真正需要时使用。
    29→*   **减少解释**：尽量不要用括号来解释术语或者比喻，减少对流畅性的打断
    30→
    31→
    32→## 4. 典型句式 (Patterns to Mimic)
    33→*   “其实我知道大家觉得...但是我也对此持有非常疑虑的态度，我必须要明确承认这一点。”
    34→*   “我们可以从两个极端角度来回答这些所有问题。”
    35→*   “云的理想非常直接，就是我们要建设一个IT的巴别塔。”
    36→*   “这不仅是炫技，更是为了解决...的矛盾。”
    37→
    38→## 5. 禁忌 (Strict Don'ts)
    39→*   **禁止**：说教式的语气（如”记得要注意...”）。
    40→*   **禁止**：在没有具体方案时使用空洞的鼓励话语。
    41→*   **禁止**：使用官僚色彩浓厚的行政套话。
    42→*   **禁止**：在输出文本中提及内部决策框架名称（GPA、IPO 等）——这些是内部推理工具，直接按原则行事即可，不需要向读者点名。
    43→*   **禁止**：在同一篇文章里重复使用同一个比喻；每篇文章比喻总量不超过 1-2 个，超出则删减。
    44→*   **永久禁用比喻**：”简装房”——这是特定历史场景下的表达，不再在任何生成内容中使用。
    45→


Error: File content (12413 tokens) exceeds maximum allowed tokens (10000). Use offset and limit parameters to read specific portions of the file, or search for specific content instead of reading the whole file.


18:      "Bash(/deai:*)",
19:      "Skill(deai)",


grep -A 20 '"deai"' /root/projects/butler/.claude/settings.local.json | head -40


(Bash completed with no output)


find /root/projects/butler -maxdepth 2 -type f \( -name "*deai*" -o -name "*revision*" \) 2>/dev/null


grep -l "去AI\|去ai\|deai\|de-ai" /root/projects/butler/*.md 2>/dev/null


/root/projects/butler/BOT_FEATURES_REFERENCE.md
/root/projects/butler/POWELL_REVISE.md


ls -la /root/projects/butler/tag20260215/.claude/commands/ | grep deai


ls: cannot access '/root/projects/butler/tag20260215/.claude/commands/': No such file or directory


ls -la /root/projects/butler/tag20260215/ 2>/dev/null | head -20


ls -la /root/projects/butler/tag20260302/.claude/commands/ 2>/dev/null | grep deai


total 272
drwxr-xr-x 12  501 games  4096 Feb 15 10:47 .
drwxr-xr-x 20 root root   4096 Mar 19 16:04 ..
-rw-r--r--  1  501 games 24810 Feb  6 15:30 BOT_FEATURES_REFERENCE.md
-rw-r--r--  1  501 games  2812 Feb  2 10:56 BOT_FIX_SUMMARY.md
-rw-r--r--  1  501 games  5114 Jan 22 11:30 Bulter-Bot使用指南.md
-rw-r--r--  1  501 games  1236 Jan 19 13:35 CLAUDE.md
-rw-r--r--  1  501 games  3512 Jan 20 18:34 CONFIGURATION_SUMMARY.md
-rw-r--r--  1  501 games 24884 Feb  5 20:43 debug_failed_payload.json
-rw-r--r--  1  501 games 23142 Feb  6 11:23 debug_request.json
-rw-r--r--  1  501 games    95 Feb  6 11:23 debug_response.json
-rw-r--r--  1  501 games  4596 Jan 19 14:04 decision.md
-rw-r--r--  1  501 games  6743 Jan 22 14:49 distilled_insights.md
drwxr-xr-x  2  501 games  4096 Feb  6 15:30 docs
drwxr-xr-x  2  501 games   168 Mar  2 09:41 experiments
drwxr-xr-x  8  501 games   123 Mar  2 09:40 health
-rw-r--r--  1  501 games  4188 Jan 19 13:46 health.md
-rwxr-xr-x  1  501 games  3989 Feb  4 15:26 h.sh
-rw-r--r--  1  501 games   481 Jan 22 14:46 list_samples.py
drwxr-xr-x  2  501 games   127 Feb  5 20:02 logs


-rw-r--r-- 1 501 games 2799 Jan 29 15:38 deai.md


grep -A 10 -B 2 "deai\|去AI\|AI tone" /root/projects/butler/BOT_FEATURES_REFERENCE.md 2>/dev/null | head -40


### AI味去除工具

**POWELL_REVISE.md** 是一个手动修订规范，用于AI生成内容后的"去AI味"处理。

**典型AI痕迹**:
- ❌ "首先...其次...最后..."
- ❌ "总而言之" "综上所述"
- ❌ 过度工整的排比句
- ❌ "让我们携手共进，共创美好未来"

**修订策略**:
- ✅ 删除过渡词堆积
- ✅ 打破排比对仗


Perfect! Now I have all the information. Let me compile a comprehensive report.

## Summary

I found the existing "deai" skill file in your project. Here's the complete information:

### **Main Deai Skill File**
- **Location**: `/root/projects/butler/.claude/commands/deai.md`
- **Status**: Active and registered in `.claude/settings.local.json`
- **Model**: Sonnet
- **Allowed Tools**: Read, Write, Glob
- **Context**: Fork mode

### **File Content Overview**

The `deai.md` file is a comprehensive skill that removes AI tone from articles. It follows a 7-step process:

1. **Parse Input** - Takes file path as argument
2. **Read Reference Guides** - Uses `POWELL_REVISE.md` and `writing_style.md` as authority
3. **Read Original Article** - Loads the content
4. **Analyze and Revise** - Applies revision standards in specific order:
   - Section 零 (Ten writing principles)
   - Section 一 (AI trace checklist)
   - Section 二 (Revision operations manual)
   - Style alignment with writing DNA
5. **Generate Revised Filename** - Adds `-Revised` before extension
6. **Save Revised Version** - Writes humanized content
7. **Confirmation** - Shows changes with specific rules applied

### **Reference Documents**

**1. POWELL_REVISE.md** (`/root/projects/butler/POWELL_REVISE.md`)
- 432 lines comprehensive guide covering:
  - 7 core writing principles (problem-driven, deletion priority, no recap, direct judgment, etc.)
  - AI trace identification checklist with 9 categories
  - Sentence-level revision operations
  - Special case handling
  - Self-checklist with 16 verification points
  - Quick template for rapid revision
  - Vocabulary blacklist/whitelist

**2. writing_style.md** (`/root/projects/butler/writing_style.md`)
- User's authentic writing style DNA:
  - Structured thinking with fragmented expression
  - Technical idealism romanticism (limit to 1-2 metaphors per article)
  - Candid "self-deprecation" and transparency
  - Calm fatalism with optimism
  - Bilingual tech mixing (中文 + btw, todo, hosting, etc.)
  - Conclusion-first approach
  - Zero-fluff principle
  - Typical sentence patterns
  - Strict prohibitions (no "简装房" metaphor, no pedagogical tone, etc.)

### **Registration**

The skill is registered in `/root/projects/butler/.claude/settings.local.json` as:
- `Bash(/deai:*)`
- `Skill(deai)`

### **Backups**

The skill was also archived in:
- `/root/projects/butler/tag20260302/.claude/commands/deai.md` (March 2, 2026 snapshot)

### **Related Documentation**

The skill is referenced in:
- `/root/projects/butler/BOT_FEATURES_REFERENCE.md` - includes a section on "AI味去除工具" (AI tone removal tool)

The deai skill is fully implemented and ready to use. It integrates deeply with your personal writing standards as defined in the POWELL_REVISE.md and writing_style.md guides.

agentId: abdadb149058d8d42 (use SendMessage with to: 'abdadb149058d8d42' to continue this agent)
<usage>total_tokens: 33449
tool_uses: 22
duration_ms: 157278</usage>

Prompt: Search for the existing "deai" skill file in this project. Look for files related to "deai", "de-ai", "去ai化", or "AI tone removal" in the .claude directory, superpowers directory, or any skills directory. Read the full content of any matching files. Also check for any related prompt files or configuration.


# 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味):
这个方案能不能行？我觉得问题不大，主要是看执行。
```

**保留技术准确性**:
```
✅ 保持: 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生成的"。


# 写作风格指南 (Writing Style Guide)

## 1. 核心语感基因 (Style DNA)
*   **结构化思考，碎片化表达**：
    *   习惯使用清晰的列表（1, 2, 3...）和子弹点。
    *   即便是复杂论述，也要拆解为明确的标题（如“现状”、“挑战”、“结语”）。
*   **技术理想主义的浪漫**：
    *   可以使用宏大的历史或文学隐喻（如：西西弗斯、巴别塔、福特生产线、魔法），但每篇文章**最多出现 1-2 个比喻**，不重复使用同一个。
    *   将枯燥的技术概念”人格化”或”生活化”（如：服务器是宠物还是牛群）。
*   **真诚且透明的“自黑”**：
    *   不避讳谈及局限性或个人背景（“小镇做题家”）。以坦诚建立信任，反对官僚套话。
*   **冷静的宿命感与乐观**：
    *   语气中常带有“接受最坏情况，但坚持背水一战”的韧性。

## 2. 沟通与词汇 (Communication & Vocabulary)
*   **中英技术混排 (Bilingual Accuracy)**：
    *   在中文叙述中自然嵌入技术或商务术语（如：btw, todo, hosting, computing, infra, winback, poc, roadmap）。
    *   专业名词严格保留英文，追求表达的精确性。
*   **结论先行 & “为什么”驱动**：
    *   首先概述核心结论。
    *   强调行动的合理性，解释“为什么要解决这个问题”。
*   **零废话原则 (Zero Fluff)**：
    *   省略无意义的寒暄和重复。直接输出核心逻辑。

## 3. 输出规范 (Output Standards)
*   **简洁有序**：逻辑结构必须是第一位的，多用子弹点。
*   **去概念化**：擅长将复杂技术“人话化”。
*   **纯文本倾向**：优先用自然语言分段，不用 Markdown 加粗（**xxx**）装饰普通词汇，不用 `---` 分割线制造仪式感，标题和有序列表仅在结构真正需要时使用。
*   **减少解释**：尽量不要用括号来解释术语或者比喻，减少对流畅性的打断

## 4. 典型句式 (Patterns to Mimic)
*   “其实我知道大家觉得...但是我也对此持有非常疑虑的态度，我必须要明确承认这一点。”
*   “我们可以从两个极端角度来回答这些所有问题。”
*   “云的理想非常直接，就是我们要建设一个IT的巴别塔。”
*   “这不仅是炫技，更是为了解决...的矛盾。”

## 5. 禁忌 (Strict Don'ts)
*   **禁止**：说教式的语气（如”记得要注意...”）。
*   **禁止**：在没有具体方案时使用空洞的鼓励话语。
*   **禁止**：使用官僚色彩浓厚的行政套话。
*   **禁止**：在输出文本中提及内部决策框架名称（GPA、IPO 等）——这些是内部推理工具，直接按原则行事即可，不需要向读者点名。
*   **禁止**：在同一篇文章里重复使用同一个比喻；每篇文章比喻总量不超过 1-2 个，超出则删减。
*   **永久禁用比喻**：”简装房”——这是特定历史场景下的表达，不再在任何生成内容中使用。


---
description: Remove AI tone from article and save revised version
argument-hint: <file_path>
allowed-tools: Read, Write, Glob
context: fork
model: sonnet
---

# De-AI Article Reviser

Remove artificial AI tone from articles using the project's established revision standards.

## Step 1: Parse Input

Input file path: $ARGUMENTS

If no path provided, ask the user to provide a file path.

## Step 2: Read Reference Guides

Read these two files from the project root for revision standards:
- `POWELL_REVISE.md` — the primary de-AI revision guide (principles, AI trace checklist, revision operations, vocabulary blacklist/whitelist)
- `writing_style.md` — the user's authentic writing style DNA

These two files are the **sole authority** on what counts as AI tone and how to fix it. Do NOT use your own generic rules — follow these guides strictly.

## Step 3: Read Original Article

Read the file content using the Read tool with the provided path.

## Step 4: Analyze and Revise

Apply `POWELL_REVISE.md` in this order:

1. **Section 零 (十大写作原则)**: Check each principle — problem-driven opening, deletion priority, no recap, direct judgment, metaphor as last resort, hidden first-person, forced subjectivity, vocabulary reduction, audience baseline, no chicken soup.
2. **Section 一 (AI痕迹识别清单)**: Scan for and fix all listed AI traces — transition word piling, mechanical parallelism, over-balanced phrasing, defensive citations, empty modifiers, AI endings, self-Q&A, perfect three-part structure, grand vocabulary bombing.
3. **Section 二 (修订操作手册)**: Apply sentence-level rewrites — break parallelism, add colloquial tone, vary paragraph lengths, insert genuine thinking.
4. **Style alignment**: Cross-reference with `writing_style.md` to match the user's authentic voice — bilingual tech terms, conclusion-first, zero-fluff, max 1-2 metaphors.

**Preserve**:
- Original meaning and key information
- Technical terms and proper nouns
- Code blocks, lists, and structural formatting
- Original language (Chinese/English)

## Step 5: Generate Revised Filename

From the original file path, generate the revised filename:
- Extract directory, filename, and extension
- Add `-Revised` before the extension
- Example: `/path/to/article.md` → `/path/to/article-Revised.md`

## Step 6: Save Revised Version

Write the humanized content to the new file path.

## Step 7: Confirmation

Output a success message showing:
- Original file path
- Revised file path
- 3-5 specific changes made (reference which POWELL_REVISE rule was applied)

## Output Format

```
Article Revised - AI Tone Removed

Original: /path/to/article.md
Revised:  /path/to/article-Revised.md

Changes applied:
- [原则3 戛然而止] 删除了首尾呼应的结尾段
- [1.1 过渡词] 删除了"首先...其次...最后"结构
- [1.1 空洞修饰词] 将"破坏性是灾难级的"改为具体描述
- ...

Done.
```


Now I have a thorough understanding of both systems. Let me compare them:

**The user's existing system (POWELL_REVISE.md + writing_style.md + deai.md)**:
- Focuses on removing AI traces and matching a specific personal writing style
- Has 10 writing principles (problem-driven, deletion priority, no recap, direct judgment, etc.)
- Has an AI trace identification checklist
- Has sentence-level revision operations
- Has a vocabulary blacklist/whitelist
- Has a personal writing style DNA guide
- The goal is to make text sound like "Powell wrote it"

**The new prompt the user found**:
- Focuses on making text slightly more verbose, explanatory, colloquial
- Has systematic synonym/phrasing substitutions
- Has bracket content integration/removal rules
- Has sentence structure & colloquial touch adjustments
- Maintains technical accuracy
- The goal seems to be for academic/technical papers - making them sound more human-written but in a different way

Both systems aim to remove AI artifacts and preserve technical accuracy while handling brackets differently, using word substitutions, and restructuring sentences. The key difference is direction: Powell's system strips down to direct, concise prose with a specific voice, while the new prompt adds conversational warmth and explanatory detail to academic writing. I'm noticing these two approaches have fundamentally opposite strategies—POWELL prioritizes deletion and compression for a personal tech audience, while the new prompt favors addition and explanation for academic contexts. The voice differs too: POWELL maintains strong personality and opinion, whereas the new approach aims for generic professionalism. They also diverge on specific techniques like bracket handling (delete versus integrate), first-person usage (minimize versus eliminate), and word substitution (simplify versus elevate vocabulary). Even colloquial tone and length control follow opposite principles. The bracket integration technique and synonym substitution patterns are worth considering, though the new prompt's direction toward verbosity conflicts with POWELL's deletion-first philosophy, and adding filler words would undermine the approach's core principle of removing unnecessary elements.


现在我已经完整读取了两个系统。下面是对比分析。

---

## 核心差异：方向完全相反

这是最关键的一点：

| 维度 | 你的现有系统 (POWELL_REVISE) | 新提示词 |
|------|------|------|
| **核心策略** | **减法** — "删句优先于改句" | **加法** — "增加冗余与解释性" |
| **目标** | 像真人（你本人）写的 | 像真人（泛指）写的，但偏"论文腔" |
| **适用场景** | 个人博客/技术文章 | 学术论文/技术文档 |
| **声音** | 强烈个人风格（有 writing_style.md DNA） | 无个性，通用"人味" |
| **长度控制** | 越短越好 | 保持与原文相当 |

新提示词的核心手段是"把简洁的写法展开成更长的写法"（如 "管理" → "开展管理工作"），这在 POWELL 体系里属于**要删掉的废话**。

---

## 具体规则对比

### 1. 括号处理
- **POWELL**: 删除所有解释性括号，无例外
- **新提示词**: 用"也就是"、"即"、"比如"整合进句子（如 `ORM（对象关系映射）` → `对象关系映射即ORM`）

**评价**: 新提示词的"整合"思路在某些技术文档场景下比一刀切删除更灵活。但你的文章面向高级技术受众（POWELL 原则9），括号解释本身就多余，删掉更干净。

### 2. 词汇替换
- **POWELL**: 有黑名单，方向是**用简单词替代花哨词**（"赋能"→删掉，"深入全面"→删掉）
- **新提示词**: 有系统替换表，方向是**用低频词替代高频词**（"采用"→"运用/选用"，"通过"→"借助/凭借"，"基于"→"鉴于"）

**评价**: 两者方向不同。新提示词的替换表本质上是在做"换一种说法让AI检测器认不出来"，但并没有让文字更好。POWELL 的策略是删减而非替换。不过，"以及"替代"和/及/与"这条在列举场景下确实更自然，可以参考。

### 3. 第一人称
- **POWELL**: "隐去第一人称"，但允许偶尔使用，全文不超过5个"我"
- **新提示词**: 完全禁止第一人称

**评价**: 你的规则更务实。个人文章完全不用"我"反而不自然。

### 4. 口语化程度
- **POWELL**: 鼓励适度口语（btw, 其实），但也指出"说实话""说白了"是伪口语
- **新提示词**: 轻度口语化，明确禁止"xxx呢"这种形式

**评价**: 两者都有分寸感，但 POWELL 更深入（区分了真口语和伪口语）。

### 5. 句式层面
- **新提示词**有几个具体的句式规则值得注意：
  - 使用"把"字句（"将对象移动" → "把对象移动"）
  - 条件句转换（"若...则..." → "如果...就..."）
  - 动词短语扩展（这条与POWELL冲突，不可用）

---

## 结论

**整体而言，新提示词不适合你的体系。** 原因：

1. **根本方向冲突** — 新提示词是"加法"（让AI文本变得更啰嗦来模拟人类），POWELL 是"减法"（把AI的废话删干净）。你的方向更高级。
2. **缺乏个性** — 新提示词生成的是"通用人味"，没有你的 writing_style.md 那种辨识度。
3. **目标场景不同** — 新提示词面向学术论文（需要一定的"展开说明"），你的面向技术博客（读者不需要被解释）。

**值得小幅借鉴的点**（如果你觉得有需要的话）：

- **"把"字句偏好** — 将"将X移动到Y" → "把X移动到Y"，更自然，POWELL里没有明确提到这条
- **条件句口语化** — "若...则..." → "如果...就..."，符合POWELL的去书面化精神，可以加入2.2的示例
- **括号整合技巧** — 对于某些括号内容确实重要不能直接删的场景，"也就是"/"即"是比"删除"更好的选项。但这只是极少数情况

要不要把这几个小点补充进 POWELL_REVISE.md？


node "${CLAUDE_PLUGIN_ROOT}/scripts/hooks/run-with-flags.js" "stop:check-console-log" "scripts/hooks/check-console-log.js" "standard,strict"


node "${CLAUDE_PLUGIN_ROOT}/scripts/hooks/run-with-flags.js" "stop:session-end" "scripts/hooks/session-end.js" "minimal,standard,strict"


node "${CLAUDE_PLUGIN_ROOT}/scripts/hooks/run-with-flags.js" "stop:evaluate-session" "scripts/hooks/evaluate-session.js" "minimal,standard,strict"


node "${CLAUDE_PLUGIN_ROOT}/scripts/hooks/run-with-flags.js" "stop:cost-tracker" "scripts/hooks/cost-tracker.js" "minimal,standard,strict"


好的，那就加入进去吧


The user wants me to add the three small points from the new prompt into POWELL_REVISE.md. Let me plan the changes:

1. **"把"字句偏好** — Add to section 2.2 (句子层面)
2. **条件句口语化** — Add to section 2.2 (句子层面)
3. **括号整合技巧** — Modify the existing "禁止括号" rule to add a fallback for truly important bracket content

Let me read the relevant sections more carefully to make precise edits.


    12→**选定策略**:
    13→- 语气强度: 保持原风格，仅去AI痕迹
    14→- 文章结构: 保持清晰结构（1, 2, 3 列表和标题）
    15→- 减少格式: 除了必要的分段，最好不要使用Markdown语法
    16→- 禁止括号: 删除所有解释性括号（含术语解释、补充说明），无例外
    17→- 词汇处理: 删除过渡词堆积 + 打破排比对仗 + 增加口语化 + 保留技术准确性
    18→- 情绪表达: 保持冷静客观，通过细节增加人味；比喻是最后手段，只在真正更清晰时用
    19→

**选定策略**:
- 语气强度: 保持原风格，仅去AI痕迹
- 文章结构: 保持清晰结构（1, 2, 3 列表和标题）
- 减少格式: 除了必要的分段，最好不要使用Markdown语法
- 禁止括号: 删除所有解释性括号（含术语解释、补充说明），无例外
- 词汇处理: 删除过渡词堆积 + 打破排比对仗 + 增加口语化 + 保留技术准确性
- 情绪表达: 保持冷静客观，通过细节增加人味；比喻是最后手段，只在真正更清晰时用


三处修改，逐一进行。

**修改1**: 括号规则从"无例外删除"改为"默认删除，极少数重要内容用整合方式"。


Edit

- 禁止括号: 删除所有解释性括号（含术语解释、补充说明），无例外

- 禁止括号: 默认删除所有解释性括号。极少数情况下括号内容对理解确实不可或缺，用"也就是"或"即"整合进句子，不保留括号本身


node "${CLAUDE_PLUGIN_ROOT}/scripts/hooks/run-with-flags.js" "pre:edit-write:suggest-compact" "scripts/hooks/suggest-compact.js" "standard,strict"


node "${CLAUDE_PLUGIN_ROOT}/scripts/hooks/run-with-flags.js" "pre:insaits-security" "scripts/hooks/insaits-security-wrapper.js" "standard,strict"


node "${CLAUDE_PLUGIN_ROOT}/scripts/hooks/run-with-flags.js" "post:quality-gate" "scripts/hooks/quality-gate.js" "standard,strict"


node "${CLAUDE_PLUGIN_ROOT}/scripts/hooks/run-with-flags.js" "post:edit:format" "scripts/hooks/post-edit-format.js" "standard,strict"


node "${CLAUDE_PLUGIN_ROOT}/scripts/hooks/run-with-flags.js" "post:edit:typecheck" "scripts/hooks/post-edit-typecheck.js" "standard,strict"


node "${CLAUDE_PLUGIN_ROOT}/scripts/hooks/run-with-flags.js" "post:edit:console-warn" "scripts/hooks/post-edit-console-warn.js" "standard,strict"


The file /root/projects/butler/POWELL_REVISE.md has been updated successfully.

- 禁止括号: 删除所有解释性括号（含术语解释、补充说明），无例外

# 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味):
这个方案能不能行？我觉得问题不大，主要是看执行。
```

**保留技术准确性**:
```
✅ 保持: 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生成的"。

- 语气强度: 保持原风格，仅去AI痕迹

- 文章结构: 保持清晰结构（1, 2, 3 列表和标题）

- 减少格式: 除了必要的分段，最好不要使用Markdown语法

-- 禁止括号: 删除所有解释性括号（含术语解释、补充说明），无例外

+- 禁止括号: 默认删除所有解释性括号。极少数情况下括号内容对理解确实不可或缺，用"也就是"或"即"整合进句子，不保留括号本身


**修改2**: 在2.2句子层面添加"把"字句和条件句口语化两条规则。


   126→### 2.2 句子层面（重点修订区）
   127→
   128→**删除过渡词堆积**:
   129→```
   130→Before (AI味):
   131→首先，我们需要理解云计算的本质。其次，要认识到标准化的重要性。最后，我们才能真正实现IT巴别塔的愿景。
   132→
   133→After (去AI味):
   134→云计算的本质是什么？说白了就是标准化。只有把底层标准化了，才有可能建成IT巴别塔。
   135→```
   136→
   137→**打破排比和对仗**:
   138→```
   139→Before (AI味):
   140→我们既要保证性能，又要控制成本，还要提升体验。
   141→
   142→After (去AI味):
   143→性能肯定要保证。但成本控制才是长期可持续的关键，用户体验是这两者平衡后的结果。
   144→```
   145→

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

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

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

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

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


   145→
   146→**增加口语化表达**:
   147→```
   148→Before (AI味):
   149→经过深入分析，我们认为该方案具有可行性。
   150→
   151→After (去AI味):
   152→这个方案能不能行？我觉得问题不大，主要是看执行。
   153→```
   154→
   155→**保留技术准确性**:
   156→```
   157→✅ 保持: CVM, Lighthouse, TTFT, P95, GPU, infra, winback
   158→✅ 保持: 具体的性能数据 "3秒开服" "0.1%的概率"
   159→✅ 保持: 专业术语的英文表达，不要强行翻译成中文
   160→```
   161→
   162→**禁用防御性引号**:
   163→```
   164→❌ 对归纳性词汇套引号制造焦点: "调戏" "数字替身" "你问我答" "主动交办" "包工头模式" "固化" "统一入口" "神器" "抖机灵"

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

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

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

**禁用防御性引号**:
```
❌ 对归纳性词汇套引号制造焦点: "调戏" "数字替身" "你问我答" "主动交办" "包工头模式" "固化" "统一入口" "神器" "抖机灵"


在"增加口语化表达"和"保留技术准确性"之间插入两条新规则。


**保留技术准确性**:

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

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

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

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

**保留技术准确性**:


**保留技术准确性**:

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

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

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

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

**保留技术准确性**:

# 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味):
这个方案能不能行？我觉得问题不大，主要是看执行。
```

**保留技术准确性**:
```
✅ 保持: 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生成的"。

这个方案能不能行？我觉得问题不大，主要是看执行。

+系统会将对象移动到目标路径。

+系统会把对象移动到目标路径。

+**条件句口语化**:

+若配置缺失，则服务将无法启动。

+如果配置缺失，服务就起不来。

**保留技术准确性**:


三处改完了。总结：

1. **括号规则**（第16行）：从"无例外删除"改为"默认删除，极少数不可或缺的内容用'也就是'/'即'整合"
2. **"把"字句**（2.2节新增）：`将X移动到Y` → `把X移动到Y`
3. **条件句口语化**（2.2节新增）：`若...则...` → `如果...就...`

没有引入新依赖，没有改变函数签名。风险很低——都是文档级改动，不影响任何代码逻辑。可以直接在下次 `/deai` 时生效。


好的，你再看下新生成的文本，我还是觉得“不是...是...”这种句式太突兀了。还需要。

但是模式彻底变了。以前程序员靠记语法糖、堆叠代码经验或者熟悉某个框架的隐秘坑位就能建立技术壁垒，现在这些东西在 AI 面前基本归零。大语言模型写出来的代码片段通常比普通熟练工更规整，速度快了几个数量级。

现在的核心挑战不是“怎么写代码”，而是“代码写成什么样才是对的”。

好的架构设计、精准的命名、清晰的代码逻辑，这些东西在 AI 时代反而更值钱。以前这些是锦上添花，现在是保命逻辑。如果你给 Claude Code 的上下文是一团糟，命名不知所云，逻辑耦合严重，AI 很快就会被你带进沟里，开始胡说八道。好的工程实践本质上是在给 AI 提供高质量的“外部大脑”导航。一个项目的 CLAUDE.md 写得清不清晰，直接决定了模型生成的代码是生产力还是技术债。

不要再沉迷于语法细节了。

现在的重点应该是建立从需求到代码的直观映射。与其花半天纠结一个闭包的写法，不如花半小时把开发计划写清楚。这涉及到上下文工程的管理。比如把复杂任务拆解成研究、计划、执行、验证四个阶段，每个阶段只处理特定的逻辑块。这种分而治之的思路，其实是经典软件工程在 AI 时代的复兴。

工程师的角色正在从“打字员”变成“系统审计员”。

你必须对代码有真实的感受。AI 可能会幻觉出一个文件内容，或者写出一个有安全漏洞的 Bash 命令。如果你没有识别坏代码的能力，直接全盘接受，那项目崩掉只是时间问题。

所谓的技术门槛，已经从“熟练度”变成了“判断力”。

确保你的项目有清晰的规范，利用好文件系统作为 AI 的持久化记忆，建立自动化的验证闭环。只有当你能一眼看出 AI 给出的方案是否符合系统整体架构时，你才真正掌握了这套新工具。

现在的代码实现，本质上是把模糊的人类需求转化成精确的工程指令的过程。在这个过程中，对逻辑本质的理解比对语法手册的背诵重要得多。


Please run /login · API Error: 403 status code (no body)


<local-command-caveat>Caveat: The messages below were generated by the user while running local commands. DO NOT respond to these messages or otherwise consider them in your response unless the user explicitly asks you to.</local-command-caveat>


<command-name>/model</command-name>
            <command-message>model</command-message>
            <command-args></command-args>


<local-command-stdout>Set model to Opus 4.6 (1M context)</local-command-stdout>


好的，你再看下新生成的文本，我还是觉得“不是...是...”这种句式太突兀了。还需要。      但是模式彻底变了。以前程序员靠记语法糖、堆叠代码经验或者熟悉某个框架的隐秘坑位就能建立技术壁垒，现在这些东西在 AI 面前基本归零。大语言模型写出来的代码片段通常比普通熟练工更规整，速度快了几个数量级。      现在的核心挑战不是“怎么写代码”，而是“代码写成什么样才是对的”。      好的架构设…


<command-name>/exit</command-name>
            <command-message>exit</command-message>
            <command-args></command-args>


<local-command-stdout>See ya!</local-command-stdout>


No response requested.


<command-name>/compact</command-name>
            <command-message>compact</command-message>
            <command-args></command-args>


<local-command-stderr>Error: Error during compaction: Error: Please run /login · API Error: 403 status code (no body)</local-command-stderr>