鱼皮AI导航
鱼皮AI导航
  • 主页
  • 社区
  • AI工具
  • AI知识库
  • AI提示词
  • MCP
  • Skills
  • AI学习资源
  • AI资讯
  • GitHub开源
登录/注册
站长：程序员鱼皮 老鱼简历 商务合作 增值电信业务经营许可证
2026 鱼皮AI导航 | 沪ICP备19026706号-6
4
3
8

软件开发 AI 辅助工具汇总：Skills 与 MCP

李银行
李银行
2026-05-23 12:35
阅读 2216
李银行
2026-05-23 12:35
阅读 2216

第一部分：AI 辅助编程 Skills

一、元能力与通用工作流

这类技能旨在提升 AI 的通用能力，优化开发流程，是高效使用 AI 编程的基础。

Skill用途优势
Skill Creator将重复性工作流（如博客写作、代码生成）固化为可复用的 Skill。一次定义，多次调用，将 AI 助手转变为"可扩展工具平台"。
Find Skills当 AI 缺少特定能力时，自动在 skills.sh 等平台搜索并安装所需 Skill。让 AI 具备"自我扩展"能力，轻松应对新场景。
Learning Opportunities在编码过程中，主动识别可学习的知识点并提供解释和练习。实现"在编程中学习"，而非简单复制粘贴。
Planning with Files将复杂任务的规划（目标、研究、进度）持久化到 Markdown 文件中。支持跨会话任务延续，避免上下文丢失，便于项目管理。
Agent.md / Claude.md在项目根目录创建文件，作为 AI 的"永久记忆"，存放项目规范、PR 模板等。让 AI 每次对话都遵循团队约定，确保输出风格和质量的一致性。
自定义 Skill 封装将高频、固定的提示词和流程（如代码审查）封装成项目级 Skill。减少重复劳动，统一团队 AI 交互规范，便于知识沉淀。

二、测试与质量保障

这类技能专注于提升代码质量和测试效率，覆盖从用例生成到缺陷分析的全链路。

Skill用途优势
TDD/红绿重构框架强制 AI 遵循"先写失败的测试，再写实现，最后重构"的 TDD 流程。从源头保证代码可测试性，减少后期返工，提升设计质量。
单元测试生成为指定函数或模块自动生成覆盖正常、边界和异常情况的测试用例。极大减轻编写单元测试的枯燥工作，提升测试覆盖率。
自动化 Code Review对 Git Diff 或 PR 进行自动化审查，从安全、逻辑、性能等多维度输出结构化报告。可作为 IDE 插件、Git Hook 或 CI/CD 步骤，显著减少人工 Review 负担。
安全审查基于专业安全实践（如 OWASP Top 10）审查代码，识别 SQL 注入、XSS 等漏洞。弥补传统静态分析的不足，提升对安全敏感代码的防护能力。
缺陷预测与根因分析结合代码变更和历史缺陷数据，预测高风险模块，并辅助分析 Bug 根因。帮助测试团队聚焦高风险区域，提前预防线上问题。
AI 测试智能体让 AI 自主规划并执行测试（如接口、UI），生成测试报告并标记风险。将 AI 从"脚本生成器"升级为能自主完成任务的"测试代理"。

三、文档与知识管理

解决"文档与代码脱节"的痛点，实现文档的自动生成与同步。

Skill用途优势
代码驱动文档生成自动分析代码库，生成架构图、模块说明、API 文档等，并支持增量更新。告别手动维护文档，确保文档与代码实时同步，降低维护成本。
需求/测试点提炼读取 PRD、需求文档，自动提取测试点和验收标准，生成思维导图式清单。帮助测试和产品经理快速梳理测试范围，减少遗漏。
变更日志/发布说明生成根据 Git 提交记录自动生成结构化的变更日志（Changelog）。规范发布流程，让版本迭代历史清晰可追溯。
交互式代码库问答结合 RAG 技术，让 AI 基于整个代码库回答开发者关于实现、调用等问题。极大缩短新成员熟悉项目的时间，降低知识传递成本。

四、代码理解、重构与架构

