2025 年 AI 如何重构我的工作

前言

如果要用一句话概括我对 2025 年 AI 的感受，那就是：

这一次，它不是在帮我做事，而是在逼我重新定义“什么才算是我的工作”。

过去一年里，我越来越少把 AI 当作一个会聊天的工具，而是把它当作一个真正能进入流程、承担职责、交付结果的协作者来看。

所以这篇文章我不想讲玄学，也不想讲那些“AI 很厉害，未来已来”的空话。我只想讲三件更具体的事：

1. 我的认知，怎么被 AI 打碎了三次；
2. 我的团队，怎么从“用 AI”转向“与 AI 共事”；
3. 到了 2025 年，我们到底该靠什么继续值钱。

2025 年 AI 如何重构工作的封面图

PART 1 认知刷新：三次被打碎的世界观

第一次打碎：AI 从“助手”升级成了“主角”

过去我们对 AI 的想象大多停留在一个很熟悉的位置上: 它是助手，是补位，是提高效率的小外挂。

但 2025 年以后，我越来越觉得这个定位已经过时了。

AI 的能力演化，至少在我的体感里，经历了一个很清晰的四阶段过程：

• Chat：你问它答，适合获取信息和快速讨论；
• Assistant：它能围绕某项任务稳定辅助，比如整理材料、写周报、生成文档；
• Copilot：它开始进入工作上下文，和你一起写代码、补测试、做修改；
• Agent：它不只是给建议，而是能够自己完成一段闭环工作。

最关键的变化在最后一步。

Agent 的跨越，不是“更聪明了一点”，而是它开始从“动口”走向“动手”，从“问什么都会”走向“干什么都行”。当它能处理需求分析、编码、测试、部署这些串联任务时，工程师的价值中心就不可能继续停留在“写得更快”这件事上。

AI 从 Chat 到 Agent 的演化图

如果我把自己的时间线压缩成三年，也会非常清楚：

• 2023 年，我用 ChatGPT 写周报，觉得它啰嗦，远谈不上可靠；
• 2024 年，我开始用 Copilot、通义灵码处理一部分代码，发现它们在新项目里顺手，在老项目里却经常卡壳；
• 2025 年，我开始把 Cursor、Windsurf、Claude Code、Gemini CLI、Trae 真正放进交付链路里，让“写完”越来越直接地接近“上线”。

这件事带来的震动，比“AI 帮我省了多少时间”更大。

因为当 AI 可以闭环完成“需求分析 -> 编码 -> 部署”的时候，工程师真正要迁移的，不是工具熟练度，而是系统层面的判断力：问题怎么被定义，方案如何被拆解，架构怎样被设计，结果如何被验证。

第二次打碎：岗位边界正在变模糊，甚至消失

如果说第一层打碎的是“AI 在做什么”，那第二层打碎的就是“人到底凭什么分工”。

我越来越强烈地感觉到，很多岗位边界正在被 AI 侵蚀，甚至直接改写。

一个很直观的对比是：

• 一位经验丰富的工程师，可能 72 小时手撸数千行代码，能交付，但 Bug 也不少；
• 一个实习生，如果把 Cursor 和 Claude 这样的工具链配好，48 小时就能交出更稳定的结果；
• 一个原本不会写代码的需求同事，只要足够会拆问题、写 Prompt、驱动 Gemini CLI，也可能在 24 小时内做出可上线版本。

这背后的启示很直接：

技术栈本身的壁垒正在迅速下降，但另一条新的能力鸿沟正在拉开，而且比过去更陡。那就是：

• 谁能把模糊问题定义清楚；
• 谁能把系统蓝图画出来；
• 谁能驱动 AI 工具链稳定落地。

所以我越来越不相信未来的招聘 JD 还会简单停留在“Java 工程师”“Python 工程师”“Vue 工程师”这样的命名上。

更接近现实的岗位能力，反而像是：

• Problem Definer：把模糊需求翻译成明确问题；
• System Designer：把问题转成可执行的系统蓝图；
• AI Runner：把模型、工具链、流程和质量控制真正跑起来。

过去总有人问“现在该学哪门语言”，但在今天，这个问题已经越来越像在问“买哪支圆珠笔更重要”。

决定文章质量的，从来不是笔芯颜色，而是你脑袋里有没有提纲。

第三次打碎：商业模式开始从“卖功能”转向“卖结果”

如果你做过 ToB 或 ToG 软件，就一定知道一个很熟悉的痛点：我们嘴上说是在卖产品，实际做着做着，最后又回到了项目制。

所有人都在定制化交付的深坑里反复打转：

• 售前拼命画图；
• 售中痛苦落地；
• 售后持续救火。

而在预算普遍收紧、且“无 AI 不立项”越来越成为现实背景的今天，AI 第一次让我看到一个更真实的可能：

