用 AI 解决真实开发问题的实践之路 —— 三个一线案例的得失复盘

写在前面：这不是一篇"AI 万能论"的鼓吹文章，也不是"AI 没什么用"的反向毒鸡汤。
它来自我最近一段时间在生产项目里和 AI 共同作战的真实记录 —— 有让我惊喜的成功，有让我抓狂的踩坑，更有让我重新理解"人 + AI"协作边界的几个深夜。
三个案例，一份反思。希望对正在用 AI 编程的你有点帮助。

---

一、为什么写这篇文章

最近半年，AI 辅助编程的工具（Cursor、Qoder 之类的 IDE Agent）几乎已经成了我每天打开电脑后的"第一个同事"。从代码补全，到全链路接入第三方 API，再到生产事故排查，能交给 AI 干的活越来越多。

但用得越多，越能感觉到一件事：AI 不是一个均匀强的伙伴 —— 它在某些维度上像个"高级工程师"，在另一些维度上又像个"读不到环境"的实习生。

最近我手头同时推进了三件事：

1. 给一个委托单系统接入"简道云"做表单数据录入；
2. 排查生产环境上"S3 模板下载失败"导致的订单页打不开；
3. 把团队跑通的 Nginx 路径分流方案，搬到客户那台只能用 IIS 的 Windows 服务器上。

三件事，一件完美成功，一件最终定位但是过程曲折，一件部分成功 + 部分卡死。
正好横跨了"业务接入 / 故障排查 / 基础设施迁移"三个不同的工种，也让我对"AI 到底擅长什么、不擅长什么"看得相对清楚一些。

下面我会按这三个案例的真实顺序讲，不刻意美化也不夸大。

---

二、案例一：在线委托单接入简道云 —— AI 写业务代码时的"高速公路"

1. 需求是什么

业务方希望在我们的"在线委托单"页面里加一个按钮：点开按钮 → 弹出一个表单 → 填完后能直接把数据写到客户搭的简道云应用里，并且支持增删改查、查询历史录入记录。

需求看似简单，但里面藏了几个不那么"友好"的小细节：

• 表单里既有普通字段（状态、客户等级、订单金额、备注……），也有简道云特有的"成员单选/多选字段"（业务员、业务助理、指定客服）；
• 三类用户的可选值要从另一张简道云数据表动态查出来；
• 选了"实验室"后，业务员/助理/客服要联动自动带出；
• 状态、实验室、客户等级这些选项后续还会调整，不能写死。

2. AI 是怎么和我配合的

这个案例里我做的事其实很"轻"：

• 把已有后端类（JdyFormData）、前端弹窗框架、表字段定义贴给 AI；
• 告诉它简道云的 app_id / entry_id / 字段映射；
• 提出原则：“前端不直连简道云，所有简道云调用都要走自家后端中转”。

剩下的方案设计、后端 DTO、Service、Controller、前端 Store、Dialog 组件、按钮入口接入，全部由 AI 一气呵成，按"先后端 CRUD → 再前端弹窗 → 再联调"的顺序逐层推进。

期间我们一起踩了一些有意思的坑：

问题	现象	根因
点按钮没弹窗	控制台日志一切正常	Pinia setup store 把 ref({}) 自动 unwrap 成了 reactive，外部访问时多写了一层 .value
实验室联动后业务员不带值	助理、客服都正常	简道云 user 单选字段返回的是单 object，不是数组，旧解析逻辑直接丢弃
字段全是 undefined	后端日志看似 OK	后端 JSON 命名策略是"全小写"，前端按 camelCase 读，自然全空
提交成功但成员字段没写进去	简道云不报错	user 字段写入不接受 {value:[{username:"x"}]}，要 {value:"x"} 字符串值

每一个问题，AI 的处理流程几乎都是同一套：

1. 列出多个假设（H1/H2/H3……）；
2. 加少量探针日志，让我去复现；
3. 拿到运行时数据后，明确指出哪个假设被验证、哪个被排除；
4. 修完之后主动清理探针，保留代码干净。

那种感觉就像是有一个"科班训练过的工程师"坐在我旁边，只不过他不需要喝咖啡，也不会在 4 点钟跑去开会。

3. 这个案例的关键感悟

