01 / 25

深圳架构师城市沙龙 · 技术大会分享

AI 原生范式

AI原生：解构从 PRD 到研发部署全流程范式

把研发重写成 AI 可以稳定参与、可编排、可验证、可观测的生产系统。

问题 AI 手替很强，但企业研发结构并没有真正准备好。

判断真正的壁垒在约束、编排、验证、部署与资产化闭环。

主角 Zmagine 平台向上承接 PRD，向下由 ZFlow 编译与运行底座托住。

讲师

乔卓越 Zmagine AI 创始人 AI 研发架构师

本场主线

1

旧路线边界

为什么从氛围编程、Spec 到 Harness 仍然没有带来企业级质变

2

AI 编译系统

为什么要引入编译、运行时、契约、治理和 GitOps 闭环

3

真实平台主线

用企业邮件智能回复案例，走完 PRD 到上线的完整链路

“生产系统决定 AI 研发的最终上限。”

02 / 25

关于我 · 技术面

企业级后端、架构、云原生、AI 工程化。

2019 → 2026

基础设施 / 游戏业务 / 企业 AI 平台

腾讯云架构师同盟海报 — 腾讯云架构师同盟：云原生、后端架构与复杂系统交付，是我今天这场分享的方法论起点。

履历时间轴

2026

创办 Zmagine研发企业 AI 应用的大脑平台 / 新媒体影响力建设

2024

字节跳动 · 后端技术负责人AI 工程化实践 Top 1% 纪录保持者

2022

腾讯游戏 · 云原生架构师主导腾讯游戏上云自动化交付体系

2021

InfoQ 编辑推荐 / 极客时间签约讲师限流、云原生、Go 语言课程与工程实践输出

2020

网易游戏 · 高级后端研发梦幻西游

2019

YY 语音 · 后端研发基础架构部

从基础设施、游戏业务到企业 AI 平台，我长期处理的都是复杂系统如何稳定落地。

03 / 25

字节实践

团队内容榜单第一，AI Agent 工程化已经跑进真实业务现场。

团队内容榜单第一

内容影响力 > 99%

实践成就

Top 1%

AI Agent 工程化实践验证

内容榜单

第一

团队内容榜单第一

影响力

> 99%

内容影响力覆盖率

04 / 25

关于我 · 艺术面

工程能力进入创作现场，创作表达反过来要求工具真正能落地。

影像表达

纪录片创作

AI 辅助创作

陕西省大学生联赛亚军 — 长期参与舞台与影像表达训练，让我做展示时更重节奏与现场感。

AI 登月：致敬两代人 — 《AI登月：致敬两代人》：技术之外，也要处理人、情感与表达。

05 / 25

问题抛出

AI 会写代码了，为什么企业研发还是焦虑？

今天真正卡住团队的，是复杂系统里的正确性、边界、依赖、状态、回归和长期可维护性。

生成看起来很强

局部代码、脚本、页面、测试都能快速生成，单点体验很爽。

系统协同还是散的

PRD、设计、研发、测试、部署、观测仍然被拆成多条断裂的工具链。

组织并没有被重写

多数团队只是把 AI 叠加到原流程上，流程本身还没有完成结构化重写。

AI 会写代码，不等于 AI 已经能接住企业研发系统。

06 / 25

现有路线

从 vibe coding 到 SDD，再到 Harness，大家都在进步，但还没有形成真正的研发底座。

阶段 1

Vibe Coding

会话式生成很强，胜在快，但上下文一大就容易失控。

阶段 2

SDD / Spec IDE

规约更清楚，输入更稳定，但系统后段仍然是散的。

阶段 3

Harness / Skills

开始复用经验和能力包，但大多数还停留在增强个人效率。

阶段 4

Agent Programmer

自动执行单任务越来越强，但长期治理、状态和资产化仍是短板。

今天很多路线是在增强 AI 写代码的能力，但企业真正缺的是一套能接住 AI 的研发结构。

07 / 25

企业痛点

企业真正卡住的，是这六类复杂度始终没有被系统吸收。

正确性

结果能否持续验证，决定它能不能进入生产环境。

复杂度理解

超过一定规模后，AI 和人都会丢失对整体依赖的把握。

依赖与边界

服务、模型、SaaS、配置、团队协作边界经常被调用链冲穿。

状态与并发

