★ FEATURED ARTICLE 1. 从“能算”到“能想”LLM带来的范式迁移到底移了什么这几年我一直混在AI落地的一线前后做过不少所谓“智能”项目。说实话两三年之前大部分项目还挺拧巴的你让模型做个分类、打个标签效果还行但只要涉及开放式的理解、生成、推理系统立刻露馅。直到大语言模型Large Language Model简称LLM大规模进入工程视野之后我明显感觉到整个技术栈的逻辑变了——不再是我教你什么你学什么而是你见过足够多的世界之后能自己应对没见过的问题。这就是标题里“范式转变”四个字的分量。传统的AI开发范式本质上是“判别式”的。我们给模型标注好类别告诉它“这张图是猫”“这句话是负向情绪”模型学习的是决策边界是一个从输入到标签的映射。它的上限是人类标注的密度和维度——你没标过“讽刺性幽默”它就永远识别不出讽刺性幽默。而LLM走的是另一条路它先通过海量文本学会“接龙”也就是预测下一个词但就是在这样一个看似简单的任务上它把语言背后的语法、事实、逻辑、常识、甚至某种程度上的推理能力全部压进了几百亿个参数里。等到参数规模大到一定阈值各种让人意外的能力就开始涌现上下文学习In-Context Learning、思维链推理Chain-of-Thought、代码生成、多步规划。注意这些能力不是我们显式“编程”进去的也不是标注出来的而是从数据和参数规模中“长”出来的。这件事对传统的软件工程方法论几乎是颠覆性的——你没法用“需求文档模块设计”的思路去描述一个LLM应用因为它没有明确的模块边界。如果要用一句话概括这种范式转变我会说过去我们做的是“教机器认路”现在做的是“给机器一座城市的地图资料让它自己找路”。而这座“城市地图”就是我下面要展开的“认知基础设施”。到底什么叫认知基础设施我听过很多说法什么“大脑的操作系统”“知识的中台”都太虚了。我的理解很实在它是一个由模型能力、知识供给、工具调用、记忆机制、评估反馈共同构成的系统底座。就像电网之于电器、公路之于汽车LLM本身是发动机但要让发动机真正跑起来你需要一套完整的支撑体系——数据管道、向量检索、Prompt编排、评测平台、安全护栏。这套体系加起来才是你在生产环境里真正依赖的东西。这篇文章就是围绕这套体系展开的。不管你是刚接触LLM的应用开发者还是已经在做架构决策的技术负责人又或者是想搞懂“现在AI到底能干什么”的产品经理我都尽量把底层逻辑和实操经验拆开讲透。我不会念教科书只讲我这几年在真实项目里反复验证过的东西以及踩过的坑。2. 为什么说LLM是“基础设施”而不是“新工具”2.1 工具与基础设施的本质区别我们得先把概念掰扯清楚。工具是什么工具解决一个点上的问题。计算器是工具它只能算数Photoshop是工具它只能处理图像。但基础设施是什么基础设施是“其他东西可以建在它上面”的那一层。电网本身不发电给某一个具体的电器用它服务于所有电器。铁路本身不运送某一种具体的货物它承载所有货物。LLM的特殊之处在于它的“可承载性”极强。文本生成、分类、抽取、翻译、情感分析、代码生成、SQL转写、意图识别、摘要、改写……这些原本各自需要专门模型甚至专门团队的任务现在一个足够强的LLM全部能覆盖还能跨模态接图片、音频、视频。你不必再为每一个细分场景训练一个模型你只需要基于一个通用的“能力底座”用上下文、知识、工具去做适配。这就是“基础设施化”的第一个信号通用性替代专用性。第二个信号是生态化。你会发现围绕LLM已经生长出了完整的技术栈——向量数据库、编排框架LangChain这类工具链、评测体系如LLM-as-a-Judge、推理优化引擎各种量化、批处理方案、Agent框架ReAct、Plan-and-Execute这类范式。这些组件不是某一个产品的附属品而是一个生态。当一个技术出现生态说明它已经不只是工具而是土壤。第三个信号是“规模经济”效应。基础设施最典型的特征是前期投入巨大但边际成本极低。训练一个大模型的成本是天文数字但训练完之后每一次调用的边际成本可以压缩到很低同时服务成千上万个应用。这种“一次建设、多次复用”的模式和电网、公路的逻辑是一模一样的。2.2 认知基础设施包含哪些构成要素我习惯把一个完整的认知基础设施拆成五层第一层模型层。这是最底层的“认知引擎”负责理解与生成。可能是一个闭源大模型API也可能是一个开源底座模型如某个7B或70B的开放权重模型。这一层的核心指标是基础智力水平——逻辑推理、知识覆盖、指令遵循、多语言能力。它决定了你的应用“聪明不聪明”。第二层记忆与知识层。模型有截止知识有幻觉倾向没法回答私有数据问题。所以你需要一个外挂的“记忆库”和“知识库”——也就是检索增强生成RAG体系先把文档切成块Chunk用Embedding模型向量化存进向量数据库查询时先检索相关片段再丢给LLM做生成。这层的核心指标是召回准确率和上下文相关性。第三层工具与行动层。LLM不能主动“做事”它只能产出文本。要让它在真实系统里有行动力必须接工具API调用、数据库查询、代码解释器、浏览器操作、办公套件操作。这层的核心设计是Function Calling函数调用和Agent循环——让模型自己决定“要不要调工具、调哪个工具、调完工具怎么处理结果”。第四层编排与流程层。单次调用只能完成单步任务真实业务往往是多步流程先理解意图再拆解计划然后逐步执行中途可能需要追问用户最后还是汇总输出。这层需要编排框架把模型的能力组织成一条条可控制的流水线同时保留人工干预的入口。第五层评测与安全层。这是最容易被人忽略但最要命的一层。模型输出是概率性的同样的问题今天答对了明天可能答错换了个措辞结果就不一样。所以在生产环境里你必须有自动化的评测集、回归测试机制、内容安全过滤器、权限控制体系。没有这层前面做得再好都是沙上建塔。这五层合在一起才是标题里说的“认知基础设施”。单独拿一个模型出来聊“AI多厉害”是没有工程意义的——真正有价值的是这套底座能稳定支撑多少业务场景。3. 核心技术拆解从Transformer到上下文工程3.1 Transformer到底在做什么——一个生活化的解释很多人一听“注意力机制”就头大但它的核心思想其实特别朴素。想象你读一段话“小明虽然迟到了但他带来的蛋糕非常受欢迎。”你的目光扫过“虽然”的时候会下意识地把它和后面的“但”关联起来当你读“蛋糕”的时候你脑子里会浮现“吃的、甜的、生日”这些背景知识。Transformer的注意力机制做的就是这个事对于序列里的每一个词它都会计算一个“我应该重点关注谁”的权重分布然后按照权重把相关信息融合进来。关键的区别在于RNN时代模型是按顺序一个词一个词“读”的读后面的词时前面的信息会逐渐衰减就像人听一句长话听到最后忘了开头。注意力机制则让序列里任意两个位置可以直接互通无论隔得多远都能直接建立联系。这就解决了长期依赖问题也为并行计算扫清了障碍——因为你不再需要严格按顺序处理可以同时计算所有词之间的关系。所谓“多头注意力”就是多组这样的注意力头并行去捕捉不同类型的关联有的头负责语法关系有的头负责指代关系有的头负责语义相关性。然后通过层叠的网络结构把这种“关联捕捉”一层一层抽象上去底层学词法中层学句法高层学语义甚至常识。3.2 预训练、SFT与RLHF——模型能力的三级锻造一个LLM的诞生大致经过三个阶段理解这三个阶段对你用好它至关重要。第一阶段是预训练Pre-training。把互联网级别的大规模语料喂给模型目标只有一个预测下一个词。听起来简单但正是在无数次“猜下一个词”的过程中模型被迫学会了语法、事实、推理甚至代码能力。预训练决定了模型的“知识上限”和“基础智力”。这也是为什么模型界总在拼数据规模和算力——因为这部分真的属于“大力出奇迹”。第二阶段是有监督微调Supervised Fine-Tuning, SFT。预训练出来的模型只会“接龙”不会“听话”。你需要人工写大量的高质量指令-回答对让模型学会“用户问什么我就答什么”的对话格式。这个阶段的质量比数量重要得多。我自己做过实验用5万条精心构造的高质量指令对的效果有时候比50万条从网上随便抓的垃圾问答效果还好。因为模型学的是“范式”喂给它错的东西它就把错的范式学进去了。第三阶段是基于人类反馈的强化学习RLHF。这是让模型从“还不错”进化到“很惊艳”的关键一步。简单说就是让模型生成多个回答让标注员排序哪个更好训练一个“奖励模型”去学习人类的偏好再用强化学习算法让生成模型去对齐这个奖励模型。这一步的核心作用是让模型学会“做正确的选择”而不是仅仅“说流利的话”。这三阶段合在一起就是所谓“对齐Alignment”。对齐的质量直接决定了模型在真实场景里的可用性。你会发现有些模型“智商很高但情商很低”莫名其妙拒绝你的合理请求有些模型“话很漂亮但事实错误一堆”这背后往往就是对齐做偏了——过度追求安全导致误伤或者过度追求流畅导致幻觉加重。3.3 推理优化为什么7B的模型能跑得动70B才能跑的任务实际工程中我们逼于成本压力不可能所有场景都用最大号的模型。所以推理优化这个领域这两年爆炸式发展。量化是其中性价比最高的一招。模型的参数默认是16位浮点数FP16或者32位FP32每个参数占2或4字节。70B的模型光内存就占140GB消费级硬件根本没法跑。量化就是把每个参数压缩到8位整数INT8甚至4位整数INT4模型体积直接缩到原来的四分之一甚至八分之一内存占用大幅下降速度还更快。代价是极轻微的精度损失——对于大多数文本生成任务这种损失根本感知不到。目前主流的GGUF格式、AWQ、GPTQ这些方案都是为了解决量化后的部署问题。蒸馏也值得一提。思路是用强大的大模型当“老师”生成大量的高质量输入-输出对去训练一个小模型“学生”。这比人工标注便宜得多而且学到的模式更接近大模型。很多号称“专业领域小模型”的产品背后都是这个套路。我见过一个场景用70B模型蒸馏出的7B模型在特定垂直领域的回答质量比直接微调7B模型高出一大截。还有投机采样Speculative Decoding。思路是用一个又小又快的模型先草拟一批token再用大模型去拟合验证因为小模型的草稿大多能通过大模型的验证所以整体推理速度可以大幅提升。这对在线延迟敏感型场景特别有价值。3.4 上下文工程决定应用体验的隐藏战场很多人以为用LLM就是写提示词把需求说清楚就行。其实没那么简单。我越来越觉得“上下文工程”Context Engineering才是真正拉开水平的地方。什么是上下文就是你喂给模型的全部信息。它包括系统提示词System Prompt、用户问题、检索到的知识片段、对话历史、工具定义、甚至few-shot示例。上下文工程的目标是把你拥有的信息以模型最容易理解吸收的方式组织起来。举个我踩过坑的实例。早期我们做客服机器人的时候简单地把用户问题和向量检索出来的知识点拼在一起丢给模型。效果是经常答非所问明明知识库里有正确答案模型就是不用。反复排查问题出在检索环节的结构上——片段太碎、缺少原始文档的完整信息、没有标注知识的来源和可信等级。后来我们把检索结果改成了“带元信息的引用块”标题摘要原文片段新鲜度标注同时在Prompt里强制要求模型优先使用高置信度的引用内容并明确告知它找不到答案时就说不知道。改完之后准确率直接从61%跳到了88%。这背后其实涉及两个机制。一是“注意力资源分配”上下文中信息多了模型会分心你需要通过结构化的排版如用Markdown、用编号列表、用明确的指令块把注意力引导到关键信息上。二是“自洽性约束”模型倾向于生成和已有上下文一致的内容所以你给出的上下文本身就是最强的“引导信号”——给它垃圾它就吐垃圾给它结构清晰、标注分明的信息它的输出质量也会随之提升。4. 实操指南如何从一个想法搭建出LLM应用的完整底座4.1 先用“最小闭环”验证场景价值我在带团队做LLM项目时有一条铁律先不要写架构文档先花几天时间做一个“最小可用的Demo”验证这个场景到底能不能被LLM撑起来。因为LLM的能力边界不是靠文档推理出来的是要实测的。具体怎么测拿一个最真实的任务样本集比如50个典型的用户问题用最cheap的方式跑一遍用GPT-4级别的强模型、最简单的Prompt不搞什么复杂的系统提示词、不做RAG、不接工具直接硬答。这一步的目的不是测出最优效果而是测出“上限”——如果最强的模型、最简单的方案连及格分都达不到说明这个场景的核心逻辑有问题别浪费时间到工程造轮子上。如果超过了及格分那恭喜后面所有工程手段RAG、微调、Agent、评测都是在这个基础能力之上“加buff”。记住工程只能放大模型的潜力不能凭空创造模型没有的能力。4.2 模型选型选大还是选小选开源还是选API这是每次复盘必被问的问题。我的建议是动态地看项目初期首选闭源高性能API。原因有三一是效果好强模型的基础能力是开源社区短期追不上的二是省心你不用管部署、算力、稳定性把精力全放在产品和数据上三是快速验证API接入成本低到可以忽略。很多大厂的高级接口兼容OpenAI的API格式换一个BaseURL就能切迁移成本也不高。进入规模化阶段引入开源模型做降本增效。一旦需求验证通过、调用量上来了成本就变成不可忽视的变量。这时候可以用中等规模的开放权重模型如13B到70B之间的规模配合量化压缩、蒸馏很多场景的效果也能达到API强模型的八到九成但成本可能只有十分之一。关键是有数据隐私合规要求的场景私有化部署几乎是唯一选择——数据不出域这个约束是API方案解决不了的。至于选多大参数量参考这个经验值简单的分类、抽取、格式化任务7B到13B级别足够了复杂推理、长文档分析、Agent决策这类高难度任务至少需要34B或70B级别否则翻车率会让你怀疑人生。有条件的话混合架构最优简单请求走小模型高难请求走大模型中间加一层路由判断总体成本能省一半以上。4.3 搭建RAG系统的七个关键步骤RAG是当前企业落地LLM最常见的方式没有之一。因为它解决了两个核心痛点模型不知道私有业务数据模型的知识有截止时间。下面是我实践沉淀下来的七步流程第一步确定知识源。先盘清楚哪些文档要进知识库。这一步看起来低级但特别容易被忽略——现实世界里大量文档是扫描件、PPT、乱排版的网页解析出来全是垃圾。我见过一个团队花了三周搭管线最后发现OCR出来的文本里一半是乱码整个知识库就是一场灾难。先把源头的数据质量搞定比后面所有优化都重要。第二步清洗与切块。文档清洗完文本之后要切成合适的块Chunk。块太小语义不完整块太大噪声太多检索不精准。我的经验值是中文场景按段落切分单块控制在200到500字之间相邻块之间保留少量重叠比如50字防止语义被拦腰截断。Markdown结构可以直接保留表格不要拍平成裸文本尽量保留为结构化格式。第三步向量化与索引。用Embedding模型把每块转成向量存进向量数据库。有几个细节很重要一是中文场景建议使用中文语料优化过的Embedding模型英文模型对中文的支持普遍一般二是索引要建混合检索关键词BM25向量召回纯粹向量检索对专有名词、缩写特别不友好三是元数据要丰富——来源、标题、更新时间、权限标签、置信度后面过滤语义时全靠它。第四步查询改写与路由。用户输入的问题往往又短又含混。不要直接拿原始query去检索先让LLM做一个查询改写补全指代、扩展同义词、拆解多意图。例如用户问“上个月的报表怎么还没发给我”可以改写成“邮件发送延迟、月度报表、发送状态查询”几个检索子句召回效果完全不一样。如果是多轮对话还要考虑用“上下文压缩”把历史对话里和当前问题相关的部分提炼出来再去做检索——这个点能显著提升多轮场景的准确率。第五步重排Rerank。向量检索出来的Top 20里可能有一半是不相关的。直接用会污染生成质量。必须加一个Rerank环节用交叉编码器Cross-Encoder对召回结果逐条打分重排只保留Top 3到5个高置信片段送入Prompt。这一步从我的实测来看对答案准确率的提升幅度在15%到20%之间是RAG整个链路里性价比最高的一个环节。第六步生成与引用。把检索到的片段、用户问题、系统指令组装成最终Prompt。生成模块要做三件事严格限定模型只基于给定上下文回答强制要求输出内容标注引用来源对“知识库中没有答案”的情况给出兜底话术。特别注意“引用”这件事它不仅是为了合规更重要的是它极大地抑制了幻觉——模型知道你“盯”着它的信息来源它会更老实。第七步评估与迭代。RAG系统上线后不是结束是迭代的开始。我强烈建议每两周对一个几百条的评测集做一次全量回归指标包括检索召回率RecallK、答案准确率LLM-as-a-Judge打分结合人工抽样复核、回答引用率、端到端延迟。任何一次Prompt改动、切块参数调整、Embedding模型升级都要跑一遍回归否则你以为在优化实际可能是劣化。4.4 Agent与工具调用让模型真正“做事情”RAG解决的是“知道什么”Agent解决的是“能做什么”。两者结合才算完整的认知基础设施。Agent的核心机制是“感知-规划-行动-观察”的循环LLM作为推理核心观察当前状态判断要不要调用工具选择一个工具并生成调用参数拿到工具返回结果后再次判断是继续行动还是给出最终答案。这个循环可以重复多次模型就像一个“会拆解任务的调度员”。工程上我最推荐的入门范式是ReAct把思维过程显式写出来交替出现“Thought我想...、Action我调用...、Observation我看到...”一直到可以给出Final Answer。很多框架内置了这个模板但你要理解它背后的意义——强制模型把推理过程展开犯错的概率会大幅下降因为每一步都有依据。做Agent最核心的实操建议用四个字概括就是限制自由。看起来反直觉但我的经验是Agent越自由越容易出事。你给它的工具越多它越不知道怎么选你允许它无限步推理它就越会钻牛角尖。正确做法是少给工具——只给必须的那三五个限制步数——最多迭代5轮超过就强制收敛提供兜底——Agent无路可走时必须走“请求用户澄清”而不是自己胡编一个结果。关于Function Calling有一条血泪教训函数定义要写得极其详细。参数说明、枚举值的含义、异常情况处理都要写清楚。模型是靠函数定义来理解“这个工具到底是干嘛的”定义写得含糊模型就会产生幻觉式调用——比如把字符串参数传成JSON对象或者先生成代码再去执行而不是直接调用已注册的API。别图省事函数定义相当于你给模型写的“操作手册”手册写得好Agent才能可靠执行。5. 常见问题与避坑指南那些文档里不会写的教训5.1 幻觉模型一本正经地胡说八道怎么办幻觉是所有LLM应用头痛排名第一的问题。它不是bug而是模型的“默认模式”——模型本质上是在“生成最像样的文本”而不是在“查数据库”。所以别指望通过换一个模型从根本上消除幻觉只能从多个维度压制它。我总结的幻觉治理组合拳是这样的第一所有事实型回答必须走RAG禁止模型裸答业务问题第二Prompt里明确写出“如果不确定请直接说不知道”并且要在评测时专门测“不知道”场景的触发率第三输出层加校验——如果是抽取任务用正则/规则校验格式约束如果是结构化输出用JSON Schema强制格式第四引入“第二意见”机制一个模型回答后用另一个独立的模型或规则做事实交叉验证不一致就触发澄清流程。我还发现一个规律幻觉率跟模型参数量负相关跟任务难度正相关。当你发现幻觉率高得离谱优先怀疑的不是提示词而是任务本身是否超出了模型的基础能力。这时候该做的是拆任务而不是继续调Prompt。5.2 长上下文真能替代RAG吗这两年各家模型都在卷上下文长度从4K到32K、128K、200K、1M。于是经常有人问我“上下文窗口这么大了是不是不用搞RAG了直接把文档全塞进去就行”我的回答是长上下文确实解决了一类问题但完全是另一个维度的事替代不了RAG。长上下文的价值在于处理“一次性的、需要全局理解的”任务——比如分析一整份代码仓库的结构、通读一本书总结要点、对一个长对话做全局摘要。这种场景RAG反而吃亏因为检索是“取片段”片段之间的全局关联可能被丢掉。但长上下文有三道坎。第一是成本输入token按量计费一页A4纸大概800到1000个token塞一份20页的文档就是2万token对API调用来说成本感人。第二是“迷失在中间”Lost in the Middle模型对很长的中间部分注意力会衰减开头和结尾的信息记得牢中间部分大量被忽略。实测下来超长语境下的有效信息召回率远没有理论那么高。第三是延迟context过长首token响应时间变长在线交互体验会很差。所以我现在的方案是分层短问答走RAG精挑细选相关片段全局理解走长上下文全量喂入两者互补而不是互相替代。5.3 评测没有评测一切优化都是玄学这是我反复强调但总有团队忽略的一环。很多团队做完一个LLM应用拍脑袋觉得“看起来不错”就上线了。问题是LLM的输出是概率性的同样的Prompt换一种措辞结果就飘了。没有量化评测你根本不知道今天系统是变好了还是变差了。我的评测方案分三层第一层自动化客观指标。比如检索的RecallK、生成的ROUGE/BLEU对摘要类任务、结构化抽取的准确率与完整率、端到端的任务成功率。这类指标稳定、可回归、适合CI/CD里跑。第二层LLM-as-a-Judge。用一个强的Judge模型比如比主体模型高一个档次的API模型按评分标准对输出质量打分。但要防“自我偏好”——Judge模型会偏爱和自己同源的模型产生的回答风格所以必要时用双Judge交叉或者Judge模型的输出只做参考不揪着不放。第三层真人对拍。每周人工抽检50到100条实际会话标记好/差/拒绝回答/幻觉等情况用来校准自动化指标是不是“分数虚高”。自动化指标永远只能接近真实感受不能完全等价。没有评测体系的LLM项目就像没有测试服务的Web系统——你敢上线就得敢半夜接电话。5.4 成本控制LLM不是无限取用的免费餐很多团队上线LLM应用之后第一个月账单吓一跳。这是普遍现象。成本有三个大头推理token费用、向量化处理费用、人工标注与评测成本。控制策略上最有效的不是砍用量而是做分层路由。我经常搭一套“模型路由”机制先用一个小模型做意图识别把请求分级——简单请求分类、改写、抽取走小模型复杂请求推理、代码、综合分析走大模型。实测下来比例控制在“6成小模型、4成大模型”总成本能降一半还不止质量几乎无损失。另外有一个不起眼但非常有效的省钱技巧缓存。LLM服务的缓存不是传统意义上的HTML缓存而是“语义缓存”——把用户请求和之前的请求做语义相似度匹配如果高于某个阈值比如0.95直接复用之前的回答不调模型。在高频客服场景命中率能到30%甚至更高。这是一块白捡的钱。5.5 数据安全与合规不止是“上不上云”的问题最后必须聊数据安全因为我在真实项目中见过太多翻车现场。第一条原则能私有化就私有化。数据不出域是很多行业的底线。医疗数据、金融数据、企业内部文档一旦通过外部API传输无论协议上怎么承诺“不留存”心理上和法律上的风险都不可控。所以选型时优先评估开源模型私有化部署的路线这应该是一个决策前提而不是可选项。第二条原则敏感信息脱敏前置。即便用了私有化部署管线内部对流日志、用户输入、检索片段也要做敏感信息识别与脱敏。正则规则小模型分类器组合把身份证号、手机号、银行卡号这类字段提前打码避免它们进入训练语料或者被模型原样吐出来。第三条原则权限体系不能扔给模型管。LLM没有“权限”概念。你给它的上下文里如果有A部门的数据和B部门的数据它就会“一视同仁”地生成。所以知识库检索阶段就要做权限过滤——根据当前用户的角色在RAG阶段直接过滤掉无权访问的文档而不是把过滤任务交给生成模型。我把这叫做“入口治理”入口没堵住出口什么都会漏。很多企业担忧的“大模型说出不该说的东西”根源往往不是模型坏而是它的上下文里放了不该放的东西。记住一句话你喂什么它才能说什么你把门堵住它就是一座安全的博物馆而不是一扇打开的信息瀑布。6. 结语把模型当“新人”把系统当“组织”最后说点个人体会。我曾经思考过一个问题为什么同样一个模型A团队做出来的产品让人“哇塞”B团队做出来的却让人“就这”区别从来不在模型本身而在于系统。A团队围绕LLM搭了完整的认知基础设施——高质量的知识供给、精细的上下文编排、可靠的工具调用、严格的评测反馈、严密的安全边界。B团队只是把模型当成一个“高级API”丢了个问题进去期待奇迹发生。这就像两个公司招了同一位名校毕业生。一家公司给他明确的职责、充分的资料、配合默契的团队、及时的工作反馈他很快就独当一面另一家公司什么都不准备扔给他一个含糊的任务期待他自生自灭结果是显而易见的。LLM时代写几行提示词调用API非常容易但把它变成可靠、稳定、可交付的产品仍然是一个基础设施工程需要的是体系化的设计、反复的评测迭代、以及大量脏活累活的数据治理。这条路没有捷径但有迹可循。希望这篇文章能把“迹”画清楚让你在搭自己的认知基础设施时少走我走过的弯路。最后再送一个小技巧如果只能带走一个建议请记住——从最小闭环开始先验证再建设先跑通再优化先定评测再谈迭代。做到这三点哪怕踩了坑你也能清楚地知道坑在哪里理性地决定值不值得绕过去。
阅读完成 · 觉得有帮助？
