抡锤者

TomAThub

用VS Code搭配Zoo code(Woo code社群維護版)分功能大項分析以後重寫
導入資料庫格式讓Zoo 照著修正
產生出來的成品...零可用性
對這個結果也不意外就是

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

TomAThub

@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的提示詞都是空白回應應該不是因為上下文爆了

TomAThub

目前採用的Gemini的建議改用了VS Code+Zoo Code插件已成功運行並初步分析了系統
可見本地模型端的運作是沒有問題的問題還是出在了opencode能接受的語法格式問題

TomAThub

感謝以上的回覆
我有試著套入了https://huggingface.co/froggeric/Qwen-Fixed-Chat-Templates的修正
把啟動參數修改成了:

    -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方案

TomAThub

最近跟風買了塊7900XTX
之前有試著抄作業在Win10上用llama.cpp跑了Qwen3.6 27b的Q4量化版本
這幾天Qwen3.8發布了想著要在本地跑一套Qwen3.8-27B-abliterated-UD-Q5_K_XL+opencode來幫我分析一套用Foxpro寫的古老系統源碼
卻在環境架設好以後就碰了灰(執行參數抄了AGI大佬的作業https://lcz.me/post/13658)
在opencode下了指令以後 llama.cpp有收到要求並執行
但執行完畢後opencode並沒有任何輸出
用Gemini反覆測試了以後得到的結論是:
opencode不接受Qwen3.8給出的回覆格式
節錄關鍵部分如下:

導致崩潰的回覆內容 (content)：
問題出在這裡。模型生成了一段 XML 格式的工具呼叫指令：

XML


<function=multi_tool>
<parameter=tools>
[{"type": "function", "function": {"name": "exec", "arguments": {"command": "find ..."}}}]
</parameter>
</function>
為什麼 OpenCode 會當機空白？
OpenCode 是嚴格基於 OpenAI 官方標準打造的代理軟體。它預期收到的工具呼叫（Tool Call）必須是隱藏在 API 參數中的純 JSON 陣列，而不是像這樣直接把 XML 標籤寫在對話內容（content）裡面。
因為這是一顆「解除審查（abliterated）與特化微調（UD）」的非官方模型，它的底層被訓練成習慣使用這種自訂的 XML 標籤來呼叫工具。當 OpenCode 收到這串 XML 時，它的解析器直接卡死，不知道該不該把這段文字顯示在畫面上，於是就變成了「無言結局」。

想問這個問題有方法可解嗎?

抡锤者

TomAThub

帖子