تشغيل أي مهارة في Manus بنقرة واحدة

insight-collector

النجوم٨

التفرعات١

آخر تحديث١٢ مارس ٢٠٢٦ في ١٤:٣٤

Analyze any input material (URLs, code snippets, images, text, documents, screenshots) and extract technical insights, reusable code, and project ideas into the CodeSnippets knowledge base at /root/projects/CodeSnippets. Use this skill when the user drops a link, pastes code, shares a screenshot, sends a document, or provides raw text and wants it analyzed and archived as inspiration. Triggers: "收录", "分析这个", "记录一下", "add this to snippets", "collect", "/insight", or when user provides material (link/code/image/doc) with intent to archive into the project.

التثبيت

التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.

تشغيل في Manus

المصدر

lingengyuan

lingengyuan/my-skills

فتح مستودع GitHub عرض مستودعات المنشئ

تنزيل

تشغيل في Manus

المهن ذات الصلةSOC

استنادا إلى تصنيف SOC المهني

مطوّرو البرمجياتمهن الحاسوب والرياضيات·SOC 15-1252

مستكشف الملفات

3 ملفات

SKILL.md

readonly

name

insight-collector

description

Insight Collector

核心目标：榨干价值。 不只列举内容——要推理、连接、推导出行动。模板是容器，推理才是价值所在。

Step 0：扫描现有知识库

读 /root/projects/CodeSnippets/README.md 目录表，记住：

已有哪些主题（避免重复）
哪些现有条目可能与本次材料产生连接
知识库的空白领域（本次材料能否填补？）

Step 1：获取内容

输入类型	处理方式
URL	WebFetch 完整内容；有重要链出页面一并 fetch
粘贴代码	直接分析
图片 / 截图	Read 图片，描述架构图，提取可见代码和概念
文档（PDF/md/txt）	Read 文件
原始文本	直接分析

Step 2：提取——9 个维度

从材料中提取所有适用维度。🧠⚖️⚠️💡 信息密度最高、最容易被忽视，优先挖掘：

维度	提取内容	说明
🟢 可复用代码	可直接运行/导入的代码	原文提取，标注语言
🏗️ 技术模式	架构思路、API 用法、设计模式	给模式命名
📦 工具与依赖	值得关注的库、工具、服务	记录版本（如有）
🧠 心智模型	作者使用的思维框架	往往是最有价值的部分
⚖️ 权衡取舍	明确陈述的 tradeoff	X vs Y：什么时候选哪个
⚠️ 反模式与陷阱	Gotcha、常见错误、边界情况	独立踩坑要付出的代价
💡 非显见洞见	不经提示不会想到的"啊哈"结论	专家知道而新手不知道的
❓ 开放问题	材料提出或暗示的悬而未决问题	潜在研究方向
🚀 衍生想法种子	能从这里出发构建的方向（原始列表）	下一步 Step 3 深化

Step 3：深度推理——把提取物榨干

这是最重要的步骤。 对 Step 2 中每个高价值提取物，运行以下推理：

3A：蕴含链（"所以……"）

对每个重要洞见，追问 3 层：

洞见：X
→ 所以：Y（X 的直接推论）
→ 所以：Z（Y 的推论）
→ 因此可以：[具体行动]

示例：

洞见：agent 把"写代码"的时间成本降到接近零
→ 所以：过去"这个功能值不值花一天实现"的权衡框架已过时
→ 所以：边界情况、实验性功能、一次性脚本都值得尝试
→ 因此可以：建立"任何模糊想法都 prompt 一次"的工作习惯，而不是预先评估

3B：隐含假设挖掘

问：作者默认了什么，但没有说出来？

这些假设往往比结论本身更有价值——它们揭示了适用边界：

这个方案在什么条件下成立？
如果某个假设不成立，结论会怎么变？
作者的上下文（规模、技术栈、团队文化）是否影响结论的普适性？

3C：反事实分析

问：为什么选 X 而不是 Y？