这个案例之所以顺，是因为它命中了 AI 的"主场"：

• 需求边界清晰：要做什么、字段叫什么、提交到哪里，都是确定的；
• 上下文充分：相关代码、字段表、接口文档全部贴给了 AI；
• 可逐步验证：每一步都能看到接口响应、看到弹窗、看到简道云后台是否真的写入了。

一句话总结：在"明确需求 → 代码实现"这条链路上，AI 是真正意义上的加速器。
原本我自己写大概要 2.5～3 天的事，最后从需求澄清到生产可用，前后只花了大概半天到一天。

---

三、案例二：S3 模板下载失败 —— AI 排查问题时的"放大镜"和"盲区"

1. 现象很简单，根因很深

线上某天有人喊：“订单页打不开了，弹出’数据加载失败：未找到完整订单数据’。”

这条报错本身就是一个**“洋葱”** —— 它是后端业务的一句兜底文案：当一个委托单既没有内联模板 JSON、也没有可用文件流时，统一返回这一句。

也就是说，这句话背后可能藏着至少四种根因：

• 委托单数据库里就找不到这个 GUID；
• 数据库有，但模板/版本号对不上；
• 全局 S3 配置缺失；
• S3 文件存在，但服务器拉不下来。

2. AI 的排查链路：一层一层剥洋葱

让我印象很深的是，AI 在这个案例里全程没有急着下结论。它先帮我把整条链路画了出来：

前端弹窗 → mainStore.initData → /api/Main/GetOrderInfo
  → MainController（拿到 ElnOrderVo 后做完整性校验）
  → ElnMainService.GetFolderInfoService
      → Folders 表（按 GUID + IsDelete=0 查）
      → ModelVersion / OrderVersion 表（按版本号查模板路径）
      → Configurations 表（拿 S3 endpoint / account）
      → S3Helper.GetElnFtpFiles → S3Library2.GetObject(...)

然后随着我每一次提供新的线索，AI 都会精确把当前怀疑面收窄：

线索	AI 的判断
“本地正常，部署到服务器就报错”	95% 是环境差异，不要先怀疑代码
“前端响应是 200”	HTTP 200 不代表业务成功，让我去看 success / msg 字段
“服务器端日志只有 ASP.NET 管道信息”	业务分支没打日志，建议在 GetFolderInfoService 加 LogWarning
加日志后 → [GetFolderInfo] 原因="S3模板与文件均为空"	终于把问题锁定在 S3 取对象这一层
Test-NetConnection 通	网络层 OK，但应用层 GetObject 仍可能 403 / 404

到这里，AI 已经把"一句报错"层层拆解成了：网络层 OK + DB 路径解析 OK + 配置读取 OK，问题落在 S3Library2.GetObject 内部静默返回 false。

3. AI 的"盲区"出现了

接下来出现了几个 AI 没办法替我做的事：

• 它不能登上那台服务器；
• 它不能用一致的 AccessKey 去 MinIO 控制台直接 head-object；
• 它不能判断 IIS 应用池是否加载了用户配置文件；
• 它不能直接看 MinIO 服务端的访问日志。

于是它给我列出了一份相当有结构的"运维侧排查清单"：

网络代理 / IIS 应用池身份 / Temp 目录写权限 / MinIO 按客户端 IP 白名单 / 系统时间偏差 / DLL 是否真的发布到了线上 / 等等

然后我就老老实实一个一个去验证。

4. 真正的"灵感时刻"

转折发生在我突然意识到：最近上了一个"签章"功能，里面也用了 S3Library2，连的是另一套桶和账号。

我把这个信息告诉 AI，它马上重组了假设：

“如果 S3Library2.dll 内部用了 class 级别的 static 字段缓存 AmazonS3Client 或 endpoint，那即使你 new 了两个实例，底层仍然共享状态。
本地是单线程串行调用，从来不会撞；线上是 IIS 多线程并发，签章和模板下载几乎同时进入，凭据/桶被互相覆盖 → GetObject 返回 false。”

修复方案非常小：把 private static readonly S3Library2.S3Library2 s3Library = new ... 改成"每次调用都 new 一个新实例"。改完两个文件、一共 6 行代码，发布上去之后 —— 问题消失。