异步、长流程、消息、回调、流式交互很难讲清，也很难稳定跑。

验证与回归

生成之后谁来兜底、谁来回放、谁来复盘，这是生产级问题。

资产化协作

团队需要可复用、可审计、可迁移的长期资产。

08 / 25

核心判断

把该沉淀成软件的部分沉淀成软件，让 AI 进入清晰、受控、可复用的执行结构。

软件沉淀

把重复劳动沉淀成 CLI、unit、模板、规则和运行时，持续复用。

上下文缩小

用契约、蓝图、step 边界，把 AI 的工作颗粒度压缩到能稳定完成的范围。

分工明确

人负责顶层结构与决策，AI 负责小规模高价值复杂度，两者都做最擅长的事。

真正的生产力来自软件、运行时、资产和流程的持续固化。

09 / 25

S.U.P.E.R 设计哲学

AI 原生系统先把结构做对，再把智能放进去。

S · Single Purpose

每个模块、每个文件、每个 step 只解决一个问题。

U · Unidirectional Flow

输入 → 处理 → 输出，禁止反向依赖和循环调用。

P · Ports over Implementation

先定义契约、接口和 Schema，再写实现。

E · Environment-Agnostic

配置外置、日志标准化、同一份能力能跑在本地和云端。

R · Replaceable Parts

模型、数据源、前端、推送渠道都应该可替换。

一句话理解

像搭乐高一样构造系统：职责单一、接口标准、方向明确、环境无关、随时可换。

10 / 25

系统全景

Zmagine AI 编译系统总览

邮件案例完整版

需求 → 蓝图 → 运行 → 交付

11 / 25

主线案例

主线案例：企业邮件智能回复

mail_id → 结构化回复草稿

完整链路

12 / 25

邮件例子

一个邮件需求，会先收成 entry，再展开成一条明确的 flow。

PRD → entry → flow → steps

邮件回复主线

13 / 25

YAML / 注释

执行图会落成一份 entry / flow / steps 蓝图。

entry / flow / steps

依赖声明 / 数据流转

entry

entry:

name: inbox_reply_entry

flows:

customer_reply_flow:

default: true

flow

flow:

name: customer_reply_flow

parallel_execution: false

steps / 1

steps:

open_thread:

inputs:

thread_ref: { from: req::thread_ref }

outputs: [thread_body, file_handles]

scan_files:

dependencies: [open_thread]

outputs: [has_files, file_handles]

stage_files:

dependencies: [scan_files]

outputs: [cached_files]

steps / 2

digest_files:

dependencies: [stage_files]

inputs: [cached_files]

outputs: [file_digest]

compose_reply:

dependencies: [open_thread, digest_files]

inputs: [thread_body, file_digest, review_rules]

outputs: [reply_draft, review_marks]

package_reply:

dependencies: [compose_reply]

inputs: [reply_draft, review_marks]

outputs: [reply_subject, reply_body, citations]

入口挂载 / 主链

`entry` 把入口请求挂到 `customer_reply_flow`，`flow` 负责声明这条主链按顺序推进，并把 `parallel_execution = false` 固定下来。

step 契约 / 数据流

每个 step 都把 `inputs / outputs` 摊平写进蓝图：线程正文、文件摘要、审阅标记和最终回复沿依赖链逐段传递。

14 / 25

抽象代码样例

unit 只暴露一个最小运行面。

Unit 接口

无状态 / 可替换 / 易测试

抽象代码样例

Unit 消化局部输入，flow 负责推进路径。

// 智能 unit：无状态、可复用的处理单元
type Unit interface {
    Run(ctx context.Context, inputs map[string]any) (map[string]any, error)
}

// ComposeReplyUnit：把线程正文与文件摘要汇聚成回复草稿
type ComposeReplyUnit struct{}

func (u ComposeReplyUnit) Run(ctx, inputs) (...) {
    draft := composeReply(thread_body, file_digest)
    return {"reply_draft": draft, "review_marks": inspect(draft)}, nil
}

unit 很薄

`Run()` 只处理当前 step 这一次输入输出，不承接全局调度。

step 的输入 / 输出

open_thread：req::thread_ref → thread_body、file_handles
digest_files：cached_files → file_digest
compose_reply：thread_body、file_digest、review_rules → reply_draft、review_marks

路径与测试更直接

