tech/.claude/commands/arno-article-summary.md

name, description

name	description
文章摘要	读取指定文章的 markdown 内容或链接，编写介绍和要点说明，格式与 知识/金鹏.md 中的文章列表一致

核心原则（来自《How to be good at research》方法论）

执行本命令时，始终遵循以下研究级质量标准：

1. 区分信息与洞见：不被动收纳信息，批判性阅读——追问作者的假设、论据、边界
2. 区分工具与目标：摘要的目标是"提炼可迁移的认知增量"，不是"罗列文章内容"
3. 忠实原文：不注入自己的观点，不选择性筛选结论迎合预设判断
4. 延迟满足：宁愿花时间写一个能串联多篇文章的深度摘要，不追求快速产出浅层概括

用户输入

$ARGUMENTS

用户可以提供：

• 文章 URL（支持微信公众号、知乎、GitHub 等）
• 本地 markdown 文件路径
• 或直接粘贴的文章内容

执行流程

1. 读取文章内容

• URL：使用 mcp__web-reader__webReader 或 WebFetch 获取文章内容
• 本地文件：使用 Read 工具读取
• GitHub 仓库：使用 mcp__zread__get_repo_structure 了解项目结构

2. 价值判断（选题能力）

在深入分析之前，快速评估文章的认知价值，这决定后续处理的深度：

判断维度	追问	高价值信号	低价值信号
创新性	这篇文章提供了什么"不知道的东西"？	挑战现有共识、提出新框架、解释反常现象	汇总已知信息、无独立观点
可迁移性	结论能否跨场景复用？	提炼出可操作的方法论或思维模型	纯案例堆砌、无抽象提炼
论据质量	作者的证据能否支撑结论？	有实验数据、工程验证、一手经验	纯观点输出、无实证支撑
边界意识	作者是否说明了结论的适用范围？	明确指出局限性和前提假设	绝对化断言、无边界说明

• 高价值文章（2 项以上高价值信号）→ 按体系内文章组处理，深度批判性阅读
• 中等价值文章（1 项高价值信号）→ 按独立文章处理，标准分析
• 低价值文章（无高价值信号）→ 简短摘要，不生成配图，不进入体系

3. 批判性阅读（文献阅读能力）

对文章进行深度分析，不只是提取信息，而是追问：

3a. 三个核心追问

1. 作者的假设前提是什么？——这篇文章建立在哪些未经证明的前提之上？如果前提不成立，结论是否仍然有效？
2. 论据是否支撑结论？——作者提供的证据链条是否完整？是否存在逻辑跳跃或选择性举证？
3. 该研究的边界和缺陷在哪里？——结论的适用范围是什么？作者是否明确指出了局限性？哪些场景下结论可能失效？

3b. 知识分类

将文章观点归类到以下维度之一：

类别	定义	摘要中的标记方式
共识	业界已形成广泛认同的观点	用"业界共识"等表述说明
争议	存在不同声音、尚无定论的方向	在要点中保留对立观点
未探索方向	作者指出的空白或待解决问题	在要点末尾注明，作为后续关注线索
范式突破	挑战现有框架的新思路	用粗体突出，作为核心命题优先考虑

3c. 提取关键要素

在完成批判性追问和知识分类后，提取：标题和链接、来源/作者、核心论点、关键要点（3-8 个）、可引用金句。

4. 草稿先行（学术写作能力）

写作不是收尾工作，而是梳理思路的工具。 在编写正式摘要之前，先用 3-5 句话写一个"草稿摘要"：

• 这篇文章真正想说什么？（一句话核心命题）
• 它为什么重要？（跟现有认知有什么不同）
• 它跟已有文章有什么关系？（呼应、补充还是挑战？）
• 它的局限是什么？（什么场景下不适用）

这个草稿不进入最终输出，目的是强迫自己在写正式摘要前理清逻辑。如果草稿写不清楚，说明对文章的理解还不够深——回到第 3 步重新阅读。

5. 提取核心观点并构建体系

