AIMeticulously

【云栖观察】模型越来越强，为什么 Context 反而越来越值钱——云栖大会02这次在云栖大会，Qoder 现场有一句话大意是： Model power is a commodity. Context is the asset. 注意这句话不是 Qoder 的官方 slogan，是现场分享中传达的方向性观点（厂商归纳，原话以厂商现场为准，不宜过度引申）。但它戳中了一个越来越普遍的趋势：模型越强、获取模型的门槛越低，一个 AI 产品真正稀缺的部分就越往上移动。对企业和复杂应用来说，这一层越来越像 Context。 上一篇「云栖观察」（云栖大会01）第三节已经把这层判断的方向点过一遍——Qoder 把代码仓库做成 Wiki、Memory 与 Knowledge Cards，QwenWork 强调 Enterprise Context，OpenSearch 强调长期记忆与上下文压缩，三家厂商在云栖都在往同一个方向收敛。本篇把 Context 单独拆开，看清楚它怎么从一次性 Prompt 附件，升级成 AI 系统的长期资产，又会带出哪些新的工程、治理与组织问题。 一、模型知道世...

【云栖观察】代码生成率是虚荣指标——云栖大会02这次逛云栖大会，印象最深的是阿里通义 Qoder 现场的一页 PPT： Generation rate is a vanity metric. “Generation rate is a vanity metric.”（代码生成率是虚荣指标）—— 这句话的英文原文据手厂商转述，原 PPT 用法以厂商现场为准，不宜过度引申。但它与上一篇「云栖观察」第七节里我点出的判断方向一致：当 AI 生成代码占比从 50% 推到 80%、90%，软件交付周期并没有按比例缩短。具体数字来自厂商案例（高德、海信、温氏），不宜直接当行业基准，但背后的逻辑在不同客户身上反复成立——代码生成速度和软件交付速度，根本不是同一个变量。 上一篇「云栖观察」（云栖大会01）第七节提出工程化展开后，这一篇我们把这层判断单独拆开来讲清楚。 很多团队现在都在统计 AI 写了多少代码、Copilot 接受率、每天生成多少行、Token 消耗降了多少。这些数字很容易测，也很容易让人兴奋。但只要一个需求从提出到上线仍然需要两周，AI 写了 90% 还是 50%，对业务的意义...

不要再做一个 AI 生成器：真正值钱的是完成一整件工作两件事正在同时发生。 一边是云栖大会上 WonderClip 把”上传脚本→拆解镜头→准备素材→批量生成”摆成完整流水线；另一边，是单点生成工具越来越难收上价。模型厂商把生成能力内化进原生产品、通用 Agent 把单点能力吸进工作流、开源模型把 API 价格打到地板——三层压力叠加，AI 产品过去那一层薄薄的价值正在被快速抹平。 把这两件事放一起看，会得到一个分水岭判断：生成能力正在快速商品化，能留下商业深度的部分开始往完整工作流迁移。 三组迁移必须同时发生——把对象从 File 升到 Job，把资产从 Prompt 升到 Skill，把壁垒从模型迁到业务资产。下面逐项拆开。 一、最容易做出来的 AI 产品，往往也是最容易被压价的生成式 AI 出现以后，市面上大量产品可以用同一个结构描述： 上传一个输入，选择一个模型，点击生成，拿到一个结果，下载。 文案工具、图片工具、视频工具、翻译工具、配音工具、代码工具，都经历过这个阶段。 这种产品并不是没有价值。它们解决的是真实需求，尤其在模型刚出来、用户还不会用的时候，把模型封装...

