关于了解AI和使用在开发的实践

AI 与 WMS：从概念认知到业务落地实践

全文会分三层：

0. AI 基础认知：模型、Prompt、Agent、RAG 等关键概念
1. AI 工具链与开发流程：如何让 AI 真正融入日常开发
2. 案例：用 AI 完成 WMS 仓储硬件层级模块（后端 + 前端）

---

一、基础认知

1.1 AI 的几个阶段（极简版）

可以把 AI 的发展，粗糙地分成几个阶段：

阶段	举例	核心特点
规则时代	if-else、流程引擎、决策树	人写规则，机器只会照做
传统机器学习（ML）	风险评分、推荐系统、预测模型	机器从数据里学统计规律
深度学习（DL）	图像识别、语音识别、NLP	神经网络，模仿人脑结构
大语言模型（LLM）	ChatGPT、Claude、Gemini 等	通过大规模语料学习“语言+世界知识”
多模态模型	GPT-4o、Gemini Ultra 等	同时理解文字、图片、音频、视频

对于我们这类做业务系统的开发者，现在最直接能用上的就是：大语言模型 + 多模态模型，把它们当作一个非常聪明的「智能 API」。

---

1.2 几个必须搞清楚的概念

1）模型（Model）

• 本质就是一个复杂的函数：输入 → 输出。
• 输入：自然语言、代码、结构化数据、图片等；输出：答案、代码、结构化 JSON、图像等。
• 对日常开发的意义：把模型当成一个“会自己补全代码 / 生成文档 / 写 SQL / 设计接口”的远程服务。

2）Token 与上下文（Context）

• 模型处理文本的最小单位是 Token，大致可以理解为“子词”，不是简单的字或字符。

• 模型每次调用有一个 上下文窗口，决定它一次最多能看到多少 token（历史对话 + 当前问题 + 代码）。

• 实际意义：

  • 文档 / 代码不要一股脑全丢给模型，要学会分段、抽取关键信息；
  • 重要约束（架构、规范、边界条件）要集中描述，而不是散落在聊天历史里。

3）Prompt：让模型“听懂话”的关键

Prompt 可以理解为：

角色设定 + 任务说明 + 约束条件 + 输入内容 + 期望输出格式

一个典型示例：

[角色] 你是一名资深 .NET + React 全栈工程师
[任务] 请根据我给的领域设计，生成仓储模块的后端实体和 CRUD 应用服务
[约束]
- 使用 ABP 分层结构
- 严格按照我给的字段名，不要自创字段
[输入] <贴上仓储层级设计>
[输出格式]
1) 需要创建的文件清单
2) 每个文件的建议路径
3) 关键类的代码实现

核心经验：把可复用的 Prompt 抽成模板文件，后续反复使用。

4）Agent、Tool Use、RAG、Memory（简要版）

• Agent（智能体） ：不仅能回答，还能自己规划步骤、调用工具、读写文件、迭代改进。
• Tool Use / Function Calling：允许模型在对话里调用你定义好的 API / 函数，比如“查订单详情、读配置文件、执行脚本”。
• RAG（检索增强生成） ：先从你的文档 / 代码仓库里检索，再把相关内容喂给模型回答问题。
• Memory（记忆） ：让 Agent 记住长期信息，比如项目结构、常用编码风格、业务术语等。

在本文的案例里，我们重点用到的是：Prompt 模板 + 多模型分工 + AI 辅助生成代码和文档，没有深入自建 RAG 或训练模型，但思路是通的。

---

二、AI 工具链与项目背景

2.1 项目背景：一个典型的 WMS / WMCS 场景

业务上，这是一个典型的仓储 / 物流相关项目，目标是：

• 用 ABP + React 搭建一个 WMS / WMCS 系统；
• 完成基础业务：仓库、托盘、物料、任务等；
• 攻坚高阶能力：波次、策略、任务编排等；
• 在这个过程中，尽量用好 AI 来提效，而不是简单“让 AI 把代码全写了”。

技术栈大致如下：

• 后端：.NET + ABP + EF Core
• 前端：React + TypeScript
• 设施：Swagger / OpenAPI、前后端分离、OpenIddict 权限、审计日志等

2.2 多模型协作：谁负责“想”，谁负责“写”？

在实践中，我把模型大致分工为三类：

• 大模型 A：负责“设计与决策”

  • 用来做：架构选型、领域建模、模块划分、接口设计思路等；
  • 例如：根据“仓储硬件层级”需求，帮我设计一版领域模型和聚合根边界。

• 大模型 B：负责“执行与产出代码”

  • 用来做：根据既定设计，生成实体、DTO、应用服务、控制器、前端页面骨架；
  • 要求：严格遵守我给的项目结构和命名规范。

