优化(命令): 基于研究方法论重构文章摘要命令，简化知识库列表格式

- 新增"价值判断"步骤，按创新性/可迁移性/论据质量/边界意识四维度评估文章，分档处理
- 新增"批判性阅读"步骤，加入三个核心追问和知识分类（共识/争议/未探索/范式突破）
- 新增"草稿先行"步骤，在正式输出前用草稿理清逻辑
- 新增"自我批判检查点"，输出前用五个问题自查
- 增强复盘流程，记录执行变量和反常识发现
- 简化金鹏 2026-06-26 文章列表格式，移除冗余内容

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

@@ -3,6 +3,15 @@ name: 文章摘要
 description: 读取指定文章的 markdown 内容或链接，编写介绍和要点说明，格式与 知识/金鹏.md 中的文章列表一致
 ---
 
+## 核心原则（来自《How to be good at research》方法论）
+
+执行本命令时，始终遵循以下研究级质量标准：
+
+1. **区分信息与洞见**：不被动收纳信息，批判性阅读——追问作者的假设、论据、边界
+2. **区分工具与目标**：摘要的目标是"提炼可迁移的认知增量"，不是"罗列文章内容"
+3. **忠实原文**：不注入自己的观点，不选择性筛选结论迎合预设判断
+4. **延迟满足**：宁愿花时间写一个能串联多篇文章的深度摘要，不追求快速产出浅层概括
+
 ## 用户输入
 
 ```text
@@ -22,24 +31,83 @@ $ARGUMENTS
 - **本地文件**：使用 `Read` 工具读取
 - **GitHub 仓库**：使用 `mcp__zread__get_repo_structure` 了解项目结构
 
-### 2. 分析文章
+### 2. 价值判断（选题能力）
 
-提取：标题和链接、来源/作者、核心论点、关键要点（3-8个）、可引用金句。
+在深入分析之前，快速评估文章的认知价值，这决定后续处理的深度：
 
-### 3. 提取核心观点并构建体系
+| 判断维度 | 追问 | 高价值信号 | 低价值信号 |
+|----------|------|-----------|-----------|
+| 创新性 | 这篇文章提供了什么"不知道的东西"？ | 挑战现有共识、提出新框架、解释反常现象 | 汇总已知信息、无独立观点 |
+| 可迁移性 | 结论能否跨场景复用？ | 提炼出可操作的方法论或思维模型 | 纯案例堆砌、无抽象提炼 |
+| 论据质量 | 作者的证据能否支撑结论？ | 有实验数据、工程验证、一手经验 | 纯观点输出、无实证支撑 |
+| 边界意识 | 作者是否说明了结论的适用范围？ | 明确指出局限性和前提假设 | 绝对化断言、无边界说明 |
+
+- **高价值文章**（2 项以上高价值信号）→ 按体系内文章组处理，深度批判性阅读
+- **中等价值文章**（1 项高价值信号）→ 按独立文章处理，标准分析
+- **低价值文章**（无高价值信号）→ 简短摘要，不生成配图，不进入体系
+
+### 3. 批判性阅读（文献阅读能力）
+
+对文章进行深度分析，**不只是提取信息，而是追问**：
+
+#### 3a. 三个核心追问
+
+1. **作者的假设前提是什么？**——这篇文章建立在哪些未经证明的前提之上？如果前提不成立，结论是否仍然有效？
+2. **论据是否支撑结论？**——作者提供的证据链条是否完整？是否存在逻辑跳跃或选择性举证？
+3. **该研究的边界和缺陷在哪里？**——结论的适用范围是什么？作者是否明确指出了局限性？哪些场景下结论可能失效？
+
+#### 3b. 知识分类
+
+将文章观点归类到以下维度之一：
+
+| 类别 | 定义 | 摘要中的标记方式 |
+|------|------|-----------------|
+| **共识** | 业界已形成广泛认同的观点 | 用"业界共识"等表述说明 |
+| **争议** | 存在不同声音、尚无定论的方向 | 在要点中保留对立观点 |
+| **未探索方向** | 作者指出的空白或待解决问题 | 在要点末尾注明，作为后续关注线索 |
+| **范式突破** | 挑战现有框架的新思路 | 用**粗体**突出，作为核心命题优先考虑 |
+
+#### 3c. 提取关键要素
+
+在完成批判性追问和知识分类后，提取：标题和链接、来源/作者、核心论点、关键要点（3-8 个）、可引用金句。
+
+### 4. 草稿先行（学术写作能力）
+
+**写作不是收尾工作，而是梳理思路的工具。** 在编写正式摘要之前，先用 3-5 句话写一个"草稿摘要"：
+
+- 这篇文章**真正想说什么**？（一句话核心命题）
+- 它**为什么重要**？（跟现有认知有什么不同）
+- 它**跟已有文章有什么关系**？（呼应、补充还是挑战？）
+- 它**的局限是什么**？（什么场景下不适用）
+
+这个草稿**不进入最终输出**，目的是强迫自己在写正式摘要前理清逻辑。如果草稿写不清楚，说明对文章的理解还不够深——回到第 3 步重新阅读。
+
+### 5. 提取核心观点并构建体系
 
 **最关键的一步**，在编写具体内容之前完成：
 
-1. **提取核心命题**：通读全部文章，提炼一个能串联所有关联文章的核心命题，2-4 字（如"驾驭AI"）
+1. **提取核心命题**：基于批判性阅读和草稿的梳理，提炼一个能串联所有关联文章的核心命题，2-6 字（如"驾驭AI""智能体工程化"）。核心命题不应只是主题标签，而应体现文章的**独特认知贡献**
 2. **划分层级**：将关联文章按递进逻辑分层——总纲→实践层（团队/流程/产品）→战略层（组织）→根基层（文明/哲学），每层一个 2-3 字标签
 3. **排序**：体系内按层级递进排列，独立工具/项目放在最后
-4. **确定父条目**：为核心命题创建一个父条目——标题用核心命题，链接用首篇文章URL，配一张代表图片和一句金句标签
+4. **确定父条目**：为核心命题创建一个父条目——标题用核心命题，链接用首篇文章 URL，配一张代表图片和一句金句标签
 
-### 4. 生成文章配图
+### 6. 自我批判检查点（学术沟通能力）
+
+在编写最终输出之前，用以下问题自查：
+
+- **核心命题是否精准？** 是否只是换了个说法重复文章标题，还是真正抓住了文章的独特认知贡献？
+- **关联是否真实？** 文章之间的"呼应""补充"关系是真实存在的，还是为了凑体系生造的联系？
+- **是否有偷换概念？** 是否把工具/技术细节当成了核心认知贡献？（区分工具与目标）
+- **金句是否可引用？** 加粗的句子如果单独拿出来，是否仍然有意义、有冲击力？
+- **遗漏了什么？** 文章中最反常识、最容易被忽略的细节是否被覆盖了？
+
+如果任何一项自查不通过，回到第 4 或第 5 步修正。
+
+### 7. 生成文章配图
 
 摘要编写完成后，**必须**调用即梦 AI（Dreamina）为父条目或独立文章生成配图。
 
-#### 4a. 构建生成提示词
+#### 7a. 构建生成提示词
 
 从文章分析结果中提取以下元素构建文生图提示词：
 
@@ -58,7 +126,7 @@ $ARGUMENTS
 一张关于"{核心命题}"的主题配图，{关键概念转化成的视觉元素}。{风格要求}。适合作为技术文章的题图，简洁有力。
 ```
 
