新闻详情

新闻详情

首页 / 资讯中心 / 详情

MFC/VS截屏实战:GDI BitBlt原理与避坑指南

发布时间:2026/10/2 3:40:06来源:尧图网络
MFC/VS截屏实战:GDI BitBlt原理与避坑指南
简介面向MFC/C开发者的屏幕截图功能实现资源基于Visual Studio环境完整演示如何捕获整个屏幕或指定窗口并将其保存为BMP/JPEG文件。压缩包共22个文件其中6个.h头文件与3个.cpp源文件承载核心逻辑1个.rc描述对话框资源.sln/.vcxproj为VS工程配置log为编译日志整体仅136KB结构紧凑。代码围绕GDI与CDC展开依次调用GetDC获取屏幕设备上下文、CreateCompatibleDC与CreateCompatibleBitmap创建内存画布、BitBlt完成像素复制、SelectObject选入位图并给出SaveImage自定义函数的文件写入流程。同时涉及CFile/CFileException文件操作与异常处理以及ReleaseDC、DeleteDC、DeleteObject等资源释放写法可帮助读者避开常见的内存泄漏和GDI句柄泄漏问题。已有634人学习适合初学MFC图形编程或需要在项目中快速集成截屏能力的开发者参考也可在此基础上扩展定时截屏、窗口截图等功能。1. MFC/VS截取屏幕图片这套组合能给你什么以及为什么值得从头搭无论是做一个小工具随手抓屏保存还是给巡检类程序加一个“出故障先留证据”的能力用 MFC 在 Visual Studio 里把屏幕像素取出来存成图片都是 Windows 桌面端最常被问到的一类需求。这个需求不追求炫技要的是稳定、可控、不依赖网络和第三方 SDK。市面上现成截屏库很多但很多时候你只是想要一个自己说了算的入口甚至希望代码短到能写进自己项目里随时改。本文按一条真实能跑通的路径来讲先弄清楚 GDI 截屏的原理再从 VS 向导建一个 MFC 对话框工程把截图按钮接起来最后专门讲黑屏、DPI 缩放、GDI 泄漏这些让初学者翻车的点。适合想在 Visual Studio 里用 C 快速产出 Windows 小工具、又不想被大框架绑住的开发者也适合需要二次开发屏幕采集功能的人。2. 截屏的核心链路屏幕 DC、内存 DC 和位图三者怎么接才不翻车先想一个问题屏幕上的画面是以什么形式存在的系统并没有给应用程序开放一个“读取像素数组”的 API所有绘图都要经过一个叫设备上下文DC的抽象层。截屏这件事本质上就是从屏幕 DC 里把像素复制到一张由你控制内存的位图上。这个复制动作由 GDI 的 BitBlt 完成它也是整条链路里唯一绕不开的核心函数。把这条链路理解透了后面写 MFC 封装代码就只是套壳而已。2.1 为什么用 GDI 的 BitBlt而不是 PrintWindow 或剪贴板方案有不少人一开始会想窗口都能 PrintWindow直接让它把窗口画出来不就完了吗PrintWindow 确实能截某个窗口但它是请求窗口自己重绘到指定的 DC 里对于用了 DirectX 渲染、硬件加速视频的区域经常只能得到一块空白。而 BitBlt 做的是纯粹的像素块复制它不关心那些画面是谁画的只要这些像素已经呈现在屏幕上就能原样拷走。这让它成为“所见即所得”式截屏的默认答案。另一个常见思路是发送 WM_PRINT 或者把画面放进剪贴板再读出来。这些方案本质上也绕不开 BitBlt 或类似机制而且多一层剪贴板交互就多一个被其他程序清空的隐患。剪贴板方案适合做“用户主动复制屏幕”的场景不适合做无人值守的自动截图。所以 MFC/VS 场景下我的选择很固定GetDC(NULL) 拿屏幕 DCCreateCompatibleDC 建内存 DCCreateCompatibleBitmap 建位图最后 BitBlt 收尾。这套组合拳也是 Windows 上最传统、兼容性最好的截屏路径。2.2 唯一需要背下来的截屏代码全屏捕获函数下面这段用纯 Win32 写方便看清每一步后面再套进 MFC 类里。#include windows.h HBITMAP CaptureFullScreen() { // 获取主屏幕的像素尺寸。注意这个值会受 DPI 影响后面避坑章细说 int cx GetSystemMetrics(SM_CXSCREEN); int cy GetSystemMetrics(SM_CYSCREEN); // 屏幕 DC代表真实屏幕的绘图表面 HDC hdcScreen GetDC(NULL); // 内存 DC所有绘制先在这里完成不直接污染屏幕 HDC hdcMem CreateCompatibleDC(hdcScreen); // 兼容位图颜色格式与屏幕一致保证 BitBlt 不做低效转换 HBITMAP hbmNew CreateCompatibleBitmap(hdcScreen, cx, cy); // 选中位图并保存旧位图指针稍后还原 HGDIOBJ hOld SelectObject(hdcMem, hbmNew); // 核心动作把屏幕矩形区的像素原样复制到内存位图 BitBlt(hdcMem, 0, 0, cx, cy, hdcScreen, 0, 0, SRCCOPY); // 还原 DC 状态释放 DChbmNew 留给调用方保存或进一步处理 SelectObject(hdcMem, hOld); DeleteDC(hdcMem); ReleaseDC(NULL, hdcScreen); return hbmNew; }BitBlt 的十个参数里最关键的是这几组目标 DC 是内存 DC坐标是 (0, 0)宽高是 (cx, cy)源 DC 是屏幕 DC坐标也是 (0, 0)表示从屏幕左上角取起。SRCCOPY 是光栅操作码意思是“直接把源像素覆盖到目标区”不掺任何透明或混合逻辑。抓全屏时源坐标和目标坐标都是 (0, 0)看起来对称到了第四章做区域截图时这两组坐标就要各算各的了。DeleteDC 和 ReleaseDC 的顺序也有讲究先把旧的 SelectObject 还回去再把 DC 删掉。如果 DC 里还挂着我们刚创建的位图就 DeleteDC位图对象并不会被释放反而会造成 GDI 对象悬空。这个函数返回的 HBITMAP调用方必须负责在不用的时候 DeleteObject否则每次截屏都会漏掉一个位图对象具体后果放在避坑章的 5.3 里说。3. 在 VS 里建一个 MFC 对话框工程从向导到按钮全流程这一章直接落到 Visual Studio 的操作上。MFC 的历史包袱不少但用向导建一个对话框工程仍然是做桌面小工具最快的起点没有之一。整个过程大约十分钟之后你得到的不仅是一个能跑的窗口还有一个由框架管理的消息循环和资源脚本比纯 Win32 手写窗口省很多事。3.1 新建工程时的三个选项静态 MFC、字符集、最小 UI打开 Visual Studio新建项目搜索“MFC 应用”命名比如 ScreenSnap其他按默认进入向导。这里有三处值得手动调整直接影响后续体验。第一处是“应用程序类型”选“基于对话框”而不是“单文档”或“多文档”。截屏工具不需要文档视图框架对话框程序启动快、代码直观。第二处是“MFC 的使用”默认是“在共享 DLL 中使用 MFC”我建议改成“在静态库中使用 MFC”后面 5.4 会解释为什么这样能避免换台机器就缺 DLL 的尴尬。第三处是“高级功能”里的 ActiveX 控件勾选框用不上就去掉省得资源文件里多出一堆无关代码。字符集保持 Unicode 即可现在的 Windows 生态里 ANSI 工程只会给自己添麻烦。向导完成后资源视图里双击 IDD_SCREENSHOP_DIALOG 打开对话框编辑器从工具箱拖一个按钮进去把 ID 改成 IDC_BTN_SHOT标题改成“截图并保存”。再在对话框上放个静态文本框ID 改成 IDC_STATIC_INFO用来回显保存路径。界面到此就够了不需要花哨。3.2 把截图代码接进按钮CFileDialog 选路径并保存双击按钮VS 会生成一个以 OnBnClickedBtnShot 命名的消息处理函数。把下面这段写进去。这里把第 2 章的函数升级成了 MFC 类版本好处是 CClientDC、CBitmap 都是 RAII 封装函数退出时自动释放少写很多清理代码。// ScreenSnapDlg.cpp #include atlimage.h // CImage 依赖这个头文件 #include gdiplus.h // GDI 头文件CImage 内部会用到 #pragma comment(lib, gdiplus.lib) void CScreenSnapDlg::OnBnClickedBtnShot() { // 屏幕 DC用 CClientDC 构造 NULL 代表整个屏幕 CClientDC dcScreen(NULL); int cx GetSystemMetrics(SM_CXSCREEN); int cy GetSystemMetrics(SM_CYSCREEN); // 内存 DC 和兼容位图颜色格式和屏幕一致 CDC dcMem; dcMem.CreateCompatibleDC(dcScreen); CBitmap bmp; bmp.CreateCompatibleBitmap(dcScreen, cx, cy); CBitmap* pOld dcMem.SelectObject(bmp); // 复制像素从屏幕 (0,0) 取 cx*cy 大小的区域 dcMem.BitBlt(0, 0, cx, cy, dcScreen, 0, 0, SRCCOPY); // 让用户选保存路径过滤器同时支持 bmp 和 png CFileDialog dlg(FALSE, _T(bmp), _T(screen.bmp), OFN_OVERWRITEPROMPT, _T(BMP 文件 (*.bmp)|*.bmp|PNG 文件 (*.png)|*.png||), this); if (dlg.DoModal() ! IDOK) { dcMem.SelectObject(pOld); return; } CString strPath dlg.GetPathName(); // 把 CBitmap 包装成 CImageSave 之后再 Detach避免双重释放 CImage img; img.Attach((HBITMAP)bmp.GetSafeHandle()); HRESULT hr img.Save(strPath, Gdiplus::ImageFormatBMP); img.Detach(); // 还原 DC 里挂着的旧位图然后 CBitmap 析构时才会按正常逻辑释放 dcMem.SelectObject(pOld); if (SUCCEEDED(hr)) { SetDlgItemText(IDC_STATIC_INFO, strPath); } else { SetDlgItemText(IDC_STATIC_INFO, _T(保存失败检查目录权限)); } }CFileDialog 第一个参数传 FALSE 表示“另存为”对话框第二个参数是默认扩展名第三个是默认文件名过滤器里用竖线分隔多个格式。这里有个细节过滤器里写了 BMP 和 PNG 两种但 Save 时我却固定用了 ImageFormatBMP这会导致你选了 .png 后缀写出来的还是 BMP 内容。这算我自己留的一个小坑第四章会给出正确做法。这段代码的典型问题是如果路径不可写CImage::Save 会返回失败但不会告诉你具体原因。排查时优先检查目录是否存在以及是否有管理员权限。另外 GDI 在程序启动时必须初始化否则 CImage::Save 可能在特定环境下直接崩溃。在 InitInstance 里加上下面这段并在 ExitInstance 里反注册。// 在 InitInstance 函数顶部 Gdiplus::GdiplusStartupInput gdiplusStartupInput; ULONG_PTR gdiplusToken; Gdiplus::GdiplusStartup(gdiplusToken, gdiplusStartupInput, NULL);这段初始化代码属于“一次都不漏之后永远不用管”的黑匣子但如果漏掉问题会在用户机器上随机出现所以在避坑章的 5.1 之前先打上这个预防针。4. 格式和区域BMP/JPG/PNG 怎么选矩形区域怎么截截图拿到位图只是第一步真正决定这个工具好不好用的是两件事存成什么格式、截取哪块区域。格式影响文件体积和后续处理环节的兼容性区域截取则是屏幕工具从“能截图”变成“能工作”的分水岭。4.1 用 CImage 切换编码器保存体积与 Attach 的陷阱上一章留下了一个格式死角CImage::Save 的第二个参数不传会按文件扩展名推断格式传了固定编码器就和文件名无关。正确做法是根据用户选的扩展名动态决定编码器。实用写法是这样// 取扩展名并转小写注意 Right(4) 拿到的可能带点号 CString strExt strPath.Right(3).MakeLower(); HRESULT hr E_FAIL; if (strExt _T(png)) { hr img.Save(strPath, Gdiplus::ImageFormatPNG); } else if (strExt _T(jpg) || strExt _T(peg)) { hr img.Save(strPath, Gdiplus::ImageFormatJPEG); } else { hr img.Save(strPath, Gdiplus::ImageFormatBMP); }用右 3 个字符判断其实是偷懒因为 .jpg 取右三位是 jpg.png 取右三位是 png但对 .bmp 取右三位是 bmp正好都避开点号。这里如果你的文件名后缀是 .jpeg右三位是 peg也能被第二个分支接住。更严谨的做法是先用 CString 的 Find 找点号再截取但工具类项目里这个偷懒完全够用。BMP、JPG、PNG 的选择建议按下面这张表来定格式体积质量适用场景BMP最大未压缩无损临时中间文件、调试、格式转换源头JPG小压缩率高有损照片类画面、日志留痕、对体积敏感PNG中等无损压缩无损界面截图、按钮图、文档配图我自己的原则是界面截图一律 PNG因为文字和线条边缘经不起 JPG 的有损压缩只有抓拍摄像头画面或者连续帧时才考虑 JPG。另外这里有个不明显的坑CImage::Save 对 BMP 也是真的按 BMP 去写文件并不是所有格式都走 GDI 编码器所以初始化 GDI 永远是必需的不管选哪个格式。下面重点说 Attach 和 Detach。CImage 的 Attach 会把 HBITMAP 的所有权接管过来也就是说如果 Attach 之后不 DetachCImage 析构时会调用 DeleteObject 把这块位图删掉。而你的 CBitmap 对象析构时也会删一次同一个 HBITMAP 被删两次轻则崩溃重则影响进程里其他 GDI 对象。Save 之后立刻 Detach等于告诉 CImage“我用完了你不负责清理”。这个成对的习惯和内存分配要成对释放一样重要。4.2 按矩形和窗口截图BitBlt 源坐标的平移换算很多时候不需要全屏只需要某块区域或者某个窗口。区域截图的原理和全屏一模一样只是 BitBlt 里的四个坐标值从屏幕尺寸变成了矩形坐标。把 2.2 的函数加两个参数就够BOOL CaptureRectToBitmap(const RECT rcTarget, HBITMAP* phResult) { HDC hdcScreen GetDC(NULL); HDC hdcMem CreateCompatibleDC(hdcScreen); int nWidth rcTarget.right - rcTarget.left; int nHeight rcTarget.bottom - rcTarget.top; HBITMAP hbmNew CreateCompatibleBitmap(hdcScreen, nWidth, nHeight); HGDIOBJ hOld SelectObject(hdcMem, hbmNew); // 源坐标是 rcTarget.left/top目标坐标始终是 (0,0) BitBlt(hdcMem, 0, 0, nWidth, nHeight, hdcScreen, rcTarget.left, rcTarget.top, SRCCOPY); SelectObject(hdcMem, hOld); DeleteDC(hdcMem); ReleaseDC(NULL, hdcScreen); *phResult hbmNew; return TRUE; }这段代码里最容易错的就是把 rcTarget.left 和 rcTarget.top 填到目标坐标去。目标是内存 DC坐标系永远从 0 开始源是屏幕 DC坐标要按屏幕坐标系算。如果颠倒截出来的图会是一片偏移的黑区。另一个容易忽略的是多显示器场景副屏在主屏左边时rcTarget.left 会是负数。BitBlt 允许源坐标为负只要目标宽高是正数就行所以上面这段代码在多屏下也能工作前提是 rcTarget 用的是虚拟屏幕坐标系。窗口截图的落地路径是先用 GetWindowRect(hWnd, rc) 把某个窗口的屏幕矩形求出来再把这个 rc 丢给 CaptureRectToBitmap。这个做法对普通窗口有效但对被遮住的窗口只能截到遮在上面的内容因为 BitBlt 读的是屏幕最终呈现不是窗口内部状态。如果需要截被遮挡窗口的内容得换 PrintWindow这是另一个方向的问题。5. 避坑记录黑屏、DPI 缩放、GDI 泄漏、动态库缺失截屏功能看着只有几行代码真正在别人机器上跑起来翻车的都是下面这四类问题。每一条都是我见过不止一次的真实案例按“现象 → 原因 → 解决”的顺序写清楚你可以直接对照排查。5.1 截出来的图片整张是黑的或空白现象代码在开发机一切正常拷到某台机器上第一次截图成功之后截图全是黑块或者某些窗口区域是黑的但任务栏和桌面都正常。原因分三类。第一类是在服务程序或计划任务里调用 GetDC(NULL)那台“屏幕”根本不在交互桌面上没有像素可拷。第二类是某些显卡驱动开启了硬件加速覆盖层比如视频播放器、全屏游戏它们的画面不走 GDI 合成路径BitBlt 只能读到黑色。第三类是 GDI 没初始化CImage::Save 失败之后你以为截到了图实际得到的是一个空位图。解决服务场景不要用 GDI 截屏改用桌面复制 APIDXGI Desktop Duplication或者让程序跑在用户会话里视频区域截不下来属于技术边界GDI 方案解不了要么提示用户改成窗口截图模式。GDI 初始化问题排查思路很简单——在 InitInstance 里加启动代码如果加了还崩检查是不是在多线程环境里调用了 GDIGDI 的默认模式不适合在回调线程里直接使用。5.2 高分屏当道截图尺寸和位置对不上现象在 125% 或 150% 缩放的 Windows 上截出来的图比实际屏幕小一截或者只有左上角一块有内容其余是黑边。用 SetWindowPos 移动窗口时窗口的坐标和屏幕坐标也对不上。原因进程没有声明 DPI 感知时系统会做虚拟化缩放。GetSystemMetrics(SM_CXSCREEN) 返回的是虚拟分辨率比如 1920 物理像素在 125% 缩放下返回 1536。你用 1536 去创建兼容位图BitBlt 却从物理屏幕里拷 1536 个像素于是只覆盖了屏幕左上角区域。解决在 InitInstance 最前面在创建任何窗口之前调用 SetProcessDPIAware()让系统不要对这个进程做缩放模糊。老版本 Windows 上这个 API 存在但推荐做法是在应用程序清单里声明 dpiAware 为 true。VS 的 MFC 向导生成的项目默认不带这个声明所以每建一个工程都要手动加一次。加了之后GetSystemMetrics 返回的就是物理像素截屏区域和鼠标坐标才能一致。多屏且各屏缩放比例不同的时候还需要用 QueryDpiAwarenessContext 细算每个屏幕的缩放但先把进程级 DPI 感知做对能解决八成的错位问题。5.3 GDI 对象持续上涨DC 和位图成对创建、成对释放现象写第 2 章函数时每次调用都创建一个内存 DC 和位图。用任务管理器观察进程GDI 对象数每点一次截图按钮就涨几个关掉程序才回落。截几十次之后整个程序开始画不出控件文字甚至弹“创建 DC 失败”。原因每次调用内存 DC 和兼容位图各产生一个句柄但 DeleteDC 只删了 DC位图还被挂在 DC 的上下文里没删。或者反过来位图删了DC 还留着。GDI 对象不是内存泄漏那种慢慢涨它是直接撞到句柄上限Windows 对每个进程的 GDI 句柄默认上限是一万个撞上就是灾难。解决每次创建 DC之后必须 DeleteDC每次 SelectObject 换上新位图用完必须把旧位图选回去再删新位图。CClientDC 和 CBitmap 这类 RAII 类会帮你做一部分但前提是你不要手动持有裸句柄。用 CImage 时Attach 之后 Detach 也是同一件事确保位图最终由确切的一方释放。我做这个功能时习惯在按钮处理函数的开头和结尾各记一次 GetGuiResources(GetCurrentProcess(), GR_GDIOBJECTS)如果差值不是零就说明某个分支漏了释放Debug 版本里直接断言。5.4 换台机器跑不了MFC 动态库缺失和字符集设置现象程序在开发机运行正常把 Release 目录里的 exe 拷到同事电脑双击后弹窗提示“由于找不到 MFC140U.dll无法继续执行代码”或者更老一点提示 msvcp140.dll 缺失。原因VS 默认把 MFC 编译成共享 DLLexe 本身不包含 MFC 的实现代码运行时要到系统目录找对应版本的动态库。开发机装了 Visual Studio运行库齐了所以测不出问题干净机器上就原形毕露。解决项目属性 → 常规 → “MFC 的使用”改成“在静态库中使用 MFC”重新编译exe 体积会变大十几兆但目标机器不再需要额外安装运行库。代价是如果 MFC 有安全更新你需要重新编译发布。字符集方面静态链接时注意别用 ANSIMFC 静态库里 ANSI 和 Unicode 两套实现都有但混用容易遇到 _T 宏展开不一致导致的链接错误。这条是纯经验教训任何时候调试“为什么开发机疯了换机器就不行”先查运行库再查 DPI最后查权限按这个顺序能少走一半弯路。6. 进阶用法注册全局快捷键把截图变成一个按键做到这里你的 MFC 程序已经能点按钮截图并保存。要提高日常使用效率下一步就是把截图从“点按钮”升级成“按快捷键”并且让截图入口统一方便之后加定时连续截图。6.1 用 RegisterHotKey 实现全局快捷键MFC 对话框里注册全局快捷键要用 RegisterHotKey这个 API 不要求窗口处于前台只要注册成功系统就会把快捷键消息投递给指定窗口。在 OnInitDialog 里加::RegisterHotKey(m_hWnd, 0x1001, MOD_CONTROL | MOD_SHIFT, _T(A));第一个参数是接收消息的窗口句柄m_hWnd 在 OnInitDialog 里已经有效第二个参数 0x1001 是唯一 ID用来在消息处理时区分多个快捷键第三个参数是修饰键按位组合第四个参数是虚拟键码_T(A) 相当于 0x41。注册完还要在消息映射里接住 WM_HOTKEYBEGIN_MESSAGE_MAP(CScreenSnapDlg, CDialogEx) ON_MESSAGE(WM_HOTKEY, CScreenSnapDlg::OnHotKey) END_MESSAGE_MAP() LRESULT CScreenSnapDlg::OnHotKey(WPARAM wParam, LPARAM lParam) { if (wParam 0x1001) { // 和按钮共用同一个截图入口 OnBnClickedBtnShot(); } return 0; }这里有个细节RegisterHotKey 注册的是系统级快捷键如果和其他程序冲突会返回失败。所以我一般会检查返回值失败时在界面上提示“快捷键被占用”而不是让功能静默失效。对话框销毁时还要配套 UnregisterHotKey否则退出程序后快捷键可能残留。6.2 把截图动作收敛到同一个入口连续截图、定时截图这些需求最忌讳每个功能各写一份 BitBlt 代码。我习惯把从“取屏幕 DC”到“保存文件”的完整动作收敛成一个成员函数比如 CaptureAndSave(CString strPath, const RECT* pRect)。按钮处理函数、快捷键处理函数、定时器处理函数都只调它一个区别只在传参。这样以后想统一调整保存格式、加水印、写日志只改一处。定时连续截图只需要再加一个 SetTimer 和 OnTimer里面依然调同一个入口。这个习惯救过我很多次尤其是后期排查看“哪一次截图丢了”的时候单一入口能让你在日志里按时间线把每个动作串起来。这套 MFC/VS 截屏方案治好了我早年“换机器就跑不动”的焦虑也让我在碰到黑屏、DPI 这些玄学问题时不至于手足无措。代码都是老 API一点也不时髦但它稳。希望帮到你。本文还有配套的精品资源点击获取
网站建设高端定制企业官网
RELATED

