从自然语言到业务模块：AI辅助编码的工程实战解析

大模型写代码听上去很酷，但能不能真的跑起来、部署出去，才是团队关心的核心问题。在最近一次中台系统升级中，我们尝试用 DeepSeek-Coder 直接从自然语言需求生成后端模块。本文完整记录了我们如何设计 Prompt、如何控制上下文、如何校验生成结构的可用性与逻辑正确性，最终交付一套完整微服务的全过程。文中包含实测数据、踩过的坑与落地建议，适合所有正在探索 AI 编码实践的工程团队阅读。

CSDN观熵

809人浏览 · 2025-07-06 15:59:06

CSDN观熵 · 2025-07-06 15:59:06 发布

用自然语言写业务代码：我们如何用 DeepSeek-Coder 搭起微服务骨架

关键词：
自然语言编码、Prompt 编程、DeepSeek-Coder、微服务开发、模块生成、工程实践

摘要：
大模型写代码听上去很酷，但能不能真的跑起来、部署出去，才是团队关心的核心问题。在最近一次中台系统升级中，我们尝试用 DeepSeek-Coder 直接从自然语言需求生成后端模块。本文完整记录了我们如何设计 Prompt、如何控制上下文、如何校验生成结构的可用性与逻辑正确性，最终交付一套完整微服务的全过程。文中包含实测数据、踩过的坑与落地建议，适合所有正在探索 AI 编码实践的工程团队阅读。

目录：

一、项目背景：从“文档驱动”到“对话驱动”的开发尝试
二、第一步：怎么写 Prompt，才能让模型“理解你的意思”
三、模块拆解逻辑与指令分步生成实践
四、我们用自然语言生成了哪些业务组件
五、代码的质量能用吗？实测指标与回归验证
六、集成进 Git 流水线后的协作模式变化
七、落地总结：哪些能用，哪些不能用
八、下一步计划：Prompt 模板化 + 私有化语料融合实验

一、项目背景：从“文档驱动”到“对话驱动”的开发尝试

我们这个项目的起点很简单：为一个 CRM 系统扩展一个「客户跟进记录管理」模块。按照过去的方式，我们通常需要经历以下几个阶段：

产品经理写 PRD 和流程图
后端梳理接口设计、建表、字段定义
写代码 + 单测 + 联调 + 部署
整个流程从评审到交付，通常要 3～5 个工作日。

这次，我们尝试做一次“流程反转”：不给开发写接口文档，而是只写一句清晰的中文描述，交由 DeepSeek-Coder 生成模块原型，我们只做代码审查和逻辑补全。目标很明确：

快速出原型，让产品团队能提早评估界面和流程
验证大模型能否真正参与业务模块交付
构建一个从自然语言生成代码 → 集成测试 → 上线的闭环

使用模型的技术栈选型上，我们锁定了 DeepSeek-Coder（v1.5.3 GPU 推理版本），主要原因是它支持结构化对话补全，表现稳定，并且对中英文指令的兼容性好，内部在多个项目中有过基础验证。

初期我们设置了两个硬性目标：

模型生成的代码必须能跑通至少 80% 的业务流程；
整个“从指令到模块上线”的流程不超过两天。

这是一次实打实的开发流程试水，我们没打算“让模型替代人”，而是验证它是否能在真实场景中扮演“能干活的协作者”。

二、第一步：怎么写 Prompt，才能让模型“理解你的意思”

模型生成什么，取决于你说什么。这是我们在第一次试用 DeepSeek-Coder 时踩到的最大坑。

我们刚开始直接抛出一句：

“帮我写一个客户跟进记录模块，能记录沟通内容、负责人和时间，支持分页查询。”

得到的结果是一个定义模糊的 controller 方法，里面没有字段校验，没有服务层调用，返回的是伪代码结构。

后来我们发现，如果把 Prompt 拆得更细、更结构化，模型生成效果就有显著提升。下面是我们经过多轮试错之后形成的 Prompt 模板框架：

