GitHub Actions集成Gemini CLI：AI驱动自动化工作流实战

在持续集成与持续部署（CI/CD）领域，自动化工作流已成为现代软件开发的基石。其核心原理是通过预定义的脚本和任务序列，实现代码构建、测试、部署等环节的无人值守执行，从而提升开发效率与软件质量。随着人工智能技术的演进，将大语言模型（LLM）的能力注入自动化流水线，为解决需要“理解”而非单纯“执行”的复杂场景提供了新的技术路径。这不仅能实现智能代码审查、自动化根因分析等高级功能，更能显著降低人工干预成

weixin_33709364

67人浏览 · 2026-05-08 16:20:44

weixin_33709364 · 2026-05-08 16:20:44 发布

1. 项目概述：当GitHub Actions遇上Gemini，自动化从此有了“大脑”

如果你和我一样，每天都要和GitHub Actions打交道，从代码构建、测试到部署，写了一大堆YAML配置文件，那你肯定也遇到过这样的痛点：很多判断逻辑写起来特别繁琐。比如，根据提交信息自动生成变更日志、智能审核代码风格、甚至是分析测试失败的原因，这些任务往往需要写复杂的脚本，或者依赖一堆第三方Action，维护起来头大。

最近，Google把他们的多模态大模型Gemini也“塞”进了GitHub Actions的生态里，推出了 google-gemini/gemini-cli-action 。这可不是简单地把API包装一下，它提供了一个命令行工具 gemini-cli ，让你能在Actions的工作流步骤里，像调用普通Shell命令一样，直接和Gemini对话，获取结构化的输出。简单来说，它给你的自动化流水线装上了一颗“AI大脑”。

这个Action的核心价值在于 无缝集成 和 结构化调用 。你不再需要在自己的工作流里手动设置API密钥、处理HTTP请求和JSON解析。只需要像使用 curl 或 jq 一样，通过 gemini-cli 命令，就能让Gemini理解你的代码上下文、分析日志文件、生成文本，并把结果输出到环境变量或文件中，供后续步骤使用。它特别适合那些需要“理解”而不仅仅是“执行”的自动化场景，比如智能代码审查、自动生成PR描述、从错误日志中定位根因、甚至是多语言翻译项目文档等。

2. 核心设计思路：为什么是CLI模式，而非直接SDK？

初次看到这个项目，你可能会想：为什么不直接提供一个JavaScript的Action，或者在Python步骤里调用Gemini SDK呢？ gemini-cli-action 选择封装成命令行工具，背后有非常务实的工程考量。

2.1 降低使用门槛与环境依赖

GitHub Actions的每个Job可以运行在不同的操作系统（Ubuntu， macOS， Windows）和容器环境中。如果以SDK形式提供，比如一个Node.js Action，那么用户在使用时，必须确保Node.js环境可用，并且版本兼容。而CLI工具，尤其是打包成单一可执行文件（就像这个Action做的），其依赖几乎为零。它被设计成一个静态链接的二进制文件，下载即用，与宿主机的编程语言环境完全解耦。这对于那些主要使用Bash、PowerShell脚本，或者运行在精简Docker镜像（如 alpine ）中的工作流来说，是巨大的便利。

2.2 完美契合Actions的“步骤”哲学

GitHub Actions的工作流本质是一系列步骤（Steps）的集合，每个步骤通常执行一个命令或一个Action，并通过 stdout 、文件或环境变量传递结果。CLI模式天生契合这种范式。你可以在一个Step中运行 gemini-cli 命令，将其输出通过 >> $GITHUB_OUTPUT 设置为该步骤的输出，下一个Step就能直接引用。这种线性的、基于文本流的交互方式，是Unix哲学和CI/CD流水线的核心，学习成本和集成成本极低。

2.3 灵活的输入输出与组合性

作为CLI工具， gemini-cli 可以方便地接受来自管道（pipe）、文件重定向或者命令行参数的输入。例如，你可以把 git diff 的结果通过管道传给 gemini-cli 让它总结变更，也可以让它直接读取一个日志文件进行分析。它的输出可以是纯文本、JSON或其他任何格式，然后你可以用 jq 、 grep 等标准的Unix工具进行二次处理。这种组合性赋予了工作流设计极大的灵活性，远胜于一个功能固定的、黑盒式的SDK封装Action。

2.4 安全与密钥管理

