最近在开发者社区里反复刷到一条观点Stability AI 创始人认为AI 会把人类的经济寿命终结掉。很多人的第一反应是“AI 要让我失业了”但如果我们把这句话放到技术演进的语境里值得讨论的其实不是岗位消失而是另一种更现实的变化以单一技能作为终身收入来源的模式正在被 AI 快速重定价。这篇想从工程师视角出发拆解这条判断背后的AI能力边界、落地方式以及开发者可以做哪些事来应对这轮变化。1. 观点背后的“经济寿命”到底指什么1.1 AI 消灭的不是岗位而是信息差红利一个容易被情绪带偏的问题是“经济寿命终结”不等于明天所有人都会失去工作。Stability AI 创始人的说法更像是在讲一种经济学规律当某项能力的市场价格趋近于零靠出售这项能力获得长期收入的人会遇到收入模型被打破的情况。在传统软件行业里这种“能力贬值”其实已经发生过多次。早期会写网页的人可以靠一份静态页面获得不错的项目费后来建站工具普及基础建站的价格大幅下降。会写 SQL 的人曾经非常稀缺但数据库产品越来越自动化之后普通业务人员也能通过低代码工具完成部分查询。AI 正在把这件事推到更广的领域不只是代码生成还包括图片绘制、视频脚本、数据分析、甚至产品原型设计。所以用“终结”这个词听上去很吓人但本质上说的是依靠长期积累的固定技能吃一辈子的模式在 AI 时代会遇到更强的竞争壁垒。以前一个人的对手是同行现在还要面对“会用 AI 的同行”和“直接调用大模型的产品”。1.2 为什么这次和以往不一样历史上每次技术革命都会让一部分技能过时但 AI 的特别之处在于它不在某一个细分领域而是横跨文本、图像、音频、代码、推理等多个模态。过去几年各类大模型的能力边界一直在扩张。最早的对话模型只能完成简单问答后来逐渐可以写代码、做翻译、总结文档、生成图片。到 Agent 阶段模型甚至能按任务拆解步骤、调用工具、观察执行结果并修正策略。这种能力一旦接入业务流程替代的就不是某个打字员或画师而是“接到需求、拆解任务、协调资源、交付结果”这条完整链路中的多个环节。站在软件开发者的角度来看真正的变化不是“模型写不写代码”而是“需求到代码之间的距离变短了”。以前业务部门提一个需求产品经理拆成原型开发去实现现在如果模型已经理解业务流程并且能直接调用接口、修改代码、跑测试那大批重复性的编码工作会被压缩。这也是很多 AI 编程工具拿出来做演示时的核心杀招。1.3 这种判断的合理部分与争议部分合理的地方在于AI确实把大量知识工作者的“入门技能”变成了低成本资源。以前要成为一个初级前端至少需要掌握 HTML、CSS、JavaScript 和框架用法现在用 AI 编程工具辅助一个懂业务流程的人也能快速拼出带界面、带接口调用的原型。这会压缩初级岗位的供给需求也会倒逼新人学得更深更系统。争议的地方在于“经济寿命终结”是一个偏极端的话术。实际上 AI 也会创造新的岗位类型例如提示词工程、模型微调、AI Infra、大模型应用开发、Agent 平台建设等。技术变革从来不是均匀地消灭工作而是消灭旧岗位的同时产生新岗位问题在于新旧转换的窗口内很多人来不及补齐新技能。对开发者来说早一步把 AI 纳入自己的工程栈总比被动接受冲击更主动。2. AI 到底在重塑哪些“技能定价”2.1 从“会做”到“会调度”过去我们对能力的定义是“我会做这件事”例如会写 Python、会用 MySQL、会做界面设计。但在 AI 时代能力的评价维度开始向“调度能力”倾斜。你可以不懂每一个像素怎么画但你能不能把一张参考图、一段风格描述、一个产品需求翻译成模型听得懂的提示词让 AI 输出接近可用的结果。你可以不追求手写每一行 CRUD 代码但你能不能把一个模块拆成模型可执行的子任务并把错误信息回传给模型继续修正。这种变化对工作流的影响非常明显。以前一个开发团队里需求分析、概要设计、编码、测试是串行协作的现在一个人可以借助 AI 完成从需求到原型的快速验证然后再交给团队做正式实现。越靠近业务的人越需要具备“AI 调度能力”而这恰恰不是学校里哪个专业会系统教的内容。2.2 AI 时代的技能溢价点虽然基础能力会贬值但结构化的深度能力反而会更值钱。结合目前产业落地的情况下面几类技能在 AI 时代属于“溢价点”。第一类是模型与业务结合的能力。也就是知道哪些场景适合用 AI哪些不适合。不是所有业务都要上大模型很多时候传统规则引擎更快、更稳定、更省钱。能判断这种边界的人在团队里会越来越重要。第二类是工程化能力。模型只是服务真正需要解决的是请求并发、上下文管理、模型幻觉、数据隐私、成本控制、版本迭代等问题。一个能用工程方法把 AI 模型稳定部署到生产环境的工程师永远有竞争力。第三类是领域知识。大模型是通才但对特定行业的专业逻辑并不敏感。懂医疗、金融、制造、法律等行业规则的人配合模型能力能做出来的系统远超过只会调模型接口的人。2.3 程序员该如何理解“人类经济寿命”这件事对程序员而言更应该关注的是“程序员的平均技能半衰期”在变短。以前掌握一个框架可能五六年内都够用现在大模型技术几乎每年都有大版本级别的变化今天学的一套 Agent 实现方式明年可能就被框架内置了。所以真正能延长经济寿命的方式不是背住某一个框架的 API而是构建可迁移的能力理解问题的本质而不是边界场景的长尾。养成用代码快速验证想法的习惯。学会把复杂任务拆解成可执行的子任务。保持对新工具链的敏感但不盲目追逐热点。3. 从“恐惧 AI”到“把 AI 加入技术栈”3.1 大模型只是软件系统里的一个组件很多非技术背景的讨论偏向于把大模型说成一种“有意识的智能体”但从工程角度看大模型实际是一个软件组件。它接收文本或其他模态输入经过计算给出一个概率化输出。它并不神秘只是以前我们没有遇到过这么复杂的“函数”。正因为它是软件组件它就有工程化的问题。放在生产环境里我们需要考虑模型服务的稳定性、输出格式的可解析性、并发性能、降级方案、数据脱敏、生成内容审核、用户反馈闭环等。这些并不是模型 API 开箱即给的而是要应用开发者去搭建整套基础设施。所以对后端开发者来说这轮 AI 浪潮并没有绕过传统软件工程。相反它把系统工程的重要性进一步放大了。一个跑在业务系统中间的模型调用如果失败系统不能直接白屏如果输出了一段不符合规范的 JSON下游解析必须能优雅处理如果用户输入了包含隐私信息的内容系统要有脱敏和过滤机制。3.2 AI 应用的核心链路目前主流的 AI 应用无论是智能客服、文档助手、知识库问答还是自动编程大多数都跑在一条相似的链路上用户输入 → 意图理解 → 检索增强RAG → 组装提示词 → 调用大模型 → 输出校验/后处理 → 返回结果。这里的核心不只是“调用大模型”。为了减少模型胡编乱造俗称 AI 幻觉业界普遍会引入检索增强生成RAG技术先根据用户问题从知识库中找到候选资料再把这些资料拼进提示词让模型基于给定材料回答。这个思路相当于给模型配了一个实时更新的“参考资料库”比把所有知识塞进模型参数要便宜得多也更容易更新。当任务更复杂时就要引入 Agent 思维。Agent 把一个大目标拆成若干子任务每个子任务可以调用不同的工具比如搜索、查数据库、执行代码、调用第三方服务。传统程序是“输入-处理-输出”的确定流程Agent 则在流程中加入了“循环执行-观察结果-调整计划”的模式。3.3 为什么 AI Infra 和模型部署会成为热门方向术语里常提到的 AI Infra、模型部署本质上是底层基础设施问题。模型训练完成后不会自动被业务调用需要部署成可以支撑高并发请求的服务。这个过程中涉及模型推理优化、显存管理、服务编排、弹性伸缩、GPU 成本控制等。这些工作非常像早期云计算普及时的 SRE站点可靠性工程岗位。AI 应用一旦进入生产环境模型推理就不是一次性的实验而要经历性能压测、监控告警、灰度发布等流程。嗅觉敏锐的开发者已经发现与其争抢“提示词写得好不好”不如在模型服务化这条路上积累工程经验。4. 一个最小可运行的 AI 应用示例从检索到生成4.1 场景与设计思路为了把上面讲的链路落到代码层面来看一个典型场景智能客服知识库问答。假设企业内部有一个售后知识库里面有很多文档描述不同问题对应的处理流程。我们希望用户提问后系统先从知识库中检索相关文档再把文档拼进提示词最终由大模型生成一段客服回答。整个过程是一个最小的 RAG 原型。这里先做一个关键决定示例不会真的调用大模型 API因为外部 API 的申请和额度各不相同。代码会提供一个可运行的演示结构call_llm函数部分用固定文本模拟模型输出。真正接入时只需要替换call_llm函数内部的实现即可。4.2 项目结构ai-customer-service/ ├── data.py # 模拟知识库数据 ├── retrieve.py # 检索模块 ├── prompt.py # 提示词构建模块 └── app.py # 主入口串联流程这种结构主要用于教学演示方便理解每一层的职责。真实项目中还会加入向量数据库、日志、权限控制和模型网关但核心分层思路是通用的。4.3 模拟知识库数据文件路径data.py# 模拟知识库真实场景通常从数据库或向量数据库中读取 KNOWLEDGE_DOCS [ 如果订单超过 30 天未签收用户可以申请客服介入处理。, 退货通道在 App 端“我的订单-申请售后”中开启用户提交后等待审核。, 商品降价后不支持主动退差价但是可以尝试领取平台优惠券进行补偿。, 客服人工服务时间为每天 9:00 到 21:00。, 申请发票需要在订单完成后的 30 天内提交。, 隐私数据包括手机号、地址、身份证号后台不能明文展示。, ]这里不需要把文档做得很正式重点是分出不同条目方便后面测试检索效果。4.4 检索模块文件路径retrieve.py检索模块的职责是根据用户问题从文档中筛出最相关的几条。真实产品中一般使用向量检索把文档转换成向量后再用相似度排序这里为了无依赖运行改用简单的关键词命中次数排序。from typing import List, Tuple def retrieve(query: str, docs: List[str], top_k: int 2) - List[str]: 根据用户问题召回最相关的知识文档。 演示版本使用关键词命中次数进行简单打分 真实场景建议替换为向量检索或 BM25 检索。 query_chars [char for char in query if char not in 的了吗呢?。! ] scored_docs: List[Tuple[int, str]] [] for doc in docs: score 0 for char in query_chars: if char in doc: score 1 if score 0: scored_docs.append((score, doc)) scored_docs.sort(keylambda x: x[0], reverseTrue) return [doc for _, doc in scored_docs[:top_k]]这段代码的原理很简单遍历知识库中的每一条文档统计问题中的每一个字在文档里出现的次数按总次数排序取前两条作为候选资料。4.5 提示词构建模块文件路径prompt.py检索到候选资料后需要把它们组装成一段结构化的提示词。提示词的设计会影响模型回答的质量基本原则是说清楚模型扮演的角色。限定回答依据。要求模型不能编造。无法回答时给出替代方案。def build_prompt(query: str, context_docs: List[str]) - str: 基于检索结果构建提示词。 context_text \n.join(f- {doc} for doc in context_docs) prompt f你是一名电商平台售后客服助手。 请只根据下面的知识库内容回答用户问题。 如果知识库没有提供足够信息请直接说明需要人工客服介入不要编造规则。 知识库 {context_text} 用户问题{query} 请用简洁、友好的语气回答。 return prompt这里可以明显看到 RAG 的特点提示词并不固定而是动态拼接了知识库内容。这也意味着系统可以通过更新文档随时让模型回答“新政策”相关的问题而不需要重新训练模型。4.6 主入口与模拟模型调用文件路径app.py主入口负责把检索、提示词构建、模型调用三件事串联起来。为了不依赖外部服务call_llm函数会返回一段固定文本作为演示结果实际项目中把它替换成调用模型网关请求即可。from data import KNOWLEDGE_DOCS from retrieve import retrieve from prompt import build_prompt def call_llm(prompt: str) - str: 调用大模型的函数。 演示版本不发起真实网络请求只把提示词原样返回一部分 便于直接运行观察整体流程。 真实项目示例思路 1. 准备 HTTP Client向大模型服务端发送 prompt。 2. 解析响应 JSON提取生成文本。 3. 加入超时与重试、错误处理逻辑。 # 模拟模型返回结果 return [模拟模型输出]\n您咨询的问题已收到。根据平台规则建议您优先进入订单详情页申请客服介入。 def answer_user_query(query: str) - str: relevant_docs retrieve(query, KNOWLEDGE_DOCS, top_k2) if not relevant_docs: return 未检索到相关规则已为您转接人工客服。 prompt build_prompt(query, relevant_docs) result call_llm(prompt) return result if __name__ __main__: question 订单超过 30 天没收到货应该怎么处理 print(用户问题, question) print(- * 50) print(answer_user_query(question))运行这个脚本预期输出如下用户问题 订单超过 30 天没收到货应该怎么处理 -------------------------------------------------- [模拟模型输出] 您咨询的问题已收到。根据平台规则建议您优先进入订单详情页申请客服介入。4.7 这段示例说明了什么通过这段不到 100 行的示例可以看到一个 AI 应用的骨架其实并不神秘。核心价值在于工程组织把数据、检索、提示词、模型调用分层解耦。真实场景中每一层都可以替换成更强的组件而整体架构保持不变。更进一步如果要做成 Agent可以在app.py中加入循环第一次模型回答后判断是否需要继续调用工具如果需要则把工具返回结果再次拼进提示词让模型基于结果给出最终答案。这种“循环调用”模式是 Agent 应用的基础形态。5. AI 幻觉是工程问题不是玄学5.1 幻觉是怎么产生的模型本质上是在学习大量文本后根据前面的字符预测下一个最可能的字符。它并不是在数据库里查询事实而是在做概率生成。所以当用户问题比较冷门或者知识库资料不足时模型可能会生成一段听起来很流畅、但实际并不存在的描述这就是 AI 幻觉。AI 幻觉不能完全消除但可以大幅降低。最基本的手段就是上面示例中采用的 RAG 方案凡是关键业务回复都要先检索到可依据的资料再让模型基于资料生成。如果找不到资料就直接走“无法回答”分支而不是让模型自由发挥。5.2 工程上的三重防线第一道防线是召回质量。接入真实向量库后召回的内容如果不够精准模型仍然会答错。这时候需要优化切分策略、向量模型选型、召回条数和相似度阈值。第二道防线是提示词约束。提示词里要明确要求模型“只能基于给定材料回答”“材料中没有的信息不要编造”“不确定时说明原因”。这不能百分百防住幻觉但会显著减少模型自由发挥的概率。第三道防线是输出校验。在模型返回文本后还可以做关键词校验、实体校验、内容审核、兜底回复等后处理。例如如果回答中出现了知识库不存在的商品编号系统可以拦截并转人工。5.3 哪些场景对幻觉容忍度低涉及金融、医疗、法律、政务等行业的对外答复对幻觉容忍度非常低。在这些领域做 AI 应用不能只追求回答流利还要关注回答能否溯源。常见做法是在回答内容后面附上引用的知识文档 ID 或来源链接方便用户和管理员核验。开发者如果正在朝 AI 应用方向转型建议尽早把“控制幻觉”作为一项核心能力来打磨。会写提示词的人很多能在复杂业务中把幻觉控制在业务可接受范围内的人更稀缺。6. 开发者如何延长自己的“经济寿命”6.1 不要只学“怎么问 AI”要学如何构建系统只看“AI 提示词大全”并不能带来长期竞争力。真正有价值的是下面这条能力链能识别业务问题是否适合用大模型解决。能设计数据流数据从哪来、怎么清洗、怎么切分、存在哪。能搭建检索与生成链路。能做好成本、延迟、准确率之间的权衡。能监控线上表现持续优化。这套能力本质上还是软件架构能力只是处理的核心对象从传统数据变成了模型和提示词。6.2 从工具使用者变成流程设计者AI 编程工具已经让很多开发者尝到了甜头。用 Cursor、GitHub Copilot 或类似的 AI 插件辅助写代码效率确实会有明显提升。但如果只停留在“让 AI 补全函数”这个层面成长是有限的。更能提升竞争力的是把 AI 嵌入到完整研发流程中需求到测试用例的生成。遗留代码的注释与文档补齐。错误日志的实时分析。代码评审阶段的逻辑漏洞初筛。部署脚本与运维文档的自动生成。当你能把 AI 能力设计进流程而不是零散地使用 AI 工具你就在从“使用工具的人”变成“设计工具的人”。6.3 适合现在开始积累的 AI 工程技能如果从今天开始想在 AI 应用方向建立护城河可以按下面的路径有节奏地推进。基础层需要理解大模型 API 的请求格式、常用参数含义、token 的计算方式、上下文窗口的实际限制。这一层不需要研究底层的 Transformer 数学原理但要知道模型能处理多长的文本超出后会有什么表现。应用层重点学习 RAG 和 Agent。RAG 的重点在于文档切分、向量化、召回排序和提示词组装。Agent 的重点是任务拆解与工具调用可以先从一个小型项目开始例如让模型调用天气接口、计算器或数据库查询工具。工程层关注稳定性与安全。包括请求缓存、模型降级、敏感信息过滤、调用审计、成本统计。AI 应用在线上跑起来之后这些环节才是真正决定项目成败的部分。6.4 有选择地对齐“AI 工程实践”岗位很多大厂和创业公司已经在招聘 AI 应用工程师、Agent 开发工程师、AI Infra 工程师。这类岗位的职责通常包括设计并维护 AI 应用的完整链路编写与优化提示词模板打通业务系统与模型网关建立评测集来验证模型效果变化参与模型微调或部署方案选型。如果目前还在做传统后端可以主动找机会参与相关项目哪怕只是把已有的日志分析工具接一个大模型总结接口也算一次完整的 AI 工程实践。比起看大量概念视频亲手把一个 AI 小应用推到生产环境哪怕只有内部几十个人用都能逼着你去解决真实数据流、并发、安全和维护这些问题。6.5 用工程思维检查 AI 应用的盲区有一个容易被忽略的盲区是评测。传统软件功能是否正常可以通过测试用例判断AI 应用的输出是概率性的不能用一组固定用例一劳永逸地完成测试。正确做法是准备一个评测集里面包含常见问题、边界问题、敏感问题然后在修改提示词或更换模型版本时统一跑一遍评测集对比回答质量的差异。另一个盲区是版本灰度。模型的每次更新都可能改变行为直接全量替换到生产环境有风险。稳妥做法是先让一部分流量走新模型其他流量保持旧模型观察一段时间再全量切换。7. 常见问题与心态纠偏疑问实际情况建议AI 会立刻替代程序员吗短期内替代的是重复性、模板化工作复杂业务和系统设计仍需要人尽早把 AI 纳入开发流做高质量交付学习大模型要懂数学吗做应用开发不一定需要深入研究数学先做产品、再补原理按需学习向量数据库有必要学吗RAG 是当前 AI 应用落地的主流方式掌握一种向量数据库即可不必贪多提示词工程是不是核心竞争力只是入门技能工程化和业务理解更持久学会“结构化提示词”然后走向全链路每次 AI 工具更新都要追吗追热点容易迷失关注能稳定提升效率的少数工具深入使用生成内容出问题谁负责开发者与运营方都有责任必须加入审核、溯源和人工兜底机制对开发者来说过度焦虑和过度乐观都没有必要。“经济寿命被终结”更像一个提醒旧的技术护城河正在被填平新护城河要自己动手挖。只要还在持续写代码、持续做项目、持续把新能力抽象成工具AI 就依然是手里的武器而不是悬在头上的石头。最后只留一个小建议与其把时间花在争论 AI 会不会取代人类不如这周就用现有的大模型 API 写一个能解决真实小问题的工具。可以是一个会议纪要助手、一个代码 review 摘要器、一个知识库问答机器人。当完整跑通一次数据接入、模型调用、结果展示之后你对这轮 AI 浪潮的判断会踏实很多。