代码库越来越大 - Qwen3.6-27B 开始引发复合问题 - 如何巧妙地使用这个模型？

我最初手工编写了一个小型聊天机器人，用于与 llama 服务器交互并支持工具使用。但后来我开始使用 Qwen3.6-27B 进行 vibe coding，结果大为惊艳。显然，从那以后我添加了大量功能，代码库的规模也急剧膨胀。但现在我注意到代码中存在大量微小 bug，不得不手动审查和修复。这些 bug 在我看来对初级开发者来说应该是显而易见的。幸好我用的是 Python，而我在 Python 方面有多年的专业经验。但这让我思考，也许我使用模型的方式不对。或许有更好的方法来使用这个模型。我目前的做法是： 1. 启动 pi 2. 提示词 - “读取当前项目”。这会消耗当前可用上下文（共 128K）的大约 50% 3. 实现此功能或修复此 bug 4. 上下文达到 80% 或以上时，执行 /compact 但在看到所有这些 bug 后，我正在逐行追踪代码试图逐个修补。我现在每次修改都使用新的对话，并且不再要求它读取整个工作区，而是让它专注于特定的函数甚至具体的行，例如：第 670-650 行。然后让它读取并确认特定的 bug，并完全按照我的意图进行修复。我还移除了所有 KV 量化，希望以此减少 bug。我现在使用的命令如下（我的配置是 5090 搭配 64GB 内存）： /home/lenny/myp/llama.cpp/build/bin/llama-server \ -m ~/myp/models/unsloth_mtp_Qwen3.6-27B-UD-Q5_K_XL.gguf \ --temp 1.0 --top_p 0.95 --top_k 64 \ -c 131072 -t 16 -ngl 99 --flash-attn on \ --host 0.0.0.0 --port 8080 \ --spec-type draft-mtp --spec-draft-n-max 4 --parallel 1 显然，现在构建和调试功能花费的时间要多得多。 **我的问题是——有没有其他方法可以减少使用这个模型时产生的 bug？** 附注：示例 bug：有一个功能可以安排在特定时间或按重复周期执行任务。它接受 execution_time 作为参数。我发现的 bug 如下： try: parse time in UTC. except: logging.error("failed to parse") Insert into DB 而正确的应该是： try: parse time in UTC. except: logging.error("failed to parse") return "Tool call failed - incorrect time format" Insert into DB 现在我拥有数千行代码，其中随时可能出现类似的问题。