最近我开源了一个项目：
humanize-chinese-writing
GitHub：GitHub - Lanqingsong/humanize-chinese-writing: 面向多种本地 AI 工具的中文自然生成 Skill：在首次输出前建立作者站位和作品结构，减少模板化 AI 腔、回答者惯性与提纲拼接感。 · GitHub
它是一套面向中文生成的 Agent Skill，用来降低 AI 文本里的回答感、模板感和机械感。更具体一点，它主要服务于 Codex、Claude Code、WorkBuddy、TRAE 这类桌面或本地 AI 工具。
这些工具和普通网页聊天有一个明显区别：它们经常要直接生成可交付文件。
比如 README、技术博客、项目方案、课程讲稿、接口文档、产品说明、报告段落、代码注释和提交说明。生成结果不只是留在聊天窗口里看一眼，而是会进入仓库、文档、CSDN、公众号、PPT 或客户材料。
这时，AI 文本里的“回答者惯性”就会非常明显。
很多 AI 文稿没有明显语病，逻辑也能看懂，但读起来像一份标准答案：开头交代“本文将从几个方面展开”，中间严格分点，段尾反复拔高，结尾再来一句“希望对你有所帮助”。内容看似完整，交付感却很弱。
我做这个 Skill，想处理的就是这一类问题。
AI 味经常来自“回答者惯性”
我在项目里用了一个词：回答者惯性。
它指的是 AI 在正式写作任务里，仍然沿用聊天回复的姿态。正文一直像在回应一个看不见的提问者，没有真正站到作者位置上。
常见表现包括：
开头先复述任务；
正文沿用户提示逐条扩写；
每一节结构都很整齐；
喜欢连续使用纠正式句型；
抽象词很多，具体条件、动作和结果偏少；
结尾回到服务口吻，继续表示可以帮忙。
这些问题单独出现时不一定严重。真正影响阅读体验的是密度。
一篇技术博客里，每节都用“首先、其次、最后”；一份项目介绍里，段段都在讲“具有重要意义”；一篇 README 里，开头先感谢用户关注，结尾邀请继续提问。读者很快就会感觉到：这不是一篇真正组织过的文章，而是一条被扩写成长文的 AI 回复。
这类问题靠简单润色很难稳定解决。
很多人会直接对 AI 说：
写得自然一点。 降低 AI 味。 不要像机器写的。 更像真人一点。模型收到这类要求后，常见做法是替换几个词，调整一下语气，把正式表达改得口语一点。表面变化有了，文章的底层结构却没有改变。
开头仍然空泛。
段落仍然整齐。
材料仍然按提示词顺序铺开。
结尾仍然回到服务姿态。
文本只是从“正式 AI 味”变成“口语 AI 味”。
所以这个项目没有把重点放在事后替词上，而是把规则放在生成之前。
这个 Skill 的核心思路：先切换写作路径
humanize-chinese-writing的目标，是让 AI 在第一次动笔前先完成一次判断：
这次任务是什么文体？
读者是谁？
文本最后会出现在哪里？
读者读完需要获得什么？
用户提示里哪些是材料，哪些是约束？
正文应该按什么顺序展开？
哪些对话痕迹需要从成稿里移除？
这一步看起来很简单，但对最终文本影响很大。
同样是介绍一个开源工具，写法可以完全不同。
如果目标是 README，重点应该放在项目是什么、解决什么问题、如何安装、如何使用、能力边界在哪里。
如果目标是 CSDN 博客，重点应该放在问题场景、项目动机、实现思路、典型样例和参与方式。
如果目标是课程讲稿，重点应该按学习者的理解顺序展开，先建立直觉，再进入概念。
如果目标是客户方案，重点应该保留条件、限制、责任边界和交付路径。
很多 AI 文本的问题在于，它没有真正判断文体，只是把用户给的材料全部扩写一遍。
Skill 会把“用户提示”转换成“写作约束”，再根据文本任务重新组织正文。
比如用户说：
不要写成宣传文案，要写成给开发者看的项目介绍。 不要沿着我的提示逐条回答，要像一篇可以发布的 CSDN 博客。 说明这个 Skill 为什么有效，但不要夸大。 最后欢迎大家提意见和参与项目。生成前应该提取成这样的约束：
读者：开发者、AI 工具使用者、中文写作者 场景：CSDN 博客、项目介绍、开源推广 主线：AI 交付文稿的问题 → 回答者惯性 → Skill 的处理方式 → 使用场景 → 参与方式 语气：技术分享，不写成广告 边界：不承诺消除所有 AI 味，不承诺绕过检测器 结尾：邀请 Issue、PR 和实际使用反馈正文只使用这些约束，不把用户和 AI 之间的协商痕迹搬进文章。
它主要处理哪些中文 AI 味
这个项目目前重点处理五类问题。
1. 站位问题
很多 AI 文稿的第一句话就暴露了站位：
你提出的这个问题非常有价值，下面我将从背景、原因、解决方案几个方面展开说明。这句话适合聊天回复，不适合交付文稿。
文章应该直接进入主题，例如：
用 AI 生成中文文稿时，最容易暴露痕迹的地方，往往不是语法错误，而是文章一直像在回答问题。这里有一个细节需要注意：项目本身也会避免把这种对立句当成万能写法。中文里必要的辨析可以保留，但整篇文章不能一直靠对立句推进。真正自然的正文应该由主题、材料和因果关系推动。
2. 结构问题
AI 很喜欢固定结构：
一、项目背景 二、核心功能 三、使用方法 四、总结展望这种结构不是不能用，但它经常掩盖一个问题：文章只是按模板装材料，没有自己的推进线。
更适合 CSDN 博客的结构可以是：
我遇到的问题 这个问题为什么常见 项目如何处理 在桌面 AI 工具里怎么用 目前边界在哪里 欢迎大家参与这条线更接近读者的阅读过程，也更适合介绍一个开源项目。
3. 信息问题
AI 文本常见的一类空泛表达是：
该工具能够全面提升中文写作质量，帮助用户实现更加自然、高效、专业的内容创作。读起来很顺，但信息量不够。
更具体的写法是：
这个 Skill 会在正文生成前约束模型：先判断读者、文体和使用场景，再把用户提示转换成写作约束，最后检查站位、结构、信息、句式和节奏。读者能看到它具体做了什么，也能判断这个工具是否适合自己。
4. 句式问题
很多 AI 文本喜欢连续使用纠正式表达：
它不是简单润色，而是系统优化。 关键不在词语，而在结构。 真正重要的不是降低痕迹，而是提升质量。这种句式密度一高，文章会一直像在反驳某个观点。
Skill 不会把所有对立句都删掉。必要的概念辨析仍然可以保留。它真正要控制的是密度和位置：同一小节里不要连续使用相同句式，不要让整篇文章都靠纠正别人来推进。
能直说时就直说：
降低 AI 味需要同时处理文章站位、材料顺序、段落任务和句式节奏。词语替换只能解决一部分表层问题。这个表达更稳定，也更适合正式正文。
5. 节奏问题
AI 文本还有一种很隐蔽的机械感：段落太整齐。
每段长度差不多。
每节都是三点。
每句话都用相同连接词。
每个段尾都来一句总结。
读者会感觉文章像被模板切出来的。
自然的中文写作应该允许节奏变化。该展开的地方展开，该收住的地方收住。定义、例子、判断、限制、结论承担不同任务，段落长度自然也会不同。
Skill 会在生成后检查节奏风险，但它不会为了“像人”故意制造混乱。目标仍然是清楚、准确、可交付。
为什么特别适合 Codex、Claude Code 等桌面 AI 工具
网页聊天里，用户通常问完就结束。桌面 AI 工具则经常连接项目目录、读取文件、修改文件、生成仓库内容。
在这些工具里，AI 的输出经常会变成真实交付物：
README.mddocs/usage.md技术博客初稿
课程讲义
项目总结
接口说明
方案文档
提交说明
代码注释
产品介绍
这类内容需要稳定的写作规则。
你不可能每次都手动提醒模型：
不要复述我的需求。 不要写成问答。 不要沿着我的提示逐条扩写。 不要结尾说如果需要可以继续。 不要堆抽象词。 不要每节都三点。 不要写成广告。Skill 的价值就在这里。
把这些规则沉淀成一个可复用的写作约束后，Codex、Claude Code、TRAE、WorkBuddy 这类工具就可以在生成文稿前自动应用它。你给材料，工具负责根据材料组织成更接近成稿的中文文本。
它不负责替你决定事实，也不负责编造经历。它的作用是约束生成路径，减少明显的 AI 写作惯性。
一个简单对比
假设要介绍这个项目，普通 AI 很容易这样写：
随着人工智能技术的不断发展，AI 写作已经在各个领域得到了广泛应用。然而，AI 生成文本往往存在一定的 AI 味。为了解决这一问题，我开发了 humanize-chinese-writing Skill。本文将从项目背景、核心功能、使用方式和未来展望几个方面展开介绍。这段话的问题很典型：
开头背景空泛；
“广泛应用”没有具体场景；
“存在一定的 AI 味”过于笼统；
“本文将从……”保留了回答姿态；
读者还没看到实际问题。
更适合项目介绍的写法可以这样开始：
我最近在用 Codex、Claude Code 这类工具生成中文文档时，经常遇到一个问题：模型能把内容写完整，却很难直接交付。README 像标准答案，技术博客像提纲扩写，项目说明像客服回复。真正需要修改的地方，经常不是某个词，而是整篇文章的站位和组织方式。这个开头直接进入项目动机。读者能看到真实场景，也能理解为什么需要这个 Skill。
后续再讲回答者惯性、生成前约束、桌面工具使用方式，文章就有了自然推进。
如何安装和使用
仓库地址：
https://github.com/Lanqingsong/humanize-chinese-writing如果你使用的工具支持 Agent Skills，可以直接克隆项目到对应目录。
例如 Codex：
git clone https://github.com/Lanqingsong/humanize-chinese-writing.git "$env:USERPROFILE\.codex\skills\humanize-chinese-writing"Claude Code：
git clone https://github.com/Lanqingsong/humanize-chinese-writing.git "$env:USERPROFILE\.claude\skills\humanize-chinese-writing"WorkBuddy：
git clone https://github.com/Lanqingsong/humanize-chinese-writing.git "$env:USERPROFILE\.workbuddy\skills\humanize-chinese-writing"TRAE 的自定义规则和 Skill 入口可能随版本变化。如果当前版本支持 Skills，可以导入整个仓库；如果只支持 Rules，可以把SKILL.md的正文作为项目规则或用户规则使用。
安装完成后，可以直接点名：
使用 humanize-chinese-writing 写一篇 CSDN 博客，介绍这个开源项目，直接给出可发布成稿。也可以用于 README：
使用 humanize-chinese-writing 重写 README，让它脱离聊天上下文独立成立，保留安装步骤、使用方式和能力边界。用于技术方案：
使用 humanize-chinese-writing 整理这份技术方案。按照读者理解顺序组织内容，保留事实、数据、限制和责任边界。用于课程讲稿：
使用 humanize-chinese-writing 整理这份课程讲稿。先建立直觉，再解释概念，不要沿我的提示逐条扩写。有些工具支持$humanize-chinese-writing、/humanize-chinese-writing等显式调用方式。没有显式入口时，直接用自然语言点名也可以。
项目边界
这个项目目前仍然是一个写作 Skill，能力边界需要说清楚。
它不能凭空补出高质量材料。
它不能替代事实核查。
它不能保证所有文体都一次成稿。
它不会承诺绕过任何检测器。
它不会通过错别字、病句和混乱标点制造所谓“真人感”。
它更适合做一件事：让 AI 在生成中文交付文稿时，提前避开一些稳定出现的模板路径。
材料扎实，Skill 能帮助组织得更自然。
材料很空，Skill 只能减少机械表达，无法创造真实内容。
文体要求正式，Skill 会保留准确和克制，不会为了活泼破坏专业性。
事实边界不明确，Skill 应该保留限定，而不是为了流畅擅自补完。
我希望它成为一个实用的写作约束，而不是一个夸张的“AI 味清除器”。
欢迎一起完善这个项目
humanize-chinese-writing目前已经开源，后续还会继续完善。
我比较希望收到几类反馈：
哪些中文 AI 味最影响交付；
哪些规则在 CSDN、README、方案、课程讲稿中最有效；
哪些表达被规则误伤了；
Codex、Claude Code、TRAE、WorkBuddy 里的实际调用体验如何；
是否需要为不同文体增加专门规则；
审计脚本还能补充哪些中文模板风险；
项目安装方式是否需要适配更多工具。
如果你经常用 AI 写中文博客、README、项目文档、课程讲义或技术方案，欢迎试用这个项目，也欢迎在 GitHub 提 Issue 或 PR。
项目地址：
GitHub - Lanqingsong/humanize-chinese-writing: 面向多种本地 AI 工具的中文自然生成 Skill：在首次输出前建立作者站位和作品结构，减少模板化 AI 腔、回答者惯性与提纲拼接感。 · GitHub
这个项目会继续围绕一个目标迭代：让 AI 生成的中文交付文稿少一点回答感，多一点真正面向读者的组织能力。
文章标签：AI 写作、Agent Skills、Codex、Claude Code、TRAE、中文写作、CSDN、开源项目
如果有用无忘记点赞收藏
