HANKMO.COM

Token是怎么来的：大模型计费和上下文管理的底层逻辑 大家好，我是极客老墨。 上一篇讲大模型工作原理时，Token 出现了很多次。这一篇专门把它讲透——不是因为概念难，而是因为它的每一个细节都直接影响你的 API 账单和代码行为。 成本超支、上下文莫名截断、多轮对话"失忆"——这些新手最常踩的坑，根子都在 Token 上。 一、Token 是什么：BPE 分词不是按字切 Token(中文翻译定义为“词元”) 是大模型处理文本的最小单位。但很多人对它有一个根本性的误解：Token 不等于字，不等于词，更不等于汉字。 主流大模型（包括 DeepSeek）使用的分词算法叫 BPE（Byte-Pair Encoding，字节对编码）。它的逻辑是：从字节出发，统计语料中最高频的字节对，反复合并，最终形成一个包含几万到十几万个"子词单元"的词表。 结果就是：Token 的边界是由训练语料的统计规律决定的，不是人为规定的。 # 英文示例（DeepSeek tokenizer） "developer" → ["developer"] # 1 token（高频词，整词入表） "tokenization" → ["token", "ization"] # 2 tokens（低频长词，拆分） "DeepSeek" → ["Deep", "Seek"] # 2 tokens（专有名词） # 中文示例 "大模型" → ["大", "模型"] # 2 tokens（"模型"是高频词组） "量子纠缠" → ["量", "子", "纠", "缠"] # 4 tokens（低频，逐字） "API" → ["API"] # 1 token 中英文的核心差异： ...

大模型是怎么炼成的：从训练数据到你手里的 API 大家好，我是极客老墨。 你有没有想过：ChatGPT、DeepSeek，这些大模型是怎么"造"出来的？ 很多人用了大半年 AI，依然不知道答案。他们知道模型很强，但不知道强从哪来；知道调 temperature 能改变风格，但不知道为什么。这种"只会开车、不知道发动机"的状态，限制了你对 AI 能力边界的判断，也限制了你设计 AI 应用的想象力。 这篇文章要做一件事：把大模型从"一堆原始数据"到"你手里的 API"这条完整链路讲清楚。 普通人能看懂，开发者能用上。 第一段：模型是怎么被造出来的 大模型的诞生，分四个阶段，缺一不可。 flowchart TD A["海量原始数据 网页/书籍/代码/论文"] --> B["预训练 Next Token Prediction"] B --> C["指令微调 SFT 教模型听懂人话"] C --> D["强化学习对齐 RLHF 教模型说对的话"] D --> E["量化 & 部署 压缩上线"] E --> F["你调用的 API"] 阶段一：预训练——从"0"开始读书 预训练是整个大模型能力的根基。这个阶段，模型什么都不知道，就像一张白纸。 研究团队先从互联网抓取海量文本的网页数据、Wikipedia、GitHub 代码库、arXiv 论文、书籍……DeepSeek-V3 的预训练数据量超过 14.8 万亿个 Token。这是什么概念？一个人一天读 8 小时，读完大概需要 2 万年。 有了数据，然后呢？训练任务出乎意料地简单：给你前面的词，猜下一个词。 输入：「人工智能是」 目标：预测「一」 输入：「人工智能是一」 目标：预测「种」 输入：「人工智能是一种」 目标：预测「模拟」 就这么一个任务，重复几十亿次。模型每猜错一次，就调整内部参数，让下次猜得准一点——这个调整过程叫反向传播（Backpropagation）。 ...