-#### 4b. 调用即梦生成
+#### 7b. 调用即梦生成
 
 使用 `Skill` 工具调用 `arno-dreamina` 技能，传入提示词和下载路径：
 
@@ -67,16 +135,16 @@ Skill: arno-dreamina
 Args: 生成一张16:9横版文章配图，提示词：{构建的提示词}。下载到 知识/金鹏/{YYYYMMDD}/{YYYYMMDD}-{NNN}.png
 ```
 
-#### 4c. 确认配图与占位一致
+#### 7c. 确认配图与占位一致
 
 下载完成后确认：
 - 图片本地路径与摘要中 `![-](./金鹏/YYYYMMDD/YYYYMMDD-NNN.png)` 占位一致
 - 日期与文章日期匹配
 - 父条目配图用 `-001`，子文章按序编号
 
-### 5. 输出格式
+### 8. 输出格式
 
-#### 5a. 体系内文章组（有关联的文章，用父条目分组）
+#### 8a. 体系内文章组（有关联的文章，用父条目分组）
 
 ```markdown
 - [核心命题](首篇文章URL)
@@ -102,7 +170,7 @@ Args: 生成一张16:9横版文章配图，提示词：{构建的提示词}。
 - 总纲的定位描述放在来源之前（因为它是全组的总起），其他子文章的定位描述放在来源之后
 - 定位描述承上启下，用关联词串联上下文
 
