AI产品的可靠性挑战正在颠覆传统产品思维。从得物团队的实战数据到Bloomberg Law的行业警示，本文深度剖析AI在执行规范时70%的失效率如何威胁业务闭环，并揭示从Prompt优化到工程兜底的认知跃迁——用确定性系统对抗概率性输出，才是AI产品经理真正的价值锚点。

1. 我先给自己泼盆冷水：AI不是万能执行者

做AI产品这两年，我一度挺乐观的。觉得只要把Prompt拆细、RAG搭好，再配上精心设计的few-shot示例，模型应该能跟一个干了三年的老员工差不多——稳住底线，不出大错。甚至跟算法同事吹过牛：“你看，让GPT记几条规范，它背得比我还熟。” 结果呢？上周五就栽了。我拿一个中等体量的项目做压力测试，故意让AI在长上下文中连续跑15步推理。前5步一切正常。第6步开始，它把前面确定的输出格式忘了。第11步直接凭空捏了个不存在的参数。翻日志一看，上下文窗口已经被之前无关的讨论撑到快炸了。模型就像个上了年纪的图书管理员，不是不认真，是书太多，找不着了。

真正让我心头一紧的，是得物团队那个数据。他们统计过，在项目紧张的情况下，人工盯规范的比率会掉到60%–70%，而AI所谓“记忆”的规范执行率也只有70%–80%。注意，这不是实验室里测出来的，是真实上线跑出来的。我算过一笔账：如果一个任务需要遵守10条规范，70%的执行率意味着平均每三次处理就有一次会漏掉至少一条规则——而业务场景里往往是一环扣一环，漏一条就可能整个流程崩塌。上周Bloomberg Law有篇报道也在谈这个，说成长阶段的公司需要可扩展的AI合规框架，关键是一样的：你不能指望模型自己管住自己，尤其是在上下文膨胀、压力陡增的时候。

坦白讲，这盆冷水泼得值。我一直以为“把规范写进系统”是锦上添花的事——先把模型能力搞对，再考虑工程兜底。现在发现这顺序反了。模型的不确定性不是Bug，是它的天性。而我们这些做产品的，最怕的就是把产品建立在天性之上。70%不是不够好，是在生产环境里它等于“随时可能出事”。当时我意识到，如果继续相信AI能靠自我纠错把执行率拉满，那最终被坑的只会是我自己，以及信任这个产品的用户。所以得换个思路：别指望模型记住每一条规则，用工程的确定性去兜底不靠谱的AI记忆。

2. 为什么AI也会“失忆”？我拆了三个场景

我拆了三个场景。先说人工盯规范。这条防线看着最底层，其实最脆。项目一紧张。人就会抄近路。不是团队不负责。是大脑根本不擅长这种活——每行都要对一遍规则。上周复盘一个紧急上线，开发在压力下把样式规范检查表跳过了三页。理由：先跑通再说。我们拉了数据。正常节奏下人工遵守率能到80%左右。一旦赶deadline，直接掉到60%-70%。这已经拼尽全力了。指望人肉维持标准？等于把铁轨铺在沙子上。今天能跑，明天就不一定。我那时才明白，“规范”如果只写在文档里、贴在墙上，它等于不存在。

AI的记忆。喂同样一份规范文档，简单任务能记住95%，可一旦任务复杂——比如一个页面十几个组件，每个组件三四层交互——AI开始丢东西。它不会告诉你。输出看起来像模像样。但某一步的圆角半径变成0px。或者某个按钮的点击区域尺寸缩了。我找工程师做了压力测试。中等复杂度下，AI执行率只有70%-80%。每五次执行，就有一到两次走样。对严谨的交付流程来说，这个波动是灾难——没人知道哪次上线会带个小尾巴。我意识到，AI的“记忆”不是硬盘。更像会议上的速记员：记着记着，前面的话被后面的话盖掉了。

