问题背景
在一次开发过程中,遇到了一个典型但又颇具迷惑性的渲染问题: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 协作调试时,比"如何写代码"更重要的,是如何约束和引导它的思考方式。有时候,问题不在你盯着的地方,而在你忽略的地方。