提示工程架构师：用Jenkins实现提示持续集成的终极教程
关键词
提示工程、Jenkins、持续集成（CI）、提示测试、自动化流程、AI模型优化、版本控制
摘要
当AI应用成为企业核心竞争力时，提示（Prompt） 已成为连接人类需求与模型能力的“翻译官”。但手动管理提示的痛点日益凸显：改了提示效果反而差、不同环境下输出不一致、发布前缺乏全面测试……这些问题严重阻碍了AI应用的迭代效率。
本文将带你走进提示持续集成（Prompt CI） 的世界——用Jenkins这一经典CI工具，将提示的开发、测试、发布打造成自动化流水线。你将学会：
什么是提示持续集成，为什么它是AI时代的“提示管理必修课”？如何用Jenkins搭建提示CI流程，从版本控制到自动测试再到部署？如何设计提示测试用例，覆盖效果、一致性、性能等核心指标？如何解决实际应用中的常见问题（比如模型输出不稳定、测试误报）？
无论你是提示工程师、AI开发者还是DevOps，都能从本文获得可落地的实践指南。让我们一起把提示开发从“手工作坊”升级为“自动化工厂”！
一、背景介绍：为什么需要提示持续集成？
1.1 提示工程的“手工作坊”痛点
在AI应用中，提示是“指挥”模型的核心指令。比如电商客服机器人的提示：“请友好回复用户的问题，并引导他们提供订单号”，直接决定了模型输出的质量。但手动管理提示的方式，存在三大致命问题：
版本混乱：多个开发者修改同一提示，容易覆盖或丢失历史版本；测试不充分：发布前仅靠人工测试几个案例，无法覆盖所有场景；反馈滞后：改了提示后，要等用户反馈才知道效果好不好，迭代周期长。
举个真实案例：某公司的AI客服机器人，原本的提示是“回复用户的问题”，结果模型输出经常忽略“引导订单号”的要求，导致用户需要多次来回沟通。开发者改了提示后，没做全面测试就发布，结果新提示导致模型输出过于冗长，反而降低了效率。
1.2 持续集成：AI时代的“提示管理解药”
持续集成（CI）是软件工程中的经典实践：开发者频繁提交代码，自动化工具会自动构建、测试，快速反馈问题。将CI理念应用到提示工程中，就是提示持续集成——每一次提示修改，都通过自动化流程完成测试、验证，确保其可靠后再发布。
提示持续集成的价值在于：
快速反馈：改了提示后，10分钟内就能知道效果好不好；全面覆盖：自动化测试可以覆盖上百个场景，比人工更全面；一致性保障：确保提示在不同环境（比如开发、测试、生产）下的输出一致；版本可控：通过Git管理提示版本，可随时回滚到历史版本。
1.3 目标读者与核心挑战
目标读者：
提示工程师：想提升提示开发效率；AI应用开发者：想确保AI功能的稳定性；DevOps工程师：想将AI流程纳入现有CI/CD体系。
核心挑战：
如何将提示的“质量”转化为可量化的测试指标（比如效果、一致性、性能）？如何用Jenkins搭建自动化流程，连接版本控制、测试、部署？如何解决模型输出的“不确定性”（比如同一提示多次输出不同结果）？
二、核心概念解析：用“菜谱”比喻提示持续集成
2.1 关键概念类比
为了让大家更容易理解，我们用“菜谱开发”来类比提示持续集成：
| 提示工程概念 | 菜谱开发类比 | 说明 |
|---|---|---|
| 提示（Prompt） | 菜谱（Recipe） | 指导模型（厨师）输出的“指令”，比如“用番茄炒蛋的做法，加少许糖”。 |
| 提示测试（Prompt Testing） | 试菜（Tasting） | 检查菜谱的效果：味道是否符合预期？咸淡是否合适？ |
| 提示持续集成（Prompt CI） | 厨房自动化流程（Kitchen Automation） | 每次改菜谱，自动完成“备菜→炒菜→试菜→记录结果”的流程，确保菜谱可靠。 |
| Jenkins | 厨房机器人（Kitchen Robot） | 执行自动化流程的“工具”，负责调度各个步骤。 |
2.2 提示持续集成的核心流程
用Mermaid流程图表示提示CI的核心流程（类比菜谱开发）：
graph TD
A[提示工程师修改提示（改菜谱）] --> B[提交到Git仓库（保存菜谱版本）]
B --> C[Jenkins触发Pipeline（厨房机器人启动）]
C --> D[拉取代码（拿最新菜谱）]
D --> E[安装依赖（准备食材/工具）]
E --> F[运行测试（试菜：味道、咸淡、速度）]
F --> G{测试通过？（味道符合要求？）}
G -->|是| H[部署到预生产（给厨师长试吃）]
G -->|否| I[发送失败通知（告诉开发者味道不对）]
H --> J[人工验证（厨师长确认）]
J --> K{验证通过？（厨师长满意？）}
K -->|是| L[发布到生产（正式上线菜谱）]
K -->|否| M[回滚或修改提示（调整菜谱）]
L --> N[发送成功通知（告诉团队可以用新菜谱了）]
2.3 提示文件的结构设计
提示文件是提示CI的“核心载体”，需要包含提示内容、模型参数、测试用例三大要素。我们用YAML格式（易读、易写）来定义，示例如下：
# 提示文件：customer_support.yaml
name: "电商客服回复提示"
version: "1.0.2" # 版本号，遵循语义化版本规范
model: "gpt-3.5-turbo" # 适用的模型
parameters: # 模型参数
temperature: 0.7 # 输出的随机性（0=固定，1=完全随机）
max_tokens: 150 # 最大输出token数
prompt: | # 提示内容（用|保留换行）
你是一个电商平台的客服助理，需要完成以下任务：
1. 友好回复用户的问题；
2. 引导用户提供订单号（如果没有的话）；
3. 保持回复简洁（不超过3句话）。
用户的问题是：{{user_query}} # 占位符，运行时替换为用户输入
test_cases: # 测试用例（覆盖不同场景）
- id: "case_1" # 测试用例ID
input: "我的订单还没收到，怎么办？" # 用户输入
expected: ["订单号", "查询物流信息"] # 预期输出的关键信息（模糊匹配）
- id: "case_2"
input: "我上周二下的单，订单号是12345，现在还没收到货" # 包含订单号的输入
expected: ["订单号12345", "查询物流信息"] # 预期包含具体订单号
- id: "case_3"
input: "你们的服务太差了！我要投诉！" # 负面情绪输入
expected: ["抱歉", "帮您解决问题"] # 预期包含道歉和解决意愿
2.4 提示测试的三大核心指标
提示测试需要覆盖效果、一致性、性能三大指标，对应菜谱的“味道、稳定性、速度”：
| 指标 | 定义 | 类比菜谱 | 量化方式 |
|---|---|---|---|
| 效果（Effectiveness） | 提示是否能让模型输出符合预期的结果？ | 味道是否符合要求？ | 用测试用例检查输出是否包含预期的关键信息（比如“订单号”）。 |
| 一致性（Consistency） | 同一提示多次运行，输出是否稳定？ | 每次炒的菜味道是否一样？ | 多次运行同一输入，计算输出的相似度（比如用余弦相似度），方差越小越稳定。 |
| 性能（Performance） | 提示的响应时间和token消耗是否在可接受范围内？ | 炒菜速度和食材消耗？ | 记录API响应时间（<2秒）、token消耗（<50 tokens）。 |
三、技术原理与实现：用Jenkins搭建提示CI流水线
3.1 准备工作：环境与工具
在开始之前，你需要准备以下工具：
版本控制：Git（用于存储提示文件）；CI工具：Jenkins（需要安装以下插件：Git、Pipeline、JUnit、Email Extension、AWS CLI（可选））；AI模型：OpenAI GPT-3.5/4、Anthropic Claude等（需要API密钥）；依赖库：Python（用于写测试脚本）、
openai
pyyaml
junit-xml
3.2 流程设计：从“提交”到“部署”的全自动化
提示CI的流水线分为五大阶段（对应Jenkins Pipeline的
stages
| 阶段 | 目标 | 关键操作 |
|---|---|---|
| Checkout | 获取最新的提示文件 | 从Git仓库拉取代码。 |
| Install Dependencies | 安装测试所需的依赖 | 用 |
| Run Tests | 自动化测试提示的效果、一致性、性能 | 运行测试脚本，生成JUnit报告。 |
| Deploy to Staging | 将通过测试的提示部署到预生产环境 | 上传提示文件到S3或数据库（比如预生产的提示存储桶）。 |
| Notify | 通知团队构建结果 | 发送邮件或Slack通知（成功/失败）。 |
| Notify | 通知团队构建结果 | 发送邮件或Slack通知（成功/失败）。 |
3.3 代码实现：从测试脚本到Jenkinsfile
3.3.1 测试脚本：用Python写提示测试
测试脚本是提示CI的“核心引擎”，负责检查提示的三大指标。以下是一个完整的测试脚本（
test_prompt.py
import os
import openai
import yaml
import unittest
from junit_xml import TestSuite, TestCase
from sklearn.metrics.pairwise import cosine_similarity
from sentence_transformers import SentenceTransformer # 用于计算文本相似度
class PromptTest(unittest.TestCase):
def setUp(self):
"""初始化：加载提示文件和模型客户端"""
# 从环境变量获取API密钥（避免硬编码）
self.api_key = os.getenv("OPENAI_API_KEY")
if not self.api_key:
raise ValueError("请设置OPENAI_API_KEY环境变量")
# 加载提示文件（从Git仓库拉取的`prompt.yaml`）
with open("prompt.yaml", "r") as f:
self.prompt_data = yaml.safe_load(f)
# 初始化OpenAI客户端
self.client = openai.OpenAI(api_key=self.api_key)
# 初始化句子嵌入模型（用于计算一致性的相似度）
self.sentence_model = SentenceTransformer("all-MiniLM-L6-v2")
def test_prompt_effectiveness(self):
"""效果测试：检查提示是否能让模型输出符合预期的结果"""
for case in self.prompt_data["test_cases"]:
with self.subTest(case=case["id"]):
# 替换提示中的占位符（比如{{user_query}}）
prompt = self.prompt_data["prompt"].replace("{{user_query}}", case["input"])
# 调用AI模型
response = self.client.chat.completions.create(
model=self.prompt_data["model"],
messages=[{"role": "user", "content": prompt}],
temperature=self.prompt_data["parameters"]["temperature"],
max_tokens=self.prompt_data["parameters"]["max_tokens"]
)
# 获取实际输出
actual_output = response.choices[0].message.content.strip()
# 检查实际输出是否包含所有预期的关键信息
for expected_keyword in case["expected"]:
self.assertIn(
expected_keyword.lower(),
actual_output.lower(),
f"测试用例{case['id']}失败：未包含预期关键词'{expected_keyword}'"
)
def test_prompt_consistency(self):
"""一致性测试：检查同一提示多次运行的输出是否稳定"""
input_text = self.prompt_data["test_cases"][0]["input"] # 用第一个测试用例的输入
prompt = self.prompt_data["prompt"].replace("{{user_query}}", input_text)
outputs = []
# 运行5次，获取输出
for _ in range(5):
response = self.client.chat.completions.create(
model=self.prompt_data["model"],
messages=[{"role": "user", "content": prompt}],
temperature=self.prompt_data["parameters"]["temperature"],
max_tokens=self.prompt_data["parameters"]["max_tokens"]
)
outputs.append(response.choices[0].message.content.strip())
# 计算输出的相似度（用句子嵌入）
embeddings = self.sentence_model.encode(outputs)
similarity_matrix = cosine_similarity(embeddings)
# 计算平均相似度（排除自身对比）
average_similarity = (similarity_matrix.sum() - len(outputs)) / (len(outputs) * (len(outputs) - 1))
# 要求平均相似度≥0.8（越接近1越稳定）
self.assertGreaterEqual(
average_similarity,
0.8,
f"一致性测试失败：平均相似度{average_similarity:.2f} < 0.8"
)
def test_prompt_performance(self):
"""性能测试：检查响应时间和token消耗"""
input_text = self.prompt_data["test_cases"][0]["input"]
prompt = self.prompt_data["prompt"].replace("{{user_query}}", input_text)
# 调用API并记录时间
import time
start_time = time.time()
response = self.client.chat.completions.create(
model=self.prompt_data["model"],
messages=[{"role": "user", "content": prompt}],
temperature=self.prompt_data["parameters"]["temperature"],
max_tokens=self.prompt_data["parameters"]["max_tokens"]
)
end_time = time.time()
# 检查响应时间（<2秒）
response_time = end_time - start_time
self.assertLess(
response_time,
2.0,
f"性能测试失败：响应时间{response_time:.2f}秒 > 2秒"
)
# 检查token消耗（<50 tokens）
total_tokens = response.usage.total_tokens
self.assertLess(
total_tokens,
50,
f"性能测试失败：token消耗{total_tokens} > 50"
)
if __name__ == "__main__":
# 运行测试并生成JUnit报告（Jenkins需要这个报告来展示结果）
suite = unittest.TestLoader().loadTestsFromTestCase(PromptTest)
with open("test-results.xml", "w") as f:
TestSuite.to_file(f, [suite], prettyprint=True)
3.3.2 Jenkinsfile：定义流水线的“执行逻辑”
Jenkinsfile是提示CI的“指挥中心”，用Groovy语言定义了流水线的各个阶段。以下是一个完整的Jenkinsfile示例：
pipeline {
agent any // 用任意可用的Jenkins节点
// 工具配置：指定Python版本（需要在Jenkins中预先配置Python工具）
tools {
python "python3.10"
}
// 环境变量：存储API密钥（用Jenkins凭证管理，避免硬编码）
environment {
OPENAI_API_KEY = credentials("openai-api-key") // 凭证ID：在Jenkins中配置的Secret Text
AWS_ACCESS_KEY_ID = credentials("aws-access-key") // 可选：用于部署到S3
AWS_SECRET_ACCESS_KEY = credentials("aws-secret-key")
}
stages {
// 阶段1：拉取最新的提示文件
stage("Checkout") {
steps {
git branch: "main", url: "https://github.com/your-repo/prompt-repo.git"
}
}
// 阶段2：安装测试所需的依赖
stage("Install Dependencies") {
steps {
sh "pip install --upgrade pip"
sh "pip install openai pyyaml junit-xml sentence-transformers"
}
}
// 阶段3：运行测试（核心阶段）
stage("Run Tests") {
steps {
sh "python test_prompt.py" // 运行测试脚本
}
// 后置操作：无论测试是否通过，都生成测试报告
post {
always {
junit "test-results.xml" // Jenkins会解析这个报告，展示测试结果
}
}
}
// 阶段4：部署到预生产环境（只有测试通过才执行）
stage("Deploy to Staging") {
when {
expression { currentBuild.result == "SUCCESS" } // 只有成功才部署
}
steps {
// 示例：将提示文件上传到AWS S3的预生产桶
sh """
aws s3 cp prompt.yaml s3://your-prompt-bucket/staging/
--region us-east-1
--acl private
"""
// 可选：更新预生产环境的提示配置（比如数据库）
// sh "python update_staging_prompt.py"
}
}
// 阶段5：通知团队结果（成功/失败）
stage("Notify") {
steps {
script {
// 定义邮件内容
def subject = "提示CI构建结果：${currentBuild.result}（${env.BUILD_TAG}）"
def body = """
构建编号：${env.BUILD_NUMBER}
构建结果：${currentBuild.result}
测试报告：${env.BUILD_URL}/testReport/
日志链接：${env.BUILD_URL}/console
提示文件版本：${env.GIT_COMMIT}（${env.GIT_BRANCH}）
"""
// 发送邮件（需要安装Email Extension插件）
emailext(
subject: subject,
body: body,
to: "dev-team@example.com", // 接收通知的邮箱
from: "jenkins@example.com" // 发送邮箱（需要在Jenkins中配置）
)
// 可选：发送Slack通知（需要安装Slack插件）
// slackSend(
// channel: "#dev-team",
// color: currentBuild.result == "SUCCESS" ? "good" : "danger",
// message: subject + "
" + body
// )
}
}
}
}
// 全局后置操作：无论构建结果如何，都清理工作空间
post {
always {
cleanWs() // 清理工作空间，避免占用磁盘空间
}
}
}
3.3.3 关键细节说明
（1）API密钥管理：避免硬编码
在测试脚本和Jenkinsfile中，绝对不能硬编码API密钥（比如
openai.api_key = "sk-xxx"
在Jenkins中配置凭证（Credentials）：选择“Secret Text”类型，输入API密钥，保存时指定一个凭证ID（比如
openai-api-key
credentials()
environment { OPENAI_API_KEY = credentials("openai-api-key") }
os.getenv("OPENAI_API_KEY")
（2）测试报告：Jenkins如何展示结果？
测试脚本生成的
test-results.xml
成功的测试用例会显示为“Passed”；失败的测试用例会显示为“Failed”，并列出失败原因（比如“未包含预期关键词‘订单号’”）；你可以点击每个测试用例，查看详细的输出（比如模型的实际输出）。
（3）模型输出的“不确定性”解决办法
AI模型的输出是生成式的，同一提示多次运行可能会有不同结果。为了减少这种不确定性，你可以：
降低温度参数（Temperature）：温度越低（比如0.1），输出越稳定（但可能越生硬）；增加测试次数：比如在一致性测试中运行10次，而不是5次，取平均相似度；用模糊匹配：测试效果时，不要用精确匹配（比如“必须包含‘订单号’这三个字”），而是用模糊匹配（比如“包含‘订单号’或‘订单编号’”）。
（4）性能测试的优化技巧
减少提示长度：提示越长，token消耗越多，响应时间越长。比如将“请友好地回复用户的问题，并引导他们提供订单号”简化为“友好回复用户，引导提供订单号”；调整max_tokens参数：设置合适的
max_tokens
gpt-3.5-turbo
gpt-4
四、实际应用：电商客服提示的CI实践
4.1 案例背景：从“低效”到“高效”的提示优化
某电商公司的AI客服机器人，原本的提示是：
“回复用户的问题。”
结果模型输出经常忽略“引导订单号”的要求，比如用户问“我的订单还没收到”，模型输出是“很抱歉，你的订单还没收到，请耐心等待”，没有引导用户提供订单号，导致用户需要多次来回沟通。
4.2 提示优化：添加“引导订单号”的要求
开发者修改了提示，添加了“引导用户提供订单号”的要求：
“你是一个电商平台的客服助理，请友好回复用户的问题，并引导他们提供订单号（如果没有的话）。用户的问题是：{{user_query}}”
4.3 用提示CI流程验证优化效果
（1）提交提示文件到Git
将修改后的
prompt.yaml
git add prompt.yaml
git commit -m "优化客服提示：添加引导订单号的要求"
git push origin main
（2）Jenkins触发流水线
Git提交后，Jenkins会自动触发流水线（需要在Jenkins中配置“Git触发”：选择“Poll SCM”或“Webhook”）。
（3）查看测试结果
Jenkins运行完测试后，在“Test Result”页面可以看到：
效果测试：3个测试用例全部通过（比如测试用例1的输入“我的订单还没收到”，输出包含“订单号”和“查询物流信息”）；一致性测试：平均相似度0.92（≥0.8，符合要求）；性能测试：响应时间1.2秒（<2秒），token消耗42（<50 tokens）。
（4）部署到预生产环境
测试通过后，Jenkins会将提示文件上传到S3的预生产桶。客服团队从预生产环境获取新提示，进行人工验证：
客服人员输入“我的订单还没收到”，模型输出“您好，很抱歉您的订单还没收到。请提供您的订单号，我会帮您查询物流信息。”；客服人员反馈：“这个输出比之前好多了，用户不需要多次沟通就能提供订单号。”
（5）发布到生产环境
人工验证通过后，开发者将预生产环境的提示文件发布到生产环境（可以用Jenkins的“持续交付（CD）”流程，比如添加一个“Deploy to Production”阶段，需要人工确认后执行）。
4.4 常见问题及解决方案
在实际应用中，你可能会遇到以下问题，我们提供了对应的解决方案：
| 问题 | 原因 | 解决方案 |
|---|---|---|
| 测试用例误报（False Positive） | 测试用例的预期关键词设置得太严格（比如“必须包含‘订单号’这三个字”）。 | 用模糊匹配（比如“包含‘订单号’或‘订单编号’”），或用正则表达式（比如 |
| 一致性测试失败 | 温度参数太高（比如0.9），导致输出变化太大。 | 降低温度参数（比如0.3），或增加测试次数（比如运行10次）。 |
| API调用失败 | 网络问题或API密钥过期。 | 在测试脚本中添加重试机制（比如用 |
| 测试报告不显示 | 测试脚本没有生成 |
检查测试脚本的输出路径，确保 |
五、未来展望：提示持续集成的“下一步”
5.1 技术发展趋势
（1）更智能的测试：AI自动生成测试用例
当前的测试用例需要人工设计，未来可以用AI自动生成测试用例。比如用
gpt-4
（2）更全面的指标：整合用户反馈
当前的测试指标主要是“技术指标”（效果、一致性、性能），未来可以整合“用户反馈”（比如用户对AI回复的满意度评分）。比如，将用户反馈的数据导入Jenkins，作为提示是否需要优化的依据。
（3）与CD结合：提示的自动发布
当前的流程中，从预生产到生产需要人工验证，未来可以用持续交付（CD） 实现自动发布：比如当预生产环境的用户反馈满意度≥90%时，自动将提示发布到生产环境。
5.2 潜在挑战
（1）模型的“黑盒性”
AI模型的输出是“黑盒”的，很难完全预测。比如，即使提示不变，模型版本更新（比如OpenAI升级了
gpt-3.5-turbo
（2）测试的“主观性”
有些指标（比如“友好性”）很难用自动化测试覆盖。比如，模型输出的“友好性”需要人工判断。解决方案：将自动化测试与人工测试结合（比如自动化测试覆盖80%的场景，人工测试覆盖20%的主观场景）。
（3）成本问题
频繁调用AI模型的API会产生成本（比如OpenAI的
gpt-3.5-turbo
减少测试次数（比如只在关键分支（main）运行测试，其他分支不运行）；使用更便宜的模型（比如
gpt-3.5-turbo
gpt-4
5.3 行业影响
提示持续集成的普及，将推动AI应用的“工业化”：
提示工程标准化：企业会制定提示开发的规范（比如提示文件的结构、测试用例的设计）；AI DevOps崛起：DevOps工程师需要掌握提示CI/CD的技能，将AI流程纳入现有体系；AI应用可靠性提升：用户会看到更稳定、更符合预期的AI输出，提升对AI的信任度。
六、总结：让提示开发更“可靠”的终极武器
提示持续集成是AI时代的“提示管理必修课”。通过Jenkins搭建自动化流水线，你可以将提示的开发、测试、发布打造成“可重复、可验证、可追溯”的流程，解决手动管理的痛点。
本文的核心要点：
为什么做？ 解决提示开发中的版本混乱、测试不充分、反馈滞后问题；怎么做？ 用Jenkins搭建提示CI流水线，覆盖“拉取→测试→部署→通知”全流程；关键是什么？ 设计合理的测试用例，覆盖效果、一致性、性能三大指标；未来方向 整合更智能的测试、更全面的指标，实现提示的自动发布。
七、思考问题：让你更深入的探索
如何设计“多模型”的提示CI流程？（比如同时支持OpenAI和Anthropic的模型）；如何处理“长提示”的性能问题？（比如提示长度超过1000 tokens）；如何用AI自动生成提示的测试用例？（比如用
gpt-4
八、参考资源
Jenkins官方文档：https://www.jenkins.io/doc/OpenAI API文档：https://platform.openai.com/docs/提示工程指南：https://promptingguide.ai/JUnit格式说明：https://junit.org/junit5/docs/current/user-guide/#writing-testsSentence-BERT文档：https://www.sbert.net/
附录：提示文件模板
# 提示文件模板：适用于电商客服场景
name: "电商客服回复提示"
version: "1.0.0"
model: "gpt-3.5-turbo"
parameters:
temperature: 0.7
max_tokens: 150
prompt: |
你是一个电商平台的客服助理，需要完成以下任务：
1. 友好回复用户的问题（用“您好”开头，“谢谢”结尾）；
2. 如果用户没有提供订单号，引导他们提供（比如“请提供你的订单号，我会帮你查询”）；
3. 保持回复简洁（不超过3句话）。
用户的问题是：{{user_query}}
test_cases:
- id: "case_1"
input: "我的订单还没收到，怎么办？"
expected: ["订单号", "查询物流信息"]
- id: "case_2"
input: "我上周二下的单，订单号是12345，现在还没收到货"
expected: ["订单号12345", "查询物流信息"]
- id: "case_3"
input: "你们的服务太差了！我要投诉！"
expected: ["抱歉", "帮您解决问题"]
附录：测试脚本依赖安装命令
pip install openai pyyaml unittest junit-xml sentence-transformers
附录：Jenkins插件安装
在Jenkins的“Manage Plugins”页面，搜索并安装以下插件：
Git Plugin（拉取Git代码）；Pipeline Plugin（定义流水线）；JUnit Plugin（展示测试结果）；Email Extension Plugin（发送邮件通知）；AWS CLI Plugin（部署到S3，可选）；Slack Plugin（发送Slack通知，可选）。
希望本文能帮助你搭建自己的提示CI流程，让提示开发更高效、更可靠。如果你有任何问题或建议，欢迎在评论区留言！
© 版权声明
文章版权归作者所有，未经允许请勿转载。
相关文章
暂无评论...
