工程学是关于限制的艺术。如果不理解 AI 的局限性，我们就无法真正驾驭它。
在拥抱“人机共生”的愿景之前，我们必须先进行一场**“祛魅”。AI 不是全知全能的神，它是一个有着明显缺陷、高昂代价且极不稳定的概率机器。软件工程 3.0 的核心，不仅在于利用 AI 的能力，更在于管理 AI 的局限**。
首先，我们必须正视“幻觉”这一不可消除的概率幽灵。
**幻觉（Hallucination）不是 Bug，而是 LLM 的 Feature（特性）。它的创造力与胡说八道同源，都来自对概率的预测。因此，工程底线必须建立在零信任（Zero Trust）**之上。
我们不能依赖 AI 的“自觉”，必须引入确定性校验机制（如编译器、静态分析工具、单元测试）作为“裁判”。同时，应采用结构化约束，不要问“这段代码怎么写”，而要问“请填充这个 JSON 结构的字段”，通过 JSON Schema 等强制 AI 在轨道上运行。最重要的是，在关键决策点（如合并代码、生产部署），人类的 Review 永远不可省略，人必须作为最终的防线。
其次，我们需要警惕“上下文困境”，不要迷失在 100 万 Token 的迷宫中。
虽然营销术语在大肆宣扬超长上下文，但研究表明，AI 对长上下文中间部分的信息提取能力显著下降（Lost in the Middle），且塞入的信息越多，AI 对关键指令的注意力就越分散（注意力稀释），更不用说每次请求都带上整个代码库带来的天文数字般的成本。
工程策略应遵循“结构大于容量”的原则。 我们不应盲目追求无限大的 上下文窗口(Context Window)，而应追求更高信噪比的上下文（Context)。对于超大项目，单纯的文本切片检索已不足够，必须构建代码的依赖关系图谱，让 AI 沿着逻辑链路（而非文字相似度）获取上下文，即 知识图谱 (Knowledge Graph) 优于简单的 向量检索 (Vector Search)。
再次，我们要面对“西绪福斯困境”，即如何对抗模型迭代带来的熵增。
AI 模型大约每 6 个月迭代一代，而 Prompt 是一种非确定性的 API，模型微小的更新都可能导致原有 Prompt 失效（Prompt Drift）。为了应对这种不稳定性，我们需要采取模型无关性设计 (Model-Agnostic Design)。严禁在业务代码中直接硬编码特定模型的 Prompt，而应建立统一网关（Unified Gateway）和Prompt 仓库进行中间层隔离。此外，建立自动化的 评估流水线 (Eval Pipeline) 至关重要，在每次模型升级前运行回归测试，确保核心指令的输出稳定性。
最后，我们不能忽视智能的代价，必须建立算力经济学意识。
AI 是一种昂贵的计算资源。用 GPT-4 生成一个简单的 Getter/Setter 方法，在经济上是极其愚蠢的。因此，工程上应实施分级路由 (Tiered Routing) 策略。对于复杂架构设计、Bug 根因分析，使用“牛刀”如 GPT-4 / Claude 3 Opus；对于代码补全、文档生成等流水线作业，使用 GPT-3.5 / Haiku / 本地模型；而对于确定性高的任务，优先使用传统静态分析工具，而非盲目使用 AI，实现“计算换智能”。
软件工程 3.0 不是盲目崇拜 AI，而是要在“概率性的 AI”之上，构建“确定性的系统”。 只有深刻理解并敬畏这些边界，我们才能在悬崖边跳出最优雅的舞蹈。