最关键的一步，在编写具体内容之前完成：

1. 提取核心命题：基于批判性阅读和草稿的梳理，提炼一个能串联所有关联文章的核心命题，2-6 字（如"驾驭AI""智能体工程化"）。核心命题不应只是主题标签，而应体现文章的独特认知贡献
2. 划分层级：将关联文章按递进逻辑分层——总纲→实践层（团队/流程/产品）→战略层（组织）→根基层（文明/哲学），每层一个 2-3 字标签
3. 排序：体系内按层级递进排列，独立工具/项目放在最后
4. 确定父条目：为核心命题创建一个父条目——标题用核心命题，链接用首篇文章 URL，配一张代表图片和一句金句标签

6. 自我批判检查点（学术沟通能力）

在编写最终输出之前，用以下问题自查：

• 核心命题是否精准？ 是否只是换了个说法重复文章标题，还是真正抓住了文章的独特认知贡献？
• 关联是否真实？ 文章之间的"呼应""补充"关系是真实存在的，还是为了凑体系生造的联系？
• 是否有偷换概念？ 是否把工具/技术细节当成了核心认知贡献？（区分工具与目标）
• 金句是否可引用？ 加粗的句子如果单独拿出来，是否仍然有意义、有冲击力？
• 遗漏了什么？ 文章中最反常识、最容易被忽略的细节是否被覆盖了？

如果任何一项自查不通过，回到第 4 或第 5 步修正。

7. 生成文章配图

摘要编写完成后，必须调用即梦 AI（Dreamina）为父条目或独立文章生成配图。

7a. 构建生成提示词

从文章分析结果中提取以下元素构建文生图提示词：

• 核心命题（2-6 字）作为画面主题
• 关键要点（3-5 个核心概念）转化为视觉元素
• 文章调性决定视觉风格：

文章类型	风格建议
AI/技术类	深蓝科技色调，光晕效果，扁平化商务风
商业/战略类	暖色商务色调，简约现代，数据可视化元素
人文/哲学类	柔和暖色调，抽象意境，留白设计

提示词模板（16:9 横版，适合文章题图）：

一张关于"{核心命题}"的主题配图，{关键概念转化成的视觉元素}。{风格要求}。适合作为技术文章的题图，简洁有力。

生成两张图：一张 16:9 横版题图（大图），一张 160×90 列表缩略图（小图）。

7b. 调用即梦生成大图

使用 Skill 工具调用 arno-dreamina 技能，传入提示词和下载路径：

Skill: arno-dreamina
Args: 生成一张16:9横版文章配图，提示词：{构建的提示词}。下载到 知识/金鹏/{YYYYMMDD}/{YYYYMMDD}-{NNN}.png

7c. 确认大图与占位一致

下载完成后确认：

• 图片本地路径与摘要中 ![-](./金鹏/YYYYMMDD/YYYYMMDD-NNN.png) 占位一致
• 日期与文章日期匹配
• 父条目配图用 -001，子文章按序编号

7d. 生成列表缩略图（160×90）

从大图裁切生成 160×90 像素的列表缩略图，用于在文章列表中展示。

convert "<大图路径>" -resize 160x90^ -gravity center -extent 160x90 "<同目录>/<YYYYMMDD>-<NNN>-thumb.png"

参数说明：

• -resize 160x90^：按 160×90 等比缩放，^ 确保填满目标尺寸
• -gravity center -extent 160x90：居中裁切到精确 160×90
• 输出文件命名：大图 YYYYMMDD-NNN.png → 缩略图 YYYYMMDD-NNN-thumb.png

确认 convert（ImageMagick）可用；若不可用则改用 ffmpeg：

ffmpeg -i "<大图路径>" -vf "scale=160:90:force_original_aspect_ratio=increase,crop=160:90" "<缩略图路径>" -y

8. 输出格式

8a. 体系内文章组（有关联的文章，用父条目分组）

