npm global 不应该被当成系统级包管理器
npm global 最大的问题，是它看起来像一个系统级包管理器，但实际上只是某个 Node 版本附带的“局部全局”。随着越来越多 AI CLI 工具通过 npm 分发，这个长期被忽视的问题会变得越来越明显。 过去这个问题不太显眼，是因为 npm global 主要用来安装前端开发工具，例如 TypeScript、ESLint、Prettier、Vite 或某些脚手架。即使这些工具随着 Node 版本切换而消失，通常也只是影响某个项目的开发环境，而且很多团队本来就会把它们放进项目的 devDependencies 里。 但现在情况变了。Claude Code、Gemini CLI、Codex CLI、各种 MCP server、agent framework、部署工具和 AI 应用脚手架，越来越多都选择通过 npm 发布。它们不再只是“项目开发依赖”，而是逐渐变成开发者每天使用的个人工作台入口。这个时候，如果继续把 npm global 当成长期稳定的全局 CLI 管理方式，问题就会被放大。 npm global 的“全局”是有条件的npm install -g 里的 globa...
基于大模型 API 构建上层应用的知识地图
如果已经拿到了可以直接调用的大模型 API，那么真正值得投入的研究重点，就从“如何训练模型”切换成了“如何把模型变成可靠、可控、可评测、可持续迭代的应用系统”。 这篇文章整理一份面向 AI 应用层的知识地图。它的边界很明确：不讨论预训练、模型架构创新、GPU kernel、分布式训练这些底层问题，而是假设模型能力已经以 API 的形式交付给我们。我们要研究的是：如何在模型 API 之上，构建能解决真实问题的产品和系统。 从逻辑上看，应用层可以按“从输入到结果、从单次调用到持续运营”的顺序划分为七个领域：Context Engineering、Knowledge Grounding / RAG、Tool Use、Workflow / Agent、Evaluation、Observability、AI Product Design。 1. Context Engineering：让模型理解正确任务**Context Engineering 是所有大模型应用的第一层能力。**当我们不能修改模型参数时，能控制的就是上下文：任务说明、系统约束、用户输入、历史对话、外部资...
ReAct、CoT 与 Tool-Use：从想清楚到做清楚
ReAct、CoT 与 Tool-Use：从想清楚到做清楚一句话：CoT 解决”想清楚”，Tool-Use 解决”查清楚/做清楚”，ReAct 把两者编成闭环——推理指导行动，行动反馈推理。这是现代 AI Agent 的核心范式。 三个概念，一张关系图在 AI 工程的语境里，有三个高频概念总是纠缠在一起： Chain-of-Thought (CoT)：让模型把推理过程一步步写出来 Tool-Use：让模型调用外部工具获取信息或执行操作 ReAct：把推理和行动交织成循环 它们不是三个并列的方案，而是递进的能力层次： 1纯 LLM（只靠记忆）→ 加 CoT（会想了）→ 加 Tool-Use（有手了）→ ReAct（脑手协调） 下面逐个讲透。 一、Chain-of-Thought：让模型把过程写出来核心思想让模型在给出最终答案前，把中间推理步骤显式地生成出来。就像老师要求学生”写解题过程，不能只写答案”。 直观对比不用 CoT： Q: 商店有 23 个苹果，卖了 15 个，又进货 8 个，现在有几个？A: 16 用 CoT： Q: 商店有 23 个苹果，卖了...
为什么"把聊天记录全塞进去"是 LLM 产品最常见的自杀行为
为什么”把聊天记录全塞进去”是 LLM 产品最常见的自杀行为 一句话结论：无限追加聊天历史不是”给模型的上下文越多越好”——它会在四个维度同时崩盘：硬天花板、成本爆炸、延迟倍增、信号被噪声淹没。成熟的 AI 产品用分层上下文架构替代全量追加。核心思路不是”给更多信息”，而是”给每个 token 更值钱的信息”。 四个同时发作的问题直觉很自然：用户聊了 30 轮，把每一轮都喂给模型，答案不就更有上下文了吗？ 前十轮没问题。二十轮依然连贯。到四十轮左右，事情开始崩了： 回复变慢 成本悄然攀升 模型开始跑偏——重提二十分钟前的话题，跟刚说的矛盾，或者执着于某个过时信息 这不是偶发 bug，是系统性必然。原因有四层，层层叠加。 第一层：context window 是硬天花板GPT-4o 上限 128K token，Claude 200K，Gemini 2.5 Pro 1M。 数字看着大，但一个健谈用户在单次长会话里就能烧掉 100K。撞到天花板时你只有两个选择：从头截断（丢掉关键早期上下文），或者拒绝继续。两个都是烂体验。 第二层：Token 成本随每轮累积——沉默的杀手就...
推理模型如何"思考"：一切都只是 Token
推理模型如何”思考”：一切都只是 Token一句话：推理模型没有做任何新事情。所谓的”先想再答”，就是把中间推理步骤写成 token 藏在后台不让用户看见。思考 token 和输出 token 由完全相同的前向传播产生——没有第二个模型，没有独立推理引擎，没有模式开关。一切都只是 token。 思考 Token 并不特殊首先要刻进脑子里的认知：思考 token 和输出 token 是完全相同的机制生成的。 都是同一个 autoregressive 过程——模型根据前面所有 token 预测下一个 token，把它塞回上下文，重复。前向传播是同一个，权重是同一套。不存在什么”推理副脑”、辅助模块、神经网络里的推理模式开关。 让思考 token 显得不同的唯一原因：谁看得见它们。标准聊天里，模型生成的每一个 token 都直接推给用户。推理模型里，模型先生成一段”思考”token——这些 token 在内部消费，用来影响后续 token 的预测——但不对最终输出暴露。只有思考块之后的 token 才送到用户眼前。 这意味着推理不是”在基座模型之上额外加的能力”。它是基座模型本来就有...
深入理解 LLM 函数调用：模型不会"决定"用工具
深入理解 LLM 函数调用：模型不会”决定”用工具一句话：函数调用不是模型内部”觉醒”的能力，而是推理层在 prompt 里塞了一套工具描述后，模型遵循协议输出的结构化 token。本质上是 prompt engineering 的延伸——只不过发生在 API 层而非用户输入层。 模型不会”觉得该用工具了”关于函数调用最大的误解，就是以为模型内部有个”我该调工具了”的判断机制。没有。模型就是一个 autoregressive token 生成器——给定前文，预测下一个 token。仅此而已。 函数调用是推理层启用的能力，需要两个显式条件同时满足： 请求里必须带 tools 参数——一个函数定义数组，每个函数包含名称、自然语言描述和 JSON Schema 参数规格。 tool_choice 参数必须允许调用。默认值是 "auto"——模型在它觉得合适时可能返回工具调用。你也可以设为 "none"（绝不下手）、"required"（必须下手），或锁定到某个具体函数。 当 tool_choice 为 "aut...
LLM 解码策略：temperature、采样与 beam search，到底在选什么
LLM 解码策略：temperature、采样与 beam search，到底在选什么一句话：所有解码策略本质上只做一件事——从模型输出的概率分布里挑一个 token。区别只在于你用什么规则去挑，以及你要确定性还是要多样性。 基础管道：Logits → Softmax → 概率分布模型最后一层输出的是 logits——词汇表里每个 token 对应一个实数，有正有负，范围不受约束。这还不是概率。 把它变成概率靠的是 softmax： 1P(i) = exp(logit_i) / Σ exp(logit_j) 做完这一步，你手里就有了一个合法概率分布：每个 token 一个概率，全加起来等于 1。后续的 temperature、top-K、top-P、greedy decoding、beam search——全是在这个分布上做文章。要么改分布的形状，要么换挑选的规则。 Temperature：一个旋钮控制”脑洞程度”Temperature 是调起来最简单的参数。它在 softmax 之前动刀，把每个 logit 除以 T： 1P(i) = exp(logit_i / T) /...
多模态 AI 聊天的图像上传：从字节流到用户体验
多模态 AI 聊天的图像上传：从字节流到用户体验一句话：给 AI 聊天加上图片上传，不是往聊天气泡里塞个 <img> 标签就完事了。它是一条从客户端预处理直通模型 API 的工程管线——上传架构、数据格式、预处理、UX 打磨，每层都有坑，踩过才知道。 上传架构：为什么图片不该经过你的服务器用户选了一张图，这个文件总得想办法到达模型 API。最天真的做法是把所有东西都过一遍你的后端：前端上传到你服务器，你服务器再转发给模型。五个用户的时候没问题，规模化之后直接崩——图片上传吃带宽、占请求线程，你的 API 服务器瞬间变成奢华版文件代理。 正确的姿势是直传 OSS。 后端只管签发临时凭证（STS token 或预签名 URL），前端拿着凭证直接上传到对象存储。流程是这样的： 用户选图 → 前端调后端拿上传 token 后端返回一个短期预签名 URL（有效期按分钟计，绝不按小时） 前端直传 OSS，拿到永久图片 URL 这个 URL 被塞进模型 API 请求——字节流从头到尾没经过你的服务器 后端保持轻量，客户端代码里也不暴露长期密钥。安全边界清晰：临时凭证、服务端签...
Transformer 到底怎么生成文本：逐层拆解
Transformer 到底怎么生成文本：逐层拆解一句话：Transformer 推理就四个阶段——Attention（信息路由）→ FFN（知识存储）→ 层层堆叠（抽象升级）→ 解码（从向量到词）。一旦你把这四个阶段吃透，KV Cache 为什么吃内存、长上下文为什么贵、temperature 到底在调什么、模型为什么会产生幻觉、speculative decoding 怎么加速——这些工程决策突然就变得自然而然了。 阶段一：Attention——让每个 token “看到”其他所有 token一个 token 刚进入 Transformer 层的时候，它对周围的 token 一无所知。Attention 就是来解决这个问题的。 每个 token 通过三个学出来的权重矩阵做投影，产出三个向量： Q（Query，查询）： “我现在需要什么信息？”——当前 token 对历史的检索请求 K（Key，键）： “我这里有什么信息可查。”——每个 token 的索引条目 V（Value，值）： “这就是具体内容。”——被”关注”时实际传递出去的信息 当前 token 的 Q 去跟每...
从 Token 到 RAG：理解 AI Native 数据管道
从 Token 到 RAG：理解 AI Native 数据管道一句话：RAG 不是什么魔法，它只是在”大模型读不懂你的私有数据”这个问题上，搭了一条最务实的桥。这条桥由三块砖铺成——Token、Embedding、Vector Database。搞懂它们怎么连起来的、哪里会断，是每个做 AI 产品的工程师逃不掉的功课。 第一块砖：Token——模型看到的”文字”LLM 不读单词，也不读句子。它只认 token 序列。 输入是 token 序列，输出也是 token 序列。模型一辈子只干一件事：给定一串 token，猜下一个最可能的 token，然后把这个 token 拼到序列末尾，再猜下一个，循环往复。 一个 token 可能是一个完整单词（”apple”），也可能是子词碎片（”un” + “believ” + “able”），甚至只是单个字符——全看分词器怎么切。这是整个管道里最底层的粒度，一切从这里开始。 第二块砖：Embedding——把含义变成数字机器不认文字，只认数字。这是根本矛盾。 Embedding 模型做的事：把一段文本映射成一个固定长度的浮点数向量。Open...