• 小模型 / 轻量模型：负责“答疑与解释”

  • 用来做：问语法、问错误栈、问某个框架配置是什么意思；
  • 不承担大规模代码生成任务，更多是“即时搜索 + 顾问”。

这样做的好处是：

• 设计和执行解耦，避免一个模型既“拍脑袋设计”又“随手乱写代码”；
• 可以对不同任务选用性价比更高的模型组合。

2.3 辅助工具：VS Code + AI 插件

工具链：

• 编辑器：VS Code / Visual Studio

• AI 插件：GitHub Copilot / 其他厂商的 VS Code AI 插件

• 优势：

  • 直接在项目上下文中对话；
  • 能读取 / 修改仓库中的文件；
  • 支持基于选中文件或目录做局部操作，比如“只重构这个类”。

---

三、如何让 AI 真正融入开发流程

这一部分是全文的“方法论核心”：不是问一句“帮我写个 WMS”，而是设计一条可落地的 AI 开发流。

3.1 第一步：写一个“项目背景 + 规范”的 Prompt 模板

在项目根目录创建 ai_prompts/Background.md，里面固定几件事：

0. 项目背景和技术栈：

   • 业务领域：如“WMS 仓储管理 / WMCS 设备控制”；
   • 后端技术栈：.NET + ABP + EF Core，DDD 分层等；
   • 前端技术栈：React + TypeScript + Ant Design；
   • 数据库类型；

1. 分层结构约定：Domain / Application.Contracts / Application / HttpApi / EntityFrameworkCore / Web 等；

2. 命名规范：

   • DTO 命名：{EntityName}Dto、Create{EntityName}Dto 等；
   • 应用服务：{EntityName}AppService；

3. 映射风格：EF Core 是集中配置，还是每个实体一个配置类；

4. 代码风格：

   • 构造函数保证实体处于有效状态；
   • 领域层只依赖接口，不直接依赖基础设施实现；
   • 关键属性要有中文注释等。

之后每次新开对话，只要先把这份 Background.md 喂给 AI，相当于“统一了世界观和语法规范”，能明显减少后面沟通成本。

3.2 第二步：需求 → 领域模型 → 任务拆分

以“仓储硬件层级”为例，我会先用自然语言和简单结构图把需求描述给 AI：

物流中心 (LogisticsCenter)
└─ 仓库 (Warehouse)
    ├─ 巷道 (Aisle)
    │   └─ 货架 (Rack)
    │       └─ 货位 (Location)
    └─ 虚拟区域 (Area)
         └─ 通过多对多关系 AreaLocation 关联到货位
​
请基于上述层级：
1) 帮我梳理主要实体、聚合根与关系；
2) 给出一个文字版的领域建模建议；
3) 在保持 ABP 分层的前提下，列出实现这个模块需要的 10~15 个任务。

AI 通常会给出：

• 对每个实体的职责说明；
• 哪些应该是聚合根，哪些是值对象；
• 按 Domain / Application / HttpApi 等拆分的任务清单。

这一步只要设计，不要代码，方便你在“写一行代码前”先看清楚整体结构。

3.3 第三步：分批执行，而不是一锅端

从实践看，分批执行是 AI 开发中最重要的习惯之一：

0. 先让 AI 只做 实体 + 仓储接口 + 枚举：

   • Domain.Shared：仓库类型、货位状态、货架类型等枚举；
   • Domain：实体类（LogisticsCenter / Warehouse / Aisle / Rack / Location / Area / AreaLocation）及仓储接口；

1. 再生成 应用服务层 + DTO + 接口定义：

   • Application.Contracts：DTO、IAppService 接口；
   • Application：AppService 实现；

2. 最后生成 HttpApi 控制器 + 接口文档：

   • HttpApi：控制器，遵循 RESTful 约定；
   • 额外生成一份 Markdown 接口文档，给前端和 AI 前端助手使用。

每一步之间，都要：

• 先落地到本地工程里；
• 跑一遍编译 / 简单测试；
• 把报错栈贴给 AI 让它自己修。

3.4 面对报错和重试：把错误栈当作“训练素材”

当 AI 生成的代码有问题时，我的做法是：

0. 本地编译 / 运行，拿到完整错误栈；
1. 把错误栈 + 对应代码段丢给 AI：

这是编译 / 运行错误栈：
<贴错误栈>
​
这是相关代码：
<贴出对应类或方法>
​
请按照我的项目规范，帮我修复错误。
- 优先保证类型安全和运行正确；
- 如果涉及架构或设计修改，请先解释原因，再给出修改方案。

3. 让 AI 给出修复后的代码，再次落地验证。

