企业软件

微调 vs RAG 这个问题，通常不是以问题的形式出现的，而是以一句结论出现：我们需要用自己的数据微调一个模型。这是企业 AI 里最昂贵的一句话之一，而且多数情况下是错的。不是永远错，但确实是多数。这个诉求背后几乎总是两件事之一：模型不了解我们的业务，或者模型回答的方式不是我们想要的。对第一件事，微调是一个糟糕的解法；对第二件事，微调是一个昂贵的解法。 在微调、RAG 和提示词之间做选择，并不是技术偏好问题。三者各自修复的是完全不同类别的问题，选错了，就会换来几个月的工程投入，而最初那句抱怨依然原封不动地摆在那里。 最省钱的一条规则： 如果问题是模型不知道某件事，用检索。如果问题是模型知道，但回答的风格、格式或长度不对，先改提示词，...

进入 2026 年后，认真考虑迁移出 OpenAI 的团队明显变多了。开放权重模型在日常生产任务上的质量已经很难与头部模型区分开来，公开单价更低，而权重本身可以下载这一点，把与厂商的关系从依赖变成了选择。 但这并不意味着切换是免费的。API 调用本身几乎一模一样，真正要干活的是它周围的一切。本文讲清楚:哪些东西能原样搬过去,哪些会悄悄出问题,怎样设计一次有意义的比较,以及什么时候留在原地才是正确答案。 先把预期对齐。 换厂商就是换一个基础 URL、一个模型名、一份凭据。但要拿回同样的输出质量,那是以天为单位计的提示词工程。给一个范围明确的功能预留一到三周。任何假设可以即时替换的估算,都是乐观估算。 哪些东西能原样搬过去比你想的多,这...

大多数团队把 API 安全当成身份验证问题：发放令牌，在每一条路由上校验它，然后认为事情已经做完了。直到某天，一位测试人员把 URL 里的一个数字改掉，就读到了另一位客户的发票。 「已通过身份验证」和「已获得授权」之间的这道缝隙，正是绝大多数真实 API 泄露事件栖身的地方，而且它并不是扫描器能够稳定发现的那类问题。自动化工具看到一个有效的令牌和一个 200 响应，就报告成功。只有理解你业务规则的人，才会注意到那个响应里装的是别人的数据。 核心区别： 身份验证证明的是谁在调用。授权决定的是这个特定调用方可以看到什么、可以修改什么，而且它必须落实到每一个对象、每一次请求，并在数据层强制执行。几乎所有严重的 API 漏洞，都是第一件事运...

Drupal 迁移属于那种能安稳待在下个季度计划里的项目，直到某个日期让它变得紧迫。眼下正有两个日期在做这件事，而其中只有一个还没到来。 Drupal 7 已于 2025 年 1 月 5 日失去官方支持。任何还在跑它的站点，已经一年多没有任何安全保障了。Drupal 10 将在 2026 年 12 月 9 日走到生命周期终点，正好是 Drupal 12 发布的同一周，此后它不会再收到任何形式的发行版。如果你正处在这两个版本之一，问题已经不是要不要动，而是走哪条路、要花多少钱。 你现在的位置： 从 Drupal 10 到 Drupal 11 是一次真正的升级，同一个站点原地更新，通常两到六周。从 Drupal 7 到 Drupal...

自托管 Kimi K3 在 2026 年 7 月 27 日成为技术上可行的选项，那天 Moonshot AI 连同生产级推理支持一起公开了这个 2.8 万亿参数模型的权重。许多机构读到这条消息后得出结论：现在可以在自家硬件上运行前沿级推理，不必再按 token 付费了。 这个结论通常是错的，但原因并非人们预想的那样。工程上是可以做到的。真正击垮多数项目的是那笔账，而且它往往在预算批下来好几个月后才悄无声息地发作。 简短回答： 在 MXFP4 精度下，2.8 万亿参数在计入键值缓存之前就已占用约 1.4TB。一个八卡 H100 节点只有 640GB，因此根本无法服务这个模型。现实的部署要从约 1.7TB 显存起步，...

