1. 从收藏夹吃灰到真能跑起来这份资源清单到底解决什么问题做开发和测试的朋友大概都有过这种体验刷到一篇讲 AI 编程工具的文章顺手收藏看到有人分享大模型本地部署的教程再收藏听说 MCP 能让 AI 直接操作你的编辑器、数据库、浏览器赶紧又收藏。三个月后打开收藏夹链接躺了几百条真正动手跑通的没几个。问题不在于资源少而在于资源太散、太杂而且大部分分享只告诉你有这么个东西不告诉你它到底好不好用、坑在哪、免费额度够不够造。这份清单的出发点很朴素把过去一段时间里我实际用过、测过、踩过坑的 AI 编程、大模型、Skills、MCP 相关资源做一次集中梳理覆盖 30 多个条目每一条都尽量说清楚三件事——它是干什么的、我实测下来的优缺点、以及免费渠道或者低成本上手方式。关键词里的 AI、大模型、Skills、MCP、开发测试资源基本就是这份清单的四大板块。它适合几类人刚接触 AI 编程想找入口的新手、已经在用但想补齐工具链的老手、以及做测试开发想把 AI 能力接进自己工作流的工程师。需要先说明一点这份清单不是权威排行榜而是个人视角的实战记录。同一个工具在不同人手里体验差异很大我会尽量把判断依据讲出来你自己按需取用。另外工具迭代极快我写下的版本状态可能过几周就变了所以重点放在怎么判断一个工具值不值得投入这套方法上而不是死记某个功能。2. AI 编程工具从补全到 Agent别只盯着一个2.1 代码补全类工具的取舍逻辑代码补全是最早普及的一类 AI 编程能力核心场景就是你敲一半它接一半。这类工具我前后用过四五款最大的感受是补全质量高度依赖上下文窗口和项目索引能力而不是模型本身有多强。一个能读整个仓库、理解你项目里自定义函数命名的工具哪怕底层模型小一点实际体验也往往好过模型很强但只看当前文件的方案。实测下来补全类工具最值得关注的三个指标是首字延迟、多行补全的接受率、以及对项目内私有 API 的识别能力。首字延迟超过 500 毫秒你的思路就被打断了再准也没用多行补全接受率低你会频繁按 Esc反而更累私有 API 识别差它就会瞎编你项目里根本不存在的函数名这种幻觉补全是最大的坑。免费渠道方面大部分补全工具都有免费档通常限制在每月一定次数的补全请求或者只开放小模型。我的建议是先用免费档跑一周重点观察它在你自己项目上的接受率而不是看官方 demo。demo 都是精心挑过的你自己的代码才是真实考场。2.2 Agent 型编程工具能力越强边界越要划清Agent 型工具和补全工具是两回事。补全是你主导、它辅助Agent 是你给目标、它自己规划步骤、读写文件、跑命令。这类工具这两年爆发式增长关键词里的 AI Agent、多 AI 协作都属于这个范畴。我实测下来Agent 型工具最大的价值在于处理跨多个文件的机械性重构比如把某个旧 API 全项目替换成新 API、批量补测试用例、统一代码风格。但它的问题也很明显一旦任务描述模糊它会自作主张改一堆你没让它改的东西。我踩过最典型的一次坑是让它优化这个模块的性能结果它顺手把日志格式也改了导致下游的日志解析脚本全挂。所以用 Agent 的铁律是任务边界要写死改动范围要限定跑完必须 diff 审查。别偷懒直接 commit。多 AI 协作是最近比较热的方向思路是让一个模型负责规划、另一个负责执行、再来一个负责审查。听起来很美实测下来在简单任务上纯属增加开销只有在复杂重构或者需要交叉验证的场景才有意义。我的经验是任务复杂度没到一定程度别上多 Agent单 Agent 加人工审查性价比更高。2.3 提示词这件事别神化也别轻视AI 编程提示词是绕不开的话题。我的观点比较直接提示词能显著提升输出质量但它救不了模糊的需求。你如果自己都没想清楚要什么再花哨的提示词也是白搭。真正有效的编程提示词核心就三块——明确输入输出、给出约束条件、提供一两个示例。举个实际例子让 AI 写一个函数差的提示是帮我写个解析函数好的提示是写一个 Python 函数输入是形如keyvalue的多行字符串输出是 dict遇到重复 key 保留最后一个空行跳过不要用第三方库。后者几乎一次就能跑对前者你得来回改五轮。所以与其收藏一堆万能提示词模板不如练就把需求拆清楚的能力。3. 大模型选型本地、云端、私有化到底怎么选3.1 先搞清楚你的真实约束是什么大模型选型这件事网上讨论经常陷入哪个模型最强的争论但实际工程里最强往往不是最合适的。你得先回答几个问题数据能不能出本地预算多少延迟要求多高并发量多大这几个约束一摆出来选择范围立刻缩小一大半。关键词里提到企业大模型私有化部署、本地部署大模型这类需求通常来自数据敏感场景。私有化的核心价值不是省钱而是数据不出内网。但代价是你要自己扛硬件、扛运维、扛模型更新。我见过不少团队一上来就追求私有化结果发现维护成本远超预期最后又退回云端。所以我的建议是除非有硬性合规要求否则先用云端 API 验证业务价值跑通了再考虑私有化。3.2 本地部署的硬件账要算清楚本地部署大模型硬件是绕不过去的坎。核心瓶颈是显存模型参数量和显存需求大致有个对应关系7B 级别模型量化后大概需要 6 到 8GB 显存13B 级别需要 10 到 16GB再往上就得专业卡了。这里的量化是指把模型权重从高精度压缩到低精度牺牲一点精度换显存和速度常见的有 4bit、8bit 量化。很多人忽略的一点是显存够只是能跑起来要跑得舒服还得看显存带宽和上下文长度。上下文长度直接决定你能喂多长的文档进去关键词里大模型上下文长度也是热词说明大家确实关心。上下文越长显存占用越高而且是平方级增长的关系所以别盲目追求超长上下文按实际需求来。免费大模型 API 是另一个高频需求。市面上确实有一些提供免费额度的渠道通常限制在每分钟请求数或者每月总量。我的用法是把免费额度留给开发和测试阶段生产环境该付费付费别为了省这点钱把线上服务搞得不稳定。3.3 微调不是万能药先问值不值得大模型微调是很多人一上来就想做的事但我的经验是大部分场景根本不需要微调。微调适合的是任务格式固定、有大量标注数据、且通用模型怎么调提示词都做不好的情况。如果你只是想让它按特定风格回答提示词加几个示例就够了如果你是想注入私有知识检索增强通常比微调更划算因为知识更新时不用重新训练。微调的真实成本不只是训练那一下还包括数据清洗、标注、评估、以及后续每次基座模型更新都要重训。我见过团队花两个月做微调最后效果还不如精心设计的提示词加检索。所以动手前先做个最小验证用提示词方案能不能达到 80 分能的话就别微调。4. Skills 与 MCP让 AI 真正动手的两套机制4.1 Skills 的本质是给 AI 装操作手册Skills 这个概念最近很火前端开发 Skills、Agent Skills、Codex Skills 各种说法都有。剥开包装看本质Skills 就是一套结构化的指令加资源包告诉 AI 在特定场景下该怎么做、用哪些工具、遵循什么流程。你可以把它理解成给 AI 准备的岗位操作手册——它本来什么都会一点但有了手册它在你的具体业务里就能做得更规范。我实测下来Skills 最大的价值在于把重复性的工作流固化下来。比如你团队有一套固定的代码审查清单、一套固定的测试用例生成规范把它写成 SkillAI 每次执行就都按这个来不用你反复在对话里交代。这比每次手写长提示词靠谱得多也更利于团队共享。Skills 开发的门槛其实不高核心是把你希望 AI 怎么做这件事写清楚。但有个坑要注意Skill 写得太泛等于没写写得太死又失去灵活性。我的经验是把必须遵守的硬约束和可以参考的建议分开写前者用明确的规则后者用示例引导。4.2 MCPAI 和外部世界之间的标准接口MCP 是什么这个问题被问得最多。简单说MCP 是一套让 AI 模型能够标准化地调用外部工具和数据的协议。在 MCP 出现之前你想让 AI 读你的数据库、操作你的编辑器、访问你的文件系统每个工具都得单独对接乱得很。MCP 相当于定了一个统一的插头标准工具方按标准做接口AI 方按标准调用两边就解耦了。关键词里出现了各种 MCP 相关的具体场景比如接入设计工具、调试器插件、把工具流式输出到文件等。这些场景的共同点是AI 需要和某个具体软件交互。MCP 让这件事变得可配置而不是每个组合都要写代码。但 MCP 实测下来也有明显的坑。最常见的是授权问题——很多工具接入 MCP 时需要配置访问权限配置不对就连不上报错信息还特别含糊。我排查这类问题的顺序通常是先确认 MCP 服务本身起来了没再确认 AI 客户端配置里的路径和参数对不对最后才怀疑权限。另外MCP 工具调用失败时AI 有时会假装成功这个要特别警惕关键操作一定要有独立的验证步骤。4.3 Skills 和 MCP 怎么配合这两者不是竞争关系而是互补。MCP 解决AI 能碰到什么Skills 解决AI 碰到之后该怎么做。举个例子你要让 AI 自动处理一批测试数据MCP 负责让 AI 能读到数据文件、能写结果文件Skills 负责告诉它数据怎么清洗、异常值怎么处理、结果按什么格式输出。两个配齐才是一个完整的自动化流程。我的实操建议是先搭 MCP 把手脚接上确认 AI 能稳定读写你要的资源再写 Skill 把脑子里的流程固化。顺序反了会很痛苦因为流程写得再好工具连不上也是白搭。5. 开发测试资源实操从环境到验证的完整链路5.1 环境准备阶段最容易忽略的三件事搭 AI 开发测试环境很多人一上来就装工具结果卡在环境问题上耗掉大半天。我总结下来有三件事最容易被忽略。第一是版本兼容性AI 工具链更新极快某个库的新版本可能和你的工具不兼容建议锁定版本而不是无脑升最新。第二是网络和依赖源部分工具安装依赖时默认走国外源速度慢还容易断提前配好国内镜像能省很多时间。第三是权限和路径尤其是涉及文件读写、进程调用的工具路径写错或者权限不足报错往往很隐晦。我的习惯是每搭一个新环境先写一个最小可运行示例确认基础链路通了再往上叠功能。别一上来就搞复杂配置出了问题你都不知道是哪一层的事。5.2 测试环节AI 生成的测试用例要验货用 AI 生成测试用例是提效利器但直接拿来用风险很大。我实测发现AI 生成的测试用例常见问题有三个一是覆盖的是正常路径边界和异常场景经常漏二是断言写得松比如只判断不报错不判断结果对不对三是会编造不存在的接口或参数。所以我的流程是AI 生成初稿人工补边界用例然后跑一遍看覆盖率重点看异常分支有没有被覆盖到。关键词里提到 AI 测试开发这块的核心不是让 AI 替代测试而是让 AI 把重复的用例编写工作干掉人专注在设计测试策略和判断结果合理性上。5.3 把工具串成工作流才算真正落地单个工具用得再溜不成流程也是零散的点。真正提效的是把 AI 编程、大模型、Skills、MCP 串成一条链。举个我实际在用的链路用 Agent 型工具做代码改动改动完自动触发测试用例生成生成的用例跑一遍结果通过 MCP 写回项目目录最后人工审查 diff。这条链跑通之后日常的机械性开发任务能省掉一大半时间。但串流程有个前提每个环节都要有明确的输入输出和失败处理。AI 环节最怕的就是静默失败——它没做成但也不报错你以为成了。所以每个关键节点都要加验证宁可多一步检查也别让错误往下游传。6. 免费渠道与成本控制把钱花在刀刃上6.1 免费额度的正确用法免费渠道是这份清单里大家最关心的部分。我的原则是免费额度用来验证和开发不用来跑生产。原因很简单免费额度通常有速率限制和总量限制生产环境一旦被限流影响的是真实用户。而且免费渠道的稳定性通常不如付费用来做实验可以扛业务不行。具体用法上我会把免费额度集中用在探索期——试新工具、跑原型、验证某个方案可不可行。这个阶段对稳定性要求低对成本敏感正好匹配免费渠道的特点。等方案验证通过再切到付费或者自建。6.2 自建和采购的临界点在哪什么时候该自建什么时候该买服务这个临界点很多人算不清。我的经验是看两个维度使用频率和数据敏感度。低频且数据不敏感直接买服务最省事高频或者数据敏感才考虑自建。自建的成本不只是硬件还有人力——你得有人维护、有人处理故障、有人跟进更新。一个粗略的判断方法如果自建方案的年化成本硬件折旧加人力超过采购同等能力服务的费用且你没有合规硬要求那就别自建。很多团队自建是因为感觉更可控但实际算下来并不划算。6.3 成本控制的几个实操技巧控制 AI 相关成本有几个我实测有效的技巧。第一是缓存相同或相似的请求结果缓存起来能省掉大量重复调用。第二是分级简单任务用小模型复杂任务才上大模型别所有请求都走最贵的。第三是限制上下文很多人习惯把一大堆无关内容塞进上下文既费钱又降低效果按需给上下文反而更准。第四是监控一定要有调用量和费用的监控不然月底账单出来才发现超支就晚了。7. 踩坑实录那些文档里不会写的教训7.1 工具看起来能用和真能用是两回事我踩过最多次的坑就是工具在 demo 场景下跑得飞起一接真实项目就各种问题。原因通常是 demo 数据干净、规模小而真实项目数据脏、规模大、边界情况多。所以我现在评估任何工具都坚持用真实项目的一小块数据去试而不是用官方示例。这一步能提前暴露 80% 的问题。7.2 版本升级要留退路AI 工具链的版本迭代速度快到让人怀疑人生。我有一次手贱把某个核心工具升到最新版结果它改了配置格式我整套流程全挂回滚又发现旧版本和新装的依赖冲突折腾了一整天才恢复。从那以后我的规矩是升级前先备份配置升级后先在测试环境验证确认没问题再动生产。而且尽量锁定版本别开自动更新。7.3 别把 AI 的输出当事实这一点在测试和数据处理场景尤其重要。AI 会自信地给出错误答案而且错得很像对的。我见过 AI 生成的测试报告里把没跑过的用例标成通过也见过它编造出一个根本不存在的 API 文档。所以凡是 AI 产出的关键结论都要有独立的验证手段。这不是不信任 AI而是工程上必须有的冗余。7.4 排查问题的顺序很重要遇到 AI 工具报错很多人第一反应是去搜错误信息但 AI 工具的错误信息经常是下游报错、上游背锅搜到的答案往往不对症。我的排查顺序是先确认最底层的依赖网络、权限、服务进程是否正常再逐层往上查。这个顺序能避免你在错误的方向上浪费时间。关键词里提到工具连不上、找不到配置这类问题基本都是这个排查逻辑。8. 我个人的使用体会这份清单里的资源我自己也不是每个都长期在用。用下来最深的体会是工具的价值不在于它有多少功能而在于它能不能稳定地解决你的一个具体问题。与其追新不如把一两个核心工具用透把工作流跑顺。AI 编程、大模型、Skills、MCP 这些东西本质都是放大器——你原本的工作流清晰它们让你更快你原本就乱它们只会让乱得更快。另外分享一个小习惯我会给每个在用的工具记一条最小可用配置就是能跑起来的最简设置。换机器、重装环境、或者推荐给别人时直接照着这条配置来省去大量回忆和试错。这个习惯帮我省下的时间比任何单个工具带来的提效都多。工具会过时但把复杂事情拆成最小可验证单元这套方法一直管用。