几年前，开发内部AI工具需依赖专业工程师团队。如今，运营主管或CEO只需将大模型连接至公司系统，数天内即可搭建可用原型。据Gartner预测，到2026年底，40%的企业应用将包含特定任务的AI智能体，而2025年这一比例不足5%。
然而，许多原型在初步验证后便陷入停滞。不同行业的企业往往撞上相同的“墙壁”。美国汽车零部件制造商S&B Filters的案例极具代表性：其CEO Berry Carter通过模型上下文协议（MCP）将Claude与NetSuite连接，构建了一个用于查询订单状态的助手。虽然原型验证了可行性，但每次响应耗时4-6分钟，且依赖长达40页的提示词（Prompt）。工程团队并未直接修补该原型，而是基于生产级架构进行重构，最终将开发周期从数月缩短至数周。
墙1：回归螺旋
表现：修复一处问题导致其他功能失效，修改单一规则无法保证整体稳定性。
S&B困境：庞大的提示词包含所有业务规则，难以安全重构。
解决方案：
- 保留知识而非提示词：将提示词转化为需求文档，拆分工作流。让助手判断意图并调用独立工具（如订单查询、库存检查），每个工具拥有专属指令。
- 构建真实测试集：基于真实对话和工单建立包含100多个用例的测试集，确保在用户发现问题前拦截错误。
墙2：静默失败的集成
表现：部分数据返回不完整或错误，难以定位是集成、模型还是提示词的问题。
S&B困境：输入格式混乱；NetSuite中零件编号存在大量非成品子组件，导致匹配错误；知识库文本引发幻觉。
解决方案：
- 输入规范化：在数据进入系统前跨格式验证，建立标识符回退机制（如销售订单号→PO号→客户参考号）。
- 动态选择事实来源：针对具体问题选择最准确的数据源。S&B将零件编号查询指向Shopify SKU，而非NetSuite。
- 结构化数据优先：事实性问题直接查询结构化数据库，文档仅用于解释。助手直接搜索适配数据并询问缺失细节，而非猜测。
墙3：对你有效，对他人无效
表现：开发者演示完美，但实际用户遭遇体验不佳。
S&B困境：原型仅适配创建者，未考虑支持代理的高效需求及网站客户的秒级响应期待。
解决方案：
- 使用混乱的真实输入测试：提取包含拼写错误的真实工单和聊天日志进行测试。
- 预设速度目标：根据用户等待容忍度决定架构。S&B因此采用直接从ERP检索数据和流式响应方案。
- 分众设计，核心共用：采用同一后端架构，分别开发面向代理的内部助手和面向客户的网站助手前端。
墙4：问题不可见
表现：系统缺乏日志记录，故障排查如同猜谜。
S&B困境：上线后发现大量知识缺口，但无法快速定位高频问题。
解决方案：
- 人类可审查的记录：审查真实聊天记录而非仅看聚合数据。
- 聚焦高频缺口：从数百个缺口中筛选出Top 5–10项优先处理。
- 设计人工交接流程：工作时间内，AI生成摘要并转接人工，保留完整上下文；非工作时间创建工单。明确AI失效后的处理路径。
墙5：冻结状态
表现：因害怕破坏现有功能而停止更新。
S&B困境：业务规则嵌入代码，每次更新需修改提示词，风险极高。
解决方案：
- 知识外置：将产品内容存储在与OneDrive连接的知识层中，更新无需重新部署，并通过可见性规则隔离内部信息。
- 小步迭代：新功能谨慎推出。例如自动化邮件工单初期仅限订单状态、周末运行，并明确标注AI生成及提供转人工选项。
最终成果
首个生产级模块——面向支持代理的内部订单状态助手——在约四周内上线。首次响应速度提升98%，从几分钟缩短至几秒。第二季度，约5,600名网站访客使用该助手，83%的请求在未人工介入的情况下得到解决。
S&B Filters CEO Berry Carter表示：“最初构建的解决方案因我个人编写而缓慢……现在技术人员能在15秒内获取所有信息，这非常棒。”
工程师的重构顺序
- 挖掘原型：收集提示词、真实对话和边缘情况，区分需保留的逻辑与需重构的架构。
- 构建测试集：基于真实问题，在任何代码更改前完成。
- 修复数据层：确定事实来源，规范化输入，实施结构化查询。
- 重构架构：用工具调用替代巨型提示词，设定延迟目标，将知识移出代码。
- 增加可见性与交接：监控系统状态，捕获AI无法处理的情况。
- 分阶段推出：按用例、渠道和受众逐步扩展。
这种“重建引擎而非重新发现产品”的方法，使得“数周而非数月”的开发周期成为现实。
推广原型前的自查清单
- 能否列出原型能良好回答的真实问题示例？
- 是否在最混乱的真实输入上测试过？
- 是否明确每种问题的唯一事实来源系统？
- 事实性答案是否来自结构化数据而非文档推断？
- 是否有明确的响应速度目标？
- AI失效时，谁接手对话？他们是否拥有完整上下文？
- 非技术人员能否在不接触代码的情况下更新内容？
若多数答案为“否”，原型并未失败，它已证明想法可行。下一步，是为其构建坚实的基础。