难度★★☆☆☆ ⏱️ 阅读时间15 分钟 前置知识模块一~六说明从本章开始AI Native Engineering 从方法论进入实战。我们将用一个标准电商系统NovaMart作为主线项目从一张 SSD 规格文档出发经过 9 个 Git tag、11 天开发周期串联起此前全部方法论。本章是这个实战系列的全局导航。⚠️教学演示声明NovaMart 项目及其开发数据含效率指标、代码量、交付周期为教学设定的示范场景旨在展示方法论在可控条件下的运转方式。所有效率数字均为设定值而非真实项目实测读者在参考时应代入自身团队参数重新估算不宜直接作为投资回报论证的依据。行业映射Multi-Module Project Architecture · Git Tag-Driven Development · Technical Debt Prevention排他职责主线项目全局视图——完整架构说明、Git tag 索引、各实战篇对应的方法论模块、三条阅读路径、技术栈决策说明。导流去向方法论章节自行回看 → 对应篇章按实战篇标注的具体索引实战起点必通关→ 第 28 篇SSD 规格定义与任务拆解一句话理解不是看 10 个 Demo是 1 个电商项目跑通全链路。 本文产出主线项目架构图7 大模块依赖关系 分层结构Git tag 索引表9 个 tag × 对应内容 × 建议工期技术栈决策说明含 5 条 ADR 摘要覆盖选型权衡全过程 商业价值一个 10 人以内研发团队从 0 搭建标准电商系统的常规周期是 40-60 天。按本系列方法 11 天实战链路首版可运行代码的交付窗口可以压缩到 11-15 天——省出来的不是编码时间而是「需求反复澄清→技术选型争论→集成时发现不兼容」这三类典型浪费。11 天跑通全链路的实战记录本身就是这个系列方法论有效性的证明。“方法论我都看了但从哪里开始”这是 AI Native Engineering 系列开场至今最常收到的读者反馈。00-26 章构建了一个完整的理论体系从工具选型到需求规格、从编码 Agent 到三闸门、从知识工程到最小修复原则——18 篇方法论覆盖了 AI 辅助开发的全流程。但方法论是散装的零件缺一个把它们组装成整车的总装手册。本章就是那本总装手册。接下来 11 篇主线实战文章会完整记录一个电商系统的开发过程从 SSD 规格文档起步经过 9 个 Git tag、11 天开发周期跑通从 proposal 到部署的全链路。本章只做三件事告诉你为什么选这个项目、整个系统长什么样、以及接下来怎么读。一、为什么是电商系统选一个贯穿全系列的主线项目时有三个硬性要求。第一功能复杂度要适中且典型。太简单体现不出 AI Native Engineering 的优势——一个 CRUD 后台十分钟就写完犯不着上全套方法论。太复杂又会把读者的注意力从「AI 开发流程」拉到「业务规则理解」。电商系统恰好落在黄金分界线上它是 CRUD 业务规则 状态机的典型代表。订单状态流转、库存扣减并发、支付退款流程——这些场景足够展示 AI Agent 在多模块协作时的真实表现又不至于让读者花太多时间理解业务。第二方法论覆盖度要全。项目要能形成从需求到部署的完整 SDLC 闭环。对比一下电商系统和其他常见项目类型对 AI Native Engineering 各环节的覆盖环节电商系统CRUD 后台简单工具 CLI需求 Agent SSD✅ 复杂✅ 简单⛔ 极简编码 Agent 审查✅ 7 模块✅ 2-3 页⛔ 单文件多模块协作冲突✅ 依赖链⛔ 单体⛔ 无状态机与事务✅ 订单⛔ 无⛔ 无测试 Agent✅ 集成✅ 单测❌ 可跳过Docker 部署✅ 多服务✅ 单体⛔ 无电商是唯一能覆盖所有方法论模块的项目类型。不是说其他项目不能用——但它们都有方法论断层每个断层就意味着有一篇文章看完了用不上。第三读者群体要共鸣。电商的逻辑链选商品→加购物车→下单→支付→等收货→评价是每个技术人都熟悉的。不需要额外解释业务背景读者可以集中在「AI 是怎么把这套逻辑编码出来的」上。这三个条件叠加选择电商系统不是偏好是必然。二、技术栈决策的 5 条 ADR技术栈选型不是拍脑袋每条决策都有明确的上下文和替代方案。以下是主线项目中最重要的 5 条架构决策记录后端 Spring Boot 3.2.5虚拟线程高并发订单接口Jakarta EE 命名空间迁移AOT 预留GraalVM 兼容数据库 MySQL 8.0Snowflake ID替代自增主键RC 隔离级别避免间隙锁前端 Vue 3.4.xComposition APIAI D2C 友好Vite HMRAgent 闭环提速ADR 1Spring Boot 3.2.5 而非 2.7.x选用 Spring Boot 3.x 的核心原因是虚拟线程Project LoomJDK 21 起可用Spring Boot 3.2 起可通过spring.threads.virtual.enabledtrue一键开启 官方文档。电商高并发场景下订单和支付接口的吞吐量是核心指标。虚拟线程将 Java 的并发模型从「线程池 阻塞」降到「轻量级虚拟线程 挂起」在 I/O 密集型场景下同硬件配置的吞吐量有明显提升空间 推断具体倍数因业务而异不宜套用固定数字。代价是必须从 javax.* 迁移到 jakarta.*命名空间Jakarta EE 9 起的规范变更 官方文档——这是一次性的迁移成本但对老项目来说不可忽视。项目中已全部完成迁移。替代方案评估Spring Boot 2.7.x 生态更成熟、第三方库兼容性好但缺少虚拟线程支持且社区支持窗口已收窄。选 3.2.5 是面向未来的决策。ADR 2Snowflake ID 而非自增主键自增主键在单库单表下性能最好但电商系统天然需要分库分表——订单数据按时间分片、用户数据按 ID 取模——自增主键在分片场景下会有冲突。Snowflake ID 在应用层生成全局唯一 ID不依赖数据库自增能力天然支持分片。代价是 ID 长度更长64 位 BigInt以及需要引入 ID 生成器组件。本项目中 ID 生成器是一个轻量的单例使用默认数据中心的机器 ID 配置。替代方案评估UUID 也可以全局唯一但 36 字符的字符串作为主键对索引性能影响明显尤其在订单表千万级数据量时排序和分组查询会变慢。ADR 3MySQL RC 隔离级别而非 RRMySQL 默认隔离级别是 REPEATABLE READRR电商场景推荐切换到 READ COMMITTEDRC原因只有一条间隙锁。RR 级别下InnoDB 会在索引记录之间加间隙锁防止幻读电商系统高频交易场景间隙锁容易引发死锁。切换到 RC 级别后间隙锁消除死锁概率明显下降。代价是需要接受不可重复读——但在金融级支付以外的大多数电商场景中不可重复读不是一个致命问题。替代方案评估完全不用间隙锁意味着在分布式场景下可能需要乐观锁或应用层重试补偿本项目已在订单模块中通过状态机处理这类场景。ADR 4Vue 3 Composition API 而非 Options API选 Composition API 不只是版本升级它是 AI 友好度的选择。Composition API 允许按逻辑组织代码比如把所有和「购物车」相关的状态、计算属性、方法聚合在一个useCart()函数里AI Agent 在生成这类代码时上下文更集中、约束更明确。对比 Options API 下 data/methods/computed 分散在三个块中AI 需要跨块理解完整逻辑才能准确生成代码。Vue 3 的 Proxy 响应式机制在处理多层嵌套对象时比 Vue 2 的Object.defineProperty开销更小 Vue 官方文档配合 Vite HMRAI 生成代码后的即时反馈循环更短。ADR 5单体架构而非微服务这是一个教学决策而非技术决策。单体架构足够承载电商系统的 7 个模块还能让读者专注于理解「Agent 交互逻辑」而非「服务发现和配置中心」。微服务引入的分布式事务、服务调用链追踪、配置中心等复杂性会稀释 AI Native Engineering 的教学目标。如果你在实际项目中需要微服务本系列支付集成与物流集成展示的 Temporal 工作流编排可以作为拆微服务的起点——这些模块已经是按照微服务边界设计的。三、七大模块架构总览整个电商系统由 7 个业务模块组成以下图展示它们的依赖关系M01 商品管理M03 购物车M04 订单管理M07 评价系统M02 用户认证M05 支付对接M06 物流跟踪层次说明基础层绿色商品M01和用户M02是业务基座不依赖其他模块。这两个模块在 AI 编译修复的最小修复原则、主线项目索引与架构总览、主线一规格驱动 这三章完成。交叉层橙色购物车M03依赖商品和用户。通过 Redis 缓存购物车数据是典型的缓存套数据库模式。核心层红色订单M04是系统的交通枢纽依赖商品、用户、购物车。订单状态机在主线三前端模块 D2C 生成、主线四AI 安全合规落地 这两章完整实现。外围层蓝色支付M05、物流M06、评价M07都依赖订单彼此独立。数据库关系核心表是理解这个架构的另一条线索。user → cart → cart_item形成购物车链order → order_item形成订单链。order同时关联payment、shipping和order_log。product作为商品实体同时被cart_item和order_item引用——这是订单数据快照的关键设计订单生成时复制商品的当前价格信息而不是实时查询价格。四、9 个 Git tag 与 11 天工期映射每个 Git tag 对应一个可独立运行的代码里程碑。Tag 的编号方式遵循v主版本.次版本-模块模式方便按模块 checkout。06-0106-0206-0306-0406-0506-0606-0706-0806-0906-1006-1106-12v0.1-spec (SSD 48 任务)v0.2-product (商品模块)v0.3-user (用户认证 JWT)v0.4-cart (购物车 Redis)v0.5-order (订单状态机)v0.6-payment (支付对接)v0.7-shipping (物流跟踪)v0.8-review (评价系统)v1.0-final (集成 部署)设计期核心编码业务编码集成编码收尾电商实战 11 天工期Tag 速查表Tag对应篇章交付物工期v0.1-spec28全量规格文档 48 原子任务Day 1v0.2-product29商品模块代码 AI 审查报告Day 2v0.3-user30-31用户认证 JWT 权限控制Day 3-4v0.4-cart32购物车 Redis 集成Day 5v0.5-order33-34订单状态机 分布式事务Day 6-7v0.6-payment35支付对接接口 退款流程Day 8v0.7-shipping36物流轨迹模拟器Day 9v0.8-review37评价系统 评分聚合Day 10v1.0-final38全链路集成测试 Docker 部署Day 11方法论→实战映射每个 Git tag 背后都对应具体的方法论落地。这是本系列和其他电商教程的核心区别方法论文章主题实战文章实战落地09-10需求 Agent SSD28Proposal → 48 任务拆解11-12三闸门28-29提案确认 功能点验收13-14编码 Agent29商品模块自动代码生成15-16审查 Agent29java-reviewer 自动化审查17-18修复 Agent29最小修复原则的实际案例19-20测试 Agent29-34单测 集成测试自动生成21-22Temporal 流水线28-38Workflow 编排贯穿全流程23-24多人协作30-34并行开发中的冲突处理25-26持续交付 部署38Docker 全链路部署核心逻辑阅读每个实战篇之前先看一眼这个映射表——你在实战中看到的每一个 Agent 操作都会在前面的方法论篇章中找到它的设计初衷。五、三条阅读路径不是所有读者都需要从头读到尾。根据你的角色和目标选择对应路径路径适用人群顺序总时间风险A. 通读推荐全职开发者00-26 → 27 → 28-38 顺序全部8-10 小时无系统性强B. 实战驱动技术管理者27 → 28-38 → 遇到看不懂的摆渡回 09-263-5 小时⚠️ 易跳过方法论导致 Agent 交互逻辑黑盒化C. 角色横跳架构师27 → 28 → 33 → 34-38按模块兴趣跳4-6 小时⚠️ 单个模块代码上下文不连续路径 B 注意事项技术管理者时间紧迫想快速看到 AI 编码的效果。但请务必不要跳过 Rules 编写方法论 Prompt Eval——它是所有实战篇的规格基础48 个原子任务的拆解方法不读通后面的 Agent 编码根本不知道 Context 是怎么喂给 AI 的。路径 C 注意事项如果你只关注订单模块主线三前端模块 D2C 生成、主线四AI 安全合规落地至少先读 Rules 编写方法论 Prompt Eval 了解 SSD 和任务拆解方法再git checkout到v0.5-order。不要试图只读代码不看方法论映射——实战篇的代码是「方法论的具象化」不是自我解释的。六、六类陷阱与规避陷阱 1跳过方法论直接看实战后果看不懂 Agent 交互逻辑把 AI 生成代码的过程误读为「AI 在乱写」。比如没读过 13-14 章就去读 AI 编译修复的最小修复原则 的商品模块编码你看不到 Prompt 是如何构造的、上下文是如何传递给编码 Agent 的——你只看到结果但不理解为什么 AI 能产出这个结果。规避每篇实战文章的开头都有一个「前置方法论清单」边栏标注了阅读前必须回看的方法论篇章。请按清单操作。陷阱 2不 checkout 对应 tag后果代码状态不同步导致测试失败。比如读到主线四AI 安全合规落地 订单状态机时本地还在v0.2-product的代码上——缺少购物车实体和用户认证订单接口 401 或数据缺失。读者以为是代码有问题实际是没切换到正确 tag。规避每篇文章的第一个代码块一定是git checkout -f v0.x。不习惯 Git tag 操作的读者可以先在v0.1上把 tag 操作流程跑通。陷阱 3误解「AI 翻车现场」后果实战篇刻意保留了 AI 出错及修正过程这是为了展示方法论特别是 17-18 章的修复 Agent 和最小修复原则。首次阅读的读者可能误判为「这个 AI 也不行」或「作者的代码有 Bug」。规避文中标注了「AI 翻车现场」的段落旁边会附带标注此处是 AI 生成的原始错误通过 XX 方法论引导后修正。区分两个版本看理解方法论的干预效果。陷阱 4按非电商场景抵触后果认为「我不做电商这套对我没用」。电商系统只是载体其本质模式可以迁移订单状态机等价于任何审批流OA、工单、审核库存并发等价于任何资源争抢秒杀、预约、排队支付退款等价于任何资金流转押金、结算、赔付。除了状态流程的通用性之外电商系统的每个模块本身也是一种常见业务模式的代表商品模块是典型的内容管理用户模块是认证授权骨架购物车是临时聚合——这些模式可以迁移到 SaaS、企业内部系统乃至医疗和物流行业。陷阱 5Java 8 / Vue 2 老团队的迁移门槛后果Spring Boot 3 强制从 javax.* 迁移到 jakarta.*命名空间Vue 3 的 Composition API 是思维级差异。团队如果短期不打算升级可能会觉得实战篇的技术栈不可直接复用。规避方案如果只是技术栈版本问题——「跳过语法看逻辑」。关注点放在 AI 处理业务边界的过程上而非具体代码的 API 细节。Composition API 和 Options API 的区别不会影响对 AI 编码 Agent 工作方式的理解。陷阱 6最容易崩盘的关键节点——Rules 编写方法论 Prompt Eval这是整个实战链路上不可跳过的关口。Rules 编写方法论 Prompt Eval 的任务是从一个需求 Proposal 拆解出 48 个原子任务形成完整的 SSD 规格文档。如果这章没读通、规格定义模糊后续所有 Agent 编码都会因为上下文不足而产出垃圾代码。不是「不太好」的程度是从根本上不可用。判断是否读通的标准很简单能否在本地 IDE 中完整复现 48 个任务的拆解目录。能做出来进入 AI 编译修复的最小修复原则。做不出来回到 Rules 编写方法论 Prompt Eval 继续。铁律三则Tag 是指南针不是装饰品。每篇实战文章的起点都是git checkout。不养成这个习惯你会花一半的时间在「代码怎么跑不起来」上而不是理解 AI Native Engineering 本身。Tag 不是写给版本管理看的是写给后面的自己看的。不要跳过方法论去「先跑起来」。如果时间有限少读两篇方法论比少读一篇实战更有价值。因为实战篇本身就是对方法论的演示——你看懂了方法论再看实战是巩固只看实战不懂方法论是猜谜。刻意保留翻车现场比展示完美代码更有价值。这不是一套「看看我多厉害」的作品展示。你会在实战篇中看到 AI 写错了代码、Agent 审查没通过、修复 Agent 修出了新 Bug——这些不是意外是 AI 辅助开发中的常态。知道 AI 在什么环节会出错比看它写出完美代码更有实际参考价值。现在打开终端git checkout v0.1-spec。下一章见。评论区钩子你团队目前用的技术栈是什么版本如果是 Java 8 Vue 2迁移到 Spring Boot 3 最让你头疼的是什么欢迎在评论区聊聊你的迁移经历。本专栏的开源落地工具IvyFlow本专栏的整套方法论——多角色工作流、阶段守卫、OpenSpecSuperpowers 双驱动、Skill/Rule/Agent 三层分层——并非纸上谈兵。它们的落地载体是 IvyFlow一个 AI-Native 开发工作流 CLI 工具也是本专栏作者的开源项目。IvyFlow 用一条命令ivy init在项目中部署 5 种角色Developer / PM / QA / Architect / DevOps共 20 条命令和约 30 个 Skill将专栏中讨论的Phase Gate、Delta Spec 反写、TDD 强制循环、SubAgent 并行扇全部编码为脚本校验而非纯 Prompt 约定——守卫脚本会硬性拦截 AI 跳过阶段的行为让流程纪律从建议变成物理约束。GitHubgithub.com/jseko/IvyFlow官方网站jseko.github.io/IvyFlow安装npm install -g ivyflow-cli ivy init如果你读完本专栏想立刻落地IvyFlow 就是这套体系的开箱即用入口。