第一次接触大模型微调时，很容易被一串缩写绕晕：CPT、SFT、LoRA、QLoRA、DPO、PPO、GRPO……它们看起来像一排互相竞争的“微调方法”，其实很多并不在同一个维度上。
先记住这篇文章的核心地图：CPT、SFT、DPO、PPO、GRPO 描述“用什么训练信号、想让模型学会什么”；全参数微调、LoRA、QLoRA 描述“哪些参数参与更新、以什么方式更新”。 两条轴可以组合，不是非此即彼。
下文会按“要不要微调 → 训练目标 → 参数更新方式 → 项目选型与评估”的顺序展开。先说结论：微调不是给模型补一份随时更新的知识库，也不是越复杂越好。很多需求用提示词或 RAG 更直接；只有当问题确实需要改变模型稳定的行为模式，而且手头有合适的数据和评估方法时，微调才值得投入。
一、什么是微调？它能解决什么问题？大模型预训练完成后，已经具备通用的语言和任务能力。微调（fine-tuning）是在已有模型基础上继续训练，让它在特定数据、任务或行为要求上更贴合目标。
可以把预训练想成打下通用基础，把微调想成针对岗位继续训练。但这个类比有一个重要边界：微调并不保证原有能力完全保留。 训练数据太窄 ...
很多人第一次看到 Transformer 的 Q、K、V，都会被一串矩阵和公式劝退。其实先记住一个直觉就够了：每个 Token 都会生成一份“我想找什么”（Q）、一份“我有什么特征”（K），以及一份“我能提供什么内容”（V）。
模型用 Q 和其他 Token 的 K 计算相关程度，再按照这个相关程度汇总它们的 V。下面就沿着“文字 → 向量 → QKV → 注意力 → 新表示”这条路，把它一步步拆开。
一、先用一个例子理解 Q、K、V想象你在公司遇到一个问题：“谁能帮我优化数据库查询？”
Q（Query，查询）：你当前想寻找的信息，也就是“我需要数据库优化方面的帮助”。
K（Key，键）：每位同事身上便于匹配的特征，例如“熟悉数据库”“擅长前端”。
V（Value，值）：同事真正能提供的经验和内容。
你用问题去匹配每个人的特征，匹配度越高，就越多地参考对方的经验。注意力机制做的事情很像这样：对一个 Token 来说，它会查看当前允许关注的其他 Token，并根据匹配分数混合它们的信息。
这个类比帮助理解 Q、K、V 的分工，但不要把它们当成模型能读懂的中文标签。真实的 Q、K、V ...
当所有人都在讨论”用哪个 Agent 框架”时，真正站在潮头的编码智能体产品，几乎清一色选择了裸写循环。这不是巧合，而是一场值得深挖的架构哲学分歧。
一、一个反直觉的事实如果你在 2025 年之后接触过 AI 编程工具，大概率听说过这几个名字：Claude Code（Anthropic 官方 CLI）、Codex CLI（OpenAI 官方 CLI）、OpenCode（开源新秀）。它们是目前最炙手可热的一批编码智能体（Coding Agent）。
一个很容易想到的问题是：这些产品是用什么框架搭建的？LangChain？LangGraph？CrewAI？
答案出人意料——一个都没用。它们全部是基于模型厂商原生 API 自研的 Agent 循环。而且不只这三家：Aider、Cline、Gemini CLI、Goose、Pi……你能叫得上名字的主流编码智能体，几乎清一色走上了”无框架、裸写循环”的路线。
为什么？这篇文章试着把这件事讲透。
二、先破除一个误解：Agent 到底是什么在讨论框架之前，先对齐一个认知。很多人被复杂的框架术语（Agent 类、Executor、Graph Nod ...
最开始部署 New API 时，更新一次代码就要登录服务器、停容器、拉新代码、重新构建，再把服务启动起来。偶尔改个小功能，前后折腾几分钟不算什么；线上已经有人在用时，这几分钟就不太好接受了。
我想要的不是一套看起来很复杂的发布平台，而是一个足够稳妥的流程：代码放到自己的仓库，准备好版本后点一下构建，服务器自动启动新版本，确认没问题再把流量切过去；新版本不正常时，能够尽快切回旧版本。
最后落地的是一套小而实用的方案：Gitee 保存代码，Gitee Go 负责流水线，Docker 镜像放在镜像仓库，运行环境是另一家云厂商的 Linux 服务器，Nginx 负责入口切换。服务器不需要和流水线在同一家云上。
图 1：一次发布从代码到线上请求的完整链路。
先把几个概念分开这次最容易绕进去的地方，是把“源码在哪里”“镜像放在哪里”和“服务跑在哪里”当成了一件事。其实它们可以完全分开：
位置
负责什么
这次的选择
代码仓库
保存 Dockerfile、源码和流水线配置
Gitee
构建服务
根据代码构建镜像
Gitee Go
镜像仓库
保存带版本号的 Docker 镜像 ...
2026 年 8 月 17 日，我看到 Tibo Sottiaux 在 X 上发了一组 Codex 配置：选择 gpt-5.6-sol，把上下文预算设为 100 万 Token，并在 90 万 Token 左右开始压缩旧历史。
帖子里有两个数字需要分开看。OpenAI 官方模型页列出的 GPT-5.6 Sol 上下文窗口是 1,050,000 Token，Tibo 写进 Codex 的预算是 1,000,000 Token。这组设置针对 Codex 客户端，不是 chatgpt.com 的设置，也不能直接套到其他 GPT-5.6 型号上。
Tibo 的原帖到底说了什么？我把原帖的核心部分截在下面，方便和配置逐项对照。Tibo 的公开账号简介写的是 “Codex & ChatGPT @OpenAI”。
图 1：Tibo 原帖的核心部分，完整内容和一次性 CLI 命令可以点开原帖查看。
帖子主要说了五件事：
GPT-5.6 Sol 的官方模型规格支持 1,050,000 Token 上下文窗口。
Codex 的默认上下文限制经过了性能和成本调优，默认不开到最大值。
用 ...
API 中转站是位于应用和模型厂商之间的一层 API 网关。你仍然通过 API Key 调用模型，但请求先到中转站，再由中转站转发给 OpenAI、Claude、Gemini、DeepSeek 等上游服务。中转站一般会比官方 API 便宜，这也是大多数人选择它的主要原因。
不过，不同中转站的可信度差别很大。有些商家会偷偷进行模型映射、在后台调整倍率，或者保留用户的请求内容。选择中转站不能只看低价，还要看模型、计费和隐私规则是否透明。
如果你只是想找一个便宜、透明的 OpenAI API 中转站，可以直接试试我自己使用并维护的 newapi.zahml.top：计费公开透明，部分模型最低 0.07 倍率，并且不会保存用户提交给模型的请求与对话内容。
API 中转站是什么？一次请求的链路可以简化为：
123456Codex / Claude Code / CursorCline / OpenCode / Roo Code ↓ API 中转站 ↓ OpenAI / Claude / Gemini 等模型
中转站负责校验 Ke ...
大模型的上下文缓存是什么？从底层原理到 GPT、Claude 的长对话策略使用 GPT、Claude 等大模型进行编程时，经常会出现这样的情况：刚开始对话只有几千 Token，经过多轮代码分析、工具调用和报错修复后，上下文很快就增长到几万甚至几十万 Token。
表面上看，模型每一轮都需要重新读取完整历史：
123456789系统提示词项目规范工具定义用户第一轮问题模型第一轮回答用户第二轮问题模型第二轮回答……当前问题
如果每次都按普通输入重新计算，长对话的费用和响应时间都会快速上升。Prompt Caching，也就是提示词缓存，正是为了解决这种重复计算问题。
不过，缓存并不意味着“历史对话免费”，也不意味着对话可以无限增长。理解它的底层逻辑后，才能真正用好长上下文。
缓存到底保存了什么？大模型收到一段输入后，并不是简单地把文字读进内存。
输入文本首先会被分成 Token，然后经过模型每一层的注意力计算。在这个过程中，模型会为已经处理过的 Token 生成 Key 和 Value 等中间表示，通常统称为 KV Cache。
可以把它理解为：
123456789原始输入 ↓Tok ...
2026 年国内外主流大模型 API 价格对比：GPT、Claude、Gemini、DeepSeek、Kimi、千问、MiniMax 怎么选？大模型能力越来越强，但不同厂商的计费方式也越来越复杂。
除了最基本的输入 Token 和输出 Token，现在还需要考虑：
缓存读取价格
缓存写入价格
长上下文阶梯价格
思考 Token
Batch 批处理折扣
Priority 优先服务
不同地区的部署价格
限时活动和分时折扣
本文整理了目前国内外主流厂商最新、最常用的模型，重点对比官方 API 价格、缓存价格、模型定位和适用场景。
本文价格统计截至 2026 年 7 月 21 日。除特别说明外，价格均为每 100 万 Token，即每 1M Tokens 的价格。本文比较的是厂商官方 API，不是 ChatGPT、Claude、Gemini 等网页会员订阅价格，也不包括第三方中转站加价。
一、先看懂大模型 API 是怎么收费的一次普通模型请求的费用，通常可以简化为：
1234请求费用 =输入 Token 数量 ÷ 1,000,000 × 输入单价+输出 Token 数量 ÷ 1,00 ...
深入理解 Java 并发中的 synchronized 与 volatile在 Java 并发编程中，synchronized 和 volatile 是两个非常基础但又非常容易混淆的关键字。很多人在刚开始学习并发时，会简单地认为它们都是“保证线程安全”的工具，但实际上二者解决的问题并不完全一样。
准确地说，volatile 主要解决的是可见性和有序性问题，而 synchronized 解决的是更完整的线程安全问题，包括原子性、可见性和有序性。理解这两个关键字的核心，不是死记硬背它们的语法，而是要先理解 Java 并发中到底会出现什么问题。
并发问题的本质在单线程程序中，代码通常按照我们写下的顺序执行，变量被修改之后，后面的代码马上就能看到这个修改。但在多线程环境下，情况就复杂得多。
现代计算机为了提升性能，并不是每次读写变量都直接访问主内存。CPU 有自己的缓存，线程执行时也可能把变量值保存到寄存器或工作内存中。这样带来的问题是：一个线程修改了共享变量，另一个线程不一定能马上看到。
例如下面这段代码：
1234567891011121314class Demo { p ...
一文讲透 Java 代理模式：从静态代理、JDK 动态代理到 Spring AOP代理模式是 Java 中非常重要的设计模式，也是理解 Spring AOP、Spring 事务、MyBatis Mapper 代理、RPC 远程调用等技术的基础。
很多人第一次看代理模式时，会觉得它很简单：不就是在真实对象外面包了一层吗？
这个理解没有错，但还不够深入。
代理模式真正重要的地方在于：它让我们可以在不修改原始业务代码的情况下，对方法调用过程进行增强。
比如原来的业务方法只负责保存用户：
123public void save(User user) { System.out.println("保存用户：" + user);}
现在我们想在保存用户之前打印日志，在保存用户之后统计耗时。如果直接修改业务代码，当然可以实现，但这样日志、耗时统计、事务、权限等非核心逻辑就会和业务代码混在一起。
代理模式解决的就是这个问题。
它的核心调用链是：
1调用方 -> 代理对象 -> 真实对象
调用方并不直接访问真实对象，而是先访问代理对象。代理对象 ...
