佬们，

我开发了 Linky，一个能自动在各类网站提交链接（发外链）的 AI 工具。

传统工具的痛点：

• 名单固定： 往往只能在预设的 500-2000 个站点里打转。
• 极其脆弱： 只要目标网站改个 UI，脚本就报错。
• 特征明显： 机械化的操作路径很容易被反爬虫系统识别。

我的解决方案：

Linky 结合了 AI（Claude/OpenAI） 和 Playwright。它不再是死记硬背脚本，而是通过理解网页结构来智能操作。

核心亮点：

• 全网通用： 你给它任何网址，它都能尝试去理解并完成提交，不局限于固定列表。
• 自适应 UI： 即使网站改版，AI 也能通过语义理解找到正确的输入框和按钮。
• “动作回放” (Action Replay)： AI 第一次成功探索后会记录路径，后续执行零成本，无需重复消耗 Token。
• 拟人化操作： 模拟真实的点击和录入行为，规避自动化检测。
• 自带 Key (BYOK)： 用户自带 API Key，成本完全透明，不收中间费。

技术栈：

• 桌面端： Electron + React 19
• 后端： Python + FastAPI + browser-use (AI 浏览器框架)
• 自动化： Playwright

目前仅支持 macOS，Windows 版本正在路上。

这还是个正在开发中的早期项目，我不知道大家是否认为它有用。

如果你对这个工具感兴趣的话，欢迎去 GitHub 点个 Star 以给我反馈！

GitHub 传送门： https://github.com/jiweiyeah/linky-ai

（补充：这工具是用 Claude 写的，用 AI 来写一个 AI 工具，这种感觉挺奇妙的 ）

Skills 的底层逻辑：从提示词到架构模式

最近 Skills 功能上线了，看到大家都在分享使用教程。

我就不凑热闹发教程了，今天给各位大佬分享一点更底层的东西：Skills 的本质到底是什么？

学不会？没事，学中干，干中学各位，没必要非要知道原理，只要会用即可！！！

下面我用很简答易懂的话讲解了，还不懂就评论问吧！！！

什么是 Skills？

Skills 的本质：Agent 时代的通用架构模式

Skills 不属于任何模型，不属于 MCP，也不属于任何一家科技巨头。

它是 Agentic AI ( 智能体 AI) 发展过程中诞生的一种通用设计 模式 (Design Pattern)。

抛开所有无用的内容，来看看具体实现，Skills 的核心逻辑其实很简单，可以用下面这个永恒的公式概括：

Skills = System Prompt (系统提示词) + Trigger (自动触发器) + Executable (可执行文件)

1. 手动模式 vs 自动模式

为了理解 Skills 的适用性，我们回溯到人与 AI 交互的最基本形式。

比如当你想要 AI 帮你写出一段高质量代码时，你通常可能会输入这样一段话：

“你现在是一个资深 Python 架构师，精通设计模式和性能优化。请帮我审查这段代码…”

在这个瞬间，你所输入的对话，其实就是在手动执行一个 Skill。

你通过手动输入，给 AI 设定了角色 (Role) 和 上下文 (Context)。

所谓的 Skills，就是把这个过程 “代码化” 或 “自动化” 了。

无论是在 Gemini CLI、Claude Code 还是现在的这些 IDE 中，逻辑都是一样的：

用户将这段 “资深 Python 架构师” 的设定（Prompt）封装成一个独立的模块。

系统告诉模型：“如果用户问代码问题，你就自动加载这个模块，不需要用户每次都手敲。”

2. 为什么系统提示词 (System Prompt) 也能调用 Skills？

你可能会问：模型是怎么知道我有这些 Skills 的？

这就涉及到了 System Prompt 的隐形机制。

在对话开始之前，IDE 已经在后台偷偷做了一件事：它把所有可用 Skills 的名字和描述，写进了发给模型的第一条系统提示词里。

这就像是考试前，老师（IDE）给学生（模型）塞了一张小纸条：

“考试须知：如果你遇到不懂的代码题，你可以申请查阅‘Python 架构师手册’（即调用 skill: python-architect）。”

正因为系统提示词里预埋了这些指令，模型才能在遇到问题时，理直气壮地 “调用” Skills。

所以，System Prompt 不仅是 Skills 的载体，更是 Skills 的 “目录” 和 “导航”。这也是为什么我在 IDE 不支持的情况下能够将 skills 实现，很早就写出提示词来实现了 skills 这个功能。

3. 进阶：Skill 包的解剖学 (Scripts & Assets)

很多高级 Skill（比如 ui-ux-pro-max-skill）不仅仅是一个 Markdown 文件，它往往是一个文件夹。

一个完整的 Skill 包结构通常是这样的：

my-complex-skill/
├── SKILL.md          # 大脑：提示词和指令
├── scripts/          # 手脚：Python/Node.js 脚本
│   ├── audit.py
│   └── generate.js
└── assets/           # 素材：图片、模板
    └── logo.png

当 AI 决定调用这个 Skill 时，它不仅会读取 SKILL.md，还会获得执行 scripts/ 下脚本的权限。 比如，AI 可能会运行 python scripts/audit.py 来扫描你的代码，而不是自己瞎猜。

4. 环境悖论：没有 Node 环境会怎样？

这是一个非常现实的问题：

