在当前的 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 需求分析： 理解自然语言描述的业务目标。
- AI 系分设计： 输出符合规范的技术方案。
- AI 代码研发： 完成具体逻辑实现。
- AI 自动化测试： 生成用例并执行验证。
- AI 自动化运维： 监控告警，甚至生成应急止血预案。
三、 关键技术深水区
在推进 AI 工程化的过程中，以下几个技术点是我们必须攻克的堡垒：
向量数据库与存储架构
数据是怎么存储的？向量数据库如何与传统关系型数据库配合？我们需要一种机制，让 AI 能够理解现有系统架构，并在一定业务或代码行数限制下，自动进行架构升级或代码重构（高内聚、低耦合、可扩展）。Agent 间的协作协议
如果前端有一个 Agent，后端有一个 Agent，它们之间如何通信？我们需要统一的 AI 文档输出协议。例如，当接入同学说“我在文档里写不上，我的需求是用类列表到 OB”，AI 是否能自动生成 SQL 任务并同步申请 GUC 权限？这需要打通从自然语言到数据库操作的闭环。存量业务的 AI 改造
对于庞大的存量业务领域模型，接口是字段的增删改查，还是基于组件/模块粒度的形式化需求文档？
- 难点： 存量需求变更时，如何让 AI 理解并 update 整个设计文档？
- 策略： 建立抽象整合层。无论是新增还是修改，都转化为标准的“需求文档”格式，便于维护且清晰。同时，利用 Mock 数据中心，在代码推送到 Stable 环境前，先通过 Mock 接口验证业务逻辑，确保血缘链路正确。
- 灰度发布与流量治理
AI 生成的代码上线风险如何控制？
- 场景模拟： 包含了分批部署、流量关闭、进程 shutdown、流量通过 VIP 打到其他未 shutdown 的服务器。
- 痛点： 如果有灰度概念，流量 1% -> 100% 逐步灰度，那有个问题来了，灰度没问题，线上呢？上线的分批 shutdown server 时，你的流量依旧打到了。比如代码包更新了 1 台服务器还启动了，那不是还是百分之 1 打在了新的 jar 包上，老的代码还是旧的？还是灰度完了，然后挂上上线，然后走的就是正常的流程，然后挂上下线，然后...
- 思考： 这需要 AI 具备极强的运维感知能力，理解复杂的发布拓扑。
四、 总结与展望
AI 工程化不仅仅是引入一个大模型，而是要构建一套完整的 AI 流式处理体系。
- 短期目标： 完善 AI CLI 和 AI Skill，让开发者能通过自然语言直接调用底层能力。
- 长期愿景： 实现真正的 AI Delivery。让 AI 成为研发团队中不可或缺的“数字员工”，它不仅懂代码，更懂业务、懂架构、懂运维。
这是一场关于生产力的革命。我们不仅要问“AI 能做什么”，更要问“为了让 AI 做好这些，我们的工程体系需要做哪些改变”。路虽远，行则将至。