辅助开发者进行代码库分析、重构和架构设计，提升代码可维护性。

Skill用途优势
代码库侦察兵分析 Git 历史，识别高频修改文件、Bug 集中区和技术债热点。帮助团队快速定位系统瓶颈，确定重构和优化优先级。
复杂度分析与重构建议计算圈复杂度等指标，找出"坏味道"代码，并提供具体的重构方案。将重构建议具体化，使代码优化过程更可执行。
架构审计与质量评估依据经典软件工程原则（如《代码整洁之道》）评估架构设计。从更高维度审视系统，发现设计层面的问题，提升整体质量。
遗留代码重构针对旧代码，按指定原则（如单一职责、TypeScript 严格模式）进行系统性重构。将庞大的重构工作拆解为 AI 可执行的步骤，降低重构风险。
设计模式与架构咨询根据需求描述，推荐合适的设计模式或架构风格，并生成骨架代码。在架构设计阶段提供专业建议，避免走弯路。

五、调试与运维

加速 Bug 定位、修复和运维问题分析，缩短问题解决周期。

Skill用途优势
自动化 Bug 分析与修复将错误日志、堆栈信息和相关代码提供给 AI，自动定位根因并提供修复建议。显著缩短复杂 Bug 的排查时间，尤其适用于偶发和难以复现的问题。
性能与 SQL 优化分析慢查询、性能热点代码，提供索引、缓存或算法层面的优化建议。通过 AI 分析执行计划，快速定位性能瓶颈，提升系统响应速度。
日志分析与异常监控解析日志文件，聚类相似错误，总结异常模式，并生成排查建议。帮助运维和开发团队快速掌握系统健康状况，提前发现潜在问题。

六、前端、UI 与图表生成

专注于提升前端开发和可视化表达的效率与质量。

Skill用途优势
截图/设计稿转代码将 UI 截图或 Figma 设计稿转化为 HTML/CSS/React/Vue 等前端代码。极大缩短从设计到原型的交付时间，快速验证想法。
统一 UI 风格生成遵循特定的设计语言生成风格统一的组件和页面。避免 AI 生成千篇一律的风格，提升产品审美。
技术图表生成通过自然语言描述，自动生成架构图、流程图、时序图等，支持 Excalidraw 等工具。高效创建用于文档和汇报的专业图表。
图片优化与处理自动增强截图清晰度、对比度，或将 AI 生成图片转为可编辑的 PSD/PPTX 文件。提升文档和分享材料的专业度，方便二次编辑。

七、工具生态与平台集成

主流工具

  • 通用代码助手: GitHub Copilot, Amazon CodeWhisperer, Google Code Assist, 通义灵码, 百度 Comate, 华为 CodeArts Snap
  • AI 原生 IDE: Cursor, Claude Code, Devin

核心能力

  • 实时代码补全、跨文件编辑、一键重构、智能对话式编程
  • 支持自定义指令和 Agent 模式，自动执行多步任务

生态协议

  • MCP (Model Context Protocol): 统一的工具调用协议，让 AI 安全调用外部 API、数据库等
  • Skills.sh 标准: 开放 Skill 规范，将自定义能力打包为标准模块供不同 AI 工具复用

第二部分：MCP（Model Context Protocol）

一、MCP 协议概览

定义与定位 MCP 由 Anthropic 于 2024 年开源，旨在统一 LLM 与外部工具、数据源的连接方式，被称为"AI 世界的 USB-C"。

核心架构 采用 Host-Client-Server 架构，基于 JSON-RPC 2.0 通信，支持本地 (stdio) 和远程 (HTTP/SSE) 两种传输方式：

  • MCP Host: 运行 LLM 的应用（Claude Desktop、Cursor 等）
  • MCP Client: 嵌入 Host，负责协议编解码和通信
  • MCP Server: 连接具体工具/数据源，向 Client 暴露能力

三类核心能力

  • Tools: 可执行的动作（调用 API、读写文件、执行命令）
  • Resources: 可供读取的上下文数据（文件内容、数据库记录、网页）
  • Prompts: 可复用的提示模板

