yuer2025

写分布式查询引擎久了，你会发现一个规律： 而且不是“慢慢变复杂”，而是： 开始返工 开始推翻 开始重写 开始怀疑最初的架构判断 这不是某个团队的问题，而是分布式查询引擎的工程宿命。这篇文章，

最近在看一个 分布式查询引擎（Distributed Query Engine） 的 Rust 项目需求，目标其实很直接： 多节点执行 低延迟 / 高吞吐 数据 Shuffle / Partition

在工程实践中，我们经常试图用“更强的能力”去解决问题： 更大的模型 更快的识别 更密的规则 更复杂的策略 但越来越多的系统级事故表明： 有一类问题，并不是能力不够，而是层级放错了位置。 一、攻击逻辑已

前言 最近一段时间，大模型在技术圈的讨论，几乎都围绕着： Prompt 怎么写 模板怎么复用 如何让 AI 一次性给出“正确答案” 但当我把 AI 引入到高风险文本场景（需要由人承担现实后果的正式文本

很多人第一次使用大模型时，都会下意识把它当成一个更聪明的搜索引擎，或者一个听话的执行器。 于是最常见的问题往往是： 但如果你用得够久，就会慢慢意识到一件有点反直觉的事： 越是试图“命令”模型，效果反而

这篇文章不是讲 Prompt 技巧，也不是模型评测， 而是想聊一个更底层的问题： 一、一个工程上不太舒服的结论 现在很多 AI 应用，本质是在“裸用大模型” 先把结论抛出来

这两年大家在掘金聊 AI，基本都围绕这些关键词： RAG Agent Workflow 自动化 多模型协同 但如果你真的做过稍微复杂一点的 AI 项目，很可能已经遇到过这些问题

很多销售已经在用 GPT 了。 写话术、改文案、整理客户信息，都没问题。 但一旦你尝试让 GPT 参与判断，比如： 这个单子该不该继续跟？ 要不要投入更多资源？ 是激进推进，还是保守观望？

我把 GPT 当成 Runtime 用：只用一个客户端，跑一个可控、可审计的投资决策 DEMO 背景：为什么“问答式 AI”在真实决策中不够用？ 如果你真的用 LLM 参与过投资、经营、项目评估，