大模型能干什么：六大核心应用场景拆解 大家好，我是极客老墨。 有个问题我被问过很多次：大模型除了聊天，还能干什么？ 这个问题背后藏着一个更深的困惑：我学大模型开发，到底能做出什么东西？值不值得投入时间？ 值得。但前提是你得搞清楚它的边界——哪些场景是大模型真正擅长的，哪些是现在能落地的，哪些是看着很美但开发成本极高的。 这篇文章拆解六个核心场景：文生文、文生图、文生视频、语音交互、数字人、智能问答。每个场景我会讲清楚技术本质是什么、真实能力边界在哪里、开发者能拿它做什么，以及一个 Go 开发者该从哪里切入。 不堆概念，只讲和开发直接相关的部分。 一、文生文：最成熟，也最容易被低估 技术本质 文生文（Text-to-Text）是所有大模型能力的基础层。给定一段文本输入，模型输出文本结果——翻译、摘要、续写、代码生成、问答、分类、抽取，本质都是这个范式。 它的核心机制是自回归生成（Autoregressive Generation）：模型逐个 token 预测，每次预测都以前面所有内容为条件。这意味着它天然支持任意长度的输出，也意味着它的"思考"过程是线性的、不可并行的。 能力边界 文生文做得好的事：结构化生成、风格迁移、代码辅助、信息抽取、分类标注。 文生文目前还做不好的事：精确计算（数学运算容易出错）、实时数据（知识截止限制）、高度确定性任务（每次输出有随机性）。 2026 年之后，推理模型（DeepSeek-R1、OpenAI o3）的出现让数学和逻辑推理能力大幅提升——但这是专门设计了长思维链的推理模型，普通对话模型仍然存在上述限制。 开发者能做什么 用户需求 → Prompt → 大模型 → 文本输出 → 业务逻辑处理 这是最简单的链路，也是 90% 的大模型应用的骨架。几个典型落地方向： 代码辅助：接入 IDE 插件，或者独立的代码问答服务。输入自然语言描述，输出对应语言的实现代码。DeepSeek-V3 在代码生成上性价比极高，是首选。 文档处理：上传合同、技术文档、会议记录，提取关键信息、生成摘要、回答问题。结合 RAG（后面的模块会详细讲），可以大幅减少幻觉。 内容生成：营销文案、邮件草稿、产品描述、SEO 内容。注意：大模型不是完美的，高质量内容生成必须加人工审核环节。 结构化抽取：从非结构化文本中提取 JSON 格式的数据，配合 Function Calling 或 Structured Output，可以直接对接业务数据库。 老墨说： 文生文不只是"聊天"，它是一个可编程的文本处理引擎。你用自然语言定义规则，它按规则处理任意输入——这是一种新的编程范式，比你写正则表达式和 if-else 强大得多，也灵活得多。 二、文生图：创意的民主化 技术本质 文生图（Text-to-Image）的主流技术路线是扩散模型（Diffusion Model）——从随机噪声出发，在文本描述的引导下，迭代去噪，最终生成图像。代表模型有 Stable Diffusion、DALL·E 3、Midjourney、Flux。 这和文生文用的技术栈完全不同。大多数大模型 API 平台（OpenAI、智谱、火山引擎）会把文生图单独封装成一个 API 端点，你不需要了解扩散过程，直接调用即可。 ...

大模型发展史：从一篇论文到改变世界 大家好，我是极客老墨。 有人问过我：学大模型开发，需要搞清楚历史吗？ 我的答案是：不需要全记，但有几个节点绕不过去。就像你不需要知道 Linux 每一个版本的变化，但如果你不知道 1991 年 Linus 为什么会写内核、不知道 GPL 协议的来历，你就很难理解为什么今天的开源生态长成了现在这个样子。 大模型的历史也是一样的道理。 这篇文章不是"时间轴背诵手册"，而是帮你搞清楚：每一个关键节点留下了什么技术遗产，以及这些遗产如何层层叠加，构成了你今天调用 API 时那个"黑盒"里的底层逻辑。 第一阶段：奠基期（2017–2019）——骨架确立，两条路线分叉 在 2017 年之前，AI 语言模型靠 RNN 和 LSTM 驱动。这两种架构有一个致命弱点：序列化处理——它们必须一个词一个词地读，前面没读完，后面没法算。这就导致了两个问题：长文本里的前后关联容易丢失，训练也难以并行，规模扩不上去。 这个局面被一篇论文打破了。 Transformer 诞生（2017 年 6 月） Google Brain 团队的 Ashish Vaswani 等人发表了 Attention Is All You Need，提出了 Transformer 架构，核心是"自注意力机制（Self-Attention）"。 它的革命性在哪里？一句话：让模型在处理一个词的时候，能同时看到整个句子里所有词的关联权重，而不是只看"左边刚读过的"。 并且这个计算是可以并行的——GPU 的算力第一次被大模型充分用上了。 Transformer 由 Encoder（理解）和 Decoder（生成）两部分组成，可以灵活组合。这个设计直接决定了后来大模型的两条技术路线。 老墨说： Transformer 是大模型的底层骨架，今天你用的 GPT、Claude、DeepSeek，技术根基都在这篇 2017 年的论文里。你可以不懂数学，但"自注意力"这个词要知道它是干什么的。 两条路线分叉（2018 年） Transformer 出来之后，OpenAI 和 Google 各自选了一条路。 GPT-1（2018 年 6 月，OpenAI）：只用 Decoder，专注文本生成。1.17 亿参数，在约 5GB 的书籍语料上预训练，验证了"预训练+微调"在生成任务上的可行性。能力有限，但确立了 GPT 系列"纯 Decoder 生成式"的路线。 ...

