问题背景
在一次开发过程中，遇到了一个典型但又颇具迷惑性的渲染问题：Markdown 表格的行分割线在 Xcode 预览中正常显示，但在运行时完全消失。
代码块中的代码内容在 Xcode 预览中正常显示，但在运行时完全消失。
这类问题通常与运行环境差异、渲染上下文或视图修饰符有关。接下来，我记录了自己与 AI 结对编程、一步步定位并解决问题的过程。
问题分析过程
我并没有一开始就把两个现象同时抛给 AI。原因很简单，第二个问题（代码块消失）涉及的代码更复杂，极容易把 AI 带进错误方向。
直觉告诉我，这两个现象很可能是同一个根因的不同表现。因此，我选择先挑一个"看起来更简单"的现象：表格分割线消失，作为切入点，让 AI 先集中精力解决一个问题。
第一阶段：错误的假设
AI 的第一反应非常"教科书式"，它将注意力放在了表格样式配置上：
swift
// 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)
}它提出了几个假设：
- 颜色
.grid在运行时未正确解析 - MarkdownUI 的边框样式在运行时未正确应用
- 环境变量（colorScheme）未正确传递
这些假设看起来合理，但都隐含着一个前提：问题一定出在 Markdown 样式本身。
第二阶段：调试验证
为了验证这些假设，我按 AI 的建议加入了一些调试代码：
swift
// 打印 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 才真正开始切换视角，把注意力转向：
MarkdownView的修饰符- 父视图的布局容器
- 父级容器滚动视图配置
最终，问题定位到了这一段代码：
swift
LazyVStack(alignment: .leading, spacing: 16) {
// ...
}
.padding()
.drawingGroup() // ← 问题根源
.transaction { transaction in
transaction.animation = nil
}当我移除 .drawingGroup() 后：表格分割线恢复显示，代码块内容也一并正常了！
为什么 .drawingGroup() 会导致问题？.drawingGroup() 将视图内容合成到离屏渲染层，用于性能优化。但这个过程可能影响细线渲染：
- 合成精度：细线（1px）在合成时可能被抗锯齿或采样影响
- 渲染上下文：离屏渲染与直接渲染的上下文不同
- 颜色混合：合成过程中的颜色混合可能使浅色边框变淡或消失
关于 AI 结对编程的思考
AI 在结对编程中并不是"不会解决问题"，而是很容易在错误前提下持续消耗时间。
AI 高度依赖模式匹配。一旦问题被归类为"表格渲染异常"，它就会自然地把注意力集中在样式、颜色、主题等常见因素上，而对"之前一直正常、最近才出问题"这类时间线线索不够敏感。当初始假设没有被及时推翻时，AI 往往会在同一方向上不断微调，形成事实上的思维死循环。
要让 AI 跳出这种状态，关键并不是提供更多细节，而是强制改变它的分析边界。明确指出当前方向可能是错的、强调哪些部分已经被确认没有问题，甚至直接禁止继续修改某类代码，反而能显著提升排查效率。一旦分析范围被重新划定，AI 才会开始关注父视图、修饰符链或最近的改动这些更有价值的线索。
这也决定了 AI 结对编程的合理分工方式。人类负责判断方向、提供上下文和时间线；AI 负责搜索、枚举和验证可能性。当人类不主动介入纠偏时，AI 很容易在"看似合理"的路径上反复打磨，却始终无法触及根因。
最终，这次问题能够被定位到 .drawingGroup() ，并不是因为 AI 突然变得更聪明，而是因为分析视角发生了改变。这也提醒我，在与 AI 协作调试时，比"如何写代码"更重要的，是如何约束和引导它的思考方式。有时候，问题不在你盯着的地方，而在你忽略的地方。