“如果我在 Skills 中设定了调用 Node.js 脚本，但我电脑上没有安装 Node，Skills 会自动下载吗？”

答案是：通常不会。

Skills 是运行在你本地环境 (Local Environment) 中的。

• Skill 就像是一张游戏光盘。

• 你的电脑 就像是游戏机。

• Node/Python 环境 就像是操作系统。

如果你买了游戏光盘（下载了 Skill），但没买游戏机（没装 Node），游戏是跑不起来的。 Agent 尝试运行 node script.js 时，会直接收到系统的报错：command not found: node。

虽然现在的 Agent 很聪明，它可能会检测到报错，然后建议你：“检测到未安装 Node.js，请先安装。”

但它通常不敢（也不应该）擅自帮你下载安装这种系统级的 Runtime，因为这涉及巨大的安全风险和兼容性问题。 如何保证能够让 skills 实现下载 node 环境呢？

这里有一个专业的术语，叫 “Runtime Bootstrapping” (运行时引导)。

你不应该简单地说 “下载 Node”，而应该在 Skill 的定义中加入一段 “自愈式 (Self-Healing)” 的指令。

专业的话术建议：

“Prerequisite Check & Environment Setup” (前置检查与环境搭建)

“在执行任何脚本之前，请先运行 node -v 验证运行时环境。如果环境缺失，请不要直接报错，而是根据用户的操作系统（Windows/macOS/Linux），生成对应的安装命令（如 winget install 或 brew install），并引导用户完成安装。”

这样做，你的 Skill 就从一个 “会报错的脚本”，变成了一个 “会照顾用户的智能体”。

这也是为什么 ui-ux-pro-max-skill 这个 skills 会有那么多人是使用，因为人在 skills 中照顾到了所有的群体，没有环境，那我就下环境，可以看这个 skills 来实现自己的 skills。

5. 核心辨析：Skills vs MCP vs RAG

在 Agent 的架构中，很多人容易混淆这三个概念。其实它们构成了智能体的 “能力铁三角”：

一句话总结它们的关系：

一个强大的 Agent，会用 Skills (专业思维) 去指挥 MCP (手脚)，并参考 RAG (记忆) 来完成任务。

Skills 往往是那个指挥官。它定义了流程，而 MCP 是它调用的工具。

6. 痛点：为什么有些模型 (如 GLM-4.7) 跑 Skills 效果不好？

这其实是目前 Agent 开发中最大的坑：Skills 对模型是有门槛的。

你可能会发现，同样的 Skill，在 gemini 3 flash 上跑得行云流水，但在 GLM-4.7 或 DeepSeek 上却经常 “卡壳” 或 “乱答”。

这背后的原因主要有三点：

A. Function Calling (工具调用) 的微调差异

Skills 的触发依赖于模型输出极其精准的 JSON 格式 指令。

• Claude/Gemini：经过了海量的 Tool Use 专项微调，它们知道什么时候该 “闭嘴去调工具”。

• 普通模型：往往有 “抢答” 的毛病。它们看到了 Skill 的描述，却选择直接用自己的通用知识去回答用户，而不是去调用 Skills。

B. System Prompt 的权重问题

Skills 的指令通常是写在 System Prompt 里的。

有些模型在训练时，过分强调了 User Prompt (用户输入) 的权重，导致它忽略了 System Prompt 里的设定。

结果就是：你明明加载了 “资深架构师” 的 Skill，它却还是像个 “普通客服” 一样回答你。

这也就是为什么在国内模型中需要设定很严格的提示词规则！！！

C. 复杂推理链 (Reasoning Chain) 的断裂

执行一个 Skill 往往需要多步操作（思考 → 选工具 → 看结果 → 再思考）。

很多模型在第一步之后就 “累” 了，或者丢失了上下文，导致 Skill 执行到一半就中断了。

结论：Skills 是一种高级玩法，它需要 Agentic Model (代理级模型) 的支持，而不仅仅是 Chat Model (聊天模型)，并且要上下文够长才能支持的更好。

6. Skills 是如何跑起来的？

这个模式的成功，依赖于现代 LLM (大语言模型) 进化出的两个通用素质：

A. Tool Use / Intent Recognition (意图识别能力)

这是 Skills 的开关。

模型必须具备一种元能力：不仅仅是 “回答问题”，而是能 “判断该用什么方法回答问题”。

当模型意识到：“用户的问题超出了我的通用知识，我需要激活 python-architect 这个专业模块” 时，Skill 就被触发了。

B. Long Context / In-Context Learning (上下文学习能力)

这是 Skills 的容器。

当 Skill 被激活时，系统会瞬间将几千字甚至上万字的专业指令（即那个封装好的 Prompt）注入到对话流中。

模型必须有足够大的容量来接纳这些新规则，并立即改变自己的行为模式。

7. 最后的最后

Skills 是 Prompt Engineering (提示词工程) 走向 Software Engineering (软件工程) 的必然产物。

它解决了 AI 应用开发中的一个根本矛盾：通用性与专业性的矛盾。

我们不需要一个在每一秒都精通所有领域的臃肿 AI。

我们需要的是一个灵活的调度器，它能根据你的需求，在毫秒级的时间内，从口袋里掏出那个最正确的剧本（Skill），瞬间变身为那个领域的专家。

这就是 Skills。

它是流动的知识，是按需分配的智慧。 感谢各位观看！！！如果有用请多多评论！！！