AI编程 工作流自动化教程｜附配置文件

在过去几年里，AI 编程工具从“代码补全助手”逐渐演变为“软件开发协作伙伴”。无论是需求拆解、代码生成、单元测试、文档编写，还是代码审查、CI/CD 自动化，AI 都可以显著提升开发效率。

但很多人使用 AI 编程工具时，仍然停留在“打开聊天窗口，复制粘贴代码，让 AI 帮忙改一改”的阶段。这种方式虽然有帮助，但效率并不稳定，也很难融入团队开发流程。

真正高效的做法，是把 AI 编程能力接入到标准化工作流中，让它在合适的节点自动参与，例如：

• 提交代码前自动检查格式和潜在问题；
• Pull Request 创建后自动生成变更摘要；
• 自动补全测试用例；
• 自动更新接口文档；
• 自动根据 Issue 生成开发任务；
• 自动分析 CI 失败原因；
• 自动进行 Code Review 辅助审查。

本文将从实践角度出发，介绍一套适合个人开发者和中小团队使用的 AI 编程工作流自动化方案，并附带可直接参考的配置文件。

一、为什么需要 AI 编程工作流自动化？

很多开发者刚开始使用 AI 编程工具时，会觉得它“很聪明”，但用久之后也会遇到一些问题。

例如：

1. 每次都要手动描述上下文

   你需要告诉 AI 项目背景、技术栈、代码结构、当前问题、预期结果。重复输入这些内容很浪费时间。

2. AI 输出质量不稳定

   同一个问题，不同的描述方式会得到完全不同的结果。如果团队成员各自使用不同提示词，产出的代码风格也会不一致。

3. 很难和现有工程流程结合

   开发团队通常已经有 Git、CI/CD、代码规范、测试流程。如果 AI 只是单独存在于聊天窗口里，它就无法真正参与软件交付链路。

4. 缺少可追溯性

   AI 生成了什么建议？是否被采纳？是否引入 bug？这些内容如果没有沉淀，就很难复盘。

5. 无法形成团队标准

   个人用 AI 可以随意，但团队使用 AI 必须有规则，包括代码风格、安全边界、审查规范、提示词模板等。

因此，我们需要把 AI 能力纳入标准开发工作流，让它从“临时助手”升级为“自动化协作者”。

二、整体工作流设计

一个完整的 AI 编程自动化工作流，可以分为以下几个阶段：

需求输入
  ↓
Issue 规范化
  ↓
AI 辅助任务拆解
  ↓
分支创建与开发
  ↓
AI 代码生成 / 重构 / 测试补全
  ↓
本地自动检查
  ↓
提交代码
  ↓
Pull Request
  ↓
AI 自动生成 PR 摘要
  ↓
AI 辅助 Code Review
  ↓
CI/CD 自动测试与构建
  ↓
合并发布
  ↓
AI 自动生成变更日志

这套流程的核心目标不是让 AI 替代开发者，而是让 AI 在重复性强、规则明确、上下文清晰的环节发挥作用。

其中最值得自动化的几个节点包括：

三、推荐技术栈

为了方便落地，本文以一个常见的前端或全栈项目为例，假设项目使用：

• GitHub 作为代码托管平台；
• GitHub Actions 作为 CI/CD 工具；
• Node.js / TypeScript 作为主要技术栈；
• ESLint / Prettier 作为代码规范工具；
• Husky / lint-staged 作为提交前检查工具；
• AI 工具可以是 ChatGPT、Claude、Cursor、GitHub Copilot、CodeRabbit 或自建 OpenAI API 服务。

即使你的项目不是 Node.js 技术栈，整体思路也可以迁移到 Python、Go、Java、Rust 等项目中。

四、项目目录结构建议

为了让 AI 更好地理解项目，我们建议在项目根目录下增加一个 .ai 目录，用于存放 AI 工作流相关配置、提示词和规范文档。

推荐结构如下：

your-project/
├── .ai/
│   ├── context.md
│   ├── coding-rules.md
│   ├── review-rules.md
│   ├── test-rules.md
│   └── prompts/
│       ├── issue-to-task.md
│       ├── pr-summary.md
│       ├── code-review.md
│       └── ci-failure-analysis.md
├── .github/
│   ├── workflows/
│   │   ├── ci.yml
│   │   └── ai-pr-summary.yml
│   └── pull_request_template.md
├── src/
├── tests/
├── package.json
├── eslint.config.js
├── prettier.config.js
└── README.md

