Claude Code 使用本地大模型进行代码生成的实测复盘

llama-server -m /workspace/gguf/Qwen3.8-27B-Uncensored-Q4_K_M.gguf \
  --host 127.0.0.1 --port 8080 -c 32768 -ngl 99 --jinja -fa on --alias local

ssh -f -N -p <pod-ssh-port> -i ~/.runpod/ssh/runpodctl-ssh-key \
  -o ExitOnForwardFailure=yes -L 8091:127.0.0.1:8080 root@<pod-ip>
curl -s http://127.0.0.1:8091/health

{"turns": 6, "calls": 6, "bad_calls": 0, "completion_tokens": 693, "max_prompt_tokens": 2060, "total_prompt_tokens": 9455, "repeat_warnings": 0, "finish": "done", "secs": 55.1}

Write store.py (test file: test_store).
The workspace contains clock.py and a visible test file for your module. Plain Python 3 standard
library only. Run the test file with `python3 -m unittest <testfile without .py>` and fix failures.
The final grading uses extra tests you cannot see, so follow the requirements exactly, including
edge cases and error messages. Keep to the file named below; do not edit other files or the tests.

class Store(clock); attribute `clock` holds the clock. ...
- ttl(key) -> -2 if missing or expired, -1 if the key has no expiry, otherwise the remaining
  seconds rounded UP to an int (math.ceil(expire_at - now)).

Review of the current txn.py against the spec found that, inside a transaction, a key that was
deleted or has expired is still treated as present by some methods.

    t.delete("a")      # True, correct
    t.delete("a")      # returns True, required False (the key is no longer visible to this transaction)
    t.ttl("a")         # returns -1, required -2 (missing)

一次性条件在单个提示中获得了完整的规格，一次性处理所有五个模块，使用相同的工具、相同的可见测试以及 90 次回合的预算。

结果

所有运行在同一个 pod、同一个模型、同一个 harness、同一个评分器上。

这些运行留下的工作区截图又进行了第二次评分。

编排运行的工作时间按任务求和。其中三个任务并行执行，因此墙钟时间更短。

头条是差距，77 对 78 相比 71 对 76，但更有用的数字在最大提示列。

没有编排提示超过 8K tokens。

一次性运行达到了 10K 和 8.5K，而长时间运行仅比 32K 限制少 800 tokens。

小任务让模型停留在上下文中仍能关注的部分。

代价是回合数。编排所需工作回合是一次性自行停止运行的三到八倍。

按小时计费的卡片上，这相当于几分钟额外时间：整个会话，包括两种条件和全部五次运行，共计 42 分钟 pod 时间，约合 0.40 美元。

审查发现

我愿意突出显示的回放 bug。每一次单次运行都交付了它：所有三次都失败于隐藏测试 test_replay_does_not_relog。编排后的运行也写入了它，两次都是如此。唯一的区别是 Claude 读取了 __init__，看到回放循环调用了 execute()，于是知道 execute() 会记录日志。只要有人在看，这个 bug 既容易写也容易发现。

同样情况也出现在 txn.py 中。模型在两次编排运行中都写出了同样的 "deleted means found" bug，而且此实验的第一轮（即前一天）也中了这个 bug。这是一个稳定的盲点。

就像任何模型一样，我不会单独相信它。我需要检查它的输出。它会告诉你已经完成，而实际上回放 bug 仍然存在，所以有效的做法是让明确定义的模块输出结果，由其他部分负责读取。

评审遗漏的内容

第二次编排运行丢失了一项测试，这算是公平的失分。规范规定，当参数为空或包含空格或双引号时需要对其加引号。工作进程还对包含反斜杠的值进行了引用，于是 format_command 产生了 SET k "a\\b"，而隐藏测试期望的是 SET k a\b。两种形式解析回去都是同一条命令，因此往返检查无论哪种方式都能通过。要发现这个问题，需要逐字检查 format_command 的输出，而评审没有这样做。