调度器依据依赖关系计算 ready step；unit 只看 `inputs`，单测、集成测试和替换都更直接。

15 / 25

执行示例图

一次邮件执行，会沿着这条路径走完整个关键链路。

entry → flow → steps

邮件执行主线

16 / 25

分层对应

把编排层单独抬出来，入口、编排、unit 和运行时就各归其位。

入口 / 编排 / unit / 数据 / 运行时

分层对应

常见后端分层

Service 入口层

承接请求入口、参数校验和路由。

BIZ 业务编排层

串联业务流程、依赖顺序和分支策略。

DATA / Gateway / Repository

访问数据库、文件、RPC 和外部网关。

Infra / Common

承接状态、日志、策略、可观测与通用能力。

入口承接

编排承接

局部动作

运行治理

Zmagine / ZFlow 对应

Zmagine Entry / Service

承接入口、参数与路由，把请求送进结构主线。

ZFlow Flow / Step

承接业务编排、依赖关系、分支与执行顺序。

Unit

承接局部领域动作，内部调用 Repo / Gateway / RPC。

Binding / State / Policy / Observability

承接状态、回放、策略与运行时治理。

结构拆开之后：入口、编排、局部动作和运行治理各归其位，迁移和维护时不会再全部挤在同一层里。

17 / 25

局部上下文与测试

AI 只处理局部任务，流程仍可回放，每个 unit 都能独立验证。

局部上下文 / unit 测试

回放 / 闸门 / 发布

① 局部输入

thread_body线程正文与历史往来摘要

file_digest[]文件抽取文本与整理后的摘要

review_rules客户等级、风险标签与人工确认要求

② 每个 unit 都能独立测试

open_threadunit / contract

digest_filesunit / replay

compose_replyintegration / safety

package_replysnapshot / schema

③ 可复现流程

blueprintbp-8f4c31

replay samplesmail-reply-regression-07

release gatestaging → canary → prod

trace_idREQ-2026-0417-EM-118

同一条证据链

蓝图版本

样本回放

发布闸门

放量记录

18 / 25

平台落点

平台把录入、追踪、放量和回放收进同一块工作台。

关键工作台截面

录入 / 追踪 / 放量 / 回放

1

录入：需求进入平台，但不再以聊天记录的形式继续漂移。

2

追踪：蓝图、测试、发布和运行状态在同一张工作台上连起来。

3

放量：灰度、金丝雀和回滚只呈现必要控制面。

4

回放：问题定位回到证据链，不回到“重新猜一遍 Prompt”。

19 / 25

底座必要性

为什么中间必须有一层 ZFlow？

正交 / 局部性 / 契约 / 可运行

复杂度吸收层

20 / 25

定位对比 A

现有路线正在往“结构时代”迁移，但所处层次并不相同。

定位图

自动执行 vs 结构承载

Skill / Spec Kit

更偏增强 AI 的技能与表达能力，重点在局部任务组织。

Agent Programmer

自动执行越来越强，但长期治理和团队资产沉淀仍然是难点。

结构底座路线

真正开始碰系统级结构、全流程联动和企业级治理闭环。

21 / 25

定位对比 B

为什么 Archon 值得作为开源路标？

它证明了结构层正在成为开源世界的新焦点，单体 prompt 和单体 coding agent 已经不够覆盖整条研发系统。

GitHub 18.5k stars

workflow engine for AI coding agents

Archon 的 YAML 在编排研发活动

Archon 是一个面向 AI coding agents 的工作流引擎，用结构化流程承接计划、实现、审批与反复迭代。

steps:
  - id: plan
    prompt: "先分析代码并输出计划"

  - id: implement
    depends_on: [plan]
    loop:
      prompt: "实现下一步并运行校验"
      until: ALL_TASKS_COMPLETE

  - id: approve
    depends_on: [implement]
    loop:
      prompt: "展示结果并等待人工审批"
      until: APPROVED

它证明了结构层已经成为开源社区从工具走向系统的关键一步。

Archon 证明了什么

研发流程的结构组织，本身就是一个独立问题。

两者的关系

两者指向同一方向，但关注层次和承接范围不同。

Zmagine 更强调什么

PRD 到部署的全流程范式、编译控制层、运行治理与 GitOps 一体化。

Archon 是一个重要的开源路标，而 Zmagine 想走的是更完整的 AI 原生研发系统路线。

