AI 结对编程：如何让 AI 跳出死循环？

问题背景

在一次开发过程中，遇到了一个典型但又颇具迷惑性的渲染问题：Markdown 表格的行分割线在 Xcode 预览中正常显示，但在运行时完全消失。

代码块中的代码内容在 Xcode 预览中正常显示，但在运行时完全消失。

这类问题通常与运行环境差异、渲染上下文或视图修饰符有关。接下来，我记录了自己与 AI 结对编程、一步步定位并解决问题的过程。

问题分析过程

我并没有一开始就把两个现象同时抛给 AI。原因很简单，第二个问题（代码块消失）涉及的代码更复杂，极容易把 AI 带进错误方向。

直觉告诉我，这两个现象很可能是同一个根因的不同表现。因此，我选择先挑一个“看起来更简单”的现象：表格分割线消失，作为切入点，让 AI 先集中精力解决一个问题。

第一阶段：错误的假设

AI 的第一反应非常“教科书式”，它将注意力放在了表格样式配置上：

// Theme+Zane.swift
.table { configuration in
  configuration.label
    .fixedSize(horizontal: false, vertical: true)
    .markdownTableBorderStyle(.init(.horizontalBorders, color: .grid))
    .markdownMargin(top: .em(1.6), bottom: .zero)
}

它提出了几个假设：

1. 颜色 .grid 在运行时未正确解析
2. MarkdownUI 的边框样式在运行时未正确应用
3. 环境变量（colorScheme）未正确传递

这些假设看起来合理，但都隐含着一个前提：问题一定出在 Markdown 样式本身。

第二阶段：调试验证

为了验证这些假设，我按 AI 的建议加入了一些调试代码：

// 打印 colorScheme 值
.onAppear {
    print("colorScheme: \(colorScheme == .dark ? "dark" : "light")")
}

// 临时改为红色验证
.markdownTableBorderStyle(.init(.horizontalBorders, color: .red))

结果非常明确：

• Xcode 预览：红色边框可见
• 实际运行：依然不可见
• colorScheme 值正常

这一步基本可以确认：

• MarkdownUI 的样式机制是生效的
• 边框颜色、主题配置本身没有问题
• 问题只存在于运行时渲染环境

第三阶段：陷入死循环（重复多次）

我明确向 AI 反馈：

MarkdownUI 和自定义主题之前一直正常，现在才出问题，说明根因很可能不在这里，请从其他方向排查。

但 AI 并没有真正“换脑子”，而是开始在同一条错误路径上反复尝试：

• 修改 .grid 颜色定义
• 改用系统颜色
• 调整边框样式配置
• 在 tableCell 中添加 overlay

这正是 AI 结对编程中最常见的问题之一在错误假设下不断做局部优化，形成思维死循环。

第四阶段：跳出循环

我不得不更明确、甚至有点“强硬”地约束 AI：

MarkdownUI 和 MarkdownView 本身没有问题。禁止再修改任何 Markdown 相关代码。从其他方向重新排查。

这一次，AI 才真正开始切换视角，把注意力转向：

1. MarkdownView 的修饰符
2. 父视图的布局容器
3. 父级容器滚动视图配置

最终，问题定位到了这一段代码：

LazyVStack(alignment: .leading, spacing: 16) {
    // ...
}
.padding()
.drawingGroup()  // ← 问题根源
.transaction { transaction in
    transaction.animation = nil
}

当我移除 .drawingGroup() 后：表格分割线恢复显示，代码块内容也一并正常了！

为什么 .drawingGroup() 会导致问题？.drawingGroup() 将视图内容合成到离屏渲染层，用于性能优化。但这个过程可能影响细线渲染：

1. 合成精度：细线（1px）在合成时可能被抗锯齿或采样影响
2. 渲染上下文：离屏渲染与直接渲染的上下文不同
3. 颜色混合：合成过程中的颜色混合可能使浅色边框变淡或消失

关于 AI 结对编程的思考

AI 在结对编程中并不是“不会解决问题”，而是很容易在错误前提下持续消耗时间。

AI 高度依赖模式匹配。一旦问题被归类为“表格渲染异常”，它就会自然地把注意力集中在样式、颜色、主题等常见因素上，而对“之前一直正常、最近才出问题”这类时间线线索不够敏感。当初始假设没有被及时推翻时，AI 往往会在同一方向上不断微调，形成事实上的思维死循环。

要让 AI 跳出这种状态，关键并不是提供更多细节，而是强制改变它的分析边界。明确指出当前方向可能是错的、强调哪些部分已经被确认没有问题，甚至直接禁止继续修改某类代码，反而能显著提升排查效率。一旦分析范围被重新划定，AI 才会开始关注父视图、修饰符链或最近的改动这些更有价值的线索。

这也决定了 AI 结对编程的合理分工方式。人类负责判断方向、提供上下文和时间线；AI 负责搜索、枚举和验证可能性。当人类不主动介入纠偏时，AI 很容易在“看似合理”的路径上反复打磨，却始终无法触及根因。

最终，这次问题能够被定位到 .drawingGroup() ，并不是因为 AI 突然变得更聪明，而是因为分析视角发生了改变。这也提醒我，在与 AI 协作调试时，比“如何写代码”更重要的，是如何约束和引导它的思考方式。有时候，问题不在你盯着的地方，而在你忽略的地方。