这里的 .ai 目录非常关键。它相当于给 AI 准备的“项目说明书”。当 AI 工具支持读取项目文件时，它可以根据这些说明生成更符合项目规范的代码。

五、配置项目上下文：context.md

首先，我们需要准备项目上下文文件，让 AI 快速了解项目背景、技术栈和目录规范。

创建文件：

mkdir -p .ai/prompts
touch .ai/context.md

示例配置如下：

# Project Context

## 项目简介

这是一个基于 TypeScript 的 Web 应用项目，主要用于构建企业内部管理系统。

## 技术栈

- 语言：TypeScript
- 前端框架：React
- 构建工具：Vite
- 状态管理：Zustand
- UI 组件库：Ant Design
- 测试框架：Vitest + React Testing Library
- 包管理器：pnpm

## 目录说明

- `src/pages`：页面级组件
- `src/components`：通用组件
- `src/hooks`：自定义 Hooks
- `src/services`：接口请求封装
- `src/stores`：状态管理
- `src/utils`：工具函数
- `tests`：测试用例

## 开发原则

1. 优先使用函数式组件。
2. 所有组件必须使用 TypeScript 类型声明。
3. 接口请求必须统一放在 `src/services` 中。
4. 业务逻辑尽量从组件中抽离到 hooks 或 services。
5. 不允许在组件中直接写复杂数据转换逻辑。
6. 新增功能必须补充测试用例。
7. 禁止提交 console.log、debugger、无用注释。

这个文件的目的，是让 AI 在生成代码之前先了解项目约定。你可以把它理解为“AI 的入职文档”。

六、配置编码规范：coding-rules.md

接下来，为 AI 准备明确的编码规范。

# Coding Rules

## 通用规则

1. 输出代码必须可运行，不要只给伪代码。
2. 修改已有代码时，应尽量保持最小变更。
3. 不要随意重构无关模块。
4. 不要引入未声明的新依赖。
5. 如果确实需要新增依赖，必须说明原因。
6. 不要硬编码接口地址、Token、用户 ID 等敏感信息。
7. 不要删除已有测试，除非明确说明原因。

## TypeScript 规范

1. 禁止使用 `any`，除非有明确理由。
2. 优先使用 `interface` 描述对象结构。
3. 函数参数和返回值必须有明确类型。
4. 公共方法必须保证类型可推导和易读。
5. 不允许忽略 TypeScript 报错。

## React 规范

1. 组件命名使用 PascalCase。
2. Hooks 命名必须以 `use` 开头。
3. 组件内部避免复杂业务逻辑。
4. 列表渲染必须使用稳定 key。
5. 避免不必要的状态提升。
6. 避免在渲染过程中创建大量临时对象。

## 错误处理

1. 接口请求必须处理异常。
2. 用户可感知错误需要有提示。
3. 日志中不能暴露敏感信息。
4. 不要吞掉异常。

有了这个文件之后，你在 Cursor、Copilot Chat 或其他 AI 编程工具中可以直接引用：

请先阅读 .ai/context.md 和 .ai/coding-rules.md，然后根据项目规范实现以下功能……

七、配置测试规则：test-rules.md

AI 生成代码时，最容易忽略测试。我们可以通过测试规则文件强化这一点。

# Test Rules

## 测试原则

1. 新增业务逻辑必须补充测试。
2. 修复 bug 时必须增加回归测试。
3. 测试用例应覆盖正常流程、异常流程和边界条件。
4. 不要为了通过测试而修改业务逻辑。
5. 不要删除已有测试用例。
6. 测试命名必须清晰描述场景。

## React 组件测试

1. 优先测试用户行为，而不是内部实现。
2. 使用 React Testing Library。
3. 查询元素优先使用 role、label、text。
4. 避免过度依赖 snapshot。
5. 异步行为必须使用 `waitFor` 或 `findBy`。

## 工具函数测试