将API密钥等敏感信息通过GitHub Secrets注入到工作流环境变量中，是Actions的标准安全实践。 gemini-cli 通过环境变量（如 GEMINI_API_KEY ）读取密钥，这种方式与Actions的机密管理机制无缝对接。用户无需在脚本中硬编码密钥，也无需关心SDK内部的认证逻辑，安全性更高，配置也更清晰。

注意：虽然CLI模式优势明显，但它也意味着每次调用都可能产生一次网络请求（调用Gemini API）。在设计工作流时，需注意API的调用频率和成本，避免在循环中无节制地调用。

3. 实战部署：从零开始配置你的第一个AI工作流

理论说得再多，不如动手跑一遍。我们来搭建一个真实场景： 自动为Pull Request生成友好、专业的描述 。很多开发者提交PR时描述写得很简略，维护者需要花费额外时间理解改动内容。我们可以用 gemini-cli-action 在PR创建或更新时，自动分析代码差异，生成一份建议的描述。

3.1 基础环境与密钥准备

首先，你需要在Google AI Studio获取一个Gemini API密钥。

访问 Google AI Studio （需登录Google账号）。
点击“Create API Key”按钮，创建一个新的密钥。
复制生成的API密钥，它看起来像一串长字符。

接下来，在GitHub仓库中设置Secret：

进入你的GitHub仓库页面。
点击 Settings -> Secrets and variables -> Actions 。
点击 New repository secret 。
Name 输入 GEMINI_API_KEY （注意， gemini-cli 默认读取这个环境变量名）。
Value 粘贴你刚才复制的API密钥。
点击 Add secret 。

3.2 编写GitHub Actions工作流文件

在你的项目根目录下创建 .github/workflows/auto-pr-description.yml 文件。

name: Auto-generate PR Description

on:
  pull_request:
    types: [opened, synchronize] # 在PR打开和更新（同步新提交）时触发

jobs:
  suggest-description:
    runs-on: ubuntu-latest
    permissions:
      contents: read
      pull-requests: write # 需要写入权限来更新PR描述或评论
    steps:
      - name: Checkout code
        uses: actions/checkout@v4
        with:
          fetch-depth: 0 # 获取完整历史，以便进行diff比较

      - name: Setup Gemini CLI
        uses: google-gemini/gemini-cli-action@v1
        with:
          api-key: ${{ secrets.GEMINI_API_KEY }}

      - name: Generate PR description suggestion
        id: gen-desc
        run: |
          # 获取当前PR与目标分支（如main）的差异
          git diff origin/${{ github.base_ref }} HEAD -- . ':(exclude)*.lock' ':(exclude)*.log' > diff.txt
          
          # 使用gemini-cli分析diff，并生成描述
          PROMPT="你是一个资深的代码审查员。请分析以下代码变更（git diff 格式），为这个Pull Request生成一段清晰、专业的描述。描述应包括：1. 本次变更的主要目的。2. 涉及的核心文件与模块。3. 关键的技术实现点（如果有）。4. 需要注意的潜在影响（如果有）。请直接输出描述内容，不要额外解释。"
          
          SUGGESTION=$(gemini-cli --model gemini-1.5-flash --prompt "$PROMPT" --file diff.txt)
          
          # 将建议描述输出到步骤变量
          echo "description_suggestion<<EOF" >> $GITHUB_OUTPUT
          echo "$SUGGESTION" >> $GITHUB_OUTPUT
          echo "EOF" >> $GITHUB_OUTPUT
          
          # 也可以将建议保存为文件，供后续步骤使用
          echo "$SUGGESTION" > pr-suggestion.md

      - name: Comment on PR with suggestion
        uses: actions/github-script@v7
        if: always() # 即使上一步失败也尝试评论（例如API调用超时）
        with:
          github-token: ${{ secrets.GITHUB_TOKEN }}
          script: |
            const fs = require('fs');
            let suggestion;
            try {
              suggestion = fs.readFileSync('pr-suggestion.md', 'utf8');
            } catch (e) {
              suggestion = `⚠️ 自动生成描述失败。错误信息：${e.message}`;
            }
            
            const { issue: { number: issue_number }, repo: { owner, repo } } = context;
            // 在PR上添加评论，而非直接修改描述，更为安全和非侵入式
            await github.rest.issues.createComment({
              owner,
              repo,
              issue_number,
              body: `### 🤖 AI 生成的 PR 描述建议\n\n${suggestion}\n\n*（此评论由工作流自动生成，仅供参考和补充。）*`
            });