什么是大模型：开发者必须搞清楚的核心概念 大家好，我是极客老墨。 2022 年 11 月 30 日，OpenAI 悄悄上线了一个叫 ChatGPT 的产品。没有发布会，没有大规模营销，结果五天内注册用户突破 100 万，两个月后破 1 亿——成为史上用户增长最快的消费级应用。 这一年，我第一次在终端里用 API 让它写了段 Go 代码，代码是对的。我盯着屏幕看了很久，心里有个声音说：这东西不一样。 这篇文章的目标很简单：搞清楚大模型是什么，从哪来，现在有哪些主流选择，以及作为开发者你需要知道哪些核心概念。不涉及数学，不涉及训练原理，只讲和开发直接相关的部分。 大模型是什么 大模型（Large Language Model，LLM），本质是基于海量文本数据训练出来的神经网络模型，通过学习语言的统计规律，获得了理解和生成自然语言的能力。核心参数规模通常在百亿级以上——这也是"大"的由来。 一个直白的类比：你可以把大模型想象成一个读过人类几乎所有书籍、论文、代码、对话记录的人。它没有真正的"理解"，但它见过的模式足够多，所以当你给它一段输入，它能预测出"接下来最合理的内容是什么"——而这个"预测"往往精准得令人惊讶。 对开发者来说，有三件事最重要： 调用方式：你不需要自己训练模型。通过 API，几行代码就能接入 GPT、DeepSeek、Claude 等顶级模型的能力 核心价值：大模型把自然语言变成了一种编程接口——你用人话描述需求，它输出结果，极大降低了 AI 功能的开发门槛 能力边界：参数规模决定了模型的能力上限，但训练数据质量、微调策略同样关键。参数多不等于万能 老墨说： 别被"大"字唬住。大模型对开发者的意义就一句话：用 API 调用别人训好的模型，你只管写业务逻辑。 大模型从哪来：关键发展节点 大模型的演进不需要全记，但有几个节点值得了解——它们直接决定了今天你能用到的技术基础。 2017 年：Transformer 诞生 Google 发表了论文 Attention Is All You Need，提出了 Transformer 架构。这篇论文是今天几乎所有大模型的技术根基。在它之前，语言模型用 RNN（循环神经网络），慢且难以并行训练；Transformer 引入了自注意力机制，让模型能同时关注序列中所有位置的关联，训练效率和能力都大幅提升。 2020 年：GPT-3 开启规模时代 OpenAI 发布 GPT-3（1750 亿参数），首次证明了"规模即能力"——只要参数足够大、数据足够多，模型会涌现出意想不到的新能力。这一发现改变了整个 AI 研究方向。 2022 年：ChatGPT 引爆应用层 ...

Rust 学习笔记 25：高级特性 (Advanced Features) “With great power comes great responsibility.” – Uncle Ben (actually unsafe block) Rust 通常强制执行内存安全规则，但有时我们需要绕过它们（比如操作硬件、与 C 交互）。这时，Unsafe Rust 就派上用场了。 此外，Rust 的 Trait 和类型系统还有很多高级用法，能让你的代码更具表现力。 1. Unsafe Rust unsafe 关键字给我们开启了 5 种超能力： 解引用裸指针 (Raw Pointers)。 调用不安全的函数/方法（包括 FFI）。 访问或修改可变静态变量 (Mutable Static Variables)。 实现不安全 Trait (unsafe trait)。 访问 union 的字段。 裸指针： 1let mut num = 5; 2let r1 = &num as *const i32; 3let r2 = &mut num as *mut i32; 4 5unsafe { 6 println!("r1 is: {}", *r1); 7} 编译器不会检查裸指针是否有效、是否为空、是否遵守所有权规则。你自己要负责。 ...

