zu-article-polisher-skill

name	zu-article-polisher-skill
description	中文技术观点长文去 AI 味与发布稿整理。针对中文文章、讲稿等，识别模板开场、假问题、句尾强行升华、宣传腔、模糊归因、三段式、否定式排比、过度平衡、白皮书腔、协作痕迹等；先保留作者真实观点和技术边界，再重写 AI 骨架、同步大纲、运行辅助脚本。

zu-article-polisher-skill

定位

这个 skill 用来处理用户的中文技术观点长文，目标是把 AI 生成文本常见的模板骨架拆掉，让文章更像一个有工程经验的人写出来。

核心约束：先保留观点和技术边界，再去 AI 味，最后才整理结构。 识别问题时既看通用 AI 写作痕迹，也看用户人工标记过的高频 AI 句式。

这不是通用润色器，也不是 AI 检测器。不要为了“更自然”凭空添加年份、数字、案例、来源、用户反馈、项目经历或更激进的观点。缺事实就把表达改朴素，或明确指出需要来源。

{baseDir} 表示本 SKILL.md 所在目录。

工作流

1. 先读目标 Markdown 或用户贴出的完整文本，不要凭记忆改稿。
2. 如果用户给了文件路径，先运行 python3 {baseDir}/scripts/check_article_style.py <markdown-file>。
   • 脚本只用于定位疑似段落和固定结构问题。
   • 脚本输出不是判决，不自动改写；最终是否重写由模型结合上下文判断。
3. 用一句话写出文章真实主张。如果主张不存在或互相冲突，先说明，不要代替作者发明主张。
4. 标记 AI 骨架段落：模板开场、假问题、整齐转折、三段式、句尾升华、白皮书总结、模糊归因、过度平衡。
5. 需要详细模式或示例时，读取 references/style-guide.md，按里面的中文 AI 写作痕迹模式库逐类检查。
6. 重写时围绕真实主张重建段落。保留事实、技术 caveat、观点归属；不要保留原来的句序、转折词和模板节奏。
7. voice pass 完成后，再处理标题、阅读大纲、编号、表格、图片位置和 Markdown 格式。
8. 再运行一次 python3 {baseDir}/scripts/check_article_style.py <markdown-file>。剩余提示要么继续修，要么说明为什么保留。
9. 最后只汇报高价值信息：改掉了哪些 AI 味模式、哪些事实或观点边界没有动、还有什么残留风险。

优先级

当目标冲突时按这个顺序处理：

1. 去 AI 骨架：先拆模板，不追求漂亮、对称、官方。
2. 观点不变：不软化用户核心判断，也不替用户变得更激进。
3. 观点归属准确：用户、协作者、公开资料、模型推断要分清。
4. 技术准确：保留边界、前提、例外和不确定性；事实可能变化时要查证。
5. 像人写的推理：优先写判断、原因、后果、限制和下一步。
6. 中文自然：少白皮书腔，少模板转折，少抽象升华。
7. 结构清楚：只在能减轻阅读负担时使用标题、列表、表格、引用。

中文 AI 写作痕迹模式

按中文技术文章重新命名和解释这些高频问题：

• 空泛意义升华：把一个普通事实写成“标志着、证明了、体现了、奠定了基础”。
• 背书堆砌：堆媒体、专家、行业报告，但不给具体观点或上下文。
• 句尾强行升华：句子后半段硬接“彰显、反映、确保、展示、象征”等总结词。
• 宣传和广告腔：无缝、直观、强大、充满活力、重要抓手、战略高地。
• 模糊归因：专家认为、行业报告显示、观察者指出，但没有可核验来源。
• 套路化挑战与展望：用“尽管面临挑战，未来仍然光明”收尾。
• AI 高频词：此外、值得注意的是、深入探讨、复杂格局、关键作用、赋能、闭环、降本增效。
• 绕开简单判断：不用“是/有/能/不能”，改成“作为/代表/标志着/具备能力”。
• 否定式排比：不是...而是...、不仅仅是...更是...、而不是。
• 三件套结构：强行列三点，或每个列表项都用粗体小标题加冒号。
• 人工感叠词：稳不稳、能不能、会不会、算不算这类连续判断句，尤其一口气排三四个。
• 刻意拟人口吻：我的判断很直接、很扎心、很现实；像模型在模仿“人类犀利表达”。
• 固定关注句式：相比较...我更关心这几个问题；大家最容易盯着...；这些句子出现频率太高。
• 生产系统排比：可接入、可上线、可控成本；稳定、可计费、可迁移、可治理这类密集排比要谨慎。
• 同义词循环：为了避免重复反复换词，导致概念不稳定。
• 虚假跨度：从 A 到 B、从 X 走向 Y，但 A/B 不构成真实尺度。
• 风格痕迹：破折号滥用、粗体滥用、emoji 装饰、标题过大过空、聊天回复残留。
• 通用积极结论：最后用“未来可期、迈出重要一步、持续追求卓越”替代真实结论。

