1. 项目概述为什么我们需要一个“说人话”的AI文本清理器如果你和我一样深度依赖AI辅助写作无论是写代码注释、技术文档、产品发布说明还是日常沟通那你一定对下面这种“AI味”文本不陌生“在当今快速发展的人工智能时代如何打造一个真正赋能开发者的工具已经成为业界不容忽视的关键议题。”或者当你在微信上问AI“晚上吃什么”它可能会给你一个这样的回复“先说结论吃日料。我把你最近三周的外卖记录过了一遍已经把差异收窄到两个选项根因基本坐实是你上周说过腻了火锅。要不要我顺手帮你把 X 店的外卖也下了你一回复我就上手。”读起来是不是感觉怪怪的第一段像极了公司年会的开场白充满了空洞的“赋能”、“业界”、“关键议题”等黑话第二段则把技术排查的“根因分析”、“收窄差异”等工程师腔调生硬地套进了生活对话里。这种文本我们称之为“AI味”或“AI slop”——它语法正确信息无误但就是透着一股非人的、模板化的、过度表演的别扭感。MrGeDiao/shuorenhua说人话这个项目就是为了解决这个问题而生的。它不是简单的同义词替换器也不是要把文本润色得辞藻华丽。它的目标非常聚焦识别并清理AI模型在生成中文文本时常见的“写作姿态”问题保留核心事实和术语将文本改写成更自然、更可信、更适合直接发布或使用的中文。简单说就是把AI写出来的“机器腔”改回当前场景下一个正常人会说的话。这个项目特别适合以下几类人开发者与工程师经常用AI生成代码注释、提交信息、技术文档、Issue回复希望文本更专业、直接避免“过度设计”的说明。内容创作者与运营使用AI辅助撰写社交媒体文案、博客、产品介绍需要去除营销腔和模板感让内容更接地气。任何与AI协作写作的人在日常沟通、邮件、报告撰写中希望AI的输出更像“人话”减少阅读时的认知摩擦和尴尬感。它的核心价值在于提供了一套基于规则和场景判断的、可复现的“文本风格校准”方案。你不是在盲目地让AI“改写得更自然”而是给它一套明确的“交通规则”告诉它哪些是“违规驾驶”如过度承接、无源引用并引导它驶向“安全、顺畅”的表达车道。2. 核心设计思路从“见词就杀”到“场景化手术”很多初级的“去AI化”尝试容易陷入“敏感词过滤”的陷阱即建立一个禁用词列表见到“赋能”、“抓手”、“闭环”就替换或删除。这种方法粗暴且容易误伤因为同一个词在不同语境下含义可能天差地别。说人话项目的设计哲学要精细得多。它更像一个拥有丰富经验的文本编辑其工作流程不是简单的“查找-替换”而是一个多层次的“诊断-手术”过程。理解这个设计思路是有效使用它的关键。2.1 核心工作流八步诊断法项目核心文件SKILL.md定义了一套严谨的工作流我将其概括为“八步诊断法”场景预判首先判断文本的用途。是日常聊天(chat)、技术状态同步(status)、技术文档(docs)还是公开写作(public-writing)不同的场景决定了后续处理的“手术刀”的锋利程度。比如chat场景下只会处理最明显的套话力求保留口语感和随意性而public-writing则会启用全部规则进行深度扫描。划定保护区在动刀之前先圈出绝对不能碰的“文物区”。这包括数字与版本日期、时间、版本号如v1.8.0、指标数据。改写时绝不能把Python 3.9改成Python 大约三点九。代码上下文命令行指令、文件路径、API参数、配置项、错误信息。这是技术文本的命脉必须原样保留。事实归属具体的人名、组织名、明确的责任主体和时间线。避免模糊化处理导致信息失真。引用与证据引号内的原文、完整的报错堆栈、实验数据结果。这些是论述的基石不容篡改。问题强度分级不是所有“AI味”都同等严重。系统会识别问题的强度等级轻微模板感如过度使用“首先”、“其次”、“总而言之”等连接词。明显AI腔如“赋能”、“深耕”、“打造一站式解决方案”等互联网黑话。结构性表演感整段文本呈现出一种固定的、不自然的“姿态链”例如“先替对方下判断 - 表演深度共情 - 给予夸张赞誉”的“接住体”。决定改写档位根据场景和问题强度决定是“轻修”只改几个词、“中改”调整句式结构还是“重写”对整段姿态进行重构。触发场景包这是v1.8.0版本引入的强大功能。当识别出文本属于README、发布说明(release note)、论坛帖子(forum post)或Issue回复(issue reply)这些具体子场景时会调用专门的“场景包”(Scene Packs)进行更精准的整形。例如README场景包会重点清理“价值宣言堆叠”确保开头就讲清楚项目是什么、为谁解决什么问题。模式与词条双重清理先处理高层的“结构反模式”如“无源引用”使用“众所周知”、“人们常说”但无具体出处再使用“禁用短语”词库进行兜底清理。项目目前积累了210条中文短语和96条英文短语的识别规则。保真回读改写完成后进行一次快速“质检”。检查核心事实、术语、语体风格是否保持了一致保护片段是否完好句子之间是否有因改写而产生的断裂感。残留审计最后进行一次针对性扫描(Residual Audit)专门查找是否还有“开场白残留”如“在...背景下”、“总结陈词残留”如“综上所述”、“旁白腔残留”如以旁观者角度评论文本自身等漏网之鱼。这一整套流程的核心原则用一句话概括就是先保信息再谈风格。所有花哨的改写都必须建立在“不歪曲事实、不破坏技术准确性”的基础之上。这使它特别适合处理技术协作中那些需要精确性同时又要求表达自然度的文本。2.2 正向风格引导不只是删除更是重建清理“AI味”并非一味做减法。说人话项目还定义了一系列“正向风格目标”为改写指明方向具体动作优先将“我们将对系统进行优化”改为“我们会把数据库查询缓存起来”。真主语和真动作将“该方案的落地遇到了挑战”改为“我们在部署时发现内存不够”。允许不完美不追求每一句话都打磨得同样光滑、对称。保留一些口语化的、稍显冗长的表达反而更显真实。场景校准确保改写后的文本风格与场景匹配不会把技术报告改成散文也不会把聊天记录改成公文。这种“破而后立”的思路使得它的产出不是一篇被阉割得干巴巴的文字而是一篇更聚焦、更直接、更像“人”写出来的内容。3. 实操指南如何在不同平台集成与使用了解了核心思路下一步就是把它用起来。说人话项目设计得非常开放可以集成到多种AI编码助手和聊天界面中。下面我将以最常用的几种场景为例提供详细的配置步骤和操作心得。3.1 在 Cursor / Windsurf 中深度集成对于重度使用Cursor这类IDE智能插件的开发者深度集成能获得最佳体验。不建议每次手动复制粘贴SKILL.md而是将其作为项目级的写作规范。操作步骤克隆项目到本地在你的项目根目录或一个全局配置目录下执行git clone https://github.com/MrGeDiao/shuorenhua.git。配置 Cursor Agent Rules在项目根目录创建或编辑.cursor/rules.mdc文件如果没有该目录和文件请自行创建。添加规则在rules.mdc中加入如下内容。这段规则告诉Cursor当涉及写作和改写任务时优先参考shuorenhua的规则但对于代码生成、日志分析等纯技术任务则不要套用以免影响准确性。## 写作与文本风格 当你需要处理中文文本的改写、润色、总结或扩写任务特别是用户提到“去AI味”、“说人话”、“自然一点”、“别那么正式”时请严格遵循 [你的路径]/shuorenhua/SKILL.md 中的规则和工作流。 **特别注意**对于代码生成、命令行操作、日志分析、数据结构解释等纯技术性输出不应用此风格规则应优先保证技术准确性和清晰度。测试在Cursor中尝试让AI写一段版本更新说明。你可以对比一下在启用规则前后AI生成的文本从“隆重宣布我们激动地发布了v2.0它带来了颠覆性的体验...”变成了“v2.0主要更新了以下内容1. 修复了XX漏洞2. 新增了YY接口...”。实操心得将shuorenhua的路径设置为相对路径如./shuorenhua/SKILL.md可以让配置随项目走便于团队共享。单独为每个项目配置可能有点麻烦但对于需要统一对外技术文档风格的项目来说这点投入非常值得。3.2 在 ChatGPT 或 Claude 中作为自定义指令如果你主要在Web端使用ChatGPT或Claude进行写作那么“自定义指令”(Custom Instructions)或“永久上下文”是最佳入口。操作步骤以ChatGPT为例打开ChatGPT设置找到“自定义指令”。在“关于你”或“如何回复”的框中添加如下核心提示当我要求你改写、润色或生成需要对外发布的中文文本如博客、文档、邮件、社交媒体文案时请遵循以下原则 1. 避免使用“赋能”、“抓手”、“闭环”、“深耕”、“打造一站式解决方案”等互联网黑话和空洞短语。 2. 避免“在...背景下”、“随着...发展”等套路化开场。 3. 避免替读者下判断或过度共情的“接住体”表达。 4. 优先保留具体数字、代码、命令、错误信息等事实细节。 5. 让语言更直接、具体像两个专业人士在对话。 你可以参考“说人话”(shuorenhua)项目的风格来处理这类请求。当你需要生成一段文本时可以在提问中再次强调“请用‘说人话’的风格来写”。注意事项Web端模型的上下文窗口和指令遵循能力有限这种方法无法实现项目里那种精细的场景判断和多层工作流。它更像一个“简约版”的提醒。对于非常重要的文本建议还是将待改写的文本和SKILL.md的核心规则一起粘贴到对话中进行单次处理。3.3 通过命令行工具进行批处理对于有编程基础需要批量处理大量文本如一堆AI生成的初稿文档的用户可以通过命令行调用Codex或OpenAI API来实现。一个简单的Python脚本示例假设你已经配置好了OpenAI的API密钥。import openai import os # 读取 shuorenhua 的 SKILL.md 作为系统提示词 with open(path/to/shuorenhua/SKILL.md, r, encodingutf-8) as f: system_prompt f.read() def rewrite_with_shuorenhua(text, scenepublic-writing): 使用说人话规则改写文本 :param text: 待改写的原文 :param scene: 场景可选 chat/status/docs/public-writing :return: 改写后的文本 user_prompt f 请遵循已提供的规则以【{scene}】场景改写以下文本。 请先进行场景判断和问题分析然后执行改写确保保留所有事实细节数字、代码、名称等。 待改写文本{text} response openai.ChatCompletion.create( modelgpt-4, # 或 gpt-3.5-turbo messages[ {role: system, content: system_prompt}, {role: user, content: user_prompt} ], temperature0.2 # 低温度保证输出稳定符合规则 ) return response.choices[0].message.content # 使用示例 original_text 在数字化转型的浪潮中本项目致力于赋能开发者打造极致体验的开发工具链。 rewritten_text rewrite_with_shuorenhua(original_text, scenedocs) print(改写前, original_text) print(改写后, rewritten_text)运行后输出可能会是“这个项目主要帮助开发者提升开发工具链的使用效率。”技术细节这里将temperature参数设得较低0.2是为了让AI的输出更确定、更严格地遵循系统提示词中的规则。如果设得过高改写风格可能会不稳定。4. 场景深度解析从“通用清理”到“外科手术”说人话项目之所以强大在于它不仅仅做通用化处理更能针对特定写作场景进行“外科手术式”的精准优化。v1.8.0版本引入的Scene Packs场景包功能是这一能力的集中体现。理解并善用这些场景能让你的文本质量提升一个档次。4.1 Scene Packs四大可发布文本场景这四种场景对应了开发者和技术写作者最高频的对外沟通需求。它们的优化目标截然不同。场景包核心目标典型“手术”操作避坑指南README第一屏说清价值让访客在10秒内明白这是什么、能做什么、如何开始。1.砍掉口号删除“引领未来”、“革命性”等空洞标语。2.聚焦问题将“功能列表”重构为“为你解决XX痛点”。3.前置先决条件把“安装要求”提到“快速开始”之前避免用户跑了一半才发现环境不对。切忌把README写成产品发布会讲稿。它的首要任务是信息传递效率而非情绪渲染。Release Note清晰罗列变更让用户快速了解变了什么、为何要变、升级时要注意什么。1.去情绪化删除“我们非常激动地宣布”、“隆重推出”等发版感言。2.结构化分类严格按Added(新增)、Changed(变更)、Fixed(修复)、Breaking(破坏性变更)分类。3.附上证据对关键修复可提及关联的Issue编号或测试结果。避免使用“性能大幅提升”这种模糊表述改为“查询响应时间平均降低40%”。用户要的是事实不是感受。Forum Post (论坛帖)像维护者在分享分享真实经验、技术取舍和观察建立信任。1.去官方腔避免“本公司”、“我们团队”这种疏离感称呼多用“我”。2.展现过程保留一些探索中的失败尝试和思路转折这比直接给完美方案更真实。3.具体提问如果需要帮助问题要具体附上环境、代码片段和错误日志。论坛帖不是产品公告栏。目的是交流不是广播。带着具体问题和真诚分享的心态去写。Issue Reply (Issue回复)高效解决问题确认问题、厘清范围、明确下一步推动问题闭环。1.确认复现首先表明“我看到了你的问题”或“我尝试复现了”。2.划定边界明确这是bug、文档问题还是使用方式问题。3.给出可操作项是提供修复补丁、给出临时方案还是需要用户提供更多信息避免“我们会关注”这类无效回复。切忌客服式的“抱歉给您带来不便”。开发者社区更认可直接、务实、聚焦于解决方案的沟通。4.2 基础场景的实战应用除了上述四个精细场景四个基础场景决定了改写的“力度”。chat(聊天):力度最轻。只删除最刺眼的套话如“请问还有什么可以帮您”这种客服结尾或者“您提到了一个非常深刻的问题”这种过度承接。目标是保留聊天的随意感和即时性不能把朋友间的吐槽改成工作报告。示例AI回复“您的观察非常敏锐这确实点出了问题的核心。”可能被简化为“对这个问题很关键。”status(状态同步):力度中等。常用于团队日常站会、项目进度更新。核心是保留动作、状态、阻塞点和下一步计划这些硬信息压掉“在领导的带领下”、“经过团队不懈努力”等套话。示例“关于XX模块的优化目前正在持续推进中已取得阶段性成果。” 改为“XX模块正在重写缓存逻辑已完成70%等DB索引方案确定后继续。”docs(技术文档):力度中等偏保守。包括API文档、代码注释、部署指南。绝对优先保护技术准确性命令、参数、代码块。清理的目标主要是去除不必要的“教学腔”如“值得注意的是”、“显而易见地”和冗余的解释让文档更简洁、直给。示例“调用此API将返回一个用户对象值得注意的是该对象包含了用户的详细信息。” 改为“此API返回用户对象内含用户详情。”public-writing(公开写作):力度最重并会触发Scene Packs。用于博客、技术文章、产品公开信等所有对外的、希望树立专业或个人品牌形象的文本。启用全部规则进行扫描并努力将文本导向“真诚、专业、易懂”的风格。场景选择心法当你 unsure 该用哪个场景时问自己一个问题这段文字最糟糕的结局是什么如果是“让朋友觉得我像个机器人”用chat如果是“让同事看不懂项目卡在哪里”用status如果是“让用户照着文档做还是出错”用docs如果是“让读者觉得我在吹牛或说空话”用public-writing。5. 避坑指南与常见问题排查即使有了强大的工具在实际使用中也可能遇到问题。以下是我在深度使用说人话项目过程中总结出的常见“坑点”和解决方案。5.1 效果不理想可能是这些原因问题现象可能原因解决方案改完后“AI味”依然很重1. 使用的AI模型如GPT-3.5对复杂系统提示词遵循能力不足。2. 输入文本的“结构性表演感”太强超出了当前词库和模式的覆盖范围。3. 场景(scene)选择错误例如用chat场景去改一篇正式博客。1.升级模型优先使用GPT-4、Claude 3等更强的模型它们对指令的理解和遵循能力好得多。2.人工干预对于特别顽固的文本可以先让AI“诊断”使用annotation mode指出问题所在然后你再根据诊断结果手动指导它改写某个局部。3.检查场景确认你传递给系统的场景参数是否匹配文本用途。误杀了不该改的内容1. 某些专业术语或固定搭配被误判为“黑话”。2. 在docs场景下对代码注释中的一些描述性语句进行了过度修改。1.利用保护区确保数字、代码、命令等已被正确识别和保护。对于易误伤的专业术语可以考虑在原文中用某种方式如反引号临时标记提示AI不要修改。2.调整场景如果是代码注释确保使用docs场景它会更加保守。也可以尝试在提示词中额外强调“此为代码注释仅清理明显冗余保持技术准确性”。改写后语气生硬或断裂1. AI在删除套话后没有很好地重组句子导致连贯性丢失。2. “保真回读”环节未能修复因删除大段内容造成的逻辑断层。1.提供更多上下文不要只给AI一句话给出一整段或上下文。AI在更完整的语境下能做出更连贯的改写。2.分步操作先让AI执行“诊断”列出问题点然后让它针对每个问题点提出修改建议最后再让它整合成一段连贯的文字。这个过程虽然慢但可控性更高。在Cursor/IDE中规则不生效1. Agent规则文件(.cursor/rules.mdc)路径错误或格式不对。2. 当前对话的上下文没有触发规则中定义的条件。1.检查路径确保在rules.mdc中引用的SKILL.md文件路径是有效的。可以先用绝对路径测试。2.明确触发词在向AI提要求时使用规则里定义的关键词如“请用‘说人话’的风格改写这段”、“去掉AI味”。5.2 关于“AI味”的本质思考很多人期望用一个工具就能让AI写出和特定人类一模一样的文字这是不现实的。说人话项目作者也明确指出了这一点“去掉明显套路”不等于“拥有具体作者的个人表达”。这个项目解决的是“公害”问题——那些让大多数人都觉得别扭的、通用于几乎所有AI模型的表达套路。它无法也不应该赋予AI独特的“文风”。你的个人风格比如喜欢用特定的比喻、有独特的节奏感是需要通过微调模型、构建个人语料库或进行细致的后期编辑来实现的。因此请将说人话视为一个优秀的“文本基底处理工具”。它负责把粗糙的、充满模板感的AI初稿打磨成一块干净、规整的“坯料”。在这块坯料的基础上你再进行个性化的雕琢和润色效率会高得多。5.3 贡献与规则迭代如果你发现某个典型的“AI味”表达没有被覆盖或者遇到了有趣的边界案例非常鼓励向项目提交Issue或Pull Request。在提交新词条时一个黄金法则是问自己这是一个全新的“模式”还是现有某个模式的“变体”例如“赋能”是一个模式“助力”、“赋智”可能就是它的变体。提交时如果能归纳出模式如“空洞动词抽象宾语”并提供正反例句会比单纯提交一个词条更有价值。项目中的CONTRIBUTING.md文件提供了详细的贡献指南。从我个人的使用经验来看说人话项目最大的意义是它为我们提供了一套可讨论、可迭代、可验证的“中文数字写作规范”。在AI协作日益深入的今天我们不仅是在教AI如何写更是在重新思考和定义在数字世界里什么是清晰、真诚、高效的沟通。它不再只是一个工具而是一个关于如何与机器共同写作的实践框架。