AIMeticulously

【云栖观察】云栖大会不是答案，它是一张 AI 产业正在下注什么的地图这次逛云栖大会，我最大的收获不是又记住了几个新模型、几家新公司，而是看展会的方法变了。 以前参加技术大会，容易默认几个判断：大厂重点讲的方向，大概率代表未来；台上反复出现的概念，大概率就是行业共识；一个产品已经被摆到展台上，似乎也意味着它已经足够成熟。见得多以后，又容易滑到另一个极端，觉得大会就是市场活动，展台就是广告，PPT 就是包装。 这两种看法都太省事。 展会当然有营销属性，但营销本身也是信息。一个厂商愿意把预算、产品经理、工程团队、销售团队和展位资源砸到一个方向上，至少说明两件事：它希望市场相信什么，以及它正在为什么问题做产品化尝试。 所以我现在更愿意把大型技术大会当成一个高密度的产业采样场。它不给答案，但给你样本、信号、反例，还有一张”行业正在为什么未来下注”的地图。 一、先把展会里的“热闹”拆成不同证据层级这次我开始有意识地把一个技术方向拆成五个层级来看： 叙事层 → 产品层 → 生产层 → 业务层 → 收入层（Narrative → Product → Production → Business ...

文中数据来源：CodeRabbit 2025.12 / New Relic 2026 报告、Microsoft Work Trend Index 2026、Microsoft FY26 Frontier Firms 公告、GitHub Spec Kit、AWS Kiro、OpenAI Codex、Claude Code、Alibaba Qoder、JetBrains 2026.1 AI Pulse。案例为代表性场景归纳，不指向具体企业。 你最大的错误不是没买工具，是没写 CLAUDE.md一家股份制银行的 CIO 跟我抱怨：AI 工具买了、模型部署了、人也训了，2026 H1 整半年下来交付周期几乎没动。核心系统组的负责人更直接：”AI 写的代码能用，但每次都要重写一遍——它不懂我们行的规则、不懂监管要求、不懂怎么和那个 30 年历史的老系统对接。” 问题不在 AI 不够强，在于你们没把规则写下来。CodeRabbit 在 2025 年 12 月对 470 个开源 PR 的分析给出了一组被广泛引用的数字：AI 协作 PR 平均含 10.83 个问题，纯人工 PR 6...

做一个应用的门槛塌了，碰用户数据的门槛没塌电商的中台负责人最近在问我同一件事：业务侧一周就能自己用 AI 搭出三个内部小工具，IT 的开发排期却还排到下个季度。这中间到底卡在哪？ 我们的回答只有一个判断：开发门槛塌了，碰用户数据的门槛没塌。 这句话背后是两件同时发生的事。 Bolt.new 是 StackBlitz 做的，2024 年 10 月一条推文静默发布，五个月做到 4000 万美元 ARR。Sacra、Growth Unhinged 把它追踪为史上增长第二快的产品（仅次于 ChatGPT）。2026 财年收官时，StackBlitz CEO Eric Simons 在 LinkedIns 上透露：Bolt.new 已经被四分之三的财富 500 强企业使用，企业级 ARR 同比涨了 10 倍（Eric Simons 官方帖子，2026 财年收官）。Lovable 是瑞典斯德哥尔摩的团队（创始人 Anton Osika），2025 年 11 月靠 $200M A 轮估值 $1.8B，2025 年 12 月底 B 轮估值 $6.6B，半年估值翻了近 4 倍（Forbes...

