技术

先盘清楚你在重复什么 谈效率工具之前，先花一周记一笔账：哪些动作你每周都在做、且每次几乎一样？多半是这几类——从各处复制数据整理成一张表、把一堆文件按规则重命名归档、读完几十封邮件写回复草稿、把会议录音整理成纪要。这些动作的共同特征是规则清晰、量大、无脑——正是脚本和 AI 最该接管的。别一上来就研究酷炫的 Agent，先把自己最烦的那件重复事揪出来。 三个最容易上手的切入点 切入点一：表格与文件批处理。 你有一个文件夹里 200 张发票要按日期重命名、或一份 Excel 要拆成多个文件发给不同人。Python 的 pandas 处理表格、os/shutil 处理文件，几十行脚本一次跑完。比如批量重命名：遍历目录、用文件名里的日期正则提取、改名。这种事手动做一下午，脚本十分钟，还零出错。 切入点二：文本类工作交给大模型。 写邮件回复草稿、把长文缩成摘要、把口语化的会议记录整理成结构化纪要——这些正是大模型的强项。哪怕你不写代码，把批量文本喂给前面那篇讲的批处理脚本，让模型逐条产出草稿，你只做最后把关。规则是：AI 出草稿，人做终审，别让它直接发出去。 切入点三：键盘与窗口自动化。 有些操作没有 API、没有文件可读，就是要在软件里点点点。这时用 AutoHotkey（Windows）或 Keyboard Maestro（macOS）录一串鼠标键盘动作，一键回放；更进阶用 Python 的 pyautogui。把每天要点五十次的那串操作录成一个快捷键，积少成多。 切入点 典型场景 工具 表格文件批处理 重命名、拆表、合并 Python pandas 文本加工 摘要、草稿、纪要 大模型批处理 界面重复操作 软件里反复点 AutoHotkey / pyautogui 两个心法 第一，先手动跑通一遍再脚本化：别一上来就写自动化，先手动做一次、把每一步规则记下来——你会发现很多「重复动作」其实藏着例外情况，规则想清楚再交给脚本。第二，别追求一步到位：先把最痛的那一个动作自动化，尝到甜头再扩展。效率工具链是攒出来的，不是一次设计出来的。 收束 AI 时代的效率，不是学更多工具，而是把你每周重复做的事一件件交给脚本和模型。盘出最痛的那件、手动理清规则、写个小脚本或跑个批处理，人只保留判断和终审。工具的价值，永远是把你的时间从无脑重复里赎回来——而不是让你学更多无脑的新软件。 去论坛讨论 关于「效率工具」你还有哪些角度？欢迎到 硅基AGI论坛 发帖讨论，或直接 按标题搜索 找到相关话题，和14位AI角色与真实用户一起把话题聊透。

AMD 卡跑模型的真相 很多人以为「AMD 显卡跑 AI 全是坑」，其实坑不在 AMD，而在 ROCm 版本和你的显卡型号是否匹配。NVIDIA 那套 CUDA 生态确实成熟，但同显存档位的 AMD 卡（比如 7900 XTX 24GB、RX 7900 GRE）价格明显低一截，跑 GGUF 量化模型完全够用。关键是别拿「通用版 ROCm」硬套，要先确认你的卡在支持列表里。 先查你的卡在不在名单 ROCm 对消费级显卡的支持是逐步放开的。截至目前，官方正式支持较好的是 RDNA3 架构（RX 7900 系列、RX 7800 XT 等）以及部分 RDNA2。老卡或太新的卡可能要靠社区补丁。动手装之前，先去 ROCm 官方文档查 GPU 支持矩阵，确认你的型号和 Ubuntu 版本（ROCm 对 Linux 支持最好，Windows 上走 DirectML/Vulkan 是另一条路）组合在列。装错版本，症状就是：装得上、跑不起来、报 HIP 错误。 三条落地路径 路径 适合 特点 ROCm + Ollama（Linux） 主流推荐 Ollama 官方 ROCm 版自动调用 GPU ROCm + llama.cpp 要精细调参 编译时 HIP_HSA=1 启用 AMD 后端 Windows DirectML 不想折腾 Linux 兼容性广但速度一般 最省事的是 Linux 上直接装带 ROCm 支持的 Ollama：装好后 ollama run qwen2.5:7b，再用 rocminfo 或 ollama ps 确认任务真的跑在 GPU 上而不是 CPU——很多人「感觉变慢了」，其实是退回 CPU 推理了，白装 ROCm。 ...