请使用 SpringBoot 构建一个客户跟进记录模块，包含以下功能：
1. 接口定义：
   - 添加客户跟进记录
   - 查询客户的所有跟进记录，支持分页
2. 字段：
   - 客户ID（customerId, Long）
   - 沟通内容（content, String）
   - 跟进人（follower, String）
   - 跟进时间（followTime, DateTime）
3. 返回结构需为统一响应格式，包含 code、msg、data。
4. 所有字段加非空校验。
5. Controller、Service、Entity 分层结构。

用这种 Prompt 发给 DeepSeek-Coder，返回的是一个结构完整的三层代码，包括：

Controller 层：接口定义清晰、注解齐全
Service 层：封装业务逻辑，并使用注入的 DAO 操作数据库
Entity 层：字段定义准确，包含注解、非空校验
Page 查询逻辑带有分页对象和参数封装类（PageParam）

我们做了几组对比测试，发现字段和行为写得越具体，模型生成的内容越贴近我们想要的“工程结构”。它并不是靠模型“聪明”，而是你给得足够清楚，它才知道怎么还原一套完整模块。

我们还总结出几个 Prompt 编写技巧：

尽量少用“描述性模糊语句”，比如“尽量简洁”“提高效率”，这些词对模型没有约束力；
要写清楚“输入是什么”，“输出是什么”，比如 GET 参数 vs POST Body；
明确规范格式要求，例如“返回统一包装类”或“字段用驼峰命名”；
每条功能点单独列出，避免换行中的语义干扰。

这个阶段模型就像个“编程助理”，你不可能一句话让它替你写完所有逻辑，但如果你把它当成一位需要你指导的实习生，你会发现它执行力很强。

三、模块拆解逻辑与指令分步生成实践

很多人第一次用大模型写代码时，最容易掉进的一个坑就是“一口气全交代”，期望模型一次生成整个系统模块，包括接口、数据表、业务逻辑、异常处理、测试和部署脚本。结果往往是：什么都写了，但什么都不完整。

我们的经验是——模型擅长执行“清晰单一”的目标指令，但不擅长处理“长篇复合”需求。
所以我们采用了“分步生成+模块拆解”的策略，先把业务功能切成几个逻辑块，再逐步用 Prompt 让模型生成对应结构。具体流程如下：

业务功能拆解为最小交互单元
在“客户跟进记录”模块中，我们拆解出如下核心子功能：
- 创建记录（POST）
- 查询记录列表（GET + 分页）
- 获取某客户最近一次跟进记录（GET）
- 删除记录（DELETE）
字段与数据结构先行
让模型先生成 Entity，确保字段定义、注解、数据库映射一致性。Prompt 示例：
```
创建一个名为 FollowRecord 的实体类，字段包括：
- Long id
- Long customerId
- String content
- String follower
- LocalDateTime followTime
要求使用 Lombok、JPA 注解，并加上非空校验。
```
模型返回的结构清晰，命名合理，并自动加上了 @TableName("follow_record") 与 @TableId(type = IdType.AUTO)，适配我们项目使用的 MyBatis-Plus。
逐步构建接口控制器和业务逻辑
对每个功能点，使用独立 Prompt 生成 Controller + Service + Mapper。例如：
```
创建一个 FollowRecordController，包含 POST 接口 /follow-record/add，接收 JSON 参数，调用 service 层保存记录。
```
这样模型只关注一个动作，生成结果往往更规范，更少遗漏。
拼接与组装
所有生成的 Controller、Service、Entity 代码手动合并，修改 package 路径，形成完整结构。

在这个流程中，我们保持每条 Prompt 不超过 120 字，最多处理一到两个功能。这样不仅让生成结果更准确，也方便我们后续验证和调试。

四、我们用自然语言生成了哪些业务组件

这次试验的目标是通过自然语言，自动生成“可部署、可联调”的业务代码组件。最终，我们用 DeepSeek-Coder 成功生成并交付了以下主要部分：

