我们注意到一个值得正视的现象：越来越多企业 AI 项目卡在落地，不是模型不够强，而是工程基本功没做。一支技术团队本周复盘的故障案例把这个事说清楚了 — 大模型输出格式错乱、关键约束丢失，根因不在模型本身，而在提示词没结构化、用户输入没隔离、输出没校验。

这是什么

这是一家技术团队的故障复盘。场景很典型：业务方用大模型自动生成文档，要求严格控制字数、固定格式、文末带结束语。结果输出经常不达标 — 格式乱了、字数超了、结束语没了。

排查后四个根因浮出水面：

第一，提示词把系统约束、用户输入、格式要求混在一起写，模型分不清谁优先；第二，没有用分隔符（占位符）把用户输入和系统指令隔开，用户输入直接污染了系统规则；第三，代码层没做长度校验，长文本触发模型上下文窗口（即模型一次能读多少字的上限）截断，约束被吃掉；第四，模型输出不合规时，程序不做检查就照单全收，没有重试机制。

修复方案也很朴素：把提示词分成「角色—任务—约束—用户输入」四段，用占位符隔离，输出做关键字校验，不合格就重试。

行业怎么看

这个案例折射出 Andrew Ng（吴恩达）近期反复提到的一个判断 — 90% 的 Agent（能自主执行多步任务的 AI 助手）项目卡在落地，瓶颈往往不是模型智能，而是工程化能力。换句话说，今天大量「AI 项目失败」的锅，不该甩给模型厂商。

但也有反对声音值得听：企业方会说，模型 API（应用程序编程接口）的错误反馈、上下文管理本来就乱，厂商难辞其咎。一种代表性意见是 — 「提示词工程」（prompt engineering，即设计让模型稳定输出指令的方法）被神化了，它本质上是补 API 设计缺陷的补丁，真正的解法是模型侧提供更强的结构化能力。

另一面容易被忽略：这些基本功不性感，传统企业 CTO（首席技术官）不想做、预算不愿投。结果就是模型换了一代又一代，业务侧的稳定性没改善。

对普通人的影响

对企业 IT 负责人：内部 AI 项目如果反复翻车，先别升级模型版本，先回去查提示词结构、输入隔离、输出校验这三条线。

对个人职场：能把提示词写成「四段式结构化模板」的人，在接下来两年会成为隐性优势 — 不只是产品经理和工程师，连运营、市场、财务岗都会用到。

对消费市场：面向 C 端（个人消费者）的 AI 产品稳定性问题短期内不会有显著改善，付费意愿和留存率都会被拖累。