AI Coding 可以理解为把人工智能(Artificial Intelligence,AI)能力接入 IDE(Integrated Development Environment,集成开发环境)或代码仓库后的开发辅助方式。它能读代码、写代码、解释逻辑、生成脚本、整理文档,也能根据需求给出实现方案。
但在后端开发里,AI Coding 不是“自动完成需求”的黑盒。它更像一个编程能力很强、通用知识丰富、但不了解你当前业务背景的新同事。你给它足够清楚的需求、代码上下文和约束,它就能写出接近项目风格的实现;你只给一句“帮我做个订单导出”,它就很容易猜错领域模型、接口边界、权限规则和异常处理方式。
后端项目通常有几个特点:
- 业务规则多,很多逻辑藏在历史代码、配置和数据库约束里;
- 模块之间依赖复杂,改一个接口可能影响多个调用方;
- 代码不只要能跑,还要考虑事务、并发、权限、幂等、审计、性能和可维护性;
- 需求会变化,开发过程通常需要多轮沟通和迭代。
所以,AI Coding 的核心用法不是“让 AI 直接写完”,而是把它纳入一个可控的工程流程:人负责需求理解、上下文组织和质量判断,AI 负责加速分析、生成草稿、补齐样板代码和辅助验证。
一、先纠正两个常见误区
1. 只看最终输出,不看实现过程
有些开发者使用 AI Coding 时,只关注它最后生成了哪些文件、代码能不能编译通过,而忽略了中间的设计过程。这在后端开发里风险很高。
代码能编译通过,不代表功能正确。常见问题包括:
| 问题类型 | 表现 | 后果 |
|---|---|---|
| 业务理解错误 | 把“已支付订单”理解成“已创建订单” | 数据导出、统计、结算结果错误 |
| 领域模型用错 | 新建了一套重复模型,没有复用已有实体 | 系统出现两套语义相近但行为不同的代码 |
| 事务边界不对 | 在循环中多次提交,或漏掉事务注解 | 部分成功、部分失败,数据状态不一致 |
| 权限校验缺失 | 只实现功能接口,没有接入鉴权逻辑 | 产生越权访问风险 |
| 异常处理粗糙 | 直接吞异常或返回通用错误 | 排查困难,调用方无法正确处理失败场景 |
AI 生成代码后,开发者必须能回答几个问题:
- 它为什么这么改?
- 它改了哪些模块?
- 它有没有复用现有代码?
- 它有没有引入额外副作用?
- 它的边界条件有没有覆盖?
- 它的失败路径是否符合系统约定?
如果这些问题答不上来,就不能把输出直接合并。
2. 把 AI 当成懂业务的专家
AI 擅长通用编程模式,比如 Controller、Service、Repository 的分层代码,常见 SQL(Structured Query Language,结构化查询语言)查询,CSV(Comma-Separated Values,逗号分隔值)到 JSON(JavaScript Object Notation,JavaScript 对象表示法)的转换脚本,接口文档模板等。
但它默认不了解你的业务语义。
比如同样是“冻结用户”,不同系统里可能代表完全不同的含义:
| 系统 | “冻结用户”可能意味着什么 |
|---|---|
| 交易系统 | 禁止下单、提现、退款 |
| 内容系统 | 禁止发帖、评论、私信 |
| 权限系统 | 禁止登录,但保留历史授权记录 |
| 风控系统 | 用户进入人工审核流程,不一定立即禁用 |
如果提示词只写“实现冻结用户接口”,AI 只能根据常见经验猜测。后端开发里真正重要的部分,往往正是这些业务细节。
更合理的定位是:
AI Coding = 编程能力强的执行者 + 通用方案生成器 + 文档整理助手
开发者 = 需求解释者 + 上下文组织者 + 架构决策者 + 质量把关人
二、用外部 Markdown 管理 AI 上下文
AI Coding 的上下文窗口有限。即使工具支持读取代码仓库,也不适合每次都让它重新扫描全部文件。复杂项目里,更稳定的方式是把关键上下文沉淀到 Markdown 文档中,让 AI 在不同会话中读取这些文档,恢复必要背景。
核心思路是:不要把所有信息塞进一次对话,而是把需求、代码结构、设计决策和迭代记录放到外部文件里。
flowchart LR
A[需求输入] --> B[人工拆解需求]
B --> C[筛选相关代码文件]
C --> D[生成上下文 Markdown]
D --> E[AI Coding 读取上下文]
E --> F[生成方案或代码]
F --> G[人工审核]
G --> H[更新 Markdown]
H --> E
这个循环解决了两个问题:
- 会话切换后,不需要从零解释背景;
- 多轮修改后,关键决策不会被上下文压缩丢失。
1. 需求理解与文件筛选
启动 AI 辅助开发之前,不要急着让它写代码。更稳妥的做法是先把需求拆成三类信息:
| 信息类型 | 需要弄清楚的问题 |
|---|---|
| 功能目标 | 要解决什么业务问题,用户是谁,成功结果是什么 |
| 约束条件 | 权限、性能、数据范围、兼容性、开关配置、灰度规则 |
| 影响范围 | 要改哪些模块,哪些接口或任务会受影响 |
然后在代码仓库里找到相关文件。可以先用搜索工具定位领域词、接口名、表名、事件名:
# 搜索业务关键词
rg "OrderExport|订单导出|exportOrder" src/
# 搜索接口路径
rg "/api/orders|/orders/export" src/
# 搜索数据库表或字段
rg "order_status|payment_status|order_export" src/
# 查看模块结构
tree -L 3 src/main/java
文件筛选时,不需要把整个仓库都交给 AI。更合理的是选出这些内容:
- 入口层:Controller、API 定义、路由配置;
- 业务层:Service、领域服务、策略类;
- 数据层:Repository、Mapper、实体对象、数据库迁移脚本;
- 公共约定:异常码、权限注解、分页模型、响应结构;
- 参考实现:同类功能的已有代码。
2. 建立上下文文档
上下文文档不需要写成正式设计文档,但必须结构清晰。推荐至少维护三个 Markdown 文件。
docs/ai/
├── requirement-context.md # 需求上下文
├── repo-map.md # 代码仓库相关结构
└── implementation-plan.md # 实现方案与迭代记录
requirement-context.md 可以这样写:
# 需求上下文:订单导出功能
## 业务目标
为运营人员提供订单导出能力,支持按时间范围、订单状态、支付状态筛选订单,并导出为 CSV 文件。
## 使用角色
- 运营管理员:可以导出全部订单
- 商家管理员:只能导出自己店铺的订单
## 输入条件
- startTime:必填,导出开始时间
- endTime:必填,导出结束时间
- orderStatus:可选
- paymentStatus:可选
- shopId:商家管理员场景由登录上下文决定,不允许前端任意传入
## 输出结果
- CSV 文件
- 字段包括:订单号、店铺名称、支付金额、订单状态、支付状态、创建时间
## 关键约束
- 最大导出时间范围:31 天
- 单次最多导出 100000 条
- 必须做权限校验
- 导出任务异步执行
- 需要记录操作审计日志
## 不做什么
- 不支持跨租户导出
- 不支持自定义导出字段
- 不做实时大文件同步返回
repo-map.md 用来描述相关代码位置:
# 代码仓库上下文:订单模块
## 入口层
- OrderController:订单查询相关接口
- ExportTaskController:导出任务创建与查询接口
## 业务层
- OrderQueryService:订单查询逻辑
- ExportTaskService:导出任务创建、状态流转
- PermissionService:权限判断
## 数据层
- OrderRepository:订单数据读取
- ExportTaskRepository:导出任务持久化
## 公共约定
- ApiResponse<T>:统一响应结构
- BizException:业务异常
- ErrorCode:错误码枚举
- PageRequest:分页请求结构
## 可参考实现
- UserExportService:用户导出的异步任务实现
- ProductExportService:商品导出的 CSV 写入逻辑
implementation-plan.md 记录设计方案和变更:
# 实现方案:订单导出
## 当前方案
1. 新增创建导出任务接口
2. 校验权限与查询条件
3. 写入 export_task 表,状态为 PENDING
4. 后台任务消费导出请求
5. 分页查询订单数据并写入 CSV
6. 上传文件到对象存储
7. 更新任务状态为 SUCCESS 或 FAILED
## 待确认问题
- CSV 文件保存时长是多少?
- 是否需要导出收货人手机号?
- 失败任务是否允许重试?
## 变更记录
- 2026-06-07:确定采用异步任务,避免大文件同步返回
3. 跨会话传递上下文
复杂任务通常会经历多个会话。为了避免上下文断裂,可以在新会话开始时直接要求 AI 读取指定文档。
请先阅读以下三个文件,恢复当前任务上下文:
1. docs/ai/requirement-context.md
2. docs/ai/repo-map.md
3. docs/ai/implementation-plan.md
阅读后请只输出:
- 你理解的业务目标
- 涉及的核心模块
- 当前实现计划
- 仍需确认的问题
暂时不要修改代码。
这个提示词有两个关键点:
- 先让 AI 复述理解,避免它带着错误上下文直接动代码;
- 明确“暂时不要修改代码”,把分析阶段和编码阶段分开。
4. 分阶段保存,避免上下文压缩丢信息
当任务很大时,不要让 AI 一次性阅读大量文件再生成完整方案。可以把分析拆成多个阶段,每个阶段结束后都要求它更新 Markdown。
flowchart TD
A[分析 Controller 层] --> B[更新 repo-map.md]
B --> C[分析 Service 层]
C --> D[更新 repo-map.md]
D --> E[分析数据层]
E --> F[更新 repo-map.md]
F --> G[生成 implementation-plan.md]
这种做法会慢一点,但稳定性更高。尤其是老项目、微服务项目、模块命名不统一的项目,外部文档比长对话更可靠。
三、开发者要成为 AI 输出的质量把关人
AI Coding 输出的代码不能只靠“看起来像那么回事”判断。后端开发要建立一套检查体系,从功能、代码质量、影响范围、测试和上线风险几个维度验证。
1. 先理解 AI 的能力边界
| AI Coding 擅长的事 | 需要人工重点把关的事 |
|---|---|
| 生成模板代码 | 业务规则是否正确 |
| 根据参考代码模仿风格 | 是否破坏现有架构边界 |
| 编写常规脚本 | 数据口径是否符合业务定义 |
| 整理文档大纲 | 关键结论是否准确 |
| 补充单元测试样例 | 测试是否覆盖真实风险 |
| 解释已有代码 | 解释是否漏掉隐含依赖 |
AI 可以很快生成代码,但它不知道哪些规则是“绝对不能错”的。比如金额计算、权限判断、库存扣减、审批状态流转,这些逻辑必须由开发者确认。
2. 用五层检查法判断输出质量
flowchart TD
A[AI 输出代码] --> B[需求匹配检查]
B --> C[代码仓库一致性检查]
C --> D[实现细节检查]
D --> E[测试覆盖检查]
E --> F[性能与安全风险检查]
F --> G{是否通过}
G -- 是 --> H[提交代码]
G -- 否 --> I[反馈问题并迭代]
I --> A
每一层都要有明确检查项。
| 检查层 | 关注点 | 示例问题 |
|---|---|---|
| 需求匹配 | 是否实现正确功能 | 是否遗漏权限、状态、时间范围限制 |
| 仓库一致性 | 是否符合现有架构 | 是否复用统一异常、响应、分页、权限组件 |
| 实现细节 | 代码是否可靠 | 事务是否正确,空值是否处理,边界是否覆盖 |
| 测试覆盖 | 是否可验证 | 是否有单元测试、集成测试、异常路径测试 |
| 风险检查 | 是否影响线上稳定性 | 是否有慢查询、越权、数据泄露、重复执行问题 |
3. 常见 AI 输出问题与识别方式
| 问题 | 识别方式 | 处理办法 |
|---|---|---|
| 幻造不存在的类或方法 | 编译失败,或搜索不到引用 | 要求 AI 基于真实文件重新生成 |
| 重复造轮子 | 项目已有类似实现,但 AI 新写一套 | 提供参考实现,让 AI 按现有模式改 |
| 业务条件漏判 | 正常路径能跑,异常路径错误 | 补充边界条件和反例 |
| 事务范围错误 | 多表更新时状态不一致 | 明确事务边界和失败回滚规则 |
| 查询性能差 | 循环查库、无分页、无索引字段过滤 | 要求改为批量查询或分页处理 |
| 权限缺失 | 接口只校验参数,不校验身份 | 提供权限组件和调用示例 |
| 错误码随意新增 | 与团队错误码体系不一致 | 要求复用已有错误码或补充枚举 |
给 AI 反馈时,不要只写“这里不对”。更好的反馈格式是:
问题:
当前实现直接使用请求参数中的 shopId 查询订单。
为什么不对:
商家管理员只能导出自己店铺的订单,shopId 必须从登录上下文获取,不能由前端传入,否则存在越权风险。
请修改:
1. 从 LoginUserContext 中获取当前用户身份;
2. 如果是商家管理员,使用上下文中的 shopId;
3. 如果是运营管理员,允许按请求参数筛选 shopId;
4. 补充越权访问的单元测试。
这类反馈包含“问题、原因、修改要求、测试要求”,AI 更容易给出可用结果。
四、后端项目的 AI Coding 标准流程
后端开发可以拆成两个阶段:系统分析阶段和代码开发阶段。两个阶段的输入、输出和检查方式不同,不要混在一次对话里完成。
1. 阶段一:从 PRD 到系统分析
PRD(Product Requirements Document,产品需求文档)进入开发前,需要先转成工程语言:涉及哪些模块、复用哪些代码、新增哪些能力、风险在哪里。
flowchart LR
A[输入 PRD] --> B[人工提取需求要点]
B --> C[筛选相关代码文件]
C --> D[AI 辅助分析现有实现]
D --> E[生成系统分析文档]
E --> F[人工审核与补充]
F --> G{分析是否准确}
G -- 否 --> D
G -- 是 --> H[进入代码开发阶段]
系统分析阶段可以让 AI 做这些事:
- 根据 PRD 提取功能点;
- 根据文件列表解释现有模块职责;
- 对比已有实现,判断哪些代码可以复用;
- 生成初步实现方案;
- 列出待确认问题和风险点。
推荐提示词:
你是后端研发助手。请基于 PRD 和代码仓库上下文,生成系统分析文档。
输入材料:
1. PRD 内容:见 docs/prd/order-export.md
2. 代码结构说明:见 docs/ai/repo-map.md
3. 参考实现:UserExportService、ProductExportService
输出要求:
1. 业务目标
2. 涉及模块
3. 可复用代码
4. 需要新增的类和接口
5. 数据库变更
6. 权限与安全要求
7. 异常与错误码设计
8. 测试计划
9. 待确认问题
限制:
- 不要直接修改代码
- 不要编造不存在的类
- 对不确定的点标记为“待确认”
分析文档不是一次生成就结束。人工审核时要重点看:
- 是否误解 PRD;
- 是否遗漏现有模块;
- 是否引入不必要的新设计;
- 是否忽略事务、权限、幂等、性能;
- 是否把待确认问题说清楚。
2. 阶段二:从系统分析到代码实现
系统分析通过后,再开启新的代码开发会话。新会话只读取必要上下文,不再混入大量需求讨论历史。
flowchart TD
A[新会话读取 Markdown 上下文] --> B[确认开发任务]
B --> C[指定目标目录和参考代码]
C --> D[AI 生成小批量代码]
D --> E[人工 Review]
E --> F[运行测试]
F --> G{是否通过}
G -- 是 --> H[Git 提交可用版本]
H --> I{需求是否完成}
I -- 否 --> D
I -- 是 --> J[更新文档并准备合并]
G -- 否 --> K[反馈具体问题]
K --> D
代码开发阶段要控制修改粒度。不要一次要求 AI 完成 Controller、Service、Repository、数据库迁移、测试和文档。更好的拆法是:
- 先生成接口入参与出参对象;
- 再生成 Service 主流程;
- 再补数据访问层;
- 再接入权限与异常;
- 再补测试;
- 再更新接口文档。
每完成一个可运行的小版本,就提交一次。
# 查看 AI 修改了哪些文件
git status
# 查看具体差异
git diff
# 运行测试
mvn test
# 提交一个可回退的小版本
git add src/main/java docs/ai
git commit -m "feat: add order export task creation flow"
频繁提交不是为了制造提交记录,而是为了降低回退成本。AI 多轮修改后,如果没有中间版本,问题定位会很麻烦。
3. 开发阶段的提示词模板
请基于 docs/ai/implementation-plan.md 实现订单导出任务创建接口。
开发范围:
- 只修改订单导出相关文件
- 本轮只实现 Controller、Request、Response、Service 主流程
- 暂时不要实现后台任务消费逻辑
参考代码:
- UserExportController
- UserExportService
- ApiResponse
- BizException
- PermissionService
实现要求:
1. 校验 startTime、endTime,最大范围 31 天;
2. 根据登录用户判断权限;
3. 创建导出任务,初始状态为 PENDING;
4. 返回 taskId;
5. 使用项目已有错误码风格;
6. 补充必要的单元测试。
输出前请说明:
- 新增或修改了哪些文件;
- 每个文件的职责;
- 仍未实现的内容。
这个提示词把范围、参考代码、实现要求和输出格式都说清楚,可以减少 AI 自由发挥的空间。
五、用 AI Coding 生成 Python 数据处理脚本
后端开发不只有业务接口,还经常会遇到批量数据处理任务,比如:
- CSV 转 JSON;
- 批量生成 SQL 脚本;
- 日志清洗和统计;
- 多语言文案整理;
- 测试数据生成;
- 配置文件批量转换。
这类任务很适合让 AI Coding 辅助,因为规则通常明确,输入输出容易验证。
flowchart LR
A[准备样例数据] --> B[定义处理规则]
B --> C[AI 生成脚本]
C --> D[本地执行]
D --> E[校验输出]
E --> F{是否正确}
F -- 否 --> G[补充反例和错误样本]
G --> C
F -- 是 --> H[沉淀脚本和使用说明]
1. 数据脚本需求要写清楚
给 AI 生成脚本前,至少准备四类信息:
| 信息 | 示例 |
|---|---|
| 输入格式 | CSV 字段:key、zh_CN、en_US、module |
| 输出格式 | JSON 对象,按 module 分组 |
| 转换规则 | 空值跳过,重复 key 报错 |
| 校验规则 | key 必填,en_US 必填,module 必填 |
提示词示例:
请生成一个 Python 脚本,把 i18n.csv 转成 messages.json。
输入 CSV 字段:
- module:模块名,必填
- key:文案 key,必填
- zh_CN:中文文案,可为空
- en_US:英文文案,必填
输出 JSON 格式:
{
"moduleName": {
"key": {
"zh_CN": "...",
"en_US": "..."
}
}
}
规则:
1. module、key、en_US 为空时报错;
2. 同一个 module 下 key 重复时报错;
3. 输出文件使用 UTF-8;
4. 命令行参数支持 --input 和 --output;
5. 控制台打印处理成功数量和错误行号。
2. 脚本示例
import argparse
import csv
import json
from pathlib import Path
REQUIRED_FIELDS = ["module", "key", "en_US"]
def validate_row(row: dict, line_no: int) -> list[str]:
errors = []
for field in REQUIRED_FIELDS:
if not row.get(field, "").strip():
errors.append(f"line {line_no}: field '{field}' is required")
return errors
def convert(input_path: Path) -> dict:
result: dict[str, dict[str, dict[str, str]]] = {}
errors: list[str] = []
with input_path.open("r", encoding="utf-8-sig", newline="") as file:
reader = csv.DictReader(file)
for line_no, row in enumerate(reader, start=2):
row_errors = validate_row(row, line_no)
if row_errors:
errors.extend(row_errors)
continue
module = row["module"].strip()
key = row["key"].strip()
result.setdefault(module, {})
if key in result[module]:
errors.append(f"line {line_no}: duplicated key '{key}' in module '{module}'")
continue
result[module][key] = {
"zh_CN": row.get("zh_CN", "").strip(),
"en_US": row["en_US"].strip(),
}
if errors:
raise ValueError("\n".join(errors))
return result
def main() -> None:
parser = argparse.ArgumentParser()
parser.add_argument("--input", required=True, help="input csv file path")
parser.add_argument("--output", required=True, help="output json file path")
args = parser.parse_args()
data = convert(Path(args.input))
output_path = Path(args.output)
output_path.write_text(
json.dumps(data, ensure_ascii=False, indent=2),
encoding="utf-8",
)
total = sum(len(items) for items in data.values())
print(f"converted {total} records into {output_path}")
if __name__ == "__main__":
main()
执行方式:
python convert_i18n.py --input i18n.csv --output messages.json
这类脚本生成后,开发者仍然要检查:
- 错误行号是否准确;
- 编码是否处理 UTF-8 BOM;
- 重复数据是否被识别;
- 空字段是否按规则处理;
- 输出结构是否能被目标系统消费。
六、Agent 应用开发中的提示词工程
Agent 可以理解为围绕一个目标运行的智能应用。它可能只调用一次 LLM(Large Language Model,大语言模型),也可能串联多个模型、工具、检索步骤和业务接口。
Agent 开发的难点通常不在“写一段提示词”,而在工作流设计:
- 输入是什么;
- 每一步由谁处理;
- 中间结果如何传递;
- 失败如何兜底;
- 输出格式如何稳定;
- 哪些内容需要人工确认。
1. Agent 设计流程
flowchart TD
A[定义业务场景] --> B[识别用户与目标]
B --> C[定义输入输出格式]
C --> D[判断是否需要多步骤工作流]
D --> E[设计提示词与工具调用]
E --> F[在 Agent 平台搭建流程]
F --> G[使用样例验证]
G --> H{结果是否稳定}
H -- 否 --> I[调整提示词或工作流]
I --> E
H -- 是 --> J[沉淀版本]
2. 单模型与多模型工作流的区别
| 类型 | 适合场景 | 风险 |
|---|---|---|
| 单 LLM | 问答、摘要、简单分类、格式转换 | 复杂任务容易遗漏步骤 |
| 多 LLM 工作流 | 审核、分析、生成、校验分离的复杂任务 | 流程设计复杂,中间结果需要约束 |
| LLM + 工具 | 查数据库、调用接口、读取文件、生成报告 | 工具权限、异常处理和结果可信度要控制 |
| LLM + 人工确认 | 财务、审批、发布、敏感操作 | 需要设计人工确认节点 |
3. 提示词结构模板
一个可维护的提示词应该包含角色、任务、输入、输出、约束和示例。
角色:
你是一个代码审查助手,负责检查后端代码中的风险。
任务:
根据输入的 Git diff,识别功能正确性、性能、安全、可维护性问题。
输入:
- Git diff
- 相关需求说明
- 项目编码规范
检查范围:
1. 是否符合需求;
2. 是否存在空指针、越权、事务错误;
3. 是否存在 N+1 查询;
4. 是否缺少必要测试;
5. 是否破坏已有接口兼容性。
输出格式:
请以 JSON 输出:
{
"riskLevel": "LOW | MEDIUM | HIGH",
"issues": [
{
"type": "SECURITY | PERFORMANCE | BUG | STYLE",
"file": "文件路径",
"line": "行号或代码片段",
"description": "问题说明",
"suggestion": "修改建议"
}
]
}
限制:
- 不要输出无依据的问题;
- 不要编造不存在的代码;
- 如果信息不足,请在 issues 中说明需要补充的上下文。
提示词工程的关键不是把话写得很长,而是让模型知道边界:做什么、不做什么、按什么格式输出、遇到不确定信息怎么处理。
七、用 AI Coding 整理技术文档
技术文档很适合与 AI Coding 协作,尤其是系统设计、接口说明、周报、排障记录和知识沉淀。这里的重点不是让 AI 随意发挥,而是先给结构,再让它填充内容。
flowchart LR
A[提供文档目标] --> B[给出大纲]
B --> C[标记重点内容]
C --> D[AI 生成 Markdown]
D --> E[人工校验关键结论]
E --> F[补充图表和代码]
F --> G[发布到协作平台]
1. 文档生成提示词
请根据以下要求生成系统设计文档,输出 Markdown。
文档目标:
说明订单导出功能的后端设计,供研发评审使用。
章节结构:
1. 背景与目标
2. 需求范围
3. 总体架构
4. 核心流程
5. 接口设计
6. 数据库设计
7. 异常处理
8. 权限与安全
9. 测试计划
10. 风险与待确认问题
重点要求:
- 权限与安全部分必须详细写;
- 核心流程使用 Mermaid flowchart;
- 接口设计使用表格;
- 不确定的点不要编造,统一放到“待确认问题”。
2. 图表选择
| 图表类型 | 适合表达什么 |
|---|---|
| Mermaid flowchart | 业务流程、系统架构、任务流转 |
| Mermaid sequenceDiagram | 服务之间的调用顺序 |
| Mermaid classDiagram | 类和领域模型关系 |
| Mermaid stateDiagram | 状态机,例如订单状态、审批状态 |
| Mermaid gantt | 项目计划和排期 |
| PlantUML 用例图 | 用户与系统功能关系 |
| PlantUML 部署图 | 服务、节点、中间件部署关系 |
| 表格 | 参数、方案对比、字段说明 |
| 代码块 | 接口示例、配置、命令、脚本 |
比如异步导出任务可以用状态图表达:
stateDiagram-v2
[*] --> PENDING: 创建任务
PENDING --> RUNNING: 后台任务开始处理
RUNNING --> SUCCESS: 文件生成成功
RUNNING --> FAILED: 处理失败
FAILED --> RUNNING: 手动重试
SUCCESS --> EXPIRED: 文件过期清理
图表之后要解释状态含义,而不是只放图。
| 状态 | 含义 |
|---|---|
| PENDING | 任务已创建,等待后台消费 |
| RUNNING | 正在查询数据并生成文件 |
| SUCCESS | 文件已生成,可下载 |
| FAILED | 任务失败,可查看错误原因 |
| EXPIRED | 文件超过保留期,已被清理 |
八、沉淀提示词和最佳实践
团队使用 AI Coding 一段时间后,会积累很多可复用资产:
- 需求分析提示词;
- 代码开发提示词;
- Bug 分析提示词;
- 接口文档模板;
- 系统设计文档模板;
- 数据处理脚本模板;
- Agent 工作流模板。
如果这些内容只散落在个人聊天记录里,很难复用。更合理的方式是建立提示词和实践库。
1. 提示词模板应该记录哪些字段
| 字段 | 说明 |
|---|---|
| 名称 | 例如“后端新功能系统分析模板” |
| 适用场景 | 新功能、Bug 修复、代码审查、文档生成 |
| 输入材料 | PRD、代码路径、错误日志、Git diff |
| 提示词正文 | 可直接复制使用的模板 |
| 输出格式 | Markdown、JSON、表格、代码块 |
| 使用示例 | 一组真实但脱敏的输入输出 |
| 注意事项 | 常见误用方式和边界 |
| 版本记录 | 每次调整原因和效果 |
2. 提示词也要版本管理
提示词不是写完就固定不变。一次实际任务结束后,可以回顾几个问题:
- 哪些描述让 AI 理解更准确;
- 哪些地方导致 AI 自由发挥过多;
- 哪些输出格式最方便人工 Review;
- 是否需要加入反例;
- 是否需要加入“不允许做什么”。
一个提示词从“能用”到“稳定可复用”,通常需要经过多次任务打磨。团队层面可以把成功模板沉淀下来,让新成员直接使用成熟流程,而不是从零摸索。
九、最小可执行落地清单
把 AI Coding 引入后端开发,不需要一开始就搭建复杂平台。可以从一套最小流程开始:
- 每个复杂需求创建
docs/ai/目录; - 用
requirement-context.md记录需求、约束和不做的内容; - 用
repo-map.md记录相关代码文件和可复用实现; - 用
implementation-plan.md记录实现方案、待确认问题和变更; - 分析阶段只让 AI 生成方案,不让它直接改代码;
- 编码阶段控制修改范围,小批量生成、小批量提交;
- 每次 AI 输出后按五层检查法 Review;
- 数据转换、文档整理、Agent 提示词设计可以优先交给 AI 辅助;
- 成功的提示词和流程及时沉淀成团队模板。
AI Coding 真正改变的不是“谁来敲代码”,而是开发者的工作重心。重复性编码、格式转换、草稿生成可以更多交给工具;需求理解、架构判断、风险控制和质量把关,仍然必须由开发者负责。这样协作时,AI 才会从一个不稳定的代码生成器,变成后端研发流程中的可靠加速器。