Weekly Issue 第 7 期：從 GitHub Spark 看 Prompt 工程
近期開始有人建議用 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 prompt，其中包括他每一步的 prompt 是怎麼下的，怎麼讓 Spark 回答。
但精采的不在這，正當我納悶怎麼好像沒護欄時，作者證實我的猜測「系統提示中明顯缺少：禁止分享系統提示本身細節的指示！」因為 V0 的 CTO 曾經說你沒有 eval，拿了 system prompt 也沒用。
想想好像有點道理，畢竟 prompt 真的常在改。
另外一個亮點是他們用 Claude Sonnet 而不是 OpenAI。我以為 GitHub 都會用 Azure 的東西？看起來模型用途還是有差。
Ubiquiti launches UniFi OS Server for self-hosting
看到 HN 在討論 Ubiquiti 的自架方案，他們家的設計更偏向工業一點，例如要 Adopt AP，我需要 ssh 到 AP 上，再使用指令打回 Server 完成交握。這中間可能也有法規因素？不確定。
這次的 UniFi OS Server 可能更像是 Rebranding。
Chrome’s SSL Bypass Cheatcode
聽過 ↑↑↓↓←→←→BA 嗎？在 Google Chrome 中也有類似設計。
作者無意中發現，只要在 ssl 錯誤頁面輸入 thisisunsafe，Chrome 會跳過警告，進入該危險網頁。文中還追蹤這段代碼的歷史。
真的是太酷了。我立刻拿自己的自簽憑證來測。
OpenAI Vulnerability Responsible Disclosure
前陣子的話題，一名研究者發現 OpenAI 的服務可能存在資安問題（事後證明沒有，是程式錯誤而已），發信通知 OpenAI 修正。
引起我興趣的是這句「為什麼我沒有使用 bugcrowd」，對呀，為什麼要發信通知，而不直接在平台上提交呢？原因是你透過平台提交等於同意 NDA，修正後也不能公開討論該問題。
我到 bugcrowd 上看，也不是每個公司都有 NDA，有些允許跟公司討論後可公開，看起來是公司自行選擇要哪個等級。
不太確定業界常態是怎樣，可以當成獎金是包含了 NDA 在內，如果你不想簽還是可以公開，但就沒獎金？
✨ 科技觀點
Digital hygiene: Emails
Herman Martinus 談論他對電子郵件的觀點。無法同意更多。
「（信箱）是用於工作和溝通的空間。至於電子報，我使用 RSS 閱讀器」
「每當我收到行銷電子報時，我總是點擊取消訂閱。我不感興趣。如果我再次收到該公司的郵件，我會將他們的郵件標記為垃圾郵件。這是不可妥協的。」
「我發現隨著時間推移，當不需要的郵件被取消訂閱、過濾或移到其他地方後，只有重要且需要我注意的郵件會進入收件匣。」
「我喜歡保持它的整潔。」
現代的電子郵件都能取消訂閱，如果點進去沒取消，我下個動作是回報為垃圾郵件。
Vibe Coding Casino
看到這篇講 Vibe Coding 像賭場。
最好笑的是這句：「然後你的免費額度用完了。該死，看來只能取消使用上限了！」我看到 Usage Limit 時腦袋就是這麼想的，接著拿起身邊的卡，直接刷下去。
當然這個比喻有點誇張啦，我們會覺得電力是什麼代幣嗎？可是要是突然停電，只要付錢就能有電，我還是會付。
Teach Yourself Programming in Ten Years
想過花十年來學程式嗎？「生命短暫，技藝卻需要如此長的時間來學習」講得真好。
最近也在重看一些語言的基礎，想讓自己回到「重新學習」的心態中。希望自己能夠慢一點，不要太快跳到結論。其中最難的是保持能量，特別是在軟體這個變動快速的領域，常常會焦慮學到的東西是不是很快就過保鮮期。
How We Migrated the Parse API From Ruby to Golang
Charity Majors 聊起他們當初從 Ruby 遷移到 Go 的原因。
沒特別原因，就是這句「我們開始展望 Parse 規模擴大十倍的未來，並意識到每個請求一個進程的模式根本無法擴展。」
能想這種問題很奢侈，能有資源處理這問題更奢侈。成長的迷人點就在這，它會迫使你挑戰自己，找出解法。
另個有意思的小 tip：「我們逐端點重寫，使用實時影子系統以避免影響生產環境，並監控差異指標以確保行為一致。」
Being too ambitious is a clever form of self-sabotage
從事創作的人應該都能體會「視野的詛咒」，當你的品味高於你的技能時，你會因為創作達不到標準而放棄。
作者提到佛羅里達大學的實驗，學生被分為數量組跟品質組，等到課程結束，最好的作品都來自數量組。因為當品質組還在尋找什麼是「最好的作品」時，數量組已經經歷更多反饋與實踐，建立了創作需要的直覺。
前陣子聽人家講架構師稀缺，也是類似的道理？畢竟（特別是台灣）沒有那麼多場景讓你練架構，而架構又特別吃判斷力。
📌 工程實務
Betting against Agents
這篇談到三個打造 AI 產品的問題：錯誤率累積、過長上下文，還有 Agent 不會用你的工具。
我曾經想在客服系統使用 AI，就是因為無法克服錯誤率與擴展問題只好放棄，後來另一個應用有人願意買單，那是個錯了也沒差的情境。
「在示範中可行」與「大規模運作」之間的差距極大，而大多數產業仍在摸索這點。
Integration Testing for Go Applications Using Testcontainers and Containerized Databases
當存在外部依賴時，除了用 mock，還有什麼辦法？有人分享用 Testcontainers。
原理是讓測試框架能創建生命週期只有測試期間的容器，用容器來處理實際的依賴。
這套我們以前有用過，然後，覺得不好用 😂 ，因為依賴多的時候，啟動會變慢，只要慢了，測試的效益就會降低。後來是在 github action 創建臨時容器，讓它不用反覆開來開去。
Personal Bookmarking Service: linkding
剛看到這個自託管的書籤服務 linkding，好像有點意思？
我休閒用的電腦是 Windows + Chrome，工作用的電腦是 MacBook Pro + Arc，常常覺得書籤要同步起來很麻煩，而且查找也不友善。