1. 从一份YC名单里嗅到的风向变化前阵子我把YC S23那一批项目名单从头到尾翻了两遍第一遍是看热闹第二遍是拿着笔记本逐个记。原因很简单我做AI应用落地咨询这几年判断方向不能靠感觉得看真金白银投出来的项目在做什么。看完之后最大的感受就一句话AIGC那波“套壳狂欢”确实在退潮而AI往具体行业里扎的势头越来越猛。这个判断不是拍脑袋。你去看S23这批项目纯做“AI生成文案/图片/视频”的通用工具占比明显下降取而代之的是大量垂直场景的AI应用——法律合同审查、医疗病历结构化、制造业质检、保险理赔自动化、客服工单分流。这些项目有个共同特征不追求模型多强而是追求把某个具体流程的某个环节做透。换句话说投资人不再为“又一个AI聊天框”买单而是为“这个AI能帮某行业省掉几个人力”买单。这篇文章我想聊的就是这个转向背后的逻辑以及如果你是一个开发者、产品经理或者想用AI做点事的人应该怎么理解并抓住这波变化。我会从项目结构拆解、核心技术点LLMOps、Copilot、RPA这些热词到底怎么落地、实操路径、常见坑几个角度展开。不管你是刚接触AI应用的新手还是已经在做落地项目的从业者应该都能从里面找到能直接用的东西。2. YC S23这批项目到底在做什么结构拆解与选型逻辑2.1 从“模型能力展示”到“流程嵌入”的转变早两年看AI项目BP里恨不得把“我们用了GPT-4”写在第一页。S23这批项目反过来了很多项目介绍里根本不提用了什么模型而是直接说“我们把XX行业的XX流程从3天缩短到2小时”。这个变化非常关键它意味着AI从“卖能力”变成了“卖结果”。我拿一个具体的例子来说。名单里有个做建筑行业投标文件审查的项目它的核心不是让AI读懂标书——这个用通用大模型加提示词就能做——而是把审查规则拆成了几百条结构化检查项AI负责提取标书里的关键信息然后逐条比对规则库最后输出一份带风险等级标注的审查报告。这里面模型只是其中一个环节真正值钱的是那套规则库和流程编排。提示如果你现在还在做“通用AI助手”类的产品建议认真想想你的用户到底在什么场景下会打开你。没有场景锚点的AI产品留存率通常很难看。2.2 为什么垂直场景的AI应用突然吃香了这里面的逻辑其实不复杂。通用大模型的能力在过去一年快速拉平了你能调用的API别人也能调用模型本身不再是壁垒。那壁垒在哪里在行业know-how的数字化程度和流程整合的深度上。我总结下来S23这批项目能拿到钱主要靠三个东西数据壁垒有些项目手里有行业独有的标注数据或规则库比如医疗编码库、法律判例结构化数据这些不是爬虫能搞定的。流程壁垒把AI嵌入到客户已有的工作流里比如直接对接企业的ERP、CRM系统替换成本高客户一旦用了就不太愿意换。合规壁垒金融、医疗这些行业对数据隐私和审计要求极高能搞定合规的团队天然有优势。这三个壁垒里流程壁垒是最容易被低估的。我见过太多技术很强的团队模型效果比竞品好一截但就是因为没有嵌入客户流程最后被一个效果一般但能直接对接客户现有系统的产品打败。2.3 一个典型项目的技术架构拆解我拿名单里一个做保险理赔自动化的项目来拆。它的流程大概是客户上传理赔材料照片、PDF、手写单→ OCR识别结构化 → 大模型做信息抽取和初步审核 → 规则引擎做合规校验 → 人工复核异常件 → 输出理赔结论。这个架构里大模型只负责信息抽取和初步判断真正决定准确率的是前面的OCR质量和后面的规则引擎。很多团队一上来就想用大模型端到端搞定结果发现幻觉问题在保险这种容错率极低的场景里根本没法接受。所以他们的选择是把大模型的能力限制在一个可控的范围内用规则引擎兜底。这个思路我觉得特别值得借鉴。你在做AI落地的时候不要想着让模型解决所有问题而是要想清楚哪些环节模型做得好、哪些环节必须用确定性逻辑兜住。3. 热词背后的真问题LLMOps、Copilot、RPA到底怎么落地3.1 LLMOps不是运维是“让模型持续变好”的工程体系LLMOps这个词现在被用得很泛好像只要部署了个模型就叫LLMOps。但我在实际项目里看到的LLMOps核心其实是三件事评估、监控、迭代。评估这块很多团队做得太粗糙。我见过一个团队模型上线前就找了20条测试用例跑了一遍觉得效果不错就上了。结果上线一周用户投诉不断。问题出在他们的测试用例和真实用户输入分布差太远。后来我们帮他们搭了一套评估流水线每天从线上采样500条真实请求人工标注100条跑自动化评估指标同时监控模型输出的异常率。这套东西搭起来之后模型迭代的方向才清晰。监控这块除了常规的延迟、错误率我建议一定要监控输出分布的变化。比如你做一个客服意图分类的模型如果某天“退款”类意图的占比突然从5%涨到30%那可能是业务侧出了什么问题或者模型漂移了。这种信号比单纯的准确率下降更早出现。迭代这块我的经验是小步快跑。不要憋大招每次只改一个变量比如只换提示词模板或者只调整检索策略然后看评估指标的变化。一次改太多东西效果好了你不知道为什么好坏了也不知道为什么坏。3.2 Copilot类产品的核心不是“补全”是“上下文理解”GitHub Copilot火起来之后一堆产品都叫自己Copilot。但我用下来真正好用的Copilot和普通代码补全的区别在于它能不能理解你当前工作的上下文。举个例子你在写一个React组件普通的补全工具只能根据当前行的语法给你提示。但好的Copilot会看你整个文件的结构、你引用的组件库、甚至你最近几次提交的代码风格然后给出更符合你项目习惯的建议。这个差别在写业务代码的时候特别明显——前者给你的是“语法正确的代码”后者给你的是“能直接用的代码”。注意如果你在做Copilot类产品不要只盯着补全准确率这个指标。用户真正在意的是“我接受这个建议之后还需要改多少”。这个指标我一般叫“接受后修改率”比单纯的接受率有价值得多。3.3 RPA和AI的结合点在哪里RPA机器人流程自动化这两年热度回升很大程度上是因为AI补上了它最缺的那块能力处理非结构化数据。传统的RPA只能操作结构化数据比如从Excel里读一个数字填到另一个系统里。但企业里大量的流程涉及PDF、邮件、图片、聊天记录这些非结构化内容传统RPA搞不定。现在有了大模型RPA可以先调AI把非结构化数据转成结构化的然后再走原来的自动化流程。我去年帮一个客户做的项目就是这种模式他们财务部门每天要处理几百封供应商发来的对账单邮件邮件里既有PDF附件又有正文表格。原来的做法是人工一封封看现在用RPA抓取邮件调AI提取关键字段供应商名称、金额、账期然后自动录入到财务系统人工只处理异常件。整个流程下来处理时间从平均每封8分钟降到1分钟以内。这个案例里AI不是替代RPA而是给RPA装上了“眼睛”和“大脑”。如果你在做RPA相关的工作建议重点看看哪些流程卡在“数据格式不统一”这个环节上那里就是AIRPA的机会。4. 实操从零搭建一个垂直场景AI应用的完整路径4.1 第一步选场景别选“大”场景我见过太多团队一上来就说“我们要做法律行业的AI助手”这种场景太大了。法律行业里合同审查、判例检索、法律咨询、文书生成每个都是不同的产品。你选一个大场景最后做出来的东西往往哪个环节都不够深。我的建议是从“一个岗位的一天”里找场景。比如你选“合同审查”再往下拆初级律师审查一份采购合同他具体在做什么先看双方主体信息对不对再看付款条款有没有坑再看违约责任是否对等再看争议解决条款。这里面每一个检查项都可以是一个AI功能点。你先把其中一个做到90分比做五个60分的功能有价值得多。选场景的时候我一般用这个标准来判断值不值得做判断维度值得做的信号不值得做的信号频率每天都要做或每周多次一年做几次耗时单次超过10分钟几分钟搞定容错率错了可以人工复核错了后果严重且不可逆数据可得性有历史数据或规则文档完全靠人脑经验无记录用户付费意愿直接影响收入或成本只是“锦上添花”4.2 第二步数据准备别急着调模型很多技术出身的同学一拿到场景就想着怎么调模型但我的经验是数据准备占整个项目60%以上的工作量而且这部分做扎实了后面模型选型反而简单。数据准备分三块输入数据用户实际会输入什么格式是什么有没有噪声我一般会收集至少200条真实输入样本然后做聚类分析看看主要分几类。输出数据期望AI输出什么格式是JSON还是自然语言字段有哪些这个要和业务方对齐清楚不然后面返工成本很高。评估数据怎么判断输出对不对这个最容易被忽略。我建议在项目开始前就定好评估标准最好能有一个小规模的标注集哪怕只有100条也比没有强。提示如果业务方说“我们也没有历史数据”那你要小心了。没有数据意味着没有评估标准项目很容易变成“我觉得好就是好”的扯皮。这种情况下建议先做一个规则版的原型让业务方用起来在用的过程中积累数据。4.3 第三步技术选型别追新追稳技术选型这块我的原则是能用API就不自己部署能用小模型就不上大模型。原因很简单API的维护成本低小模型的响应速度快、成本低。只有在数据隐私要求极高或者延迟要求极严的场景下才考虑自己部署。具体到模型选择我一般按这个顺序试先用通用大模型API跑一版baseline看看效果上限在哪里。如果效果不够再考虑微调小模型比如7B参数级别的。如果微调还不够再考虑用更大的模型或者更复杂的架构。这里有个坑要提醒不要一上来就微调。我见过一个团队花了两周时间微调了一个模型结果发现用更好的提示词就能达到差不多的效果。微调应该是最后的手段不是第一选择。4.4 第四步流程编排把AI嵌进去AI能力做出来之后怎么嵌到用户的流程里这个环节决定产品能不能用起来。我一般会画一张流程图标出哪些环节是AI做、哪些是人工做、哪些是规则做。以合同审查为例AI做提取合同关键条款、比对规则库、标注风险点规则做格式校验、必填项检查、金额计算人工做最终确认、修改建议、与对方沟通这个分工不是固定的要根据实际效果调整。比如如果AI提取准确率很高就可以减少人工复核的比例如果某个条款AI总是搞错就把它交给规则或者人工。5. 踩过的坑垂直AI应用落地常见问题与排查5.1 模型效果“实验室好、线上差”怎么办这个问题太常见了。实验室里用精心挑选的测试集准确率90%一上线就掉到60%。原因通常是线上数据的分布和测试集不一样。排查思路先看线上请求的输入长度分布是不是比测试集长很多长文本容易导致模型遗漏关键信息。再看输入的语言风格是不是有大量口语化表达、错别字、中英混杂这些在测试集里可能没有覆盖。最后看输出格式是不是有大量请求要求模型输出特定JSON格式而模型经常格式错误解决这类问题我的经验是在线上加一层输入预处理。比如把长文本先做摘要再送模型把口语化表达先做标准化把格式要求用few-shot示例写清楚。这些预处理看起来简单但效果往往比换模型还明显。5.2 用户不用怎么办产品做出来了效果也不错但用户就是不用。这种情况我遇到过好几次后来发现原因基本是嵌入位置不对。比如你做了一个AI辅助写周报的功能如果用户需要打开一个新页面、登录一个新系统才能用那大概率没人用。但如果你把它做成一个浏览器插件用户在写周报的文档里直接就能调用使用率会高很多。所以我的建议是AI功能要出现在用户本来就在工作的地方。他在用Excel你就做Excel插件他在用企业微信你就做企业微信应用他在用VS Code你就做VS Code扩展。不要试图让用户改变工作习惯来适应你的产品。5.3 成本控制别让API账单吓到老板大模型API按token计费用起来很容易超预算。我见过一个项目上线第一个月API账单就超了预算的三倍。控制成本的方法有几个缓存很多请求是重复的或者相似的可以把结果缓存起来。比如用户问“怎么开发票”这个问题可能一天被问几十次缓存命中率很高。分级处理简单问题用小模型复杂问题用大模型。比如意图分类用小模型内容生成用大模型。限制输入长度很多场景不需要把整篇文档送给模型可以先做检索只送相关段落。批量处理非实时场景可以攒一批请求一起处理很多API对批量调用有折扣。注意成本控制不要牺牲用户体验。我见过一个产品为了省钱把模型换成了效果差很多的版本结果用户流失更严重。省下来的API费用还不够弥补用户流失的损失。5.4 常见问题速查表问题现象可能原因排查动作解决方向输出格式不稳定提示词不够明确检查提示词是否有格式示例加few-shot示例或用JSON mode长文本效果差模型上下文窗口不够看输入token数是否超限先检索再送模型或分段处理响应太慢模型太大或请求太复杂看延迟分布定位慢请求换小模型或加缓存特定类型输入总出错训练数据覆盖不足采样错误case做聚类针对性补充数据或规则用户反馈“不好用”嵌入位置或交互不对观察用户实际操作路径把功能嵌入用户已有工作流6. 这波转向对开发者和创业者的实际影响6.1 对开发者从“调API”到“懂业务”如果你是一个开发者这波转向意味着只会调API是不够的。你需要理解你服务的那个行业的业务流程知道哪些环节是痛点哪些数据是关键哪些规则不能违反。我认识一个做医疗AI的工程师他花了三个月时间跟着医院的病案室老师上班看他们怎么编码、怎么审核、怎么和临床沟通。这三个月他没写一行代码但后来他做的产品比竞品好用很多因为他知道病案室老师真正需要什么。所以我的建议是选一个行业扎进去。不一定要换工作但可以多和业务方聊天多看行业文档多理解他们的KPI是什么。这些积累最后都会变成你的竞争力。6.2 对创业者壁垒在场景里不在模型里如果你在创业这波转向意味着不要再讲“我们用了最先进的模型”这个故事了。投资人现在想听的是“我们解决了哪个行业的哪个具体问题客户愿意为此付多少钱”。我见过一个做制造业质检的团队他们的模型效果其实一般但他们把质检流程和工厂的MES系统打通了质检结果直接触发产线调整。这个整合能力才是他们的壁垒模型只是其中一环。所以创业者在选方向的时候我建议问自己三个问题这个场景里客户现在是怎么做的痛点有多痛我的方案比现有方案好在哪里是更准、更快、还是更便宜客户换了我的方案迁移成本高不高这三个问题想清楚了方向基本就不会错。6.3 对想入行的人从“会用工具”到“能解决问题”如果你是想进入AI应用领域的新人我的建议是不要只学工具要学解决问题的方法。工具会变今天流行LangChain明天可能流行别的。但解决问题的方法论是通用的怎么定义问题、怎么准备数据、怎么评估效果、怎么迭代优化。这些能力不会过时。具体的学习路径我建议先找一个你熟悉的场景比如你之前做过的某个工作想想里面有没有可以用AI优化的环节。然后用最简单的工具哪怕就是调API做一个原型出来。找几个真实用户试用收集反馈迭代几版。把这个过程写成案例比任何证书都有说服力。7. 我个人的一些观察和体会做AI落地这几年我最大的体会是技术不是最难的理解场景才是。我见过太多技术很强的团队因为选错了场景或者没理解用户需求最后做出来的东西没人用。反而是一些技术一般但特别懂业务的团队做出了很受欢迎的产品。另一个体会是不要追求完美。AI应用不可能100%准确关键是找到一个人工兜底的机制让整体流程可靠。我做的项目里没有一个AI是100%准确的但通过合理的人机分工整体效率提升都很明显。最后说一个具体的技巧在项目开始前先做一个“人工模拟版”。就是不用AI让人按照你设想的流程手动做一遍看看流程通不通、瓶颈在哪里。这个模拟版花不了多少时间但能帮你避免很多设计上的坑。我每次做新项目都会先做这一步实测下来非常有用。