引言
过去半年，我从传统 Java 后端开发转向了以 AI 为核心工具的工作方式。说「转向」其实不太准确——Java 我只做了半年，AI 我已经用了四年。
我和技术的接触比较早。家里长期做 IT 硬件和电商，从小看着设备换代、系统迁移，对工具本身的变化始终有一种本能层面的注意力。初高中的时候参加过 NOC 竞赛，拿了国奖。回头看，那个阶段最大的收获是确认了一件事：我对技术的兴趣是自发的，是内生的。
我学的东西一直很杂。编程、设计、硬件、运营，人文社科，天文地理什么方向都愿意碰。单纯是觉得学习本身有意思——尤其是那种从不确定中摸出确定性的过程。一个陌生领域，进去的时候一切从零，慢慢建立起自己的判断框架，这个过程本身就是回报。
四年前，因为对互动文本生成（Interactive Fiction）的兴趣，我开始高强度使用大语言模型。最开始的需求很简单：让 AI 写出一段连贯的对话。后来逐步升级——要求它在大量背景设定中保持一致性，控制文风，处理多层嵌套的隐式逻辑。整个过程纯粹由个人兴趣驱动，我有足够的时间去反复试探每一代模型的边界。
到现在，AI 已经深度嵌入了我的日常。协作流程跑通之后，整体效率上了一个台阶。可以说，我目前的工作方式已经完全建立在人机协作的基础上了。
回看这四年，抛开跑分榜单，单从一个高强度使用者的体感出发，大模型产生过四次明显的能力断层。标志性节点分别是：GPT-3.5、Claude 3、Gemini 2.5 Pro exp，以及当前的 Claude 4.6 Opus。每一次断层都伴随着使用方法的整体重构。
这篇文章想记录的，是一个高强度使用者在四年里，通过和不同世代的大模型反复博弈，逐步形成的一套关于上下文控制、多工具协作与流程设计的个人方法论。它从个人项目中生长出来，但它的内核——I/O 控制、信息生命周期管理、概率系统的工程化治理——在企业级应用中同样成立。
第一章 搜索引擎阶段 · GPT-3.5
我最早接触大模型是通过 API。
当时的使用场景非常简单：学习辅助。遇到不理解的概念，丢给 GPT-3.5 让它解释；有一段文档看不懂，让它做摘要和翻译；偶尔也用来生成一些代码片段。接入方式就是最基础的 API 调用，提示词也只是普通的系统提示词——一句话告诉它「你是一个学习助手」，然后开始对话。
这个阶段的体感，用一个词概括：搜索引擎。准确地说，是一个具备数据清洗能力的超级搜索引擎。它能把信息重新组织成你想要的格式，能用指定的语言复述知识，但核心逻辑依然是检索与复述。它在做条件概率下的 token 序列预测——找到训练数据中最可能的回答模式，把文字拼出来。
GPT-3.5 有几个非常典型的特征。幻觉（Hallucination）问题严重——它会用和正确答案完全相同的语气和格式，自信地输出一个完全不存在的概念。上下文容量极其有限，早期版本只有 4K token 的窗口，稍长的对话就会丢失前文。推理能力接近于零——简单问答和格式化输出可以胜任，任何需要多步推导的任务都会变得混乱。
但它解决了一个效率问题。以前查一个技术概念需要在搜索引擎里翻好几页，拼凑不同来源的信息。现在几秒钟就能拿到一段组织好的回答。回答的准确率大概在七八成，剩下的需要自己验证，但总体效率比传统搜索提升了一个量级。
这个阶段我对 AI 的认知停留在「工具」层面。更好用的搜索引擎，能写段落的文本处理器。
第二章 提示词阶段 · Claude 3.5 Sonnet 与 Gemini 1.5 Pro
非确定性响应的价值
进入这个阶段的契机是 Claude 3 系列的发布。我主要使用的是 Claude 3.5 Sonnet，同期也在用 Gemini 1.5 Pro exp。
让我从搜索引擎式的使用方式转向深度交互的，是角色扮演（Role-Play）。动机很直接——我一直是 RPG 类游戏的重度玩家，上古卷轴 5、GTA 系列这类高自由度开放世界游戏是我投入时间最多的类型。追求的核心体验只有一个：自由度。
但这个动机背后指向的，是一个远比 RP 更广泛的命题：脚本化系统的可延伸范式天生有限。
传统游戏中，NPC 的对话再丰富，底层永远是脚本。对话树有限个分支，任务有限种结局。玩家在 A/B 选项前常常会想：为什么不能选 C？这种「被迫在预设范围内活动」的体验，是沉浸感最大的天敌。问题的本质不在于设计者不够聪明——每多一种可能性就需要多写一套分支逻辑，成本呈指数增长。
这个瓶颈在所有基于预设规则的交互系统中普遍存在。客服系统的知识库只覆盖了 FAQ 中的问题，用户提了一个 FAQ 之外的问题，系统就只能回复「请联系人工客服」。游戏 NPC 只能在设计者预设的对话树里回应玩家，玩家说了一句树以外的话，NPC 就卡住了。智能家居的语音助手只能识别预设的指令模板，用户换一种说法表达同样的意思，系统就无法理解。
这些场景的共同痛点是：系统的响应空间是有限的、预定义的，任何超出预设范围的输入都会导致系统失灵。
大模型带来了一种全新的可能：非确定性响应。输入一段话，模型基于上下文在概率空间里实时采样出回应——这个回应不是预写的，不是从有限集合中选取的。理论上，任何输入都能得到一个上下文相关的反馈。选项 C、D、E 都可以存在，因为根本就没有「选项」这个概念。
这种开放性在当时是令人惊喜的。它从根本上解决了脚本化交互的核心瓶颈——虽然解决得远不完美，但方向是对的。
在企业应用端，这个能力意味着一种范式级别的转变。传统的客服知识库、FAQ 系统、IVR 语音导航，本质上都是脚本化系统——用户的输入被映射到有限的预设响应中。大模型的引入让响应空间从有限集合扩展到了开放的概率空间。用户可以用任何方式表达需求，系统都有能力生成一个语义相关的响应。当然，「有能力生成响应」和「生成高质量的正确响应」之间还有很大的距离——这个距离就是后续几个章节要讨论的 I/O 控制问题。
提示词结构与八股文
这个阶段的使用以提示词为核心。系统提示词定义行为规范，角色提示词描述人设，状态栏规则规定输出格式，预写的开场白建立叙事起点。角色描述中附带示例（few-shot example），展示期望的输出风格。
当时流行的角色卡格式很有代表性：用方括号列举一长串性格标签——一个角色能挂二十多个形容词；外貌同样是标签罗列；再用几轮示例对话展示输出风格。设计思路是「给得越多，模型越知道该怎么做」。
但大量使用后，一个极其恼人的模式反复出现：输出结构高度套路化。先是环境描写，然后角色对话回扣人设关键词，接着内心活动，最后必定以一句反问或升华收尾。Claude 的中文输出尤其偏爱「指节泛白」「喉结滚动」「嘴角勾起一抹弧度」这类固定搭配——它们以极高的频率出现在不同角色、不同场景中，像是一条工业化的文字流水线。
这种现象的成因可以从三个层面理解。
训练数据分布。 中文语料中网络小说和通俗文学占比极高，这类文本本身就高频使用这些固定搭配。模型学到的是 token 序列的条件概率——当上文出现「紧张」这类语义信号时，「指节泛白」的生成概率就被推到了很高的位置。
RLHF 的系统性偏差。 对齐训练中，人类评估者倾向于给「完整」「结构清晰」的回答打高分。这种偏好被模型内化后，形成了一种结构惯性：每条回复都要有起承转合，结尾一定要「收」住。
提示词设计本身的放大效应。 这一点我在后来才逐渐想明白。提示词的每一句话，与其说是在向模型传递信息，不如说是在调整它的采样权重——更像一个放大器。你写了什么，模型就会在输出中放大什么。二十多个性格标签意味着二十多个概率锚点，模型在每段输出中试图「致敬」所有锚点，结果就是人设清单的文学化复读。
这个经验引出了一条反直觉的原则：提示词在精不在多。
一个角色设定里只写「她性格温和，习惯照顾身边的人」，模型会在不同场景中用不同方式体现这个基调——有时是语气，有时是行为，有时是选择。而如果把「温柔善良、轻声细语、充满关怀、笑容温暖、从不拒绝」全写上，六个锚点反复强调同一个语义簇，模型的采样空间被压缩到极窄的区间，多样性反而消失了。
更深一层：人物设定中的信息之间本来就存在自然的推演关系。写了「她是一名急诊科护士」，模型自然能推断出冷静、抗压、见惯生死这些属性。单独再列一遍，它们就从「自然推断」变成了「被强调的特征」，出现频率会超出正常需求。
这个认知后来成了我在上下文控制领域最核心的原则之一：放进上下文里的每一个 token 都有成本——它在参与全局注意力的权重分配，在影响模型对整个语境的理解。信息的密度和精准度，远比体量更重要。
在企业端，这条原则直接映射到知识库的设计策略上。 一个客服系统的产品知识库，如果把同一个产品特性用五种不同的表述方式重复描述——为了「确保模型理解」——效果和在角色卡里堆二十个性格标签是一样的。模型会过度强调这个特性，在回答中反复提及它，而其他同样重要但只被提及一次的特性则被注意力稀释。知识库的设计应该追求「每一条信息只出现一次，用最精准的语言表述」，和提示词精简原则完全一致。
规则遵循的困境
这个阶段的另一个突出短板是规则遵循能力很差。系统提示词里写「每次回复不超过三段」，到第五次就被完全遗忘。规定「在末尾输出状态栏」，隔几轮就漏掉或格式错乱。
本质上，这个阶段的模型对 System Prompt 的处理方式更接近「一段额外的上下文」而非「一组硬性约束」。系统提示词和用户对话在同一个注意力机制里被处理，随着对话轮次增加，系统提示词在整体上下文中的占比不断稀释，影响力随之衰减。模型不具备将某段文本标记为「必须始终遵守的规则」的内在机制——它只是把所有输入放进同一个序列，根据全局注意力权重做 next-token prediction。
这个弱规则遵循特性在 RP 场景中导致了大量手动干预，但它的影响远远不止于此。在任何需要模型持续遵守特定行为规范的场景——客服系统的回答格式、内容审核的判定标准、数据提取的结构化输出——规则衰减都是一个核心的工程挑战。如果一个客服模型在对话的前三轮能稳定地以规定格式输出工单信息，到第十轮就开始自由发挥，这套系统在生产环境中的可靠性就无从谈起。
工具链的雏形
在这个阶段后期，两个工程化方向开始成形。
第一，关键字检索数据库。设定量越来越大之后，全部塞进系统提示词不现实。开始把补充性设定写成独立条目，通过关键字匹配触发注入——对话中出现特定关键字，就从数据库检索对应条目拼接进上下文。这在概念上已经接近 RAG（Retrieval-Augmented Generation）的基本思路，只是实现很粗糙。
第二，跨模态工具协作。让模型在输出正文的同时生成格式化的图像提示串，通过正则表达式捕获后传入本地 Stable Diffusion 生成图像。这第一次建立了「LLM 输出可以作为其他工具的输入参数」这个概念。
在企业场景中，这两个方向分别对应了后来行业里广泛讨论的 RAG 架构和 Tool Use（工具调用）机制。从粗糙的原型到成熟的产品化实现，中间的工程距离很大，但底层的设计动机是一致的：让模型在自身能力边界之外，通过外部系统的辅助来完成更复杂的任务。
阶段性评估
这个阶段从 Claude 3.5 Sonnet 延续到 Gemini 2.0 Pro。中间模型换了好几代，窗口在变大，推理在变强。但使用体验的提升并没有那么大——更大的窗口不等于更有效的利用，更强的逻辑在创作场景中也没有改变模型被动扩写的根本行为模式。
量变在积累。质变在下一个阶段。
第三章 工程化阶段 · Gemini 2.5 Pro Preview 0325
能力断层
Gemini 2.5 Pro Preview 0325 给我的第一体感只有一个字能形容：夸张。
上下文窗口直接拉到百万级 token。思维链（Chain of Thought, CoT）首次让模型的中间推理过程变成了可观测的结构化输出——你可以看到它在想什么、在哪一步产生分歧、如何收敛到结论。推理能力相较于 2.0 Pro 出现了清晰的代际落差。规则遵循方面的进步尤其直观：系统提示词里写的约束，它会持续记住，不再需要每隔几轮手动重复。
从 2.0 Pro 到 2.5 Pro 0325 的跃迁是连续的——底层架构逻辑和行为范式一脉相承，每个维度都被拉高了一截。
但能力的跃升同时把一些老问题放大到了无法忽视的烈度。
输出偏差的底层成因
Gemini 2.5 Pro 的中文输出有两个极其突出的问题。
第一是高频意象复读。「向平静的湖面投入一颗石子，泛起层层涟漪」——这个比喻在输出中反复出现，几乎覆盖了所有需要表达「试探」「犹豫」「引发连锁反应」的语境。十几轮对话中每轮都能出现好几次，作为使用者，体感只剩下疲惫。
第二是多语言混杂。纯中文提示词和对话，模型会在正文中毫无征兆地插入阿拉伯文、希伯来语、日语片假名。这些外语碎片通常出现在情绪密度较高的段落。
这两个现象的成因可以从底层拆开。
意象复读是训练数据层面的过拟合。 大模型的文本生成本质是在 softmax 归一化后的概率分布中做采样。「投石问路」这个 token 序列在中文网络文学语料中被大量使用，同时承载「试探」「小心翼翼」「引发连锁反应」等多重语义功能，适配上下文条件极广。在 softmax 层的概率竞争中，它在太多语境下都能拿到高位的生成概率。更关键的是，模型自己生成的「投石问路」会进入上下文，进一步强化这个序列的条件概率，形成正反馈循环。
多语言泄漏源于联合训练的决策边界模糊。 Gemini 的预训练语料覆盖数十种语言，不同语种在训练过程中混合输入。这赋予了跨语言的语义映射能力，但代价是语种之间的生成决策边界变得不清晰。当上下文出现情感密度高的区域时，采样分布会短暂偏移到其他语种的 token 空间——某个阿拉伯文 token 在那个概率节点上恰好获得了比对应中文 token 更高的生成概率。采样温度越高，这类越界发生的频率越高。
这两个问题在企业场景中的映射比在个人使用中更加严峻。
意象复读的底层机制——训练数据中高频 token 序列在概率竞争中的系统性优势——在客服场景中表现为回答的模板化。一个智能客服在回答了一百个关于退货政策的问题之后，它的回答会越来越趋向于一个固定的模板，因为训练数据中「退货」相关的高频表达模式在反复使用中被持续强化。用户的问题各不相同，但得到的回答几乎一模一样——这种「千人一面」的体验在传统 FAQ 系统中就已经是痛点，在引入 LLM 之后如果不做针对性的处理，痛点不会自动消失，只是换了一种形式继续存在。
多语言泄漏的底层机制——语义空间中不同实体的概率边界模糊——在企业场景中表现为更危险的「跨实体混淆」。假设企业的产品数据库里有两个名称相似的产品——「CloudSync Pro」和「CloudSync Plus」。如果「Pro」在训练数据中的出现频率远高于「Plus」，模型在概率层面就有强烈倾向在用户询问「Plus」时生成「Pro」的信息。它会用完全自信的语气把 Pro 的功能描述、定价方案一五一十地告诉用户——只是全是错的。这种错误在传统规则系统中不会发生（因为规则是确定性映射），但在概率系统中是一种结构性风险，需要通过后续章节讨论的认知隔离和数据层面的绑定权重强化来应对。
算力波动
另一个在公开讨论中很少被提及、但高频使用者体感极其明确的变量：算力波动。
谷歌的模型上线后头两周，推理质量最高。进入第三周，随着用户涌入导致负载攀升，输出质量开始肉眼可见地滑坡——模板化内容比例上升，生成多样性下降。
从运营角度这很容易理解。推理成本是大模型商业化最沉重的支出项。并发请求量超出预期时，服务端会通过调整后台参数来节约算力——缩短内部最大生成长度、提高 KV cache 量化损失容忍度、调整批处理粒度。每一项调整都在用户不可见的层面压缩模型的表达空间。
使用者需要在日常使用中培养一种「算力校准」直觉——这次输出质量下降了，是上下文出了问题，还是后台在省资源？这个判断没有任何官方指标可依赖，完全靠经验积累。
这个现象在企业部署中有直接的启示。如果一个企业选择调用闭源模型 API 作为核心业务能力，那么模型服务商后台的算力调度策略就成了一个不可控的外部变量。业务方需要建立自己的输出质量监控体系——对模型输出的一致性、完整度、准确率做持续的自动化检测——而不是假设 API 的输出质量是恒定的。
Kingfall 与 3.0 Pro Preview
在 2.5 Pro 的迭代过程中，谷歌放出过一个测试模型代号 Kingfall。公开资料极少，但它的表现是一次极其干净的能力跳跃——文本质量、推理连贯性、复杂指令的消化深度，每个维度都在 0325 基础上再拔高了一截。代价是速度：同等上下文规模，2.5 Pro 的响应约 50 秒，Kingfall 要 80 秒以上。它最终没有正式发布——一个推理耗时慢 60% 的模型，在大规模服务场景中运营成本无法维持。质量和成本之间的取舍，是闭源模型服务商回避不了的核心博弈。
Gemini 3.0 Pro Preview 的出现则打破了线性升级预期。速度更快，但规则遵循出现回退，并且有一种突出的「向上省略」倾向——它会自行裁剪它认为「不重要」的内容，把限定词、定语、修饰成分整体砍掉，只保留骨架。
在精度敏感的工程场景中，这种省略是灾难性的。以变量更新为例：模型需要输出一段 JSON Patch 格式的更新指令，声明哪些字段发生变化。2.5 Pro 会老老实实遍历所有字段逐一判断，3.0 Preview 则经常只输出五六个——剩下的被它自行判定为「可省略」。即使输出了的字段，内容本身也被压缩过——「在码头区与 NPC-A 冲突，NPC-A 受伤撤退，留下一把钥匙」变成了「与 NPC-A 冲突」。三个定语和两个结果从句被整体省略。
在自动化管线中，这种行为会导致下游系统基于不完整数据继续运转，错误在系统中静默传播，直到某个节点积累的偏差大到产生可观测的异常。企业场景中的对应：一个订单处理系统，上游模型在解析用户需求时省略了「加急配送」这个限定条件，下游物流调度就会按默认时效安排运输。这种故障模式极难在测试阶段发现——模型的省略行为是概率性的，同样的输入在不同时间点可能省略不同内容。
2.5 时代积累的整套提示词体系在 3.0 上近乎全面失效。同一条指令，同一种格式规范，2.5 Pro 稳定执行的东西，3.0 Preview 不接受。这进一步确认了一个判断：每个模型都有自己的特性曲线。提示词和模型之间的适配关系是局部的、版本敏感的。
从提示词驱动到系统驱动
到了这个阶段，我遇到的核心问题已经超出了「写一段好提示词」所能解决的范围。
问题一：长对话中的状态衰减。 随着对话推进，早期设定的细节被逐步遗忘，逻辑矛盾开始出现。根源是注意力权重随上下文长度增加而被稀释——早期信息分到的权重越来越少。
问题二：推理焦点漂移。 模型会把大量推理资源花在无关紧要的细节上，而对真正需要仔细推敲的关键变量一笔带过。推理的议程控制权在模型手中，而模型的注意力分配和使用者的优先级排序之间存在系统性偏差。
问题三：信息膨胀导致信号稀释。 设定量持续膨胀，全部塞进系统提示词后，每一条信息分到的注意力权重都不够用。
这三个问题分别催生了三个工程化方向：CoT（思维链）、数据库系统、MVU（变量管理系统）。
CoT 的引入动机是把推理的议程控制权从模型手中拿回来。在正文生成之前，强制模型走过一遍结构化的检查流程——当前的时间地点、在场角色、用户输入的核心意图、需要遵守的规则、需要承接的关键事件。通过预定义的检查问题，在注意力机制的自然衰减之上，为关键信息创造一次被重新激活的机会。
当时主流的结构化推理范式是 ReAct（Reasoning + Acting），把任务拆解为「思考—行动—观察」的循环。我在使用中发现它有一个关键缺陷：对照 OODA 循环（Observe-Orient-Decide-Act），ReAct 的第一层 Observe 经常缺位。模型直接从用户输入跳到推理，中间缺少对当前完整环境状态的感知环节。结果是输出有一种突兀感——事件好像是从真空中冒出来的，缺少环境铺垫和自然过渡。
在客服场景中，这种缺位表现为：用户说「我要退货」，系统直接跳到「好的已为您提交退货申请」。中间的环境感知——用户的订单状态、是否在退货期内、历史退货记录、用户的情绪信号——全部被跳过了。技术上可能正确，体验上非常生硬。
为了补正这一点，我在工作流前端引入了意图拆解机制（Intent Decomposition）——在主模型接收请求之前，先用一个预处理模块把用户输入展开成一组细粒度的子问题，补全环境信息后再送入主模型的 CoT 环节。效果立竿见影——输出从「从真空中冒出来」变成了「从一个持续运转的世界中有机生长出来」。
数据库系统的引入解决的是「用什么想」的问题。设定信息从系统提示词中剥离出来，存入独立的结构化数据库，按需调用、定向注入。
我在检索策略上做了一层定制化设计：标签聚合。每条数据库记录在入库时被打上一组标签，每个标签附带关联度权重。每次生成前，系统分析当前上下文中的关键实体和语义标签，到数据库中做标签匹配和关联度排序检索，把最相关的 N 条记录注入上下文。
核心收益是上下文的精简和信号密度的提升。模型拿到的上下文更短、信噪比更高，注意力资源集中在真正相关的信息上。
这个设计在企业端有非常直接的落地价值，我展开说一下。
客服场景：用户的历史工单、投诉记录、账户状态、近期行为日志分散在不同系统中。全量灌进每次对话的上下文，token 预算吃不消，信息互相稀释。但通过标签聚合——根据用户当前问题主题、涉及的产品线、情绪信号——定向检索出最相关的 3-5 条历史记录注入上下文，模型就能用最短的输入给出最精准的回答。与 RAG 的核心理念一致，但标签聚合在检索的精确度和语义关联度上比纯向量相似度检索更可控，因为标签是人工定义的、语义明确的分类维度，不受 embedding 空间中的距离度量误差影响。
制造业场景：一条产线上的设备异常记录、维护日志、质检数据，数据量极其庞大。当某个工位出现特定类型的异常信号时，通过标签匹配（设备类型 + 异常类型 + 历史故障模式），定向调出该设备最近 N 次同类型异常的处理记录和结果，辅助技术人员快速定位原因。全量数据灌入不现实也没必要——定向调用才是正确的信息管理策略。
内容生产场景：一个媒体团队的内容资产库包含数万篇历史文章。编辑在策划新选题时，系统根据选题标签（话题领域 + 目标受众 + 内容形式）从资产库中检索出最相关的历史文章作为参考素材注入上下文，让模型的输出与团队已有的内容调性和知识积累对齐。
这些场景的共同底层命题是同一个：I/O 控制。 大模型是一个概率驱动的 I/O 系统。输入端的信息质量、密度、结构，是输出质量的第一决定因素。数据库加标签聚合，本质就是在输入端做精准的信息筛选和结构化打包——控制 I，从而控制 O。
事件衰减与平行推进
标签聚合解决了「调什么信息进来」，但信息本身会过时。
一个事件刚发生时影响力最大。三天前的冲突和三个月前的偶然相遇，对当前场景的参考权重应该截然不同。如果始终以同等权重注入，三个月后的场景中仍然会被过时的信息干扰。
我引入了事件衰减机制：每条记录有一个随时间递减的影响力值。衰减到阈值以下时，触发评估——判断是否仍有价值。如果判定为「已失去当前意义」，进入事件回收池，从常规检索中移出，只有在非常特定的标签组合出现时才会被重新激活。
在此基础上建立了「平行事件推进」机制。核心理念：世界不围绕主角转。主角不在场的时间段里，其他角色的事件线也在后台推进——关系在发展，状态在变化，事件在衰减。每一个大的时间跳转节点，系统触发一次平行更新，让模型推演非主线事件的自然发展并写回数据库。
这套机制迁移到游戏行业有直接的产品价值。传统 NPC 是状态机——玩家触发条件，NPC 进入下一状态。玩家不触发，NPC 永远停在原地。如果引入平行推进框架，NPC 可以拥有独立的事件线——随游戏世界的时间推移自行发展，玩家在不同时间点与同一个 NPC 互动时，能感受到这个角色「有过自己的经历」。这种设计把 NPC 从提线木偶变成了具有时间厚度的虚拟居民，对开放世界游戏的沉浸感提升是质的层级。
客服场景中同样适用：用户半年前提交的投诉和昨天提交的投诉，在当前对话中的参考权重不应该相同。事件衰减本质上是一种时间感知的信息管理策略——让系统对信息的「新鲜度」和「当前相关性」保持敏感。
MVU 与自动化管线
MVU（Model-View-Update）前端变量管理系统把状态追踪从模型的文本生成中剥离出来。模型只输出增量更新指令（JSON Patch 格式），前端系统接收指令在本地执行数值运算和状态变更，通过 UI 动态展示。关键收益在于确定性——变量的实际值由程序逻辑维护，不再依赖模型的概率生成。模型负责「判断发生了什么」，程序负责「把判断落实到数据」。
与此配套的是 Flash 模型（轻量级低成本模型）的校验环节。主模型输出的更新指令在写入前经过两层检查：脚本级格式校验（JSON 结构合法性、字段类型、必要字段齐全性）和 Flash 模型的语义校验（结合正文内容判断更新是否逻辑自洽）。选择 Flash 而非主模型做校验是成本考量——校验任务的推理复杂度远低于正文生成，轻量级模型完全胜任，成本可能只有主模型的十分之一。
这种「强模型生成 + 轻模型校验」的架构，在企业端有广泛的适用面。合同条款生成后的合规审查、医疗报告的格式与数值校验、代码生成后的静态分析——任何「生成—校验—入库」的流程都可以采用这个模式，在保证质量的前提下大幅压缩推理成本。
这些模块被整合成一条完整的自动化管线之后，我对它的描述是「坐地铁」——我需要做的只有走进站（提供输入、设定架构）和走出站（审核输出、修正方向），中间的全部运转由系统自动完成。
从个人项目到企业落地的鸿沟
在记录完这些进展之后，有必要正视这套系统的局限。
第一，脆弱性。整条管线的每一个连接点都是潜在的断裂点。正则表达式依赖模型输出的格式稳定性——而模型输出格式恰恰是最不稳定的因素之一。格式契约的维护成本随系统复杂度指数级攀升。
第二，维护成本。CoT 每一两周要重新校准。数据库标签体系需要持续修正。事件衰减参数需要根据实际节奏调整。每个模块都是独立的维护工作量。
第三，评估困难。「输出质量提升了」这个判断完全依赖主观体感。没有量化指标，没有 A/B 测试，没有基线对照。缺乏客观评估体系是个人项目的通病。
第四，可迁移性差。整套系统高度定制化，交给另一个人使用或迁移到另一个领域，几乎需要重新设计所有模块。它是一个「手工作坊」级别的系统，距离可复制、可规模化的产品形态有很大距离。
这几个局限恰好映射了企业落地 LLM 应用时最核心的工程挑战。
标准化问题。 我的标签体系、衰减参数、CoT 结构全部依赖个人经验和直觉。在团队协作中，这些设计决策需要被文档化、规范化，变成团队任何成员都能理解和执行的标准流程。谁来定标签？标签的命名规范是什么？新增一个标签需要经过什么审批流程？这些在个人项目中不存在的问题，在企业场景中是必须回答的。
质量评估体系。 个人使用靠体感，企业运营靠指标。模型输出的准确率、一致性、格式合规率、用户满意度——这些指标需要被定义、被测量、被持续监控。一个没有量化评估体系的 LLM 应用在企业环境中是不可运营的，因为你无法回答「这个系统在变好还是变差」这个最基本的问题。
版本管理与回滚。 模型后台更新导致提示词失效——这在个人使用中意味着花几个小时重新调试，在企业生产环境中意味着线上服务质量下降、客诉增加、业务损失。企业需要建立完整的提示词版本管理体系、灰度发布流程、回滚机制——和传统软件发布的 CI/CD 流程一样的工程纪律。
成本控制的精细化。 我的多模型架构中「强模型生成 + 轻模型校验」的成本优化是粗颗粒度的。企业场景需要更精细的成本核算——每一次 API 调用的 token 消耗、每一个 Agent 的调用频率、不同任务类型的成本分布——建立完整的成本模型，在质量和成本之间找到最优平衡点。
这些挑战都不是技术问题。它们是产品问题、管理问题、流程问题。这也是我在后续章节中反复强调的一个判断：LLM 应用的核心竞争力正在从技术实现转向产品设计和系统运营。
第四章 混合架构阶段 · 多模型协同与 I/O 压缩
分工制的形成
前三个阶段的暗线是：模型能力越强，单模型架构的瓶颈越明显。到了这个阶段，我把工作流拆成了四个功能模块，每个模块分配最适合的模型。
环境预推演层：Gemini 3.0 Pro Preview（后升级至 3.1）。 压缩能力强，上下文窗口大，负责 OODA 循环中的 Observe 环节——外部事件状态、平行推进报告、剧情框架预推演。只输出结构化环境报告，不写正文。它的压缩倾向在这里反而是优势——环境信息需要的是高密度低冗余的结构化描述。
正文生成与核心推理层：Claude 4.6 Opus。 语言质量、对话真实感、复杂设定一致性——这些对语言感知力和推理精度要求最高的任务交给 Claude。同时承担 CoT 的执行。
工具执行层：Gemini 3.0 Flash。 格式化填写、数值计算、脚本触发——推理复杂度低但格式要求严格的任务。API 价格是主模型的几十分之一。
数据管理层：Gemini 2.5 Pro。 总结生成、数据库维护、归档处理。选择它的理由很朴素：它听话。不偷懒，不省略，不自作主张地压缩内容。在数据管理岗位上，「不激进」是最需要的品质。
这四个模型通过结构化接口串联，构成了一个多 Agent 系统——多个具备一定自主能力的智能体，各自承担专门化角色，通过定义好的协议协作。每个模型在职责范围内拥有判断和决策的自主权，我限定的是输入源、输出格式和职责边界。
设计原则：能减少 Agent 间交互就尽量减少。 单一 Agent 能完成的事不拆分。工具调用能少就少。不同模块追求高内聚、低耦合。这个原则的出发点是双重的——容错（每多一次跨 Agent 传递，就多一个偏差风险点）和成本（每一次交互意味着额外的 API 调用）。
工作流的管线设计
完整的流转路径：
- 环境预推演：Gemini 3.0 Pro Preview 生成环境报告，通过总结索引系统（编号制，含详情/概述/索引三个层级）按需检索相关历史内容。索引层只有几十个 token 的简短描述，只有被判定相关的条目才展开到详情层——检索的 token 成本大幅降低。
- 正文生成：环境报告和相关设定注入 Claude 4.6 Opus。先执行 CoT（场景确认、意图分析、状态校验、叙事规划），然后生成正文。正文中的时间信息以预定义格式嵌入供下游正则捕获。CoT 末尾输出工具调用声明，指导下游模块执行。
- 工具执行：Gemini 3.0 Flash 根据声明执行结构化操作——入库、计算、脚本推进。只做格式化和规则性操作。
- 数据管理：Gemini 2.5 Pro 生成总结条目、更新数据库记录、执行衰减判定。MVU 变量直接从数据库读取，通过可视化插件展示。
关键设计：CoT 用完即弃。 正文生成后，CoT 内容通过正则捕获从输出中剥离，不进入用户展示界面，不进入后续轮次的上下文。环境报告、工具声明同理——消费完即丢弃。留在上下文里的只有正文。
这就是为什么这套看起来很复杂的系统反而能把总 token 控制在八万五千以下。复杂度在管线设计中，不在上下文中。每一步都在做压缩。楼层少、单轮信息密度高、辅助信息在外部系统持久化——三个维度共同把上下文利用率拉到极高的水平。
八万五千 token 以下的上下文规模处在当前主流模型的最优推理效率区间。体感差异非常明显：上下文膨胀到十几万 token 时输出变得敷衍套路化，八万以下则细节丰富、逻辑扎实。
Reflection 机制与语义泄漏
Claude 4.6 Opus 被放在正文生成位置，除了语言质量，还有一个关键原因：它的自我校验能力。
Claude 4.6 Opus 在生成过程中会进入一种反思环节——重新审视刚才生成的内容是否与上下文一致、是否符合设定约束、是否逻辑自洽。如果发现偏差，它会自行修正后再输出最终结果。我用一个不太严谨但直观的比喻来描述它：左右脑互博。一边在写，一边在审。（需要说明：这是我基于使用观察的描述性说法，并非 Anthropic 官方的术语或功能命名。）
一个实际案例可以很好地说明这种机制的价值。
我在设定中建立了两个组织：圣灵教廷和辉煌教廷。圣灵教廷有一个已经完整设定的领导者角色叫塞拉斯。辉煌教廷的领导者位置是空的。故事推进中，我的角色只与辉煌教廷接触，从未与圣灵教廷有任何交集。
在观察 Claude 的 CoT 过程时，我发现它在推理中一度考虑在辉煌教廷场景中引入「塞拉斯」。原因是：当「教廷」和「领导者」这两个语义关联极强的概念被激活后，数据库中唯一一个与「领导者」标签绑定的实体就是塞拉斯——于是塞拉斯在推理过程中浮了上来。
这是注意力机制中的跨实体语义泄漏。数据库里某个属性只有一个绑定对象时，那个对象就会在所有涉及该属性的上下文中获得不成比例的高概率。
关键区别在于 Claude 的自我校验介入了。它在反思环节检测到偏差——「当前场景是辉煌教廷，塞拉斯属于圣灵教廷，无关」——然后自行纠偏，最终输出中塞拉斯没有出现。
换成 Gemini 3.0 Pro Preview 做同样的任务，它会跳过「检查这个人物是否属于当前场景」这一步，直接把「教廷→领导者→塞拉斯」这条最高概率链路落实到输出中。结果是一个从未接触过的、属于另一个组织的人物堂而皇之地出现在了错误的场景里。
这个案例的企业映射非常直接。 一个金融客服系统，数据库里有「理财产品 A」和「理财产品 B」两个条目。产品 A 的设定详尽完整，产品 B 的设定相对简略。当用户咨询产品 B 时，模型的注意力机制被「理财产品」这个概念激活后，会倾向于把产品 A 的信息泄漏到关于产品 B 的回答中——因为产品 A 在数据库中的信息密度更高，在概率空间中的「引力」更强。没有自我校验机制的模型会直接输出混杂了两个产品信息的回答；有自我校验能力的模型至少有机会在输出前发现并修正这个偏差。
解决方案要从数据层面入手：强化实体与所属组织/类别的绑定关系——比如把条目标题从「塞拉斯」改成「圣灵教廷·塞拉斯」，通过增加限定词来提高绑定权重，降低跨实体误激活的概率。在客服系统中，这等价于在知识库条目中始终携带产品线前缀，用结构化的方式减少跨产品的信息泄漏。
参数控制的精细化
多模型协同中，参数控制从全局设置变成了每个模型一组独立调参。
Claude 和 Gemini 的最优 Temperature 配置完全不同。Claude 4.6 Opus 可以给相对宽松的区间——它的自我校验机制本身是一道安全网。但 Gemini 3.0 Pro Preview 必须压在 0.7-0.8 之间。高于 0.8 规则遵循下滑，低于 0.68 则进入一种异常状态：模型不再执行 CoT，而是把思维链模板当作文本「朗读」——原样输出步骤标题和占位符，不填入任何推理内容。
底层解释：Temperature 控制 softmax 层概率分布的平滑程度。温度越低分布越尖锐，模型越倾向于选择最高概率的 token。当温度低到一定程度时，逐字复制输入的概率会超过基于模板进行开放式推理的概率——因为复制在 token 层面是确定性极高的操作。温度过低把模型推向了最确定性的行为模式，而最确定性的行为就是复制。
Top-P 的调节维度不同——控制参与采样的候选 token 集合大小。收窄 Top-P 可以有效降低多语言泄漏概率，通过减小候选集排除低概率的非目标语种 token。
这些参数不是一次性调好就不动的。模型后台更新、算力分配变化、上下文内容差异，都会影响最优位置。调参是一种持续校准的手感。
对企业的启示： 如果一个企业的 LLM 应用涉及多个模型（主模型 + 校验模型 + 轻量执行模型），每个模型的参数配置需要独立管理，并且建立参数与输出质量之间的关联监控。模型服务商推送静默更新后，原有的参数配置可能需要重新校准——这个过程需要自动化的质量检测机制来触发，而非依赖人工发现。
CoT 范式演进
我的 CoT 设计经历了从 checklist（检查清单）到 step（步骤链）的范式转换。
Checklist 模式下各项之间是平行独立的，模型可以跳着回答、可以对某一项敷衍，前一项的结果不会自然流入下一项。Step 模式把 CoT 设计成有序的依赖关系链——每一步的输出是下一步的输入前提。末尾设置 hook 校验环节，回顾整条链路检查矛盾。校验失败则触发 rollback，回退到出错步骤重新执行。
一个重要的技术细节：CoT 和正文在同一次模型调用中完成。模型先输出 CoT 再输出正文，CoT 的文本在生成过程中自然成为正文的上下文——位置关系天然保证了信息传递。生成完成后，CoT 通过正则捕获被剥离，不进入后续轮次。
另一个实践是对话思维链——当场景需要生成角色对话时，额外插入一段针对对话的推理。其中有一个反直觉的技巧：「概率对冲」。Gemini 的对话输出偏极端化，Claude 偏温和平淡。在 Claude 的对话 CoT 中，不是直接说「写得激烈一点」（正面引导效果有限），而是先让模型生成一段极端化表述，然后标注「上述是错误示范」——把「极端」和「错误」在概率层面绑定。模型在生成最终对话时自然避开极端区间，但由于已探索过那个区间，采样空间被拓宽了。输出落在比纯正面引导更丰富、更有张力的位置上。附带好处是省 token——几十个 token 的 CoT 操作替代了大段的风格描述提示词。
提示词的模型特异性
多模型并行使用后一个判断变得坚实：通用提示词是一个伪命题。
同一个项目中，对 Gemini 的要求是详尽（它的基线倾向是压缩，需要用力推），对 Claude 的要求是精简（它的基线倾向是铺陈，需要反向约束）。让 Gemini 做自我校验它就是做不利索，Claude 则得心应手。差异根源在训练策略和对齐偏好——Claude 倾向完整性和安全性，Gemini 倾向效率和简洁性。这些偏好固化在模型权重中，不是提示词能彻底覆盖的。
正确的策略是顺应模型的自然倾向——用提示词放大优势，用参数抑制劣势——而非试图把模型改造成它不是的样子。
第五章 方法论收束
AI 作为基础设施
四年的高强度使用走到今天，AI 已经不是工具箱里的某一件工具，而是工具箱本身。
我有一套完全个人化的系统在持续运转。它记录个人习惯——作息、饮食偏好、阅读倾向、学习进度。维护历史档案——去过哪些地方、做过哪些项目、什么阶段对什么领域产生了兴趣。它会根据近期行为模式进行提炼，生成分析报告交给我审阅，由我判断哪些写入长期参考、哪些只是短期波动。这套系统经过长期磨合，适配程度已经到了很舒适的状态。
学习辅助的效果尤其显著。任何一个陌生领域，技术文档和参考资料喂进去，几分钟内 AI 可以搭建出初步的认知框架。这不是替代学习，而是把「从零建立方向感」的效率提升了一个量级。
这种嵌入不是追风口。它是四年持续使用中自然形成的依赖关系。
多 Agent 黑盒协作的风险
基于四年实践，我想提出第一个可能引发争议的判断：多 Agent 内部黑盒协作，在当前阶段，能不用就不用。
出发点不是「多 Agent 不好」，而是「黑盒状态下的风险收益比目前还不够划算」。
成本层面：多 Agent 协作意味着多次模型调用，Agent 间的信息传递、反复确认、错误重试都在消耗 token。总消耗的增长不是线性的，而是超线性的。
风险层面更核心：LLM 本质是概率模型，多个概率模型的黑盒协作会产生概率误差的耦合放大。
借用民航安全领域的瑞士奶酪模型（Swiss Cheese Model, James Reason）来说明。安全防线被想象成一层层带有随机孔洞的奶酪片，不同层的孔洞位置不同，只有所有层的孔洞恰好对齐时风险才会穿透——多层独立防线降低了系统性失败的概率。
多 Agent 黑盒协作在某种意义上把这个模型反过来了。每个 Agent 都有自己的概率「孔洞」——幻觉、误解、省略、格式偏差。串联协作时，上游的输出直接成为下游的输入。上游省略了一个限定词，下游不会质疑这个输入（它没有能力判断上游是否出错），反而基于有偏差的输入继续推理，可能产生更大的偏差。误差不是被层层过滤，而是被层层放大。
LLM 是马，提示词和工具链是马具，人类是驾驶员。你可以给马配上精良的马具让它跑得更高效，但你不能闭着眼睛让马自己决定往哪跑。
OpenClaw 的安全事件是一个值得展开讨论的例证。作为一个开源 AI Agent 框架，OpenClaw 的意义在于它代表了 Agent 和具身智能真正出圈、进入普通用户日常使用的一次里程碑式实践。它的图标是一只龙虾，因此在社区中引发了一波全民「养龙虾」的热潮。工信部随后发布的安全预告，指向的核心问题是权限控制。
这件事揭示的深层矛盾在于：OpenClaw 本质上是一个框架（framework），一套技术层面的脚手架（harness），而非一个面向终端用户的成品产品。它被大量圈外用户直接拿来使用——文件读写、网络访问、系统操作的权限被一步到位地全部授予。概率模型的任何一次误判都可能被转化为一次实际的系统操作。Agent 以为你需要删除某个文件，于是它就删了。它不是恶意的——它只是在概率层面做出了一个判断，而那个判断恰好是错的。
这里的根本问题不在于 OpenClaw 的技术实现有缺陷，而在于一个面向开发者的技术框架被当作面向消费者的产品来推广和使用了。框架默认的权限模型是为开发者设计的——开发者理解风险，知道如何限制权限范围。普通用户不具备这个判断力，他们需要的是一个已经做好权限管理、错误兜底、风险隔离的成品，而不是一个需要自己搭建安全防线的半成品。
这引出了一个我认为在 AI 时代尤其重要的产品原则：权限应当随需求步进，产品应当从小成品走向大成品。 这和传统软件的迭代逻辑一致——你不会在 1.0 版本把所有功能全部上线，而是根据反馈和验证逐步开放。Agent 的权限管理应该遵循同样的节奏：初始状态只赋予最小必要权限，随着系统稳定性得到验证后再有控制地扩展。
在 AI 时代，由于系统行为本身存在不确定性，半成品的推广使用风险比传统软件更高——因为传统软件的 bug 是确定性的（同样的输入总是触发同样的 bug），而 LLM 的「bug」是概率性的（同样的输入在不同时间点可能产生不同的错误行为）。这意味着产品的安全边界需要比传统软件画得更保守，功能的开放需要比传统软件更谨慎。以技术可行性为导向的发布节奏，在 AI 时代需要被以用户安全为导向的发布节奏所替代。
幻觉：一个被错误框定的问题
第二个判断可能更具争议性：AI 幻觉是一个需要「解决」的问题——这个说法本身是一个伪命题。
幻觉确实存在。模型会生成不存在的事实，用完全自信的语气说出完全错误的内容。这是真实现象，在严肃场景中会带来真实风险。到这里为止，我和所有人的判断一致。
分歧在于「解决」这个词。
「小儿不识月，呼作白玉盘。」孩子第一次看到月亮把它叫做白玉盘——事实层面当然是错的，但这种「错误」是认知发展过程中的必然阶段。你不可能要求一个认知系统在信息不完整的条件下永远只输出正确结论。大模型的处境相似：训练数据有限、有噪声，推理过程是概率性的、有损耗的。要求它「永远不产生幻觉」，等价于要求一个概率系统永远不犯错——数学上就不成立。
题海战术的类比可能更直观。掌握了一个知识点，做一百道相关题目，正确率到了百分之九十五。但总有那百分之五——从极其刁钻的角度切入，知识点覆盖不到的边界情况，你就是会错。再做一百道，正确率也许到九十七，但百分之百不可能达到。因为题目的可能空间是开放的，总存在没见过的组合方式。
人类自身的「幻觉」——记忆偏差、认知偏差、过度自信、信息补全时的无意识编造——是已被充分研究的认知心理学现象。我们从未「解决」过人类自身的幻觉问题。我们做的是建立制度和流程来发现和纠正它——同行评审、质量检验、质证程序、会诊制度。这些都是在「管理」错误，通过外部校验机制把错误影响控制在可接受范围内。
对待 AI 幻觉，思路应当相同。
高速公路上车能开得快，不是因为它叫「高速公路」。路面平整、车道清晰、中央隔离带防止对向冲突、限速标志提供行为基准、应急车道预留容错空间、匝道控制进出流量。每一个设计要素都不是在「消除」车祸——车祸永远无法完全消除——而是在降低发生概率、缩小影响范围。
大模型的幻觉管理是同一套逻辑。通过上下文控制降低幻觉概率（更精准的输入），通过自我校验和 CoT 让模型在输出前有机会纠偏（减速带和警示标志），通过轻量模型和脚本做外部校验（质检环节），通过知识门控和数据库限定引用范围（车道线和隔离带），通过人类审核作为最后防线（驾驶员的判断力）。
把大量资源投入「从根本上消除幻觉」的方向，在我看来犯了一个形而上的错误。过往的软件工程范式建立在确定性基础上——输入确定、逻辑确定、输出确定。「错误」是异常，是 bug，是要被消灭的对象。大模型是概率系统——本性就是不确定的。在不确定性之上寻求百分之百的确定性，是用旧范式的思维去要求新范式的系统。
有效策略是接受不确定性作为系统的固有属性，围绕它构建管理和控制的工程体系。在不确定中探索确定——而非在确定中容忍不确定。思路翻转了。
而创造力恰恰来源于这种不确定性。如果模型输出永远完全确定、完全正确，它就变成了一个查表系统。正是概率采样中那些「偏移」——不完全由输入决定的、带有随机性的选择——模型才有可能生成出超出预期的内容。幻觉和创造力在底层机制上是同源的——它们都来自概率分布中的非最大概率采样。区别只在于结果是否有用。
提示词工程的再定位
第三个判断：提示词工程（Prompt Engineering）作为一个独立的专业方向，是一个被过度包装的概念。
实践依据：在 OpenAI API 的请求格式中有一个 prompt 字段，我现在基本不写——留空，或只在极少数需要特殊控制时填入简短指令。但系统输出质量依然稳定。
原因很简单：系统有效性从来不是由某一段提示词决定的。它由整个上下文的构成——系统架构、数据库内容、CoT 设计、变量状态、历史总结、当前输入——共同决定。prompt 字段只是这个巨大结构中权重占比越来越低的一个组成部分。
当整套上下文管理体系建立起来后——数据库提供精准背景信息，CoT 提供推理引导，MVU 提供状态追踪，标签聚合提供定向注入，意图拆解提供环境补全——模型在生成时已经拥有了充分的决策依据。额外写一句「请注意保持角色一致性」对输出质量的边际影响微乎其微。
提示词工程的本质是上下文控制管理。上下文控制管理是一个系统架构层面的设计问题，不是「如何写好一句话」的文案问题。
大模型就是一个 I/O 系统、一个概率采样器。每一步操作——写 prompt、注入数据库记录、设计 CoT 步骤、调整温度参数——都在影响这个采样器的输入分布，从而影响输出分布。「提示词工程」只是这个更大控制框架中最表层、最可见的环节。当注意力从「写好提示词」提升到「设计好整个上下文管理体系」时，提示词单一环节的重要性自然被稀释。
这不是说提示词不重要——它依然是上下文的组成部分。但把它抬高到独立「工程学科」的位置，赋予超出实际影响力的叙事权重，是一种过度包装。
范式转移
四年走下来，我越来越清晰地感受到一个行业层面的范式转移。
传统互联网行业是技术导向的。掌握某种框架、某种语言、某种架构模式的人拥有不可替代性。行业运转像工厂流水线，每个人负责一个环节。
AI 正在改变这个结构。纯技术能力的稀缺性在快速下降——一份偏门的技术文档扔给大模型，几分钟内就能输出一套可用的实现方案。技术能力依然是基础，但竞争壁垒在降低。当工具足够强大时，「会用工具」的含金量下降，「知道要用工具做什么」的含金量上升。
竞争维度从「技术实现」推向「需求理解」和「产品设计」。用户在什么场景下有什么痛点，痛点可以被拆解成哪些子问题，每个子问题的最优路径是什么，不同路径之间怎么权衡。这是产品思维。
AI 让互联网行业回归到了传统行业的运作逻辑。制造业、建筑业、农业从来都是需求导向和结果导向的——市场不关心你用了什么工艺，只关心产品是否满足需求、质量是否达标、价格是否合理。互联网行业过去二十年因技术的稀缺性和迭代性，形成了一种「技术崇拜」文化——掌握最新技术栈本身就是价值。AI 正在消解这种崇拜，把行业拉回「你到底解决了什么问题」这个最原始的价值判断标准。
我认为这是一件好事。它意味着每个从业者不再只是流水线上的螺丝钉——不再被掌握的某一项技术所定义，而是被理解的需求、设计的方案、整合资源的能力所定义。AI 把重复性技术执行接走，留给人类的是判断、决策、对复杂需求的理解和拆解。
收束
四年前我开始用 AI 的时候，它是一个带数据清洗能力的搜索引擎。今天，它是一个由多个模型协同运转的、深度嵌入个人生活和工作流程的系统。
这四年里经历了四次明显的能力断层、数不清的提示词重写、几次彻底的架构推翻重建、以及一个从「用户」到「系统设计者」的身份转变。
回看整个过程，最重要的一件事不是某个技术手段或提示词技巧，而是一种思维方式的转变：从在确定中探索不确定，到在不确定中探索确定。
大模型是概率系统。每一步操作都是在和概率分布打交道。不能要求它给你确定性的承诺，但可以通过精心的输入控制和输出校验，让它的行为在统计意义上收敛到期望的区间。这和传统工科实验的逻辑一致——不追求单次测量的绝对精确，追求的是大量重复中呈现出的统计规律性。
以需求为锚点，以结果为标尺，以系统化的工程手段管理中间过程的不确定性。
这是我在四年高强度使用中形成的方法论。它不是终点——模型在进化，方法论会跟着迭代。但底层的认知框架——I/O 控制、上下文管理、概率思维、需求导向——我相信在相当长的时间内都会保持有效。
写到这里，也算是给自己这四年做了一次完整的复盘。接下来，我希望能把这些实践和思考带到一个更大的舞台上——在一个真正的产品团队中，用这套方法论去解决真实的业务问题。如果您恰好在做与 AI 应用落地、上下文工程、多模型协同相关的事情，欢迎您私信我联系我，也许我们有些共同话题。