5. 这个案例的关键感悟

这是我对"人 + AI 协作边界"理解最深的一次：

• AI 极擅长的事：把一句报错拆解成完整调用链；列出全部可能假设；给出针对性的探针/日志/排查命令；在我提供新线索时，立刻重组假设。
• AI 必然受限的事：它没办法替我"上服务器"、“看 MinIO 控制台日志”、“敲 PowerShell”。
• 真正决定问题能否解决的关键：不是 AI 多聪明，而是我能不能持续把"环境侧的真实信息"喂给它。

如果我没有意识到"签章功能也用了 S3Library2"这个上下文，AI 永远也不可能凭空猜出"static 实例并发冲突"这件事。
反过来，一旦我把这个上下文给到它，它能在 30 秒内给出修复方案。

信息差，是 AI 排错能力的真正天花板。

---

四、案例三：Nginx → IIS 迁移 —— AI 在基础设施上的"半盲区"

1. 背景：WAF 要求统一入口

公司因为 WAF 改造，希望把"多域名 + 多端口"的旧架构，改成"统一 443 入口 + 路径分流"。我们已经在 Nginx 上跑通了一套：

/fdd/         → 主前端
/fdd/test/    → 测试前端
/fdd/api/     → 后端接口
/third-party/ → AI 接口

现在客户那边硬性要求：用 IIS 复现这套方案，端口 8090。

2. AI 给方案的速度极快

我把 Nginx 的现有配置贴给 AI，它几乎立刻给出了 IIS 等价方案：

能力	Nginx	IIS
子路径静态站点	alias + try_files	应用程序 + 各目录 web.config SPA 回退
API 反向代理	proxy_pass	URL Rewrite + ARR Rewrite
去掉路径前缀	proxy_pass 末尾加 /	捕获组 {R:1} 拼到目标 URL
配置集中度	单文件 nginx.conf	站点根 + 多个应用 + 多个 web.config

它甚至贴心地把 SPA 回退、API 代理、/third-party/ 转发的完整 web.config 模板都写好了，照贴就行。

3. 但卡点接二连三冒出来

落地之后我发现一连串问题：

• 访问 http://localhost:8090/fdd → 404.0；
• 错误页里"处理程序：StaticFile，物理路径：C:\inetpub\wwwroot\fdd"；
• 站点功能里有 URL Rewrite，但根本没看到 ARR；
• 我把 /third-party/ 配成代理到 127.0.0.1:8090，结果 IIS 自己代理自己，循环了……

每个问题 AI 都能给出解释（而且解释得相当准确）：

• “404 不是网站没启动，是 IIS 在错误的地方用错误的方式找静态文件 —— 你需要把 /fdd 配成应用程序，不是普通目录”；
• “URL Rewrite ≠ 反向代理 —— 你必须装 ARR 并启用 Server Proxy Settings”；
• “IIS 监听的是 8090，那后端服务就不能也是 8090，否则就是死循环”；
• “如果 ARR 没勾 Preserve Host Header，后端拿到的 Host 会是 127.0.0.1，不是原始域名”。

4. 最后只跑通了一半

实话实说：这个案例没有彻底成功。

最终我们做到了：

• 静态文件能通过 IIS 出来；
• 单层 API 代理能跑；

但仍卡在：

• ARR 在那台特殊的 Windows 上死活装不利索；
• 多层路径（/fdd/api/ 与 /fdd/test/api/）在 IIS 模式下分流不够干净；
• 团队最后倾向于"在 Windows 上也起个 Nginx，绕开 IIS"。

5. 这个案例的关键感悟

这次踩坑让我意识到一个非常重要的事实：

AI 在"应用层代码"上是高手，但在"操作系统 + 中间件 + 服务器配置"这一层，它跟人一样需要看到现场。

具体来说：

• AI 能告诉你 IIS 应该装 ARR；
• AI 能给你一份完整的 web.config；
• AI 能告诉你 proxy_pass http://x:y/ 末尾的斜杠会改变 URL 拼接；
• 但 AI 没办法确认你那台 IIS 服务器上"应用程序请求路由缓存"图标到底有没有；
• 也没办法确认你点开"Server Proxy Settings"以后到底有没有勾上 Enable Proxy；
• 更没办法判断你是不是"有 URL 重写就以为有反向代理"。

