细节决定成败，AI并非无敌

最近做一个转发请求的后端功能，跟以往的区别是要传一个file。

然后难蚌的一幕出现了，搜了deepseek，千问，还有好几篇文章，给出的方案都是类似的，但是都跑不通。

以deepseek为例

var client = new HttpClient();

var url = "你的API地址"; // 例如: "http://example.com/api/upload"

var formContent = new MultipartFormDataContent();

var filePath = @"你的文件路径"; // 例如: @"C:\path\to\your\file.txt"

var fileName = "file.txt"; // 服务端期望的文件名（可选）

var fileContent = new ByteArrayContent(System.IO.File.ReadAllBytes(filePath));

fileContent.Headers.ContentDisposition = new System.Net.Http.Headers.ContentDispositionHeaderValue("form-data") { Name = "\"file\"", // 注意这里的双引号，取决于API是否需要引号，有些API可能需要，有些则不需要 FileName = "\"" + fileName + "\"" // 同上，取决于API的要求 };

formContent.Add(fileContent);

var response = await client.PostAsync(url, formContent);

 

编译确实没问题，但是请求怎么试怎么报错，搞了一上午没有思路，对比同事swagger的请求也没看出什么区别，确实要multipartContent。

中午睡醒后忽有灵感，对比我本地swagger请求后端时network的参数。发现原来是contect-disposition 这里 name没对

 

修改配置后请求成功，代码如下

public static async Task<bool> Upload(IFormFile file, HttpClient client)
{
var multipartContent = new MultipartFormDataContent();

var fileStream = file.OpenReadStream();
var fileContent = new StreamContent(fileStream);
multipartContent.Add(fileContent, "files", file.FileName);

var result = await client.PostAsync("your url", multipartContent);

}

这里的原因就是参考多篇网站文章，生成了最可能的结果，并保证了编译性，但是这个结果跑起来是否有效，AI实际是没法保证的。

所以AI虽然能给出一些思路，但是最终调试和背锅还是要靠人。