1. 覆盖空值、非法值、边界值。
2. 覆盖典型输入和典型输出。
3. 对日期、金额、权限等敏感逻辑必须重点测试。

八、配置 AI Code Review 规则

在团队协作中，AI Code Review 是非常实用的场景。它可以帮你快速发现：

• 低级语法问题；
• 潜在空指针；
• 类型不安全；
• 边界条件遗漏；
• 异常处理不完整；
• 重复代码；
• 测试缺失；
• 安全风险。

创建 .ai/review-rules.md：

# AI Code Review Rules

## Review 目标

请重点检查以下内容：

1. 代码是否符合项目编码规范。
2. 是否存在潜在 bug。
3. 是否有类型安全问题。
4. 是否有性能问题。
5. 是否缺少异常处理。
6. 是否缺少测试用例。
7. 是否引入安全风险。
8. 是否存在过度设计。
9. 是否影响已有功能。
10. 是否有更简单的实现方式。

## 输出格式

请按照以下格式输出 Review 结果：

### 总体评价

用 2 到 3 句话概括本次变更质量。

### 必须修改

列出必须修改的问题。如果没有，请写“无”。

### 建议优化

列出可以优化但不阻塞合并的问题。

### 测试建议

指出需要补充或确认的测试场景。

### 风险提示

说明本次变更可能影响的模块或用户路径。

九、常用 Prompt 模板

为了让团队成员使用 AI 时保持一致，我们可以把高频 Prompt 固化下来。

1. Issue 转任务模板

文件：.ai/prompts/issue-to-task.md

# Prompt: Issue To Task

你是一名资深软件工程师和技术负责人。

请根据以下 Issue 内容，输出结构化开发任务。

## 输出要求

请使用以下格式：

### 需求理解

用简洁语言说明该 Issue 要解决什么问题。

### 用户故事

作为【用户角色】，我希望【目标】，以便【价值】。

### 验收标准

使用 Given / When / Then 格式列出验收标准。

### 技术拆解

按前端、后端、测试、文档分别拆解任务。

### 风险点

列出潜在技术风险和依赖项。

### 预估复杂度

使用 S / M / L / XL 进行评估，并说明原因。

使用方式：

请根据 .ai/prompts/issue-to-task.md 的要求，分析下面这个 Issue：
【粘贴 Issue 内容】

2. PR 摘要模板

文件：.ai/prompts/pr-summary.md

# Prompt: PR Summary

你是一名严谨的软件工程协作助手。

请根据本次 Git diff 生成 Pull Request 摘要。

## 输出格式

### 变更概述

用 3 到 5 条 bullet 总结本次改动。

### 修改文件

列出主要修改文件及其作用。

### 测试情况

说明已执行或建议执行的测试。

### 影响范围

说明可能受影响的功能模块。

### Review 关注点

指出审查者需要重点关注的地方。

3. 代码审查模板

文件：.ai/prompts/code-review.md

# Prompt: Code Review

你是一名资深代码审查专家。

请基于项目规范，对下面的代码变更进行 Review。

请重点关注：

1. 正确性
2. 可维护性
3. 类型安全
4. 边界条件
5. 异常处理
6. 性能问题
7. 安全风险
8. 测试覆盖

请按照以下格式输出：

## 总体评价

## 必须修改

## 建议优化

## 测试建议

## 风险提示

4. CI 失败分析模板

文件：.ai/prompts/ci-failure-analysis.md

# Prompt: CI Failure Analysis

你是一名 DevOps 工程师。

请根据以下 CI 日志分析失败原因。

## 输出要求

### 失败结论

用一句话说明最可能的失败原因。

### 关键日志

摘取最关键的错误日志。

### 原因分析

说明为什么会失败。

### 修复方案

给出可操作的修复步骤。

### 预防建议

说明如何避免类似问题再次出现。

十、本地提交前自动化配置

AI 自动化不能替代基础工程质量控制。提交前检查非常重要。

安装依赖：

pnpm add -D husky lint-staged eslint prettier typescript

初始化 Husky：

pnpm exec husky init

配置 package.json：