而恰恰是这些"图标到底有没有 / 勾没勾选 / 端口有没有冲突"的小事，决定了一个 IIS 配置最后能不能跑起来。

一个最深刻的教训：目标一致，载体不同，失败往往出在"以为装了 URL 重写就等于装了 Nginx"。
这种"概念上看起来一样，工程上完全不一样"的隐性差异，是 AI 最容易忽略的盲区，也是人类工程师必须自己负责验证的地方。

---

五、综合感悟：AI 是个超级加速器，但不是替代品

把这三件事放在一起看，能总结出一些规律。

1. 成功案例的共性

• 需求收敛：要做什么、字段叫什么、写到哪儿，先在一张表里写清楚；
• 上下文充分：把相关代码、接口文档、字段映射、错误日志一次性给 AI；
• 可验证的小步：每改一段就跑一次，每跑一次就看响应、看日志、看页面；
• 一层只干一件事：后端管业务、前端管 UI、Nginx/IIS 管路由，分层清楚 AI 才能按层交付。

2. 失败 / 卡住案例的共性

• 环境隔离：AI 没办法登服务器、没办法看 MinIO 控制台、没办法看 IIS 图标；
• 信息缺失：关键现象藏在我自己脑子里（比如"签章也用了 S3Library2"），不主动告诉 AI 它就猜不到；
• 概念相似但工程不等价：URL 重写 ≠ 反向代理；/fdd 目录 ≠ /fdd 应用程序；8090 入口 ≠ 8090 后端；
• 现象倒推架构：白屏、404 把 JS 当 HTML 返回这种事，多数是路径或 handler 配错了，不是业务代码写错。

3. AI 最有用的几个时刻

• 接入第三方 API 时，按你给的字段表写出端到端代码；
• 把一句模糊的报错拆解成完整调用链 + 多个候选根因；
• 跨语言、跨框架的"等价配置"翻译（Nginx ↔ IIS、Vue 2 ↔ Vue 3 等等）；
• 写探针日志、收日志后给出收窄结论；
• 修完一段问题之后主动清理临时调试代码。

4. 必须由人来兜底的几件事

• 方向判断：“这件事到底要不要做？要不要换个技术栈？”
• 环境验证：上服务器跑命令、看物理路径、看进程、看权限；
• 现场观察：图标到底装没装？开关到底勾没勾？端口到底通没通？
• 历史上下文：“这个问题最近还动过别的什么模块？”

5. 一个真实的体感

这三件事一起做下来，最直观的感觉是：

原本要 3 天才能搞定的事，配合 AI 能压缩到半天到一天；
但原本就需要"上服务器 + 看现场"的事，AI 一分钟也帮不上你。

更准确地说：AI 不是把工作量"消除"了，而是把工作量从"敲键盘"挪到了"做决策、给上下文、做验证"上面。
你越擅长把现场情况清楚地讲给它，它越能像个高级工程师一样工作；你给的越含糊，它就越像一个"看起来很自信、其实在乱猜"的实习生。

---

六、结语：一种新的"协作姿势"

我现在看 AI 编程，更像是看一个"超级加速器" —— 它能让一个普通工程师在熟悉的领域里跑得比以前快 3～5 倍，让一个有经验的工程师把更多精力放在"判断和验证"上，而不是"码字和查文档"。

但它改变不了几件事：

• 项目本质的复杂度还在；
• 生产环境的物理性还在（网络、防火墙、服务器、IIS、磁盘权限……）；
• 业务理解和工程经验还在。

未来一两年，AI 工具一定会更强 —— 也许它能直接接管一部分服务器排查、能跑命令、能读控制台日志。但即使到那一天，"人对方向负责、AI 对实现加速"这种协作分工的本质，我相信也不会变。

最稳的路线，依然是：

人定方向 + 人验环境 + AI 出方案 + AI 写代码 + 人最后兜底。

把这种姿势练熟，比追逐每一个新模型、每一款新工具都重要得多。

---

—— 写于一次同时啃下"业务接入 / 故障排查 / 基础设施迁移"三件事之后，献给所有正在和 AI 一起写代码的同行。