和你根本你半夜刷招聘软件，发现“三年 Java，带团队，薪资可谈”的岗位越来越挑人，而“初级前端、初级后端、代码搬运工”这类岗位名肉眼可见地少了。再打开朋友圈，一茬一茬的人在晒 Cursor 写代码、AI Agent 自动提交 PR，配文还都是“生产力解放”“一个人顶一个组”。焦虑吗？多少有一点。
但我在这一行混了十几年，今天想跟你说一句实话：AI 确实在改变程序员这个职业，但它改变的是“需求结构”和“工作方式”，不是把程序员这个物种消灭掉。 更准确地说，AI 正在把那些只会“翻译需求成代码”的人推下牌桌，同时把那些“懂业务、懂设计、会用工具”的程序员抬上火箭舱。
这不是鸡汤，是我这一两年里在真实项目里亲眼看到、亲手验证过的结论。这篇文章不跟你谈抽象的“未来趋势”，也不贩卖“再不学就晚了”，我就用几个具体的观察、一次完整的工具实战、一个可以照着做的 AI 应用开发流程，把“程序员怎么被 AI 带着飞”这件事掰开揉碎讲明白。
1. “程序员失业”焦虑的真相：岗位在变，但不是消灭
1.1 为什么“程序员失业”会成为一个热搜级话题
先说结论：这几个热搜词之所以反复出现，背后有三个被放大的错觉在互相叠加。
第一个错觉叫“AI 写代码的速度太快了”。你让 ChatGPT 写一个冒泡排序，它一秒出结果；让 Cursor 在你现有工程里加一个接口，它十秒钟把 Controller、Service、Mapper 全给你铺好。旁观者看到的是“AI 已经把活干完了，要程序员还有什么用”，但漏掉了最关键的一点：AI 生成的代码本身不产生价值，通过验收、正确嵌进系统、满足业务预期的那部分代码才产生价值。 这就好比你请了个实习生，三分钟能写出 200 行代码，但里面有 50 个编译错误、30 个逻辑漏洞，你依然需要一个能把这些代码盘活的人。
第二个错觉叫“岗位数量在肉眼可见地缩水”。确实，我身边不少公司在招聘初级岗位时变得更加谨慎，一些技术含量偏低、重复度偏高的职位（比如单纯写页面、只做数据搬运的岗位）确实在变少。但与此同时，懂 AI 开发、能调模型、能做 RAG 应用的岗位预算反而在涨。这不是程序员这个大盘子变少了，而是岗位密度从“低端执行层”往“高价值决策层”转移。你感觉岗位少了，是因为你一直在看旧地图。
第三个错觉叫“AI 已经全知全能”。短视频里那些“我一句话让 AI 生成了一个 App”的演示特别唬人。但你去真实工程环境里试试就知道了：让 AI 理解你那套 8 年历史、文档缺位、团队换过三轮的老系统，它大概率会一本正经地给你写出一个“看起来合理但一上线就炸”的东西。AI 是很好的执行者，但它不是一个“自带完整业务上下文”的同事。真正能落地的 AI 编程，永远需要一个人类在中间补上下文、划边界、做判断。
1.2 AI 淘汰的到底是什么类型的程序员？价值锚点说了算
我带了这么多年项目，看人的时候习惯先判断一个词：价值锚点。就是这个人觉得自己在一个项目里不可替代的原因是什么。
以前很多程序员的锚点是“我会写 Java”“我会写 Vue”“我熟悉 Spring Cloud”。这些东西在 AI 出现之前是稀缺技能，所以值钱。但今天，你让 AI 去写一个符合 Spring Cloud 规范的微服务，它在五分钟内就能交付第一版。也就是说，当“会写某种代码”这件事的稀缺性被技术抹平，“只会写代码”的人自然会感受到危机。
那被留下来的是谁？锚点在下面三类上的程序员：
- 锚点是“我懂这个行业的业务噪音”：比如你做过三年银行核心系统，知道日切、对账、冲正这些业务是怎么流转的。AI 能写出漂亮的代码，但它不知道“夜里 11 点后这个接口不能做非查询操作”这种行业规则。
- 锚点是“我能把模糊需求变成精确方案”：产品经理说“把体验做更好”，AI 会给十种写法，但哪个方向才是这版产品真正需要的，需要人来判断。
- 锚点是“我能对线上结果负责”：AI 不背锅，也不会在大促前夜帮你盯着监控。代码上线后出问题，责任人是程序员，不是模型。
所以你想一个问题就行：如果你的日常工作中，大部分时间花在“把已经设计好的功能翻译成代码”，那 AI 就是来取代你的；如果你的工作里包含“为什么要做这个功能、边界在哪、怎么评估它是否成功”，那 AI 是来成就你的。工具替代的是动作，不是责任。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 我用 AI 编程工具的实战体验：从“写得更快”到“少踩坑”
2.1 为什么我选择 Cursor？工具选型背后的逻辑
先说背景，我平时主要参与的是 Java/Spring Boot 方向的业务系统开发，同时会写一些前端页面和脚本工具。市面上的 AI 编程助手我基本都试过，GitHub Copilot、通义灵码、Cursor、JetBrains 家的 AI Assistant，还有各种国产的智能体平台。现阶段主攻 Cursor，原因有三。
第一，它 读整个工程的能力 明显更强。Copilot 的单文件补全做得不错，但当你需要 AI 跨多个文件帮你改动时，Cess Cursor 的 Agent 模式能把相关的 Controller、Service、Mapper、配置文件一起纳入上下文，这是接近“真实结对编程”的体验。第二，它的交互模式更像“对话式修改”，而不是“嵌入式补全”。我改一个复杂点时，可以直接问它“这个模块哪些地方都引用了这个工具类，给我列出来并说明影响”，它像同事一样回答，而不是静静在光标后面猜你要写什么。第三，因为它的新版本功能更新很勤，很多细节设计是冲着“专业程序员日常”去的，而不是冲着“短视频演示”去的。
但这不代表你无脑装一个 Cursor 就能“飞”。我给你一句很实在的建议：AI 编程工具的上限取决于你给它多少正确的上下文，下限取决于你做不做 Code Review。 工具只是一个杠杆，支点不稳，撬动的可能就是没完没了的返工。
2.2 加一个“导出 Excel 报表”功能的完整过程
用一个真实小需求来演示：上个季度我们内部管理系统要加一个“按月导出对账单”的功能。我特意模拟两种用法，给你们看看差别。
第一次，我直接问 Cursor：“给订单模块加一个导出 Excel 报表的接口。”它很快就生成了一份看起来完整度满分的代码，Controller 有、Service 有、导出工具类也调了。但我 review 的时候发现两个问题：第一，它没有沿用项目里的 ApiResponse<T> 统一返回结构，而是自己定义了一个 Result 类，这会导致前端所有拦截器全部失效；第二，它选的导出方式是 POI 的 SXSSFWorkbook，但项目里早就封装过一个基于 EasyExcel 的异步导出组件，运维那边还配了文件清理任务，只用这个组件才能触发。
这就是典型的“能运行但不可用”的 AI 代码。它没有你脑子里那些约定俗成的项目知识。
第二次，我把三样东西喂给它：项目里统一返回类的代码、异步导出组件的接口签名，还有一句业务约束“对账单的金额精度需要保留两位，且包含已支付和待支付两类订单之和”。这次生成的代码基本能直接用，整个改动大约花了 20 分钟，我主要在看逻辑、改边界，而不是从零敲代码。
所以我想让你记住的第一个实操心法：用 AI 前，先给它“项目集成的规则清单”。 不用很长，几条核心约定就够。你可以放在项目根目录的 AGENTS.md 或 CLAUDE.md 文件里，让 AI 每次回答前先读这个规则。比如：
markdown复制# 项目编码规则
- 所有接口返回必须用 ApiResponse<T>
- 导出 Excel 必须使用 AsyncExporter 组件，禁止直接用 POI 操作
- 数据库时间字段统一传字符串 yyyy-MM-dd HH:mm:ss，禁止 Date 直出
- 新增依赖需先在用户故事中说明理由
我当时整理完这个文件后，Cursor 在项目里的“智商”至少高了一个档次。这叫 给 AI 建立项目共识，就像你给新同事一本新人手册。
2.3 AI 代码的常见坑与 Code Review 重点
AI 生成的代码能不能直接上线？我的答案是：可以，但那必须发生在你 review 完之后。 下面几个点是我在实战里踩过、也看别人踩过的，专门帮你避雷。
第一个坑是**“幻觉式 API 调用”**。AI 偶尔会一本正经地调用一个不存在的方法，或者想当然地给某个库加上一个不存在的参数。最常见的场景是：它用了你依赖的某个库的新版本 API，而项目实际还锁在老版本。遇到这种情况，把完整的报错信息和 pom 文件版本扔回给它，它通常能自己修正，但你必须有一个“AI 也可能编接口”的意识，不要无脑信任自动补全。
第二个坑是**“路径和环境的想当然”。AI 默认你文件读写用的是相对路径，但很多线上服务部署在容器里，工作目录跟你本地跑是完全不同的。还有配置文件，它可能写死一个本地 IP，测试环境一跑就崩。这类问题的特点是“在我的机器上明明能运行”，所以你 review 时尤其要关注资源路径、环境变量、配置中心这些外部依赖**。
第三个坑是**“没有安全问题视角”**。AI 生成的 SQL 常常忘了加租户隔离条件；前端代码可能把后端异常信息直接抛到页面上；鉴权注解也可能漏掉。这些在语法层面完全没问题，但一上线就是事故。所以但凡涉及数据查询、权限控制的代码，我要求组里必须人工过一遍越权类风险。
第四个坑是**“测试覆盖的错位”**。AI 很擅长写单元测试，但它会给你写出“验证代码存在”而不是“验证行为正确”的测试。比如它可能断言 service.getById(1) 的返回值不为 null，这等于没测。你 review 测试用例的时候，要看断言是不是覆盖了你最关心的业务分支。
坦白讲，Code Review 这个环节在 AI 时代不是变轻松了，而是变得更重要了。以前你 review 的是同事写的代码，默认他有基础判断力；现在你 review 的是大模型基于概率生成的代码，它什么都敢写，你就要什么都敢质疑。
2.4 把提示词当成“给实习生派活”，效果翻倍
经常有人问我：“提示词是不是要学很多东西？有没有模板？”我的答案会让你失望：好提示词不是一套玄学，它就是一条朴素的沟通原则——把背景、约束、示例和验收标准说清楚。
我发现最能提升 AI 编码质量的提问范式是这五要素：
- 角色背景：一句话说清楚它在什么项目里工作，技术栈是什么。
- 任务目标：它要交付什么，不要用什么，边界在哪。
- 上下文链接：相关代码文件、接口定义、报错日志，能贴就贴。
- 输出格式：告诉它是直接出完整代码，还是先给方案你确认再写。
- 验收方式：你打算怎么验证它，比如“编译通过”“跑通单测”“符合项目统一返回类”。
举个例子。别只说“给用户模块加一个查询接口”，你可以这样写：
text复制在这个 Spring Boot 3 项目中，给 UserController 增加一个分页查询用户列表的接口。
要求：
1. 复用现有的 PageResult 返回结构，不要新建统一返回类；
2. 查询条件包含 name 模糊匹配和 status 精确匹配；
3. 查询逻辑写在 UserQueryService 里，不要在 controller 里直接调 mapper；
4. 先告诉我你准备怎么改，确认后再生成完整代码。
最管用的是最后一句话：“先告诉我你准备怎么改，确认后再生成完整代码。”这就相当于你跟实习生说“你先把方案讲给我听，我点头你再去动手”。AI 一旦先输出方案，你就能在半路上把方向纠偏，而不是等它写出一大坨不符合预期的代码再返工。
我还有个习惯：让 AI 先解释代码，再让它改代码。当 Cursor 对我的老工程乱来的时候，我会先把它“骂一顿”（把报错贴给它），然后补一句：“先读一下这个模块的代码，告诉我这个方法的调用链路和它改完后可能影响哪些地方，再动手。”这一步能大幅减少它“自以为改好了但破坏了其他调用点”的概率。
3. 程序员与 AI 最好的相处方式：把 AI 变成产品能力
3.1 两条最典型的路：RAG 知识库与 Agent 工作流
聊完了“用 AI 写代码”，我要说一个更值得程序员关注的方向：别只把 AI 当成编辑器里的插件，要把它当成一个可以嵌入产品的组件。 这也是“程序员拥抱 AI”与“普通用户用 AI”之间最大的区别——普通用户问 AI 一个问题拿到答案就结束了，程序员要做的是把这个能力沉淀成系统的一部分，让它持续地为业务供给价值。
眼下最典型、也最容易出成果的路有两条：RAG 知识库和 Agent 自动化工作流。
RAG（Retrieval-Augmented Generation，检索增强生成）解决的是“AI 没有你的私有数据”的问题。你把自己的文档、规则、历史工单、产品资料做成可检索的索引，再让大模型基于这些检索结果回答问题。这个方案最大的好处是不需要微调模型，成本低、效果好、可以随时更新知识，特别适合企业内部问答、客服辅助、研发知识库这些场景。
Agent 工作流解决的是“AI 只能聊天，不能干活”的问题。你可以把它理解成一个有工具使用能力的机器人：让它读取数据库、调用接口、发送消息、定时执行任务。程序员最熟悉这些工具链，所以做 Agent 落地几乎是手拿把攥的事。
3.2 从零搭一个私有知识库问答助手
我用自己上个月做的一个小项目给你们拆一下完整链路。事情起因是组里的新人总是重复问一些相同的问题：怎么连测试库、怎么走发布流程、这个服务异常怎么排查。我整理文档写了不少，但没有一个统一入口，于是花了不到三天搭了一个“团队知识库问答机器人”。
技术选型长这样（这是当时实际用的组合，供参考）：
| 组件 | 选择 | 选择理由 |
|---|---|---|
| 向量数据库 | 本地部署的 Milvus 或轻量级 Chroma | 数据不出内网，安全可控；Chroma 部署成本更低，适合百份级文档规模 |
| Embedding 模型 | BGE-M3 或通义文本向量模型 | 中文效果稳定，对技术文档类短句召回质量高 |
| 大模型 | Qwen 或智谱 GLM 的 API | 通过 API 调用，免去自建模型服务的运维成本 |
| 前端入口 | 一个很轻的 Web 页面 + 飞书群机器人 | 团队日常在飞书里沟通，群里直接提问最方便 |
搭建过程大概分四步：
第一步，文档清洗与切分。这是最容易被新手忽略但最影响效果的一步。不要直接把一整篇长文档向量化，而是要把文档切成适中大小的片段，并且片段之间要有一点重叠，防止查询时上下文被切断。我实践下来，中文技术文档切到 512 到 768 个 token 一段，重叠 64 到 128 个 token，效果比较均衡。切分时如果能按 Markdown 的标题层级先做结构切分，再对超长段落做二次切分，召回效果会明显更好。
第二步，数据入库。把文档片段逐条 embedding，然后写进向量库。这一步没什么技术难度，但要注意给每条数据保留元数据，比如文档名称、原文链接、所属模块。后面做引用溯源时，这些信息会非常有用。
第三步，检索召回。用户提问后，先把问题 embedding，再从向量库里召回 top-k 条相关片段。k 值我一般取 5 到 8，具体看文档分散程度。如果你发现知识库里内容很多，且主题跨度大，建议加一个重排（rerank）环节，把召回结果用交叉编码器再审一遍，不然容易出现“相关但答非所问”的尴尬。
第四步，大模型组织答案。把召回的片段拼到提示词里，让大模型“只依据提供的资料回答”。注意一定要指定：如果资料不足以回答，就明确说不知道，不要自由发挥。
这套流程跑通之后，我最大的感受是：AI 应用开发的难点真不在 API 调用，而在数据质量和交互设计。 你文档没写好、切分不科学，再强的模型也回答得稀烂。
3.3 嵌入团队工具的自动化工作流，AI 才算真的“用起来”
知识库问答是“被动答疑”，另一类值得做的是“主动干活”的 Agent。我举一个真实例子：我们组每周要出一份项目进展周报，以前需要有人去翻各个需求的状态、统计 bug 数、汇总风险。我后来写了一个定时 Agent：每周五下午自动从项目管理平台拉取数据，过滤出本组的任务，用脚本汇总成 Markdown，再调用大模型生成一份带摘要和周计划的草稿，最后推送到群里的周报机器人。
说实话，这套东西执行起来不难，最核心的就是把动作拆成“读取数据—加工数据—调用模型—输出消息”四段。但它的价值非常大，因为它把程序员从重复劳动中解放出来，让你去做周报里那些真正需要判断的内容。这就是“AI 让程序员飞起来”最直观的体感：同一个下午，别人在复制粘贴数据，你在写新功能的方案。
如果你想做 Agent，可以先去了解 LongChain 或 LangGraph 这类编排框架，也可以直接用各平台自带的 Workflow 画布。但我建议你不要一上来就研究复杂的框架，先用一个 20 行左右的 Python 脚本，把“拉数据—调模型—发消息”打通，等真正理解了状态流转和异常处理，再决定要不要引入框架。
4. 未来程序员的能力版图：代码只是其中一块
4.1 能力重心从“写代码”转向“做决策”
如果只让我用一句话总结 AI 时代程序员的位置，我会说：你不再是代码的生产者，而是行为的决策者。 你决定让 AI 做什么、不做什么；决定它产出的东西是否被采纳；决定系统边界在哪里。这个转变比你多会一个框架重要得多。
以前写一个功能，核心成本在“实现”；现在实现成本被 AI 压得很低，核心成本变成了“定义清楚什么是正确”。所以我在面试程序员的时候，已经不把“会背多少 API”当重点了，而是更多看这个人能不能把抽象需求拆成可执行步骤、能不能说清楚一个功能可能带来哪些边界影响、能不能写出让 AI 听得懂的任务描述。这一整套能力，我叫它“数字时代的工程表达力”。
这个表达力包含三个子能力：
- 上下文获取能力：你比 AI 多知道哪些信息？你能不能快速把项目里的信息整理出来交给 AI？
- 约束表达能力：你能不能清楚地告诉 AI“这里不能那样做”“这个方案违反了什么约定”？
- 结果评估能力：AI 给出来的东西，你能否判断好坏、发现隐患、补上测试？
这三个能力，本质上和编程语言无关，但它们会决定同一位程序员在 AI 时代的产出差距。别人用 AI 一小时交付一个模块，你花三小时还在跟 AI 互相拉扯，差的就是这三个底层能力。
4.2 现在就可以上手的三个提升方向
别把这件事想得太宏大，你不需要等公司给你安排 AI 转型任务，我现在就能给你三个可以立刻去做的方向。
第一个方向是把手头的重复代码交给 AI 重构。你不想写但又不得不写的 Mapper、DTO、CRUD 接口，都可以让 AI 帮你生成，然后你自己专注在业务校验和异常处理上。用完之后你会立刻感受到，压力小了很多。这能帮你建立“AI 可用”的信心。
第二个方向是每周用 AI 做一个小工具，解决一个真实问题。比如写个脚本自动整理日志、写个工具批量处理图片、做一个 Excel 合并小助手。不用追求完美，先跑通。这个过程中你会积累大量和 AI 协作的手感，包括怎么提问、怎么纠正它、怎么验收结果。
第三个方向是把自己熟悉的一个模块“AI 化”。选一个你负责的老模块，把它的文档、设计思路、常见问题整理成一份结构化资料，然后喂给 AI 做成知识库或提示词。以后你再带新人、再排查问题，都可以先让 AI 预答一遍，你再复核。这就是把你个人的隐性经验变成可复用的资产。
4.3 给所有被焦虑困扰的程序员一个判断框架
最后，我想给你一个我用来判断自己职业安全度的框架，你可以定期拿来自检。核心就一句：当 AI 能替代掉你的绝大部分动作，你是否还能提供让项目变好的判断力？
我拆成四个问题：
- 如果把你手头的任务交给一个“AI + 一个刚毕业的新人”组合，他们能完成到什么程度？如果接近百分之百，说明你当前做的事，可替代性很高。
- 你所在项目里，有哪些知识只存在于你的脑子里，没有任何文档也没有第二个人完全掌握？这些就是你短期的安全垫。
- 你是否了解你所在行业的业务逻辑，不只是技术实现？换句话说，你能不能跟产品经理、运营、客户在一个频道上对话？
- 你最近三个月，有没有主动给团队的工作方式带来变化，包括引入新工具、优化流程、减少重复劳动？
如果你的答案不太理想，也不用紧张。我见过太多工作了五六年、陷入重复开发的同行，慢慢开始焦虑。我给你们的方法很简单：不要把“熟练使用 AI”当成口号，要把它变成你每天的工作习惯。 打开你的编辑器，先让 AI 读一遍你今天要改的模块，问它“这段代码的意图是什么”；提交代码前，让 AI 先做一轮“预 review”。坚持两三个月，你会发现自己对 AI 的态度从“怕它”变成了“用它”，进而变成“指挥它”。
我个人现在最享受的时刻，不是 AI 帮我写了多少代码，而是我把它当成一个永远不会嫌弃我问题蠢的结对搭档。有了它，我更敢去接那些我以前不敢碰的陌生领域了——内核协议看不懂，就贴给 AI 逐行讲给我听；数据管道不会搭，就让它先给我列方案我再来选。这种边学边做、以战养战的状态，反而让我找到了刚入行时那种什么都能学的兴奋感。
所以，别慌。如果你愿意往前迈一步，AI 不是悬在你头顶的剑，而是踩在你脚下的风火轮。