数据库实体类 Entity
模型生成了 FollowRecord 实体，字段精度、类型、注解都基本正确，支持直接接入 MySQL 表结构迁移流程。配套生成了 Mapper 层接口和 XML 映射。
Controller 层接口定义
生成了标准的 RestController，接口路径清晰，返回类型使用了我们项目内部封装的统一响应类 Result<T>。并自动识别 GET 与 POST 使用不同参数注解。
Service 层逻辑封装
对于 addRecord()、queryPage()、queryLatestByCustomer() 等方法，模型不仅生成了基本逻辑，还加上了空参校验和异常处理。ServiceImpl 内注入 Mapper 并完成了数据调用封装，结构与我们手写代码高度一致。
分页与请求封装对象 DTO
当我们在 Prompt 中写到“需要分页查询”，模型自动补充了 FollowRecordPageRequest 作为分页参数对象，内含 pageNum、pageSize、customerId 等字段，并带注释。
返回对象封装 VO（View Object）
Prompt 明确指出“不要直接返回数据库实体”，模型正确生成了 FollowRecordVO，并使用 BeanUtils.copyProperties() 完成转换。
字段级注解与数据校验
大部分字段生成了 @NotNull、@Size(max = 100) 等注解，兼容 Hibernate Validator 体系，可直接集成项目级统一参数校验流程。
简单单元测试用例模板
我们还尝试引导模型生成测试代码。Prompt 示例：
```
为 FollowRecordServiceImpl 编写单元测试类，使用 JUnit5 和 Mockito。
```
返回的测试用例覆盖了核心的 addRecord() 和 queryPage() 方法，虽然未达到生产标准，但基本结构完整，可作为模板调整。
Swagger 接口文档注解
Prompt 中加一句“支持接口文档”，模型就自动加上了 @Api、@ApiOperation 等注解，符合我们内部使用的 Swagger/OpenAPI 规范。

这些代码最终经过了人工审核与小幅修改后成功部署上线，并与前端完成联调。整体流程从生成到上线共耗时 1.5 天，比传统开发快了 60% 以上，前期 PRD 与接口对齐所需会议次数从 3 次缩减到 1 次。

我们认为，大模型并不神奇，它只是把过去需要大量沟通、重复敲打的内容快速变成了“可调试的代码”，真正的效率提升来自 Prompt 结构清晰、任务拆解合理、上下游接口协同紧密。

五、代码的质量能用吗？实测指标与回归验证

我们对 DeepSeek-Coder 生成的代码质量，做了一轮较为系统的验证。验证维度涵盖语法正确性、业务逻辑覆盖、代码规范符合度、测试通过率、人工修改比率五个核心指标，并与团队手写代码进行了横向对比。

测试基线为同一模块（客户跟进记录），我们将模型生成的代码在不做修改的情况下，直接接入项目并运行单测与逻辑回归流程。

实测指标如下（以 10 个业务功能为单位）：

指标	DeepSeek 生成代码	人工手写代码
编译通过率	100%	100%
接口可用性（Postman 实测）	92%	100%
单测通过率（含逻辑断言）	88%	96%
需要手动修改的比例（逻辑/命名）	27%	-
命名规范匹配率（驼峰 + 语义）	85%	100%
空参/越界容错率（含默认值）	76%	91%

整体结论是，在结构类代码（如实体类、Controller、分页逻辑）中，模型生成几乎可以直接使用；但在涉及较强业务逻辑的流程（如权限判断、空数据回退、边界校验）中仍存在盲区，特别是对上下文状态的“保持感知”仍较弱。

例如，模型会正确生成分页接口，但在构造 PageResult<T> 时可能遗漏封装总页数字段，导致前端展示异常；又如模型会生成统一响应结构，但在异常分支中忘记封装 Result.fail() 而直接抛出原始异常。

回归验证中，我们将改动前后的代码分别跑了一轮 42 个测试用例，包括接口返回、数据写入、权限边界、字段越界、空值处理、主键重复等典型测试点。整体通过率达 88%，比预期略高，但也提示我们：模型生成代码“八成能用”，但不能跳过人工逻辑审阅。