3.3 关键步骤与参数解析

这个工作流有几个关键点需要深入理解：

触发条件 ( on: pull_request ) : 我们设置在PR打开和同步（即推送新提交）时触发，确保每次更新都能得到最新的分析。
权限设置 ( permissions ) : 为了向PR添加评论，我们需要显式授予 pull-requests: write 权限。这是GitHub Actions更细粒度权限控制的要求。
actions/checkout 的 fetch-depth : 设置为 0 是为了拉取完整的Git历史。这对于 git diff 命令正确计算与目标分支的差异至关重要。如果使用默认值（浅克隆）， git diff 可能无法工作。
google-gemini/gemini-cli-action@v1 : 这是核心Action。它会在运行器环境中安装 gemini-cli 工具。我们通过 with 参数传入API密钥。
gemini-cli 命令参数 :
- --model : 指定使用的Gemini模型。 gemini-1.5-flash 是兼顾速度与性能的推荐选择，适合自动化任务。对于更复杂的分析，可以考虑 gemini-1.5-pro 。
- --prompt : 这是给模型的指令。我们精心设计了提示词（Prompt），明确界定了AI的角色、任务和输出格式。好的Prompt是获得高质量结果的关键。
- --file : 指定一个文件作为模型的输入内容。这里我们传入了包含代码差异的 diff.txt 文件。CLI会自动读取文件内容并将其与Prompt组合后发送给模型。
输出处理 : 我们将模型生成的结果 $SUGGESTION 通过特定的格式 <<EOF ... EOF 写入 $GITHUB_OUTPUT ，使其成为该步骤（ id: gen-desc ）的输出变量，名为 description_suggestion 。同时，我们也保存到文件 pr-suggestion.md ，作为冗余备份。
添加PR评论 : 我们使用 actions/github-script 来执行一段JavaScript代码，读取生成的建议文件，并以评论的形式添加到PR中。这种方式比直接修改PR描述更友好，因为它只是提供建议，不会覆盖作者原有的描述。

3.4 实操心得与避坑指南

Prompt工程是关键 ：AI输出的质量极大程度上依赖于Prompt。我们的示例Prompt定义了角色、任务和输出结构。在实际使用中，你可能需要根据项目特点调整。例如，对于前端项目，可以要求AI关注UI组件和状态管理；对于后端项目，则关注API接口和数据模型变化。多迭代几次Prompt，观察输出结果，不断优化。
控制输入内容与成本 ： git diff 的输出可能非常长，尤其是涉及大量文件变更时。这会导致API调用消耗更多的Token，增加成本并可能触发速率限制。我们的命令中使用了路径过滤 -- . 和排除模式 ':(exclude)*.lock' 来忽略依赖锁文件和日志文件，这是一个有效的优化。你还可以考虑只diff特定目录，或者使用 --stat 先看概况，再针对性地diff关键文件。
错误处理与降级 ：网络请求可能失败，API可能暂时不可用。我们在 Comment on PR 步骤中使用了 if: always() 和 try...catch 结构，确保即使生成建议失败，也会在PR上留下一条包含错误信息的评论，而不是让整个工作流静默失败。这是一种良好的韧性设计。
模型选择与响应时间 ：对于CI/CD流水线，速度很重要。 gemini-1.5-flash 的响应速度比 -pro 模型快很多，对于代码分析、文本生成等任务通常已足够。如果你的任务需要极深的推理能力（如设计复杂的算法），再考虑使用Pro模型，但要接受更长的等待时间。

4. 进阶应用场景：解锁AI驱动的自动化潜能

除了生成PR描述， gemini-cli-action 还能在软件开发生命周期的多个环节大放异彩。下面分享几个我实践过的、效果显著的进阶场景。

4.1 场景一：智能代码审查辅助

传统的静态代码分析工具（如ESLint, SonarQube）能捕捉语法错误和代码异味，但难以理解代码的“意图”和“设计合理性”。我们可以让Gemini充当第一轮审查员。

工作流思路 ：在每次推送代码到特性分支时，让Gemini分析最新提交的代码变更，从代码逻辑、潜在bug、性能隐患、可读性、是否符合项目规范等角度给出审查意见。

关键步骤示例 ：

# 获取最近一次提交的diff
git diff HEAD~1 HEAD -- . ':(exclude)*.lock' > last_commit.diff