与 Function Calling 的区别

  • Function Calling: 单厂商私有接口，模型调用单个函数
  • MCP: 开放协议，完整生态和通信标准，多模型多厂商的"工具总线"

二、MCP 客户端（Hosts）

通用 AI 客户端

  • Claude Desktop、DeepChat、ChatWise、5ire、eechat

开发者专用客户端

  • Cursor / Windsurf：深度集成 MCP 的 AI IDE
  • JetBrains IDEs：通过 MCP Proxy 插件获得 MCP 能力
  • 命令行与 Notebook 客户端：MCP-CLI、MCP-Jupyter

语言 SDK 官方及社区提供 Python、TypeScript、Java、Kotlin、Swift、Go、C#、Ruby、Rust 等多语言 SDK。

三、常用 MCP 服务器

类别服务器说明
文件系统Filesystem MCP安全访问本地目录，读写搜索
GitMCP按需检索 Git 仓库文档和代码
Obsidian MCP读写 Obsidian 笔记库
代码仓库GitHub MCP Server管理仓库、Issue、PR
Sourcegraph MCP强大代码搜索能力
Semgrep MCP静态分析，代码安全扫描
浏览器自动化Playwright MCP微软官方，浏览器控制与 UI 测试
Puppeteer MCP网页自动化和抓取
Firecrawl MCP动态渲染网页抓取为 Markdown
Apify MCP3000+ 云爬虫集成
Fetch MCP通用网页内容获取
数据库PostgreSQL MCPSchema 探索、SQL 执行、慢查询分析
Supabase MCP数据库、认证、实时订阅管理
Qdrant MCP向量数据库，RAG 和语义搜索
API/云服务OpenAPI MCP Server将 OpenAPI 规范自动转为 MCP 工具
Cloudflare MCP管理 Workers、KV、R2
阿里云 Ops MCP运维 ECS、监控、OOS
Docker/K8s MCP容器和集群管理
办公协同Slack / 企业微信 MCP消息发送、频道管理
Notion MCP读写页面和数据库
Google Sheets MCP表格数据操作
记忆/多模态Memory MCP基于知识图谱的持久记忆
mem0-mcp代码偏好和模式管理
Figma MCP读取设计稿生成前端代码
聚合网关OpenMCP多 Web API 聚合为单一入口
MetaMCP多 MCP Server 统一管理中间件

四、集成方式

IDE/编辑器中集成

  1. 在配置文件中添加 MCP Server 启动命令和参数
  2. 重启 Host 应用，自动建立连接
  3. LLM 在对话中发现并调用 Server 工具

封装现有 API 为 MCP Server

  1. 使用官方 SDK 创建项目
  2. 用装饰器定义工具函数（名称、参数、描述）
  3. 函数内部调用业务 API
  4. 启动后即可被任何 MCP 客户端调用

Agent 框架中使用 LangChain、AutoGen 等框架中，MCP Server 作为工具提供者，Agent 规划时自动调用。

五、实战案例

案例 1：从需求到 PR（端到端开发）

  • 组合：GitHub MCP + Filesystem MCP + Playwright MCP
  • 流程：描述需求 → 创建 Issue 和分支 → 读取代码生成方案 → 编写代码并 UI 测试 → 提交代码创建 PR

案例 2：代码库问答与重构

  • 组合：GitMCP + Sourcegraph MCP + Memory MCP
  • 流程：查阅提交历史和文档 → 搜索代码引用 → 存入持久记忆 → 基于历史上下文重构

案例 3：前后端联动（全栈开发）

  • 组合：Figma MCP + Filesystem MCP + Supabase MCP
  • 流程：读取设计稿生成前端代码 → 写入项目 → 设计数据库 Schema → 生成 CRUD 接口 → 前后端整合

案例 4：运维与数据分析

  • 组合：Docker/K8s MCP + PostgreSQL MCP + 云平台 MCP
  • 流程：拉取监控数据 → 查看服务状态 → 查询日志指标 → 生成分析报告并发送通知

六、学习资源

  • 官方: modelcontextprotocol.io（规范、SDK、示例）
  • Awesome 列表: awesome-mcp-servers、awesome-mcp-clients
  • 中文社区: CSDN、知乎等平台大量实践文章
