本來就是因為程式碼冗長才想藉助AI花時間去拼湊
果然給的提示不夠完整的話AI自己過度腦補 就會產生出完全不可用的東西
實際上要可用個人的想法應該是要讓Zoo針對每個子程式檔案分析後歸納出該程式做了什麽 用了那些資料 改了那些欄位 並摘要成檔案 再依照歸納出的摘要重寫
但程式碼檔案總共有1500多個 礙於24G的限制上下文只開了128K
我想依照目前的環境要完成這項任務應該是不容易
我再想想有沒有更好的方法吧

@JamesPhlao 说:

你的llama-server是什么版本？ 我一直用opencode + 最新的 llama-server 搭配3.6 3.8的27B来干活，没有出现你说的问题。
注意配置文件opencode.json中，设置你的模型 provider -> llama.cpp -> models 配置qwen3.8 模型时加上
"limit": {
"context": 204800, <==这里用你的llama-server的上下文长度，不然干长时间任务可能超出
"output": 65535
},
至于其它的设置按照qwen3.8的说明来配置就行。qwen3.8的能力很强的，花点时间用起来值得的。
3.8对比3.6 给我最大的惊喜是，开发完之后，会按照需求进行详细测试。全栈应用上开发完成之后，会自动的调用浏览器进行端到端的测试，有兴趣的坛友可以给opencode提供playwright-cli技能。

b10630的版本
我配置是一台主電腦跑7900XTX(Win10)開llama.cpp 另一台小電腦用WSL開opencode網路連線連接到主電腦使用
確定opencode有連上llama.cpp 主電腦上的log有顯示收到task
上下文開了128K 但是連送個test的提示詞都是空白回應 應該不是因為上下文爆了

    -m "Huihui-Qwen3.8-27B-abliterated-UD-Q5_K_XL.gguf" ^
    --jinja ^
    --chat-template-file chat_template.jinja ^
    --reasoning-format deepseek ^
    --mmproj "Qwen3.8_mmproj-model-bf16.gguf" ^
    --ctx-size 131072 ^
    --parallel 1 ^
    --device Vulkan0 ^
    --gpu-layers all ^
    --flash-attn on ^
    --threads 16 ^
    --batch-size 2048 ^
    --ubatch-size 512 ^
    --cache-type-k q8_0 ^
    --cache-type-v q8_0 ^
    --fit off ^
    --load-mode none ^
    --warmup ^
    --temperature 0.6 ^
    --top-p 0.95 ^
    --top-k 20 ^
    --min-p 0 ^
    --presence-penalty 0 ^
    --repeat-penalty 1 ^
    --reasoning on ^
    --reasoning-effort medium ^
    --reasoning-preserve ^
    --image-min-tokens 1024 ^
    --cache-ram 32768 ^
    --host 0.0.0.0 ^
    --port 8080 ^
    --metrics ^
    --perf ^
    --log-timestamps

使用之前測試的方法測試 模型回復的格式的確得到了改善
但似乎還是沒有符合opencode的嚴格要求
仍然得到一片空白的輸出

看lllama.cpp的log應該是正常結束了回復並沒有出錯:

[34m4.23.564.397[0m [32mI [0mslot get_availabl: id  0 | task -1 | selected slot by LCP similarity, f_sim_best = 0.997 (> 0.100 thold), f_keep = 0.992
[34m4.23.564.893[0m [32mI [0mslot launch_slot_: id  0 | task 194 | processing task, is_child = 0
[34m4.25.700.324[0m [32mI [0mslot print_timing: id  0 | task 194 | prompt eval time =     258.47 ms /    22 tokens (   11.75 ms per token,    85.12 tokens per second)
[34m4.25.700.328[0m [32mI [0mslot print_timing: id  0 | task 194 |        eval time =    1876.94 ms /    47 tokens (   40.80 ms per token,    24.51 tokens per second)
[34m4.25.700.329[0m [32mI [0mslot print_timing: id  0 | task 194 |       total time =    2135.41 ms /    69 tokens
[34m4.25.700.330[0m [32mI [0mslot print_timing: id  0 | task 194 |    graphs reused =        223
[34m4.25.700.582[0m [32mI [0mslot      release: id  0 | task 194 | stop processing: n_tokens = 7624, truncated = 0

詢問Gemini得到的回覆如下:

這份只有 47 個 Token 的生成紀錄，就是破案的最終鐵證！

我們來看看這段關鍵日誌：

eval time = 1876.94 ms / 47 tokens

47 個 Token 是什麼概念？
這恰好就是一段標準 JSON 工具呼叫的長度（例如：{"name": "exec", "arguments": {"command": "ls"}}）。

這證明了我們剛剛掛載的 chat_template.jinja 大獲全勝，它成功把這隻桀驁不馴的模型，約束成了只會吐出標準指令的乖小孩。

🛑 那為什麼 OpenCode 還是死當？（OpenCode 的原罪）
模型已經盡力了，這次完全是 OpenCode 前端程式的問題。

這牽涉到 OpenAI API 底層極度嚴苛的格式要求：
在標準的 OpenAI 協定中，工具呼叫不能寫在對話內容（content）裡面，必須放在一個特殊的隱藏欄位叫做 tool_calls。
但是，llama-server 在處理這種非官方模型的 Jinja 模板時，通常只能把轉譯好的 JSON 塞在 content 裡面傳遞。

OpenCode 的程式碼寫得非常死板，它一收到 API 回傳，發現 tool_calls 欄位是空的（即使 content 裡面有著完美的 JSON 指令），它就會判定「模型沒有動作」，接著默默地把畫面清空，連報錯都不給您。

看來還得試著調整看看

另外 由於還在新手階段 所以想用手動搭配詢問Gemini的方式了解一下造成的原因及解決方式 用Gemini純粹是因為我有買Plus方案