REVIEW_PROMPT="作为资深开发者，请审查以下代码变更。请指出：1. 明显的逻辑错误或边界条件缺失。2. 可能的安全漏洞（如SQL注入、XSS）。3. 代码风格问题（命名、函数长度等）。4. 是否有更优的实现方式。请以列表形式给出具体建议，并引用代码行号。"

gemini-cli --model gemini-1.5-flash --prompt "$REVIEW_PROMPT" --file last_commit.diff > review_notes.md

然后，可以将 review_notes.md 的内容发布到提交的评论区，或者发送到团队的Slack/钉钉频道，提醒作者关注。

注意事项 ：AI审查不能替代人工审查。它更适合作为“增强工具”，帮助发现那些容易被人类审查者忽略的、模式化的问题。对于业务逻辑的正确性，必须由人来把控。

4.2 场景二：自动化测试失败根因分析

测试套件失败是常事，但从冗长的日志和堆栈跟踪中快速定位根本原因却很耗时。我们可以让Gemini来当“调试助手”。

工作流思路 ：在CI的测试Job失败后，触发一个后续Job，收集失败的测试用例名称、错误日志和相关的代码片段，交给Gemini分析可能的原因。

关键步骤示例 ：

# 假设测试框架输出了失败日志到 test-failures.log
FAILURE_LOG=$(cat test-failures.log | head -c 15000) # 限制长度，避免超出上下文

ANALYSIS_PROMPT="以下是自动化测试失败的日志。请分析错误信息、堆栈跟踪和测试名称，推测导致测试失败的最可能原因。重点关注：1. 空指针或未定义行为。2. 网络或外部服务依赖问题。3. 测试数据问题。4. 并发或时序问题。请给出最可能的前3个原因，并简要说明推理过程。"

gemini-cli --model gemini-1.5-pro --prompt "$ANALYSIS_PROMPT" --text "$FAILURE_LOG" > failure_analysis.md

将分析结果附加到CI运行的总结果中，或者通知给提交者，可以极大加速调试过程。

实操心得 ：这个场景下，使用理解能力更强的 gemini-1.5-pro 模型往往能得到更准确的分析。同时，一定要对输入的日志进行裁剪，只保留最关键的错误部分，因为模型的上下文长度有限，过长无关的日志会干扰分析。

4.3 场景三：动态生成发布说明（Changelog）

维护一个清晰、有意义的CHANGELOG文件是件麻烦事。我们可以让Gemini根据一个发布周期内的所有提交信息，自动归纳、分类并生成草稿。

工作流思路 ：在创建Git Tag（如 v1.2.0 ）时触发工作流。获取从上个Tag到当前Tag之间的所有提交信息，让Gemini总结新功能、修复的Bug和破坏性变更。

关键步骤示例 ：

# 获取两个tag之间的提交信息
git log --oneline --no-merges $(git describe --tags --abbrev=0)..HEAD > commits.txt

CHANGELOG_PROMPT="以下是自上次发布以来的所有提交信息（每行一条）。请将它们整理成一份发布说明草案，按以下类别分组：'### 🚀 新功能'、'### 🐛 Bug修复'、'### ⚠️ 破坏性变更'、'### 🔧 其他改进'。对于每个条目，请用简洁易懂的语言重新描述，合并相似的提交。直接输出Markdown格式的结果。"

gemini-cli --model gemini-1.5-flash --prompt "$CHANGELOG_PROMPT" --file commits.txt > changelog_draft.md

生成草稿后，可以作为一个Artifact上传，或者自动创建一个包含该草稿的Release Draft，由维护者最终审核和发布。

避坑技巧 ：提交信息（Commit Message）的质量直接决定生成效果。如果团队提交信息写得很随意（如“fix bug”、“update”），AI也很难归纳。推广使用约定式提交（Conventional Commits）规范，能让这个自动化流程的效果提升一个数量级。

5. 性能调优、成本控制与安全实践

将AI模型集成到自动化流水线中，必须考虑性能、成本和安全性，否则很容易从“利器”变成“负担”。

5.1 性能调优：减少延迟，提升流水线速度