用标准化产品，去满足个性化需求。

这件事不是靠一句“AI 很智能”实现的，而是靠两层能力叠加起来的：

1. 软件先把最佳实践、业务规则和行业经验固化成 SOP；
2. AI 在执行 SOP 时，再根据现场条件去做自动适配。

也就是说，AI 真正有价值的地方，不是替代软件，而是让标准软件第一次有机会长出足够灵活的“万用钥匙”。

这也是为什么我越来越相信：

AI + 灵活 SOP，很可能是 ToB/G 商业软件重新走向产品化的一次真正转机。

从厂商、客户到产品本身，这个逻辑都会一起变：

• 对厂商来说，比拼点不再只是“功能做了多少”，而是行业 Know-How 沉淀得有多深；
• 对客户来说，购买逻辑不再是为“可能性”付费，而是为“确定性”买单；
• 对产品来说，它不再是一次性交付的软件，而会越来越像持续进化的结果引擎。

归根到底，客户从来不是为你的功能清单买单，而是为他节省下来的成本、提升的收入、减少的工作量买单。

PART 2 探索实践：AI 融入，从理念到实战

团队重构：我们的“AI 人力编制”

很多团队谈 AI，最后都停在 PPT 上。真正有变化的团队，一定会把 AI 从“人人都能用一下的工具”，变成“写进流程、写进职责、写进岗位说明书的编制”。

这也是我们这两年最明显的变化之一。

我们开始不再把 AI 只看作一个随手调用的助手，而是明确把它放进人力结构里，让它承担清晰的输入、输出和责任边界。

这张表真正重要的，不是“AI 替代了几个人”，而是它提醒我们：

一个任务一旦已经清楚到可以说明它的输入、处理和输出，它就很有可能正在进入被 AI 重写的边界。

人类岗位与 AI 编制协作图

实例 1：Agent-001 把“技术经理助理”这件事重新做了一遍

过去，一个 PRD 出来之后，技术经理要花很多时间理解需求、思考技术方案、拆 WBS、评估风险。这个过程不难，但很耗精力，而且标准化程度往往不够高。

现在如果把这段工作交给 Agent-001，流程会变得非常不同：

1. 产品或项目经理上传完整 PRD；
2. DeepSeek 或 Kimi 对 PRD 做结构化解析；
3. 迪科智能 / Dify 负责串联工作流；
4. 输出详细设计、WBS 任务包和风险清单；
5. 最终通过钉钉或微信推送进入评审链路。

最明显的变化，不只是更快，而是从“每次从零开始写一份文档”，变成“用标准化流程先生成 80 分版本，再由人类做 10 分钟微调”。

这样一来，技术经理真正该花时间的地方，就会回到更重要的部分：架构评审、复杂问题判断和团队资源协调。

实例 2：Agent-002 把“开发交付”推近到了“直接可部署”

第二个变化发生在开发环节。

过去从设计稿到可运行功能，中间隔着一串很长的体力活：搭架子、写页面、接接口、补单测、写文档、补 Dockerfile、准备部署。

现在，当设计稿和详细设计都已经结构化之后，Agent-002 实际上已经能把这段链路压缩得非常短。

它的工作方式大概是：

1. 接收 Figma 设计稿与详细设计；
2. 结合 Claude、Kimi、Cursor、Trae、Gemini CLI 生成代码骨架和核心逻辑；
3. 同步生成单测；
4. 自动补齐容器化所需文件；
5. 输出一个更接近“可部署结果”而不是“半成品代码”的交付物。

这会让开发人员的注意力发生明显迁移。

他们不再主要消耗在重复编码上，而会更多投入到边界处理、性能优化、复杂逻辑和最终体验上。换句话说，AI 不是让开发消失，而是把开发从流水线位置，往系统判断的位置再推了一层。

实例 3：Agent-003 让 QA 从体力活变成自动化流水线

质量保障是另一个被重写得很明显的环节。

以前测试的痛点很典型：准备环境、写测试用例、执行测试、汇总结果，周期长、重复多，而且很依赖人工稳定性。

而现在，借助“迪科智能”与“小迪数智员工”这样的组合，我们已经能把从 PRD 到测试报告的过程做成一条自动化流水线：

1. PRD 上传后由模型做结构化解析；
2. 自动生成测试用例和测试清单；
3. 自动获取测试配置；
4. 小迪数智员工执行具体测试动作；
5. 自动汇总缺陷与测试报告，并同步告警。

这类流程最有说服力的地方，不是“听起来先进”，而是它在时间上的差异往往非常残酷。

过去需要 3 小时才能跑完的一套流程，现在 AI 可能 20 分钟就能完成。更重要的是，这件事还可以在凌晨自动跑批，第二天一早团队醒来就能看到完整报告。