相关资讯

更多精彩内容,欢迎继续阅读

较早相关资讯

最新相关资讯

SGLang HiCache 分层 KV 缓存实战:RadixAttention 与 write policy 调优 2026/10/2 4:25:28

SGLang HiCache 分层 KV 缓存实战:RadixAttention 与 write policy 调优

1. 从一次推理延迟抖动说起:HiCache 到底在解决什么如果你最近在折腾本地大模型推理,尤其是用 SGLang 跑 Qwen 系列或者 DeepSeek 系列,大概率会遇到一个很微妙的现象:首 token 延迟(TTFT)在长对话、多轮会…

阅读更多 →
腾讯 WorkBuddy 实战指南:AI Agent 工作台从安装到 Skill 开发全解析 2026/10/2 4:25:28

腾讯 WorkBuddy 实战指南:AI Agent 工作台从安装到 Skill 开发全解析

1. 为什么我要认真写这篇 WorkBuddy 实战指南WorkBuddy 这个产品刚出来的时候,我其实没太当回事。腾讯系的产品,名字里带个 Buddy,听起来像是又一个套壳的对话助手。直到有次团队里一个非技术岗的同事,用它在半小时内把一份三十多…

阅读更多 →
LLM工程化落地七层控制体系:从Prompt到监控的实战方法论 2026/10/2 4:25:28

