Stephan_

現在最划算的訂閱不是opencode-go
也不是 commandcode-goat
是 ChatGPT-plus 😂

最近一直在思考一個問題：面向前沿模型編寫 skill，確定性和靈活性的平衡如何把握？
確定性指的是用更多硬約束或程式碼來編寫 skill
靈活性指的是更少的細節和約束，只從 high-level 和 prompt-driven 的角度來編寫 skill
這兩者之間需要一個動態平衡，不是唯一答案
起因是在比較 matt 寫的 /spec-implement 和我寫的 /pi-matt-implement-flow
我的流程和框架限定很多，好處是確定性強，agent 不容易跑偏。壞處也是確定性強，agent 自我發揮的空間不足😂
以前的模型還不夠聰明，所以我會更偏確定性強的方向
現在 Opus-5.5/GPT-6.1-sol 這個級別的模型就不一樣了，確定性太強似乎反而會限制他的發揮
你怎麼看？

最近的思考🤔：
研發更多的時間應該放在制定 eval 評估資料集和評估準確性及完備性上，然後透過建構 eval loop 驅動業務迭代
而不是直接 vibe coding 業務程式碼
理想情況下，透過合理的 goal + eval loop，業務程式碼應該可以自我迭代才對
正在嘗試做這方面的轉變，歡迎交流。

為什麼很多AI測評跑分和自己的體感不太一樣？
我覺得關鍵是大部分測評都是發令槍一響，看誰跑得遠
至於跑到哪裡去不管，跑到天上去都行，整個測評過程不需要收斂
真實場景下，最磨人的是收斂和對齊的過程，跑得遠的不一定就好，能在跑道裡一直跑的才好。

用慣了 Deepseek-v4-flash，實在受不了 GLM-5.3-flash 😂
關鍵 GLM 它慢就慢吧，還動不動報錯，穩定性不太行
這樣的話完全可以用更強的模型做規劃+deepseek-v4-flash 做執行來替代呀。

思考一個問題：有沒有一套框架，能把一個完整的 SaaS 服務範本 + AI harness + 自訂 skill 做成一個可插拔框架？
DeepSeek Harness 可能成為這樣的基礎設施嗎？有沒有其他已成形的專案？

Matt Pocock 提到的 smart zone 是上下文長度約 12 萬，我用 grok-4.6 的體感也差不多，接近 20 萬左右時會出現明顯變笨的情況。不知道大家的體感如何？其他模型是否也有明顯的 smart zone？

grok build 是我用過體驗最好的 TUI，現在搭配 grok-4.6 可以說是性價比之王了。主要是 grok 的速度比很多一線模型都快，品質能站到第一梯隊的話競爭力就太強了（而且隨便儲值也不封號）！

看完了老羅採訪周鴻禕的三個半小時的播客，能聽出來老周是確實有很多切實的行業經驗的，可惜老羅問的問題不夠深入和專業，有點遺憾
比如老羅說到海外頂尖模型是這個觀點，我覺得是有些偏頗了。因爲不同領域有不同的最佳模型，比如在編程領域目前claude-4和gpt-5-codex可能都優於；又比如老周不止一次提到的LLM幻覺問題，在360是如何優化的？並沒有追問下去
聽完整體感覺最有價值的點就是老周說到的垂直+訂閱的收費模式，老周還提到收費模式上應該是token按量計費+membership會員費的方式，這種方式確實是一種長期看更可行的收費模式。單純賣token的模式壁壘太低，用戶付費的動機應該是在LLM之上，產品提供的垂直Agent的能力

OpenAI 发布了一篇 "GPT-5 编码指南", 给出了6条使用GPT-5进行AI编程的最佳实践：
# 1. 指令应精确，避免信息冲突
新款GPT-5模型在遵循指令方面的能力有了显著提升，但这也带来一个副作用：当面对模糊或相互冲突的指令时，它可能会难以处理。这种情况在你的 .cursor/rules 或 配置文件中尤其需要注意
# 2. 设定合适的推理级别
GPT-5 在解决问题时总会进行一定程度的推理。若想获得最佳效果，处理复杂任务时应使用 "high reasoning effort" 。如果你发现模型对简单问题有“想太多”的倾向，可以给出更具体的指令，或选择 medium 或 low 的推理级别
# 3. 使用类似XML的语法来帮助结构化指令
我们与Cursor合作发现，使用类似XML的语法可以为模型提供更多上下文，从而使GPT-5更好地工作。例如，你可以给模型以下编码指南：


- 每个组件都应该是模块化和可重用的


- 样式：TailwindCSS


# 4. 避免使用