- [核心命题](首篇文章URL)
- ![-](./金鹏/YYYYMMDD/YYYYMMDD-NNN-thumb.png)
- ![-](./金鹏/YYYYMMDD/YYYYMMDD-NNN.png)
- 金句标签（核心命题的精髓表达，一句话）
    - 层级标签： [文章标题](子文章URL)
        - 定位描述——用一句话说明本文在体系中的位置，**粗体**突出关键词
        - 来源名称
        - 具体要点一
        - 具体要点二
        - **关键洞察或金句（加粗）**
    - 层级标签： [下一个文章标题](URL)
        - 来源名称
        - 定位描述——承上启下，用"这与XX呼应""与XX一样"等词语串联
        - 具体要点...

规则：

• 父条目缩进 0，子文章标题行缩进 4 空格，子文章内容缩进 8 空格
• 层级标签在子文章标题前面：层级标签： [文章标题](URL)，如 总纲： [驾驭AI：...](url)、团队层： [角色分工：...](url)
• 子文章标题：动作名词：具体内容，不超过 20 字
• 来源行只写平台/作者名（如 腾讯云、极客鑫），不在此处加层级标签
• 总纲的定位描述放在来源之前（因为它是全组的总起），其他子文章的定位描述放在来源之后
• 定位描述承上启下，用关联词串联上下文

8b. 独立文章（不属任何体系的工具项目或单篇文章）

- [文章标题](URL)
    - ![-](./金鹏/YYYYMMDD/YYYYMMDD-NNN-thumb.png)
    - 来源名称
    - 一句话核心摘要
    - 补充要点

规则：

• 缩进 4 空格，不加层级标签
• GitHub 项目：简要说明用途、技术亮点

标题命名

类型	格式	示例
父条目	核心命题，2-6 字	驾驭AI
体系内子文章	动作名词：具体内容，≤20 字	角色分工：gstack 的虚拟工程团队
独立文章	简洁直白，≤15 字	实时数字人

描述编写

1. 粗体用于：核心命题、关键洞察、金句、颠覆性结论、范式突破
2. 每条要点控制在 1-2 行
3. 忠实原文观点，区分"作者的结论"和"我们的推断"
4. 子文章定位描述必须说明该文在体系中的位置，并与前文建立真实的关联（不为了体系完整而生造联系）
5. 对"争议"类观点保留对立声音，不一边倒呈现

注意事项

• 大图占位 ![-](./金鹏/YYYYMMDD/YYYYMMDD-NNN.png)，缩略图占位 ![-](./金鹏/YYYYMMDD/YYYYMMDD-NNN-thumb.png)，日期与文章日期一致
• 缩略图 160×90 像素，由大图通过 ImageMagick 裁切生成
• 父条目和独立文章均需生成大图 + 缩略图；体系内子文章不单独生成配图
• 多个相关链接（GitHub、官网等）用缩进放在描述最后

执行后复盘（标准化复盘流程）

每次执行本命令后，必须按以下结构化流程复盘。参照"实验迭代能力"的标准化原则——无论成功还是失败，都固定记录核心变量。

1. 记录执行变量

变量	说明
输入类型	URL / 本地文件 / 粘贴内容 / GitHub 仓库
价值判断	高 / 中 / 低，判断依据
文章数量	单篇 / 多篇关联 / 独立
是否形成体系	是 / 否，原因

2. 分析执行过程

分析本次执行过程的优点和缺点：

• 优点：哪些步骤/设计执行顺畅、达到预期效果？
• 缺点：哪些步骤/设计存在问题或可改进之处？
• 反常识发现：执行中是否有预期之外的情况？例如预期能形成体系的文章实际关联薄弱，或被判断为低价值的文章实际有意外亮点？

3. 评估是否需要更新命令

基于上述分析，判断当前命令是否需要更新。如果执行顺利无问题，注明"当前命令无需更新"。

4. 如需更新，提出建议并由人类确认

如果发现需要改进的地方，给出具体的更新方案（修改内容、位置、原因），由人类用户确认后再执行对命令文件的修改。

原则：可改可不改的不改；只提出对执行质量有实质影响的更新建议。