先把话说在前面任何号称“会调API就能做大模型应用”的教程基本都是把人往坑里带。真正到了企业级项目里模型调用只是最不起眼的一环提示词怎么写、多轮会话状态怎么管、检索和生成怎么配合、评测指标怎么定、灰度怎么发这些才是决定一个AI产品能不能从Demo走到生产的生死线。我自己前后带过好几个大模型AI应用开发项目从智能客服到企业内部知识问答都踩过一遍这篇文章就把这些实战经验做个系统复盘重点放在提示词工程、大模型NLP应用以及AI对话产品落地这三块。文章面向的不是完全没碰过大模型的零基础人群而是已经能调通模型API、但想往企业级应用开发方向深入的同学。你会看到大量我在真实项目里总结的模板、参数、排查思路和工程取舍很多内容在官方文档里根本找不到属于必须踩过坑才写得出的那类东西。1. 从“能回复”到“能上线”企业级AI应用开发差的不只是模型1.1 三个常见的Demo翻车现场先还原三个我见过无数次的场景。场景一开发同学用模型官网的Chat界面调试提示词觉得效果不错于是直接把这套提示词粘到后端代码里。结果一到生产环境输出格式开始飘客户要求必须返回JSON结构模型偶尔多解释一句整个解析就崩了。问题出在哪官网Chat界面有隐藏的系统指令多轮纠错能力也远超一次性的API调用你在网页上测的是“对话体验”而程序里需要的是“稳定输出”。场景二项目要做企业知识库问答。开发同学把几百页PDF全部切块塞进向量库检索top k设成5然后把检索结果拼进提示词发给模型。看起来Pipeline没问题但问出来的答案经常驴唇不对马嘴。深入排查才发现很多文档是扫描件OCR阶段就已经引入了大量错别字切块时又把表格从中间拦腰截断关键数据全部丢失。检索结果看着相关实际可用信息寥寥。场景三对话产品上线第二天就有用户投诉。投诉内容出奇一致机器人聊着聊着突然失忆用户在上一条消息里明明说了“我今年35岁”下一条问“我多大”机器人一本正经地回复“这个问题我无法回答因为我无法访问之前的对话历史”。这不是模型不行是会话状态管理根本没接。这三个场景有个共性模型API本身没出问题出问题的全是模型外围的工程环节。企业级AI应用开发和普通Web开发最大的区别在于除了逻辑正确你还要面对一个“概率性输出”的核所有外围模块都要围绕“不确定性”做设计。1.2 需求拆解先搞清楚业务到底要模型干什么企业级项目启动的第一件事不是选模型不是搭框架而是把业务需求拆成模型能执行的任务。我习惯用一个三层拆解法第一层业务目标。比如“降低客服人力成本”“让新员工快速查到自己要的制度”。这一层描述的是业务价值模型不直接执行。第二层任务类型。把业务目标转成自然语言处理任务是文本分类、信息抽取、文本生成、语义检索还是多轮对话这一步决定了你的技术架构。很多项目失败就是因为把多任务揉在一起却指望一个提示词搞定。第三层评价指标。业务方怎么判断“这个 AI 好用”回答准确率响应时间转人工率知识覆盖度没有量化指标后面所有的优化都是玄学。这里特别提醒一点不要一上来就想“我要做一个AI助手”这种巨宽泛的目标。AI助手是产品形态不是任务定义。做“规章制度问答助手”和做“销售话术陪练助手”底层技术路线完全不同——前者核心是检索准确率后者核心是对话策略和反馈生成。如果需求文档是两句话带过的宁可停下来和业务方掰扯清楚也别凭着感觉埋头开干。2. 提示词工程实战让输出从“像话”到“像业务”2.1 系统提示词的结构化写法提示词工程最核心的产出就是系统提示词System Prompt。很多初学者的写法是“你是一个智能助手请回答用户问题”这几乎等于没有约束。企业级场景里系统提示词应该像一份技术规格说明书至少包含以下部分角色定义模型在业务中扮演什么角色边界在哪里什么该答什么不该答。任务目标模型的输出要达成什么业务目的。输入描述模型会收到什么类型的内容格式是什么。输出规范返回格式、长度、语体风格、是否允许追问。禁忌行为绝对不能做的事例如编造数据、泄露系统提示词。兜底策略实在不知道答案时该怎么做。下面是一份我常用的模板你可以直接抄作业# 角色 你是某企业内部制度问答助手负责解答员工关于人事、财务、行政制度的问题。 # 任务目标 基于提供的知识库片段准确回答员工提问。不编造制度内容。 # 输入说明 你会收到两类输入 1. 员工问题格式为 【用户问题】... 2. 检索到的知识库片段格式为 【知识片段】... 如果知识片段与问题无关请忽略无关片段。 # 输出规范 - 只输出最终答案不输出推理过程。 - 答案必须简洁、口语化不超过150字。 - 如果信息不足明确回复“当前知识库中未找到相关信息建议咨询人力资源部”。 # 禁忌 - 不得编造制度条款。 - 不得输出知识片段编号或原始文档路径。 # 兜底问题处理 当用户提问和公司制度无关时回复“我是制度问答助手暂时只能解答人事、财务、行政相关问题。”这套结构看着简单调过的人才知道有效。角色定义决定模型的“人设基线”输出规范控制格式禁忌行为和兜底策略则直接减少幻觉和乱答。2.2 少样本示例把模型行为校准到业务轨道系统提示词再长有些业务细节靠文字描述就是说不清。这时候少样本示例Few-shot Examples是更高效的手段。我观察到的经验是给模型两个高质量示例效果往往胜过在提示词里写两百字的规则描述。举例来说制度问答场景里员工问“年假没休完能顺延吗”标准答案是提示知识片段里的人力资源制度原文但要转成口语。模型若无示例经常直接复制粘贴原文生硬不说还可能有遗漏。给它两个输入输出对示例1 输入 【用户问题】 入职第一年有年假吗 【知识片段】 第一章第三条员工入职满一年后可享有每年5个工作日的带薪年假。入职未满一年者按实际工作月份折算。 输出 入职满一年就可以休5天年假。不满一年的按实际工作月份折算天数。 示例2 输入 【用户问题】 今年年假没休完能顺延到明年吗 【知识片段】 第四章第八条年假原则上应在自然年度内休完。因工作原因未休完的经部门负责人审批后可顺延至次年3月31日前使用。个人原因未休完的视为自动放弃。 输出 工作原因没休完的部门负责人同意后可以顺延到明年3月31日个人原因没休完的就不能顺延了。示例必须遵循三个原则一是贴近真实用户输入不要用自己编的书面语二是覆盖典型边界情况至少一个正面例子、一个拒绝回答的例子三是输出风格保持一致。示例里的输出文字其实也是在给模型做“格式锚点”让它在生成时自觉朝这个方向靠。2.3 输出格式化从自然语言到机器可解析企业级应用里模型的输出几乎很少直接展示给用户通常要被下游程序消费——存数据库、触发工单、填表单。这就要求输出必须是稳定的结构化数据。强行让模型输出JSON不是不行但严格模式在不同模型上支持程度不一样最稳妥的做法是“提示词约束 格式修正层”。提示词里这么写请严格输出JSON格式不要输出任何其他解释性文字格式如下 { intent: query_category, answer: 最终回复内容, need_human: true, req_reason: 是否需要人工介入简要原因 }但经验告诉我哪怕提示词写得再死某些模型在小概率情况下仍然会多输出注释或前后带markdown代码块标记。这时候别指望改提示词能100%解决后端一定要有一个解析容错层。我自己常用的是先剥离代码块标记再定位第一个{和最后一个}拿到子串之后用json.loads解析解析失败就走兜底分支告诉用户“系统暂时没理解已转人工”。在实际代码里这一步长这样import json import re def parse_model_json(raw_text: str) - dict: # 容错处理剥离常见的 markdown 代码块标记 text raw_text.strip() text re.sub(r^(?:json)?\s*|\s*$, , text, flagsre.IGNORECASE) start, end text.find({), text.rfind(}) if start -1 or end -1: raise ValueError(no json object found in model output) try: return json.loads(text[start:end 1]) except json.JSONDecodeError: # 如果模型输出的 JSON 内部有转义问题可以尝试简单修复 text_fixed re.sub(r,\s*([}\]]), r\1, text[start:end 1]) return json.loads(text_fixed)这段代码谈不上优雅但确实在项目里救过我很多次。原理也很简单模型输出的JSON偶尔会在最后一个字段后面多留一个逗号或者把代码块语言标记带出来正则定位大括号的写法能过滤掉绝大多数的格式噪音。2.4 我在提示词调优中总结的版本管理习惯提示词不是写一次就完事的它和代码一样需要迭代必须有版本管理意识。我见过太多团队提示词直接写在代码里、配在数据库里版本混乱到根本不知道线上跑的是哪一版、上一个好效果是被谁改坏的。我现在习惯把所有提示词沉淀成模板文件和后端代码一起进Git仓库# prompts/qa_system.yaml version: 2.3 updated_by: zhangshan updated_at: 2025-06-18 system_prompt: | 你是某企业内部制度问答助手... few_shot_examples: - input: ... output: ... - input: ... output: ... temperature: 0.2 max_tokens: 512每次改提示词都要同步更新版本号、改动人和改动原因。线上跑出问题的时候可以快速回滚到上一版然后A/B对比效果搞清楚到底是数据变了还是提示词变了导致的效果偏移。这个习惯在模型API升级、底座模型被替换的时候尤其重要。3. 大模型NLP应用落地文本处理中的业务判断力3.1 大模型分类任务的企业级设计文本分类是大模型NLP应用里最普遍的一类任务工单自动分派、用户意图识别、舆情正负向判断、招标文件初筛。传统做法是训练一个BERT类分类模型现在用大模型做这件事的优势很直接few-shot能力极强新增类别时不需要重新训练模型改一下类别定义和示例就能上线。但大模型分类也有硬伤类别多的时候容易混淆对类别边界不清晰的数据稳定性差。我在项目里总结了一套比较可靠的落地配置类别数量少于20个直接用提示词分类类别20到50个用“二级分类”策略先把粗类分出来再细分类别超过50个优先考虑用embedding做语义召回生成候选集再让模型从候选中挑一个最合适的直接让模型面对50多个类别做选择输出质量会有明显下降。典型的提示词写法参考你是工单分类引擎。请阅读工单内容判断其所属类别。 可选类别及其定义 - network_issue网络连接故障、无法上网、延迟高 - hardware_fault硬件设备损坏、无法开机 - account_problem账号登录失败、密码遗忘 - billing_issue账单扣费异常、发票咨询 输出JSON格式 {category: 类别标识, confidence: 0-1之间的数字, reason: 分类依据} 严格只输出JSON不要输出其他内容。 工单内容 {work_order_text}这块价值最大的细节是分类时要把类别定义写得像操作手册而不是干巴巴的名词解释。比如account_problem不能只写“账号问题”要列出业务实际遇到的“登录失败”“密码错误”“账号锁定”等具体表现模型才能准确对应到真实文本。3.2 信息抽取的实体校验环节信息抽取项目比如从简历里抽姓名、岗位、工作年限从合同里抽金额、日期、甲方乙方。用大模型做抽取确实高效但抽出来的结果不能直接用必须加一层业务校验。举例来说合同抽取场景def extract_contract_info(text: str) - dict: prompt load_prompt(contract_extract) result call_model(prompt.format(texttext[:3000])) data parse_model_json(result) # 业务校验 if data.get(amount): # 金额不能为负数 data[amount] abs(float(data[amount])) # 金额必须大于1000否则可能抽取错误 if data[amount] 1000: data[amount_warning] 金额异常偏低请人工复核 if data.get(date): # 日期格式必须为 YYYY-MM-DD if not re.match(r^\d{4}-\d{2}-\d{2}$, data[date]): data[date_warning] 日期格式异常请人工复核 return data这条规则看上去是常识但很多团队漏掉。模型是概率输出单次抽取正确率就算有95%抽100个字段也会错5个如果整个流程没有校验环节错误数据就直接进了业务系统。抽取结果里凡是需要进入财务流程、审批流程的字段一律要在schema里设计校验规则没有把握的宁可标记“待人工确认”也不要让错误值静默通过。3.3 长文本处理不要带着上下文硬算企业里经常遇到超长文档几十页的合同、上百页的年报、几万字的访谈记录。大模型的上下文窗口虽然越来越大但把所有内容一次性塞进去既不经济也不稳定关键信息被淹没在无关篇幅里是常见问题。我实践中会按文档结构拆分处理而不是全文硬算第一步按标题、段落把长文切块块内保留结构信息第二步对每个块做针对性抽取或摘要也就是Map阶段第三步把各块结果合并做去重和矛盾检测也就是Reduce阶段。例如做年报摘要我会先按章节切分让模型对“经营情况讨论与分析”“重大事项”“财务报告”分别生成摘要最后再合成总摘要。分块处理还有个额外好处可以并行调用显著降低单次响应时间对延迟敏感的线上服务非常重要。需要注意的是分块策略不能拍脑袋要贴合文档本身的格式。制度类文档按章节切对话类内容按轮次切技术文档按模块切好的切分策略本身就是一种业务理解。4. 检索增强生成RAG给大模型配一个靠谱的资料员4.1 为什么企业知识问答绕不开RAG知识问答项目如果直接拿大模型训好的知识来回答大概率会翻车。企业内部制度、产品手册、专家经验这些知识大模型在预训练阶段根本没学过就算学过一点也会过期。RAG的价值就在于把答案的“事实来源”从模型参数记忆变成外部检索到的实时知识片段。RAG还有一个隐藏优势可追溯。用户问“试用期提前离职扣工资吗”只给一个答案对方不一定信把答案和制度出处一并给出来诸如“根据《员工手册》第三章第五条”信任度就完全不同。而可追溯性在生产项目中涉及的不仅是用户体验更是责任认定的需要——出了问题能定位是不是知识库内容本身有问题而不是模型乱说。4.2 文档清洗和切分准确率的第一个决定因素RAG的效果好坏文档清洗和切分比向量模型的选择影响更大。很多团队一上来就折腾embedding模型文档却还是原始PDF直接切块这属于舍本逐末。我把清洗流程固定成四步格式解析提取PDF文字内容扫描件必须过OCROCR结果认真核对错别字。噪声过滤去掉页眉、页脚、页码、目录水印、重复空行。结构还原识别标题层级保留原文档的章节结构信息。切块时把标题作为上下文拼进切块内容这比单纯切纯文本在召回时准确得多。表格处理表格是检索重灾区建议按行转成自然语言描述竖排变横排逻辑才能保留清楚。切块的参数方面我一般用500到800字左右的中文块重叠80到100字。这个数值不是绝对的取决于文档密度。制度条款类文档每个条款自成逻辑单元切太碎容易丢失条件状语技术类文档则可以切小一些聚焦单个概念。4.3 检索策略向量检索之外要加元数据过滤和重排企业级RAG绝对不能只靠向量检索一把梭。数据量大到一定程度语义相似不等于业务相关。比如知识库里有2023版和2025版两份制度员工问“年假几天”向量检索可能把两个版本都召回来答案就互相打架了。我的建议是至少叠加两层第一层是元数据过滤。知识文档入库时就带上部门、生效日期、文档类型等标签检索时先按条件过滤再走向量召回比如只检索生效日期小于等于当前日期的文档、exclude掉已作废版本。这一步能把海量检索空间缩小一个量级。第二层是重排。向量召回top 50再用一个交叉编码器重排序取top 5。交叉编码器把查询和候选文本拼在一起过模型打分比向量距离准确虽然速度慢但只对几十条候选重排性能开销完全可以接受。下面是多层检索的伪代码流程def search(query: str): # 第一层元数据过滤 filters { is_active: True, dept: [人事, 行政], effective_date: {$lte: today} } # 第二层向量召回 candidates vector_store.search(query, top_k50, filterfilters) # 第三层重排 reranked reranker.rerank(query, candidates) return reranked[:5]在回答质量要求高的场景重排这一层经常能让“答案相关”的比例提升20个百分点以上性价比非常高。4.4 RAG效果崩了应该如何定位问题上线之后用户反馈回答质量不行别急着调提示词。先用“分环节定位法”确认问题出在哪一环如果检索回来的片段本身就文不对题问题在数据或检索调提示词无效。如果片段相关但生成答案没用上那就是提示词里指令不够明确或者是上下文组装顺序有问题。如果答案把A文档的内容和B文档的内容错误拼接那就是多文档融合策略缺失。定位方法也很简单把一次完整请求的检索片段和最终答案同时打出来看。所以我强烈建议项目从一开始就把检索片段落日志否则出问题根本无从排查。5. 构建AI对话产品会话管理、幻觉防控与体验5.1 多轮会话状态管理要点AI对话产品和单次问答最大的区别在于“状态”。用户在第七轮说出“那帮我换成这个套餐”系统必须知道“这个”指代的是前文里哪款套餐。企业级项目的会话管理通常这样设计前端把消息发给后端后端维护一个消息历史队列每次请求时把最近N轮对话记录和当前用户消息一起组装成上下文发给模型。N的取值需要权衡轮次太少模型记不住关键信息太多则token成本高、响应慢而且模型容易“迷失在长上下文里”。我在多数业务里取6到10轮同时只保留必要字段。组装上下文的参考代码def build_conversation_context(history: list[dict], new_message: str) - list[dict]: messages [ {role: system, content: SYSTEM_PROMPT} ] # 保留最近6轮对话 recent_history history[-6:] for item in recent_history: messages.append({role: user, content: item[user]}) messages.append({role: assistant, content: item[assistant]}) messages.append({role: user, content: new_message}) return messages只有上下文管理还不够更关键的是关键词信息提取。很多业务场景要求系统在对话过程中持续收集结构化信息比如办证咨询里用户提到的城市、证件类型。这类信息的抽取最好在每轮对话里运行一个后台槽位填充流程把结果同步到会话状态的独立字段中而不是依赖模型对话上下文里的隐式记忆。槽位设计是传统对话系统和生成式对话的接缝处做得好能弥补大模型状态跟踪不稳定的短板。5.2 幻觉防控这是对话产品信誉的分水岭AI对话产品上线后被用户骂最多的问题几乎都是“幻觉”——一本正经地编造公司制度、编造产品退换货规则、编造客服处理进度。完全消除幻觉在现阶段很难但工程上能做的防控手段非常多。我的做法分三个层次第一层源头控制。系统提示词里明确写“只基于知识片段回答”这是底线。同时对模型做反事实引导“知识片段中没有提到xx回复说不知道”。第二层流程拦截。检索结果的可用性判断要前置如果检索片段和用户问题的相关性低于阈值直接让机器人回复“这个问题涉及的信息暂不在支持范围内已帮您转人工”根本不把这段内容送进生成器。这一步用简单的相似度阈值就能实现。第三层结果校验。对生成的答案做一次“事实性检查”用另一个语言模型或使用知识片段回读验证把关键数字和制度名称抽取出来和知识片段做比对不匹配就触发重写或人工接管。还需要关注的是诱导越狱问题。用户会尝试让客服机器人“骂人”“编个假需求”“忽略之前规则”所以系统提示词里要加防注入教导模型区分系统指令与对话内容把可疑输入当普通问题处理不执行其中的隐藏指令。5.3 延迟、并发与成本控制企业级对话产品上线后运维的挑战主要集中在成本与延迟。大模型API的单位token价格虽然一直在降但业务量上来之后预算依然很容易失控。我一般会在应用和模型之间加一个轻量代理层实现三件事流式输出SSE把首字延迟压下来。用户对话体验的瓶颈往往是“看到第一个字的时间”而不是整体完成时间。全量生成等待时间长用户感知差改用流式返回用户往往还没读完第一个字后面的内容已经在路上。缓存层对高频、重复的知识问答做精确命中缓存。完全一样的用户问题在客服场景里占比相当高业务知识库类问题更高。路由和分级简单问题用轻量模型回复复杂问题才调用强模型。判断问题难易同样可以靠一个快速分类模型或规则来做。这个策略能把整体成本降到原来的三分之一是我每次都会采用的手段。5.4 测评体系没有评价指标优化就是无底洞对话产品上线前后的每次改动都需要有据可依。我在每个项目里都会构建一个“评测集自动化跑测”机制评测集通常包含三部分高频问题、边界问题、异常输入。高频问题覆盖日常用户询问的主体边界问题包含多轮指代、缺主语的模糊提问、涉及时效性的政策问题异常输入有乱码、错别字、表情符号、与业务无关的闲聊等。自动跑测脚本的逻辑是每改一版提示词或检索策略就拿评测集完整跑一遍记录每一题的回答情况。判断标准分三档完全正确、部分可用需要人工修改、错误。只要新版方案比旧版多产生五个错误就立刻回滚。使用这个流程后团队再没有发生“改完提示词导致某类问题集体翻车”的情况。6. 一个完整的项目案例企业内部制度问答助手的工程化落地6.1 需求定义和技术选型用一个真实案例把前面的方法串起来。假设现在要给一家中型公司做制度问答助手覆盖员工手册、考勤制度、差旅报销、IT支持四项制度员工数约2000人。需求确认阶段的关键决策点如下决策点选择原因是否允许闲聊不允许控制成本减少内容风险多轮能力要求支持6轮内指代多数制度咨询在6轮内能闭环实时性要求接受3-5秒响应制度问答对时效要求不高是否需要转人工需要复杂问题人工介入是刚需端到端评测标准准确回答率90%业务方可接受的及格线这套决策过程的价值在于在写代码之前就把产品边界定义清楚。很多项目没有定义清楚边界最后就成了“ChatGPT套壳”什么都想答什么都答不好。6.2 Pipeline各模块的工程实现细节完整的系统分前端对话界面、服务端会话管理、检索服务、模型网关、管理后台五块。模型网关对外统一暴露接口内部负责解析系统提示词模板、组装检索片段、调用模型并对返回结果做格式校验和兜底。以FastAPI为例一个简化版的接口结构如下from fastapi import FastAPI from pydantic import BaseModel app FastAPI() class ChatRequest(BaseModel): session_id: str query: str class ChatResponse(BaseModel): reply: str references: list[str] need_human: bool app.post(/api/chat) async def chat(req: ChatRequest): history get_history(req.session_id) contexts retrieve_contexts(req.query) # RAG 检索 reply, need_human generate_answer(req.query, history, contexts) save_history(req.session_id, req.query, reply) return ChatResponse(replyreply, referencescontexts, need_humanneed_human)更关键的不在接口而是在generate_answer内部做了一道风险判断权限边界问题怎么办比如员工问薪资数据不答政策未覆盖的怎么办标注可转人工检索结果里出现已废弃文档怎么办元数据过滤已经处理。三道闸门下来安全兜底才算拉满。6.3 上线后的效果优化记录首轮上线后人工评测显示准确回答率约82%离90%的目标还有距离。通过查看评测日志我定位到三个主要错误簇差旅报销规则格式复杂有大量表格和例外条款切块后上下文残缺部分回答只能答出基础规则。员工问“请假要提前几天”这类问题不同制度文档给出的前提不同员工试用期和正式员工的规则不一样检索时没有过滤员工级别把多条矛盾规则一并送进了模型。部分用户会把口语说得很含糊比如“报销打点是啥”不带上下文直接检索必然失败。对应的优化方案表格转文本时按行拆解并标注表头和所属章节向量检索结果返回后增加“生效身份”规则校验对常见口语化问法建立同义改写映射命中后先映射成标准检索语句再做检索。优化后再跑评测集准确回答率提升到93.5%。这个案例展示的其实是所有企业级NLP项目的共同宿命没有一次全局的最优解只有一版一版压低错误率的迭代。6.4 灰度发布与线上回滚机制对企业级应用开发来说把模型当“活代码”看待是基本的工程素养。大模型的提示词微调、知识库数据更新都可能让同一个问题的答案发生非预期变化。灰度发布的核心是控制变更影响面它的具体做法是先将一部分流量切到修改后的提示词版本上同时开启“答案对比模式”让新旧版本处理同样的线上问题自动比较两者的差异。一旦发现旧版回答正确而新版反转立即触发告警自动把全部流量切回旧版。知识库更新用同样的逻辑不建议直接把整库替换掉而是一个版本一个版本增量上线。因为全量换库风险极大新库的切分策略一旦有偏差全部问题的答案都可能崩塌。最后再说一下日志和评测集建设。上线的第一天就要把数据留全——用户问题、检索片段、推荐答案、用户点击反馈全都记录下来。这些数据积累到一定量之后价值会超过任何一套人工标注。可以定期从线上日志里抽样错误case补充进评测集保证评测集越来越接近真实的用户提问分布系统的优化方向也就越来越准。我自己在带项目时还有个小习惯每一个提示词改动、每一个检索参数的调整都用一条简单的历史记录把它和评测结果绑定在一起。这样复盘时、新同事接手时不必重新踩一遍当初的坑看一眼历史就能知道什么值得调整、什么会导致效果变差。企业级AI应用开发的复杂度远远超过模型调参本身把工程纪律做扎实就相当于拿到了在大模型时代最稀缺的那一档基本功。