1. 多进程多线程调试不是“加个断点就完事”，而是上下文主权的争夺战
我第一次在 VSCode 里给一个用multiprocessing.Process启动的子进程打上断点，却眼睁睁看着它一路飞过——主进程停住了，子进程像没看见断点一样继续跑完。那一刻我才意识到：VSCode 默认的调试器根本不知道那个子进程的存在。它不是“没断住”，而是压根没接管。
这不是 VSCode 的缺陷，而是调试模型的根本差异。传统单线程调试，调试器和被调进程是 1:1 的主从关系；而多进程/多线程场景下，你面对的是一个动态生成的、异构的调试拓扑结构。AI 编程工具（比如 Cursor、Trae、Claude Code 插件）介入后，这个结构更复杂了：AI 可能正在后台解析你刚写的asyncio协程栈，也可能正把你的日志点自动转成条件断点，还可能在你切换线程时悄悄重载了局部变量视图——但它不会告诉你它“看到”的上下文和你当前调试器看到的是否一致。
这就是为什么“过度依赖 AI 辅助编程”会直接导致“上下文丢失”：AI 工具基于它自己的代码理解模型构建上下文快照，而 VSCode 调试器基于运行时内存状态构建执行上下文。两者不同步，断点就变成了薛定谔的猫——你不确定它是该停，还是不该停，还是停错了地方。
本文不讲“如何启用多进程调试”这种文档级操作。我要带你实操验证四套断点协同策略，每一套都对应一种真实工程场景：
- 当你用 Trae 的 Solo 模式重构一个含threading.Thread的旧模块时，怎么让 AI 的提示词建议和你手动设置的线程断点不打架；<
