如果只看新闻标题AI市场给人的感觉已经热得发烫好像所有项目都在接大模型所有公司都在谈AI转型。但“AI市场被低估了”这句话仍然值得认真对待尤其是当你自己动手做AI应用、接过大模型API、在企业里推过一个AI功能之后你会发现一个很明显的事实真正被过度讨论的是概念真正被明显低估的是落地深度。这里的“市场”不一定指股票估值更值得拆的是“AI应用渗透率”和“AI对实际工作流的改造程度”。很多行业还在用最原始的方式做文档、写代码、处理数据、回客服消息AI在这些场景里的覆盖率远没有新闻里那么高。所以这个标题放到开发者、产品经理和创业者面前会有更现实的解释AI市场被低估指的是“能真正创造生产力的部分”还远没有跑满。这篇不聊短期价格也不聊该买什么。我从工程实践和产品落地角度拆一下为什么AI市场存在被低估的一面同时也要说清楚哪些地方其实还在高估泡沫。1. 先拆清楚被低估的到底是AI市场还是AI落地1.1 市场叙事往往高估短期低估长期互联网刚出现的时候也经历过类似阶段。短期叙事会让所有人觉得新技术马上要改变一切等到预期回落又有人觉得它没什么用。现在AI正好处在这个“预期剧烈波动”的周期里。如果站在技术采用曲线上看生成式AI对软件工作流的改变程度可能还处在很早期的位置。大多数开发者已经用过代码补全但未必把它接进完整的开发流程大多数公司已经试过ChatGPT但未必把AI沉淀成内部工具很多业务部门做了Demo但没进入生产环境。这就是一个典型的“长期价值被低估”的状态。我一般会用一个很土的标准来判断看一个功能是否被低估不是看发布会多热闹而是看使用频率和付费意愿。如果用户天天在编辑器里用AI补全说明AI编程确实有价值如果用户只在截图测试时用一次那无论宣传多好落地都还是零。1.2 新闻里的AI市场和工程师面对的AI市场不是同一个新闻里的AI市场到处都是融资、榜单、参数、Demo。工程师面对的AI市场则是模型返回不稳定、接口限流、输出偶尔乱码、上下文太长、权限没有收敛、日志没有结构化以及“领导觉得AI能自动干完所有事”的预期错位。这两个市场差异非常大。一个AI应用如果只是“效果惊艳”但没有可靠的调用链路没有失败重试没有输出校验没有可观测性那它很难从测试环境走进生产环境。反过来一旦把这些工程问题解决好哪怕模型能力没有提升应用价值也会明显上涨。也就是说AI市场被低估的部分有很大一块不在模型层而在工程层和产品层。所以后续内容会集中在哪些信号说明AI应用还没跑满、哪些方向值得做、哪些方向是高估陷阱以及如何用一个最小闭环验证“被低估”的判断。2. 哪些信号说明AI应用层还没真正跑满2.1 AI编程工具的渗透率热闹背后仍有大量传统工作流AI编程是最近最容易被观察到的场景。Cursor、Copilot这些工具已经证明了代码补全和代码生成的价值但实际渗透率远没有到饱和。我在实际项目里观察到的情况是愿意用AI写代码的团队通常已经具备比较好的代码规范、代码评审和测试习惯而那些代码结构混乱、没有单元测试、没有CI/CD的传统项目反而很难用好AI编程因为模型生成的代码质量再高也架不住项目本身的耦合和烂代码积累。这个现象说明一个问题AI的价值不是单独存在的它依赖周边工程环境和协作流程。当前大量传统团队还停留在“用AI辅助查资料、写正则、解释报错”的阶段还没有把AI编程纳入日常开发闭环。对AI市场来说这就是明显没有跑满的部分。如果你还没开始用AI编程我建议先不要追求“AI自动生成整个项目”而是从单文件、单函数开始。先让它写测试、写注释、重构小段代码让团队形成“AI生成结果 - 人审查 - 进入版本控制”的习惯。这个习惯一旦建立开发效率的提升会比较稳定。2.2 企业生产环境更看重可靠性而不是Demo效果另一个被低估的信号是大部分企业应用还在等“可靠版本”而不是“更强模型”。大模型能力只要达到及格线企业就更在意输出是否稳定、是否可解释、是否能把失败控制在业务可接受范围内。举个例子一个客服自动回复系统如果模型100次里有3次输出不合适的情绪、给错优惠信息业务部门就不敢上线。而如果加上严格的意图分类、敏感词过滤、人工兜底就算模型本身能力一般系统也能跑得很稳。这种“工程兜底”能力才是企业真正缺的东西。热词里频繁出现“AI Agent开发”“AI应用开发”“AI模型部署”其实也是在找同一条路从“模型能对话”到“模型能干活”。能干活不是靠一句提示词而是靠完整的任务解析、工具调用、结果校验、异常恢复机制。目前这些基础设施还不成熟所以应用层的渗透率不高但需求是实打实存在的。2.3 热词背后藏着真实需求只是还没形成标准方案“AI编程”“AI Agent”“本地部署AI”“AI应用开发”“AI产品经理”这些词被频繁搜索说明已经不是好奇心驱动而是实务需求驱动。很多人已经在尝试怎么把AI放进自己手里的事。问题是这些方向还没有出现类似“数据库SQL”一样稳定的标准方案。大多数团队的做法是先接API再调prompt然后发现效果不稳定再加后处理再做评估集。这个过程非常依赖人的经验没有现成的最好实践。也正因为没有标准方案早期投入的人才和能力才容易被低估。一旦有人能把这套工程框架沉淀下来价值会非常大。3. 被低估不等于什么都值得做先排除三类高估3.1 第一类没有数据闭环的通用大模型大模型本身拥有极高价值但通用基座模型的门槛越来越高不是普通团队能碰的领域。对创业团队或企业内部项目来说如果只做一个通用模型没有数据闭环没有特定场景的持续优化那它很容易被大厂发布的下一代模型覆盖。判断是否值得做可以看三个问题是否能拿到别人拿不到的领域数据是否能基于这些数据形成持续改进的飞轮用户是否因为你的模型和数据私有化而留下来。如果答案都是否那这个项目的护城河很弱。市场上有一批模型和套壳应用估值很高但实际留存和付费很弱这就是典型的高估部分。3.2 第二类只换交互不解决流程问题的套壳应用很多人以为接个大模型API把聊天框换成行业界面就是AI产品。这个想法在早期可以验证需求但很难形成长期价值。真正的价值来自流程改造。比如同样做“AI写周报”一个产品只是让用户把零散信息丢给大模型生成周报另一个产品会先收集一周的代码提交、会议纪要、工单记录再自动生成周报草稿并让人确认。前者是套壳后者是工作流。后者明显更不容易被替代因为它融入了数据获取和流程闭环。我在评估AI项目时很关注一个指标用户是否因为AI而改变了原来的工作路径。如果只是从“自己写周报”变成“复制粘贴到聊天框里生成周报”那还是浅层使用。真正的改变是“系统自动收集信息 - 生成初稿 - 用户修改确认”这种改变才值得长期投入。3.3 第三类把AI当卖点而不是体验的MVP很多MVP犯的错误是先决定“我要做一个AI应用”再反过去找场景。这个顺序反了。正确的顺序应该是找到一个具体、频繁、有付费价值的问题再用AI去优化它。如果你做出来的产品把“AI驱动”几个字去掉之后用户依然愿意用那才是真正有价值的产品。如果AI只存在于宣传语里用户用完一次就不再用那这个项目其实是在制造短期噪音。这类项目被高估的典型表现是下载量、注册量高但次周留存很低Demo效果好但真实用户在复杂场景下得不到稳定结果。判断一个AI项目是否被高估不要看它融了多少钱要看它每周被稳定打开多少次、解决了多少个具体任务。4. 如果你也想判断AI市场是否被低估先跑一个最小闭环4.1 选一个每天重复、结果可验收的任务判断AI有没有价值不用先看市场报告。最好的方法是找一件自己每天都要做、结果可以明确验收的重复任务然后尝试用AI把它跑通。常见的候选任务包括每周整理工作日志并生成周报把客户邮件分类并生成回复草稿把技术会议录音转写成要点阅读一篇长文档并提取结构化字段给代码生成单元测试和注释。选择标准有三个频率高至少每周一次结果可验收生成完你能判断对不对输入输出明确不需要太强的主观创作。我一般会建议从“耗时15分钟以内的小任务”开始不要一开始就做复杂Agent。原因是范围越小越容易观察AI的实际表现也越容易定位问题。小任务跑通了再扩大到长链条任务。4.2 搭工作流的六个环节输入、模型、提示词、校验、输出、日志一个能进生产的AI功能至少要有六个环节而不只是“调接口返回结果”。这六个环节是输入处理清理格式、截断长度、处理编码模型选择根据任务复杂度选择合适模型而不是永远用最强模型提示词设计写清楚角色、输入格式、输出格式和边界结果校验用规则或二次模型检查输出是否合法输出生成按目标格式保存、展示或写入下游系统日志记录记录请求参数、模型响应、耗时、异常和人工修正结果。很多项目失败不是模型不行而是这六个环节缺了三四个。比如输入没有清干净输出格式不稳定没有日志出问题后只能靠人重新跑一遍。下面是一个很简化的示例用来说明“工作流”长什么样而不是一个可以直接上线的完整系统# 示例最小AI处理工作流 def process_task(input_text): # 1. 输入处理 cleaned clean_text(input_text) if len(cleaned) 0: return input is empty # 2. 调用模型 response llm_call(cleaned, modeldefault) # 3. 结果校验 if not validate_format(response): response retry(cleaned) # 4. 输出 save_result(response) # 5. 日志 log_request(input_text, response, statusok) return response这个示例不复杂但它把关键环节都放进去了。对于刚开始做AI应用的人来说照着这个骨架写比直接堆功能更容易稳定。4.3 用三条数据验证时间、稳定性和使用意愿跑完最小闭环之后不要只看“好像效果不错”要看数据。我会重点看三条时间处理同一批任务原来需要多久现在需要多久稳定性连续跑20次成功率和输出合格率有多少使用意愿连续用一周后你是否愿意继续用是否有同事主动问你要。如果只是第一次用觉得惊艳第三次就不想用了那说明流程设计有问题或者任务根本不适合AI。如果连续跑下来时间节省明显、合格率高、并且你开始依赖它那就说明这个场景确实有真实价值。这里容易遇到的一个坑是单条任务很惊艳批量任务立刻乱套。原因通常是输出格式没有严格约束或者输入文件命名、编码、长度不一致。所以我的经验是单条跑通之后一定要马上测试5条以上批量输入观察失败率和输出命名。5. 从工程实践看被低估的关键参数5.1 不是模型越强越好而是成本、延迟、成功率要匹配很多团队总想用能力最强的模型但实际上不同任务对模型要求完全不同。一条“提取日期和金额”的任务用小型模型加规则校验就能解决一篇需要深度专业判断的分析报告才用得上更强大的推理模型。从成本角度看大型模型调用价格更高延迟也更长。如果业务日调用量很大模型选型不合理成本会指数级上升。市场现在还有大量任务在使用重型模型做简单事这本身就是工程化不足的表现。从另一个角度看这也说明应用层还有巨大的优化空间属于“被低估的工程红利”。我在做AI改造时会先把任务分成几档任务类型模型选择关注指标简单分类、提取字段小型模型 规则校验成本、准确率中等文本生成、改写标准模型 提示词模板格式稳定率、耗时复杂推理、长文档分析强推理模型 缓存答案质量、上下文长度Agent多步任务强模型 工具调用框架任务完成率、失败重试不要一上来就预设“必须用最强模型”。先跑模型对比用一份固定的评估集测10到20条记录成功率和时间。评估集要包含正常输入和异常输入否则你看到的只是Demo效果。5.2 Agent化不是一句话的事可靠性工程才是突破口“AI Agent”是最近最容易被高估又最容易被低估的概念。被高估的地方在于很多人觉得它像个人类员工给它一句话它就能自己干活被低估的地方在于一旦把任务拆细、加好工具调用和校验逻辑它能干的事比Demo里多得多。真正靠谱的Agent实践依赖几个工程基础任务拆解把复杂任务拆成可独立验证的子任务工具接口每个工具都有清晰的入参、出参、错误码校验机制每个子任务完成后都要校验结果不能直接进入下一步失败恢复遇到工具调用失败能自动重试或降级可观测性记录每一步的输入、输出、耗时和成本。这些东西没有一样是模型自己解决的。模型负责判断工程负责兜底。目前大多数企业的Agent项目还卡在“工程兜底”这一步而这恰恰是下一阶段最值得投入的地方。一个能稳定完成80%任务并自动转人工的Agent比一个能在演示中100%完成任务但线上经常出错的Agent更有市场价值。5.3 本地部署与模型私有化的真实价值热词里出现了“本地部署AI”和“AI模型部署”这个方向也值得拆开看。本地部署不是指必须部署几十B的大模型它可以是从几十亿参数到几百亿参数的不同选择。对很多企业来说数据不能出域、不能走外部API是硬性要求。这种情况下本地部署就是刚需而不是炫技。但本地部署的难点不只是把模型跑起来。真正难的是后续的维护、微调、评估和监控。很多团队部署完模型发现推理速度太慢或者并发一上来就显存溢出或者量化后效果下降明显最后还是转向了混合方案敏感数据本地跑非敏感任务调云端API。如果你计划做本地部署建议先确认几个条件业务到底有多少并发需要多少显存和内存是否必须私有化还是外网API加脱敏方案就能满足团队有没有人力维护模型版本和推理服务数据量是否值得做微调还是靠提示词和检索就够了。这几点确认完再决定要不要自己部署。不是所有场景都适合本地部署但满足合规和数据私有化要求的场景确实有着很强的真实需求。这些需求没有被资本市场充分定价属于典型的“被低估”。6. 未来更可能被低估的岗位和能力6.1 AI产品经理从写提示词到拆流程AI产品经理这次被搜索得很多但很多人的理解还停留在“会写提示词”上。提示词只是最表层的东西。真正有价值的AI产品经理要做的是把一个业务问题拆成输入、判断、工具、校验、输出、人工介入六个部分并且知道哪些环节用模型、哪些环节用规则、哪些环节必须人做。比如设计一个“合同审核助手”普通产品经理说“用AI帮我审合同”。合格的AI产品经理会先问合同有哪些类型哪些条款是红线是否要提取金额、期限、违约责任审核结果是否要生成结构化报告如果AI拒绝回答怎么办准确率要求是多少这些才是产品价值的核心。这类人才目前严重不足。原因也很简单需要同时懂业务、懂大模型能力边界、懂工程约束、懂用户信任问题。复合型能力很难短期复制所以相关岗位和能力都会被市场低估一段时间。6.2 AI应用开发者和Agent开发者沉淀中间层能力现在大家普遍认为AI应用开发门槛低因为调用API很简单。但调用API和做出稳定产品之间还隔着数据清洗、提示词版本管理、评估集建设、缓存策略、批量任务调度、失败重试、日志分析、权限控制。这些“中间层能力”是AI应用真正能跑起来的关键。一个只会在Notebook里调模型的开发者和一个能把AI工作流接入业务系统并稳定运行一年的开发者市场价值完全不同。后者不仅懂模型还懂工程化。目前多数团队缺的正是这种能衔接模型和业务的工程型人才。如果你现在想切入AI我建议不要只学“怎么调接口”而是把一门语言的好实践、数据库、消息队列、日志监控这些基本功补上。AI应用跑量之后真正让你踩坑的往往不是模型能力而是工程系统。6.3 一线业务侧的AI布道者还有一个容易被忽视的岗位能说服一线员工使用AI的人。很多AI项目失败不是产品不行而是用户不用。一线员工对AI的担心包括做错了谁负责、会不会替代我、输出不可信怎么办、流程会不会变得更麻烦。能解决这些问题的人不一定写代码但必须理解业务流程能把AI工具包装成“帮自己干活”的助手而不是“领导用来考核效率”的工具。这种业务侧能力在AI普及过程中会越来越值钱。企业想提升AI渗透率光有技术团队不够还需要能在一线做培训和流程再造的人。7. 怎么读Eric Vishria这类“AI被低估”观点7.1 投资人的“被低估”和工程师的“被低估”不是一回事标题里的Eric Vishria如果只看字面他说的是一种市场定价判断。站在一级市场或长期投资视角看到的是生成式AI对软件开发生命周期和企业工作流的重塑还没有完全反映到估值里。这个判断放在五到十年的尺度上很可能成立。但工程师和产品经理要小心投资人的“被低估”不代表明天所有AI股票都会涨也不代表随便做一个AI项目都能成功。它更像是在说这个市场的真实需求空间比当前产品供给能力要大。需求大产品供给能力弱中间就是机会。所以读这类观点时不要把它当成操作指令要把它当成一个假设如果AI市场真的被低估那应该体现在哪些具体指标上可能是企业AI渗透率可能是AI项目留存率可能是AI相关岗位薪资也可能是AI工具在传统行业的使用频率。把这些指标列出来才是更有价值的动作。7.2 把观点变成可验证假设再决定要不要跟进我自己面对“XX市场被低估”这种观点时不会急着下结论。我会把它转成几个可以验证的动作先看自己所在行业的AI使用深度是停留在聊天还是已经进入业务系统再做一个最小AI工作流记录时间和稳定性数据然后观察团队或客户是否愿意改变原有习惯来使用它最后评估成本模型成本、人力成本、维护成本是否低于节省下来的时间。如果以上四点都倾向正面那说明至少在你所在的细分场景里AI确实被低估了。如果做不到那说明你可能只是处于一个还没有找对场景的阶段需要调整方向。我一直觉得AI市场最有趣的地方不在于模型本身多强大而在于“怎么把模型变成一个个可靠的任务完成者”。这件事需要大量工程实践需要懂业务、懂数据、懂产品、懂人。当前大多数企业还处在尝试期所以不管外界说高估还是低估真正的机会都在“落地”这两个字上。如果你也想验证这个判断建议先从下周要做的第一张周报开始把整理素材和生成草稿交给AI自己只做确认和修改。跑上两周再看你的时间账本和愿意程度。你能把一个简单任务真正跑顺才有资格讨论AI市场是不是被低估。