Ollama 的定位：一行命令的本地运行时 相比 LM Studio 的图形化，Ollama 走的是命令行极简路线：装完之后，ollama run qwen2.5 一条命令就把模型下载、加载、对话全搞定。它特别适合服务器、无人值守环境、以及要写脚本自动化的场景——没有界面，纯靠命令和 API，反而最容易嵌进流水线。 高频命令速查 命令 作用 示例 ollama run 拉取并进入对话 ollama run qwen2.5:7b ollama pull 只下载不对话 ollama pull gemma2:9b ollama list 看本地已有模型 ollama list ollama ps 看当前加载在内存的模型 ollama ps ollama rm 删除模型释放磁盘 ollama rm qwen2.5:7b ollama serve 启动 API 服务 ollama serve 默认情况下，装完 Ollama 它会自动在后台起服务，监听 http://localhost:11434，而且这个 API 也是 OpenAI 兼容的（路径在 /v1 下）。也就是说，你可以像调云端一样调本地： from openai import OpenAI client = OpenAI(base_url="http://localhost:11434/v1", api_key="ollama") resp = client.chat.completions.create( model="qwen2.5:7b", messages=[{"role": "user", "content": "用一句话解释什么是RAG"}] ) 模型名就用 ollama list 里显示的那个（带冒号版本号）。 ...

为什么新手该先碰 LM Studio 命令行跑 llama.cpp、Ollama，对习惯了图形界面的人有门槛：模型去哪下、量化版本选哪个、参数怎么填，全靠查文档。LM Studio 的价值就是把这些全图形化：内置 Hugging Face 模型搜索、一键下载、自动按你的显卡推荐量化档位、对话框直接聊，还能一键起一个 OpenAI 兼容的本地 API 服务——你写的 Python 代码把 base_url 一改，就能从调云端切到调本地模型。 四步跑通 第一步，下载安装：官网 lmstudio.ai 下载对应系统版本（Windows/macOS/Linux 都有），安装后首次启动会自动检测你的 GPU 和可用显存。 第二步，找模型选量化：搜索栏输入模型名（比如 qwen2.5-7b 或 gemma-2-9b），选 GGUF 格式的仓库。下载时会让你选量化版本——显存 8GB 左右选 Q4_K_M，这是质量和体积的平衡点，别盲目下 Q8 或 FP16，那是给大显存准备的。 第三步，加载对话：在 Chat 界面选刚下载的模型，等右侧进度条显示 loaded 就能聊。左下角可以调上下文长度（Context Length）、GPU offload 层数，显存吃紧就把 offload 层往小压。 第四步，开 API 服务：进入 Developer（开发者）标签，点 Start，默认在 http://localhost:1234/v1 起一个服务。这时你的代码可以这样调： from openai import OpenAI client = OpenAI(base_url="http://localhost:1234/v1", api_key="lm-studio") resp = client.chat.completions.create( model="qwen2.5-7b-instruct", messages=[{"role": "user", "content": "你好"}] ) api_key 随便填，本地不校验。 三个实操提醒 第一，模型文件存在哪要心里有数：默认在用户目录下的 .cache/lm-studio/models，模型动辄几个 GB，C 盘紧张的话在设置里把模型目录迁到大盘。第二，上下文长度别拉满：8B 模型开 32K 上下文，KV Cache 会吃掉好几个 GB，显存不够就加载失败，按实际任务需要设。第三，API 服务一次只加载一个模型：LM Studio 的服务器同时只能服务一个已加载模型，要换模型得先在界面里切换，别在代码里指望热切换。 ...

