请购单的描述中是否可以自动显示AC？
简短的回答是是的。
首先，我需要声明的是，目前没有现成的方法来满足您的需求。在10月1日刚刚发布的最新sprint-176-update中，MS引入了一个新特性，当合并拉取请求时，自定义工作项状态。但它只针对工作项状态，不针对其他字段。

要解决此请求，我们可以在目标分支上添加Build Validation以调用REST API Pull Requests - Update，从而使用任务/故事的验收标准更新描述。

PATCH https://dev.azure.com/{organization}/{project}/_apis/git/repositories/{repositoryId}/pullrequests/{pullRequestId}?api-version=6.0

从上面的REST API URL，我们可以知道，如果我们想使用REST API拉取请求-更新，我们需要提供pullRequestId。
在预定义的变量中，有一个变量System.PullRequest.PullRequestId，我们可以使用它来获取pullRequestId。
在获得pullRequestId之后，我们可以使用另一个REST API Pull Request Work Items - List来获得与拉取请求相关联的工作项：

GET https://dev.azure.com/{organization}/{project}/_apis/git/repositories/{repositoryId}/pullRequests/{pullRequestId}/workitems?api-version=6.0

我们可以获取工作项ID：

现在，我们可以使用Work Items - Get Work Item来获得验收标准的值：

最后，我们可以使用REST API Pull Requests - Update，用任务/故事的接受标准更新描述。
下面是我的测试powershell脚本：

$PullRequestId = $Env:System_PullRequest_PullRequestId

Write-Host "Current PullRequestId is $PullRequestId"

$url = "https://dev.azure.com/<YourOrganizationName>/<YourProjectName>/_apis/git/repositories/<YourRepoId>/pullRequests/$($PullRequestId)/workitems?api-version=6.0"
$PullRequestWorkItems= Invoke-RestMethod -Uri $url -Headers @{   
 Authorization = "Bearer $env:SYSTEM_ACCESSTOKEN"
} -Method Get

$WorkItemId= $PullRequestWorkItems.value.id

Write-Host This is WorkItems Id: $WorkItemId

$Testurl = "https://dev.azure.com/<YourOrganizationName>/<YourProjectName>/_apis/wit/workitems/$($WorkItemId)?api-version=6.0"
$WorkitemInfo= Invoke-RestMethod -Uri $Testurl -Headers @{   
 Authorization = "Bearer $env:SYSTEM_ACCESSTOKEN"
} -Method Get

$AcceptanceCriteria= $WorkitemInfo.fields.'Microsoft.VSTS.Common.AcceptanceCriteria'

Write-Host This is Acceptance Criteria info: $AcceptanceCriteria

$UpdatePRurl = "https://dev.azure.com/<YourOrganizationName>/<YourProjectName>/_apis/git/repositories/a<YourRepoId>/pullRequests/$($PullRequestId)?api-version=6.0"

$connectionToken="Your PAT"
$base64AuthInfo= [System.Convert]::ToBase64String([System.Text.Encoding]::ASCII.GetBytes(":$($connectionToken)"))

$headers = @{ Authorization = "Bearer $env:SYSTEM_ACCESSTOKEN" }

$body=@"
  {
    "description": "$($AcceptanceCriteria)"
  }
"@

Write-Host "$url"
$response= Invoke-RestMethod -Uri $UpdatePRurl -ContentType "application/json" -Body $body -headers @{authorization = "Basic $base64AuthInfo"} -Method PATCH

这是测试结果：

拥有一个包含详细信息的拉取请求当然可以改善审阅者的体验，并且由于PR与提交历史相关联，PR的描述也可以帮助审阅历史的个人。虽然没有将工作项的详细信息复制到PR描述的内置功能，但是有几个选项。

合并请求策略的选项

1.需要链接的工作项：策略确实支持要求将工作项链接到PR的选项。这些工作项确实会展开为描述，并轻松地超链接到任务。
1.要求注解解析：你可以在请购单上添加一条评论，要求作者提供更多的细节。请购单在作者满足这一要求之前不会关闭。

改进拉取请求说明的选项

1.合并请求模板：支持在PR创建之前使用默认文本填充PR。这只是一个具有特殊命名约定的降价文件，因此没有添加自动化的选项，但它的目的是让您在PR被接受之前与PR作者沟通您想要的内容。http://www.bryancook.net/2020/06/using-templates-to-improve-pull.html?m=1
1.提交消息：我鼓励您的团队提供更好的提交消息。如果他们在消息中包含工作项编号（#1234），则消息将自动扩展为工作项描述，并自动将工作项链接到PR。您甚至可以包含语法来更改工作项的状态（Resolved：编号1234）
1.降价：PR描述可以用降价格式来写，这允许PR作者为他们的改变提供一个好的案例，包括图像、表格等。

PR可扩展性选项

老实说，我在这里包括这些是为了完整性。这是大量的代码和头痛，以克服开发人员卫生。
1.自定义版本：您可以编写一个构建定义，在每次代码更改时运行，以检查构建的细节，如果某些细节不存在，则会失败。（PR ID）可用作构建的环境变量（Build.Reason、Build.SourceBranch），因此您可以使用REST API to fetch the PR information并执行一些自定义检查，例如您期望的某些关键字或格式的存在。然后，您可以将此生成定义关联为PR策略中的必需生成。
1.状态API：与上述方法类似，创建一个构建，该构建查找是否存在您的构建定义插入到PR描述中的某些关键字。如果未找到此文本，请使用API获取工作项（如果链接到PR）的详细信息，更新PR并将状态消息发布到PR。将状态检查的定义作为必需项添加到PR策略中。
1.Webhook +状态API：与这两种方法类似，您可以设置自定义webhook，以便在创建或更新PR时调用自定义端点，而不是触发构建。自定义端点将状态消息发布回PR，并将PR策略设置为强制执行该消息。This article outlines how to create a Azure Function to perform a custom policy。
作为一个评论者，你要记住的一个关键点是，你不必在PR满足你的需要之前完成它。

这是可能的，但它不是直接的：）
我想到的选项之一是通过分支策略分配一个可选的审阅者：

你可以进入项目设置-〉存储库-〉自动包含的审阅者。你可以使用一个没有真实的身份的服务账户（或任何其他账户）并将其分配给为特定分支创建的每个PR。当您将此类分配设置为可选时，您将能够完成PR而无需该账户的接受，并且PR的提要将添加描述，可能是你的空调。
当然，这是假设你有通用AC的情况下。如果你想基于任务AC添加AC，你可以利用Azure DevOps的REST API，并在每次创建PR时添加它们。需要一些额外的编程，但这仍然是可行的。