芥末
发布于 2026-01-07 / 0 阅读
0
0

AI Coding 在后端开发中的上下文管理与质量把关实践

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、数据库迁移、测试和文档。更好的拆法是:

  1. 先生成接口入参与出参对象;
  2. 再生成 Service 主流程;
  3. 再补数据访问层;
  4. 再接入权限与异常;
  5. 再补测试;
  6. 再更新接口文档。

每完成一个可运行的小版本,就提交一次。

# 查看 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 引入后端开发,不需要一开始就搭建复杂平台。可以从一套最小流程开始:

  1. 每个复杂需求创建 docs/ai/ 目录;
  2. requirement-context.md 记录需求、约束和不做的内容;
  3. repo-map.md 记录相关代码文件和可复用实现;
  4. implementation-plan.md 记录实现方案、待确认问题和变更;
  5. 分析阶段只让 AI 生成方案,不让它直接改代码;
  6. 编码阶段控制修改范围,小批量生成、小批量提交;
  7. 每次 AI 输出后按五层检查法 Review;
  8. 数据转换、文档整理、Agent 提示词设计可以优先交给 AI 辅助;
  9. 成功的提示词和流程及时沉淀成团队模板。

AI Coding 真正改变的不是“谁来敲代码”,而是开发者的工作重心。重复性编码、格式转换、草稿生成可以更多交给工具;需求理解、架构判断、风险控制和质量把关,仍然必须由开发者负责。这样协作时,AI 才会从一个不稳定的代码生成器,变成后端研发流程中的可靠加速器。


评论