关键点：不要自己默默改完，再让 AI 接着开写。

• 你希望 AI 在上下文里“看到”这些错误和修复过程，它会学会：

  • 某些框架在你项目中的特殊用法；
  • 项目中的真实依赖关系和边界约束。

3.5 前后端分离项目：如何让两个对话“说同一种话”

在前后端分离的项目中，一个常见问题是：

后端 AI 和前端 AI 各聊各的，接口文档对不齐。

实践里我用了两种方式：

0. 用同一个编辑器打开前后端两个项目：

   • 让 AI 可以同时看到后端和前端的代码；
   • 后端改了接口，AI 能立刻帮你改前端调用。

1. 把接口文档当作“中间语” ：

   • 在后端利用 AI 生成一份结构化的 API 文档（Markdown 即可）；
   • 前端侧把这份文档和 Background Prompt 一起喂给 AI，要求它按照文档生成页面和服务封装；
   • 这样前后端虽然是两次不同的对话，但“对齐”在同一份接口文档上。

---

四、AI + WMS 仓储硬件层级：一个完整实战

这一部分用一个具体模块来串联：从领域设计 → 后端实现 → 接口文档 → 前端页面。

4.1 业务场景：仓储硬件层级

目标是实现一个典型的仓储硬件层级：

物流中心 (LogisticsCenter)
└─ 仓库 (Warehouse)
    ├─ 巷道 (Aisle)
    │   └─ 货架 (Rack)
    │       └─ 货位 (Location)
    └─ 虚拟区域 (Area)
         └─ AreaLocation (多对多：虚拟区域 - 货位)

模块主要需求：

• 维护完整的层级关系（谁属于谁）；
• 支持按层级过滤、联动下拉（例如：选仓库 → 过滤巷道 → 过滤货架 → 过滤货位）；
• 为后续的任务分配、策略编排提供基础数据结构。

4.2 用 AI 完成后端 Domain 设计与实现

第 1 步：确认实体与字段设计

在把层级结构告诉 AI 之后，不要直接说“帮我生成代码”，而是先要求它：

• 列出每个实体需要的核心字段、约束和关系；
• 标明唯一性约束、索引建议等；
• 明确聚合根边界和导航属性。

确认完后，再下达生成代码的指令：

请基于刚才确认的设计：
1) 在 Domain.Shared 层生成所有枚举（仓库类型、货位状态、区域类型等）；
2) 在 Domain 层为每个实体生成类和仓储接口；
3) 按照我在 Background.md 中约定的 EF Core 映射风格，生成映射配置代码。
​
要求：
- 严格使用我给定的字段名，不要新增业务字段；
- 关键属性添加中文注释；
- 在代码顶部用注释标明建议文件路径。

这样一轮下来，后端的领域层和基础持久化配置基本就成型了。

第 2 步：生成 Application 层与 HttpApi

在领域模型稳定后，再让 AI 去生成：

• Application.Contracts：

  • DTO 类型（列表、详情、创建、更新）；
  • IAppService 接口定义；

• Application：

  • AppService 实现，尽量使用 ABP 提供的 CRUD 基类；

• HttpApi：

  • 控制器，主要负责路由定义和调用应用服务；

同样，通过 Background Prompt 约束：

• 路由前缀、RESTful 约定；
• 返回统一的分页结果类型；
• 不在 Controller 里写业务逻辑。

4.3 用 AI 生成接口文档，服务前端

在后端基本跑通之后，我会专门开一轮对话，让 AI 根据实际项目代码生成一份 “接口清单 + 简要说明” 的 Markdown 文档。

示例 Prompt（简化版）：

【目标】
我想生成一份接口文档，先输出“接口清单 + 简要描述”，
暂时不要输出详细的请求 / 响应字段定义。
​
【模块背景】
- 模块名称：WMS 仓储硬件层级管理
- 主要功能：维护物流中心 / 仓库 / 巷道 / 货架 / 货位 / 虚拟区域等基础数据
​
【任务】
1. 根据当前仓储模块的 HTTP API，列出接口清单：
   - 接口名称（中文）
   - 英文标识（用于方法名 / 总结）
   - HTTP Method（GET / POST / PUT / DELETE）
   - URL
   - 入参字段名称 + 简要描述
   - 出参字段名称 + 简要描述
   - 功能说明（1–2 句话）
​
【输出格式】
请用 Markdown 输出，例如：
​
## 仓库管理
​
1. 获取仓库列表
   - Key: GetWarehouseList
   - Method: GET
   - URL: /api/app/warehouses
   - 入参：
     - name: 仓库名称（模糊匹配）
     - type: 仓库类型
   - 出参：
     - items: 仓库列表
     - totalCount: 总条数
   - 说明: 分页查询仓库列表，支持按名称、编码筛选。