模型选型 ：如前所述， gemini-1.5-flash 是自动化任务的绝佳选择，它在响应速度上比Pro模型快数倍，而多数分析、生成类任务其能力已绰绰有余。仅在需要进行复杂逻辑推理、代码生成或非常长的上下文分析时，才考虑Pro模型。
优化Prompt ：清晰、简洁、结构化的Prompt能让模型更快地理解意图并给出准确回答，避免它“胡思乱想”产生冗余内容。在Prompt中明确指定输出格式（如“用列表形式”、“输出JSON”），可以省去后续解析的麻烦。
精简输入 ：这是最重要的优化点。永远不要将整个代码库或巨大的日志文件直接扔给AI。使用 grep , head , tail , jq 等工具提取关键信息。例如，只发送失败的测试日志，而不是全部日志；只发送变更的代码块，而不是整个文件。
缓存与去重 ：如果某个步骤（如分析代码风格）的结果在多次工作流运行中很可能相同，可以考虑将结果缓存起来（例如，存入一个由文件哈希值命名的缓存文件），避免重复调用API。GitHub Actions本身也支持缓存功能。

5.2 成本控制：精打细算每一分Token

Gemini API按Token使用量计费。在自动化场景下，如果不加控制，成本可能会悄悄增长。

监控与预算 ：在Google AI Studio控制台设置预算提醒。定期查看API使用报告，了解哪个工作流、哪个任务消耗最多。
限制调用频率 ：不是每次代码推送都需要深度分析。可以考虑仅在特定分支（如 main , develop ）的推送、或创建PR时触发AI分析任务。可以使用 on: push: branches: [ main ] 或 on: pull_request 进行限制。
设置超时与重试策略 ：在网络不稳定或API暂时性故障时，无限制的重试会导致不必要的Token消耗和流水线阻塞。在工作流步骤或 gemini-cli 调用外层，设置合理的超时（如 timeout-minutes: 2 ）和重试次数。
估算Token用量 ：对于文本任务，一个简单的估算方法是：中文字符大约相当于1-2个Token。你可以在Prompt中要求模型“用尽可能简洁的语言”来回应。对于代码分析，可以要求它“只列出最关键的三点”。

5.3 安全实践：保护你的代码与密钥

API密钥安全 ： 绝对不要 将API密钥硬编码在YAML文件或代码中。必须使用GitHub Secrets，并通过 ${{ secrets.YOUR_SECRET_NAME }} 的方式引用。确保拥有仓库Secrets写入权限的人员是可信的。
代码与提示词安全 ：记住，你发送给Gemini API的代码和提示词，会离开你的基础设施，到达Google的服务器。 切勿发送任何敏感信息 ，包括但不限于：真实的生产环境密钥、密码、个人身份信息（PII）、未公开的商业逻辑代码、核心算法等。如果必须分析包含敏感数据的日志，务必先进行脱敏处理。
输出内容审查 ：AI生成的内容可能存在错误、偏见或不准确。对于自动生成并应用于生产环境的操作（如自动合并PR、自动部署），必须设置人工审核环节，或者至少要求多个条件同时满足（如AI建议 + 测试通过 + 特定人员批准）。我们的PR描述示例中，选择“添加评论”而非“直接修改描述”，就是一种安全的设计。
权限最小化 ：遵循最小权限原则。为工作流只授予其完成任务所必需的最低权限。例如，如果只是生成评论，那么 pull-requests: write 就足够了，不需要 contents: write （写入代码）权限。

6. 常见问题与故障排查实录

在实际集成 gemini-cli-action 的过程中，我遇到并解决了一些典型问题。这里记录下来，希望能帮你少走弯路。

6.1 问题速查表

