您花费数小时编写代码，进行假设，调整条件，但错误仍然重现。听起来很熟悉吗？这种沮丧的状态通常被称为“幽灵狩猎”。该程序似乎过着自己的生活，忽略您的更正。
造成这种情况的最常见且最烦人的原因之一是在应用程序中完全错误的位置寻找错误。
“虚假症状”的陷阱
当我们看到错误时，我们的注意力就会被吸引到它“出问题”的地方。但在复杂的系统中，发生错误（崩溃或不正确的值）只是一长串事件的结束。当你试图修复结局时，你是在对抗症状，而不是疾病。
这就是流程图概念的用武之地。
它在现实中是如何运作的
当然，没必要每次都直接在纸上画（画）出流程图，但将其放在脑子里或手边作为架构指南很重要。流程图允许您将应用程序的操作可视化为结果树。
在不理解这个结构的情况下，开发者常常是在黑暗中摸索。想象一下这种情况：您在一个条件分支中编辑逻辑，而应用程序（由于一组特定参数）转到您甚至没有想到的完全不同的分支。
<块引用>
结果：您花费数小时对算法的一个部分进行“完美”代码修复，当然，这对解决算法实际失败的另一部分的问题没有任何作用。
<小时/>
击败错误的算法
要停止敲打紧闭的门，您需要改变诊断方法：
- 在结果树中查找状态：在编写代码之前，您需要准确确定应用程序所采取的路径。逻辑在什么时候出现了错误？哪个具体状态（状态）导致了该问题？
- 复制成功率为 80%：这通常由测试人员和自动化测试完成。如果bug是“浮动”的，则开发参与过程中共同寻找条件。
- 使用尽可能多的信息：日志、操作系统版本、设备参数、连接类型（Wi-Fi/5G）甚至特定的电信运营商对于本地化都很重要。
错误时刻的“照片”
理想情况下，要修复它，您需要在重现错误时获取应用程序的完整状态。交互日志也非常重要：它们不仅显示最终点，还显示整个用户路径（失败之前执行了哪些操作）。这有助于理解如何再次重新创建类似的状态。
未来提示：如果您遇到复杂的情况，请在这部分代码中添加扩展的调试日志记录信息，以防这种情况再次发生。
<小时/>
人工智能时代“难以捉摸”的状态问题
在使用LLM（大型语言模型）的现代系统中，经典决定论（“一个输入，一个输出”）经常被违反。您可以传递完全相同的输入数据，但会得到不同的结果。
发生这种情况是由于现代生产系统的非决定论：
- GPU 并行性：GPU 浮点运算并不总是关联的。由于线程并行执行，数字相加的顺序可能会略有变化，这可能会影响结果。
- GPU 温度和限制：执行速度和负载分布可能取决于硬件的物理状态。在巨大的模型中，这些微观差异会累积，并可能导致在输出时选择不同的标记。
- 动态批处理：在云端，您的请求会与其他请求合并。不同的批量大小会改变内核中的计算数学。
在这样的条件下，再现“同样的状态”几乎是不可能的。只有统计测试方法才能拯救您。
<小时/>
当逻辑失败时：内存问题
如果您使用“不安全”语言（C 或 C++），该错误可能会因内存损坏而发生。
这些是最严重的情况：一个模块中的错误可能会“覆盖”另一个模块中的数据。这会导致完全无法解释的孤立故障，无法使用正常的应用程序逻辑进行追踪。
如何在架构层面保护自己？
为了避免这种“神秘”的错误，您应该使用现代方法：
- 多线程编程模式：清晰的同步消除了竞争条件。
- 线程安全语言：编译时保证内存安全的工具：
- Rust：所有权系统消除了内存错误。
- Swift 6 并发：强大的数据隔离检查。
- Erlang：通过参与者模型完成进程隔离。
摘要
修复错误并不是要编写新代码，而是要了解旧代码是如何工作的。请记住：您可能会浪费时间编辑管理层根本不接触的分支。记录系统状态，考虑AI非确定性因素，选择安全工具。
Leave a Reply