- URL: https://alienchow.dev/post/ai_takeaways_mar_2026/
- Added At: 2026-07-26 06:58:07
- Tags: #read
本文是平台工程师对AI热潮的冷思考：批判术语炒作、落地尴尬，指出AI学习便利无需焦虑追新，但基础设施即代码等领域表现糟糕。建议屏蔽噪音、专注核心，要求生产环境演示验证真实价值。
这篇文章是一位平台工程师/SRE 在 2026 年 3 月对当前 AI 热潮的冷思考，集中吐槽了 AI 领域的过度炒作、术语通胀和实际落地时的尴尬。作者并非否定 AI 的价值，而是呼吁在营销噪音中保持务实。
核心信号：AI 让学习变得极其便利，但这也意味着你不用再追逐潮流。
你可以随时用 AI 生成定制化的学习材料，比如让 Gemini 做深度研究、把日语说明书丢给 NotebookLM 用英文提问。既然能“零延迟”获取任何知识，那就不必焦虑地去学那些很快就会过时的 AI 工作流——去年你刚学会的提示技巧、工具调用协议，转眼就被厂商自动化掉了。与其被牵着鼻子消耗工程资源，不如专注核心业务目标，六个月后再问 AI “我错过了什么”，瞬间就能跟上。
术语和使命的异化：人们忙着为旧概念造新词，而软件工程的价值被扭曲。
作者举了“RAG”被重新定义为仅指向量数据库检索的例子，讽刺业界为了标新立异不断发明新词（JIT-Search-Grounding、DeepRAG）。同时，AI 项目失败就归咎于工程师“技能不足”，成功则归功于 AI 价值，这种逻辑逼迫工程师变成什么都懂一点的“锯齿形人才”——看似能应付一切，却容易割伤自己。SRE 提出的可靠性、灰度发布等传统保障，常被视作创新的绊脚石，而实际上，AI 编码工具产出的代码漏洞百出，相关安全事故频发。
代理式 SRE（Agentic SRE）被寄予厚望，但解决不了真实世界的根本问题。
有团队试图跳过数据统一，用“联邦代理”直接连到各个数据孤岛上做故障排查。作者一针见血：如果团队之前连基础遥测都不愿接入，凭什么会为你搭建一个权限全开的 MCP 服务器？数据获取才是瓶颈，不是数据访问的方式。大部分组织连统一的观测管道都没有，文档陈旧、依赖图缺失，强行上代理只会产出更多幻觉。想让 AI 达到一丁点实用程度，需要先花费巨大工程精力去治理数据、维护文档，而这恰恰是业务团队无暇顾及的。
厂商自己都不信自己的产品。
AI 编码工具大肆宣扬代理开发的威力，但自家命令行工具却用 JavaScript 写成，内存占用巨大，全然不顾性能最优的语言（如 Go）。如果它们真信任自己的技术，就该用 AI 生成一套 Go 写的轻量工具，而不是让用户承受 Node.js 运行时的负担。
企业软件的护城河将不再是功能，而是文档。
简单工具确实能被 AI 轻松复制，但企业购买的是责任和专家支持。当系统崩溃时，需要有人背锅、有人救火。未来，企业软件商可能会封闭详细文档，只向付费客户通过专用 AI 提供，以此防止用户用通用 AI 轻易复制领域知识或叉出竞品。
基础设施即代码（IaC）是 AI 的滑铁卢。
出乎意料，AI 对 HCL、YAML 这类声明式配置的处理很糟糕。原因包括：声明式代码缺乏意图线索，模型难以推断；基础设施领域分支（fork）多、提供商杂，AI 常混用不同平台的特性或虚构参数；测试成本极高，反馈循环慢，代理往往在反复失败后直接推倒重来，无法完成多组件集成。
最终建议：关掉噪音，专注核心，要求演示。
作者认为，现在任何人都可以用 AI 做出一个半吊子原型，但真正困难的“第二天运维”（day-2 maintenance）才是照妖镜。面对铺天盖地的 AI 神器宣传，不妨冷静地问一句：“能给我看一下它在实际生产环境中运行的 demo 吗？”