dufu：中文文案去掉机器腔，怎样保留原意？

dufu中文文案去掉机器腔怎样保留原意dufu杜甫是一套中文润色 Skill供能读取 SKILL.md 的 Agent 使用。它帮助检查套话、调整表达并要求保留事实、数字和原意附带的检测脚本只提供规则提示。这篇属于“我的 100 个开源项目”系列。前面介绍过选题和上传工具这次把注意力放到写稿技术说明已经写清楚了为什么读起来还是像一段产品宣传文案里的机器腔具体从哪里找“全面提升效率”“赋能创作者”很容易写出来却没有交代谁做了什么。介绍一个工具如果读者看完仍不知道输入什么、得到什么换几个形容词也解决不了问题。dufu 把常见问题拆得很具体模板连接词、抽象名词、冗长定语、过于对称的句子以及反复出现的总结。这些线索能帮作者定位需要重读的地方。技术创作者可以先检查产品介绍、教程开头和发布文案再决定哪些句子确实需要改。有操作顺序的教程可以保留“首先、其次”。有准确因果关系的句子也不用为了少一个词就拆掉。判断应落到这一句是否让人理解不能把词表变成禁用清单。怎样先检查再动手改dufu 有直接改、先诊断和深度改三种路线。普通润色默认交付改写结果先诊断只列问题和建议不改全文深度改允许调整段落顺序但要先列出保留的信息。诊断结果按位置、原句、问题和建议组织便于逐句核对。执行规则如果还没想好是否重写可以这样向 Agent 提要求使用 dufu先诊断这段产品说明只列影响理解的问题和原句位置暂时不要改写。保留产品名、版本、数字和原始立场。拿到诊断后再指定要改的段落。这样能把“哪里难读”和“怎么改”分开处理原稿也方便留作对照。输入也要给得具体。比如这段文字用于项目 README读者第一次接触工具希望留下安装前提和限制那就把这些要求和原稿一起交给 Agent。只说“写得高级一点”很容易把清楚的说明改成更多修辞。需要短稿时还可以说明哪些段落允许压缩哪些命令和参数必须原样保留。想快速扫一遍文本还可以在项目目录执行python scripts/detect.py--file./input.txt--json这个命令需要 Python 和 UTF-8 文本文件。它不会调用一个远程检测服务脚本本身读取文本后按固定规则分析改写仍由读取 Skill 的 Agent 完成。脚本源码表达变自然了事实也要留住对技术文章来说“读起来顺”只是一个条件。版本号、时间、接口名、参数限制和产品承诺改错了句子再自然也不能直接发。下面是为说明方法编写的示例不是项目的实际运行记录原句为了进一步提升资料整理效率我们进行了导出流程的优化。新版支持将搜索结果导出为 JSON 和 Markdown。改写我们改了导出流程。新版支持把搜索结果保存成 JSON 和 Markdown方便继续整理资料。改写保留了两种格式也没有增加“快了多少”“一键完成”等原稿没有的信息。如果原文没说明优化效果不能添上节省几小时的故事如果写的是“可能支持”也不能顺手改成“已经支持”。dufu 的规则要求保留人物、数字、专名、因果关系和原始立场。我的使用建议是把这些信息单独列成检查项改完再对照原稿。涉及引用时措辞润色也不能代替查证出处。写作规则复核可以先只看事实再看文风。第一遍检查数量、条件和承诺有没有变第二遍检查句子是否顺、段落是否重复。发现一句话缺少依据时回到资料补证据或删去主张不靠改成更像真人的口吻掩盖问题。检测结果能证明文章是谁写的吗不能。detect.py 检查的是文本特征是否出现预设连接词、抽象词和对称句式是否有较长句子以及能否找到部分时间、数字或地点线索。输出包括命中的词、句子长度和启发式提示没有“AI 写作概率”字段。这些规则的覆盖范围有限。人工写的文章也可能命中“因此”模板稿也可能完全避开词表。脚本找到的数字线索不等于事实已经核验没有找到时间地点也不代表文章质量差。所以检查结果适合用来挑出值得重读的句子。它不能证明作者身份不能保证通过第三方检测更不能替文章的原创性、准确性和平台审核作结论。dufu 自身也明确不承诺“检测必过”。开始使用前需要准备什么从项目仓库取得 Skill 文件按你所用 Agent 的安装方式放入可读取的位置再提供原稿、读者、用途和不可改动的信息即可。dufu 自身无需注册账号或申请专用 API KeyAgent 的运行方式和费用仍取决于你使用的工具。截至 2026 年 10 月 3 日公开仓库清单为 1.0.2采用 MIT 许可证GitHub 与 Gitee 的 HEAD 提交一致。项目地址GitHub 主仓、Gitee 镜像。版本以以后读取的仓库清单为准。给它第一段原稿时先说明需要诊断还是改写。收到结果后对照事实再通读语气和段落。技术内容有些术语本来就必须准确保留它们比刻意追求口语化更合适。