ARTICLE · 1008147
第十四课:AI辅助技术文档与API文档生成
第十四课:AI辅助技术文档与API文档生成
发布日期:2026-09-15 · 预计阅读:14分钟
本课目标1. 掌握AI生成README文档的方法与最佳实践
2. 学会用AI自动生成Swagger/OpenAPI注解与接口文档
3. 掌握AI从git log生成变更日志与架构文档
4. 搭建文档自动化CI流水线,让文档跟着代码走
为什么程序员讨厌写文档?
每个程序员都听过这句话——"代码写完了,文档补一下"。然后呢?就没有然后了。
文档是项目里最容易被拖延的部分,原因很现实:
- 代码改了文档没改
:改了10个接口,文档里还写着旧参数名,调用方一调试就报错 - API文档严重过时
:线上跑的是v3版本,文档还停留在v1,新人看了直接走弯路 - 新人看不懂
:架构图三年没更新,代码注释等于没有,新人入职一周还在搞环境 - 写文档比写代码累
:代码有逻辑可以推导,文档要"翻译"成人话,还要考虑读者层次
这些痛点的本质是:文档和代码是两个世界,它们之间没有自动同步机制。
AI的价值就在于——从代码反向生成文档,让文档跟着代码走。你不需要"写"文档,你只需要"审"文档。
AI生成README文档
README是项目的门面,但90%的README要么是空壳,要么是三个月前的版本。用AI从项目结构反向生成,5分钟搞定一份专业README。
Prompt模板:从项目结构生成README
# 角色:你是资深技术文档工程师# 任务:根据项目结构和核心代码,生成专业README请分析以下项目结构和关键文件,生成一份完整的README.md:## 输入1. 项目目录结构(tree命令输出)2. pom.xml / package.json / go.mod(依赖与技术栈)3. 核心入口文件(Application.java / main.py / index.ts)4. 配置文件(application.yml / .env.example)## 输出要求README需包含以下模块:- 项目名称与一句话描述- 功能特性(Features)- 技术栈(Tech Stack)- 快速开始(Quick Start):环境要求 + 安装步骤- 项目结构说明(Structure)- API概览(核心接口列表)- 配置说明(Configuration)- 贡献指南(Contributing)- 开源协议(License)风格要求:简洁、可操作、代码块用正确的语法高亮标记。
实战示例:Spring Boot项目生成README
假设我们有一个Spring Boot用户服务项目,目录结构如下:
user-service/├── src/main/java/com/example/userservice/│ ├── UserServiceApplication.java # 启动类│ ├── controller/│ │ └── UserController.java # REST接口│ ├── service/│ │ └── UserService.java # 业务逻辑│ ├── repository/│ │ └── UserRepository.java # 数据访问│ └── model/│ ├── User.java # 实体类│ └── dto/ # 数据传输对象├── src/main/resources/│ └── application.yml # 配置文件└── pom.xml # Maven依赖
把目录结构、pom.xml和Application.java丢给AI,它生成的README长这样:
# README.md(AI生成)# UserService - 用户服务> 基于Spring Boot 3.2的微服务用户管理系统,> 提供用户注册、登录、信息管理等核心能力。## 功能特性- 用户注册与登录(JWT认证)- 用户信息CRUD操作- 基于角色的权限管理(RBAC)- 操作日志审计## 技术栈| 层级 | 技术选型 ||------|---------|| 框架 | Spring Boot 3.2.1 || ORM | MyBatis-Plus 3.5.5 || 数据库 | MySQL 8.0 || 缓存 | Redis 7.0 || 认证 | JWT (jjwt 0.12.3) |## 快速开始### 环境要求- JDK 17+- Maven 3.8+- MySQL 8.0+- Redis 7.0+### 安装步骤```bash# 1. 克隆仓库git clone https://github.com/example/user-service.git# 2. 配置数据库cp src/main/resources/application.yml.example application.yml# 修改数据库连接信息# 3. 启动服务mvn spring-boot:run```...(省略后续模块)
[TIP]README必备的6个模块:① 项目简介(一句话说清做什么)② 快速开始(3分钟能跑起来)③ 项目结构(新人导航图)④ API概览(核心接口列表)⑤ 配置说明(环境变量/配置项)⑥ 贡献指南(让别人能参与)。少一个模块,README就不完整。
AI生成API文档(Swagger/OpenAPI)
API文档是前后端协作的生命线。但手写Swagger注解?一个Controller可能要加20多个@Api、@ApiOperation、@ApiParam注解,工作量比写接口本身还大。
AI可以读取你的Controller代码,自动生成全套Swagger注解。
原始Controller(无Swagger注解)
@RestController@RequestMapping("/api/users")public class UserController {@Autowiredprivate UserService userService;@GetMapping("/{id}")public User getUser(@PathVariable Long id) {return userService.findById(id);}@PostMappingpublic User createUser(@RequestBody UserDTO dto) {return userService.create(dto);}@PutMapping("/{id}")public User updateUser(@PathVariable Long id,@RequestBody UserDTO dto) {return userService.update(id, dto);}@DeleteMapping("/{id}")public void deleteUser(@PathVariable Long id) {userService.delete(id);}}
Prompt:自动添加Swagger注解
# 角色:你是Swagger/OpenAPI文档专家# 任务:为Controller自动添加Swagger注解请为以下Controller代码添加完整的Swagger3注解(springdoc-openapi):要求:1. 类级别添加 @Tag(模块名称+描述)2. 每个接口添加 @Operation(summary + description)3. 参数添加 @Parameter(name + description + required)4. 返回值添加 @ApiResponses(成功/失败场景)5. 请求体添加 @Schema 注解到DTO类6. 保持原有业务逻辑不变,只添加注解输入Controller代码:[粘贴上面的UserController代码]
AI添加注解后的Controller
@RestController@RequestMapping("/api/users")@Tag(name = "用户管理", description = "用户CRUD接口")public class UserController {@Autowiredprivate UserService userService;@GetMapping("/{id}")@Operation(summary = "根据ID查询用户",description = "返回指定ID的用户详细信息")@ApiResponses({@ApiResponse(responseCode = "200", description = "查询成功"),@ApiResponse(responseCode = "404", description = "用户不存在")})public User getUser(@Parameter(name = "id", description = "用户ID", required = true)@PathVariable Long id) {return userService.findById(id);}@PostMapping@Operation(summary = "创建用户",description = "根据传入的用户信息创建新用户")@ApiResponses({@ApiResponse(responseCode = "201", description = "创建成功"),@ApiResponse(responseCode = "400", description = "参数校验失败")})public User createUser(@Parameter(description = "用户创建信息", required = true)@RequestBody UserDTO dto) {return userService.create(dto);}@PutMapping("/{id}")@Operation(summary = "更新用户信息",description = "根据ID更新用户信息")@ApiResponses({@ApiResponse(responseCode = "200", description = "更新成功"),@ApiResponse(responseCode = "404", description = "用户不存在")})public User updateUser(@Parameter(name = "id", description = "用户ID", required = true)@PathVariable Long id,@Parameter(description = "用户更新信息", required = true)@RequestBody UserDTO dto) {return userService.update(id, dto);}@DeleteMapping("/{id}")@Operation(summary = "删除用户",description = "根据ID删除指定用户")@ApiResponses({@ApiResponse(responseCode = "204", description = "删除成功"),@ApiResponse(responseCode = "404", description = "用户不存在")})public void deleteUser(@Parameter(name = "id", description = "用户ID", required = true)@PathVariable Long id) {userService.delete(id);}}
四个接口,AI一次性添加了@Tag、@Operation、@Parameter、@ApiResponses全套注解。启动服务后访问/swagger-ui.html,Swagger页面直接可用。
手写文档 vs AI生成文档
AI生成变更日志(Changelog)
Changelog是版本升级时的"交底文件"——告诉用户改了什么、为什么要改、有没有Breaking Change。但绝大多数项目的CHANGELOG.md要么不存在,要么是git log的原始复制粘贴。
AI可以从git log自动生成符合Keep a Changelog规范的结构化变更日志。
Prompt模板:git log转Changelog
# 角色:你是版本管理专家# 任务:将git log转换为结构化Changelog请将以下git log转换为 Keep a Changelog 格式的CHANGELOG.md:规则:1. 按 commit type 分类:feat→Added, fix→Fixed,perf→Changed, refactor→Changed, docs→Docs,BREAKING CHANGE→Removed/Changed2. 合并语义相同的提交3. 过滤无意义的merge commit和chore4. 每个条目附带commit hash前8位作为引用5. 版本号从tag中提取输入git log:[粘贴 git log --oneline --pretty=format:"%h%s" 输出]
实战示例
假设你的项目有以下git log:
# git log输入a1b2c3d4 feat: 新增用户批量导入功能,支持Excel模板下载e5f6g7h8 fix: 修复用户登录时token过期时间计算错误i9j0k1l2 feat: 添加用户头像上传接口,限制2MBm3n4o5p6 refactor: 重构UserService,抽取公共校验逻辑q7r8s9t0 fix: 修复分页查询totalCount为0的问题u1v2w3x4 BREAKING CHANGE: 用户接口返回字段从userId改为idy5z6a7b8 docs: 更新API文档示例c9d0e1f2 perf: 优化用户列表查询,添加联合索引g3h4i5j6 chore: 升级Spring Boot到3.2.1
AI生成的CHANGELOG.md:
# CHANGELOG.md(AI生成)# ChangelogAll notable changes to this project will be documented in this file.## [v2.1.0] - 2026-09-15### Added- 新增用户批量导入功能,支持Excel模板下载 (a1b2c3d4)- 添加用户头像上传接口,限制2MB (i9j0k1l2)### Fixed- 修复用户登录时token过期时间计算错误 (e5f6g7h8)- 修复分页查询totalCount为0的问题 (q7r8s9t0)### Changed- 重构UserService,抽取公共校验逻辑 (m3n4o5p6)- 优化用户列表查询,添加联合索引 (c9d0e1f2)- ⚠️ BREAKING CHANGE: 用户接口返回字段从 userId 改为 id (u1v2w3x4)### Docs- 更新API文档示例 (y5z6a7b8)### Internal- 升级Spring Boot到3.2.1 (g3h4i5j6)
9条commit被整理成6个分类,BREAKING CHANGE被高亮标注,调用方一眼就能看到迁移风险。这比原始git log可读多了。
AI生成架构文档
架构文档是项目里最"玄学"的部分——图没人画,描述没人写,最后只剩一张三年前的PPT截图。
AI可以分析代码的模块依赖关系,自动生成Mermaid或PlantUML格式的架构图描述,直接在Markdown里渲染。
Prompt:分析模块依赖生成Mermaid图
# 角色:你是软件架构师# 任务:分析项目结构,生成Mermaid架构图请分析以下项目的模块结构和依赖关系,生成 Mermaid C4-Context 架构图:要求:1. 识别系统中的核心组件(服务、数据库、消息队列等)2. 标注组件之间的依赖关系和数据流向3. 使用C4模型的Context层次4. 添加中文标注说明输入项目结构:user-service/├── controller/ → 接收HTTP请求├── service/ → 业务逻辑,调用repository├── repository/ → 数据访问,连接MySQL├── cache/ → Redis缓存层├── mq/ → Kafka消息生产者└── config/ → 配置中心,读取Nacos
AI生成的Mermaid架构图
```mermaidC4Contexttitle 用户服务架构图 (UserService)Person(user, "客户端", "Web/App/第三方调用方")System(userservice, "UserService", "用户管理微服务")System_Ext(mysql, "MySQL", "用户数据持久化")System_Ext(redis, "Redis", "热点数据缓存")System_Ext(kafka, "Kafka", "异步消息队列")System_Ext(nacos, "Nacos", "配置中心")Rel(user, userservice, "HTTP/REST API", "JSON")Rel(userservice, mysql, "读写", "JDBC/MyBatis")Rel(userservice, redis, "缓存读写", "Lettuce")Rel(userservice, kafka, "发送事件", "Protobuf")Rel(userservice, nacos, "拉取配置", "HTTP")UpdateRelStyle(user, userservice, $offsetX="-30")UpdateRelStyle(userservice, mysql, $offsetY="-20")```
这段Mermaid代码放到GitHub README或支持Mermaid渲染的文档工具中,直接渲染成可视化架构图。代码变了,重新生成一次,架构图永远是最新状态。
[TIP]Mermaid vs PlantUML怎么选?GitHub/GitLab原生支持Mermaid渲染,无需额外工具,适合README和Issue。PlantUML功能更强大(时序图、状态图更精细),但需要插件渲染。团队无特殊需求建议优先选Mermaid。
文档自动化CI流水线
前面讲的都是在"手动"让AI生成文档。更进一步——把AI文档生成集成到CI/CD流水线中,代码合并时自动更新文档。
文档自动化流水线设计
┌──────────┐ ┌──────────────┐ ┌──────────────┐ ┌──────────────┐│ 开发者 │────▶│ PR 合并到 │────▶│ AI 分析 │────▶│ 自动更新 ││ 提交PR │ │ main 分支 │ │ 代码 diff │ │ 文档文件 │└──────────┘ └──────────────┘ └──────────────┘ └──────┬───────┘│┌──────────────┐ ┌──────────────┐ ││ 文档随代码 │◀────│ 创建文档 │◀─┘│ 一起上线 │ │ 更新 PR │└──────────────┘ └──────────────┘▲│┌──────┴───────┐│ 人工 Review ││ 确认无误后 ││ 合并文档 PR │└──────────────┘
GitHub Actions配置示例
# .github/workflows/doc-auto-update.ymlname: AI Doc Auto Updateon:pull_request:types: [closed]branches: [main]jobs:update-docs:if: github.event.pull_request.merged == trueruns-on: ubuntu-lateststeps:- name: Checkout codeuses: actions/checkout@v4with:fetch-depth: 0- name: Get changed filesid: changedrun: |git diff --name-only HEAD~1 HEAD > changed.txtecho "files=$(cat changed.txt)" >> $GITHUB_OUTPUT- name: AI generate docsenv:AI_API_KEY: ${{ secrets.AI_API_KEY }}run: |# 分析diff,判断需要更新哪些文档# 调用AI生成更新后的文档内容python scripts/ai_doc_generator.py \--diff changed.txt \--output docs/- name: Create doc update PRuses: peter-evans/create-pull-request@v6with:title: "docs: AI自动更新文档"body: "本PR由CI自动生成,请review文档变更"branch: docs/auto-updatelabels: documentation, auto-generated
流程说明:
- PR合并触发
:代码合并到main分支时自动触发 - AI分析diff
:分析改了哪些文件,判断需要更新哪些文档 - 自动生成文档
:调用AI生成更新后的README/Changelog/API文档 - 创建文档PR
:自动创建一个文档更新PR,等待人工review - 人工确认
:review通过后合并,文档和代码同步上线
[!]AI生成文档仍需人工review,不能完全自动化上线。AI可能误解代码意图,生成不准确的描述。特别是涉及安全策略、认证流程、业务规则的文档,必须由开发者确认后才能合并。CI流水线做的是"生成和提醒",不是"替代人工判断"。
AI文档生成工具对比
除了自己写Prompt,市面上也有专门的AI文档生成工具。各有侧重,按需选择:
建议:小型项目用Cursor/Copilot Chat即时生成,中大型项目用Mintlify搭文档站,有特殊格式需求的团队用自定义Prompt + CI流水线。
回复关键词获取福利
回复「AI文档生成」获取本课全部资料:
1. README生成Prompt模板(含6种项目类型变体)
2. Swagger注解自动生成脚本(支持Spring Boot 3.x)
3. Changelog自动化GitHub Actions配置文件
4. Mermaid架构图模板库(C4/时序图/流程图)
AI编程交流群
文档自动化、CI流水线、Prompt工程实战经验分享
群内定期推送文档生成最佳实践与工具评测
遇到文档难题?群友帮你一起搞定
扫码加入交流群
下周预告:第十五课 · AI辅助代码迁移与版本升级
Java 8升17、Python 2升3、框架大版本升级——AI帮你搞定最痛苦的迁移工作