{
  "scripts": {
    "dev": "vite",
    "build": "tsc -b && vite build",
    "lint": "eslint .",
    "format": "prettier --write .",
    "typecheck": "tsc --noEmit",
    "test": "vitest run"
  },
  "lint-staged": {
    "*.{ts,tsx,js,jsx}": [
      "eslint --fix",
      "prettier --write"
    ],
    "*.{json,md,css,scss}": [
      "prettier --write"
    ]
  }
}

配置 .husky/pre-commit：

#!/usr/bin/env sh
. "$(dirname -- "$0")/_/husky.sh"

pnpm lint-staged
pnpm typecheck

这个配置可以确保每次提交前自动执行格式化、Lint 和类型检查。虽然它不直接调用 AI，但它为 AI 生成代码提供了质量底线。

十一、ESLint 配置示例

如果你使用 TypeScript + React，可以参考下面的 ESLint 配置。

文件：eslint.config.js

import js from "@eslint/js";
import tseslint from "typescript-eslint";
import reactHooks from "eslint-plugin-react-hooks";
import reactRefresh from "eslint-plugin-react-refresh";

export default tseslint.config(
  js.configs.recommended,
  ...tseslint.configs.recommended,
  {
    files: ["**/*.{ts,tsx}"],
    plugins: {
      "react-hooks": reactHooks,
      "react-refresh": reactRefresh
    },
    rules: {
      ...reactHooks.configs.recommended.rules,
      "react-refresh/only-export-components": [
        "warn",
        {
          allowConstantExport: true
        }
      ],
      "@typescript-eslint/no-explicit-any": "warn",
      "@typescript-eslint/no-unused-vars": [
        "warn",
        {
          argsIgnorePattern: "^_"
        }
      ]
    }
  }
);

文件：prettier.config.js

export default {
  semi: true,
  singleQuote: false,
  trailingComma: "none",
  printWidth: 100,
  tabWidth: 2
};

十二、GitHub Pull Request 模板

PR 模板可以让人类和 AI 都更容易理解本次变更。

文件：.github/pull_request_template.md

## 变更说明

请简要说明本次 PR 做了什么。

## 关联 Issue

Closes #

## 变更类型

- [ ] 新功能
- [ ] Bug 修复
- [ ] 重构
- [ ] 文档
- [ ] 测试
- [ ] 构建/部署
- [ ] 其他

## 测试情况

- [ ] 已执行单元测试
- [ ] 已执行集成测试
- [ ] 已执行手动测试
- [ ] 不需要测试，原因：

## 影响范围

请说明可能受影响的模块。

## Review 关注点

请指出希望 Reviewer 重点关注的内容。

## 截图或录屏

如涉及 UI 变更，请补充截图或录屏。

十三、GitHub Actions：基础 CI 配置

文件：.github/workflows/ci.yml

name: CI

on:
  pull_request:
    branches:
      - main
      - develop
  push:
    branches:
      - main
      - develop

jobs:
  check:
    runs-on: ubuntu-latest

    steps:
      - name: Checkout repository
        uses: actions/checkout@v4

      - name: Setup pnpm
        uses: pnpm/action-setup@v4
        with:
          version: 9

      - name: Setup Node.js
        uses: actions/setup-node@v4
        with:
          node-version: 20
          cache: "pnpm"

      - name: Install dependencies
        run: pnpm install --frozen-lockfile

      - name: Type check
        run: pnpm typecheck

      - name: Lint
        run: pnpm lint

      - name: Test
        run: pnpm test

      - name: Build
        run: pnpm build

这一步确保所有代码在合并前都必须通过类型检查、Lint、测试和构建。

十四、AI 自动生成 PR 摘要

如果你希望在 PR 创建或更新时自动生成摘要，可以借助 GitHub Actions 调用 AI API。

注意：下面示例使用 OpenAI 兼容接口。实际使用时，请根据你的服务商调整 API 地址和模型名称。

先在 GitHub 仓库中配置 Secret：

OPENAI_API_KEY=你的 API Key

然后创建文件：.github/workflows/ai-pr-summary.yml

name: AI PR Summary

on:
  pull_request:
    types: [opened, synchronize, reopened]

permissions:
  contents: read
  pull-requests: write