-#### 5b. 独立文章（不属任何体系的工具项目或单篇文章）
+#### 8b. 独立文章（不属任何体系的工具项目或单篇文章）
 
 ```markdown
 - [文章标题](URL)
@@ -120,38 +188,49 @@ Args: 生成一张16:9横版文章配图，提示词：{构建的提示词}。
 | 类型 | 格式 | 示例 |
 |------|------|------|
 | 父条目 | 核心命题，2-6 字 | `驾驭AI` |
-| 体系内子文章 | `动作名词：具体内容`，≤20字 | `角色分工：gstack 的虚拟工程团队` |
+| 体系内子文章 | `动作名词：具体内容`，≤20 字 | `角色分工：gstack 的虚拟工程团队` |
 | 独立文章 | 简洁直白，≤15 字 | `实时数字人` |
 
 ### 描述编写
 
-1. **粗体**用于：核心命题、关键洞察、金句、颠覆性结论
+1. **粗体**用于：核心命题、关键洞察、金句、颠覆性结论、范式突破
 2. 每条要点控制在 1-2 行
-3. 忠实原文观点
-4. 子文章定位描述必须说明该文在体系中的位置，并与前文建立关联
+3. 忠实原文观点，区分"作者的结论"和"我们的推断"
+4. 子文章定位描述必须说明该文在体系中的位置，并与前文建立**真实的**关联（不为了体系完整而生造联系）
+5. 对"争议"类观点保留对立声音，不一边倒呈现
 
 ### 注意事项
 
 - 图片占位 `![-](./金鹏/YYYYMMDD/YYYYMMDD-NNN.png)`，日期与文章日期一致
 - 多个相关链接（GitHub、官网等）用缩进放在描述最后
 
-## 执行后复盘
+## 执行后复盘（标准化复盘流程）
 
-每次执行本命令后，必须完成以下步骤：
+每次执行本命令后，必须按以下结构化流程复盘。参照"实验迭代能力"的标准化原则——无论成功还是失败，都固定记录核心变量。
 
-### 1. 分析执行过程
+### 1. 记录执行变量
+
+| 变量 | 说明 |
+|------|------|
+| 输入类型 | URL / 本地文件 / 粘贴内容 / GitHub 仓库 |
+| 价值判断 | 高 / 中 / 低，判断依据 |
+| 文章数量 | 单篇 / 多篇关联 / 独立 |
+| 是否形成体系 | 是 / 否，原因 |
+
+### 2. 分析执行过程
 
 分析本次执行过程的优点和缺点：
 
 - **优点**：哪些步骤/设计执行顺畅、达到预期效果？
 - **缺点**：哪些步骤/设计存在问题或可改进之处？
+- **反常识发现**：执行中是否有预期之外的情况？例如预期能形成体系的文章实际关联薄弱，或被判断为低价值的文章实际有意外亮点？
 
-### 2. 评估是否需要更新命令
+### 3. 评估是否需要更新命令
 
 基于上述分析，判断当前命令是否需要更新。如果执行顺利无问题，注明"当前命令无需更新"。
 
-### 3. 如需更新，提出建议并由人类确认
+### 4. 如需更新，提出建议并由人类确认
 
 如果发现需要改进的地方，给出具体的更新方案（修改内容、位置、原因），由人类用户确认后再执行对命令文件的修改。
 
-> **原则**：可改可不改的不改；只提出对执行质量有实质影响的更新建议。
+> **原则**：可改可不改的不改；只提出对执行质量有实质影响的更新建议。