微调 vs RAG 这个问题，通常不是以问题的形式出现的，而是以一句结论出现：我们需要用自己的数据微调一个模型。这是企业 AI 里最昂贵的一句话之一，而且多数情况下是错的。不是永远错，但确实是多数。这个诉求背后几乎总是两件事之一：模型不了解我们的业务，或者模型回答的方式不是我们想要的。对第一件事，微调是一个糟糕的解法；对第二件事，微调是一个昂贵的解法。 在微调、RAG 和提示词之间做选择，并不是技术偏好问题。三者各自修复的是完全不同类别的问题，选错了，就会换来几个月的工程投入，而最初那句抱怨依然原封不动地摆在那里。 最省钱的一条规则： 如果问题是模型不知道某件事，用检索。如果问题是模型知道，但回答的风格、格式或长度不对，先改提示词，...
API开发
关于API开发的文章、指南和教程，为开发者和企业提供实用知识与技巧。面向开发者与技术团队。
进入 2026 年后，认真考虑迁移出 OpenAI 的团队明显变多了。开放权重模型在日常生产任务上的质量已经很难与头部模型区分开来，公开单价更低，而权重本身可以下载这一点，把与厂商的关系从依赖变成了选择。 但这并不意味着切换是免费的。API 调用本身几乎一模一样，真正要干活的是它周围的一切。本文讲清楚:哪些东西能原样搬过去,哪些会悄悄出问题,怎样设计一次有意义的比较,以及什么时候留在原地才是正确答案。 先把预期对齐。 换厂商就是换一个基础 URL、一个模型名、一份凭据。但要拿回同样的输出质量,那是以天为单位计的提示词工程。给一个范围明确的功能预留一到三周。任何假设可以即时替换的估算,都是乐观估算。 哪些东西能原样搬过去比你想的多,这...
大多数团队把 API 安全当成身份验证问题：发放令牌，在每一条路由上校验它，然后认为事情已经做完了。直到某天，一位测试人员把 URL 里的一个数字改掉，就读到了另一位客户的发票。 「已通过身份验证」和「已获得授权」之间的这道缝隙，正是绝大多数真实 API 泄露事件栖身的地方，而且它并不是扫描器能够稳定发现的那类问题。自动化工具看到一个有效的令牌和一个 200 响应，就报告成功。只有理解你业务规则的人，才会注意到那个响应里装的是别人的数据。 核心区别： 身份验证证明的是谁在调用。授权决定的是这个特定调用方可以看到什么、可以修改什么，而且它必须落实到每一个对象、每一次请求，并在数据层强制执行。几乎所有严重的 API 漏洞，都是第一件事运...
Kimi K3 API 带着一个不寻常的组合登场：接近前沿水平的基准成绩、激进的定价，以及可供下载的权重。Moonshot AI 于 2026 年 7 月 27 日公开了这些权重，使 K3 成为迄今公开发布的最大模型，也是这一规模的模型首次在原则上可以由你自己运行。 对于已经在向前沿供应商付费的团队来说，这提出的是一个务实问题，而非哲学问题：它在你的技术栈里有没有位置，把一部分流量迁过去究竟会改变什么。本文讨论成本测算、集成工作，以及那些公开数字无法转化为生产表现的环节。 简而言之： Kimi K3 的缓存未命中输入约为每百万 token 3 美元，缓存命中输入约为 0.30 美元，输出约为 15 美元，...
凡是按端点数量来估算定制 API 开发成本的人，几乎都会算错，而且通常差三倍。端点本身是整件事里最便宜的部分：十来个端点，只是读写你手里已经有的数据，对一位称职的后端开发者来说不过是两周的活。 真正花钱的，是把这些端点变成另一家公司愿意把生意押上去的东西所需要的一切：经得起安全评审的认证、让你日后还能改主意的版本管理、好到没人需要给你发邮件的文档，以及能告诉你哪个客户今天早上过得不顺的运维装置。有一个 API，和有一个别人依赖着做生意的 API，两者之间的那道落差，才是预算真正的去处。 价格区间速览: 只被你自己的应用调用的内部 API，通常花费 10,000 到 30,000 英镑。由少数几家指定集成方使用的合作伙伴 API，一般...
CRM 与 ERP 集成几乎总是被说成一个连接问题，而它几乎从来都不是连接问题。两套系统都有文档齐全的接口，也都有现成的连接器。真正的难处在于，销售和财务花了很多年，用两套不同的词汇去描述同一门生意，而集成正是这两套词汇被迫达成一致的地方。 当有人问起，一条被转化过两次的线索到底该生成一个客户还是两个，这个项目就不再是技术问题了。这样的对话，在三十个字段上重复一遍，才是真正的工作量。 先做这件事: 在挑选连接器或平台之前，先写下每一个共享字段由哪套系统拥有，以及两边同时被编辑时会发生什么。跳过这一步的集成建得很快，然后用好几年时间不断产出重复记录、对不上的合计数，以及没人敢信的报表。 为什么 CRM 与 ERP 的数据始终对不齐两套...
第三方 API 集成是商业软件里被低估得最稳定的一类工作。文档读起来清清楚楚，供应商提供了客户端库，于是有人说两周。六周之后，团队还在争论：当一个 webhook 为一笔已经退款的订单第二次送达时，究竟应该发生什么。 这道差距不是能力问题。真正的原因在于，一次集成里有意思的部分从来不是请求和响应，而是当对方系统做出它的文档从未描述过的行为时，随之而来的一切。它一定会这么做，因为它是一个活着的产品，属于一群有自己路线图、对你的发布计划不承担任何义务的人。 经验法则： 只从一个服务拉取数据的只读集成，通常需要一到三周。会写入事务的集成需要三到六周。两个都允许编辑的系统之间的双向同步需要六到十二周，而且永远不会真正结束，因为冲突解决是一个...
OpenAI API 集成在原型阶段看起来微不足道，一旦进入生产环境就会变成一个正经的工程项目。概念验证只需要一个下午：装上客户端库，粘贴一个密钥，发出一段提示词，拿回一个有用的答案。紧接着就有人问：请求超时了会怎样，客户把一份一百页的合同粘进输入框时这笔钱谁出，还有上个季度的账单数据是不是刚刚裹在系统提示词里离开了公司。 本文讲的是第二个阶段。它涵盖 API 在既有架构中该放在哪里，如何把公司数据圈住，如何在成本失控之前勒住它，以及如何判断这个功能到底有没有在起作用。面向的读者是已经有真实生产应用的团队，不是从空仓库起步的人。 一句话总结: 生产级的 OpenAI API 集成，大部分是普通的工程工作。把 API 放在你自己的后端...
对于计划在2026年部署大语言模型（LLM）的英国（UK）企业而言，确定真实的AI集成成本是关键的财务步骤。将AI集成到软件应用中可以实现客户服务流程的自动化、提高生产力并从对话数据中释放深度洞察。然而，为此类方案制定预算不仅仅是看开发者的每小时费率。具体而言，企业必须计算周期性Token费用、向量数据库托管以及提示词验证中间件的支出。本指南详细介绍了与定制AI集成相关的价格结构、API运行机制和部署成本。 API计费警告： 请务必在服务商控制面板（如 OpenAI 或 Anthropic）中配置硬性消费限额。如果代码循环或用户请求触发了无限递归调用，跳过此步骤将使您的企业面临巨额的账单风险。 核心要点： 您的总成本取决于Token...
降低 LLM 延迟是构建响应迅速的 AI 应用的工程师面临的最关键挑战之一。虽然大型语言模型（LLM）的能力持续增强，但它们逐 token 的生成方式会给最终用户带来令人沮丧的瓶颈，而漫长的等待时间会直接导致参与度下降和应用流失。因此，优化推理管线的速度是开发者的一项核心要求。本指南概述了如何配置提示词缓存、实现响应流式传输、构建边缘网络路由，以及使用无服务器配置来削减处理延迟。 性能指标提示： 在测量 API 延迟时，请将首个 Token 时间（TTFT）与整体生成速度区分开来。较低的 TTFT 会让应用对用户产生即时的感觉，即便整个输出生成需要数秒，因为文本会立即开始渲染。 要点总结： 提示词缓存： 复用静态前缀头以绕过解析状...