复杂需求。我试过一个比较大的模块重构，让AI先拆成20个子任务，每个子任务对应几条规范约束。前三个很顺。到第七八个，它开始把第四步的“禁用弹窗”条件错误地延续到第十一步。而且这种退化不是线性的——上下文冲到某个长度阈值时，执行率断崖式下跌。像开会开到后半程，突然想不起来开头定下的原则。上周四我看到一篇报道，研究者提到AI驱动的漏洞利用窗口已经缩小到几小时。这背后是模型对上下文敏感度的脆弱——复杂任务里一点点偏差就会被放大。对我来说，这个场景直接指向一个结论：需求越大，AI越容易“失忆”，而且没人能预测它会在哪一步忘。所以靠模型自己记住每一条规则，根本不现实。我不再指望加几个few-shot示例就能搞定。

3. 观念转变：从“相信AI自我纠错”到“设计系统强制兜底”

拆完那三个场景，我愣在工位上。不是技术问题。是方向问题。我一直在琢磨怎么让AI记住更多规范。怎么把Prompt写得滴水不漏。怎么设计更好的few-shot让模型自己纠错。但事实摆在这里：上下文一冲，模型就是会忘。而且这种遗忘，不是靠补课能解决的。上周四那条新闻让我更确信——攻击者响应时间压缩到几小时，我们却还指望AI在执行到第18步时记得第3步的约束。这不合理。然后看到得物团队的Harness概念。第一反应：这名字起得挺硬。但读完之后头皮发麻。他们根本不纠结怎么让AI记住规范，直接写代码做“护栏”。把执行规范变成系统级检查机制。在AI输出前后用hooks和自动化工具拦截、校验。这不是优化。这是换了一条路。

这个转变意味着什么？我给自己打了个比方。之前我的思路是：给AI一本交通规则手册，让它背下来。然后指望每次上路它都自觉遵守。但现实呢？AI开到第10个路口时，可能已经把“红灯停”记成了“黄灯也停”。Harness的思路：别只靠司机的觉悟。直接在路上装红绿灯、装摄像头、装自动栏杆。你AI可以开得很快，但到了红灯口，系统物理上不让你过。这就是产品思维的分水岭。我过去总想“教好”模型，现在我知道，有些约束天生不适合靠模型“记住”，必须靠系统强制执行。比如规范里明确写“用户未登录时禁用弹窗”。这种边界是硬约束。不应该留给AI去判断“这个场景下弹窗算不算违规”。直接写一个hook，在AI输出任何包含弹窗逻辑的代码之前，先检查上下文里是否包含“已登录”条件。不满足就拦截，返回一个标准错误信息。简单粗暴。但可靠。

想通这一点后，我的角色定义也变了。以前AI产品经理的核心工作是写Prompt、调RAG、选few-shot，本质上是在给模型当“补习老师”。现在我得重新画一条线：哪些规范可以放心交给AI去灵活执行，哪些必须由系统强制托管；哪些责任可以放权给模型的泛化能力，哪些必须由工程团队写死。我的判断标准很简单：凡是涉及用户安全、合规、核心业务逻辑的硬约束，全都交给Harness；凡是风格偏好、排版美观、文案语气这类可以容忍变化的，才让AI自己发挥。这个分类本身就是产品决策，而且每一步都要跟算法、工程、法务反复确认认知一致——因为一旦你把一条硬约束放给了模型，后面出了事故，没人会怪模型，只会怪产品经理没有做好兜底。有了这个认知框架，我才真正理解什么叫“工程的确定性对抗AI的不确定性”。下一节，我要动手搭“护栏”了。

4. 落地“护栏”实战：hooks、自动化与灰度节奏

