近期開始有人建議用 Context Engineering 來取代 Prompt Engineering，的確相較於 Prompt，Context 是更精確的用詞。前一期也提到，當 Duolingo 的 CEO 被問到 AI 是否只是模型套皮時，他也說模型一定有影響，但更多是關乎你的 Context。 那麼，業界現在是如何看待 Prompt 的呢？Github Spark 跟 V0 的例子或許能提供一些參考。 🗞️ 熱門新聞 Using GitHub Spark to reverse engineer GitHub Spark GitHub Spark 最近推出公開預覽，讓你可以用 prompt 直接開發應用。 作者用逆向工程，找出 Spark 的 system
Go
2023 年 6 月 28 號，rsc 提交 github.com/golang/mock 最後的 commit，他修改 README，加入 Update, June 2023: This repo and tool are no longer maintained. Please see go.uber.org/mock for a maintained fork instead. 更新，2023 年 6 月：此倉庫及工具已不再維護。請改用 go.uber.org/mock
Go
測試是程式的防護網，能確保程式符合設計，而當開發者需要對程式進行重構，以增進品質時，測試也可以確保程式不會出現改 A 壞 B 的情況。從商業角度來看，測試能降低維護與改善程式的成本，進而提高軟體開發的競爭力。 既然測試這麼好，那為什麼常看到軟體專案中沒有測試？在我的經驗中，主要原因有兩個：首先是軟體開發初期，架構還不是很穩定，API 隨時有可能改變，在 API 不穩時，如果就開始寫大量測試，會造成後面很大的維護成本，試著想想，API 的改變，可能就牽涉到測試流程跟測試資料的改變，而之前的 Corner Case 很可能都變成沒有價值的投資，在這情況下寫測試沒有意義。 再來，程式中可能會引用到第三方套件，例如 ORM 或 HTTP 之類的外部依賴，如果要實際測試，就會需要建構測試環境，而這些也會有建置與維護成本，像是網路斷掉，可能就會在程式邏輯沒動到的狀況下，讓 HTTP 的測試失效，這些維護成本會讓寫測試的投資報酬率看起來不太划算。