那一夜我删掉了所有的旧代码：一个17年老兵的失业、反思与AI突围 [!quote] 这是一个最坏的时代，也是一个最好的时代。对技术人来说，这更是一个“不得不变”的时代。 大家好，我是极客老墨。 很久没有更新公众号了。后台有很多老朋友私信问我：“老墨，咋没更新了？”“老墨，是不是转行卖保险去了？” 其实，过去这段时间，我不是在偷懒，我是在“服刑”。生活给我判了一场名为“中年失业”加“创业连续失败”的重刑。 最近，收到很多朋友失业的消息，说实话，我并不意外，大势所趋罢了。对于他们的遭遇，我深有体会，所以，我必须静下心来，深深的思考。 今天，我坐在书房里，看着窗外凌晨三点的灯火，心境比任何时候都要平静。我想把这段时间我掉过的坑、流过的汗，以及那点死里逃生的思考，摊开了跟兄弟们聊聊。 如果你也正感到前路模糊，希望你能耐心看完，这或许是我们这代技术人最后的一次集体突围。 一、 7个项目，0个跑通：我被AI浪潮撞断了腰 去年，是我从业17年来最疯狂、最辛苦，也是最惨烈的一年。 2025年，我和几个相识多年的技术老兵，仍然使用着传统的技术，做移动端App、做后端系统、做交易平台，我们每天只睡4-5个小时，写代码写到眼睛看屏幕都是重影。 结果，我们忽视了正在如潮水般涌动的AI浪潮，却收到了现实给我们的7记响亮的耳光。 这7个项目，一个都没有跑出来，没有任何盈利。 我们这群有着大厂经验的人，习惯了“高并发、高可用、高扩展”。当我们还在花两个月时间打磨那套完美的分布式微服务架构时，外面的年轻人用几行 Python 脚本接上 GPT-4 的 API，配合一个简单的网页模板，一周就上线了，而且用户反馈比我们还好。 我们发现，AI 时代的逻辑变了：“完美的工程实现”在“快速的价值反馈”面前，一文不值。 最让我们绝望的是，我们引以为傲的技术壁垒，在不断进化的模型面前，显得如此苍白。原本我们需要写几百行逻辑去判断的自然语言意图，DeepSeek 一句系统提示词就搞定了。 我们这群写了十几年代码的人，突然发现自己变得“多余”了。那种感觉，就像是你精心维护了十几年的分布式系统，突然遭遇了全区域的掉电，所有的冗余、所有的备份，在绝对的力量面前，毫无意义。 那一刻，我正式失业了。 二、 围墙里的中年人：房贷、孩子与消失的护城河 失业后的前两个月，我陷入了前所未有的焦虑。 这种焦虑除了那种“没钱花”的恐慌，更多的是一种“自我价值彻底归零”的虚无。 每天早上醒来，脑子里跳出来的不是代码逻辑，而是三个冰冷的数字： 房贷：每个月几大千的月供，像闹钟一样精准，从不缺席。你看着银行卡余额一点点减少，那种倒计时的声音会在深夜里无限放大。 教育：孩子上辅导班、兴趣班的费用。在这个内卷的时代，你不敢停。你看着孩子纯真的笑脸，心里想的却是：“爸爸下个月还能不能供得起你的钢琴课？” 医疗：父母渐渐老去。那份体检报告上的每一个红点，都意味着一笔不确定的支出。 人到中年，上有老，下有小。失业这两个字，对我们这种人来说，不是“休息”，是“断供”。 我曾试图更新一下我的简历。但我看着简历上那些“精通分布式架构”、“深度理解 JVM”、“Go 高性能编程”，突然觉得这些东西好陌生。在 AI 时代，当一个初级程序员配合 Cursor 就能写出八成正确的业务代码时，我这些积累了十几年的经验，还能卖出原来的价格吗？ 我把自己关在房间里，关掉了所有的博客，清空了那些凌乱的技术文章。看着那些曾经为了涨粉写的“分布式架构文章”、“精通设计模式”、“Go语言精简教程”、“Python 入门教程”，我觉得它们简直就是时代的垃圾。 技术人的现实是：在 AI 时代，技术本身的“实现能力”正在贬值，而“解决问题的能力”正在升值。 但我当时没想明白。我感到生活处处都是围墙。左边是 40 岁的红线，右边是 AI 的替代，头顶是生活的重压。我感觉自己像是一个在旧时代战场上磨刀的铁匠，突然发现对面的人已经开始用无人机了。 我问自己：老墨，你除了写代码，还会什么？如果明天代码消失了，你还能在这个社会上生存吗？我当时发现，还真TM不能！除了写代码，我发现自己竟然似乎一无是处！ 三、 觉醒：在传统行业的泥坑里，寻找AI的落脚点 焦虑到极致的时候，整个人都是萎靡的状态。我知道这样下去不行，于是我开始约朋友们喝茶、聊天，一起探讨新的方向。 一段时间后，我做了一个决定：停下来，走出去。 我不去卷那些花哨的 AI 概念了，不去跟那群 20 出头的年轻人卷提示词、卷用法了，也不再去跟风某某Agent了。我开始回访那些以前在甲方工作的朋友，去探访那些传统的行业：保险、医疗、电商、小外贸、甚至社区服务。 我发现了一个惊人的事实：虽然 AI 已经人人都耳熟能详，但真正能够用 AI 来解决实际问题的传统行业，极少。 他们缺乏的，从来都不是那些花里胡哨的AI概念，而是用AI来帮他们把那些每日重复的工作从流程中省掉的落地方案。 ...