想清楚那条线。动手。第一个动作特别朴实：代码生成后、合并到主分支之前，插一个自动化检查的 hook。之前团队里人工遵守规范的比率撑死了六到七成。AI 自己记规范也就七八成。等于每十次就有两三次漏掉关键约束。hooks 逻辑？简单。把安全规则、命名规范、敏感信息过滤这些“高频率、低容忍”的东西写成确定性的校验脚本。AI 输出的东西先过一遍脚本。违反的直接拒绝。返回具体的错误信息让人工修正——别让 AI 自己瞎改。上周我拿一个小模块试跑。头三天就拦住了六次误用敏感接口的情况。换成以前，这些错得等到测试上线才被发现。代价是前端要多写几百行校验代码。但跟反复返工的成本比起来，这笔账太划算了。

灰度节奏是我额外加的一道保险。我没敢一口气全量上 hooks。先挑了一个中等复杂度的子模块试跑。每天盯两个指标：坏 case 率和开发效率变化。第一个星期坏 case 率从 12% 直接降到 1.5%。但开发效率也降了 8%。每次被拦下来，人得盯着错误信息去改。流程变长了。我跟算法同学商量，把校验报错的信息格式改成直接定位到行号+建议修正代码。开发效率很快又拉回 95%。这时候我才敢往其他模块铺。刚好看到 5 月 19 号那篇关于 AI 漏洞窗口缩小到小时级别的报道。我更加确信了：威胁响应窗口在变短。依赖人工或 AI 记忆去守底线已经来不及。只有工程层面的确定性检查能兜住。

执行率接近 100%。但这还不是最爽的。最爽的是“失忆率”的变化。以前 AI 稍微一大段上下文就忘掉前几条规范。现在 hooks 把基础约束写死之后，喂给大模型的上下文干净了。它不需要记“不要泄露用户手机号”“不要用弱类型”这些琐事。只需要专心处理业务逻辑。这个月跑下来，同一份需求下 AI 反复犯同类错误的比例降了六成以上。代价是产品经理要多花 20% 的精力去梳理哪些规范需要写进校验脚本、哪些可以做增量更新。但比起之前整天追着 AI 屁股后面改 prompt，我现在更愿意把时间花在设计工程护栏上。就是这样。

5. 收个尾：AI产品经理的终点不是模型能力，是可靠性工程

这一个月走下来，我最大的感受不是“AI变强了”，而是“我敢放手让AI干活了”。之前每次推线上，心里都悬着——它这次会不会忘了一条关键规范？上下文多了会不会乱？现在hooks把底层约束焊死，自动化校验在合并前拦一道，灰度分期慢慢放量。心态变了：从“祈祷它别出错”变成“出错也没关系，系统会兜住”。这种安全感不是来自模型本身，是来自我亲手搭的那套工程护栏。上周看到一篇报道说AI能让漏洞窗口缩小到小时级，我第一反应不是兴奋。更确定了一件事：如果漏洞窗口在缩小，那错误窗口也在缩小。系统越敏捷，越需要工程级的刚性约束来兜底，否则敏捷只会放大混乱。这是我现在的想法。

得物团队说他们的目标是消除开发过程中的不确定性。我认同这个方向，但“消除”这个词可能太绝对了。我更愿意说：把不确定性框在一个可接受的范围内。AI的不确定性是它的本性，上下文遗忘、概率输出、边界漂移，这些东西不会因为Prompt写得漂亮就消失。真正的解法是用工程的确定性去对抗AI的不确定性——把那些不能讨价还价的规则写进校验脚本，把需要持续迭代的业务逻辑留给模型去发挥。产品经理的角色也跟着变了。以前天天琢磨“怎么让模型记住更多东西”，现在琢磨“哪些东西根本不需要模型记，直接写成规则让系统执行”。前者是跟模型较劲，后者是跟系统协作。我这么看。

AI产品经理的终点不是模型能力，是可靠性工程。模型会迭代，能力会上限。但用户要的不是一个偶尔惊艳、经常翻车的产品，而是一个稳定可预期的工具。与其赌下一次模型更新能把失忆率降到零，不如现在就动手搭护栏。让AI在安全区内自由地发挥它的创造力，同时用工程兜住它一定会犯的那些错。这就是我做AI产品这两年学到的最实在的东西。