AI新手入门指南：从零开始学AI工具

Claude Code 的 command not found / claude is not recognized 几乎都只是安装目录（~/.local/bin）没在 PATH 里，二进制其实存在。本文系统梳理安装方式与位置、修复 PATH、多重安装冲突、npm 的 EACCES 权限错误（不要 sudo，改用原生）、Windows 用错 shell 的陷阱，并按 claude doctor → which -a claude → 加 PATH → 删除多余版本 → 原生重装的顺序给出排查工作流。

在公司电脑上或通过 VPN 使用 Claude Code 时，出现 “Unable to connect to API”、“ECONNREFUSED”、“SSL certificate verification failed” 或 “fetch failed” 而连不上——这些都是网络错误，意味着请求根本没到达 Anthropic 服务器（api.anthropic.com），与认证（401/403）、服务器过载（529/500）和速率限制（429）不同。本文整理企业网络的三大阻断点（未配置的代理、替换证书的 TLS 检查代理、阻断域名的防火墙）以及 DNS/VPN/Docker，并涵盖代理设置（HTTPS_PROXY、NODE_EXTRA_CA_CERTS、绝不使用 NODE_TLS_REJECT_UNAUTHORIZED=0）、防火墙放行域名与排查工作流——全部基于官方信息。

Claude Code 的「API Error: 529 Overloaded」和「500 Internal server error」都是服务器端事件，并非你的请求或设置有误，也不消耗配额。Claude Code 在显示提示前已以指数退避自动重试最多 10 次。本文说明等待重试、用 /model 切换、查看状态页、/feedback 反馈等应对，以及它们与 429、usage limit 的区别和面向开发者的设计要点。

Claude Code 的「Claude usage limit reached」不是错误，而是 Pro/Max 订阅使用量限制的设计方式。限制分为「滚动的5小时窗口」与「每周窗口」两层，Max 还另有仅针对 Opus 的每周额度。本文梳理什么在吃掉额度（模型选择影响最大）、撞到上限那一刻的5种对策、如何用 /usage 查看剩余量，以及订阅限制与 API 限制的根本区别。

Claude Code / API 的「Prompt is too long」不是 bug，而是你的输入（会话历史＋文件＋工具定义等）超出了模型的上下文窗口。它既不是 usage limit 额度，也不是 max_tokens 输出截断。本文梳理什么在填满窗口、最快的5步对策（/compact、/clear、subagent、削减固定负载、1M 模型）、200K 与 1M 窗口的区别，以及如何与容易混淆的错误区分开。

Claude Code 的 MCP 服务器连接错误可分为三大类：本地子进程启动失败、远程认证、配置文件错误，而 /mcp 的状态会告诉你属于哪一类。本文梳理状态读法、按原因分类的对策、Windows 上的 npx 陷阱（用 cmd /c 包裹），以及从状态到 stderr 再到独立启动的排查工作流。

在 Claude Code 长时间作业时，屏幕上突然涌出「court」加上原始的 invoke / parameter 标签，工具调用却没有执行——这是 Claude（Opus 4.8/4.7 系列）在生成工具调用控制 token 时把它生成坏掉的模型侧缺陷，并非你的环境或命令的失误。harness 以 fail-closed 方式拒绝坏掉的调用，因此不会误执行命令；真正棘手的是坏块残留历史后模型会模仿它、产生「连锁」。本文基于官方文档与实际 Issue，梳理其机制、两大成因、三个常见误解，以及用户与开发者各自的对策（核心铁律：失误两次就撤到新会话 /clear）。

某天 ChatGPT 或 Claude 账号突然用不了了：2026年账号停用（封号）与警告的报告正在增多，可怕的是即使没有恶意，也可能因一不小心违反条款而被封号。本文基于已公开的使用政策与报道，整理了为了不在 OpenAI（ChatGPT、Codex）和 Anthropic（Claude、Claude Code）上丢失账号需要知道的内容（不是规避检测的窍门，而是如何遵守条款）。两家共通的5个触发点：禁止内容、越狱，未经授权的自动化与爬取，共享或转卖账号/API 密钥，可疑访问模式，以及支付不一致与欺诈。2026年最大的陷阱：把 Claude 个人套餐（Free/Pro/Max）的 OAuth 令牌用在官方应用以外的产品（含 Agent SDK 这类外壳）会违反 Consumer ToS，曾引发大规模封号潮；正确做法是用 API（按量计费）运行应用与 Agent，个人套餐则当作官方应用对话。文章还给出7点防范清单与申诉指引：警告是纠正的机会，多数可继续使用；轻微违规可申诉，严重违规通常永久停用且难以恢复。用正确的套餐，做正确的用途，诚实地使用。

把庞大的 AI 从头重新训练太贵，但你又想为自己稍作调整；LoRA（Low-Rank Adaptation）通过冻结原始模型、只训练一个极小的附加部件（适配器），把可训练参数削减约 90%，实现了这个愿望。LoRA 让微调大幅更便宜、更快，并在 Stable Diffusion 等图像生成中作为添加角色或画风的小文件极受欢迎。本文用补丁的比喻来讲解。LoRA 是参数高效微调（PEFT）的代表：把庞大的原始权重冻结，在每一层插入一个小的附加矩阵，只训练它（W = W0 + BA，其中 W0 被冻结，BA 是新增的那一小部分）。它建立在这样一个发现之上：调整 AI 并不需要大的改动，低秩就足够。优势：可训练参数减少约 90%（在 GPT-3 规模下据报道少 10,000x）、更省 GPU 内存（约少 3x）、训练更快更便宜、合并适配器后不增加推理延迟、更不易过拟合。它最大的优势是适配器可更换：保留一个通用底座，按用途即时更换小巧的（几 MB）LoRA 文件（客户支持、公司语气、某个特定角色）。很多人第一次接触 LoRA 是在图像生成中，Stable Diffusion 上学会了角色、画风或主体的 LoRA 被广泛共享（添加画风、学会角色、轻巧易分享）。QLoRA 结合量化，在 4-bit 底座之上训练 LoRA，比标准 LoRA 省约 4x 内存，能在消费级 GPU（有时是 CPU）上微调庞大模型，且精度损失极小。相比全量微调（训练所有权重），LoRA 在训练的权重、成本、产出和适用场景上都不同；对大多数工作，LoRA 就足够。底座保持原样，风味小幅调出。文中数值引自公开资料，仅供参考。

