📅 发布时间：2026/7/31 19:10:40

AI工程 V0.2--从Coding到Delivery的全链路重构及思考

　　在当前的 AI 浪潮下，我们正处于从单纯的 AI Coding（辅助写代码）向 AI Delivery（全链路交付）转型的关键时期。这不仅仅是工具的升级，更是研发范式、协作模式乃至架构设计的深刻变革。本文基于近期的探索与实践，梳理了我们在 AI 工程化落地过程中的核心思考与技术痛点。

一、现状与挑战：大模型应用的“最后一公里”

目前我们已经初步实现了 JSON 解析等基础能力，可以通过 Prompt 生成所需的数据格式，但这仅仅是冰山一角。面对复杂的业务场景，我们面临着几个灵魂拷问：

非结构化数据的处理：现有的数据库多为结构化或列表式存储，而向量数据库虽然解决了语义检索问题（如 A->B 的指向性），但在实际工程中，如何将海量存量数据高效转化为向量并存储？
Prompt 工程的标准化：现在的 Prompt 往往是一个黑盒。如何将其转化为标准化的组件？是否可以将“提示词”本身封装为一个可复用的行业模块，只要数据存在，就能定向指定某个行业的需要？
关键词匹配的智能化：传统的关键词匹配太生硬。我们希望实现的是：用户说几句话代表同一个意思，AI 能提取出关键语义，甚至通过历史专家的操作记录（如代码库 787 行）来自动判断并补充上下文，实现“特性的自动生成”。

二、核心概念重塑：从 AI Coding 到 AI Delivery

我们需要重新定义 AI 在研发中的角色。

旧范式（传统研发）：产品痛点收集 -> 需求分析 -> 系分设计 -> 代码研发 -> 自动化测试 -> 发布部署。
新范式（AI Delivery）：这是一个自上而下的任务传递式协作（类似数马 & 集团用工角度）。AI 不再只是写代码的工具，而是具备“理解需求”、“生成系分文档”、“跨物种协作”能力的智能体。我们的目标是打造 “1+N” 的组织效能——即 1 个核心人类专家 + N 个 AI 助手。

在这个新范式中，AI 的角色贯穿全流程：

三、关键技术深水区

在推进 AI 工程化的过程中，以下几个技术点是我们必须攻克的堡垒：

向量数据库与存储架构
数据是怎么存储的？向量数据库如何与传统关系型数据库配合？我们需要一种机制，让 AI 能够理解现有系统架构，并在一定业务或代码行数限制下，自动进行架构升级或代码重构（高内聚、低耦合、可扩展）。
Agent 间的协作协议
如果前端有一个 Agent，后端有一个 Agent，它们之间如何通信？我们需要统一的 AI 文档输出协议。例如，当接入同学说“我在文档里写不上，我的需求是用类列表到 OB”，AI 是否能自动生成 SQL 任务并同步申请 GUC 权限？这需要打通从自然语言到数据库操作的闭环。
存量业务的 AI 改造
对于庞大的存量业务领域模型，接口是字段的增删改查，还是基于组件/模块粒度的形式化需求文档？

难点：存量需求变更时，如何让 AI 理解并 update 整个设计文档？
策略：建立抽象整合层。无论是新增还是修改，都转化为标准的“需求文档”格式，便于维护且清晰。同时，利用 Mock 数据中心，在代码推送到 Stable 环境前，先通过 Mock 接口验证业务逻辑，确保血缘链路正确。

场景模拟：包含了分批部署、流量关闭、进程 shutdown、流量通过 VIP 打到其他未 shutdown 的服务器。
痛点：如果有灰度概念，流量 1% -> 100% 逐步灰度，那有个问题来了，灰度没问题，线上呢？上线的分批 shutdown server 时，你的流量依旧打到了。比如代码包更新了 1 台服务器还启动了，那不是还是百分之 1 打在了新的 jar 包上，老的代码还是旧的？还是灰度完了，然后挂上上线，然后走的就是正常的流程，然后挂上下线，然后...
思考：这需要 AI 具备极强的运维感知能力，理解复杂的发布拓扑。

四、总结与展望

AI 工程化不仅仅是引入一个大模型，而是要构建一套完整的 AI 流式处理体系。

　　这是一场关于生产力的革命。我们不仅要问“AI 能做什么”，更要问“为了让 AI 做好这些，我们的工程体系需要做哪些改变”。路虽远，行则将至。