22 / 25

边界与真实难点

真正难的地方，集中在迁移、治理和持续运行。

1

认知成本高：抽象设计、编排思维、运行治理都需要工程经验。

2

迁移有代价：通常需要不兼容隔离、灰度和双轨切换。

3

持续运行型任务更难：并发、异步、长流程和状态语义仍然需要持续演进。

4

安全与合规不可跳过：越是自动化，越要重视审计、追踪和边界。

5

这也正是价值所在：因为它试图吃掉的，恰恰是企业研发里真正难的问题。

边界说得越清楚，系统就越接近真实生产环境。

23 / 25

引擎模块与开发路径

Zmagine / ZFlow 的开发，要同时处理编排、运行时、性能与模型策略。

引擎模块

模型与商业路径

ZFlow 核心模块

编排与规划

Parser、Planner、flow 数据结构、QoS 校验，负责把蓝图编译成可执行计划。

调度与运行时

Scheduler、Executor、Binding、State、ControlRoute，把依赖关系推进成真实执行路径。

策略与质量

Retry、Timeout、Policy、QoS、Branch Control，保证 step 失败、分支和服务质量可治理。

性能与观测

Plan 缓存、StructBind、并发执行、Trace / Observability，让引擎既能跑得快，也能回放和排障。

开发时要考虑的环节

1

前沿模型辅助引擎开发：用 Claude Code 与 Opus 4.6 级别前沿模型处理接口设计、运行时抽象、调度与性能细节。

2

业务 unit 逐步迁移：做业务流、研发流、AI flow YAML 和 unit 开发时，约束一旦稳定，就可以逐步迁到高性价比国产开源模型。

3

开发不只写功能：还要同时考虑状态、并发、重试、回放、审计、trace、发布闸门和后续迁移成本。

模型分层

高难抽象阶段用最强模型，稳定 unit 逐步切向高性价比模型。

开闭源协同

底座、unit 资产、业务模板和平台能力可分层开放。

商业化路径

引擎、平台、企业定制与托管运行仍在持续验证。

24 / 25

展望

下一步，是把这套结构继续推向开源、长流程和更广的产业场景。

2025.07

ZFlow 开源

关键时间点

1

2025 年 7 月：ZFlow 引擎计划启动开源，先开放核心编排、调度、运行时与基础 unit 能力。

2

下一阶段：继续补全 Unit 开发体验、回放链路、观测能力与平台侧集成。

3

更远一步：扩展到更长异步流程、更多行业场景和组织级资产化路径。

开放方向

开源底座

开放引擎核心，降低结构化编排和运行时治理的接入门槛。

平台延伸

平台继续承接 PRD、测试、发布、回放和多环境运行治理。

模型协同

前沿模型承担高难抽象，稳定 unit 逐步迁向更高性价比模型。

25 / 25

结尾判断

带走的，是一种新的研发组织方式。

01

AI 手替会越来越强，生产系统决定最终上限。

02

真正的壁垒来自约束、编排、验证和资产化。

03

Zmagine 代表从 PRD 到部署的 AI 原生研发范式。

分享收束

软件工程的竞争，会越来越集中在谁能把复杂系统编译成可持续运行的生产结构。

这条路线还会继续延伸到更长异步流程、更多行业场景和组织级资产化路径。

Q

欢迎追问

异步 / 流式 / 灰度迁移 / 开闭源模型 / 商业模式

26 / 26

附录 · GitOps 云原生部署

项目组自维护的 GitOps 全局形态

代码仓和部署仓分层协同，项目组围绕 Git 证据链自维护研发、发布、回滚与环境变更。

2024

我在腾讯游戏上云范式设计与落地

代码仓与部署仓分层协同，项目组可以围绕 Git 证据链自维护研发、发布、回滚与环境变更。

27 / 27

附录 · GitOps 云原生部署

基于 ArgoCD 的大规模应用管理

基于 AppSet、模板和 values，ArgoCD 可以把多环境、多应用、多集群的发布关系收进统一控制面。

2024

我在腾讯游戏上云范式设计与落地

基于 AppSet、模板和 values，ArgoCD 可以把多环境、多应用、多集群的发布关系收进统一控制面。

28 / 28

交流与联系

Thanks

AIGC 欢迎技术交流

微信扫码添加，AIGC 欢迎技术交流