LLM工程化落地七层控制体系:从Prompt到监控的实战方法论

1. 这不是“学LLM”,而是“用LLM”——从工具视角重新理解大模型的实操逻辑你点开这篇内容,大概率不是想听“LLM是Large Language Model的缩写”这种教科书定义。你真正卡住的地方,可能是:明明调通了API,但返回结果忽好…

阅读更多 →
腾讯 WorkBuddy 实战笔记:models.json 配置与 Skill 机制避坑指南 2026/10/2 4:25:28

腾讯 WorkBuddy 实战笔记:models.json 配置与 Skill 机制避坑指南

1. 为什么我要认真写一份 WorkBuddy 实战笔记WorkBuddy 这个腾讯 AI 工作台刚出来的时候,我其实没太当回事。市面上挂着“AI 工作台”名头的产品太多了,大多是把聊天框换个皮,再塞几个预设提示词就敢叫 Agent。真正让我改变看法,是…

阅读更多 →
Scikit-learn入门:从环境搭建到训练第一个机器学习模型 2026/10/2 4:25:28

Scikit-learn入门:从环境搭建到训练第一个机器学习模型

新手必看:用Scikit-learn跑通第一个机器学习模型,从环境搭建到结果解读先聊点实在的。很多朋友刚接触机器学习,看了不少理论,什么梯度下降、过拟合、交叉验证,名词都认识,但真让自己动手建一个模型&#xf…

阅读更多 →
腾讯WorkBuddy AI Agent工作台:从安装配置到Skill任务编排实战指南 2026/10/2 4:25:21

腾讯WorkBuddy AI Agent工作台:从安装配置到Skill任务编排实战指南

1. 为什么我要认真聊聊 WorkBuddy 这个工具第一次听说 WorkBuddy 是在一个技术群里,有人甩了张截图,说腾讯出了个 AI 工作台,能把日常那些重复性的活儿全接过去。当时我的第一反应是:又一个套壳产品吧?毕竟这两年打着“…

阅读更多 →

今日资讯

本周资讯

本月资讯

看完文章仍有疑问?

联系尧图顾问,获取一对一建站咨询

立即免费咨询 📞 400-888-8888
📞 ✉