在实践中，如果一次性让 AI 生成“非常详细 + 带示例”的文档，很容易出现：

• 响应内容太长导致连接中断；
• 生成过程报错，需要重试。

解决办法就是：

• 第 1 轮只要清单和字段说明；
• 真需要详细示例时，再按“单个接口 / 单个模块”去要。

4.4 前端：基于接口文档和 OpenAPI 的批量页面生成

有了规范的接口文档和后端 Swagger / OpenAPI 之后，前端这边可以这样做：

0. 根据 OpenAPI 生成统一的服务封装：

   • 利用 openapi-typescript / openapi-generator 等工具生成 API 客户端；
   • 或者用 AI 根据 OpenAPI / Swagger JSON 生成 Axios 封装代码。

1. 把 Background Prompt + 接口文档喂给前端 AI 助手：

   • Background：说明前端用 React + Ant Design，约定路由风格、组件拆分规范；
   • 接口文档：说明有哪些实体、每个实体的 CRUD 接口、字段含义。

2. 让 AI 以“模块”为单位生成页面骨架：

   • 例如：

     • 物流中心管理：列表页 + 新建/编辑弹窗组件；
     • 仓库管理：同上；
     • 巷道 / 货架 / 货位 / 区域 / 区域货位关联等，都按类似模式生成。

   • 同时生成：

     • 路由配置；
     • 枚举常量文件（仓库类型、货位状态等）；
     • 模块 README，简要说明各页面职责和调用关系。

3. 自己补齐细节与视觉体验：

   • 表单校验规则（长度、必填、格式）；
   • 列表筛选、排序、分页的体验优化；
   • 删除确认、批量操作、导入导出等增强功能。

这样，前端模块可以在非常短的时间内从“0”到“可用”，后续主要精力转向交互和体验打磨，而不是在 CRUD 上重复造轮子。

---

五、踩过的坑与经验总结

这一节总结一些在 AI + WMS 实践中遇到的典型问题和对应的“反模式 / 正确姿势”。

5.1 一次性输入太多 vs 分步驱动

• 反模式：

  • 把业务需求、接口设计、代码风格一股脑丢给 AI，让它“帮我把后端和前端都写完”。
  • 结果通常是：结构混乱、边界不清、改一处牵一发而动全身。

• 建议：

  • 严格按照“设计 → Domain → Application → HttpApi → 文档 → 前端”的步骤来；
  • 一次性只做一个清晰的任务：生成实体 / 生成 DTO / 生成接口文档等。

5.2 不沉淀 Prompt 模板 vs 有一套可复用的模板体系

• 反模式：

  • 每次新对话都重新解释一遍项目背景和规范；
  • 结果是不同对话里 AI 理解的“世界观”不一致，代码风格、结构各不相同。

• 建议：

  • 把常用模板抽出来，例如：

    • 项目背景（Background）；
    • 需求 → 领域建模 → 任务拆分；
    • 执行任务（只实现一个具体子任务）；
    • 局部代码审查与重构；
    • 接口文档生成。

  • 模板存成 Markdown 文件，后续只需要替换中间的“需求描述 / 模块名称”。

5.3 完全相信 AI vs 自己做“架构师 + Reviewer”

• 反模式：

  • 把 AI 当成“比自己更懂业务、更会架构的存在”；
  • 盲目接受它给出的所有设计和实现。

• 建议：

  • 把 AI 当作一个 高效的助理 / 代码生成器 / 思路补充者；

  • 你自己负责：

    • 领域建模决策；
    • 架构边界与依赖方向；
    • 最终代码 Review 和质量把关。

5.4 忽视“响应长度 / 网络问题” vs 学会“降维请求”

• 反模式：

  • 让 AI 一次性生成所有接口的“详细请求/响应示例 + 业务说明 + 用例”；
  • 容易出现超时 / 连接中断 / 服务端报错。

• 建议：

  • 先让 AI 生成 精简版接口清单；
  • 真需要具体示例时，再针对某个接口单独展开；
  • 在 Prompt 里显式限制输出体量，例如“不要超过 200 行”。

5.5 只在一个项目玩 AI vs 真正形成“跨项目能力”

• 反模式：

  • 把所有 Prompt 和经验写在某个临时对话里，项目一换、对话一丢，全部清空重来。

• 建议：

  • 把这套“AI + WMS”的方法论抽象成通用的：

    • Prompt 模板；
    • 模块搭建 checklist；
    • 常见坑位与解决方案；

  • 放到单独的知识库（比如 docs/ai_prompts/ 目录），下一个项目继续复用。