我做了一个中文自然写作 Skill：让workbuddy, Codex、Claude Code 等AI工具交付文稿少一点 AI 味

最近我开源了一个项目humanize-chinese-writingGitHubGitHub - 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可以直接克隆项目到对应目录。例如 Codexgit clone https://github.com/Lanqingsong/humanize-chinese-writing.git $env:USERPROFILE\.codex\skills\humanize-chinese-writingClaude Codegit clone https://github.com/Lanqingsong/humanize-chinese-writing.git $env:USERPROFILE\.claude\skills\humanize-chinese-writingWorkBuddygit clone https://github.com/Lanqingsong/humanize-chinese-writing.git $env:USERPROFILE\.workbuddy\skills\humanize-chinese-writingTRAE 的自定义规则和 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、开源项目如果有用无忘记点赞收藏