为此我们在项目中设立了一套标准流程：

模型生成后 → 人工代码走查
接入 CI 后 → 跑一轮功能级自动化回归测试
上线前 → 审查模型改动部分是否包含异常分支与接口完整性

模型不等于“终稿”，更像是加速器，用来快速打出一个可调试的结构草稿，剩下的交给开发者完善。

六、集成进 Git 流水线后的协作模式变化

为了让 DeepSeek-Coder 真正融入团队开发，我们将其集成进了 GitLab 的开发流水线中。整体目标是让模型生成代码的过程可控、可审、可回退，避免“谁都能调用模型但没人知道改了什么”的混乱局面。

我们做了以下几个集成动作：

Prompt 与代码生成双绑定
所有 Prompt 输入与模型生成结果都自动写入 Git Commit Message 和文件变更记录中。我们自定义了一个前缀规范：
```
[AI-GEN] Add FollowRecord module via DeepSeek-Coder
Prompt: "请为客户跟进记录生成 controller 和 service 结构"
```
这样在代码审查时，Reviewer 能清晰知道这段代码是人写的还是模型写的，用了什么输入。
GitLab MR 合并前自动检查
在 Merge Request（MR）中，我们加入了一个静态审查任务：
- 如果发现新代码为 AI 生成，强制要求 Review 人数 ≥ 2；
- 强制检查是否有异常处理、空值容错逻辑、测试类。
审查通过后，CI 自动触发 UT + Lint 流水线，跑通后才允许合并。
Prompt 模板管理系统
为了让团队成员使用统一 Prompt 风格，我们把所有成功用过的 Prompt 存入一个私有仓库（Markdown 文档格式），包括：
- 目标说明（生成什么模块）
- 输入结构模板
- 样例输出截图
- 使用场景标签（分页接口 / 数据结构 / 参数校验）
这样团队新人不需要重复摸索，只要按模板写 Prompt，生成结果就稳定可控。
多人协作下的模型调用权权限控制
由于大模型调用存在资源成本，我们限定了仅 Team Leader 和后端负责人有权限直接调用模型生成主模块，普通开发可调用子模块或补全逻辑。在 CI 中，模型调用也做了日志审计，记录调用者、时间、Prompt 内容和生成结果。

这些机制的落地效果非常明显：

Pull Request 的平均审核时间从 5 小时降到 2.1 小时；
模型生成代码占比达到 42%，而回滚率低于 6%；
团队中 3 位没有 SpringBoot 项目经验的新人，通过 Prompt 模板成功完成了功能模块开发任务。

总结一句话：模型不会取代协作，但它改变了协作方式。

从前是人写代码、彼此审查；现在是人指导模型生成代码，然后一起看模型哪里“答得还行”、哪里“跑题了”。这种变革，不只是开发效率的提升，更是开发范式的转向。

七、落地总结：哪些能用，哪些不能用

经历了一整套完整模块的自然语言驱动开发流程后，我们对模型在真实工程环境中的可用性有了更冷静、更清晰的认知。可以负责任地说，大模型确实能生成「可跑、可测、可上线」的业务代码，但并非所有环节都适合交由模型完成。

哪些能用：

结构性强的代码骨架
- Controller、Service 接口层
- DTO、VO、Entity 数据结构
- 分页查询、增删改查类业务
- Swagger 注解、接口注释、统一响应封装
这些代码往往有规律、可模板化，模型在学习大量项目代码后，具备了高度结构还原能力。尤其在标准后端技术栈（如 SpringBoot、MyBatis-Plus）中，模型几乎可以直接产出符合企业风格的模块模板。
封装层逻辑迁移
- 统一返回封装工具
- Bean 转换工具类
- 常见工具类如日期格式化、枚举管理器
这些内容原本就容易被拷贝重复编写，交由模型生成效率极高，还能帮团队统一代码风格。
模板化单元测试
- 常规接口逻辑的测试用例
- Mock 行为构造、断言结构补全
只要描述清晰，模型可以快速补齐标准测试流程，覆盖率虽不高，但起点明确。

