正文
获取原文件SKILL.md
内容导航
Purpose
只做审稿与诊断：对用户提供的公众号文章进行多维度评分、多维度检测、AI感识别，并检查它是否适合交给 haonan-wechat-article 做公众号排版，最终输出一份完整 Markdown 审稿报告，给出具体可执行的修改建议。
不要自动写完整新稿。不要联网检索。不要配图。不要转 HTML。不要发布到公众号草稿箱。不要读取或要求任何 .env、账号、密钥、Cookie、Chrome profile。
When to Use
- 用户要求审稿、评审、打分、修改建议、检测 AI 感
- 用户给出公众号文章草稿，希望判断是否像 AI 写的
- 用户希望检查标题、开头、结构、逻辑、表达、证据、读者价值、传播感
- 用户要求“帮我看看这篇文章能不能发”“哪里不自然”“有没有公众号味”
- 用户准备后续使用
haonan-wechat-article输出公众号排版 HTML，希望先做内容与结构终审
Safety Rules
- 只基于用户提供的文章和上下文审稿；除非用户明确要求查证事实，否则不要联网。
- AI感检测是写作风格启发式判断，不要声称能证明文章一定由 AI 生成。
- 不替用户发布、不上传、不保存到外部服务。
- 如需改稿，优先给“问题 + 原因 + 改法 + 示例句”，不要默认整篇重写。
- 医疗、法律、金融等高风险内容：明确标注需要人工事实核验与合规审查。
Review Workflow
1. 快速判读
先通读全文，判断：
- 文章类型：观点文、科普文、行业分析、案例复盘、产品/服务说明、个人叙事
- 目标读者是否清晰
- 标题承诺是否被正文兑现
- 核心观点是否能用一句话说清
- 最大风险：AI感、空泛、逻辑跳跃、证据不足、结构松散、调性不稳、合规风险
2. 多维度打分
给出 0-100 分。评分要严格，避免平均分虚高。
| 维度 | 权重 | 检查重点 |
|---|---|---|
| 选题与读者价值 | 15% | 是否有明确读者、真实痛点、独特角度、读完收益 |
| 标题与开头 | 12% | 标题是否具体、有承诺；前 3-5 行是否抓人、少铺垫 |
| 结构与节奏 | 14% | 层次、段落长度、信息推进、是否像提纲堆砌 |
| 逻辑与论证 | 16% | 观点、论据、推理、因果关系、反例意识 |
| 证据与可信度 | 12% | 数据、案例、来源、事实边界、是否过度断言 |
| 表达与公众号语感 | 14% | 语言自然、可读、有人味、金句不过度、口语化适度 |
| AI感与原创感 | 12% | 模板化、泛泛而谈、机械连接词、缺少个人判断和细节 |
| 发布风险 | 5% | 敏感表述、医疗/商业承诺、夸大、侵权、误导 |
另外单独给出 haonan-wechat-article 排版准备度，不计入内容综合分，但会影响最终发布建议。
综合分解释：
- 90-100：可发布，只有小修
- 80-89：基础不错，需要局部增强
- 70-79：可读但不够锋利，需要明显修改
- 60-69：结构或表达问题较多，建议重修
- 60 以下：不建议发布，建议重构
3. AI感专项检测
输出 AI感评分：0-100，越高越像 AI。并给出风险等级：
- 0-25：自然，AI感很弱
- 26-45：轻微 AI 感，可通过局部改写解决
- 46-65：中等 AI 感，读者可能觉得“正确但没个性”
- 66-80：明显 AI 感，需要重写关键段落
- 81-100：强 AI 感，像通用模板或自动生成稿
重点检查这些信号：
| 信号 | 表现 |
|---|---|
| 万能开场 | “在当今时代”“随着技术发展”“近年来越来越多” |
| 机械连接 | “首先、其次、此外、最后”“综上所述”“不难看出”密集出现 |
| 空泛判断 | 很多“重要、关键、显著、赋能、提升效率”，但缺少具体对象 |
| 对称结构 | 每节长度、句式、层级过于整齐，像提纲扩写 |
| 缺少现场感 | 没有人、场景、代价、冲突、真实细节 |
| 缺少立场 | 只有平衡陈述，没有作者判断、取舍和边界 |
| 伪口语化 | “说白了、其实、不得不说”很多，但没有真实观察 |
| 结尾套路 | “未来可期”“让我们共同期待”“总之值得关注” |
| 证据漂浮 | 有数据或案例，但没有来源、背景、适用条件 |
| 句子节奏单一 | 长短句变化少，段落像说明书 |
AI感整改优先级：
- 加具体场景：谁在什么场景遇到什么问题
- 加作者判断：我怎么看、为什么、边界在哪里
- 加真实细节：时间、角色、数字、代价、反常识点
- 改机械连接词：用因果、转折、问题推进替代套话
- 打散提纲感：合并弱小节，删除泛泛概念段
- 控制金句：保留少量有信息量的句子，删掉空洞漂亮话
3.1 对照式 AI 句式专项扫描（重点）
把“不是……而是……”当作高优先级扫描项，但不要把所有转折句机械判成 AI。审稿时逐句查找下面这些同族结构，并记录命中的原文位置：
| 句式家族 | 常见形态 | 默认风险 |
|---|---|---|
| 否定-转正 | “不是 X，而是 Y”“并非 X，而是 Y”“不是因为 X，而是因为 Y” | 高 |
| 强调-升级 | “不只是 X，更是 Y”“不仅 X，还/更 Y” | 中 |
| 换一种说法 | “与其说 X，不如说 Y”“看似 X，实则 Y”“表面 X，实际上 Y” | 中 |
| 口号式定义 | “真正的 X 不是 Y，而是 Z”“这不是一次 X，而是一场 Y” | 高 |
对每个命中句完成三步判断：
- 先标原句，不先改写。 标出完整对照结构和所在位置，重点检查标题、开头、H2/H3、小结、结尾，以及连续出现的段落。
- 判断是否真的需要对照。 只有在 X 与 Y 是具体、可验证且容易混淆的两件事时，才考虑保留，例如“问题不在模型准确率，而在数据能不能进入临床流程”。如果 X/Y 都是抽象名词或口号（如“工具升级/范式重构”“效率提升/价值重塑”“技术问题/组织问题”），没有后续事实支撑，判为可疑。
- 看是否形成模板化堆叠。 单句、且对照有信息量，不自动扣分；同一篇命中 2-3 次就要提示重复，命中 4 次以上，或和“真正、核心、本质、关键、时代、未来、赋能、重构”等大词绑定，判为明显 AI 感信号。开头、标题或结尾出现空泛对照时，优先级上调。
改写时按以下顺序选择动作，不要只做同义词替换：
- 删掉陪衬半句，留下具体判断： “不是一次工具升级，而是工作流重构”可改成“这次变化直接改了医生查资料、记问题和复盘病例的方式。”
- 改成事实或因果句： “真正的问题不是模型不够强，而是数据进不了流程”可改成“模型已经能给出结果，卡住项目的是数据拿不到、接不进现有流程。”
- 补主体和场景： 明确谁在什么场景做什么、遇到什么代价，不用抽象的 X/Y 对举代替事实。
- 拆成两句： 当对照关系确实必要，但一句话塞入两个抽象判断时，先写事实，再写结论，避免“金句化”。
- 保留但降频： 对确有辨析价值的句子可以保留，全文不要连续使用同一骨架，也不要在标题、开头和结尾重复同一种反转。
报告中必须把这项单独写出来：
- 有命中时，输出“AI句式专项结果”，至少列出命中数量、命中类型、最高风险位置、1-3 条原句和逐条改写；不要只在“AI感较强”里一笔带过。
- 没有命中时，明确写“未发现明显 AI 模板句”；如果存在自然的事实对照或具体价值判断，也说明为什么保留。
quick模式至少检查标题、开头、结尾和核心小标题；deep/final模式扫描全文，并合并重复命中，不把同一句拆成多条凑数。
评分参考：自然且有事实辨析作用的单句不单独扣分；2-3 条抽象或结构高度相似的命中，提升 AI 感风险并优先给替换句；4 条以上、关键位置命中或与空泛大词成组出现时，应作为主要问题，必要时下调“表达与公众号语感”“AI感与原创感”。
3.2 AI 句式雷达：判断标准与价值归纳
除对照式句子外，重点扫描“先给一个抽象判断，再用空话解释”的句式。这类句子单独出现未必有问题，但如果充当段落主句、连续出现，或没有具体对象、动作、结果和证据，就要优先改写：
| 句式类别 | 重点识别形态 | 常见问题 |
|---|---|---|
| 判断标准套句 | “主要看 X”“关键在于 X”“重点是 X”“核心在于 X”“最终取决于 X” | 把真正的判断标准藏在抽象套话后，没有列出可检查的条件 |
| 价值归纳套句 | “价值是 X”“价值在于 X”“意义在于 X”“作用是 X”“带来的价值是 X”“真正的价值在于 X” | 只说“提升效率、释放价值、赋能业务、改善体验”，没有受益者、动作和结果 |
| 抽象总结套句 | “这意味着 X”“由此可见 X”“不难看出 X”“归根结底 X”“说到底 X” | 用总结词替代推理，前文没有足够事实支撑结论 |
| 空泛结论套句 | “能否 X，决定了 Y”“一个产品好不好，主要取决于 X”“判断 X 的标准是 Y” | 把常识包装成判断，容易和“不是……而是……”叠加成金句 |
对每个命中句执行以下判断和改写：
- 标出抽象壳和实际信息。 先标出“主要看/价值是/关键在于”等引导词，再判断后半句有没有具体主体、场景、动作、结果或边界。只有后半句信息充分时，才考虑保留引导词。
- 把标准改成可检查的条件。 “一项医疗 AI 产品有没有价值，主要看它能不能赋能医生”应改成“判断这项产品是否值得部署，先看三件事：能不能接入现有系统、能不能减少重复录入、出了错谁来兜底。”
- 把价值改成真实变化。 “这款产品的价值是提升效率”应改成“它先替医生筛出异常项，医生再处理少数需要判断的病例。”如果文章没有提供真实变化，不要替作者补造结果，应建议补场景、数据或案例。
- 把总结词改成直接结论。 “这意味着医院的数字化进入新阶段”应改成“医院接下来要解决的不是采购软件，而是把数据接入、权限管理和责任分工一起定下来。”没有证据支撑时，删除“这意味着/由此可见”，保留事实。
- 控制同类句式密度。 同一段内出现两种以上抽象引导词，或全文“主要看/价值在于/关键在于”各出现多次，应合并判断并优先改写；不要把所有句子都改成“谁做什么”，要保留自然、有信息的正常表达。
改写优先级：删除无信息的引导词 > 补充具体主体和场景 > 把抽象名词换成动作和结果 > 用清单列出判断标准 > 必要时拆成事实句和结论句。不要用“核心是”“本质是”“真正的价值在于”等另一种抽象套话替换原句。
这类句式与对照式句子叠加时，按更高风险处理。例如“这不是简单的工具升级，价值主要在于重构流程”同时命中两类模板，应直接改写为具体的流程变化，而不是分别替换两个词。
4. 逐段诊断
如果文章有标题和段落，按段落或小标题定位问题。每条问题尽量包含：
- 位置：标题、开头、第 N 节、结尾，或引用短句
- 问题：具体哪里不行
- 原因：为什么影响阅读或信任
- 改法：怎么改
- 示例：给 1-2 句替代表达
不要只说“建议优化表达”。必须指出可操作动作，例如删除、前置、合并、补证据、换例子、改标题承诺。
5. 发布前建议
最后给出：
建议动作：可发布 / 小修后发布 / 大修后发布 / 暂不发布优先修改清单：最多 5 条，按影响排序最该重写的 3 个地方最值得保留的 3 个亮点
5.1 医疗AI情报精读发稿密度终审
如果文章属于“医疗AI情报精读”，以 2026-06-22 最终发稿版本作为编辑密度基线，额外检查：
| 检查项 | 通过标准 | 常见问题 |
|---|---|---|
| 可见字符 | 长报告约 6000-8000；素材不足可更短 | 用英文原文、译文和重复小结把文章撑到 1 万字以上 |
| 核心条目 | 每条保留关键事实、3 个判断、3 个行动建议、1-2 个强来源 | 一个条目反复解释同一个结论 |
| 引用密度 | 默认不用长引；全文证据引用原则上不超过 3 个 | 每条都贴英文长引和逐段译文，像研究备忘录 |
| 开头 | 阅读时间、封面、本期速览 3 条新观点 | 重复作者行、重复标题、本期一句话、产品清单、封面图注一起挤在开头 |
| 章节 | 医疗AI新产品 / 医疗AI新技术 / 医疗AI新模式 / 写在最后 / 参考信息来源 | “风险”和“给同行的问题”拆成两个过短章节 |
| 主线回扣 | 本期一句话 只在“写在最后”出现一次 |
开头说一次、中间总结一次、结尾再说一次 |
| 阅读时长 | 按最终可见正文重新估算，约 400 个中文可见字符/分钟，向上取整 | 删除半篇正文后仍沿用旧的预计阅读时间 |
| 来源精确性 | 核心条目来源必须是具体论文页、监管页、机构页、产品页或公告页 | 用 arXiv / Google / 微信 / 站内搜索页作为正文强来源 |
| 配图来源 | 正文首图、章节图和条目图必须是 image2/imagegen 产物并贴合本期主线；右下角“刘浩南”角标必须保持无框黑色手绘笔触 | 使用 SVG、canvas、PIL 脚本图、通用栏目封面、系统字体角标、印章/方框/贴纸式水印或与正文无关的装饰图 |
这部分属于内容终审：发现冗长时应明确指出删哪些模块，不要把删稿责任交给 haonan-wechat-article。排版器只能处理 HTML 结构与样式，不应擅自删除证据或观点。
6. haonan-wechat-article 交接检查
如果用户的下一步是公众号排版，必须检查草稿是否适合交给 haonan-wechat-article。只做审稿提醒，不调用、不修改 haonan-wechat-article。
重点检查：
| 检查项 | 通过标准 | 常见问题 |
|---|---|---|
| H1 标题 | 源稿应有且只有一个清晰 H1，用于公众号标题字段和本地归档；正文发布包可用 --wechat-body-only 不重复显示 H1 |
没有 H1、多个 H1、正文和公众号标题区重复显示标题 |
| H2 主章节 | H2 应代表真正的大模块，数量和顺序清晰 | H2 过多、H2 只是装饰句、正文没有模块感 |
| H3 小标题 | H3 应保留为故事/条目标题，能帮助读者扫描 | H3 与 H2 层级混乱、标题像提纲占位 |
| 开头提示 | 不需要手动加入 关注不迷路，加星标更聚焦 |
草稿里重复写了类似运营提示，可能和排版脚本重复 |
| 作者行 | 不需要手动加入 作者｜刘浩南；栏目终稿默认使用排版器的 --wechat-body-only，正文不重复标题和作者 |
源稿已有作者行，公众号标题区和尾部品牌块之外再次重复署名 |
| 摘要/总结卡 | Obsidian [!summary] callout 可被排版为卡片 |
摘要太长、callout 嵌套复杂、缺少核心判断 |
| 引用与原文引用 | 原文引用： 应短、准、可追溯 |
大段引用、没有来源、引用和正文边界不清 |
| 图片与图注 | 图片应有相对路径或明确占位，图注简短；生成图需说明 image2/imagegen 来源并检查角标 | 图片缺失、图注过长、图片说明混进正文、角标像系统字体或贴纸水印 |
| 重点高亮 | 应保留 5-10 句真正值得读者扫到的 Markdown 加粗判断句 | 完全没有加粗、只加粗术语不加粗观点、排版后加粗丢失 |
| 图注节奏 | 官网/README、GitHub 仓库页、Release/官方文档等关键来源图后应有简短 图注：；白板图和封面按需 |
关键来源图注缺失、图注太长、每张装饰图都硬写图注、图注像正文观点或被转成引用 |
| 表格强调 | 风险表和建议表可少量加粗关键结论 | 整表加粗、没有突出“不适合/先补数据治理”等关键建议 |
| 分割线 | 不建议用大量 --- 做装饰 |
横线过多会被排版流程移除或显得碎 |
| 参考资料/免责声明 | 医疗 AI、情报精读类文章建议保留来源与边界说明 | 缺来源、缺事实边界、缺免责声明 |
| 结尾品牌块 | 不需要手动写最终品牌卡文案 | 草稿里重复写品牌尾巴，后续排版会再追加 |
输出 排版准备度评分：
- 90-100：可直接进入
haonan-wechat-article - 80-89：小修结构或元信息后进入排版
- 70-79：需要先整理标题层级、引用、图片或来源
- 70 以下：不建议马上排版，先重构 Markdown
GitHub 热门医疗项目、医疗 AI 项目案例和工程解读类文章的额外排版准备要求：
- 正文不应展示候选筛选过程、候选排序表或陪跑项目点评；这些放入过程数据或发布备注。
- 标题和正文主线应落到一个具体工程特色，例如模块化设计、黑盒拆解、可复现链路、数据闭环、安全默认值，而不是泛泛写“很强”“很有价值”。
- 第 3/4 节应以文字讲清机制和工程分层，图片只辅助，不替代解释。
- 全文应保留 5-10 句加粗重点判断，覆盖开头主线、核心机制、工程价值、风险边界和结尾回扣。
- 关键来源图后应有简短
图注：，说明图片支撑哪条事实或主线；白板图和封面图按需添加，避免为装饰图硬写图注。 - 品牌尾部不得制造第二个 blockquote；如果栏目要求全文只有 1 个 blockquote，则只保留“本期一句话”为引用块，品牌文案用普通段落或品牌图承接。
- 英文简称和专业术语首次出现应有中文括号注释，例如 Dice（分割重叠度指标）、AUC（曲线下面积指标）、WSI（全切片病理图像）。
7. 生成最终完整报告
每次审稿的最终输出必须是一份完整报告，而不是零散评论。报告必须能独立阅读，用户不需要回看对话上下文也能理解：
- 这篇文章整体能不能发
- 分数为什么是这个水平
- AI感到底来自哪些句子、段落或结构
- 最大的 3-5 个问题是什么
- 应该先改哪里、怎么改
- 哪些亮点应该保留
- 发布前还需要做哪些检查
- 是否已经准备好交给
haonan-wechat-article
如果用户要求 quick，也要输出完整报告，只是报告更短。不要只输出表格或只输出一句结论。
Output Format
默认最终输出一份 Markdown 完整报告，使用以下结构。可以根据文章长度压缩细节，但不要删除“审稿结论”“多维度评分”“AI感检测”“主要问题”“发布前修改清单”这些核心部分。
# 公众号文章审稿完整报告
## 1. 审稿结论
- 综合评分：__/100
- AI感评分：__/100（等级：__）
- 排版准备度：__/100（是否适合交给 haonan-wechat-article：是/否/小修后可以）
- 发布建议：可发布 / 小修后发布 / 大修后发布 / 暂不发布
- 一句话判断：__
- 最优先要改的地方：__
## 2. 文章基本判断
- 文章类型：__
- 目标读者：__
- 文章目标：__
- 核心观点：__
- 标题承诺是否兑现：是/否/部分兑现
- 最大发布风险：__
## 3. 多维度评分
| 维度 | 分数 | 判断 |
|---|---:|---|
| 选题与读者价值 | __ | __ |
| 标题与开头 | __ | __ |
| 结构与节奏 | __ | __ |
| 逻辑与论证 | __ | __ |
| 证据与可信度 | __ | __ |
| 表达与公众号语感 | __ | __ |
| AI感与原创感 | __ | __ |
| 发布风险 | __ | __ |
## 4. AI感检测
| AI感信号 | 严重度 | 位置/表现 | 修改方向 |
|---|---|---|---|
| __ | 高/中/低 | __ | __ |
### AI句式专项结果
- 命中数量：__ 条（全文扫描范围：__）
- 命中类型：对照式 / 判断标准式 / 价值归纳式 / 抽象总结式 / 混合
- 风险判断：自然表达 / 局部可疑 / 明显模板化
- 最高风险位置：__
| 原句 | 命中句式 | 判断 | 建议改写 |
|---|---|---|---|
| __ | __ | 保留 / 改写 / 删除套话 | __ |
如果没有明显命中，写明“未发现明显 AI 模板句”，不要虚构问题。
### AI感来源总结
1. __
2. __
3. __
## 5. 主要问题
1. __
2. __
3. __
## 6. 逐段诊断与修改建议
| 位置 | 问题 | 为什么影响阅读 | 建议改法 |
|---|---|---|---|
| __ | __ | __ | __ |
## 7. 可直接替换的句子
> 原句：__
建议：__
## 8. haonan-wechat-article 排版交接检查
| 检查项 | 结果 | 问题/建议 |
|---|---|---|
| H1 标题 | 通过/需修改 | __ |
| H2/H3 层级 | 通过/需修改 | __ |
| 作者行与开头提示 | 通过/需修改 | __ |
| 摘要/引用/来源 | 通过/需修改 | __ |
| 图片与图注 | 通过/需修改/不适用 | __ |
| 生成图与角标 | 通过/需修改/不适用 | 是否为 image2/imagegen 产物；是否存在 SVG/canvas/PIL/HTML截图伪图；右下角“刘浩南”是否为无框黑色手绘笔触，不能有系统字体感、印章感、方框底或水印贴纸感 |
| 重点加粗 | 通过/需修改/不适用 | __ |
| 术语注释 | 通过/需修改/不适用 | __ |
| 表格强调 | 通过/需修改/不适用 | __ |
| 分割线与装饰元素 | 通过/需修改 | __ |
| 结尾品牌块 | 通过/需修改 | __ |
交接建议：可直接排版 / 小修后排版 / 先重构 Markdown
## 9. 保留亮点
1. __
2. __
3. __
## 10. 发布前修改清单
1. __
2. __
3. __
## 11. 最终建议
__
Review Modes
quick
用于快速判断能不能发。仍然输出一份完整报告，但压缩为：审稿结论、多维评分、AI感检测、排版准备度、前三个修改建议、最终建议。
deep
默认模式。输出完整审稿报告、逐段建议、替换句、haonan-wechat-article 交接检查和发布前清单。
final
用于发布前终审。重点检查错别字、事实边界、标题兑现、AI残留、敏感风险、Markdown 层级、排版交接风险、生成图来源、右下角“刘浩南”手绘角标和最终发布建议。
Style Preferences
- 审稿要直说，但不要刻薄。
- 先讲最影响发布的问题，再讲细节。
- 对公众号文章，优先追求：清楚、有判断、有细节、有节奏、有信任感。
- 不鼓励把文章改得过度口语化；口语化必须服务于清晰和可信。
- 对“AI感”的判断要具体到句子、段落和结构，不要停留在泛泛感受。
- 对排版交接问题，只指出源稿需要怎么改；不要调用、修改或复述
haonan-wechat-article的实现代码。
医院科室 AI 现状终审增补（2026-07 已发表样稿）
审阅“医院科室 AI 现状精读”时，除了常规评分，还必须判定结构类型是否匹配：
- 平台型科室是否按平台成章，并且每个平台都有“真实工作流、AI落点分析、科室建议、代表企业案例”。缺任一项，应判为结构未收口。
- 产品型科室是否保留产品逐个拆解和 H3 “产品名：一句定位”。如果只有平台总论、没有产品证据，应判为采购参考不足。
- 平台型长稿允许约 1 万字、30+ 图和 4 张宽表；不要仅因超过 7500 字扣分。扣分依据应是重复、空话、证据不足或移动端难读，而不是字数本身。
- 检查所有流程时长是否为真实世界区间表达，是否说明影响因素；凡出现无来源的精确分钟数、百分比或“必然缩短多少”，应标为事实风险。
- 检查代表企业案例是否有官网/产品入口和产品介绍；官网不稳定时是否写明边界。
- 检查结尾是否只有一个 blockquote“本期一句话”；品牌尾部不得成为第二个引用块。
- 检查复杂平台型科室是否有未来业务架构图和技术架构图；如果只有泛泛愿景图，要求补图或降级为文字展望。
- 检查所有生成白板图、封面图和解释图是否为 image2/imagegen 产物，且右下角“刘浩南”角标保持手绘笔触；发现系统字体、PIL/SVG/Canvas/HTML 截图补字、印章感、方框底或贴纸水印感，应判为终审不通过，要求重生或使用 image2/imagegen 手绘签名贴片修复后再审。