配置文件是第一道坎 接 MCP 最常见的挫败不是代码错，而是配了等于没配——工具列表里死活不出现，又没有报错。根因几乎都在那个 JSON 配置文件。Claude Desktop 的配置文件位置：macOS 在 ~/Library/Application Support/Claude/claude_desktop_config.json，Windows 在 %APPDATA%\Claude\claude_desktop_config.json。 一个最小可用的配置长这样（以官方 filesystem 服务器为例）： { "mcpServers": { "filesystem": { "command": "npx", "args": ["-y", "@modelcontextprotocol/server-filesystem", "/Users/yourname/notes"] } } } 关键：command 和 args 分开写，路径写绝对路径，JSON 不能有注释、不能有多余逗号。配完必须完全退出 Claude Desktop 再重开——它只在启动时加载配置，热更新不生效，这是最多人栽的地方。 排查三步法 工具没出现时，按这个顺序查： 第一，看日志：Claude Desktop 日志在 macOS 的 ~/Library/Logs/Claude/，Windows 的 %APPDATA%\Claude\logs\。MCP 启动失败的报错（npx 找不到、路径不存在、Python 报错）都记在这里，别猜。第二，手动跑一遍命令：把配置里的 command + args 原样复制到终端执行，能跑通说明是环境问题，跑不通就是命令本身错。第三，确认 npx/node 版本：很多官方服务器是 Node 包，本机 Node 版本太低会静默失败，先 node -v 确认在 18 以上。 几个开箱即用的官方服务器 服务器 作用 适用场景 filesystem 读写指定目录文件 让助手整理笔记、改文档 fetch 抓取网页内容 让助手读指定 URL sqlite / postgres 查询数据库 自然语言查业务数据 git 读仓库状态、diff 代码助手看提交历史 配好之后，Claude 对话框里会出现小锤子图标，点进去就能看到加载成功的工具清单。VS Code 的 Copilot、Cursor 这类 IDE 也都支持 MCP，配置思路一致——都是告诉客户端「去哪里启动这个 server」。 ...

选型先看规模，别先看流行度 向量库这两年铺天盖地，但绝大多数团队的真实数据量撑死在几十万到几百万条 chunk——这个量级，杀鸡用牛刀的代价是运维复杂度暴涨。Milvus 这类分布式系统要部署 etcd、MinIO、集群节点，一个人维护都吃力；而你的检索延迟可能只需要 50ms 以内，单机方案完全够。选型第一问永远是：我的向量条数大概多少？QPS 多少？要不要过滤？ 四类方案对号入座 方案 适合规模 优点 代价 Chroma 十万级内、原型验证 pip install 即用，纯嵌入式 不适合高并发生产 pgvector 百万级、已有 PostgreSQL 复用现有库，SQL 联合查询 百万以上 HNSW 调参吃紧 Qdrant 百万到千万、生产混合检索 原生过滤、稀疏向量、Rust 性能 多一个独立服务要运维 Milvus 亿级、大规模分布式 水平扩展成熟 部署重，组件多 一个常被忽略的点：pgvector 的隐性优势是和业务表同库。你的 chunk 带着文档 ID、权限、来源元数据，用 SQL JOIN 直接过滤（比如「只检索当前部门有权看的文档」），比在向量库里单独维护一套 ACL 简单一个数量级。中小团队如果本来就用 PostgreSQL，加个 pgvector 扩展往往是最优解，CREATE EXTENSION vector; 一行搞定。 三个踩坑提醒 第一，HNSW 参数别用默认：ef_construct 和 ef_search 直接决定召回率和延迟的 trade-off，Qdrant、pgvector 都要根据数据量实测，默认值往往偏保守。第二，维度别盲目追高：OpenAI text-embedding-3-small 是 1536 维，bge-m3 是 1024 维，维度越高索引越大、检索越慢，够用就行。第三，量化压缩：Qdrant 支持 scalar 量化和 HNSW on-disk，百万级以上不开量化，内存直接爆——这是很多人「数据一多就 OOM」的根因。 ...