AI 工具之争已经结束——但赢家用不用得上，是另一回事——AI 时代软件工程变革·慢慢学AI175上一篇（AI174）讲了代码评审升级：AI 写代码之后，开发者的角色从写的人变成审的人，三层评审模型（AI pre-review / 人类 spot-check / 治理规则）是组织能力的一部分——评审带宽涨不上去，AI 写得越快，组织积累的债越危险。这篇接着讲工具选型，但前提是组织已经按这套搭好了刹车。没刹车就上高自主性工具，是在裸奔。 先给结论。2026 年中回看，AI 工具的”王座”不是在四个工具之间轮转，是被 Claude Code 和 Codex 两家拿走了——准确说，是它们拿走了”高自主性”这一档，也就是真正能把端到端交付周期压下去的那一档。GitHub Copilot 还挂在 29% 的工作场采用率第一，但那是企业采购惯性托着的，新增曲线已经走平；Cursor 是上一代的体验王，增速在放缓；Google Antigravity 是用 Gemini 加云加企业合规砸进来的第三股力量，可两个月才到 6%，还在起跑。 国内这边，能同时接住”自主代理能力 +...

AI 时代的代码评审——AI 写代码之后，谁来审？上一篇（AI173）我把”验证”列为代码近乎免费之后的第三道新瓶颈，结尾留了一句”第四节单独讲”。这篇兑现。先给结论：2026 年中回看，AI 编程工具交付的最大变量不是 license 数、不是 seat 数、不是模型跑分，是评审带宽。 CodeRabbit 在 2025 年底那份报告里分析了 470 个开源 GitHub PR，结论是 AI 参与生成的代码，缺陷比纯人工代码多 1.7 倍（每 PR 平均 10.83 vs 6.45 个，按文件大小/复杂度未配对），安全漏洞按子类分别高了 1.57 到 2.74 倍——XSS 2.74×、密码处理不当 1.88×、不安全的直接对象引用 1.91×、不安全反序列化 1.82×；logic/correctness 1.75×、readability 3×+、formatting 2.66×、error handling 接近 2×。Apiiro 2025 年 9 月在 Fortune 50 企业仓库里扫描（数据覆盖 2024.12–2025.6）补了另一面：AI ...

当代码近乎免费，瓶颈跑去了需求、集成、验证、对齐最近一个客户跟我说了一句话，大意是：工具买了，课也上了，钱没少花。可交付还是那样，不知道问题在哪。 很多老板自己动手试过编程，或者给团队上了 AI 工具。新鲜感过去，该卡的地方还是卡在老地方。 读完你会知道：你的钱去哪了，以及下一步真正值得投的方向在哪。 一、代码变便宜了，然后呢写代码这件事，在变便宜。 GitLab 2026 年发布的调研里，85% 的受访者说了一件事：AI 已经把瓶颈「从写代码」推到了「审查和验证代码」。LinearB 分析了 810 万次 PR 发现：用 AI 辅助的开发者，合并的 PR 数量多了将近一倍，可审查时间也多了将近一倍——个人效率在涨，团队产出没有等比例跟上。 当「写」不再值钱，「其他东西」就开始值钱。制造业的老板知道这种感觉：当一道工序突然变快，在制品就会堆积到下一道去。电商的美工也一样——出图快了，可产品上架还是那么慢，流量没涨，库存反而堆起来了。 软件工程正在重演同样的事。 瓶颈搬家这件事，制造业有半个多世纪的体感。软件工程也一直在走，只是随着 Vibe Coding 概念的爆火，编程普及...

上 AI 之前，先把团队按价值流重组在你为公司引入 AI 之前，有一件回报远高于选工具、高于选模型的事：先按价值流重组技术团队。 我见过太多企业，AI 工具买了、模型部署了、人也训了，交付还是慢，员工还更累。根因几乎都不在 AI 不够强，而在团队按技术层（前端、后端、算法、运维、安全）错切。一个端到端的功能要跨四五个团队，每次交接都在掉东西：需求掉一点，上下文掉一点，责任感掉一点。团队边界改对了，AI 才有放大的土壤；边界不对，AI 只会在错的结构上加速制造债务。 这篇文章给一套能动手的组织设计法——Team Topologies（团队拓扑，Skelton & Pais, 2019 / 2025 第二版）。核心三条：按价值流切团队、盯紧每个团队的认知负荷、把内部平台当产品。下面用一个制造业的真实场景拆开讲，再把视角拉到 2026 年的 AI 代理时代——Skelton 自己最近一年的 keynotes 已经把 Team Topologies 重新定位为「AI 时代的基础设施 for agency」，这是这一版要补的关键判读。 一位制造业 CIO（案例基于真实项目...

