每天，成千上万句的“小度小度”涌向 AI 助手。小度 AI 智能助手产研团队以信息类 Bot（Aries）为试点，打通了从 bad case 发现、问题定位到上线解决的完整闭环，并将这套方法推广至音乐、短视频和长视频业务，推动研发从被动接需求转向主动发现问题、端到端解决问题。实践效果明显：在不增加人力的情况下，Aries 每周解决需求数从 2 个提升至 12.5 个，增长约 6 倍；端到端满足度从 76.1% 提升至 81.5%。截至今年7月，团队已累计发现 160 个需求并上线解决 121 个，短视频 UP 主召回专项满足度也从 47% 提升至 67%。
本文聚焦一个扎心的悖论：AI 工具全面普及后，单点效率明显提升，但需求整体交付周期并未显著缩短。作者结合行业数据指出，真正消耗 80%+ 交付周期的并非执行速度，而是角色之间的等待、交接与信息损耗。 据此提出 AI 提效分级框架（L1/L2/L3） 与 AI Native 组织 两大理念，打破产研测运维职能边界，以 BuilderAgent 实现需求到上线的全流程闭环，让提效结果"可复制、可持续"。
在 《是时候了解一下 Git worktree 了》 一文中，我们介绍了如何在 Codex、Claude Code 等 Coding Agent 中利用 Git worktree 实现并行开发。不过，那篇文章聚焦于单仓库场景。当我们尝试将 worktree 应用于采用多仓库架构的 LLM Arena 平台时，又遇到了一系列新问题。 本文记录我们如何为多仓库场景设计面向 Coding Agent 的 worktree 工作流，以及如何处理子模块初始化、需求编号冲突和多 Agent 编排等问题。
地图情报核实要判断"某段路到底有没有车走过"。车少的长尾路段（乡道、新修路、偏远低频路）要把时间拉到半年才攒得出足够轨迹，而这批 180 天、近 10 万亿点的历史轨迹躺在离线数仓里，查一次要跑几个小时。我们用一套建在 ClickHouse 上的检索服务，把它做成在线可查——任意区域检索 TTFB 0.35s。本文复盘我们如何用 ClickHouse + S2 地理编码 + 流式检索，在近 10 万亿轨迹点的底库上做到任意区域秒级可视化。既有存储引擎选型、地理索引设计的原理解析（第 5 节），也有一线踩出来的避坑经验（第 6 节）。适合关注海量数据检索、时空数据处理、OLAP 实战的同学。
把验证流程左移，通过前置的审查、运行时验证、视觉验证等系统化的能力建设，让 Agent 在开发过程中就能按项目的工程规范完成自检和修复，提高上游交付的质量减少返工。
AI 写代码越来越快，网盘主端 FE 团队每月约 2000 次 CR 中，AI 生成代码占比已达 55.87%。代码产出速度提升，传统人工 Code Review 的压力同步放大——Reviewer 不仅要看代码风格，还要判断逻辑、调用链、API 契约和高危问题，精度与专注度双双下降。本文分享了他们如何在 CI/CD 流水线中嵌入 AICR 强制检测链路，用多维度多角色 AI 审查为人工 Reviewer 减负，以及建设过程中对检测耗时、误报治理、模型选型等问题的实战思考。
本篇文章想做一件事：把学习方向调转过来。不只是用管理学教 Agent 如何工作，而是站在管理者和团队协作的视角，用 Agent 的运行逻辑，反过来重新审视组织协作——那些藏在算法里的管理真理，也许正是团队长期忽视的地方。
为什么 Prompt 写得再细，AI 还是会输出奇怪的结果？为什么新项目 AI 很好用，历史业务却总是翻车？本文作者从信息论出发，用一个简单的框架帮你拆解 AI Coding 里的种种困惑——当你不再跟着新概念焦虑，而是回到"信息"和"不确定性"的底层逻辑，很多问题会清晰得多。
AI Coding 已改变研发方式，但单点代码生成只占研发工时 10-32%，整体提效有限。本文从我们团队在民生彩票、政务等项目的真实交付复盘出发，提出 Harness 全链路研发智能体：把大模型放进一套可控的研发流程，将需求分析、接口设计、代码生成、自动 CR、单测、冒烟验证、环境部署、问题排查串成带反馈控制的闭环，让 AI 从"会写代码"升级为"能完成可验证交付"。本文系统阐述其需求可执行性检查、状态机与质量门禁设计、失败回流机制、复杂度感知编排、RD/QA 协同模式，并以行业研究（METR RCT、Google DORA、SWE-bench 等）做交叉印证。
用 AI 做产品，最大的坑可能不是"做不出来"，而是"什么都想做"。本文记录了百度前端研发工程师与 AI 组队开发 Design.md Token Exporter 的全过程——ChatGPT 陪他脑暴、Codex 当主力写代码、Gemini 做体验顾问，但 AI 的热情差点让产品变得臃肿不堪。当技术门槛被击碎后，什么该做、什么不该做，成了每个产品人必须自己回答的问题。这篇文章，讲的就是这个"取舍"的故事。