哪些不能用或不建议直接使用：

涉及业务权限、流程状态的核心逻辑
- 用户上下文判断、角色校验
- 流程中断、异常分支、灰度策略逻辑
模型无法掌握企业内部规则，可能在关键判断中生成错误逻辑，甚至遗漏处理路径，存在严重隐患。
高复杂度事务编排、异步链路逻辑
- MQ、Kafka 消息处理模块
- 分布式事务、多数据源切换等敏感组件
模型在这些环节生成的代码可读性不差，但正确率低，耦合性高，人工审校成本反而更大。
团队核心业务知识领域的逻辑封装
- 风控、计费、策略引擎等企业专属代码
模型缺乏训练语料，不具备上下文语义图谱，生成内容往往片面或误导。

换句话说，模型擅长做重复的、格式化的、上下文清晰的工作，而在人类要判断“为什么这么写”或“是否有业务冲突”的环节时，仍然需要人工主导。我们认为合理的分工是：

模型写骨架，人补逻辑；
模型提建议，人做判断；
模型做初稿，人做收尾。

八、下一步计划：Prompt 模板化 + 私有化语料融合实验

这次实践让我们认识到：AI 编码并不是一件“每次从零开始试”的事。相反，Prompt 的设计、调用的上下文、项目的语义知识，都需要体系化管理。

我们下一阶段的重点是两个方向：

1. Prompt 模板体系化建设

过去我们在 Notion 上零散记录了好用的 Prompt，这远远不够。现在我们打算构建一个“Prompt 模板中心”，核心思路是：

将每一个业务场景（分页接口、字段校验、批量处理）抽象为模板；
每个模板包含：功能意图、输入样式、生成结果截图、注意事项；
与 Git 分支规范绑定，例如以 feature/prompt-* 开头的分支可触发自动加载模板 Prompt；
加入 CI 检查，如检测生成代码是否包含测试类、异常处理。

通过这种机制，让团队成员只需修改变量字段，即可稳定生成可用模块，避免“每个人都用自己的写法和风格去调模型”。

2. 模型语料融合与私有化适配实验

我们使用的大模型仍然是开源版本推理部署，并未接入企业私有代码语料。下一步我们计划：

搭建一个轻量级 RAG（Retrieval-Augmented Generation）框架，将企业已有代码库向量化；
在 Prompt 时注入与当前模块相关的历史代码片段（如实体、接口、命名规范）；
测试模型在私有语境下是否能更好生成“风格统一、逻辑连续”的业务模块；
对比无语料、半语料、全语料三种调用策略在生成正确率上的提升比例。

我们预期，私有化语料 + Prompt 体系化，能把当前 70%-80% 可用率的生成水平进一步推高到 90% 以上，真正让 AI 编码成为稳定的工程能力，而不是一次性的“工具尝试”。

最终目标并不是“让模型写代码”，而是让团队拥有一个具备上下文认知、语义对齐能力的开发协作者。未来，我们希望构建出一整套 Prompt 流程、版本管理、审计回溯的协作闭环，真正让自然语言变成工程生产力的一部分。

个人简介

作者简介：全栈研发，具备端到端系统落地能力，专注人工智能领域。
个人主页：观熵
个人邮箱：privatexxxx@163.com
座右铭：愿科技之光，不止照亮智能，也照亮人心！

专栏导航

