VINO/WANG返回博客 ←

BLOG / POST

2025 与 AI 共舞的一年

回顾 2025 年 AI Agent 的爆发，思考 AI 如何融入开发工作流以及构建业务级 Agent 的可能性。

  • summary
  • AI

2025 无疑是 AI Agent 爆发之年。从年初 DeepSeek 的破圈走红，到 Manus、Cursor、Claude Code 等一系列 Agent 产品相继面世， 伴随着 Function Call、Tools、MCP、ReAct、Skills 等关键技术范式的快速演进。几乎每一个节点，都令我兴奋不已。

前言：贯穿全年的两个问题

整个 2025 年，我始终在反复思考两个问题：

  1. AI 如何真正融入开发工作流？
  2. 我能否构建出真正可用的业务级 Agent？

为了寻找答案，过去一年我进行了大量尝试，也踩过不少坑。这篇总结，既是对这段探索历程的复盘，也是对接下来方向的一次重新校准。

一、AI 编程：实践与反思

这一年，我几乎体验了所有主流的 AI 编程工具，并深度实践了 Vibe Coding。

Vibe Coding 是 2025 年兴起的一种新型 AI 辅助编程范式。其核心在于，开发者不再逐行手写代码，而是通过自然语言描述需求，由大语言模型（LLM）生成可运行代码，开发者则专注于提出想法与验证结果。

它在短时间内确实能大幅提升编码速度，但在真实工程环境中，往往难以达到预期效果。这也是为什么很多人认为 AI 编码仍停留在“玩具”阶段。

我遇到的一些典型翻车场景：

  1. 上下文缺失导致的错误抽象
    在现有代码基础上迭代新功能时，AI 在不了解完整业务背景与技术架构的情况下，容易创建“看似优雅、实际多余”的抽象层。

  2. 代码风格不一致
    同一模块中，AI 在不同时间生成的代码风格可能迥异，破坏整体一致性。

比如，组件中一部分使用箭头函数与解构赋值，另一部分却是 function 声明和传统赋值，就像两个不同开发者在不同时期写的代码拼凑在一起。

  1. 技术债的隐性堆积
    功能短期内看似可用，但长期维护成本显著上升，尤其在边界条件与异常处理上。

Vibe Coding 暴露的核心问题

  1. 代码不可控
    AI 常会“自作主张”补充逻辑，甚至脱离上下文随意发挥，给后续维护埋下隐患。

  2. 难以符合团队技术规范
    无论是项目结构、命名约定，还是内部工程规范，AI 往往无法天然对齐。

  3. 无法感知内部沉淀
    公司内部封装好的组件、业务流程、中台能力等，本是提效关键，但对通用大模型来说几乎是“盲区”。

当前最有效、可推广的 AI 编程工作流

在不断试错后，我阅读了大量社区关于AI编程的技术文章，并开始纠错实践。 我探索到：问题不在于 AI 不够聪明，而在于我们的工程体系本身并不“AI 友好”。 因此，我开始转向改造框架，让 AI 在约束下输出可靠代码。

将前端基础框架升级为「AI 友好型框架」

我正在做的一件事，是把公司内部的前端基础框架，系统性地改造成 AI Friendly Framework。

  1. 为框架添加 Agents.md
    Agents.md 本质上是“给 AI 看的项目开发说明书”，为 AI 提供稳定、明确、可执行的项目级上下文与行为约束，内容包括：

    • 项目概述
    • 构建与测试命令
    • 代码风格指南（约束 AI 生成符合内部规范的代码）
    • 核心原则（如 KISS 原则：保持简单，避免过度设计）
    • 私有化组件说明

  2. 业务组件本地化

    • 将以往通过 npm 发布的私有化组件转为本地源码，让 AI 能直接读取并理解使用方式。
    • 聚焦标准化场景，沉淀业务场景代码块(Block)，如“管理后台 CURD 页面”、“钉钉免密登录逻辑”、“数据大屏”等。
    • 为内部组件提供结构化文档，明确告知 AI 各组件的职责、示例代码与推荐组合方式。

  3. 先规划，再构建
    对于复杂功能，首先让 AI 制定编码计划，经人工矫正确认符合要求后，再进入 Build 阶段。例如：

    • 拆解页面结构与模块职责
    • 明确需使用的内部组件与公共能力

相比与前端我认为这套方法更适合后端编码，原因在于后端的开发流畅和逻辑更为固定。而前端还有个难点在于对于页面样式的百分百还原还存在一定的问题，未来或许可以开发一个类似于低代码拖拉拽的AI对话形式来进行样式的微调。

二、AI Agents 的真实落地尝试

业务向 AI 助手开发实践

我曾尝试在真实业务中落地一个 AI Agent：

构建一个可对话的 AI 助手，让资产管理员通过自然语言完成一系列资产操作。

结论是：这次尝试未能成功。 但它让我看清了当前业务 Agent 落地的实际阻碍。

关键问题

  1. 业务流程复杂且强依赖审批
    核心流程涉及多级审批，而审批链路不在我们产品内，导致 AI 执行难以闭环。

  2. 存量系统的技术债
    旧代码质量与架构限制，使得对接 Agent 时需要大量“打补丁”式改造。（我个人更倾向在 AI 辅助下进行重构与编排，这样长期成本更低。）

  3. 技术之外的信任问题
    用户是否愿意将资产数据交给大模型？即便厂商强调数据安全，在企业场景中仍是现实阻力。（我认为可将选择权交给用户，让其自行部署模型或选择可信第三方。）

阶段性结论

  1. 业务型 Agents 目前门槛仍高
    与其强推，不如先从简单的 AI 套壳应用入手，验证基础价值。

  2. 优先构建可控的工作流，而非“全自动智能”
    AI 更适合作为流程中的一环，处理重复性任务，而非全权代理。

  3. 暂时避开高数据敏感场景，尝试 ToC 方向
    在约束更少的场景中打磨能力与产品形态。

三、项目开发平台（进行中）

基于以上反思，我开始了新的尝试：ArkMind 项目开发平台。

这是一个面向开发者的 AI 应用平台，目标是从需求描述出发：

  • 自动生成数据库设计
  • 进一步生成接口定义
  • 为 AI 提供完整、结构化的编程上下文
  • 输出符合工程规范且可控的代码

我希望实现的理想场景是：在一次项目需求会议结束后，能直接产出数据库设计、接口设计及前端页面，形成一个可运行的最小 MVP 版本。

写在最后

现阶段，我的看法是：

AI 尚不能取代程序员，但不会使用 AI 的程序员，正在快速失去竞争力。竞争的焦点已从“会不会写代码”转向“能否高效驾驭 AI，持续放大个人产出”。

AI 正在系统性地重塑开发工作方式。在其加持下，构建 MVP、验证想法、试错迭代的成本大幅降低，开发重心从“重执行”转向“重决策”。

AI 时代也在淡化传统的角色边界。产品、前端、后端、低代码之间的界限日益模糊。新一代开发者不应只是“需求实现者”，而需同时具备产品理解力、系统抽象能力与工程落地能力。

在这样的背景下，若只沉浸于“纯技术深度”的单一叙事，反而可能局限视野。主动扩展认知边界、提升综合判断力，正成为比单点技术能力更重要的长期竞争力。

2026 年，我希望能更多地去 Build，接触更广阔的领域，学习跨学科知识，减少内耗。在实践中学习，在迭代中修正方向。

完。

（初稿写于 12 月 16 日凌晨 3 点，在给孩子换完尿布后无法入眠。）