写在前面 你的软件架构不是被”设计”出来的，是被你的组织架构”长”出来的。这条 1968 年提出的定律，正在被 2026 年的 AI 代理反复验证。 哈佛商学院的镜像假说：组织距离比代码复杂度更能预测软件缺陷率。你以为是技术债，多数时候是组织债。 Amazon、Spotify、Apple——三家万亿级公司用三种命运，诠释同一条定律：能跨越组织-架构同步周期的人赢，卡在错配里的人输。 AI 代理正在进入组织架构图。当节点不再全是人类，康威定律的下一个 56 年，从这里开始。 我常跟一把手讲一句话：你们公司的 AI 项目能不能跑出来，在你选什么模型之前，组织架构图已经给了答案。 这不是我坐在咨询室里编出来的判断。它来自我过去几年陪电信运营商、制造业 CIO、金融机构数字化负责人做 AI 转型的真实观察——同样一套 LLM、同一批供应商、几乎一样的预算，两家公司的结果天差地别。把他们的组织架构图拿出来一对比，差异在那。 这条判断的源头，是 1968 年一个叫 Melvin Conway 的程序员。他在《Datamation》杂志发了一篇 4 页的论文，说了一句让后来所有 CTO 都得...

写在前面 AI 智能体的上限，不只看模型大小，更看“上下文管理”这门手艺。它就像为 CPU 配置内存，决定了智能体思考的深度和效率。 上下文窗口不是垃圾桶：信息过载会“投毒”、干扰、混淆 AI 的判断。精准，远比海量更重要。 高手用“写、筛、压、隔”四字诀管理 AI 上下文，把有限的“内存”用在刀刃上，实现降本增效。 未来的竞争是系统效率的竞争。用多智能体架构“隔离”任务，让每个智能体在自己的小窗口里做到极致，是构建复杂任务系统的关键。 核心摘要智能体（Agent）执行任务离不开上下文（Context）。所谓“上下文工程”，正是在智能体执行任务的每一步，都为其上下文窗口精准注入恰当信息的艺术与科学。本文将当下主流智能体所采用的上下文工程策略，归纳为几大通用模式。 上下文工程（Context Engineering）正如 Andrej Karpathy 所说，大语言模型（LLM）就像一种“新型操作系统”。LLM 是 CPU，而它的“上下文窗口”就是 RAM，充当着模型的工作记忆。正如 RAM 的容量有限，LLM 的上下文窗口在处理各种上下文来源时也面临容量瓶颈。操作系统的核心工...

写在前面 大多数AI翻车不是模型太笨，而是上下文工程缺席——信息没被正确“写入、选取、压缩、隔离”。 忽视上下文=真金白银的损失：从 Bard 发布翻车到“260块鸡块”，企业都在为记忆缺陷买单。 盲目拉长上下文只会放大噪音与攻击面；小而准的上下文管控才是性能与安全之解。 先做上下文，后谈大模型：常见收益是输入成本 -80%、准确度 +15~90%，比换更大模型划算得多。 2023-2025年的企业实践证明，AI 应用失败的根本原因不是模型不够智能，而是”上下文工程”的缺失。谷歌因此损失1000亿美元市值，而掌握这项技术的企业却实现了40-90%的性能提升。 一、1000亿美元的教训：当AI”失忆”时会发生什么谷歌Bard的致命一击2023年2月，谷歌满怀信心地向世界展示其AI聊天机器人Bard。然而，在这场万众瞩目的发布会上，Bard犯了一个令人震惊的错误。 当被问及詹姆斯·韦伯太空望远镜的成就时，Bard自信地回答：”它拍摄了太阳系外行星的第一张照片。”这个答案听起来很专业，但有一个致命问题——它是错的。实际上，第一张系外行星照片是在2004年由欧洲南方天文台...