1. 为什么“会用AI”和“能落AI”之间隔着一道天堑这两年跟不少想转行做AI产品经理的朋友聊过发现一个特别普遍的现象简历上写着“熟练使用各类AI工具”“了解大模型基本原理”面试时也能把Transformer、RAG、Agent这些词说得头头是道但一到“你做过什么AI产品”这个问题就卡壳了。能说出来的无非是“用某个对话工具写过文案”“用某个绘图工具做过图”再往深了问——这个功能如果让你来设计你怎么定义需求怎么评估效果怎么跟算法团队对齐基本就答不上来了。这就是“会用AI”和“能落AI”之间最真实的差距。会用指的是你作为终端用户能操作某个现成的AI产品完成一个具体任务能落指的是你作为产品负责人能把一个模糊的业务问题拆解成AI能解决的技术问题定义清楚输入输出、评估标准、迭代路径并推动算法、工程、运营多方协作把它真正做出来、跑起来、用起来。这个差距不是靠多看几篇公众号文章、多刷几个Demo就能填平的。它需要一套系统性的训练——从需求发现到方案设计从数据准备到模型选型从效果评估到上线迭代每一个环节都有大量的隐性知识和踩坑经验这些东西在常规的教程里根本不会写因为写教程的人自己可能也没真正落地过几个AI产品。我见过太多人卡在“会用”这个阶段投了几十份AI产品经理的岗位面试机会寥寥偶尔拿到面试也过不了终面。问题不在于他们不够聪明而在于他们缺少一个把“用户视角”切换成“产品负责人视角”的训练过程。而这个训练过程恰恰是“就业实战营”这类项目试图解决的核心问题。这篇文章不打算给你灌鸡汤也不会罗列一堆“AI产品经理必备技能”的空话。我想做的是把“从会用AI到能落AI”这个转化过程中真正关键的几个环节拆开来讲清楚——每个环节到底在训练什么能力、为什么这个能力在面试和实际工作中如此重要、以及你可以怎么自己动手去补上这块短板。不管你是正在考虑报类似的实战营还是想自己摸索着入门这些内容都能帮你少走至少半年的弯路。2. 拆解“就业实战营”到底在训练什么能力2.1 需求翻译能力把“我想要”变成“AI能做”大部分想做AI产品经理的人第一个卡点就是需求翻译。业务方跑过来说“我想要一个智能客服”或者老板说“咱们也搞个AI助手吧”你怎么办直接去找算法团队说“做个智能客服”那大概率会被怼回来——“具体要解决什么问题知识库从哪来回答准确率要求多少多轮对话要支持几轮”实战营里通常会用一个模拟项目来训练这个能力。比如给你一个场景某在线教育平台想用AI辅助老师批改作文。这个需求听起来很明确但真正拆解起来你会发现有无数个需要定义的细节。批改什么类型的作文议论文还是记叙文批改的维度是什么语法、逻辑、文采还是结构每个维度的权重怎么分配输出形式是什么打分、评语还是修改建议准确率要求多高老师能不能接受AI批改的结果直接给学生看这一连串问题就是需求翻译的过程。你需要把“AI辅助批改作文”这个模糊的诉求翻译成“输入一篇800字议论文输出语法错误标注、逻辑连贯性评分、结构完整性评分、三条改进建议语法错误召回率不低于95%评分与人工评分偏差不超过10%”这样的技术需求。这个翻译过程做得好不好直接决定了后面所有环节的效率和最终产品的质量。我自己的经验是需求翻译最核心的能力是“边界定义”。AI不是万能的你得清楚哪些事AI能做、哪些事AI做不好、哪些事AI做起来成本极高但收益很低。比如让AI判断一篇作文“有没有思想深度”这个需求就非常难落地因为“思想深度”本身就没有客观标准标注数据都很难做。但让AI找出“论据是否支撑论点”就相对可操作因为你可以定义什么叫“支撑”——论据是否与论点直接相关、是否提供了具体事实或数据、是否回应了可能的反驳。实战营里训练这个能力的方式通常是让你反复做“需求拆解练习”给一个业务场景你先自己拆然后跟导师和同学对比看看别人拆出了哪些你没想到的维度哪些维度你拆得太细导致无法落地哪些维度你完全忽略了但其实是关键。这种反复对比和修正的过程比看一百篇需求分析的文章都管用。2.2 数据思维AI产品的燃料不是代码是数据很多从传统产品经理转过来的人最大的思维盲区就是数据。传统产品经理也讲数据但讲的是DAU、留存率、转化率这些业务指标。AI产品经理讲数据讲的是训练数据、验证数据、测试数据的划分是标注规范、标注质量、数据分布是数据增强、数据清洗、数据平衡。我见过一个真实的案例某团队做了一个AI简历筛选工具Demo阶段效果很好准确率能到90%以上。但上线之后HR反馈“根本没法用”。排查下来发现Demo阶段用的测试数据都是互联网行业的简历格式规范、用词标准。但实际业务中大量简历来自传统行业格式五花八门有PDF扫描件、有图片、有手写体甚至还有用表格做的简历。模型在这些数据上的表现一塌糊涂。这就是典型的数据思维缺失。做AI产品你不能只看模型在标准测试集上的指标你得关心你的产品实际会面对什么样的数据。这些数据的分布是什么样的有没有长尾情况标注成本有多高标注一致性怎么保证实战营里训练数据思维的方式通常是让你亲手做一个完整的数据闭环。比如做一个文本分类的模拟项目你需要自己定义分类体系、自己写标注规范、自己标一批数据、自己检查标注一致性、自己划分训练集和测试集、自己分析模型在哪些类别上表现差、自己决定是补充数据还是调整分类体系。这一套走下来你对“数据决定AI产品上限”这句话会有完全不同的理解。有个细节特别值得说标注规范的设计。很多人觉得标注就是“告诉标注员怎么打标签”但实际操作中你会发现同一个样本不同标注员的理解可能完全不同。比如“这条用户评论是否属于投诉”有的标注员认为“抱怨就是投诉”有的认为“只有明确要求赔偿才算投诉”。如果你不在标注规范里把边界情况写清楚标出来的数据就是一团浆糊模型学出来的东西也是四不像。2.3 评估体系设计没有度量就没有迭代AI产品和传统软件产品最大的区别之一就是“对不对”这件事变得模糊了。传统软件功能对不对很容易判断——点击按钮能不能跳转、输入数据能不能保存。但AI产品模型输出的结果往往没有绝对的对错只有“好一点”和“差一点”。这就需要一个评估体系来量化“好”的程度。评估体系设计是AI产品经理最核心的能力之一也是最难训练的能力之一。因为它需要你同时理解业务目标和技术指标并且能在两者之间建立映射关系。比如一个AI写作辅助工具业务目标是“提升用户的写作效率”技术指标可能是“生成文本的BLEU分数”或者“人工评分”。但BLEU分数高就一定意味着用户效率提升了吗不一定。用户可能更在意生成的内容是否符合自己的语气风格而不是跟参考文本有多相似。实战营里训练这个能力通常会让你为一个模拟产品设计完整的评估方案。你需要定义离线评估用什么指标、在线评估用什么指标、人工评估的维度和评分标准是什么、A/B测试怎么设计、灰度发布的策略是什么。每一个选择背后都有大量的权衡。举个例子离线评估和在线评估的指标往往是不一致的。离线评估你可以算准确率、召回率、F1值但上线之后你关心的是点击率、采纳率、用户满意度。这两者之间可能有很大的鸿沟。一个模型离线F1值很高但上线后用户就是不买账因为用户的行为受到太多离线指标无法捕捉的因素影响——界面设计、响应速度、信任感建立等等。我自己的经验是评估体系设计最忌讳的就是“唯指标论”。指标是工具不是目的。你得时刻问自己这个指标真的能反映用户体验吗有没有可能模型在这个指标上表现很好但用户实际感受很差比如一个AI摘要工具ROUGE分数很高但生成的摘要读起来很生硬、不连贯用户宁愿自己看原文。这种情况下你就需要引入人工评估来补充自动指标的不足。2.4 跨职能协作算法、工程、运营之间的翻译官AI产品经理在日常工作中大量时间花在跟不同角色沟通上。跟算法工程师沟通你需要懂一些技术语言知道什么需求技术上可行、什么不可行、大概需要多少数据、训练周期多长。跟工程团队沟通你需要理解系统架构、接口设计、性能约束。跟运营团队沟通你需要把技术指标翻译成业务语言让他们理解为什么这个版本的效果提升了、那个版本的效果下降了。这个“翻译官”的角色是AI产品经理区别于传统产品经理的重要特征。传统产品经理更多是跟设计、开发、运营协作技术门槛相对低。AI产品经理面对的技术不确定性更高算法团队的工作方式也跟工程团队很不一样——算法迭代是实验驱动的需要反复试错周期很难精确预估。如果你不理解这一点就会在排期和预期管理上出大问题。实战营里训练跨职能协作能力通常是通过模拟项目中的角色扮演来实现的。你作为产品经理需要跟扮演算法工程师的导师对齐技术方案跟扮演工程负责人的导师讨论系统设计跟扮演运营的导师制定上线策略。每一次沟通都是一次实战演练导师会故意提出各种刁钻的问题来考验你的应变能力。有个特别实用的技巧跟算法团队沟通时不要问“这个能不能做”而要问“如果要做需要什么条件”。前者很容易得到“做不了”的回复后者则能引导对方跟你一起思考解决方案。比如你想做一个“AI自动生成周报”的功能直接问“能不能做”算法工程师可能说“生成质量没法保证”。但如果你问“如果要做需要什么样的数据、什么样的评估标准、什么样的兜底方案”对话就会进入一个建设性的方向。3. 模拟项目实战一个AI功能从0到1的完整推演3.1 项目选题为什么“AI会议纪要”是个好练手项目在实战营里选题很重要。太简单的项目练不到核心能力太复杂的项目又容易让人迷失在细节里。我观察下来“AI会议纪要”这类项目特别适合作为入门级的实战训练因为它同时覆盖了语音识别、文本摘要、信息抽取、结构化输出等多个技术模块但又不会复杂到让人无从下手。具体来说一个完整的AI会议纪要产品需要解决这些问题音频怎么采集和预处理多人对话怎么区分说话人语音转文字之后怎么做文本清洗怎么从大段对话中提取关键决议和待办事项怎么处理口语化的表达和重复内容输出格式怎么设计才能让用户快速抓取重点每一个问题背后都是一连串的产品决策。比如说话人区分你可以选择用声纹识别来自动区分也可以让用户手动标注。自动区分体验好但准确率可能不稳定手动标注准确率高但用户操作成本高。你怎么选这取决于你的目标用户和使用场景——如果是内部小团队日常会议大家彼此熟悉手动标注可能可以接受如果是大型企业的跨部门会议参会人经常变化自动区分就更有必要。选题确定之后你需要写一份完整的产品需求文档。这份文档不是走形式而是你后续所有工作的基础。需求文档里要写清楚产品目标是什么、目标用户是谁、核心使用场景是什么、功能范围包括哪些不包括哪些、关键指标怎么定义、技术约束有哪些、风险点在哪里。写完之后导师和同学会从不同角度挑战你的假设这个过程非常痛苦但非常有效。3.2 技术方案选型为什么“够用就好”比“追求先进”更重要技术方案选型是AI产品经理最容易犯错的环节之一。很多新手产品经理会陷入“技术崇拜”觉得一定要用最先进的模型、最新的架构。但实际工作中技术选型的核心原则是“够用就好”而不是“越先进越好”。还是以AI会议纪要为例。语音转文字环节你可以选择开源的Whisper模型也可以选择商业化的语音识别API。开源模型的好处是数据不出本地、可以自己微调、长期成本低坏处是需要自己部署和维护、对工程能力要求高。商业API的好处是开箱即用、准确率有保障、维护成本低坏处是按量付费、数据要传到第三方、定制化空间小。你怎么选这取决于你的业务场景。如果是对数据隐私要求极高的场景比如涉及商业机密的内部会议那开源模型可能是唯一选择。如果是面向中小企业的通用工具商业API可能更合适因为你的团队可以把精力集中在产品体验上而不是底层模型的调优上。文本摘要环节也是类似。你可以选择抽取式摘要从原文中挑出最重要的句子组合成摘要也可以选择生成式摘要让模型用自己的话重新组织内容。抽取式摘要的好处是不会产生事实错误因为每句话都来自原文坏处是可能不够连贯、不够简洁。生成式摘要的好处是更自然、更精炼坏处是有可能产生幻觉编造原文中没有的信息。我自己的经验是在会议纪要这个场景下混合方案往往效果最好先用抽取式方法找出关键句子再用生成式方法对这些句子进行润色和重组。这样既保证了事实准确性又提升了可读性。当然这个方案也不是万能的具体怎么选还是要看你的产品定位和用户需求。3.3 评估方案设计怎么判断“这个纪要能不能用”会议纪要产品的评估比一般的文本摘要更复杂因为“好纪要”的标准很难量化。一段会议录音不同的人整理出来的纪要可能完全不同但都可能是“好”的。这就给评估体系设计带来了很大挑战。实战营里通常会让你从三个维度来设计评估方案内容完整性、信息准确性和可读性。内容完整性看的是关键信息有没有遗漏——决议、待办、负责人、截止时间这些要素是不是都提取出来了。信息准确性看的是提取出来的信息有没有错误——负责人是不是搞错了、截止时间是不是听错了、决议内容是不是理解偏了。可读性看的是纪要读起来顺不顺——逻辑是不是清晰、语言是不是简洁、格式是不是易读。每个维度都需要设计具体的评估方法。内容完整性可以用“关键信息召回率”来衡量但前提是你得先定义什么是“关键信息”。这个定义本身就是一个产品决策——你认为会议纪要里必须包含哪些要素这些要素的优先级怎么排信息准确性可以用人工抽检的方式随机抽取一批生成的纪要让标注员逐条核对。可读性则更适合用人工评分让评估者按1到5分打分。这里有个坑特别值得说评估者的一致性。不同的人对“可读性”的理解可能差异很大有的人觉得简洁就是好有的人觉得详细才是好。如果你不做评估者培训、不写详细的评分标准评估结果的可信度就很低。实战营里通常会让你先自己评一批数据然后跟导师的评分对比看看差异在哪里、为什么会有差异、怎么调整评分标准来减少主观性。3.4 上线策略灰度发布、用户反馈与快速迭代产品做出来只是第一步怎么上线、怎么收集反馈、怎么迭代才是决定产品能不能真正“落”下来的关键。AI产品的上线策略跟传统软件有很大不同因为AI模型的效果不是固定的它会随着数据分布的变化而漂移也会随着用户使用方式的变化而表现出不同的行为。灰度发布是AI产品上线的标准做法。先让一小部分用户使用观察核心指标的变化收集用户反馈发现问题及时修复。灰度发布的关键是“灰度粒度”的设计——是按用户随机分组还是按部门分组还是按使用场景分组不同的分组方式会影响到你能否准确归因问题。比如你发现灰度组的用户满意度比对照组低了5个百分点这个下降是因为模型效果不好还是因为界面设计有问题还是因为用户不习惯新的交互方式如果你是按用户随机分组的那你可以比较两组用户在相同场景下的行为差异。但如果你是按部门分组的那部门之间的差异可能会干扰你的判断。用户反馈的收集和分析也是AI产品经理的核心工作。AI产品的用户反馈往往比传统软件更模糊——“这个纪要总结得不好”这句话背后可能有无数种原因可能是漏掉了关键信息可能是提取了错误的信息可能是语言太生硬可能是格式不符合习惯。你需要通过追问、观察、数据分析来定位真正的问题。我自己的经验是AI产品上线初期一定要建立“快速迭代”的节奏。因为模型的问题往往需要多轮调整才能解决如果你按照传统软件的发布周期来走一个月才发一个版本那用户早就流失了。实战营里通常会模拟一个两周的迭代周期第一周收集反馈、分析问题、制定方案第二周开发、测试、发布。这个节奏虽然紧张但能让你真实体验到AI产品迭代的挑战和乐趣。4. 面试通关AI产品经理岗位到底在考察什么4.1 简历怎么写才能通过初筛AI产品经理的简历跟传统产品经理的简历有本质区别。传统产品经理的简历强调“我做了什么功能、带来了什么业务增长”AI产品经理的简历需要强调“我解决了什么AI落地问题、怎么定义和评估AI效果”。很多人的简历写的是“负责XX产品的AI功能设计”这种写法太笼统了面试官根本看不出你的实际能力。更好的写法是具体到某个AI功能写清楚你在这个功能中做了什么决策、解决了什么问题、取得了什么效果。比如“设计并落地了智能客服的意图识别模块定义了12类意图的分类体系和标注规范通过引入主动学习策略将标注成本降低了40%意图识别准确率从78%提升到91%”。关键词也很重要。AI产品经理的简历里应该自然出现这些词需求拆解、数据标注、评估指标、A/B测试、模型选型、Prompt工程、RAG、Agent、幻觉处理、兜底策略。但注意不要堆砌每个词都要有具体的项目经历来支撑。还有一个容易被忽略的点简历里要体现你对AI技术边界的理解。比如你可以在项目描述里写“在方案设计阶段排除了端到端生成方案因为该场景对事实准确性要求极高生成式方案存在幻觉风险最终选择了检索增强的混合方案”。这种表述能直接告诉面试官你不是盲目追新的人你知道什么场景该用什么技术。4.2 面试中的高频问题与回答框架AI产品经理的面试通常会围绕三个维度展开产品能力、技术理解、项目经验。每个维度都有一些高频问题我挑几个最有代表性的来说。“你怎么判断一个需求适不适合用AI解决”这个问题考察的是你的需求判断力。回答框架可以是先看这个需求的核心痛点是什么是不是需要处理非结构化数据、是不是需要从大量数据中找规律、是不是需要个性化响应。如果是那AI可能适合。然后看数据条件——有没有足够的标注数据、数据质量怎么样、标注成本能不能承受。最后看容错空间——AI的输出允许出错吗如果出错后果很严重那可能需要人工兜底或者换方案。“你怎么评估一个AI功能的效果”这个问题考察的是你的评估体系设计能力。回答框架可以是先定义业务目标再把业务目标拆解成可量化的技术指标然后设计离线评估和在线评估的方案最后说明怎么通过A/B测试验证效果。注意要提到人工评估和自动评估的结合以及评估指标可能存在的偏差。“如果模型效果不好你怎么排查问题”这个问题考察的是你的问题定位能力。回答框架可以是先看是数据问题还是模型问题还是产品设计问题。数据问题包括标注质量差、数据分布不均衡、训练数据与线上数据不一致。模型问题包括过拟合、欠拟合、模型容量不够。产品设计问题包括用户输入不符合预期、交互流程有歧义、兜底策略不完善。排查的时候要逐层排除先看数据再看模型最后看产品。“你怎么跟算法团队协作”这个问题考察的是你的跨职能沟通能力。回答框架可以是先对齐目标确保双方对“什么是好”有共识。然后对齐节奏理解算法迭代的实验驱动特性不要用工程排期的思维来要求算法。最后对齐语言学会用算法团队能理解的方式描述需求比如用“输入输出定义”“评估指标”“约束条件”来代替“我想要一个智能XX”。4.3 作品集没有实际项目经验怎么办很多转行的人最大的痛点就是“没有实际项目经验”。面试官问“你做过什么AI产品”你总不能说“我用过很多AI工具”吧。这时候一个高质量的作品集就非常重要了。作品集不需要是上线产品但需要展示你的完整思考过程。你可以选一个自己感兴趣的场景做一个完整的AI产品方案设计。包括需求分析、竞品调研、技术方案选型、数据方案设计、评估体系设计、上线策略、风险分析。每一个环节都要写清楚你的决策逻辑和权衡过程。比如你对“AI辅助健身”这个场景感兴趣你可以设计一个“基于计算机视觉的居家健身动作纠正”产品。需求分析部分你可以写清楚目标用户是谁、他们在健身时遇到的核心问题是什么、现有解决方案有什么不足。技术方案部分你可以对比姿态估计的不同技术路线分析各自的优缺点和适用场景。数据方案部分你可以设计数据采集方案、标注规范、隐私保护措施。评估体系部分你可以定义动作识别准确率、纠正建议采纳率、用户留存率等指标。这个作品集不需要很完美但需要让面试官看到你的思考深度和落地意识。我见过一个候选人他的作品集是一个“AI辅助菜谱生成”的方案从需求分析到技术选型到评估体系写了整整30页。面试的时候面试官就围绕这个作品集问了40分钟最后顺利拿到了offer。原因很简单这个作品集证明了他具备AI产品经理的核心能力哪怕他没有实际的工作经验。4.4 谈薪与选offerAI产品经理的市场行情与决策逻辑AI产品经理的薪资水平跟传统产品经理相比有明显溢价但溢价幅度取决于你的能力层次和行业选择。根据我观察到的市场情况初级AI产品经理的薪资大概比同级别传统产品经理高20%到30%高级AI产品经理的溢价可能达到50%甚至更高。但这个溢价不是白给的它对应的是更高的能力要求和更大的不确定性。选offer的时候不要只看薪资。你需要考虑几个关键因素团队的技术实力、业务的AI成熟度、岗位的实际职责、成长空间。一个技术实力强的团队能让你快速成长一个AI成熟度高的业务能让你接触到真实的落地场景一个职责清晰的岗位能让你积累可迁移的经验。特别要警惕的是“伪AI产品经理”岗位。有些公司挂着AI产品经理的title实际工作却是做数据标注管理或者给算法团队打杂。面试的时候一定要问清楚这个岗位具体负责什么有没有机会参与技术方案讨论有没有机会定义评估体系团队里算法、工程、产品的配比是怎样的如果面试官支支吾吾说不清楚那大概率这个岗位的含金量不高。我自己的经验是选AI产品经理的岗位优先选“业务场景明确、数据条件好、团队技术强”的组合。业务场景明确意味着你能快速看到自己的产品决策带来的效果变化数据条件好意味着模型效果有保障你不会把大量时间花在跟脏数据作斗争上团队技术强意味着你能从同事身上学到很多东西成长速度会快很多。5. 从实战营到真实战场那些没人告诉你的落地真相5.1 模型不是越强越好场景匹配才是关键在实战营里你可能会接触到各种前沿的模型和技术很容易产生一种“要用最先进技术”的冲动。但真实工作中我见过太多因为“技术过度”而导致项目失败的案例。有一个模拟项目让我印象很深团队想做一个“AI自动生成商品标题”的功能用于电商平台的商家后台。一开始算法团队提议用最新的大语言模型来做端到端生成效果确实好生成的标题通顺、有吸引力。但上线之后发现商家根本不买账。为什么因为大模型生成的标题虽然好看但经常偏离商品的实际卖点而且每次生成的结果都不一样商家觉得“不可控”。后来改成了“模板关键词填充”的方案用规则引擎来保证标题结构的稳定性用模型来推荐关键词。效果反而更好因为商家可以清楚地知道标题是怎么生成的也可以手动调整关键词。这个案例让我深刻理解了一个道理AI产品的核心不是“用AI”而是“解决问题”。技术方案的选择永远要服务于场景需求而不是反过来。5.2 数据标注的隐性成本远超你的想象没做过AI产品的人往往会把数据标注想得很简单——“找几个人打标签不就行了”。但实际操作中数据标注的成本和复杂度远超想象。首先是标注规范的设计成本。你需要把标注规则写得足够细细到标注员遇到任何边界情况都能找到对应的处理方式。这个规范往往需要反复迭代因为你在标注过程中会不断发现新的边界情况。我见过一个项目标注规范改了七版才稳定下来前前后后花了三周时间。其次是标注质量的管控成本。你不能假设标注员会严格按照规范来标你需要设计抽检机制、一致性检验、争议仲裁流程。如果标注质量不达标你还需要重新培训、重新标注这些成本都要提前考虑进去。最后是标注数据的维护成本。数据不是标完就完了随着业务变化分类体系可能需要调整标注规范可能需要更新旧数据可能需要重新标注。这些持续性的投入往往在项目初期被严重低估。5.3 上线只是开始持续运营才是真正的挑战很多AI产品经理把“上线”当成终点觉得产品发布了就万事大吉了。但真实情况是上线只是起点后面的持续运营才是真正的挑战。AI产品上线后你会面临一系列新问题模型效果会不会随着时间推移而下降用户的使用方式会不会偏离你的预期新的数据分布会不会导致模型表现变差竞品推出了新功能你要不要跟进这些问题都需要你持续关注、持续迭代。我自己的经验是AI产品上线后的前三个月是最关键的时期。这段时间你需要密切监控核心指标建立数据看板和报警机制定期收集用户反馈快速响应问题。如果前三个月能把产品打磨到稳定状态后面的运营压力会小很多。如果前三个月放任不管等用户流失了再想挽回成本会高得多。5.4 给正在路上的你三个最实在的建议第一个建议不要等准备好了再开始。AI产品经理这个岗位没有人是“完全准备好”才上的。你会在工作中遇到无数没学过的东西但这没关系边做边学才是常态。重要的是你有拆解问题的框架和快速学习的能力。第二个建议保持对技术的敏感度但不要陷入技术细节。你不需要自己会训练模型但你需要知道模型的能力边界在哪里、什么场景适合什么技术、大概的成本和周期是多少。这些判断力比技术细节重要得多。第三个建议多跟一线的人聊。跟算法工程师聊跟标注员聊跟用户聊。很多真实的问题和需求不在文档里不在数据里而在人的嘴里。你聊得越多对业务的理解就越深做出来的产品就越接地气。这个领域变化很快今天的热点明天可能就过时了。但有些东西是不变的对用户需求的理解、对技术边界的判断、对落地路径的规划。把这些基本功练扎实了不管技术怎么变你都能找到自己的位置。