jobs:
  ai-summary:
    runs-on: ubuntu-latest

    steps:
      - name: Checkout repository
        uses: actions/checkout@v4
        with:
          fetch-depth: 0

      - name: Get diff
        id: diff
        run: |
          git fetch origin ${{ github.base_ref }}
          git diff origin/${{ github.base_ref }}...HEAD > pr.diff
          echo "diff_file=pr.diff" >> $GITHUB_OUTPUT

      - name: Generate PR summary
        id: summary
        env:
          OPENAI_API_KEY: ${{ secrets.OPENAI_API_KEY }}
        run: |
          PROMPT=$(cat .ai/prompts/pr-summary.md)
          DIFF=$(cat pr.diff | head -c 60000)

          jq -n \
            --arg model "gpt-4o-mini" \
            --arg prompt "$PROMPT" \
            --arg diff "$DIFF" \
            '{
              model: $model,
              messages: [
                {
                  role: "system",
                  content: "你是一个专业的软件工程协作助手，请用中文输出。"
                },
                {
                  role: "user",
                  content: ($prompt + "\n\n以下是本次 PR 的 diff：\n" + $diff)
                }
              ]
            }' > request.json

          curl https://api.openai.com/v1/chat/completions \
            -H "Authorization: Bearer $OPENAI_API_KEY" \
            -H "Content-Type: application/json" \
            -d @request.json > response.json

          cat response.json | jq -r '.choices[0].message.content' > summary.md

      - name: Comment PR
        uses: actions/github-script@v7
        with:
          script: |
            const fs = require("fs");
            const summary = fs.readFileSync("summary.md", "utf8");

            github.rest.issues.createComment({
              owner: context.repo.owner,
              repo: context.repo.repo,
              issue_number: context.issue.number,
              body: `## AI PR 摘要\n\n${summary}`
            });

这个工作流会在 PR 创建或更新时自动读取 diff，然后调用 AI 生成摘要，并将结果评论到 PR 下方。

十五、AI 辅助 Code Review 工作流

如果需要进一步自动化 Code Review，可以创建另一个工作流。

文件：.github/workflows/ai-code-review.yml

name: AI Code Review

on:
  pull_request:
    types: [opened, synchronize, reopened]

permissions:
  contents: read
  pull-requests: write

jobs:
  ai-review:
    runs-on: ubuntu-latest

    steps:
      - name: Checkout repository
        uses: actions/checkout@v4
        with:
          fetch-depth: 0

      - name: Get diff
        run: |
          git fetch origin ${{ github.base_ref }}
          git diff origin/${{ github.base_ref }}...HEAD > pr.diff

      - name: Generate AI review
        env:
          OPENAI_API_KEY: ${{ secrets.OPENAI_API_KEY }}
        run: |
          CONTEXT=$(cat .ai/context.md)
          RULES=$(cat .ai/review-rules.md)
          PROMPT=$(cat .ai/prompts/code-review.md)
          DIFF=$(cat pr.diff | head -c 60000)

          jq -n \
            --arg model "gpt-4o-mini" \
            --arg context "$CONTEXT" \
            --arg rules "$RULES" \
            --arg prompt "$PROMPT" \
            --arg diff "$DIFF" \
            '{
              model: $model,
              messages: [
                {
                  role: "system",
                  content: "你是一名资深软件工程师，请用中文进行严谨但友好的代码审查。"
                },
                {
                  role: "user",
                  content: (
                    "项目上下文：\n" + $context +
                    "\n\nReview 规则：\n" + $rules +
                    "\n\n任务说明：\n" + $prompt +
                    "\n\n代码变更 diff：\n" + $diff
                  )
                }
              ]
            }' > request.json

          curl https://api.openai.com/v1/chat/completions \
            -H "Authorization: Bearer $OPENAI_API_KEY" \
            -H "Content-Type: application/json" \
            -d @request.json > response.json

          cat response.json | jq -r '.choices[0].message.content' > review.md

      - name: Comment review
        uses: actions/github-script@v7
        with:
          script: |
            const fs = require("fs");
            const review = fs.readFileSync("review.md", "utf8");

            github.rest.issues.createComment({
              owner: context.repo.owner,
              repo: context.repo.repo,
              issue_number: context.issue.number,
              body: `## AI Code Review\n\n${review}`
            });