不要只记录"他们用了 X"，要分析"选 X 而不是 Y 的决策逻辑"——这才是可迁移的判断力：

被放弃的替代方案是什么？
放弃的理由揭示了什么约束或价值观？
在不同场景下，Y 可能比 X 更合适吗？

3D：组合生成（连接现有知识库）

把本次材料中的概念与 Step 0 中记住的现有 KB 条目交叉：

[本次概念 A] × [已有 KB 条目 B] → [新想法 C]
新想法 C 的价值：{为什么 A+B 的组合比各自单独更有意思}
最小验证实验：{能在一天内完成的最小 spike}

示例：

[本次：Symphony 工作区隔离机制] × [已有：mini_symphony.py 的 TASKS.md 队列]
→ 新想法：给 mini_symphony 加 per-task git worktree，让每个任务在独立分支工作
价值：彻底消除任务间的文件干扰，失败任务不污染主工作区
最小验证：给 mini_symphony 加 --isolate 标志，用 git worktree add 实现

3E：边界与反例

问：这个方案在哪里会失效？

规模边界（10 个用户 vs 10万？）
复杂度边界（玩具项目 vs 生产系统？）
团队边界（单人 vs 多人协作？）
列出 1-2 个具体反例场景

Step 4：分类写出

目录路由

内容类型	目标目录	命名规则
可运行代码	`{language}/` 或 `snippets/`（跨语言）	`功能描述.py/.js/.rs`
项目灵感与方向	`ideas/`	`主题-方向.md`
外部资料精读	`analysis/`	`作者-主题.md`
独立 HTML 工具	`html-tools/`	`工具名.html`
项目/配置模板	`templates/`	`用途.template`

文件命名：小写、连字符、描述性。

代码文件 Header

# =============================================================================
# 名称: <Snippet Name>
# 来源: <原始 URL 或 "原创">
# 用途: <解决什么问题>
# 依赖: <pip install ... | stdlib only>
# 适用场景: <在哪些地方可以用>
# 日期: YYYY-MM-DD
# =============================================================================

文档模板

写 analysis/ 或 ideas/ 文件时，读取 references/doc-templates.md 获取完整模板结构。

Step 5：更新 README.md 和 READING_LIST.md

在中英文目录表中各新增一行：

| {emoji} | `path/to/file` | {功能描述} | {依赖} |

类型 emoji：🟢 代码 · 🟡 模板 · 🔵 参考。仅在新建目录时更新结构树。

同步 READING_LIST.md（/root/projects/CodeSnippets/READING_LIST.md）：

若本次来源 URL 在"待归档"中有对应的 - [ ] 条目 → 改为 - [x]
若 URL 不在列表中 → 在"已归档"末尾追加 - [x] {url}

Step 6：汇报

向用户报告，必须包含推理结论，不只是文件列表：

创建了哪些文件（路径 + 一句话描述）
Top 3 非显见洞见 + 蕴含链（最有价值的推理结论）
最强组合想法（哪两个概念组合最有意思，为什么）
建议的最小下一步（具体，能立即开始）

Guidelines

中文写 idea/analysis 文档和注释，代码用英文
一个来源可以产出多个文件（博文 → 代码片段 + idea 文档）
URL 来源必须包含 来源 字段
不要虚构代码——只提取实际存在于原材料的内容
对长文，聚焦最新颖可复用的部分，宁可深度不够广也不要广度不够深
衍生想法必须注明"来源组合"和"最小 spike"——没有这两项的想法是无效的
分析的质量标准：读完这个文档，能否做出比读原文更好的设计决策？

المزيد من هذا المستودع

نفس المستودع

portpilot-assistant

lingengyuan/my-skills

Use when users ask in Chinese or English to manage local dev ports via natural language (for example: pick an available port, inspect who uses port 3000, free a port, run port conflict doctor, or initialize .portmanrc). Route to PortPilot CLI commands; run read-only actions automatically and require detailed confirmation for write actions.

