CODE, ARCHITECTURE & AI

架构和远方.

174 篇记录保持好奇,慢慢积累

历史总是在重演,AI 时代的我们应该做些什么

很多公司以为自己接入了几个大模型,采购了一批智能体工具,员工就获得了某种近乎无限的生产力。 换个角度看:每个人突然多出了一百万名能力不稳定、缺乏上下文、不会主动澄清目标、偶尔虚构进度、还能高速消耗预算的下属。 这些下属不需要工位,也不会请假。它们一天可以提交上千次结果,看起来永远在工作。管理者很容易被这种吞吐量迷惑,误把生成速度当成有效产出,误把调用次数当成…
继续阅读 ↗

使用 Vibe Coding 的这6 种后遗症,你有吗?

我已经很久没有沉浸式写代码了。 以前碰到一个复杂问题,我会花几个小时读调用链、画状态变化、跟踪异常路径。刚开始很慢,脑子里只有一些零散信息。随着上下文逐渐完整,代码会形成一张连续的结构图。再往后写,很多判断不需要反复查找,心流也就出现了。 现在的工作节奏完全变了。 我先给 Agent 描述需求,等它执行。等待期间又觉得空着可惜,于是打开第二个窗口,让另一个 …
继续阅读 ↗

做 Agent 架构时,OpenViking 的几个可以学习的点

设计 Agent 架构时,有一个模块的边界经常画不清晰:上下文。规划、工具调用、执行循环这些组件的职责都好切分,唯独「Agent 该知道什么」这件事,散落在 prompt 模板、RAG 管道、记忆插件和会话历史四个地方,各管一段,互不通气。 比较常见的状态是知识走一条 RAG 管道,用户记忆走一个独立的 memory 服务,工具使用经验干脆没有沉淀机制,靠 …
继续阅读 ↗

RAG 的新思路:SAG 和 OpenViking

最近在看 RAG 的两个新思路,其实也不是说特别新,有点新瓶装旧酒的意思。 对于 RAG 的优化,一种线路是继续优化传统 RAG:切块更细一点,召回器多堆几层,重排再优化,最后把 prompt 拼得更精致。另一条线路是开始换问题定义:如果知识检索本身的建模方式就不对,后面那一长串补丁是不是从第一步就已经输了。 SAG 和 OpenViking 属于第二种。 …
继续阅读 ↗

Session First 和 Agent First,本身并没有高低之分

最近在思考一个问题:系统究竟把谁当成第一类公民。 现在我们看到很多的 AI 产品,,本质上还是「把聊天框做得更厚一点」。用户打开一个窗口,对着通识大模型说需求,模型在一个长 session 里记上下文、调几个工具、写几段内容、偶尔执行点操作。这个模式我称它为「Session First」。 「Session First」的模式跑得起来,落地也快。过去一段时间…
继续阅读 ↗

AI 时代,让自己慢下来

锡箔大佬在群里调侃,当前 AI 时代,只要你学得慢,你就不用学了。 是的,AI 发展太快了,回望去年的这个时候,我们写代码的方式还不一样,问问题的方式还不一样。 我不是焦虑效率的问题,也不是那种怀旧式的「古法编程才有灵魂」。我想的是:当生成成本持续下降,一个工程师最稀缺的能力,正在从「产出内容」快速转移到「做判断」。判断接口该不该拆,技术债该不该还,需求方嘴…
继续阅读 ↗

从 AI 的本质聊 AI 对组织的影响

这一轮 AI(LLM),引发了组织的变化,不限于裁员,裁员只是一个表象,根本的逻辑是组织里「信息如何流动」「决策如何形成」「责任如何落地」这些变了。我们所看到的多了一个写文案、写代码、做 PPT 的工具,或办公室里多了几个自动化插件等等只是改变过程中的一些小的细节。从改动的范围来看,可以看到改了分工边界,改了岗位能力结构,改了系统设计方式。 LLM 的本质是…
继续阅读 ↗

如何打造 AI-Native 软件产品研发组织

如果一个团队真的想做 AI-Native 研发组织,第一步是改 组织契约 :谁可以让 AI 产出代码,谁对代码负责,什么质量底线不能退,什么流程可以砍,什么流程必须更重。 AI 现在太会写代码了,但是这就会导致一个问题:它把「产出代码」这件事的成本做到很低,低到组织里原本那些靠角色边界、流程延迟、评审机制勉强维持的质量平衡,突然失效了。 过去一个 PM 提需…
继续阅读 ↗