大模型 API 核心参数：调对了事半功倍，调错了钱打水漂 大家好，我是极客老墨。 我刚开始接大模型 API 时，最容易犯的毛病就是把所有问题都往 prompt 上推。输出不稳定，先改 prompt；JSON 解析失败，继续改 prompt；账单涨了，还想着是不是 prompt 不够精简。改到最后，prompt 越写越长，接口却还是像没装仪表盘的车，能跑，但不知道哪里在烧钱、哪里在抖。 这篇不讲玄学调参。我就按一个常见场景来讲：做一个客服工单摘要接口。 输入是一段用户和客服的对话，输出要稳定变成这样的 JSON： 1{ 2 "summary": "用户咨询退款到账时间，客服告知预计 3-5 个工作日", 3 "category": "refund", 4 "risk_level": "low", 5 "next_action": "等待退款到账" 6} 这个接口看着简单，真接到业务里会遇到四个问题： 有时输出一段自然语言，JSON 解析直接炸。 有时写到一半停了，字段缺一截。 有时同一条工单跑两次，分类不一致。 有时为了一个简单摘要开了推理模式，成本和延迟都上去了。 这些问题不全是 prompt 的锅。后来我才把 API 参数当成方向盘、油门、刹车和仪表盘来看：prompt 负责告诉模型要去哪，参数负责控制它怎么走、走多远、花多少钱、异常时怎么停下来。 本文以 DeepSeek API 为主线。DeepSeek 当前官方文档里，Chat Completions 的模型 ID 是 deepseek-v4-flash 和 deepseek-v4-pro；deepseek-chat、deepseek-reasoner 仍可兼容，但官方已说明将于 2026/07/24 弃用。下面的参数口径按本文撰写时查阅的官方文档编写，后续以官方最新文档为准。 model：我会先选一辆够用的车 客服工单摘要这类任务，第一版通常不需要最强模型。它不是奥数题，也不是复杂代码审查，核心是稳定抽取、分类、压缩信息。 DeepSeek 当前官方模型表里有两个主模型： model 适合什么 deepseek-v4-flash 延迟、成本更敏感的通用任务，比如摘要、分类、提取、普通问答 deepseek-v4-pro 更复杂的推理、规划、工具调用、代码分析 官方还保留了两个兼容别名： deepseek-chat：对应 deepseek-v4-flash 的非 thinking 模式。 deepseek-reasoner：对应 deepseek-v4-flash 的 thinking 模式。 这里我会先做一个保守判断：能用 deepseek-v4-flash 跑稳，就先不上 deepseek-v4-pro；能关 thinking 跑稳，就先不开 thinking。 ...

