漫游的渔夫

对前端开发者来说，这很像把复杂交互拆成流程节点：每一步有目标、有状态、有输入输出、有失败处理，而不是把所有逻辑塞进一个巨大的 `handleUserInput`。...

当你能写出一个最小 Agent Loop，能看懂每一步发生了什么，能让它在错误时停下来而不是乱跑，你就已经跨过了 Agent 工程最重要的一道门槛。...

真正可维护的 Agent 工程，需要给每个工具写一份 Schema：描述用途、约束参数、标记风险、控制确认流程。对前端开发者来说，这就像给 API 写 TypeScript...

Agent 的第一步不是让模型“更聪明”，而是让模型能在可控边界内调用工具。模型负责理解用户意图、提出工具调用；程序负责校验工具名、校验参数、检查权限、执行 API、处理错...

RAG 上线后，点赞点踩只是反馈入口，不是反馈闭环。真正可优化的反馈，至少要带上 traceId、question、answer、citations、retrieval、r...

RAG 优化不能靠“我问了几句，感觉还不错”。只要你改了切块、Embedding、Rerank、Prompt 或引用逻辑，就可能出现“这个问题变好了，另一个问题又坏了”。...

前端开发者做 AI 应用，不只是把模型结果渲染出来。更重要的是设计一条完整的证据链：从检索片段，到结构化答案，再到页面引用和日志排查。...

RAG 系统的精度瓶颈往往不在 Embedding 检索，而在排序。语义检索（一阶段）只能保证“相关”，但不能保证“最优”。引入 Rerank（二阶段重排序），将最精准的资...

RAG（检索增强生成）不是简单的“语义搜索+大模型”。在真实业务场景中，单纯靠向量相似度进行全量检索会导致严重的知识污染。先用 Metadata（元数据）硬过滤缩小范围，再...

RAG 的本质是“帮模型翻书”。如果你的“书签”（切块）夹在了错的地方，或者把一个知识段落撕成了两半，模型再强也读不懂。切块不是物理分割，而是**语义单元的重新组织**。...

AI 答非所问，80% 的情况不是模型“笨”，而是你喂给它的资料“不对”或“没找准”。RAG（检索增强生成）系统的天花板由**检索质量**决定，模型输出只是在这个天花板下的...

很多前端同学刚上手 RAG（检索增强生成）时，想法都很“单纯”：一把梭把 PDF 扔给模型，剩下的交给奇迹。但现实往往是：模型回得很泛、回得像在猜，甚至直接开始胡编乱造。...

在 AI 原型阶段，最让人兴奋的莫过于发现“这个也能用模型做”、“那个居然也能交给 AI”。这种能力边界被打开的快感，常让开发者陷入一种惯性思维：**只要大模型能做，就默认...

做 AI 功能时，痛苦的通常不是“完全不会写”，而是另一种更微妙的状态：功能大概有了，接口也通了，但只要一出问题，整个人就开始陷入循环：是前端没发出去吗？后端没收到吗？模型...

很多 AI 功能最后不是死在模型不聪明，而是死在接口接不起来、浏览器跨域拦截、字段对不上、请求链路断裂。模型那边已经“差不多行了”，但系统边界没对齐，功能就只能卡在半空中。...

很多人一提到 AI 产品体验，第一反应都是放在模型本身：模型够不够强、结果够不够聪明、输出够不够像人写的。用户感受到的 AI 体验，不只是模型质量，还包括页面在等待、成功、...

前端开发者转型 AI工程师，不能止步于本地脚本。脚本是验证灵感的实验台，而 API才是生产交付的面子。本文通过对比脚本与服务的本质差异，阐述如何利用FastAPI 等工具将...

这篇文章想讲清楚的，就是为什么 AI 优化不能长期只靠“我觉得”，以及为什么“最基础的评估意识”会成为 AI 工程里从 Demo 走向产品最重要的一课。...

很多人刚开始做 AI 应用时，最常见的心路历程是：从惊叹模型的神奇，到吐槽模型的不稳，最后产生自我怀疑：“到底是模型能力不行，还是我没说清楚？...

AI 应用的稳定性不取决于它在成功时有多聪明，而取决于它在失败时有多体面。本文聊聊为什么 AI 工程化必须具备“防御性思维”，以及如何设计一套高韧性的错误处理链路。...