收益：
- 通过向人工智能提供相关代码和场景上下文的崩溃记录（堆栈跟踪），能够快速缩小可能的根本原因范围
- 能够永久解决根本原因，而不是将人工智能的诊断验证为代码中的假设并测试和消除症状
- 通过屏蔽崩溃记录和日志中的个人数据来保护调试时的隐私
Every application gives errors;优秀开发人员的区别在于他们发现并修复错误的速度。移动调试（查找并修复问题根源）特别困难，因为错误发生在用户的设备上，且处于您看不到的环境中。大多数时候，您拥有的只是崩溃日志（崩溃日志/堆栈跟踪 - 应用程序崩溃时去向的技术故障）。人工智能在读取这些神秘记录、列出可能的原因并提出解决方案方面非常强大。在本单元中，我们将学习如何使用人工智能作为“错误侦探”，但让您负责验证最终诊断和修复。
Reading the crash log: Where AI shines brightest
A crash log is a long and intimidating text;缺乏经验的开发人员不知道该去哪里寻找。 AI 在几秒钟内解析这段文本：在哪一行崩溃，抛出了哪个异常，可能的原因是什么。常见的移动错误很明显，AI 很快就能识别它们：Android 上的 NullPointerException（试图访问 null 值）、IndexOutOfBoundsException（访问不存在的列表元素）、iOS 上的 EXC_BAD_ACCESS（访问已释放的内存）、意外发现 nil（强制使用 nil 可选）。
最常见的手机崩溃类型及其典型原因如下：
Error (exception)
平台
typical cause
NullPointerException
Android
Accessing a null value
IndexOutOfBoundsException
Android
Accessing non-existent list element
unexpectedly found nil
iOS系统
Force unwrapping a nil optional (!)
EXC_BAD_ACCESS
iOS系统
Accessing freed memory
ANR/freeze
Android
Long/heavy processing on main thread
Step by step debugging flow:
- 收集记录。将崩溃日志、错误消息以及可能的重现步骤放在一起。
- Give the AI context.不仅告诉我错误，还告诉我相关的代码片段以及它崩溃的原因。
- 询问可能的原因。 “告诉我 3 个最可能的原因以及如何验证每个原因。”
- 核实。 Confirm the proposed reason in code and testing; Don't fix it by guessing.
- 修复它并再次测试。检查错误是否确实消失并且没有生成新的错误。
提示：将崩溃日志提供给 AI 时，也请包含相关的代码片段。只有通过堆栈跟踪，AI 才能做出一般预测；当您看到代码时，找到确切行和真正原因的概率会大大增加。 Context determines the quality of diagnosis.
个人数据陷阱
崩溃日志和日志通常包含用户数据：电子邮件、用户 ID、位置，甚至表单内容。将此记录按原样粘贴到 AI 中相当于将个人数据泄露给第三方，并且违反了 KVKK / GDPR。在提交录音之前清除（遮盖）个人区域。另外，请注意不要从一开始就将个人数据写入应用程序的日志中；好的日志描述了问题，但没有揭示问题的本质。
注意：人工智能建议的修复可能会“消除错误”，但可能无法解决根本原因。例如，用 null 检查包装 NullPointerException 将阻止崩溃，但如果您不弄清楚该值为何为 null，则实际的逻辑错误将继续。 Treat the disease, not the symptom.
根本原因分析
专业调试的目的不是消除错误，而是找到根本原因。我问人工智能“为什么它可能是空的，它可能在数据流中丢失了？” asking, “how do I silence this?” It is much more valuable than asking.一旦找到根本原因，同一错误的数十种变体就会立即得到解决。人工智能擅长这种连锁推理：跟踪数据从输入到输出的过程，并要求它思考它在哪里发生故障。
三个迷你箱子
Case 1 — 2 hours of work in 10 minutes.一名开发人员花了 2 个小时寻找一个仅在特定三星型号上崩溃的错误。将崩溃日志（清理个人区域）交给AI； YZ 表示，该错误指出该设备的不同相机分辨率会发生内存溢出。有了线索，10分钟就找到了原因。人工智能加速搜索，人类验证解决方案。
Case 2 — The silenced bug is back.一个团队通过使用人工智能建议来尝试捕捉事故，从而平息了一次反复发生的事故。崩溃停止了，但用户开始抱怨“数据没有保存”；因为真正的问题（数据库连接）仍然存在，只是变得不可见。一旦找到根本原因，崩溃和数据丢失都得到解决。 Lesson: silencing is not solving.
案例 3 — 日志中的数据泄露。审计发现用户的全名和电话号码被写入应用程序的崩溃日志中。开发人员定期将这些日志粘贴到 AI 中并修复错误； So personal data has been going out for months. Logs were masked and the process was corrected.教训：即使在调试时，机密性也适用。
弱提示/强提示
错误提示：“为什么会发生此错误？[堆栈跟踪]”
强烈提示：“此崩溃发生在我的 Android 应用程序中。上下文：- 执行时：用户从产品详细信息添加到购物车 - 仅在某些设备、低 RAM 型号上 - 相关代码：[ViewModel 和存储库部分]- 崩溃日志（已清除个人数据）：[堆栈跟踪]列出 3 个最可能的根本原因。对于每个：1) 我如何验证，2) 永久修复（不是沉默）。在不确定的地方说明你的假设。”
可复制模板
崩溃分析模板：“分析以下崩溃。上下文：[您正在做什么，哪个设备/版本]。相关代码：[代码]。崩溃日志（已清除的个人数据）：[跟踪]。给出 3 个最可能的根本原因，并针对每个原因进行验证和永久修复。同时标记消除症状的解决方法。”
根本原因模板：“此值意外出现 [null/false]。跟踪从输入到此点的数据流：它可能在哪里丢失或损坏？告诉我在每个阶段应该检查哪里。[代码]”
日志阅读模板：“解读此日志输出：按顺序发生了什么事件，异常在哪里，错误发生前最后一个健康的步骤是什么？[日志-个人数据已清除]”
重现模板：“我应该尝试哪些步骤、设备状态和数据来可靠地重现此错误？按概率顺序列出可能触发错误的条件。[描述]”
常见错误
- 提供上下文无关的堆栈跟踪。在没有相关代码和场景的情况下，AI 只能做出笼统的预测。
- 将个人数据与日志一起粘贴到人工智能中。违反保密规定；先戴口罩。
- Silence the symptom.使用 try-catch 隐藏崩溃会留下根本问题并产生新问题。
- 应用第一个建议而不验证它。 AI的诊断是一个假设； Confirm in code.
- 尝试在模拟器中重现它。有些错误仅出现在实际设备/条件下。
- 修正后不重新测试。修复可能会破坏其他东西； Check regression.
总之
人工智能擅长的领域之一是读取崩溃日志并找出可能的原因；当给出上下文时，诊断质量会大大提高。但最终的诊断和纠正属于人类：人工智能的建议只是一个假设，在代码和测试中得到验证。目的不是消除症状，而是解决根本原因；沉默的错误通常以另一种形式返回。崩溃日志可能包含个人数据；在将其交给人工智能之前将其屏蔽，并且不要从一开始就在日志中写入个人数据。
应用任务
获取您拥有的崩溃日志（或从人工智能生成的样本），屏蔽其中的任何个人/独特数据，然后使用“崩溃分析模板”将其提供给人工智能。区分 AI 列表中哪些根本原因是实际修复，哪些只是沉默。应用您选择的永久修复并验证错误是否已消失且不会出现新问题。
清单
- [ ] 我已经给出了崩溃日志以及相关代码和场景上下文
- [ ] 我在日志中屏蔽了个人/独特数据
- [ ] 我向人工智能询问根本原因和永久修复，而不是沉默
- [ ] 我在代码和测试中验证了诊断，我没有盲目应用它
- [ ] 修复后测试错误消失，没有回归
- [ ] 我检查了我的应用程序未在其日志中写入个人数据