2026-04-128

readme-maintainer

lingengyuan/my-skills

Update or rewrite project README files directly with the current session model (Codex/Claude Code) using local repository facts, without calling external README generation APIs. Use when users ask to "update README", "rewrite readme.md", "generate project documentation", "refresh usage/install sections", or "align README with latest code changes" for a local repo.

2026-04-128

tech-article

lingengyuan/my-skills

Writes polished Chinese technical articles for WeChat or blog publication, then optionally generates matching illustrations. Use when user wants to write, draft, optimize, or illustrate a technical article. Handles the full pipeline: type selection → research → draft → fact-check → illustration.

2026-04-128

json-canvas

lingengyuan/my-skills

Create and edit JSON Canvas files (.canvas) with nodes, edges, groups, and connections. Use when working with .canvas files, creating visual canvases, mind maps, flowcharts, or when the user mentions Canvas files in Obsidian.

2026-03-128

obsidian-bases

lingengyuan/my-skills

Create and edit Obsidian Bases (.base files) with views, filters, formulas, and summaries. Use when working with .base files, creating database-like views of notes, or when the user mentions Bases, table views, card views, filters, or formulas in Obsidian.

2026-03-128

obsidian-markdown

lingengyuan/my-skills

Create and edit Obsidian Flavored Markdown with wikilinks, embeds, callouts, properties, and other Obsidian-specific syntax. Use when working with .md files in Obsidian, or when the user mentions wikilinks, callouts, frontmatter, tags, embeds, or Obsidian notes.

2026-03-128

name

insight-collector

description

Insight Collector

核心目标：榨干价值。 不只列举内容——要推理、连接、推导出行动。模板是容器，推理才是价值所在。

Step 0：扫描现有知识库

读 /root/projects/CodeSnippets/README.md 目录表，记住：

已有哪些主题（避免重复）
哪些现有条目可能与本次材料产生连接
知识库的空白领域（本次材料能否填补？）

Step 1：获取内容

输入类型	处理方式
URL	WebFetch 完整内容；有重要链出页面一并 fetch
粘贴代码	直接分析
图片 / 截图	Read 图片，描述架构图，提取可见代码和概念
文档（PDF/md/txt）	Read 文件
原始文本	直接分析

Step 2：提取——9 个维度

从材料中提取所有适用维度。🧠⚖️⚠️💡 信息密度最高、最容易被忽视，优先挖掘：

维度	提取内容	说明
🟢 可复用代码	可直接运行/导入的代码	原文提取，标注语言
🏗️ 技术模式	架构思路、API 用法、设计模式	给模式命名
📦 工具与依赖	值得关注的库、工具、服务	记录版本（如有）
🧠 心智模型	作者使用的思维框架	往往是最有价值的部分
⚖️ 权衡取舍	明确陈述的 tradeoff	X vs Y：什么时候选哪个
⚠️ 反模式与陷阱	Gotcha、常见错误、边界情况	独立踩坑要付出的代价
💡 非显见洞见	不经提示不会想到的"啊哈"结论	专家知道而新手不知道的
❓ 开放问题	材料提出或暗示的悬而未决问题	潜在研究方向
🚀 衍生想法种子	能从这里出发构建的方向（原始列表）	下一步 Step 3 深化

Step 3：深度推理——把提取物榨干

这是最重要的步骤。 对 Step 2 中每个高价值提取物，运行以下推理：

3A：蕴含链（"所以……"）

对每个重要洞见，追问 3 层：

洞见：X
→ 所以：Y（X 的直接推论）
→ 所以：Z（Y 的推论）
→ 因此可以：[具体行动]

示例：

洞见：agent 把"写代码"的时间成本降到接近零
→ 所以：过去"这个功能值不值花一天实现"的权衡框架已过时
→ 所以：边界情况、实验性功能、一次性脚本都值得尝试
→ 因此可以：建立"任何模糊想法都 prompt 一次"的工作习惯，而不是预先评估