AI
4
8
分享
操作
评论
相关内容
0个评论
全部评论
点击登录，快来和大家讨论吧～
表情
图片
🔥热门工具
朱雀AI检测朱雀AI检测
朱雀AI检测助手朱雀AI检测助手
LovartLovart
老鱼简历老鱼简历
WritePass官网WritePass官网
面多多面多多
CursorCursor
星月写作星月写作
零感AI零感AI
墨得问题墨得问题

目录

🔥 热门文章
1
手把手教你设计一个成熟的 Agent Harness
2500
2
我用 REA 逆向了付费颜色 APP，结果很意外！
570
3
离谱，DeepSeek 崩了 5 小时，大家却喊：梁圣恩情还不完？？
420
4
DeepSeek 全新模型发布，性价比最高的一集！
380
5
B 站上 DeepSeek 闹鱼灾了，我发起《大肥鱼清除计划》！
370
6
自己学习ai，直接买cursor 的套餐，还是买gpt 或者claude 的套餐?
360
7
又一个国产版 Codex 神器，也来卷办公了！
330
8
day3-如何写出一个高质量的 Skill（组内分享） 高质量 Skill 不是“一个调得很顺的巨型 Prompt”，而是一个可验证、可回归、可维护的能力包。 先定义“什么算好”，再实现“怎么做好”。评估体系先于 Skill 本身成型。 下面用“故障诊断 Markdown 转 YAML”作为例子，但方法是通用的。 --- 一、先想清楚：Skill 到底是什么 一个 Skill 至少包含四部分： 部分 作用 接口 输入什么、输出什么、边界在哪 流程 分几步做，每步的产物是什么 规则 硬约束、经验规则、失败模式 降级策略 不确定时怎么办，而不是硬编一个看似合理的结果 高质量 Skill 的共同点：职责单一、接口清晰、规则可定位、输出可验证。 反例：把几十条经验全塞进一个主 Prompt，改一条规则要重调整个 Prompt，评估时也不知道是哪条规则退化。 --- 二、核心方法：先建评估，再写 Skill 不要先写转换器再补测试。正确顺序是： 1. 定义输出契约：什么算合法、什么算合格； 2. 建金标准集：一小批人工认可“可放行”的样本； 3. 先写评估 Skill：让它在金标准集上跑出基线； 4. 再迭代生成 Skill：每次修改跑同一套评估，无退化且目标维度提升才算正向。 这就是评估驱动开发：评估是 Skill 的单元测试，金标准集是回归锚点。 --- 三、评估 Skill：三层门禁，逐层递进 前一层不过，后一层不跑。每层留可追溯证据。 第 1 层：确定性硬门禁 用解析器、Schema、校验器完成，不消耗模型成本。 · 输出可解析； · 必填字段齐全，类型/枚举合法； · 引用目标存在，无悬空引用、无不可达节点； · 关键路径至少有一条能到达预期出口。 不通过直接打回。 第 2 层：语义断言 用脚本 + 结构遍历检查“逻辑对不对”，仍然保持确定性。 通用检查项： · 覆盖率：源材料里的关键步骤、分支、条件，输出里是否都有对应？ · 完整性：每个判断节点是否都有明确出口？有没有死胡同？ · 可达性：每条路径是否都能到达预期终点？有没有无出口循环？ · 顺序与依赖：有先后依赖的操作，是否保留了顺序？有没有被拍平成无序列表？ 例子：故障诊断转换中，检查“每个判断项是否有是/否/异常出口”“每条路径是否能到根因”。 第 3 层：LLM-as-Judge 只处理解析器表达不了的维度：忠实度、完整性、可执行性。 但 Judge 会漂移，不能单独放行，必须建立在第 1、2 层之上。Judge 的 Prompt、rubric、模型版本都要版本化，换模型必须用金标准集重新校准。 通用 Judge 维度： 维度 问什么 忠实度 输出是否忠实源材料意图？有没有自行发明内容？ 完整性 关键步骤、条件、证据是否保留？隐式知识有没有被压成空话？ 收敛性 输出是否仍指向原目标，而不是发散？ 可执行性 下游不依赖源材料能否直接使用？ --- 四、金标准集：回归测试的锚点 不需要一开始就标注几百份。用已认可的样本当种子，扩到 15～30 份，覆盖失败模式而非随机抽样： · 完整正例：典型流程； · 边界/异常分支：异常路径、循环、前置失败回退； · 已知易错模式：实际踩过的坑； · 留出集：不参与调优，只用于最终验收，防过拟合。 金标准不需要完美，只需要当前标准下认可可放行。 回归指标：关键路径用 pass^k（k 次全过），稳定性用 pass@k。 --- 五、工程约束：让批量产出可重放 · 幂等：同输入 + 同 Skill 版本 + 同规则 → 输出一致，否则无法判断变好是 Skill 改了还是随机波动； · 隔离不阻断：单份失败进隔离队列，记录失败层和原因，不阻塞其余； · 版本绑定：规则、rubric、金标准集进 Git；每份报告绑定“源版本 + 生成 Skill 版本 + 评估 Skill 版本 + Judge 模型版本”； · 抽样人工复核：Judge 临界样本 + 易错模式，人工抽检结果反过来校准 rubric。 --- 六、Skill 本身怎么写 · SKILL.md 控制篇幅，写清：输入约定、输出契约、分步流程、硬规则、降级策略； · 经验规则放 references/ 或 rules/，按失败模式分类，不要全塞进主 Prompt； · 不确定时标 needs_review: true，不要硬编看似合理的结果； · 迭代由评估报告驱动：报告告诉你哪层挂了、哪类失败模式，你改对应规则文件，而不是漫无目的调 Prompt。 --- 七、落地顺序（不要反过来） 1. 固化输出契约：Schema + 结构约束； 2. 建金标准集：从已认可的 + 最易出错的样本开始； 3. 先写评估 Skill：跑出基线报告； 4. 再迭代生成 Skill：每次修改对比逐项通过率，无退化且目标提升才算正向； 5. 批量运行 + 隔离回放：失败进队列，结束后人工抽检； 6. 评估 Skill 自身版本化：换 Judge 模型必须重新校准。 --- 八、给组员的三条硬要求 1. 不许凭感觉说“变好了”：每次修改必须附评估报告对比，逐项通过率说话。 2. 不许跳过确定性门禁直接看 Judge 分数：前两层挂了，Judge 分数没有意义。 3. 不许把规则堆进主 Prompt：规则按失败模式分文件，评估报告要能定位到具体文件。 --- 一句话收尾 生成 Skill 决定“能不能做”，评估 Skill 决定“敢不敢用”。 先让评估体系站稳，再让生成器迭代。这样交付的不是一堆“看起来还行”的产出，而是一套可证明、可回归、可交接的 Skill 质量体系。
310
9
AI 越强，被它拒绝的代价就越大 我有时候会想：AI 越来越厉害之后，有些事情，会不会反而越来越难做？ 这个想法看起来有点矛盾。AI 明明在降低门槛，让不会写代码的人做出软件，让不会画画的人生成图片，让一个人完成过去需要整支团队才能完成的工作。但今天用 Codex 的时候，AI 拒绝帮我编写 SQL 注入的请求体，而那还是我有源码、在本地跑测试的情况。那么，往后是否只会更难？ 我们假设某一天，AI 说：「这个请求违规，我不能帮助你。」到那个时候，你还有多少能力，能绕过它，把事情做完？ 这里的「违规」需要打个引号。平台的规则、模型的判断、法律的要求，以及一件事实际有没有造成伤害，彼此之间并不总是画得上等号。一个请求可能确实危险，也可能只是缺少上下文被误判，或者恰好落在某家公司的限制范围里。 无论是哪种情况，随着我们越来越依赖 AI，这句拒绝都可能变得越来越贵。 今天，一个程序员让 AI 帮忙写代码，AI 拒绝了，他大概率还有别的办法：查文档、找开源项目、问同行，或者自己写。麻烦一点，慢一点，但路还在。 可如果十年之后，大部分程序都由 AI 完成，情况就不一样了。 很多人从接触编程的第一天起，就习惯了描述需求、等待生成、运行结果、继续迭代。他们能做出相当复杂的产品，却未必经历过独立处理底层问题的训练。平时，这种能力结构完全够用，效率甚至更高。只有 AI 拒绝的时候，他们才会发现：平常被省掉的那段学习过程，恰好是此刻最需要的东西。 到那时，一次拒绝的成本，可能就从「今晚多花两个小时」，变成「先花半年学会这门技术」。 拿 SQL 注入举个稍显极端的例子：往后，连真正理解这类攻击如何发生、能够独立构造测试的人，会不会也越来越少？ 这里也包括那些有正当需求的人。一个开发者想检查自己的旧系统，一个经过授权的安全研究员想复现漏洞，假如 AI 识别到危险模式就拒绝，而使用者又只熟悉「让 AI 帮我检查」，这项原本可以独立完成的工作，就这样卡住了。 但是安全专家不会因此消失，但这类技能可能越来越集中在少数人手里。你仍然可以找专家，只是要付出更多的钱、更多的时间，以及更高的沟通成本。 类似的困境，未必只发生在网络安全领域。 你想从一个停止维护的软件里取回自己的数据，需要解析它的旧文件格式。AI 判断这涉及规避保护措施，拒绝继续。你拥有这些数据，却没有能力把它们读出来。 你买了一台设备，厂商停止提供服务。你想修改程序让它继续运转，过程中需要处理某种访问限制。AI 不愿协助，而你所掌握的维修方式，早已只剩下「把报错发给 AI」。 你想给常用的网站写一个辅助工具，减少重复操作。平台将此归入自动化限制，AI 也据此拒绝。过去会写脚本的人可以自己判断、自己处理；未来的使用者，可能连从哪里开始都不知道。 这些例子有一个共同点：当工具同时承担了「执行工作」和「传授知识」的角色，它的拒绝就不只是挡住了一次任务，也挡住了获得这种能力的机会。 更麻烦的是，这种依赖往往是我们主动选择的，而且每一步都很合理。 既然 AI 几秒钟就能做好，为什么还要花几个月学习？既然公司可以采购成熟的 AI 服务，为什么还要养一支负责基础工作的团队？既然市场上已经很少有人手写这些东西，学校为什么还要花大量时间教？ 对个人、公司和学校来说，这些选择都有现实依据。但叠加起来，整个社会保留的独立能力就可能越来越少。等到某项能力突然受到限制，我们才发现，备用方案早已在追求效率的过程中被一点点削掉了。 所以，「AI 越强，做事越便宜」可能只描述了未来的一半。 另一半是：被允许的事情越来越便宜，被拒绝的事情依然需要人工完成，却要面对更少的人才、更高的报价，以及越来越难获得的知识。两边的成本差距，会越拉越大。 有人会说，可以换一个模型，或者用本地模型。这确实是重要的选项。只要工具之间还有充分竞争，开放模型还足够可用，限制就未必能形成真正的门槛。 但备用方案也需要维护。它需要硬件、知识、软件生态，以及一群仍然理解这些系统的人。如果大多数人已经习惯了最方便的商业服务，那么「理论上还有别的办法」和「普通人实际用得起、用得明白」，之间仍然可能隔着很远。 我担心的，正是这段距离。 我不指望 AI 对任何请求都照单全收。对明显会伤害他人的行为设置限制，有充分的理由。但我们也需要关心：限制由谁定义，误判有没有申诉渠道，用户能不能换工具，以及脱离这个工具之后，还剩下多少独立行动的能力。 保留这些能力，平时看起来甚至有点低效，明明可以自动生成，还要理解原理；明明可以一键完成，还要知道手动怎么做。 但这些看似多余的知识，会在工具拒绝、失效、涨价或改变规则的那一刻，成为真正的选择权。 AI 越强，我们可能越需要留意它说「不」的那一刻。 因为那句话的分量，最终取决于：它拒绝之后，我们还能做什么。
310
10
什么是LLM
300