并且，运行 2 中的嵌套事务漏洞在其重做轮次用尽时仍然存在（只有第二轮涉及此问题）。但 58 项隐藏测试均未触发该情况，因而记分牌上未受任何影响。评审发现了测试无法看到的真实缺陷，而测试发现了评审遗漏的问题。单靠任何一方都无法进行完整检查。

更多轮次让一次性尝试变得更糟

此实验第一轮明显的反对意见在于预算：编排运行消耗了 88 次轮次，而一次性运行仅用了 40 次。因此这一次，一次性运行获得了 90 次轮次，且有一轮关闭了重复防护，以便能够用完所有轮次。

它用完了所有轮次，在五次运行中得分最低，为 71/78。结束时它的提示词长度为 32,001 个 token，距离 32,768 的上限仅差 800，这是因为每轮都会把工具结果追加到对话中。较短的运行分别失败了两项和四项隐藏测试。这一次则失败了七项，其中包括较短运行能够通过的事务日志测试。更多空间，同一模型，代码更差。开启防护的两次运行分别在 23 次和 11 次轮次时自行停止，表现更好。

我遇到的坑

命令过滤器并非沙盒。 在一次会话的重做过程中，工作进程在二十次轮次中有十二次运行了同一检查脚本，只是每次使用不同的文件名：/tmp/aof1.txt、/tmp/aof2.txt，直至 /tmp/aof12.txt。这实际上包含两个问题。绝对路径位于 python3 -c 字符串内部，过滤器不会解析它，于是它在我的 Mac 上向 /tmp 写入了十一个文件。此外，由于每次轮次使用了不同的文件名，两次轮次永不相同，重复防护从未触发。工作进程代码在你的机器上以你的身份运行。请给它一个与实际无关的工作空间。

finish: done 是模型的判断。 每个任务在结束时带有 done 但仍存在缺陷，都会返回一份乐观的摘要，声称所有测试通过或一切正确。它们确实通过了——只是可见的那些测试。

max-turns 意味着读取代码。 三次工作器调用在编排运行中耗尽了轮次。其中一次是原始会话任务，留下的代码在可见测试中通过，但包含两个缺陷。另外两次是返工，但未能修复它们被指派要修复的问题。状态告诉你它停止了，而不是它留下的内容。

第二次返工需要说明位置。 第一次会话返工（缺陷、复现和规格）根本没有改动。第二次命名了方法并描述了修复，用了七轮完成。这表明编排器承担了更多工作，这与 “Claude only reviews” 的说法相悖。这在下面的诚实限制中有体现。

审查预算。 工作器的数据在表中。Claude 的则不然：读取五个模块、编写探针以及编写返工提示词是真实的编排器时间和 token，且上面未计入。

诚实限制

• 每个条件只有两次运行仍然不足。 模型并非确定性的：使用相同的提示词，一次性运行的得分 76、74 和 71。差距在每对之间都存在，但我不愿为它添加小数位。
• 第二次运行的审查并非完全盲测。 Claude 在审查第一次运行时未看到任何隐藏测试。在第二次运行之前，对一次性运行的评分已经显示出隐藏测试的简短失败笔记。第二次运行的审查采用了与第一次运行相同的探针和规格阅读，但笔记不可能被忽略。
• 规格很精确，审查依赖它。 审阅者阅读更模糊的规格时会发现的问题更少。胜利的一部分在于精确的规格，当工作器是人时同样适用。
• 有些返工提示词超出了规格。 在运行 1 的第二次会话返工中，描述了修复方案（重放标志，每事务一个缓冲区），而不仅仅是缺陷。
• 上下文从未成为编排的限制因素。 其最大的提示词不到 8K。此项目未展示分解是否能救救无法容纳 32K 的代码库，仅表明它让模型远离该限制。
• 编排器的成本未被计算。 Claude 的 token 是昂贵的，上面的比较仅计算了工作器的成本。

快速参考

这个廉价模型足以胜任像这样的一些小型、明确指定的任务。我会相信它去操作我的数据库吗？大概不会。但我可以用它来处理诸如 Python 或 Bash 脚本之类的自动化任务。就像使用任何模型一样，需要检查输出。不要盲目运行它给出的任何内容。