凡是按端点数量来估算定制 API 开发成本的人，几乎都会算错，而且通常差三倍。端点本身是整件事里最便宜的部分：十来个端点，只是读写你手里已经有的数据，对一位称职的后端开发者来说不过是两周的活。 真正花钱的，是把这些端点变成另一家公司愿意把生意押上去的东西所需要的一切：经得起安全评审的认证、让你日后还能改主意的版本管理、好到没人需要给你发邮件的文档，以及能告诉你哪个客户今天早上过得不顺的运维装置。有一个 API，和有一个别人依赖着做生意的 API，两者之间的那道落差，才是预算真正的去处。 价格区间速览: 只被你自己的应用调用的内部 API，通常花费 10,000 到 30,000 英镑。由少数几家指定集成方使用的合作伙伴 API，一般...

CRM 与 ERP 集成几乎总是被说成一个连接问题，而它几乎从来都不是连接问题。两套系统都有文档齐全的接口，也都有现成的连接器。真正的难处在于，销售和财务花了很多年，用两套不同的词汇去描述同一门生意，而集成正是这两套词汇被迫达成一致的地方。 当有人问起，一条被转化过两次的线索到底该生成一个客户还是两个，这个项目就不再是技术问题了。这样的对话，在三十个字段上重复一遍，才是真正的工作量。 先做这件事: 在挑选连接器或平台之前，先写下每一个共享字段由哪套系统拥有，以及两边同时被编辑时会发生什么。跳过这一步的集成建得很快，然后用好几年时间不断产出重复记录、对不上的合计数，以及没人敢信的报表。 为什么 CRM 与 ERP 的数据始终对不齐两套...

采购 COBOL 现代化服务，和买任何别的软件工作都不一样。要动的那套系统已经跑了三四十年，公司里现在没有一个人完全弄得懂它，而做砸了的代价不是错过几个迭代，是监管报送出问题。与此同时，摆在你桌上的几份方案承诺的结果一模一样，报价却差出好几倍。 这篇文章讲清楚一份认真的合作到底包含什么，几类供应商之间的差别在哪里，以及哪些问题能把建立在证据上的报价和建立在乐观上的报价分开。它假设你就是事后要为这个决定作出解释的那个人。 该看什么： 一份可信的 COBOL 现代化方案包含现状勘察、目标架构设计、数据迁移、代码转换或重新托管、以比对为核心的测试计划、并行运行、切换方案以及知识转移。只给代码转换标了价的报价，不是一份项目计划，它只是其中最...

第三方 API 集成是商业软件里被低估得最稳定的一类工作。文档读起来清清楚楚，供应商提供了客户端库，于是有人说两周。六周之后，团队还在争论：当一个 webhook 为一笔已经退款的订单第二次送达时，究竟应该发生什么。 这道差距不是能力问题。真正的原因在于，一次集成里有意思的部分从来不是请求和响应，而是当对方系统做出它的文档从未描述过的行为时，随之而来的一切。它一定会这么做，因为它是一个活着的产品，属于一群有自己路线图、对你的发布计划不承担任何义务的人。 经验法则： 只从一个服务拉取数据的只读集成，通常需要一到三周。会写入事务的集成需要三到六周。两个都允许编辑的系统之间的双向同步需要六到十二周，而且永远不会真正结束，因为冲突解决是一个...

每一次大型机迁移，都从有人去搜索大型机迁移工具开始，而随后那场厂商演示看起来总是格外可信。几千行 COBOL 送进去，可读的 Java 出来，测试套件全部通过，幻灯片承诺七成到八成的自动化。演示本身通常是诚实的，只是它跑的那份代码，行为跟你的代码毫无相似之处。 本文梳理真实存在的工具类别，说明每一类真正擅长什么，以及在真实负载下各自最容易崩掉的具体位置。它写给必须在立项报告上签字的人，而不是写给组织内部替厂商说话的人。 实话实说： 大型机迁移工具确实做了大量有用的工作，尤其是在分析、数据搬运和机械转换这三件事上。它们做不到的是理解你的业务规则。自动转换可以稳定地产出能运行的代码，但产不出你的团队愿意维护的代码，而弥合这段差距，正是预...