3B：隐含假设挖掘

问：作者默认了什么，但没有说出来？

这些假设往往比结论本身更有价值——它们揭示了适用边界：

这个方案在什么条件下成立？
如果某个假设不成立，结论会怎么变？
作者的上下文（规模、技术栈、团队文化）是否影响结论的普适性？

3C：反事实分析

问：为什么选 X 而不是 Y？

不要只记录"他们用了 X"，要分析"选 X 而不是 Y 的决策逻辑"——这才是可迁移的判断力：

被放弃的替代方案是什么？
放弃的理由揭示了什么约束或价值观？
在不同场景下，Y 可能比 X 更合适吗？

3D：组合生成（连接现有知识库）

把本次材料中的概念与 Step 0 中记住的现有 KB 条目交叉：

[本次概念 A] × [已有 KB 条目 B] → [新想法 C]
新想法 C 的价值：{为什么 A+B 的组合比各自单独更有意思}
最小验证实验：{能在一天内完成的最小 spike}

示例：

[本次：Symphony 工作区隔离机制] × [已有：mini_symphony.py 的 TASKS.md 队列]
→ 新想法：给 mini_symphony 加 per-task git worktree，让每个任务在独立分支工作
价值：彻底消除任务间的文件干扰，失败任务不污染主工作区
最小验证：给 mini_symphony 加 --isolate 标志，用 git worktree add 实现

3E：边界与反例

问：这个方案在哪里会失效？

规模边界（10 个用户 vs 10万？）
复杂度边界（玩具项目 vs 生产系统？）
团队边界（单人 vs 多人协作？）
列出 1-2 个具体反例场景

Step 4：分类写出

目录路由

内容类型	目标目录	命名规则
可运行代码	`{language}/` 或 `snippets/`（跨语言）	`功能描述.py/.js/.rs`
项目灵感与方向	`ideas/`	`主题-方向.md`
外部资料精读	`analysis/`	`作者-主题.md`
独立 HTML 工具	`html-tools/`	`工具名.html`
项目/配置模板	`templates/`	`用途.template`

文件命名：小写、连字符、描述性。

代码文件 Header

# =============================================================================
# 名称: <Snippet Name>
# 来源: <原始 URL 或 "原创">
# 用途: <解决什么问题>
# 依赖: <pip install ... | stdlib only>
# 适用场景: <在哪些地方可以用>
# 日期: YYYY-MM-DD
# =============================================================================

文档模板

写 analysis/ 或 ideas/ 文件时，读取 references/doc-templates.md 获取完整模板结构。

Step 5：更新 README.md 和 READING_LIST.md

在中英文目录表中各新增一行：

| {emoji} | `path/to/file` | {功能描述} | {依赖} |

类型 emoji：🟢 代码 · 🟡 模板 · 🔵 参考。仅在新建目录时更新结构树。

同步 READING_LIST.md（/root/projects/CodeSnippets/READING_LIST.md）：

若本次来源 URL 在"待归档"中有对应的 - [ ] 条目 → 改为 - [x]
若 URL 不在列表中 → 在"已归档"末尾追加 - [x] {url}

Step 6：汇报

向用户报告，必须包含推理结论，不只是文件列表：

创建了哪些文件（路径 + 一句话描述）
Top 3 非显见洞见 + 蕴含链（最有价值的推理结论）
最强组合想法（哪两个概念组合最有意思，为什么）
建议的最小下一步（具体，能立即开始）

Guidelines

中文写 idea/analysis 文档和注释，代码用英文
一个来源可以产出多个文件（博文 → 代码片段 + idea 文档）
URL 来源必须包含 来源 字段
不要虚构代码——只提取实际存在于原材料的内容
对长文，聚焦最新颖可复用的部分，宁可深度不够广也不要广度不够深
衍生想法必须注明"来源组合"和"最小 spike"——没有这两项的想法是无效的
分析的质量标准：读完这个文档，能否做出比读原文更好的设计决策？