AI这几年把我一个很顽固的观念彻底砸碎了我一直以为所谓“智能”也好“规则”也好总该有个确定性的底座AI再强也是在这个底座上做优化。但直到我亲自把一个带有大模型推理模块的项目从零推到上线又在无数个夜里被幻觉、边界、失效的提示词折腾到怀疑人生我才慢慢意识到AI带来的根本不是“更强的工具”而是一整套关于规则的元规则被重写了。我们正在从“有限游戏”进入“无限游戏”——前者以取胜为目标后者以延续游戏本身为目的。这篇文章想聊的就是这种重构是怎么发生的、在工程上怎么应对、在思维上又该怎么转身。适合正在做AI产品、搞模型部署、写Agent的工程师也适合那些被AI搞得既兴奋又焦虑的产品经理和技术管理者。我会把技术细节和哲学判断揉在一起讲因为这两件事在这个话题下根本分不开。1. 有限游戏的终结AI如何击穿传统规则体系1.1 传统工程的“有限游戏”底色传统软件工程的核心假设是“规则完备性”——需求写清楚、接口定明白、边界划干净系统就能稳定运行。我们习惯把业务逻辑拆成if-else把流程画成泳道图把异常处理列成清单。规则定义得越完备系统的行为就越可预测。这种思维范式本质上是有限游戏目标明确、规则固定、赢家判定清晰。你写完一个模块它该干什么、不该干什么在编译期就该确定下来。我早期做传统后端的时候最自豪的事情就是把各种边界条件穷举干净让测试覆盖率逼近百分之百。那是一个“把规则推到极致”就能赢的游戏。你不需要考虑规则之外的事情因为规则已经替你挡掉了所有不确定性。但AI直接把这张桌子掀了。大模型的核心能力不是执行规则而是“在没有规则的地方生成规则”。它给出的答案不是一个查表结果而是在统计分布上最合理的下一段字词组合。这意味着你没法再用穷举的方式去定义它的行为。曾经稳定的“规则-执行-验证”闭环在生成式AI面前出现了裂缝。1.2 从“规则执行”到“规则涌现”这里有个根本性的转变值得反复咀嚼。传统程序是“规则→执行→输出”规则先于行为存在而大模型是“数据→训练→能力”行为从海量数据中涌现训练完成后你可以用提示词去引导它生成规则但规则本身并不以显式的、可审查的代码形式存在。我用一个生活化的类比来说明。传统程序像一个遵守交通法规的司机法规写在哪、怎么处罚全部明确。AI则像一个在驾驶学校看了无数案例的新手他没有背下每一条法规但面对路况时能做出大体正确的判断。问题是你没法精确预判他在某个具体路口会怎么操作。他的“规则”是隐性的、概率性的、语境依赖的。这种“规则涌现”带来的后果是你需要监控的不再是一个确定性的输出而是一个概率分布。你必须接受同样的输入今天和明天可能得到不同的回答同样的模型换一个引导词可能产生完全不同的行为模式。传统工程中“规则即契约”的稳定性在这里会被替换成“能力即服务”的弹性。你在设计系统时目标从“让行为固定”变成了“让行为可控”。1.3 规则重构的三种具体形态把“规则被重构”这句话落到实操层面我总结出三种最明显的变化形态。第一种是规则来源的重构。以前规则是产品经理和工程师一起写的现在规则是从数据里“长”出来的。你投喂什么语料、用什么方式清洗、怎么标注偏好模型就会内化什么样的行为准则。数据和价值观第一次如此直接地成为了代码的一部分。第二种是规则粒度的重构。以前规则是全局统一的——一个权限系统管所有用户一个校验逻辑管所有请求。现在AI让你可以在运行时为每一次请求生成专属的“微规则”。通过RAG塞入特定知识通过few-shot让模型适应某个风格通过角色注入让模型扮演特定身份。规则的粒度从“系统级”降到了“会话级”甚至“token级”。第三种是规则时效性的重构。传统规则的更新要发版、要灰度、要回滚AI的规则可以通过提示词、微调、检索库实时调整。今天客户不喜欢你的回复风格你改一段系统提示词马上就能上线。规则从“静态固化的石碑”变成了“持续流动的活水”。这三种重构叠加在一起意味着整个系统的行为边界变得模糊且动态。你不再能回答“系统支持什么、不支持什么”因为答案每天都在变。这就是无限游戏的第一课你无法用固定规则去应对一个会自我演变对手。2. 从提示词到Agent规则动态化的工程路径2.1 提示词不是咒语是规则的驯化接口很多人把提示词工程理解为“和AI说话的艺术”这低估了它的分量。我的看法是提示词是你和AI之间唯一稳定的规则协商接口。在有限游戏里需求文档是项目成员之间的契约在AI系统里提示词就是人机之间的契约。实际操作中我习惯把提示词当成一种“动态配置文件”来写而不是当成聊天语句来写。里面的每个模块都要有明确的功能定位角色设定负责约束语气和立场任务描述负责说明目标和输出格式约束条件负责划出行为边界few-shot示例负责给出参考范式。每一条提示词都是一次对模型行为的局部规则注入。这里有个容易踩的坑提示词越长不一定越有效但结构化的提示词一定比口语化的提示词更可控。我做过一个客服摘要项目最初的提示词只有“请总结客服对话”结果输出的摘要时好时坏。后来我把它拆成了角色、任务、步骤、输出格式、边界声明五段稳定性立刻上来了。原因是模型的注意力机制会对结构化文本中的指令位置更加敏感你给它明确的层次它就能更好地扮演那个角色。2.2 Agent的自我博弈规则在运行中被协商如果说提示词是“规则的静态注入”那么Agent就是“规则的动态协商”。一个成熟的Agent架构不再是一问一答的直接映射而是一个“目标→规划→工具调用→结果观察→反思→再规划”的循环。每一次循环里Agent会根据上一步的结果动态调整自己的策略。这已经不是在执行规则而是在一个给定的目标函数下不断重写自己的“行为规则”。我参与过一个用Agent做代码缺陷分析的项目。刚开始我们试图用规则库去定义所有缺陷模式结果发现新问题层出不穷规则库根本维护不过来。后来我们换了一种设计给Agent一个任务声明让它自己读代码、跑测试、查文档再让它决定下一步怎么办。它有时候会先跑一遍单测看看哪些用例失败有时候会直接去查Changelog找变更点行为路径完全不固定。但最终效果反而更好因为它能在运行期依据上下文临时协调规则而不是被我们预先写死的逻辑锁死。这个转变的工程意义非常大。规则不再是被“提前定义”然后“执行”的东西而是在“目标引导”下“生成”出来的过程行为。你要监控的不再是一个具体的输出而是一个Agent的决策轨迹。这也是为什么现在越来越多团队开始做Agent的可观测性把思考日志、工具调用记录、中间结果都保存下来否则你根本不知道它为什么这么做。2.3 多模型协作规则的市场化竞争当Agent开始调用多个模型或者不同AI系统之间开始协作“规则”就进入了一种类市场化的竞争状态。比如一个系统里有负责理解的模型A有负责规划的模型B有负责生成的模型C还有负责校验的模型D。它们各自的输出会相互影响但不存在一个集中的、统一指挥的规则制定者。整体行为是多方博弈的结果。我在搭建这类系统时通常会让主模型担任“路由仲裁者”的角色由它决定当前任务要交给哪个子模型、以什么优先级处理。这个路由策略本身可以在运行时通过主模型的推理来动态生成而不是写死在代码里。这相当于把“规则的选择权”也交给了模型。系统级的规则从这个角度看已经不是在“被执行”而是在“被协商”。这对传统架构有什么冲击最直观的一点是你可以通过调整某个子模型的权重、温度、系统提示词来间接影响整体规则协商的结果。但你没法通过一次代码修改来固定整个系统的行为。你必须接受系统的“行为空间”比过去大得多并围绕这个更大的空间来设计监控和干预机制。3. 部署与迭代无限游戏思维下的实操要点3.1 模型部署本地化与混合架构的取舍规则动态化带来的第一个工程难题是部署的弹性。你是用云端API还是本地部署还是混合架构这个问题没有唯一答案但可以按照数据的敏感度和延迟要求来做决策。云端API适合对数据安全要求不高、需要快速迭代验证的场景。我之前做过一个内部知识库问答工具数据不算机密直接用了大模型的托管API一周就上线了。优点是省心缺点是上下文太长时成本会飙升。本地部署则适合数据敏感、或需要离线运行的场景。我踩过一个坑没有考虑推理服务器的显存瓶颈量化后的模型效果损失明显又得换回完整精度最终被迫买了两块更大显存的卡。如果你也做本地部署我建议优先考虑这几个参数量化级别4-bit、8-bit还是FP16上下文窗口长度决定单次请求的最大token数以及并发数。尤其是并发数很多人第一版就按传统服务的思维去压测结果一个模型服务在10个并发请求下延迟直接爆炸。推理服务不像Web服务算力是硬约束你要么限流、要么排队、要么多副本没有银弹。混合架构是我目前比较推荐的模式敏感数据走本地小模型做初筛非敏感内容交给云端大模型做精细化处理。这个方案能兼顾成本和隐私代价是要多维护一套路由和脱敏逻辑。但在这个规则动态化的时代多点弹性总比单点脆弱要好。3.2 可观测性优先动态规则下如何做监控传统监控是针对固定行为的响应时间、错误码、吞吐量。AI系统的监控需要升级你不光要关心服务有没有返回还要关心返回的质量稳不稳定。我把这种监控称为“行为质量的可观测性”。具体来说我建议至少记录四类日志完整输入输出、模型的不确定性指标比如logprob或置信度、所调用的工具或检索到的上下文、以及最终结果是否被人工修正。这些数据能让你在系统行为“跑偏”的时候快速定位问题是出在提示词、上下文还是底层模型而不至于对着一个黑盒瞎猜。有一个很实用的操作在测试环境里建立一条“黄金回流”通道。把生产环境里用户反馈好的回答抽出来存成标准样例每次调整提示词或者换模型版本就拿这批样例做回归比对。这样做的好处是你能在一个相对固定的评估集上观察规则变化的影响范围避免顾此失彼。3.3 测试策略从断言到分布从用例到评估集传统测试的思维是“断言”——输入a必须输出b否则就是bug。AI系统的输出天然存在多样性断言型测试只能覆盖极小部分场景。更合理的做法是“分布型测试”对于一个输入只要输出落在一个可接受的行为空间内就算通过。举个例子你让AI写一段产品文案只要语义契合主题、没有违规内容、风格符合要求哪怕每次文字不完全一样都算通过。我经常用“评估集评分函数”的组合来实现这种测试准备一批有代表性的输入然后让裁判模型或规则打分器对输出质量进行评分只要平均分和最低分超过阈值就算通过。这样做的代价是测试成本远高于传统单元测试但收益是你能在“规则不确定”的前提下保住系统的底线。记得把评估集当成代码一样维护新增需求时把典型的新场景加进去回归时跑一遍全量。评估集就是你在无限游戏里的“规则锚点”。4. 问题与边界无限游戏的暗面4.1 幻觉与失控规则生成的另一面所有AI从业者都绕不开幻觉这个话题。幻觉的本质是模型在生成“合理但错误”的规则。它不是在胡言乱语而是在统计分布上杜撰了一个听起来很权威的答案。这是无限游戏的必然暗面一个擅长生成规则的系统必然也会生成错误的规则。我在实际项目中总结出一套缓解幻觉的组合拳第一强制模型在输出时引用信息来源拿不到的就不准说第二增加一个检索步骤让模型先查资料再回答而不是凭记忆硬编第三对高风险场景设置置信度阈值低于阈值就转人工或明确告知用户“不确定”。这套组合不能消灭幻觉但能显著降低其危害。真正的关键是别指望AI永远正确而是让它在犯错时被及时识别。还有一个容易被忽视的经验幻觉往往和提示词里的“诱导”有关。如果你在提示词里写了“你是行业顶尖专家一定能回答所有问题”模型就更容易硬编造答案。相反如果提示词允许它说“我不知道”它的幻觉率会肉眼可见地下降。允许系统承认不确定其实是在给无限游戏设置安全边界。4.2 评估难题规则被重构后谁来判断对错当输出不再是唯一确定值“对错”就成了一个哲学问题。同样的回答在A用户看来精准在B用户看来敷衍在C场景下合适在D场景下越界。传统软件工程的验收标准在这个时代经常失效。我现在的做法是建立“多维度评估”而非“单一对错”评估。比如客服场景我同时看五个维度语义相关性、事实准确性、安全合规性、语气适配度、指令遵循度。每个维度都打分综合判断才决定这个回答是否合格。裁判可以是人工也可以是一个独立的评估模型或者两者结合。关键是评估维度本身也要动态迭代——随着系统的行为空间变大你要评价的维度也会变多。这也带来了一个组织层面的难题谁来定义评估标准如果规则是从数据里长出来的那评估规则的人是否也需要理解数据我的经验是产品、算法、运营必须坐在一起定期过评估集而不是让某一方独自分定义。规则动态化之后标准的制定权也必须是动态分布的。4.3 人的角色从规则执行者到规则养护者最后想聊一个容易被技术掩盖的话题人在这个无限游戏里的位置。很多岗位焦虑“AI会不会替代我”我觉得这个问法本身就是有限游戏思维。更合理的问法是当AI把规则生成和执行的工作都包揽之后人类剩下的独特价值是什么我的答案很朴素目标设定、价值判断、边界守护。AI可以生成代码、写文案、规划路径但它没办法回答“我们为什么要做这件事”“什么是对的方向”“哪些边界绝对不能突破”。这些是规则之外的元规则是需要人来提供的。你跟一个Agent说“把利润最大化”它会真的不择手段但一个人类管理者知道企业还有品牌、合规、员工感受这些约束条件。所以我在团队里一直强调一个理念别把自己定位成给AI写提示词的操作员要定位成AI系统的“规则养护者”。你负责给系统浇水、施肥、修剪观察它的长势在它长歪的时候把它扶正。这是一种园艺师的心态而不是木匠的心态——你面对的不是一块可以精确雕刻的材料而是一个有自己生长逻辑的生命体。5. 面向无限游戏的产品与团队行动5.1 产品设计给系统留出“松动的余地”如果你正在设计一个AI产品我的第一建议是不要把产品行为焊死在一套固定流程里。留出一些允许模型自由发挥的空间反而会让产品更有韧性。比如生成式UI在传统设计里每个按钮的位置都是固定的但在AI系统里界面可以依据用户当下需求动态重组。你可以让模型判断当前用户处于什么场景然后只展示最有用的三个操作。这会让产品变“活”也会让维护变“重”这是你必须接受的交换。另外一个更实际的设计建议是永远给用户一个“退出自动规则”的入口。当AI系统的判断和用户的意图冲突时用户应该能轻松切换为手动模式。这个设计既是对用户的尊重也是你作为规则养护者的责任。无限游戏不是让AI赢而是让整个系统包括人机关系长期持续运转下去。5.2 团队协作从“写需求”到“设目标与校验”规则动态化对团队协作方式的影响可能比技术本身更先到来。传统模式下产品经理写需求文档开发照着实现测试照着验证。这是典型的有限游戏分工。但在AI系统里需求不可能被“写死”你只能设定目标和验收标准然后让模型在约束空间里自我生成实现路径。这意味着产品经理的职责要从“写详细需求”转向“定义评估维度和底线”开发的职责要从“实现规则”转向“搭建规则生成的管道和监控”测试的职责要从“断言对错”转向“建立评估集和分布容忍度”。三者的关系不再是流水线上下游而是一个围绕“规则养护”的协作网络。定期一起过评估样本、一起看bad case、一起修订提示词和RAG知识库是这个协作网络的基本动作。我见过很多AI项目失败的真正原因不是模型能力不够而是团队还在用有限游戏的分工方式管理一个无限游戏的项目。要么是产品经理事无巨细地指定每一个输出格式结果把模型的泛化能力全锁死了要么是开发只想稳定复现一个结果结果撞上了生成式输出的多样性就崩溃。所以团队心态的转变其实是项目成败的分水岭。5.3 个人成长从记忆规则到训练判断力对个人来说适应无限游戏的最好方式不是去背更多的AI工具用法而是训练自己两方面的能力一是审美判断力——知道什么是好的输出、什么是坏输出、为什么这么判断二是系统调试力——在AI行为偏离预期时能定位问题是出在数据、提示词、模型还是架构。这两种能力都不容易被AI替代因为它们恰恰是定义规则之外方向的能力。我自己有一个很笨但很有效的方法每周抽出一点时间去翻看AI系统最近产出的bad case然后问自己三个问题这个错误暴露了规则的什么漏洞这个漏洞是数据问题、提示词问题还是评估盲区下次怎么改坚持下来你会发现自己的判断力会越磨越准也更能理解“规则”在这个时代到底意味着什么。如果非得说一个进入无限游戏心态的门槛我觉得是接受失控。你没法让AI百分之百按你说的来但这不意味着你无能为力。你可以设定目标、预设边界、建立反馈、持续调整然后在动态中与系统共舞。那种硬要“把一切抓在手里”的冲动恰恰是有限游戏给你的惯性而这个惯性现在已经成了最大的风险。我自己做了这么多年AI项目最大的心得就是八个字不求掌控但求可调。系统可以有自己的生成和变化但你必须留出足够的调节旋钮——数据、提示词、评估集、人工干预入口。这些旋钮就是你在无限游戏里真正能拥有的“规则”。用它们去维持系统的健康方向而不是去钳制它的每一次输出。最后分享一个我每次给新项目定原则时都会用的标准我们设计的系统是希望它“每次都对”还是希望它“整体方向对”前者是有限游戏的执念后者才是无限游戏的智慧。AI时代我们大多数人真正要修炼的恰恰是后者。