一个庞大的 70B 模型不再需要数据中心的 GPU 机架，而能在家里一台游戏 PC 上运行，这要归功于量化——它降低模型权重的数值精度，从而大幅缩小体积和内存。模型蒸馏是把知识转移到另一个更小的模型，而量化则是让同一个模型变轻。本文用照片压缩的比喻来讲解。量化把以 FP16/FP32 小数存储的权重替换成 INT8（8 位）或 INT4（4 位）整数，减少每个权重的字节数（FP32=4、INT8=1、INT4=0.5）；就像把 RAW 照片压成 JPEG，你牺牲一点点精度换来大幅减重，令人惊讶的是放弃的东西竟然这么少。在内存上，4-bit 约为 FP16 的四分之一：70B 模型从 ~140GB 降到 ~35GB，8B 模型在 4-bit 下约 ~4.5-5GB，能塞进中端 8GB VRAM 的 GPU 用于本地运行（LLM 的民主化）。在精度上，INT8 几乎无损，INT4 在一般问答/常识类任务上退化不到 4%，但在数学、代码生成和高难度推理上损失更明显（表现为困惑度小幅上升），所以要按任务选位宽。主要方法：GPTQ（精确 4-bit 的先驱）、AWQ（保护最重要的约 ~1% 权重，往往精度高 1-2% 且更快）、GGUF（llama.cpp/Ollama 格式，Q2_K-Q8_0，CPU+GPU 混合，用于本地）和 QLoRA（4-bit 基础加 LoRA，在消费级 GPU 上微调）。它与蒸馏（转移到另一个小模型）和微调（增添任务知识）不同，三者通常组合使用（量化蒸馏后的模型；在量化基础上微调）。开始时，用 Ollama 一条命令跑一个 GGUF 模型，按 VRAM 选 Q4/Q8，代码或精确计算避开 INT4。多数主流模型已以量化形式发布，下载即用。保留聪明，只去掉重量。文中数字引用自公开资料，仅供方向参考。

庞大而高性能的 AI 聪明但又重又贵；模型蒸馏（知识蒸馏）通过把大教师模型的知识转移到小学生模型来解决这一问题，以十分之一的体积和速度保留教师 95% 以上的性能。本文用教师与学生的比喻讲解。关键在于软标签：普通训练只教"答案是猫"（硬标签），蒸馏则传递教师"90% 猫、8% 狗、2% 狐狸"这样的整个概率分布，其"犹豫程度"蕴含丰富信息；温度参数会软化概率以显现微妙关系（真实例子：GPT-4o mini 据说从 GPT-4o 蒸馏而来）。好处：又快又便宜、约 10 倍更紧凑且保留 95% 以上性能、可在边缘端运行、擅长用途专精。两种方式：白盒（完全访问权重和内部表示，转移更深，用于自家或 OSS 模型）与黑盒（只能看到输出/API 响应，把别家 API 当教师可能违反条款）。它与量化（压缩同一模型的权重精度）、微调（对现有模型针对任务追加训练）不同——蒸馏是把知识转移到另一个小模型，三者可组合。法律与 ToS 现实是 2026 年的重大议题：技术正当，但 OpenAI、Anthropic、Mistral、xAI 等都设有反蒸馏条款，禁止用输出打造竞争模型，因此用受限 API 蒸馏竞品可能违反条款。OpenAI 诉 DeepSeek 的纠纷（OpenAI 主张疑似 DeepSeek 相关账号绕过限制获取输出用于蒸馏，而 DeepSeek 条款据称允许蒸馏其输出）表明评估取决于适用谁的 API 条款，且 Claude Fable 5/Mythos 5 据报道会限制被判定为蒸馏的作业。要诀：用自家或已授权 OSS 模型当教师、用商用 API 前确认反蒸馏条款，并判断用途是否属于"开发竞争模型"。聪明靠大模型、运营靠小模型——但选谁当教师会改变技术与法律结果。数据引用自公开资料，仅供参考。

在《如何搭建多智能体系统》中我们说过，增加智能体前先为每次交接装上度量；支撑这种度量的技术正是 AI 可观测性。它让你看清 LLM 与智能体在生产环境中究竟在做什么，从而能回溯到原因。与普通应用监控的决定性区别在于：AI 可以返回 200 OK、50ms 却仍自信地产生幻觉，所以多数 AI 故障是质量故障而非基础设施故障。可观测性基于三大支柱：trace、metrics 与 logs。可观测性展示"发生了什么"，评估（evals）则衡量答案好不好，两者需成套使用。本文梳理关键指标与 LangSmith、Langfuse、Arize Phoenix、MLflow、AgentOps、OpenTelemetry 等主要工具，并讲解如何起步以及为何对智能体至关重要。