观熵系列专栏导航：
具身智能：具身智能
国产 NPU × Android 推理优化：本专栏系统解析 Android 平台国产 AI 芯片实战路径，涵盖 NPU×NNAPI 接入、异构调度、模型缓存、推理精度、动态加载与多模型并发等关键技术，聚焦工程可落地的推理优化策略，适用于边缘 AI 开发者与系统架构师。
DeepSeek国内各行业私有化部署系列：国产大模型私有化部署解决方案
智能终端Ai探索与创新实践：深入探索智能终端系统的硬件生态和前沿 AI 能力的深度融合！本专栏聚焦 Transformer、大模型、多模态等最新 AI 技术在智能终端的应用，结合丰富的实战案例和性能优化策略，助力智能终端开发者掌握国产旗舰 AI 引擎的核心技术，解锁创新应用场景。
企业级 SaaS 架构与工程实战全流程：系统性掌握从零构建、架构演进、业务模型、部署运维、安全治理到产品商业化的全流程实战能力
GitHub开源项目实战：分享GitHub上优秀开源项目，探讨实战应用与优化策略。
大模型高阶优化技术专题
 AI前沿探索：从大模型进化、多模态交互、AIGC内容生成，到AI在行业中的落地应用，我们将深入剖析最前沿的AI技术，分享实用的开发经验，并探讨AI未来的发展趋势
AI开源框架实战：面向 AI 工程师的大模型框架实战指南，覆盖训练、推理、部署与评估的全链路最佳实践
计算机视觉：聚焦计算机视觉前沿技术，涵盖图像识别、目标检测、自动驾驶、医疗影像等领域的最新进展和应用案例
国产大模型部署实战：持续更新的国产开源大模型部署实战教程，覆盖从模型选型 → 环境配置 → 本地推理 → API封装 → 高性能部署 → 多模型管理的完整全流程
Agentic AI架构实战全流程：一站式掌握 Agentic AI 架构构建核心路径：从协议到调度，从推理到执行，完整复刻企业级多智能体系统落地方案！
云原生应用托管与大模型融合实战指南
 智能数据挖掘工程实践
 Kubernetes × AI工程实战
 TensorFlow 全栈实战：从建模到部署：覆盖模型构建、训练优化、跨平台部署与工程交付，帮助开发者掌握从原型到上线的完整 AI 开发流程
PyTorch 全栈实战专栏： PyTorch 框架的全栈实战应用，涵盖从模型训练、优化、部署到维护的完整流程
深入理解 TensorRT：深入解析 TensorRT 的核心机制与部署实践，助力构建高性能 AI 推理系统
Megatron-LM 实战笔记：聚焦于 Megatron-LM 框架的实战应用，涵盖从预训练、微调到部署的全流程
AI Agent：系统学习并亲手构建一个完整的 AI Agent 系统，从基础理论、算法实战、框架应用，到私有部署、多端集成
DeepSeek 实战与解析：聚焦 DeepSeek 系列模型原理解析与实战应用，涵盖部署、推理、微调与多场景集成，助你高效上手国产大模型
端侧大模型：聚焦大模型在移动设备上的部署与优化，探索端侧智能的实现路径
行业大模型 · 数据全流程指南：大模型预训练数据的设计、采集、清洗与合规治理，聚焦行业场景，从需求定义到数据闭环，帮助您构建专属的智能数据基座
机器人研发全栈进阶指南：从ROS到AI智能控制：机器人系统架构、感知建图、路径规划、控制系统、AI智能决策、系统集成等核心能力模块
人工智能下的网络安全：通过实战案例和系统化方法，帮助开发者和安全工程师识别风险、构建防御机制，确保 AI 系统的稳定与安全
智能 DevOps 工厂：AI 驱动的持续交付实践：构建以 AI 为核心的智能 DevOps 平台，涵盖从 CI/CD 流水线、AIOps、MLOps 到 DevSecOps 的全流程实践。
C++学习笔记？：聚焦于现代 C++ 编程的核心概念与实践，涵盖 STL 源码剖析、内存管理、模板元编程等关键技术
AI × Quant 系统化落地实战：从数据、策略到实盘，打造全栈智能量化交易系统
大模型运营专家的Prompt修炼之路：本专栏聚焦开发 / 测试人员的实际转型路径，基于 OpenAI、DeepSeek、抖音等真实资料，拆解从入门到专业落地的关键主题，涵盖 Prompt 编写范式、结构输出控制、模型行为评估、系统接入与 DevOps 管理。每一篇都不讲概念空话，只做实战经验沉淀，让你一步步成为真正的模型运营专家。