人工智能不是值得信赖的——而是需要精心设计的（系列终篇）

一句话看懂：airCloset CTO Ryan 在其AI平台“Cortex”系列文章的最终篇中，从技术实现退回到底层逻辑，指出AI系统的核心问题不是“不够智能”，而是无法可靠理解复杂业务系统，并分享了亲身经历的技术陷阱：上下文窗口和模型微调这两条主流路径，在实践中都行不通。

事件核心：发生了什么

Ryan 在完成Cortex平台的五个技术组件（产品图、自动PR审查、自愈与观察、非工程师PR）开发后，于系列终篇中反思了 AI 工程的核心瓶颈。他明确表示，2025年启动该项目时的核心问题“如何让AI准确理解系统”，至今没有通过扩大模型能力得到直接解决。

他具体指出了两条“死胡同”：第一，传统的“塞满上下文窗口”策略，即便使用 Gemini 等长上下文模型，也会遭遇“丢失在中段”现象——中间信息被模型忽略，且由于 LLM 不会主动承认自己不知道，错误信息会以自信的语气输出。第二，组织级别的模型微调，在2025-2026年仍处于研究阶段，且最大障碍是无法高效“删除”旧知识：当业务规则变更时，模型权重的固化让遗忘变得极为困难。

为什么重要

这一反思对当前 AI 工程化浪潮具有直接预警意义。业界的普遍叙事是“模型能力增长、上下文窗口扩大，AI就能接管一切工作”，但Ryan的实践给出了反向证据：信息结构化程度、而非模型参数大小，才是AI能否做出正确判断的根本瓶颈。这不是某个具体模型的缺陷，而是Transformer架构在长序列输入中固有的注意力分配问题，且递归地无法通过增加窗口大小解决。

这意味着，依赖“更强大模型”来解决业务系统理解问题的预期，可能需要重新校准。企业若直接照搬“把全部文档和代码丢给AI”的方式，最终将得到表面自信却隐性错误的输出，这在PR审查、事故自愈等高风险场景中尤为危险。

对用户/开发者/创作者的影响

对企业开发者与CTO：实际部署AI到关键业务流程前，必须优先解决信息结构化。Ryan的做法是构建“知识图谱”（Cortex Product Graph），将代码、文档、数据库Schema、基础设施统一为图结构，而非单纯依赖模型的原生理解。如果你正准备将AI引入代码审查或运维，需要思考：你提供的信息是否已经按照机器能理解的方式组织过，而不是堆砌全文。

AI 工具推荐

想把多个 AI 模型放在一个入口？

GamsGo AI 集成 ChatGPT、DeepSeek、Gemini、Claude、Midjourney、Veo 等常用模型，适合写作、绘图、视频和日常 AI 工作流。

了解 GamsGo AI

推广链接：通过此链接购买，我可能获得佣金，不影响你的价格。

对AI工具的使用者：当面对AI给出的建议时，不能因为输出“专业且自信”就假定它是对的。Ryan指出，LLM “沉默地错误比卡住更可怕”。在审查AI生成的PR、文档或代码片段时，需要更严格的验证流程，尤其是当模型使用了大量上下文时，中间部分的信息很可能已被忽略。

对模型供应商与大模型研发团队：这是一个市场信号：单纯拼上下文窗口长度或模型规模，可能不是企业客户最需要的价值。帮助开发者高效地“清理和遗忘”模型中的旧知识，或者提供更好的结构化输入方案，可能是下一个竞争焦点。

值得关注的后续

1. Cortex平台的商业化路径：airCloset 内部搭建的AI平台“核心思想来源于实践，而非模型突破”，这篇总结是否意味着他们会将这套模式开源或产品化？对于其他企业而言，要复制这套“结构化图+持续审核”的体系，成本仍然很高。

2. “模型遗忘”技术的进展：Ryan指出的微调后无法高效删除旧知识的问题，是业界公认的难题。2026年是否会有新的“可编辑模型权重”或“增量遗忘”技术进入生产环境值得关注。

3. 上下文窗口策略的路线调整：Ryan明确不看好只靠扩大窗口解决工程问题，这一判断与Google等厂商大力推广例如1M+上下文窗口的策略形成正面对撞。后续业界是否会出现更多像“结构化输入优先”的第三方解决方案，以弥补大模型自身的注意力缺陷，将是重要的行业风向。

来源：dev.to