需要注意的是，AI Review 应该作为辅助，而不是替代人工 Review。尤其是涉及安全、资金、权限、数据一致性、隐私合规的代码，仍然需要经验丰富的开发者认真审查。

十六、如何在 Cursor 中配合使用

如果你使用 Cursor，可以将 .ai 目录中的规则作为长期上下文使用。

常见用法如下：

新功能开发

请先阅读 .ai/context.md、.ai/coding-rules.md 和 .ai/test-rules.md。

我要实现一个用户列表页面，要求：
1. 支持分页查询；
2. 支持按用户名搜索；
3. 支持启用/禁用用户；
4. 接口封装在 src/services/user.ts；
5. 页面放在 src/pages/UserList.tsx；
6. 使用 Ant Design 表格；
7. 补充必要测试。

请先给出开发计划，不要直接写代码。

重构代码

请根据 .ai/coding-rules.md 重构当前文件。

目标：
1. 保持功能不变；
2. 降低组件复杂度；
3. 将接口请求逻辑抽离到 service；
4. 将可复用状态逻辑抽离为 hook；
5. 不要引入新依赖；
6. 给出修改说明。

生成测试

请阅读 .ai/test-rules.md，为当前工具函数补充单元测试。

要求：
1. 覆盖正常输入；
2. 覆盖空值；
3. 覆盖非法值；
4. 覆盖边界条件；
5. 使用 Vitest；
6. 不修改业务代码。

分析报错

请根据以下错误日志分析原因，并给出修复方案。

要求：
1. 先给结论；
2. 再解释原因；
3. 最后给出最小修改方案；
4. 不要进行无关重构。

错误日志：
【粘贴日志】

十七、团队使用 AI 编程的最佳实践

1. 不要让 AI 一次性生成过大功能

AI 适合处理边界清晰的小任务。如果你让它一次性实现一个复杂系统，很容易出现架构混乱、遗漏细节、代码不可维护等问题。

建议把任务拆成：

• 数据模型；
• 接口封装；
• 页面结构；
• 表单逻辑；
• 状态管理；
• 测试用例；
• 文档说明。

每次只让 AI 处理一个明确目标。

2. 先让 AI 给计划，再让 AI 写代码

一个非常实用的技巧是：不要马上让 AI 输出代码，而是先让它输出开发计划。

例如：

请先分析需求并给出实现方案，不要写代码。

这样可以提前发现设计问题，避免 AI 直接生成一大段不合适的代码。

3. 使用“最小变更”原则

在真实项目中，随意重构是非常危险的。你应该经常提醒 AI：

请保持最小变更，不要修改无关文件，不要重构无关逻辑。

这条规则可以显著降低 AI 引入新问题的概率。

4. 始终要求测试

如果 AI 写了业务代码，却没有测试，那么这次自动化是不完整的。你可以把下面这句话加入常用提示词：

新增或修改业务逻辑时，必须补充对应测试。

5. AI 输出必须经过人工确认

AI 可能会：

• 编造不存在的 API；
• 引入过时写法；
• 忽略边界条件；
• 误解业务规则；
• 删除重要逻辑；
• 暴露敏感信息；
• 生成看似正确但不可运行的代码。

因此，AI 的结果必须经过开发者审查、测试和验证。

十八、安全与合规注意事项

在团队中使用 AI 编程，安全问题必须提前考虑。

1. 不要把敏感信息发给 AI

包括但不限于：

• API Key；
• 数据库密码；
• 用户隐私数据；
• 内部 Token；
• 商业机密；
• 未公开财务数据；
• 生产环境日志中的敏感字段。

2. 对日志进行脱敏

如果要让 AI 分析错误日志，建议先脱敏：

user_id=123456 -> user_id=
token=abcdefg -> token=
email=test@example.com -> email=

3. 限制 AI 的权限

自动化工作流中，AI 不应该拥有过高权限。比如：

• 只允许读取 diff，不允许写入主分支；
• 不允许自动合并 PR；
• 不允许直接发布生产环境；
• 不允许访问生产数据库；
• GitHub Token 权限保持最小化。

4. 记录 AI 参与痕迹