问题现象	可能原因	排查步骤与解决方案
步骤失败： `gemini-cli: command not found`	1. `google-gemini/gemini-cli-action` 步骤未成功运行。 2. 该步骤运行后，后续步骤在新的Shell环境中执行，未继承PATH。	1. 检查 `google-gemini/gemini-cli-action` 步骤是否成功（无错误日志）。 2. 确保使用 `run` 的步骤在同一个Job内。Actions的每个Step默认共享环境。如果问题依旧，尝试在调用 `gemini-cli` 的命令前加上完整路径（安装后通常位于 `/usr/local/bin/gemini-cli` ），或使用 `which gemini-cli` 命令查看其位置。
API调用失败： `Error: API key not valid`	1. GitHub Secret `GEMINI_API_KEY` 未正确设置或名称不对。 2. API密钥已失效或被撤销。 3. 工作流运行在Fork的仓库上，Secrets默认不传递。	1. 检查Secret名称是否与工作流中引用的完全一致（区分大小写）。 2. 前往Google AI Studio，确认密钥状态有效，必要时重新生成。 3. 如果PR来自Fork，需要在仓库Settings -> Actions -> General中，勾选“Send write tokens to workflows from pull requests”并选择“Read and write permissions”，同时PR发起者需要有“Allow edits and access to secrets”的权限（这有安全风险，请谨慎评估）。
模型响应慢或超时	1. 使用了 `gemini-1.5-pro` 等重型模型。 2. 输入内容（Prompt+文件）过长。 3. 网络延迟或Gemini API服务暂时性拥堵。	1. 切换到 `gemini-1.5-flash` 模型。 2. 大幅精简输入内容，移除无关代码和日志。 3. 为 `run` 步骤设置 `timeout-minutes` ，并实现重试逻辑。例如，使用 `max-attempts` 和 `retry-on` 参数（需配合 `actions/github-script` 或其他支持重试的Action）。
AI生成的内容质量差	1. Prompt指令不清晰、不具体。 2. 输入给模型的上下文信息不足或噪声太多。 3. 任务本身超出当前模型的能力范围。	1. 迭代优化Prompt 。明确角色、任务、输出格式。可以加入“请一步步思考”的指令（Chain-of-Thought）来提升复杂任务的表现。 2. 提供更干净、更相关的输入。例如，只给模型看变更的函数，而不是整个文件。 3. 尝试更换模型（如从Flash换到Pro），或者将复杂任务拆解成多个简单的子任务，分步调用AI。
工作流因成本过高被中断	1. 输入内容过大，导致单次调用消耗Token过多。 2. 工作流被频繁触发（如每次推送都触发），且未做任何限制。 3. 代码逻辑错误导致在循环中重复调用API。	1. 实施 5.2 成本控制章节的所有建议。 2. 在Google AI Studio设置用量配额和预算警报。 3. 审查工作流逻辑，确保没有意外的无限循环或重复调用。可以在工作流中添加一个步骤，先用 `wc` 命令估算输入文本的大小，如果超过阈值则跳过AI调用。

6.2 调试技巧：查看实际的API请求

有时你需要知道 gemini-cli 到底向API发送了什么。虽然Action本身没有提供详细日志，但你可以通过一个“迂回”的方式来进行调试。

方法：在工作流中，在调用 gemini-cli 之前，将你准备好的Prompt和文件内容打印出来（注意脱敏）。

- name: Debug - Print inputs (Sanitized)
  run: |
    echo "=== Prompt Preview (first 500 chars) ==="
    echo "${PROMPT:0:500}"
    echo "..."
    echo ""
    echo "=== File Content Preview (first 1000 chars) ==="
    head -c 1000 diff.txt
    echo "..."

这能帮你确认输入是否符合预期，是否包含了不该有的敏感信息。

6.3 网络问题与代理配置

如果你的自托管GitHub Actions运行器位于网络受限的环境，可能需要配置代理才能访问Gemini API。 gemini-cli 本身可能不直接支持代理设置，但你可以通过为整个Job或Step设置 HTTP_PROXY / HTTPS_PROXY 环境变量来影响其网络请求。

jobs:
  my-job:
    runs-on: self-hosted
    env:
      HTTPS_PROXY: "http://your-proxy-server:port"
      HTTP_PROXY: "http://your-proxy-server:port"
    steps:
      - uses: google-gemini/gemini-cli-action@v1
        with:
          api-key: ${{ secrets.GEMINI_API_KEY }}
      - run: gemini-cli --model gemini-1.5-flash --prompt "Hello"

请注意，这取决于运行器的基础环境是否尊重这些环境变量。更可靠的方式是在自托管运行器上全局配置网络代理。

将 gemini-cli-action 集成到你的工作流中，就像是给一台精密的机器安装了一个智能传感器。它不能替代机器本身的核心功能（构建、测试、部署），但它能赋予机器感知、理解和决策的新维度。从自动生成文档到智能排查问题，其可能性只受限于你的想象力。关键在于找到那些重复、琐碎且需要一定认知能力的任务，然后设计一个可靠的Prompt和工作流，让AI成为你不知疲倦的助手。

DeepSeek技术社区

欢迎加入DeepSeek 技术社区。在这里，你可以找到志同道合的朋友，共同探索AI技术的奥秘。

更多推荐