用 AI Skills 武装你的写作流程，从此告别重复劳动 每次让 AI 帮我写技术文章，我都得重新交代一遍：“你是一个有 20 年经验的工程师，语言要接地气，开头要有钩子，结尾要总结，不要废话……” 打完这段话，文章还没开始写，我已经累了。 这就是我开始研究 Agent Skills 的起点。研究完之后，我只想说：早该有这东西了。 一、什么是 Agent Skills？ 2025 年 12 月 18 日，Anthropic 把 Agent Skills 作为一个开放标准发布出来，规范地址在 agentskills.io。OpenAI Codex、GitHub Copilot、VS Code 等主流平台随后跟进支持。 官方文档对 Skills 的定义是： Skills are reusable, filesystem-based resources that provide Claude with domain-specific expertise: workflows, context, and best practices that transform general-purpose agents into specialists. 翻译成人话：Skill 是一个文件夹。里面放着你对 AI 的"专项培训材料"。当 AI 遇到匹配的任务时，它会自动加载这个文件夹里的内容，按照你的规范工作——不用你每次都重新解释。 用一个生活比喻：你雇了一位新助理，第一次你花了两个小时教她公司的排版规范、写作风格、邮件模板。从第二次起，你只需要说"按老规矩来"，她就能做对。Skill 就是那份"老规矩"的电子版。 老墨说： Skill 解决的核心问题是重复交代——把每次对话都要说的上下文、规范、工作流程，封装成一个可复用的模块。 ...

大家好，我是极客老墨。 作为一名常年泡在 Linux 终端里的“老兵”，我发现很多刚入行的小伙伴都有个习惯：只要系统慢了、CPU 飙升了，第一反应就是敲个 top。 说实话，每次看到那灰扑扑、死气沉沉的 top 界面，我都感觉像是在看 1970 年代的黑白电视。虽然它也能干活，但找个进程要靠眼力，杀个进程要背 PID，操作起来真的能让人抓狂。 今天，咱们给你的工具箱升个级。我会分享两款我用了多年的终端监控神器：一款是实用主义者的首选 htop，另一款则是颜值党和仪表盘迷的最爱 btop。 为什么我们要彻底抛弃 top？ 如果把 top 比作一辆手动挡的老破车，那 htop 和 btop 就是带自动泊车和全景天窗的特斯拉。 视觉疲劳：top 全是黑白数字，CPU 核心多的时候，那一串 %Cpu 数字看一眼都能吐。 交互反人类：你想杀个进程？得先记住它的 PID，退出 top（或在 top 里按 k），再手动输入 PID，再输入信号强度。这在紧急排查问题时，简直是浪费生命。 信息密度低：默认不显示进程树、不显示网络 IO、不显示磁盘负载，你得来回切换命令。 htop：实用主义者的“瑞士军刀” htop 是 top 的直系增强版。如果你追求稳定、快速且能解决 90% 的运维问题，它是你的不二之选。 为什么老墨天天在用它？ 彩色直观：CPU、内存、Swap 用颜色条（彩色进度条）表示，系统紧不紧张，扫一眼进度条的颜色就心里有数了。 支持鼠标（重点！）：你可以直接用鼠标点击列标题排序，或者点击某个进程。是的，在终端里也能像在 Windows 任务管理器里一样“指哪打哪”。 交互式进程管理：看到某个异常进程，不用背 PID。直接光标移过去，按 F9 发送 kill 信号，按 F7/F8 调整优先级（Nice 值）。 进程树视图：按 F5 开启，清晰地看到谁是父进程，谁是子进程（比如一堆 php-fpm 进程），方便精准打击。 安装与快捷键 MacOS: brew install htop Ubuntu/Debian: sudo apt install htop CentOS/RHEL: sudo yum install htop 快捷键 功能 (老墨口诀) F3 / F4 搜索和过滤（找进程飞快） F5 树形显示（谁生的谁一清二楚） F6 排序（按内存排还是按 CPU 排？） F9 杀进程（直接发送信号，干脆利落） u 只看某个用户（只盯着那个坑爹的业务账号） btop：监控界的“视觉盛宴” 如果说 htop 是为了干活，那 btop 就是为了“爽”。它是目前终端监控领域的天花板，GitHub 上 30k+ 的 Star 不是吹出来的。 ...