建议让 AI 生成的 PR 摘要、Review 建议都以评论形式保留，方便后续追溯。

十九、常见问题排查

1. AI 生成的 PR 摘要太长怎么办？

可以在 Prompt 中增加限制：

请控制在 500 字以内，重点说明变更内容、影响范围和测试情况。

也可以限制 diff 长度，但要注意 diff 被截断后，AI 可能遗漏部分信息。

2. AI Review 评论太泛泛怎么办？

通常是上下文不够。建议把以下内容加入 Prompt：

• 项目背景；
• 编码规范；
• Review 规则；
• 本次需求说明；
• 关键文件 diff。

3. CI 中调用 AI API 失败怎么办？

常见原因包括：

• Secret 未配置；
• API Key 无效；
• API 地址错误；
• 网络访问失败；
• 模型名称不正确；
• 请求体过大；
• 账户额度不足。

可以先在本地用 curl 测试 API，再接入 GitHub Actions。

4. AI 修改代码后测试失败怎么办？

不要让 AI 盲目继续修改。更好的方式是把失败日志、相关测试和修改目标一起给 AI：

下面是测试失败日志和相关代码。请分析失败原因，并给出最小修复方案。不要修改无关逻辑。

二十、推荐落地路线

如果你的团队刚开始引入 AI 编程自动化，不建议一次性上完整流程。可以按以下顺序逐步推进：

第一阶段：规范上下文

• 添加 .ai/context.md
• 添加 .ai/coding-rules.md
• 添加 .ai/test-rules.md
• 沉淀常用 Prompt

目标：让团队成员使用 AI 时有统一标准。

第二阶段：本地质量控制

• 配置 ESLint
• 配置 Prettier
• 配置 Husky
• 配置 lint-staged
• 配置类型检查和测试脚本

目标：保证 AI 生成代码不会轻易破坏基础质量。

第三阶段：CI 自动化

• 配置 GitHub Actions
• 自动执行 lint、typecheck、test、build
• 设置 PR 必须通过 CI 才能合并

目标：建立代码合并门禁。

第四阶段：AI 参与 PR 流程

• 自动生成 PR 摘要
• 自动生成 Review 建议
• 自动分析 CI 失败原因

目标：减少人工重复劳动，提高协作效率。

第五阶段：知识沉淀

• 将高质量 AI 输出整理为文档；
• 将常见问题整理为 FAQ；
• 不断优化 Prompt 和规则；
• 定期复盘 AI 引入的问题与收益。

目标：形成团队级 AI 工程能力。

二十一、完整配置清单

最后整理一下本文涉及的关键配置文件：

.ai/
├── context.md
├── coding-rules.md
├── review-rules.md
├── test-rules.md
└── prompts/
    ├── issue-to-task.md
    ├── pr-summary.md
    ├── code-review.md
    └── ci-failure-analysis.md

.github/
├── pull_request_template.md
└── workflows/
    ├── ci.yml
    ├── ai-pr-summary.yml
    └── ai-code-review.yml

.husky/
└── pre-commit

package.json
eslint.config.js
prettier.config.js

你可以先从 .ai 目录开始，把项目背景、编码规则和 Prompt 模板沉淀下来。随后再逐步接入 Husky、CI、AI PR Summary 和 AI Code Review。

结语

AI 编程的真正价值，不只是“帮你写几行代码”，而是让软件工程流程变得更加自动化、标准化和可复用。

如果你只是偶尔打开 AI 聊天窗口问几个问题，它的价值会比较有限；但如果你把 AI 接入 Issue、开发、测试、Review、CI、发布等关键环节，它就能成为团队工程体系的一部分。

一套好的 AI 编程工作流，应该具备以下特点：

• 有清晰的项目上下文；
• 有统一的编码规范；
• 有固定的 Prompt 模板；
• 有自动化质量检查；
• 有 CI/CD 门禁；
• 有 AI 辅助审查；
• 有人工最终确认；
• 有持续复盘和优化机制。

记住，AI 不是万能开发者，也不是自动交付机器。它更像一名高效但需要约束的初级工程师：速度很快，知识面广，但需要明确任务、清晰规则和严格审查。

当你用工程化方式管理 AI，它才能真正成为提升研发效率的生产力工具。