故事的起点是我们持续在围绕高德地图PC站做SEO优化，在探索各个方向上能带来增长的可能。偶然在某社媒上看到一个内容是关于一个人怎么利用AI自主发现需求并全程自主开发和上线APP的并能自动进入下一个提案的探索与执行。立马在我们的脑子中开始火星撞地球，决定在PC站SEO这个场景下借鉴这个思路，并且实践OPC（一人公司）。发现增长机会、设计方案、编写代码、测试上线——这条完整的链路上，每个环节都需要专业能力和大量时间。传统的做法每个链路都需要有特定的人来参与或者先进一点是人工指挥多个AI工具来完成，但在 OPC 的思想下，AI Agent独立自主完成是可以有机会实现的一个路径。
过去几年商品域为应对AI化挑战，构建了"事件驱动的Function-Centric Agent架构"。该架构采用两层设计：上层为业务场景workflow编排层，下层为统一能力供给层，通过AIFunction标准化封装工具和领域知识。系统整合了显性事实、关联情景和隐性经验三类商品知识库，实现了在离线业务流程统一，并基于商品事务事件实现高效实时推理。目前已在商品属性、卖点等核心场景落地，覆盖亿级商品，显著提升信息完整性和搜索转化率，新需求开发周期缩短至1周/人，为商品智能化从"单点提效"迈向"系统自治"奠定基础。
看了很多的文章和视频，我以为我理解大模型的工作原理了，直到看了vLLM的代码，我发现很多地方理解的太过表面。因此花了大概2个月的业余时间，深入阅读了vLLM的源码，本文算是对于学习代码的一个总结。另外由于当前主流LLM都是 Decoder-Only 架构，本文会聚焦LLM，不会像网络上其他介绍Transformers的文章从原始论文的 Encoder-Decoder架构讲起。
本文以搜索结果展现为例，介绍 RenderFlow 如何将 LLM 代码生成能力落地到线上服务。随着结果形态和业务场景持续增加，传统依赖人工完成逻辑编写、联调验证和问题修复的链路，逐渐暴露出交付周期长、重复适配多、调整成本高等问题。RenderFlow 围绕“生成、执行、反馈、修复、发布”构建交付闭环：Prompt 适配器负责沉淀场景上下文，可执行引擎负责承载模型产物，多轮修复机制用于收敛生成质量，覆盖发布前、发布中、上线后的质量保障则用于控制线上风险。上线后，单场景数据转化逻辑交付从天级压缩到分钟级，需人工介入修改的比例降至 5% 以下；当前系统已支撑近千个场景的线上运行。
不知道你在面试的过程中，有没有被问到如何设计一个分布式抽奖系统？或者你很好奇，线上的这些抽奖活动，背后的原理是什么？这个项目本身并不大，但却涉及很多经典的技术点，因此也在面试中比较常见。本文根据自己最近做的一个体彩的抽奖活动，讲解了我在设计分布式抽奖系统的几个核心难点——匀速消耗、超卖、少卖等等，希望可以帮助同学们可以在面试中，更加从容地回答这些问题。
都是 AI Coding，为什么 Java 体验差了一个量级？五条方法论帮你构建自己的 Harness 环境