企业 AI 最难的问题，可能是激励机制：谁有动力真正使用它？这几天在云栖听企业 AI 的论坛，技术问题被讲得很多：模型怎么接，数据怎么治理，权限怎么控制，Agent 怎么部署，云资源怎么管理，安全怎么审计，企业知识怎么进入 Context。这些都是真问题。 但听到一个制造业案例时，我突然更想问另一个问题：企业里的人为什么要主动使用 AI？ 技术问题花钱能解决，组织问题花钱也不一定能解决。这是我在这篇里最想留下的一句判断。 一、效率提升以后，省下来的时间到底去哪了？假设一个员工原来每天需要 8 小时完成某项工作，AI 把它压缩到 5 小时。从工具角度看，这是一次很漂亮的提效。但对员工来说，真正的问题是剩下的 3 小时会去哪。 如果公司给出的答案是「很好，那以后你每天再多做 60% 的工作」，员工很难形成持续主动推动 AI 的动力。这是企业里最常见的死循环——省出来的时间被立刻收回，员工用脚投票。 如果使用 AI 以后，员工需要承担新的学习成本、检查成本和出错责任，绩效评价方式却完全没变，AI 很容易变成额外负担，而不是工具。 反过来，如果团队 KPI 本来就和上新速度、客户响应、...

从 Coding Agent 到数字员工:AI 应用正在收敛成同一套系统架构把云栖大会几个 Agent 产品的展台连着看下来,最反直觉的发现是:它们看起来分属完全不同的行业,长出来的却是同一套 OS。 Qoder 在做软件开发,QwenWork 在做知识工作,TinyFish 在做 Web Browser Agent,WonderClip 在做视频生产,OpenSearch 在做搜索和 Research。 把具体行业拿掉,它们的底层结构高度趋同: 上下文 → 规划 → 技能 → 执行 → 验证 → 记忆 → 业务结果(Context → Planning → Skill → Execution → Verification → Memory → Business Outcome) 这是 Agent 产品正在收敛成的同一套系统架构。 ⚠ 本文以阿里云生态(Qoder/QwenWork/TinyFish/WonderClip/OpenSearch)为现场样本。但下面这些架构判断,对自建场景、华为云、AWS、Azure、GCP 的 Agent ...

搜索正在从”给答案”走向”完成任务”:SEO 之后会发生什么?在上一篇云栖现场观察里,我用「Query → Results → Question → Answer → Goal → Plan → Search → Reason → Search Again → Tool → Action → Verify」这条演进曲线,把搜索的三个阶段交代清楚了。结果发布后,我们在被客户准备最多的三件事是:这条曲线对现有内容资产意味着什么,SEO/GEO 该怎么重新摆位,以及哪些工程动作可以马上开始做。 这篇把这三件事展开讲清楚。 一、三个阶段的差别,不在能力,在交付物简单回顾:第一代搜索给你若干链接,用户自己比较。第三代搜索给你一份带证据链的采购建议书、预订草稿、或一份主动的策略简报。 这个差别比抽象描述更具体、更可对照。我们用三个真实工作场景展开: 第一,三家云厂商对比。第一代搜索给你三家官网链接和若干评测页面;第二代搜索把公开资料整理成一段总结,告诉你在性能、价格、服务、生态上的差异;第三代搜索会先问你的业务类型、流量、合规要求,然后调用云厂商公开报价 API、抓取最新折扣...

参加技术大会最危险的事：把别人的下注当成自己的答案这几天在云栖大会，我看了很多展台，也听了 QwenWork（阿里云企业级上下文平台）、Qoder（阿里云的代码生成助手）、WonderClip、Agentic Search、企业 AI 等不同论坛。 技术上获得了不少新信息，但更有价值的收获发生在另一层：我意识到参加技术大会最大的风险之一，是让别人的资源配置悄悄接管自己的资源配置。 大厂在台上讲一个方向，现场几十个展位都出现类似产品，媒体再集中报道，很容易产生一种心理错觉：既然大家都在做，这件事对我也应该很重要。 这个推理经常不成立。 一、大厂的下注首先服务于大厂自己的约束一家云厂商重点做 Agent Runtime，这很合理，因为它同时握有计算、模型、企业客户和平台生态。 一家协作软件公司重点做 Enterprise Context，同样合理，因为它天然拥有组织关系、身份、权限、消息和文档。 一家视频平台做完整 AI Production Workflow，依然合理，因为它要提高内容生产量、团队协作和企业客单价。 这些方向都可能代表重要趋势。 但”这个方向重要”和”我现在应该做...

【云栖观察】云栖大会不是答案，它是一张 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...