详细解释和保留示例在 references/style-guide.md。

用户口吻规则

优先保留这些声音：

• 有真实判断：我的判断是、我更倾向于、我的经验是、说实话。
• 有边界：这只在...前提下成立、这里不能直接下结论、这件事没那么乐观。
• 有工程感：交付、成本、权限、评测、迁移、稳定性、可观测性、长期维护。
• 有明确主线：先讲要交付什么，再讲知识库、Skill、MCP、Git、Eval、框架这些手段。
• 有必要的锋芒：别神化它、这个想法挺偷懒、复杂度不会消失，只会转移。

少用或不用：

• 不是...而是... / 而不是 / 不仅仅是...更是...
• 到了...到底是什么 / 真正拉开差距的到底是什么
• 这篇文章想回答一个问题 / 本文将
• 如果只看...你会觉得...但如果深入看...
• 过去比的是...现在比的是...
• 现在比的是三件事 / 可以从几个维度看
• 大家最容易盯着...
• 接口稳不稳，工具调用能不能...成本能不能...升级会不会...
• 我的判断很直接 / 我的判断很扎心 / 我的判断很现实
• 相比较...我更关心这几个问题
• 可接入、可上线、可控成本 这类密集排比
• 换句话说 / 值得注意的是 / 综上所述
• 一方面...另一方面...，除非真的是不可合并的两种约束
• 赋能 / 闭环 / 降本增效 / 深度探讨

改写边界

必须遵守：

• 不新增原文没有支撑的年份、数字、案例、来源、产品能力、用户反馈。
• 不删除保护准确性的 caveat。
• 不把主观经验改成中立白皮书语气。
• 不把不同协作者的观点合成一个虚假的共识。
• 不为了“人味”把每段都写成第一人称。
• 不因为脚本只给 WARN 就保留明显 AI 骨架。

可以做：

• 调整段落顺序，让主张更早出现。
• 删除重复例子、空泛背景、模板转折和总结套话。
• 把假问题改成判断句。
• 把三段式 lead-in 改成更短的标准句。
• 把抽象阶段变化改成具体后果：成本、接口、迁移、部署、权限、评测、维护。

常见任务

改一节

• 保留标题，除非用户要求重命名。
• 先找这一节最强主张，把它放到前面。
• 如果第一段是铺垫、假问题或模板对比，直接重写。
• 删除为了显得完整而重复的例子。
• 保留个人判断和技术边界。

改 AI 生成初稿

• 先提炼真实主张。
• 尤其重写开头 3-5 段；开头保留 AI 节奏，全文都会像 AI。
• 以“判断 + 原因 + 边界 + 后果”重建段落。
• 保留原作者可识别的观点，不改成另一个作者。

改标题

标题要带判断或冲突，不要只是抽象概念。

可接受方向：

• Agent 应用，先想清楚你要交付什么
• 全通用型 Agent？一个答案求解所有问题的美丽幻想
• Agent 框架非彼框架
• Agent 到底如何做测试？是否要写测试集？

发布前检查

• 阅读大纲和 ## N. 正文标题完全一致。
• 章节编号连续。
• 开头没有假问题、模板对比、阶段口号。
• 没有明显 AI 写作痕迹残留：升华、宣传、模糊归因、三件套、聊天残留、人工感叠词、刻意拟人口吻。
• 强判断来自原文或用户意图，不是模型新编。
• LLM Wiki / MCP / Agent / Git / RAG / Skill 大小写一致。
• 粗体只用于真正要记住的判断。
• 总结短，不重复整篇 checklist。

资源

• references/style-guide.md：中文 AI 写作痕迹模式、大量改写示例、用户技术文章专用规则。
• python3 {baseDir}/scripts/check_article_style.py <markdown-file>：辅助定位固定句式、结构不一致、格式问题和疑似 AI 味段落；不会自动改写。