diff --git a/.claude/commands/arno-anl-article.md b/.claude/commands/arno-anl-article.md deleted file mode 100644 index 73a2037..0000000 --- a/.claude/commands/arno-anl-article.md +++ /dev/null @@ -1,182 +0,0 @@ ---- -name: arno-anl-article -description: 对单篇文章进行批判性阅读，提取事实与观点，输出结构化分析报告。在工作管理项目中，可用于深度理解行业动态、技术文章、政策法规等参考材料。触发词：分析文章、文章分析、深度阅读、提取观点、文章总结、批判性阅读。 -argument-hint: <文章文件路径> ---- - -## 用户输入 - -```text -$ARGUMENTS -``` - -用户输入为**单篇**本地 Markdown 文件的路径（绝对路径）。 - -## 概述 - -对单篇文章进行批判性阅读和结构化分析，提取事实与观点，给出独立评价，输出独立的 `_分析.md` 文件。本技能聚焦于"提炼可迁移的认知增量"，而非罗列文章内容。 - -方法论参照 Vivek Nair《How to be good at research》中"文献阅读能力"框架： -> 读书不要摘抄结论，核心拷问三个问题：作者的假设是什么？证据能否支撑结论？这个研究的边界和缺陷在哪里。 - -## 执行流程 - -### 第一步：读取文章 - -使用 Read 工具读取目标文章全文内容。 - -### 第二步：价值判断 - -快速评估文章的认知价值，决定分析深度： - -| 判断维度 | 追问 | 高价值信号 | -|----------|------|-----------| -| 创新性 | 提供了什么"不知道的东西"？ | 挑战共识、提出新框架、解释反常 | -| 可迁移性 | 结论能否跨场景复用？ | 可操作的方法论或思维模型 | -| 论据质量 | 证据能否支撑结论？ | 实验数据、工程验证、一手经验 | -| 边界意识 | 是否说明适用范围？ | 明确指出局限性和前提假设 | - -- **高价值**（≥2 项高价值信号）→ 深度分析，完整输出 -- **中等价值**（1 项）→ 标准分析 -- **低价值**（0 项）→ 简要摘要，仍产出分析文件但篇幅精简 - -### 第三步：批判性阅读 - -对文章内容进行三个核心追问： - -1. **作者的假设前提是什么？** —— 建立在哪些未经证明的前提之上？如果前提不成立，结论是否仍有效？ -2. **论据是否支撑结论？** —— 证据链条是否完整？是否存在逻辑跳跃或选择性举证？ -3. **该研究的边界和缺陷在哪里？** —— 结论的适用范围是什么？哪些场景下结论可能失效？ - -### 第四步：知识分类 - -将文章观点归类： - -| 类别 | 定义 | 输出标记 | -|------|------|---------| -| **共识** | 业界广泛认同的观点 | 标注"业界共识" | -| **争议** | 存在不同声音的方向 | 保留对立观点 | -| **未探索** | 作者指出的空白 | 标注为后续关注线索 | -| **范式突破** | 挑战现有框架的新思路 | **粗体突出** | - -### 第五步：提取事实与观点 - -从文章中分离： - -- **事实**：可验证的数据、事件、案例、实验结果 -- **观点**：作者的判断、推论、建议、预测 -- **金句**：可直接引用的精炼表达（2-5 句） - -### 第六步：生成分析报告 - -分析报告保存为独立 Markdown 文件。 - -**文件名**：`<原文文件名（不含.md）>_分析.md`，保存在原文同一目录。 - -**模板**： - -```markdown -# 📊 文章分析：<文章标题> - -> **原文**：<原文文件名> -> **分析日期**： - ---- - -## 一、文章概要 - -| 属性 | 内容 | -|------|------| -| 标题 | <文章标题> | -| 来源 | <公众号名称> | -| 作者 | <作者名> | -| 发布日期 | | -| 价值评级 | ⭐⭐⭐ 高 / ⭐⭐ 中 / ⭐ 低 | - -**一句话概要**：<用一句话概括文章真正想说什么> - ---- - -## 二、事实提取 - -从文章中提取的可验证信息： - -1. <事实 1> -2. <事实 2> -3. ... - -> 如无可验证事实，标注"本文以观点输出为主，无可独立验证的事实陈述"。 - ---- - -## 三、观点提取 - -作者的核心论断和判断： - -1. **<观点 1>** — <简要说明> -2. **<观点 2>** — <简要说明> -3. ... - ---- - -## 四、批判性分析 - -### 4.1 作者假设前提 - -<作者立论建立在哪些假设之上？> - -### 4.2 论据与逻辑 - -<证据是否支撑结论？逻辑链条是否完整？> - -### 4.3 边界与局限 - -<结论适用范围？哪些场景不适用？作者是否明确指出？> - ---- - -## 五、知识分类 - -| 观点 | 分类 | 说明 | -|------|------|------| -| <观点简述> | 共识 / 争议 / 未探索 / **范式突破** | <分类理由> | - ---- - -## 六、可引用金句 - -> "<金句 1>" - -> "<金句 2>" - ---- - -## 七、总体评价 - -**亮点**： -- <优点 1> -- <优点 2> - -**不足**： -- <不足 1> - -**适用场景**：<结论适用于什么场景、什么人群> - -**关联建议**：<可进一步阅读的方向或文章> -``` - -### 模板规则 - -1. 每个章节必须填写，不可省略 -2. 低价值文章可精简"批判性分析"和"知识分类"章节 -3. 观点提取必须忠实原文，区分"作者的结论"和"分析者的推断" -4. 金句必须来自原文，不可改写 -5. 文件名中如有特殊字符，沿用原文的文件名安全规则（`_` 替换） - -## 关键指令 - -1. **忠实原文**：不注入自己的观点，不选择性筛选结论 -2. **区分事实与观点**：事实可验证，观点是判断 -3. **批判性阅读**：不止于摘抄，追问假设、证据、边界 -4. **独立输出**：分析报告保存为独立的 `_分析.md` 文件，不修改原文 -5. **简洁有力**：每条要点控制在 1-3 行，金句直接引用 diff --git a/.claude/commands/arno-article-summary.md b/.claude/commands/arno-article-summary.md deleted file mode 100644 index f364852..0000000 --- a/.claude/commands/arno-article-summary.md +++ /dev/null @@ -1,286 +0,0 @@ ---- -name: 文章摘要 -description: 读取指定文章的 markdown 内容或链接，编写介绍和要点说明，格式与 知识/金鹏.md 中的文章列表一致 ---- - -## 核心原则（来自《How to be good at research》方法论） - -执行本命令时，始终遵循以下研究级质量标准： - -1. **区分信息与洞见**：不被动收纳信息，批判性阅读——追问作者的假设、论据、边界 -2. **区分工具与目标**：摘要的目标是"提炼可迁移的认知增量"，不是"罗列文章内容" -3. **忠实原文**：不注入自己的观点，不选择性筛选结论迎合预设判断 -4. **延迟满足**：宁愿花时间写一个能串联多篇文章的深度摘要，不追求快速产出浅层概括 - -## 用户输入 - -```text -$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）为父条目或独立文章生成配图。 - -**两图体系**： - -| 图片 | 尺寸 | 用途 | 文件命名 | 在摘要中的位置 | -|------|------|------|---------|---------------| -| **文章题图** | 16:9 横版 ≥2K，显示宽度 ≤1000px | 文章详情页展开查看 | `YYYYMMDD-NNN.png` | 第二行（金句标签上方） | -| **列表标题图** | 160×90 像素 | 文章列表中作为条目缩略图展示 | `YYYYMMDD-NNN-thumb.png` | 第一行（紧接标题链接之后） | - -列表标题图由大图裁切生成（不单独调用即梦），确保两图视觉一致。 - -#### 7a. 构建生成提示词 - -从文章分析结果中提取以下元素构建文生图提示词： - -- **核心命题**（2-6 字）作为画面主题 -- **关键要点**（3-5 个核心概念）转化为视觉元素 -- **文章调性**决定视觉风格： - -| 文章类型 | 风格建议 | -|---------|---------| -| AI/技术类 | 深蓝科技色调，光晕效果，扁平化商务风 | -| 商业/战略类 | 暖色商务色调，简约现代，数据可视化元素 | -| 人文/哲学类 | 柔和暖色调，抽象意境，留白设计 | - -提示词模板（16:9 横版，适合文章题图）： -``` -一张关于"{核心命题}"的主题配图，{关键概念转化成的视觉元素}。{风格要求}。适合作为技术文章的题图，简洁有力。 -``` - -> 只需生成一张 16:9 大图，160×90 列表标题图在步骤 7d 从大图裁切得到。 - -#### 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 像素的**列表标题图**，用于在文章列表中展示。 - -```bash -convert "<大图路径>" -resize 160x90^ -gravity center -extent 160x90 "<同目录>/--thumb.png" -``` - -参数说明： -- `-resize 160x90^`：按 160×90 等比缩放，`^` 确保填满目标尺寸 -- `-gravity center -extent 160x90`：居中裁切到精确 160×90 -- 输出文件命名：大图 `YYYYMMDD-NNN.png` → 缩略图 `YYYYMMDD-NNN-thumb.png` - -确认 `convert`（ImageMagick）可用；若不可用则改用 `ffmpeg`： - -```bash -ffmpeg -i "<大图路径>" -vf "scale=160:90:force_original_aspect_ratio=increase,crop=160:90" "<缩略图路径>" -y -``` - -若两者均不可用，回退到 Python Pillow： - -```python -from PIL import Image -img = Image.open("<大图路径>") -w, h = img.size -target = 160/90 -if w/h > target: - nw = int(h * target); img = img.crop(((w-nw)//2, 0, (w+nw)//2, h)) -else: - nh = int(w / target); img = img.crop((0, (h-nh)//2, w, (h+nh)//2)) -img.resize((160, 90), Image.LANCZOS).save("<缩略图路径>") -``` - -### 8. 输出格式 - -#### 8a. 体系内文章组（有关联的文章，用父条目分组） - -```markdown -- [核心命题](首篇文章URL) -- ![-](./金鹏/YYYYMMDD/YYYYMMDD-NNN-thumb.png) ← 列表标题图（160×90） -- ![-](./金鹏/YYYYMMDD/YYYYMMDD-NNN.png) ← 文章题图（16:9 大图，width=1000） -- 金句标签（核心命题的精髓表达，一句话） - - 层级标签： [文章标题](子文章URL) - - 定位描述——用一句话说明本文在体系中的位置，**粗体**突出关键词 - - 来源名称 - - 具体要点一 - - 具体要点二 - - **关键洞察或金句（加粗）** - - 层级标签： [下一个文章标题](URL) - - 来源名称 - - 定位描述——承上启下，用"这与XX呼应""与XX一样"等词语串联 - - 具体要点... -``` - -**规则**： -- 父条目缩进 0，子文章标题行缩进 4 空格，子文章内容缩进 8 空格 -- **层级标签在子文章标题前面**：`层级标签： [文章标题](URL)`，如 `总纲： [驾驭AI：...](url)`、`团队层： [角色分工：...](url)` -- 子文章标题：`动作名词：具体内容`，不超过 20 字 -- 来源行只写平台/作者名（如 `腾讯云`、`极客鑫`），**不在此处加层级标签** -- 总纲的定位描述放在来源之前（因为它是全组的总起），其他子文章的定位描述放在来源之后 -- 定位描述承上启下，用关联词串联上下文 - -#### 8b. 独立文章（不属任何体系的工具项目或单篇文章） - -```markdown -- [文章标题](URL) - - ![-](./金鹏/YYYYMMDD/YYYYMMDD-NNN-thumb.png) ← 列表标题图（160×90） - - ![-](./金鹏/YYYYMMDD/YYYYMMDD-NNN.png) ← 文章题图（16:9 大图，width=1000） - - 来源名称 - - 一句话核心摘要 - - 补充要点 -``` - -**规则**： -- 缩进 4 空格，不加层级标签 -- GitHub 项目：简要说明用途、技术亮点 - -### 标题命名 - -| 类型 | 格式 | 示例 | -|------|------|------| -| 父条目 | 核心命题，2-6 字 | `驾驭AI` | -| 体系内子文章 | `动作名词：具体内容`，≤20 字 | `角色分工：gstack 的虚拟工程团队` | -| 独立文章 | 简洁直白，≤15 字 | `实时数字人` | - -### 描述编写 - -1. **粗体**用于：核心命题、关键洞察、金句、颠覆性结论、范式突破 -2. 每条要点控制在 1-2 行 -3. 忠实原文观点，区分"作者的结论"和"我们的推断" -4. 子文章定位描述必须说明该文在体系中的位置，并与前文建立**真实的**关联（不为了体系完整而生造联系） -5. 对"争议"类观点保留对立声音，不一边倒呈现 - -### 注意事项 - -- **两图顺序固定**：列表标题图（160×90，`-thumb.png`）在前，文章题图（16:9 大图，`.png`，显示宽度 ≤1000px）在后——渲染列表时优先展示小图，展开详情时展示大图 -- 列表标题图 160×90 像素，由大图裁切生成（不单独调用即梦），确保两图视觉一致 -- 父条目和独立文章均需生成大图 + 列表标题图；体系内子文章不单独生成配图 -- 图片日期与文章日期一致，父条目配图用 `-001`，按文章出现顺序递增 -- 多个相关链接（GitHub、官网等）用缩进放在描述最后 - -## 执行后复盘（标准化复盘流程） - -每次执行本命令后，必须按以下结构化流程复盘。参照"实验迭代能力"的标准化原则——无论成功还是失败，都固定记录核心变量。 - -### 1. 记录执行变量 - -| 变量 | 说明 | -|------|------| -| 输入类型 | URL / 本地文件 / 粘贴内容 / GitHub 仓库 | -| 价值判断 | 高 / 中 / 低，判断依据 | -| 文章数量 | 单篇 / 多篇关联 / 独立 | -| 是否形成体系 | 是 / 否，原因 | - -### 2. 分析执行过程 - -分析本次执行过程的优点和缺点： - -- **优点**：哪些步骤/设计执行顺畅、达到预期效果？ -- **缺点**：哪些步骤/设计存在问题或可改进之处？ -- **反常识发现**：执行中是否有预期之外的情况？例如预期能形成体系的文章实际关联薄弱，或被判断为低价值的文章实际有意外亮点？ - -### 3. 评估是否需要更新命令 - -基于上述分析，判断当前命令是否需要更新。如果执行顺利无问题，注明"当前命令无需更新"。 - -### 4. 如需更新，提出建议并由人类确认 - -如果发现需要改进的地方，给出具体的更新方案（修改内容、位置、原因），由人类用户确认后再执行对命令文件的修改。 - -> **原则**：可改可不改的不改；只提出对执行质量有实质影响的更新建议。 diff --git a/.claude/commands/arno-dl-wx.md b/.claude/commands/arno-dl-wx.md deleted file mode 100644 index 1c1e3e1..0000000 --- a/.claude/commands/arno-dl-wx.md +++ /dev/null @@ -1,275 +0,0 @@ ---- -name: arno-dl-wx -description: 批量下载微信公众号文章全文，以发布日期为前缀保存为 Markdown 文件到 `资料/文章/` 目录，逐篇自动调用 `arno-anl-article` 生成批判性分析报告，最后验证内容完整性。在工作管理项目中，可用于收集行业动态、技术文章、政策法规等公众号文章作为参考材料。触发词：下载公众号文章、批量获取微信公众号、微信文章下载、公众号全文保存、wx批量下载、行业文章下载、公众号归档。 -argument-hint: <链接列表> ---- - -## 用户输入 - -```text -$ARGUMENTS -``` - -用户输入为一批微信公众号文章链接（每行一个或多个），以及可选的目标保存目录。若未指定目标目录，默认保存到 `资料/文章/` 目录。 - -链接格式：`https://mp.weixin.qq.com/s/<文章ID>` - -## 概述 - -批量获取微信公众号文章全文内容，以主智能体-子智能体协作模式，依次逐个下载每篇文章，保存为 `yyyy-MM-dd_文章标题.md` 格式的 Markdown 文件（以文章发布日期为前缀），最后验证全部内容的完整性和章节连贯性。 - -## 标准输出模板 - -每篇保存的文章 MUST 遵循以下统一格式： - -```markdown -# <文章标题> - -> **来源**：<公众号名称> -> **作者**：<作者名> -> **发布日期**： -> **原文链接**： - ---- - -<文章正文内容，保留原始 Markdown 格式> -``` - -### 模板字段说明 - -| 字段 | 提取来源 | 缺省值 | -|------|----------|--------| -| `文章标题` | 文章正文最大号文字或首行加粗文字 | 无（必填） | -| `公众号名称` | web-reader 返回的 `og:site_name` 或文章顶部公众号名称 | `微信公众平台` | -| `作者名` | web-reader 返回的 `author` / `og:article:author` 元数据，或文章开头署名 | `未知` | -| `发布日期` | 页面 `create_time` 时间戳转换，或文章顶部日期标注 | 当前日期 | -| `原文链接` | 用户提供的链接 | 无（必填） | -| `文章正文` | web-reader 返回的正文内容，保留原始段落、标题、加粗、列表等格式 | — | - -### 模板规则 - -1. 元数据块使用 `>` 块引用格式，字段间用两个空格 ` ` 换行（Markdown 软换行） -2. 元数据与正文之间用 `---` 分隔线隔开 -3. 正文保留原始 Markdown 格式不变 -4. 正文中如有图片链接（`![Image]` 格式），保留不删除 - -## 适用场景 - -- 批量下载系列连载文章（如书籍章节、课程讲义） -- 保存微信公众号专栏的全部文章 -- 归档公众号内容以供离线阅读或二次处理 -- **家庭管理场景**：收集家庭教育方法、健康养生知识、理财技巧、家庭关系建设等公众号文章，作为家庭参考资料的积累 - -## 架构模式 - -采用 **主智能体 → 子智能体串行调度** 模式： - -``` -主智能体（协调者） - ├─ 子智能体 #1 → 获取文章 1 → 保存 → 关闭 - │ └─ 主智能体 → 调用 arno-anl-article 分析文章 1 - ├─ 子智能体 #2 → 获取文章 2 → 保存 → 关闭 - │ └─ 主智能体 → 调用 arno-anl-article 分析文章 2 - ├─ ... - └─ 子智能体 #N → 获取文章 N → 保存 → 关闭 - └─ 主智能体 → 调用 arno-anl-article 分析文章 N - │ - └─ 主智能体验证全部文章完整性 -``` - -### 为什么串行而非并行 - -1. 微信公众号有反爬机制，并发请求容易触发限流 -2. 子智能体之间无共享状态依赖，但需要确保编号连续不混乱 -3. 串行执行方便追踪进度、定位问题 - -## 执行流程 - -### 第一步：初始化 - -1. 解析用户提供的链接列表，确认总链接数 N -2. 确认目标目录存在，不存在则创建 -3. 告知用户共 N 篇文章待下载 - -```bash -mkdir -p "<目标目录>" -``` - -### 第二步：串行调度子智能体 - -对每个链接依次执行： - -**启动子智能体**，传入以下任务指令： - -```text -你的任务是获取以下微信公众号文章的完整内容并保存。 - -**链接**: `<文章URL>` -**序号**: <当前序号>/<总文章数N> -**目标目录**: `<目标目录>` - -**执行步骤**: - -1. 使用 mcp__web-reader__webReader 工具获取该链接的完整文章内容。 - - 微信公众号文章 WebFetch 通常无法访问，直接使用 web-reader。 - - 如果内容被截断，尝试调整参数或分段获取。 - -2. 从获取的内容中提取文章元数据： - - **标题**：文章中最大号的文字或第一行加粗文字 - - **发布日期**：优先从页面 HTML 中的 `create_time` Unix 时间戳转换（`date -d @ '+%Y-%m-%d'`），其次从文章顶部日期标注提取；如都无法获取，使用当前日期 - - **公众号名称**：从 `og:site_name` 元数据或文章顶部公众号名称提取，缺省为 `微信公众平台` - - **作者名**：从 `author` / `og:article:author` 元数据或文章开头署名提取，缺省为 `未知` - -3. 将完整文章内容按照**标准输出模板**保存为 Markdown 文件： - - 文件名格式：`yyyy-MM-dd_文章标题.md`（日期为该文章发布日期） - - 文件名中空格和特殊字符（包括中文标点如 `，。！？；：""''、【】《》—…、` 及英文标点 `/ \ : * ? " < > |`）全部替换为 `_` - - 多个连续 `_` 合并为一个，末尾 `_` 去除 - - 保存路径：`<目标目录>/yyyy-MM-dd_文章标题.md` - - **严格遵循标准输出模板**： - ``` - # <文章标题> - - > **来源**：<公众号名称> - > **作者**：<作者名> - > **发布日期**： - > **原文链接**：<文章URL> - - --- - - <文章正文内容> - ``` - - 元数据块使用 `>` 块引用，字段间用两个空格换行 - - 元数据与正文之间用 `---` 分隔线隔开 - - 正文保留原始格式（段落、标题层级、加粗、列表等），图片链接保留不删除 - -4. 检查保存的文件内容字数，与原文内容字数进行比对。 - - 使用 `wc -c` 或字符计数工具 - - 差异应在 1% 以内（允许 Markdown 格式化标记带来的微小差异） - - 如果差异过大，说明内容可能被截断，需重新获取 - -5. 完成后向主智能体报告： - - 文章标题、作者、公众号、发布日期 - - 保存的文件名 - - 原文字数 vs 保存字数 - - 是否完整获取 -``` - -**关键约束**： -- **每次只启动 1 个子智能体**，等待其完成后才启动下一个 -- 子智能体使用 `general-purpose` 类型 -- 子智能体完成后自动关闭，不保留上下文 - -### 第三步：逐篇分析 - -每篇文章下载完成后（子智能体报告后），**立即**调用 `arno-anl-article` 技能对该文章进行批判性分析： - -```bash -# 使用 Skill 工具调用 -Skill: arno-anl-article -Args: <目标目录>/<刚下载的文章文件名>.md -``` - -**分析产物**： -- 分析报告保存为 `<文章文件名（不含.md）>_分析.md`，与原文在同一目录 -- 分析报告是独立文件，**不修改、不覆盖**原文 - -**关键约束**： -- **分析必须在下一篇下载之前完成**，保持串行节奏 -- 分析报告字数应与原文篇幅匹配（长文深度分析，短文简要分析） -- 分析报告文件名中的特殊字符与原文使用相同的 `_` 替换规则 - -### 第四步：验证全部文章 - -所有 N 篇文章下载并分析完成后，执行完整性检查： - -1. **文件清单检查**：确认目录下有 N 个文件，数量正确无缺漏 - -```bash -ls -1 "<目标目录>"/*.md -``` - -2. **文件大小检查**：确认每个文件非空，大小合理（微信公众号文章通常 3,000～15,000 字符） - -```bash -wc -c "<目标目录>"/*.md -``` - -3. **首尾内容检查**：读取每篇文章的开头和结尾，验证： - - 文章有明确的标题 - - 文章有自然的结尾（不是被截断的半句话） - - 如果文章是系列连载，检查相邻文章的章节衔接是否连贯 - -```bash -for f in "<目标目录>"/*.md; do - echo "=== $(basename "$f") ===" - head -2 "$f" - echo "..." - tail -3 "$f" - echo "" -done -``` - -4. **连贯性检查**（可选，适用于系列连载）： - - 前一章的结尾是否自然引出下一章 - - 章节编号是否连续（第1章 → 第2章 → …） - - 是否有内容重复或遗漏 - -### 第五步：修复遗漏（如有） - -如果验证发现以下问题： - -| 问题类型 | 处理方式 | -|----------|----------| -| 文件缺失（某文件不存在） | 重新分配子智能体下载该链接 | -| 内容截断（字数明显偏少） | 重新分配子智能体下载该链接 | -| 内容异常（乱码、空内容） | 尝试不同工具重新获取 | -| 日期错误（文件名日期与实际不符） | 调整文件名中的日期 | - -**原则**：不手动修复内容，只重新下载。 - -### 第六步：输出汇总 - -```markdown -## 下载完成 - -- 目标目录: <目录路径> -- 文章总数: N 篇 -- 总大小: XXXX 字节 -- 完整率: N/N (100%) - -| 序号 | 发布日期 | 文章标题 | 字符数 | 下载 | 分析 | -|------|----------|----------|--------|------|------| -| 1 | 2026-06-29 | XXX | X,XXX | ✅ | ✅ | -| 2 | 2026-06-29 | XXX | X,XXX | ✅ | ✅ | -| ... | ... | ... | ... | ... | ... | -``` - -## 关键指令 - -1. **串行调度**：每次只运行 1 个子智能体，等待完成后再启动下一个 -2. **使用 web-reader**：微信公众号文章 WebFetch 通常无法访问，直接使用 `mcp__web-reader__webReader` -3. **日期命名**：文件名以文章发布日期 `yyyy-MM-dd` 为前缀，后接下划线 + 文章标题 -4. **文件名安全**：空格和特殊字符（中英文标点如 `，。！？；：""''、【】《》—…、` 及 `/ \ : * ? " < > |`）全部替换为 `_`，多个连续 `_` 合并为一个 -5. **标准模板**：每篇文章 MUST 严格遵循标准输出模板，含来源、作者、发布日期、原文链接四个元数据字段 -6. **字数比对**：每个子智能体必须比对原文字数与保存字数，发现差异 >1% 需重试 -7. **不修改原文**：保存时只添加模板元数据头部（标题、元数据块、分隔线），不改动正文内容 -8. **逐篇分析**：每篇下载完成后立即调用 `arno-anl-article` 生成独立分析报告，分析完成后才启动下一篇下载 -9. **验证优先**：全部下载和分析完成后必须执行第四步验证，不可跳过 -10. **遇错重下**：发现问题不手动修复，重新分配子智能体下载 - -## 已知陷阱 - -- **WebFetch 不可用**：`WebFetch` 工具对 `mp.weixin.qq.com` 域名通常返回错误或被屏蔽内容，**必须使用 `mcp__web-reader__webReader`** 替代 -- **内容截断**：极长文章（>15,000 字符）可能被 web-reader 截断，如遇此情况可尝试调整 `return_format` 或 `content_size` 参数 -- **反爬限流**：短时间内大量请求可能触发微信反爬，串行执行天然规避此问题；若单篇文章也失败，等待 5-10 秒后重试 -- **标题特殊字符**：文章标题可能含 `/`（如"无代码/低代码"）及各种中英文标点，文件名中必须替换为 `_` -- **URL 有效期**：微信公众号文章链接通常长期有效，但部分文章可能被删除或转为仅关注可见 -- **图片丢失**：web-reader 返回的 Markdown 可能不含文章中的图片，如需保留图片需另行处理 - -## 与项目现有工具的配合 - -本技能聚焦于微信公众号文章的获取和归档。获取完成后，可配合以下项目技能进一步处理： - -| 后续操作 | 使用技能 | -|----------|----------| -| 文章批判性分析 | `arno-anl-article`（下载后自动调用） | diff --git a/.claude/commands/arno-docker-clear.md b/.claude/commands/arno-docker-clear.md deleted file mode 100644 index 08e648c..0000000 --- a/.claude/commands/arno-docker-clear.md +++ /dev/null @@ -1,135 +0,0 @@ ---- -name: Docker清理 -description: 清理 Docker 镜像构建临时文件和悬空资源 ---- - -## 用户输入 - -```text -$ARGUMENTS -``` - -执行前**必须**处理用户输入（非空时） - -## 参数说明 - -支持以下参数（可组合使用）： - -- `cache` - 仅清理构建缓存 -- `images` - 仅清理悬空镜像 -- `volumes` - 仅清理未使用的卷 -- `containers` - 额外清理已停止的容器 -- `all` - 清理默认项目（构建缓存、悬空镜像、未使用的卷） -- `detail` 或 `详细` - 显示详细清理过程 - -## 输出 - -### 格式要求 - -按以下格式输出清理结果： - -```markdown -## Docker 清理报告 - -### 清理前状态 - -| 类型 | 总量 | 活跃 | 占用空间 | 可回收 | -|------|------|------|----------|--------| -| **镜像** | {数量} | {数量} | {大小} | {大小} ({百分比}%) | -| **容器** | {数量} | {数量} | {大小} | {大小} ({百分比}%) | -| **本地卷** | {数量} | {数量} | {大小} | {大小} ({百分比}%) | -| **构建缓存** | {数量} | {数量} | {大小} | {大小} | - -### 清理内容 - -执行以下清理： - -- **构建缓存**：{清理的缓存大小} -- **悬空镜像**：{删除的镜像数量} 个 -- **未使用的卷**：{清理的卷大小} - -{如果用户指定了 `containers` 参数，则添加： -- **已停止的容器**：{删除的容器数量} 个 -} - -### 清理后状态 - -| 类型 | 总量 | 活跃 | 占用空间 | 可回收 | -|------|------|------|----------|--------| -| **镜像** | {数量} | {数量} | {大小} | {大小} ({百分比}%) | -| **容器** | {数量} | {数量} | {大小} | {大小} ({百分比}%) | -| **本地卷** | {数量} | {数量} | {大小} | {大小} ({百分比}%) | -| **构建缓存** | {数量} | {数量} | {大小} | {大小} | - -### 清理总结 - -**释放空间总计：约 {总大小}** - -{根据清理结果给出建议} -``` - -### 执行规则 - -1. **默认行为** - 无参数时，仅清理构建缓存（不清理悬空镜像、未使用的卷、容器） -2. **选择性清理** - 根据 $ARGUMENTS 中的参数执行对应清理 -3. **容器清理** - 仅当用户明确指定 `containers` 参数时才清理已停止的容器 -4. **详细模式** - 当 $ARGUMENTS 包含 "detail" 或 "详细" 时，显示详细的清理过程 -5. **安全检查** - 清理前先检查 Docker 状态，确认可清理内容 -6. **执行顺序** - 按以下顺序执行： - - 检查当前状态（`docker system df`） - - 清理构建缓存（`docker builder prune -a -f`） - - {如果指定了 `images` 参数} 清理悬空镜像（`docker image prune -f`） - - {如果指定了 `volumes` 参数} 清理未使用的卷（`docker volume prune -f`） - - {如果指定了 `containers` 参数} 清理已停止的容器（`docker container prune -f`） - - 显示清理后状态 - -### 清理命令参考 - -```bash -# 检查磁盘使用情况 -docker system df - -# 清理构建缓存（默认执行） -docker builder prune -a -f - -# 清理悬空镜像（需要明确指定） -docker image prune -f - -# 清理未使用的卷（需要明确指定） -docker volume prune -f - -# 清理已停止的容器（需要明确指定） -docker container prune -f - -# 一次性清理所有未使用资源（包括容器，不推荐使用） -docker system prune -a -f --volumes -``` - -### 注意事项 - -- **默认不清理容器**：已停止的容器不会在默认清理中删除，需明确指定 `containers` 参数 -- 构建缓存清理后重新构建镜像会需要更多时间 -- 删除的镜像和卷无法恢复，请谨慎操作 -- 建议定期清理以保持系统整洁 -- 显示可回收空间不代表实际释放空间，可能因层共享而不同 - -## 执行后复盘 - -每次执行本命令后，必须完成以下步骤： - -### 1. 分析执行过程 - -分析本次执行过程的优点和缺点： - -- **优点**：哪些步骤/设计执行顺畅、达到预期效果？ -- **缺点**：哪些步骤/设计存在问题或可改进之处？ - -### 2. 评估是否需要更新命令 - -基于上述分析，判断当前命令是否需要更新。如果执行顺利无问题，注明"当前命令无需更新"。 - -### 3. 如需更新，提出建议并由人类确认 - -如果发现需要改进的地方，给出具体的更新方案（修改内容、位置、原因），由人类用户确认后再执行对命令文件的修改。 - -> **原则**：可改可不改的不改；只提出对执行质量有实质影响的更新建议。 \ No newline at end of file diff --git a/.claude/commands/arno-dreamina.md b/.claude/commands/arno-dreamina.md deleted file mode 100644 index 457710b..0000000 --- a/.claude/commands/arno-dreamina.md +++ /dev/null @@ -1,260 +0,0 @@ ---- -name: 即梦AI生成 -description: 使用即梦（Dreamina）CLI 生成图片或视频，支持文生图、图生图、文生视频、图生视频、多图生视频、多模态生视频 -argument-hint: <生成需求描述> ---- - -## 用户输入 - -```text -$ARGUMENTS -``` - -## 概述 - -即梦（Dreamina）是字节跳动旗下的 AI 创作平台。`dreamina` CLI 是其命令行入口，允许在任意环境中使用即梦的生成能力。 - -详细文档：https://bytedance.larkoffice.com/wiki/FWTwwm0bGiishxkKOoScdHR2nsg - -## 前置条件 - -### 安装 CLI - -```bash -curl -fsSL https://jimeng.jianying.com/cli | bash -``` - -### 登录 - -```bash -dreamina login -``` - -若登录出错，可用 `--debug` 重试： - -```bash -dreamina login --debug -``` - -登录状态存储于 `~/.dreamina_cli/`，优先复用已有登录状态。 - -## 核心命令 - -**关键原则：实际执行前必须先用 `-h` 查看子命令的具体参数**，不同命令支持的模型、比例、时长、分辨率可能不同。 - -### 1. 查询额度 - -```bash -dreamina user_credit -``` - -### 2. 文生图（text2image） - -```bash -dreamina text2image -h -dreamina text2image --prompt "<描述词>" [其他参数] -``` - -### 3. 图生图（image2image） - -```bash -dreamina image2image -h -dreamina image2image --image "<图片路径>" --prompt "<描述词>" [其他参数] -``` - -### 4. 文生视频（text2video） - -```bash -dreamina text2video -h -dreamina text2video --prompt "<描述词>" [其他参数] -``` - -### 5. 图生视频（image2video） - -```bash -dreamina image2video -h -dreamina image2video --image "<图片路径>" [其他参数] -``` - -适用场景：基于单张图片生成动态视频（如让静态图动起来）。注意：分辨率继承输入图片比例，不支持 `--ratio` 参数。 - -### 6. 多图生视频（multiframe2video） - -```bash -dreamina multiframe2video -h -dreamina multiframe2video --images "<图1>" "<图2>" ... [其他参数] -``` - -适用场景：多张图片串联成连贯故事视频（智能多帧流）。不支持模型选择。 - -### 7. 多模态生视频（multimodal2video） - -```bash -dreamina multimodal2video -h -dreamina multimodal2video --prompt "<描述词>" [--image "<图>"] [--video "<视频>"] [--audio "<音频>"] [其他参数] -``` - -适用场景：旗舰视频模式，支持图片、视频、音频等多模态参考输入。支持 `--ratio` 参数控制输出比例，Pro 版额外支持 1080p。 - -### 8. 查询异步任务结果（query_result） - -```bash -dreamina query_result --submit_id <任务ID> -``` - -### 9. 查看历史任务（list_task） - -```bash -dreamina list_task -h -dreamina list_task [过滤参数] -``` - -## 工作会话（Session） - -```bash -dreamina session -h -dreamina session list -dreamina session create "<名称>" -dreamina session use -``` - -## 标准工作流程 - -### 步骤 1：确认需求 - -根据 `$ARGUMENTS` 判断生成类型： - -| 用户说 | 对应命令 | -|--------|---------| -| "生成一张...图片"、"画一个..." | `text2image` | -| "把这张图变成...风格"、"基于这张图生成..." | `image2image` | -| "生成一段...视频"、"做一个...动画" | `text2video` | -| "让这张图动起来"、"这张图生成视频" | `image2video` | -| "用这几张图做一个故事视频" | `multiframe2video` | -| 同时提供图片+视频+音频参考 | `multimodal2video` | - -### 步骤 2：查看命令帮助 - -```bash -dreamina <子命令> -h -``` - -### 步骤 3：检查额度 - -```bash -dreamina user_credit -``` - -### 步骤 4：提交生成任务 - -- **明确告知用户**即将消耗额度 -- **小批量**执行，每次提交少量任务便于审查 -- **记录**每次测试的命令、参数、`submit_id`、最终状态 - -### 步骤 5：轮询结果 - -```bash -dreamina query_result --submit_id -``` - -- `gen_status` 为 `querying` → 保存 `submit_id`，稍后查询 -- `gen_status` 为 `success` → 获取结果 -- `gen_status` 为 `fail` → 查看 `fail_reason`，告知用户具体原因 - -### 步骤 6：下载结果到本地 - -下载到 `知识/金鹏/20260605/`。 - -**命名格式**：`yyyyMMdd_00n.<扩展名>` - -- `yyyyMMdd`：当前日期 -- `00n`：图片序号，001, 002, ... -- `<扩展名>`：图片 `.png`，视频 `.mp4` - -示例： -- `20260605_001.png` -- `20260605_002.png` -- `20260605_003.mp4` - -```bash -mkdir -p 知识/金鹏/20260605 -curl -o "知识/金鹏/20260605/20260605-001.png" "" -``` - -### 步骤 7：输出结果 - -向用户展示： -- 生成的图片/视频本地路径 -- 使用的命令和参数 -- `submit_id`（便于后续追溯） - -## 账户与模型 - -### 账户信息 - -- **VIP 等级**：maestro（大师级，最高等级） -- 大部分图片模型（3.0/3.1/4.0/4.6/5.0）免费，仅 4.1（2 积分）和 4.5（4 积分）消耗积分 -- 生成前用 `dreamina user_credit` 确认余额 - -### 模型选择规则 - -本账号为 VIP maestro，**所有生成始终使用最高质量模型**： - -| 命令 | 默认模型 | 备选 | -|------|---------|------| -| **text2image** / **image2image** | `5.0`（最新 4K，免费） | `4.6` | -| **text2video** | `seedance2.0_vip`（70 积分） | `seedance2.0fast_vip` | -| **image2video** / **multimodal2video** | `seedance2.0fast_vip`（55 积分） | `seedance2.0_vip`（追求极致或需 1080p 时） | - -关键约束： -- **非 VIP 模型不可用**：`seedance2.0` 排队 33 万+，`seedance2.0fast` 频繁触发并发限制 -- 所有模型生成文字时均可能出现拼写错误，海报类需求需后期修图 -- 首次使用前通过 `-h` 确认模型列表是否有更新 - -> 详细模型对比测试数据与场景推荐矩阵见 `.claude/memory/dreamina.md` - -## 常见问题 - -### AIGC 合规确认 - -返回 `AigcComplianceConfirmationRequired` 时，需先在即梦 Web 端完成合规确认后重试。 - -### 排队 / 并发限制 - -通过 `query_result` 持续轮询，或更新 CLI： - -```bash -curl -fsSL https://jimeng.jianying.com/cli | bash -``` - -### 日志排查 - -日志位于 `~/.dreamina_cli/logs/`。 - -## 注意事项 - -1. **区分只读和付费操作**：`user_credit`、`query_result`、`list_task`、`-h` 只读；生成命令消耗额度 -2. **异步等待**：图片和视频生成是异步的，提交和查询分开执行 -3. **不同命令参数不通用**：不要假设某命令的模型、比例、时长、分辨率适用于其他命令 -4. **帮助优先**：不确定参数时，始终先用 `-h` 查看 - -## 执行后复盘 - -每次执行本命令后，必须完成以下步骤： - -### 1. 分析执行过程 - -分析本次执行过程的优点和缺点： - -- **优点**：哪些步骤/设计执行顺畅、达到预期效果？ -- **缺点**：哪些步骤/设计存在问题或可改进之处？ - -### 2. 评估是否需要更新命令 - -基于上述分析，判断当前命令是否需要更新。如果执行顺利无问题，注明"当前命令无需更新"。 - -### 3. 如需更新，提出建议并由人类确认 - -如果发现需要改进的地方，给出具体的更新方案（修改内容、位置、原因），由人类用户确认后再执行对命令文件的修改。 - -> **原则**：可改可不改的不改；只提出对执行质量有实质影响的更新建议。 diff --git a/.claude/commands/arno-pr.md b/.claude/commands/arno-pr.md deleted file mode 100644 index b755edc..0000000 --- a/.claude/commands/arno-pr.md +++ /dev/null @@ -1,181 +0,0 @@ ---- -name: 提交代码 -description: 提交全部内容并推送到远程仓库（不检查路径） ---- - -## 用户输入 - -```text -$ARGUMENTS -``` - -执行前**必须**处理用户输入（非空时） - -## 输出 - -1. 分析本次需要提交的内容，按照**Git 提交规范**整理提交消息 - -2. 提交全部内容并推送到远程仓库 - -3. 使用以下格式输出 - -```text -项目根目录： xxx -工作目录： xxx -本地分支： xxx -远程分支： xxx -远程地址： xxx -用户输入： $ARGUMENTS -提交哈希： xxx -提交时间： yyyy-MM-dd HH:MM:SS -提交日志： - -{git日志} -``` - -## Git 提交规范 - -遵循 Conventional Commits 标准，结合项目特定需求制定以下提交规范： - -### 提交消息格式 - -``` -<类型>(<作用域>): <描述> - -[可选正文] - -[可选脚注] -``` - -### 提交类型 - -**主要类型：** -- **功能 (`feat`)**: 添加新功能或增强现有功能 -- **修复 (`fix`)**: 修复 bug 或错误行为 -- **维护 (`chore`)**: 维护性任务（依赖更新、配置修改等） -- **文档 (`docs`)**: 文档更新、README、注释等 -- **重构 (`refactor`)**: 代码重构（不改变外部行为） -- **测试 (`test`)**: 添加、修改或修复测试代码 -- **格式 (`style`)**: 代码格式化、空白调整等 -- **性能 (`perf`)**: 性能优化改进 -- **构建 (`build`)**: 构建系统、工具链变更 - -**扩展类型：** -- **安全 (`sec`)**: 安全相关修复或改进 -- **依赖 (`deps`)**: 依赖包更新或添加 -- **清理 (`clean`)**: 删除无用代码或文件 -- **优化 (`perf`)**: 性能或代码优化改进 -- **配置 (`config`)**: 配置文件修改 -- **规格 (`spec`)**: speckit 规格文档更新 - -**特殊类型：** -- **合并 (`merge`)**: 分支合并 -- **进行 (`wip`)**: 工作进行中（开发中的临时提交） -- **回滚 (`revert`)**: 回滚之前的提交 -- **发布 (`release`)**: 发布版本标签 - -### 格式要求 - -**标题行规则：** -- 使用祈使语气（"添加" 而不是 "添加了"） -- 长度不超过 50 个字符 -- 类型后使用冒号和空格分隔：`功能: 添加用户认证` -- 可指定作用域：`功能(auth): 添加 JWT 验证` - -**正文内容（可选）：** -- 标题与正文之间留空行 -- 说明"做什么"和"为什么"，而非"怎么做" -- 每行不超过 72 个字符 -- 使用项目符号列出多个改动 - -**脚注信息（可选）：** -- 标记破坏性变更：`破坏性变更: 详细说明` -- 关联 issue：`关联: #123` 或 `解决: #456` -- 标记不兼容变更：`不兼容: API 接口参数调整` - -### 提交示例 - -#### 基础提交 -```bash -功能: 添加用户登录功能 -修复: 修复内存泄漏问题 -文档: 更新 API 文档 -维护: 更新依赖版本 -``` - -#### 带作用域的提交 -```bash -功能(api): 添加用户认证接口 -功能(ui): 添加登录页面组件 -修复(服务端): 修复数据库连接超时 -测试(集成): 添加端到端测试用例 -``` - -#### 详细描述的提交 -```bash -功能: 实现实时消息推送 - -- 添加 WebSocket 连接管理 -- 实现消息广播机制 -- 添加离线消息存储 -- 支持消息确认机制 - -影响范围： -- 前端消息组件更新 -- 服务端路由扩展 -- 数据库表结构变更 - -关联: #89 -``` - -### Claude Code 提交行为规范 - -**重要：Git 提交消息格式要求** - -- **禁止**在提交消息中添加以下内容： - - `🤖 Generated with [Claude Code](https://claude.com/claude-code)` - - `Co-Authored-By: Claude Sonnet 4.5 ` - - 任何类似的 AI 工具签名或标识 - -- **原因**：保持 Git 提交历史的简洁性和专业性，避免冗余的元数据 - -- **正确示例**： - ``` - 文档: 添加用户认证功能 - - - 添加 JWT 验证中间件 - - 实现登录登出接口 - - 添加权限校验逻辑 - ``` - -- **错误示例**（不要这样做）： - ``` - 文档: 添加用户认证功能 - - - 添加 JWT 验证中间件 - - 🤖 Generated with [Claude Code](https://claude.com/claude-code) - - Co-Authored-By: Claude Sonnet 4.5 - ``` - -## 执行后复盘 - -每次执行本命令后，必须完成以下步骤： - -### 1. 分析执行过程 - -分析本次执行过程的优点和缺点： - -- **优点**：哪些步骤/设计执行顺畅、达到预期效果？ -- **缺点**：哪些步骤/设计存在问题或可改进之处？ - -### 2. 评估是否需要更新命令 - -基于上述分析，判断当前命令是否需要更新。如果执行顺利无问题，注明"当前命令无需更新"。 - -### 3. 如需更新，提出建议并由人类确认 - -如果发现需要改进的地方，给出具体的更新方案（修改内容、位置、原因），由人类用户确认后再执行对命令文件的修改。 - -> **原则**：可改可不改的不改；只提出对执行质量有实质影响的更新建议。 \ No newline at end of file diff --git a/.claude/commands/arno-util-lark-delegate.md b/.claude/commands/arno-util-lark-delegate.md deleted file mode 100644 index c539ded..0000000 --- a/.claude/commands/arno-util-lark-delegate.md +++ /dev/null @@ -1,70 +0,0 @@ ---- -name: arno-util-lark-delegate -description: 以金鹏身份向 SZIS bot 或 DIT bot 发飞书消息指派任务。目标 bot 侧的 Claude Code 通过 lark-consumer 实时收到并自动执行。当用户要让另一个项目的 CC 干活、跨项目委派、给 szis/dit 下任务时使用。触发词：委派、delegate、让szis、让dit、给szis发、给dit发、跨项目指派。 -argument-hint: ' <任务指令>' -allowed-tools: Bash ---- - -# arno-util-lark-delegate - -以金鹏（user）身份向 SZIS 或 DIT bot 的 P2P 会话发消息指派任务。目标 bot 侧的 Claude Code（lark-consumer 监听）会实时收到该消息，并自动 send-keys 到对端 CC 输入框执行。 - -## 用户输入 - -``` -$ARGUMENTS -``` - -格式：`<目标> <任务指令>`，目标取第一个词，仅接受 `szis` 或 `dit`；其余整体作为任务指令文本。 - -## 执行流程 - -### 第1步：解析目标与任务 - -- 从 `$ARGUMENTS` 取首词为 `TARGET`（szis|dit），其余为 `TASK`。 -- `TARGET` 非 szis/dit 时，提示正确用法并退出，不要猜测发送。 - -### 第2步：按目标选择 profile 与 chat_id 发送 - -**向 SZIS bot 指派**（szis profile，金鹏已在 szis 授权 user 身份）： - -```bash -lark-cli --profile szis im +messages-send --as user \ - --chat-id oc_xxx \ - --text "" -``` - -**向 DIT bot 指派**（dit profile，需金鹏已在 dit 授权 user 身份）： - -```bash -lark-cli --profile dit im +messages-send --as user \ - --chat-id oc_xxx \ - --text "" -``` - -### 第3步：输出结果 - -展示 `ok`、`message_id`、`create_time`；失败时输出完整错误码与信息。 - -## 关键约束 - -- **必须 `--as user`（金鹏身份）**：目标 bot 的 consumer sender 白名单是金鹏；若用 bot 身份发，sender 是 app，会被对端 consumer 直接过滤，任务不会被执行。 -- **profile 与目标一一对应**：向 SZIS 发用 `--profile szis`，向 DIT 发用 `--profile dit`。open_id 与 chat_id 按 app 隔离，跨用会报 `99992361 open_id cross app`。 -- **写操作可见性**：发出的消息会真实进入对端项目的 Claude Code 并执行，指令内容需明确、自洽、可独立理解（对端没有本轮上下文）。 - -## 固定参数 - -| 目标 | profile | P2P chat_id | 对端 Claude Code | -|------|---------|-------------|------------------| -| szis | szis | oc_xxx | arno/szis（tmux ds-ds） | -| dit | dit | oc_xxx | allmed/dit | - -## 示例 - -``` -# 让 SZIS 整理本周对话捕捉 -/arno-util-lark-delegate szis 整理 01-输入/对话捕捉.md 本周新增条目，归类到对应清单 - -# 让 DIT 更新项目推进报告 -/arno-util-lark-delegate dit 用 arno-prj-upd 更新项目推进报告与项目推进分析判断 -``` diff --git a/.claude/commands/arno-util-lark-inbox.md b/.claude/commands/arno-util-lark-inbox.md deleted file mode 100644 index ff5c704..0000000 --- a/.claude/commands/arno-util-lark-inbox.md +++ /dev/null @@ -1,57 +0,0 @@ ---- -name: arno-util-lark-inbox -description: 读取金鹏与飞书 bot 的 P2P 私聊记录。优先展示实时事件流（lark-inbox.ndjson），回退到 API 拉取。通过环境变量 LARK_PROFILE/LARK_INBOX_CHAT_ID/LARK_INBOX_NDJSON_PATH/LARK_BOT_NAME 适配不同项目。当用户需要查看飞书收件箱、检查发给 bot 的消息时使用。触发词：收件箱、inbox、查看消息、bot对话、飞书消息。 -argument-hint: '[条数 默认10]' -allowed-tools: Bash ---- - -# arno-util-lark-inbox - -读取金鹏 ↔ bot P2P 私聊记录。**优先增量检查**（调用 `lark-inbox-check.sh --text`），有新消息则展示；有历史消息但无新消息时静默结束；ndjson 不存在时回退 API 拉取。增量检查脚本位于 `../tools/lark-inbox-check.sh`（相对 skill 目录），与 SessionStart hook 共用同一脚本、同一时间戳跟踪。 - -## 环境变量 - -| 变量 | 说明 | 示例 | -|------|------|------| -| `LARK_PROFILE` | lark-cli profile 名 | `szis` / `dit` | -| `LARK_INBOX_CHAT_ID` | P2P 会话 chat_id | `oc_xxx` | -| `LARK_INBOX_NDJSON_PATH` | 实时事件日志路径（相对项目根） | `01-输入/lark-inbox.ndjson` | -| `LARK_BOT_NAME` | bot 显示名称 | `SZIS` / `DIT` | - -## 用户输入 - -``` -$ARGUMENTS -``` - -## 执行流程 - -### 第1步：增量检查（优先） - -调用 `lark-inbox-check.sh --text`，按 tmux session 隔离的时间戳做增量检查（同一 tmux 窗口内多次 CC 会话共享时间戳，避免重复展示），只返回上次检查后的新消息（最多5条）。 - -```bash -lark-inbox-check.sh --text -``` - -- **有新消息** → 展示新消息，结束。 -- **无新消息** → 检查 ndjson 文件是否存在且非空： - - 存在（有历史消息但无新消息）→ **静默结束**，不输出任何内容。 - - 不存在 → 进入第2步（回退 API 拉取）。 - -### 第2步：回退 API 拉取（ndjson 不可用时） - -```bash -lark-cli --profile "${LARK_PROFILE}" im +chat-messages-list --as bot \ - --chat-id "${LARK_INBOX_CHAT_ID}" \ - --sort desc --page-size ${ARGUMENTS:-10} --json -``` - -区分 `sender_type: user`（👤 金鹏）和 `sender_type: app`（🤖 bot）。 - -## 示例 - -``` -/arno-util-lark-inbox # 最近 10 条 -/arno-util-lark-inbox 20 # 最近 20 条 -``` diff --git a/.claude/commands/arno-util-lark-me.md b/.claude/commands/arno-util-lark-me.md deleted file mode 100644 index ed49793..0000000 --- a/.claude/commands/arno-util-lark-me.md +++ /dev/null @@ -1,57 +0,0 @@ ---- -name: arno-util-lark-me -description: 飞书 bot 向金鹏私聊发送消息。通过环境变量 LARK_PROFILE/LARK_ME_USER_ID/LARK_BOT_NAME 适配不同项目。当用户需要给自己发飞书提醒、通过 bot 推送通知、快速测试飞书通道时使用。触发词：发给自己、bot消息、飞书提醒、lark-me、自发送。 -argument-hint: '<消息内容>' -allowed-tools: Bash ---- - -# arno-util-lark-me - -bot → 金鹏 P2P 快捷发送。 - -## 环境变量 - -| 变量 | 说明 | 示例 | -|------|------|------| -| `LARK_PROFILE` | lark-cli profile 名 | `szis` / `dit` | -| `LARK_ME_USER_ID` | 金鹏在该应用下的 open_id | `ou_xxx` | -| `LARK_BOT_NAME` | bot 显示名称 | `SZIS` / `DIT` | - -## 用户输入 - -``` -$ARGUMENTS -``` - -## 执行流程 - -### 第1步：发送消息 - -```bash -lark-cli --profile "${LARK_PROFILE}" im +messages-send --as bot \ - --user-id "${LARK_ME_USER_ID}" \ - --text "$ARGUMENTS" -``` - -### 第2步：输出结果 - -展示发送状态、message_id、时间。 - -## 固定参数 - -| 参数 | 值 | -|------|-----| -| 身份 | `--as bot` | -| Profile | `$LARK_PROFILE` | -| 目标 | `$LARK_ME_USER_ID`（金鹏） | -| 类型 | P2P 私聊 | - -## 示例 - -```bash -# 用户输入: /arno-util-lark-me 别忘了下午3点的会议 -# 等价于: -lark-cli --profile "${LARK_PROFILE}" im +messages-send --as bot \ - --user-id "${LARK_ME_USER_ID}" \ - --text "别忘了下午3点的会议" -``` diff --git a/.claude/commands/arno-util-stop.md b/.claude/commands/arno-util-stop.md deleted file mode 100644 index 10753a1..0000000 --- a/.claude/commands/arno-util-stop.md +++ /dev/null @@ -1,34 +0,0 @@ ---- -name: arno-util-stop -description: 任务执行完毕后的收尾流程——发送对话摘要、扫描新产生的承诺/待办/想法/决定并追加到对话捕捉文件。由 CLAUDE.md 强制要求在任务完成前调用，非用户直接触发。触发词：stop、收尾、任务完成、对话捕捉。 -allowed-tools: Bash, Read, Edit, Skill ---- - -# arno-util-stop - -任务执行完毕后的收尾流程。 - -## 环境变量 - -| 变量 | 说明 | 示例 | -|------|------|------| -| `LARK_PROFILE` | lark-cli profile 名 | `szis` / `dit` | -| `LARK_ME_USER_ID` | 金鹏在该应用下的 open_id | `ou_xxx` | -| `LARK_BOT_NAME` | bot 显示名称 | `SZIS` / `DIT` | - -## 执行流程 - -### 第1步：发送对话摘要 - -通过 `arno-util-lark-me` skill 发出本次对话的简要摘要。 - -### 第2步：扫描并捕捉新事项 - -扫描本次对话中新产生的承诺、待办、想法、决定。 - -- **有**：通过 Edit 追加到 `01-输入/对话捕捉.md`，格式：`- YYYY-MM-DD 类型：承诺/待办/想法/决定 内容 — 来源：上下文`，再通过 `arno-util-lark-me` skill 发出。 -- **无**：完全静默，不要输出任何文字。 - -## 关键指令 - -⚠️ 全程只通过工具操作，不附加任何解释文字。