当测试变成“夜间自动发生的系统行为”时，QA 的职责自然就会从“执行测试”，迁移到“设计测试体系、定义质量规则、处理复杂例外”。

PART 3 产品创新：从投标助手到能力基建

智能投标助手：真正的变化不在某一个模型，而在全链路

如果把 AI 的价值只理解成“某个步骤快了”，那其实还没有真正进入业务重构层面。

对我来说，更有代表性的变化，是像智能投标助手这种全链路场景开始真正落地。

它不是只优化一个点，而是把“洞察 -> 寻标 -> 研判 -> 制标 -> 审标”整条链条都重新梳理了一遍。

尤其在审标这个环节，AI 的能力已经不是“提提建议”这么简单，而是开始具备了更完整的系统能力：

1. 行业 Know-How 可以批量注入，法规、打分表、废标案例都能进入知识底座；
2. 规则不再只是显性规则表，而能从 300 条规则扩展出大量衍生判断；
3. 超长文本的检查速度远远超过人工；
4. OCR 对卡证、合同、资质证书等非结构化材料的处理稳定性越来越高；
5. 每次实际跑批的反馈，又会成为下一轮系统优化的训练材料。

这才是我理解的“产品被 AI 重写”。

不是多了一个聊天框，而是一个本来高度依赖人工经验和耐力的行业流程，第一次拥有了可以规模化复制的自动化骨架。

能力基建：真正撑住 AI 落地的，永远不是某个热模型

很多时候，大家讨论 AI 落地时总盯着模型本身，但真正决定效果能不能稳定跑起来的，往往是底下那层并不那么性感的能力基建。

比如这些能力，几乎是很多业务场景的默认前提：

• 智能文档解析：PDF / Word -> Markdown
• 信息抽取：把长文档转成结构化 KV
• OCR：通用文字、卡证、合同、财务、资质证书识别

如果没有这层能力，很多业务数据其实根本进不了模型，也就谈不上后面的自动判断和自动执行。

所以我现在越来越相信，阻碍 AI 落地的，真正排在前面的往往不是技术本身，也不是预算，而是一种更普遍的管理心理：

“还是我自己做更快一点。”
“AI 还不够稳。”
“教它太麻烦了。”

这类想法看似务实，实际上很贵。

因为花 3 小时教会一个 Agent，如果它每周帮你省 3 小时，那么一个月就能多出接近 1.5 天，一年下来，真的是能多出一个春节假期的。

当一个任务的输入、处理和输出都已经清晰，它就不只是“可以尝试用 AI”，而是几乎注定会被 AI 改写。

PART 4 未来展望：2025 年，你到底还值钱吗？

我最近越来越常问自己一句不太舒服的话：

当 AI 能完成你 80% 的工作，你凭什么还拿 100% 的薪水？

这句话残酷，但它几乎就是 2025 年的现实。

真正的问题已经不是“你会不会用 AI 工具”，而是你的价值到底建立在什么东西上。

如果一个人的能力，只停留在“熟练使用 AI 工具”这个层面，那它很可能会经历一种非常短暂的红利期：前期提升很快，看起来很值钱，但很快就会因为工具普及而跌回平均线。

相反，那些真正理解“系统如何被重写”的人，前期学习曲线看起来更慢，但后期价值会拉得越来越开。因为他们掌握的不是一个按钮，而是一整套新的生产关系。

对我来说，2025 年之后真正升值的能力至少有三类：

• 把技术语言翻译成业务语言的能力；
• 把行业 Know-How 固化成 SOP 和系统规则的能力；
• 把模型、流程、质量和结果连接起来的 AI 工程化能力。

说得更直白一点，未来最有利润空间的组合，不是“会写 Prompt”这件小事本身，而是：

垂直行业 Know-How × AI 工程化能力

因为政企 AI 的真实难题，往往不在“模型够不够强”，而在三个更现实的障碍上：

如果一定要给今天的自己留一份行动清单，我会更愿意写这三条：

• 把 AI 嵌进你的日常流程，让它成为第一工具，而不是备用选项；
• 不要一开始就追求完美，先做到 60 分可用，快速迭代出体感；
• 把人类精力集中到那些暂时还不可替代的地方，比如行业理解、系统设计和创新判断。

结尾

2025 年，我越来越相信一件事：

如果你给不了 AI 工作，AI 就会替你工作。顺便，把你也一起优化掉。

这话听起来刺耳，但它其实不是在制造焦虑，而是在提醒我们:

AI 真正重构的，从来不只是某个岗位，而是我们看待工作的方式。

所以比“AI 会不会写代码”更重要的问题，可能是这一个：

你现在还有哪些工作，仍然在沿用过去的逻辑做事？