我一直是個很容易快樂的人。從我記事起，我就天生樂觀，而且有很強的踏實感。雖然我個人沒有焦慮症或憂鬱症，但我一生都在看著我關心的人與這些疾病作鬥爭——小題大做，為最瑣碎的事情煩惱，或者乾脆無法解釋自己為什麼如此沮喪。
我一直想幫忙，卻不知該如何表達。我該如何針對自己從未經歷過的事情提供建議呢？
然而，我確實注意到一個關鍵的模式：傾向於把所有事情都憋在心裡。當擔憂被憋在心裡時，它們會不斷繁殖，最終累積成難以承受的重負。這可不是簡單的放下就能解決的；這些想法揮之不去，像一首惱人的叮噹聲一樣不斷循環。對於那些有這種困擾的人來說，簡單地「忘記」根本不可能。
這讓我萌生了一個簡單的想法：如果你放下它們會怎麼樣？不是忘記它們或讓它們消失，而是把它們從你的腦海中轉移到一個安全的、外部的地方。一個它們仍然存在的地方，這樣如果需要的話，它們可以重新出現，但不再佔據你所有的心智空間。 20年前，正是這個簡單的想法成為了「憂慮盒」（Worrybox）的創立原則——後來我才知道，它是一種公認的理清思緒的療法。甚至連名字都一樣。我當時不知道這一點，有點不好意思。
諷刺的是，Worrybox 的想法在我腦中盤旋了好幾年。它一直縈繞著我，催促我採取行動。但由於工作繁忙，加上我覺得這個平台雖然有用，但賺不到足夠的錢來支撐它自己的伺服器，所以我一直沒能動手。
然而，這個簡單的想法卻帶來了一個重大的技術障礙。我設想的核心功能是一個簡單的計數器，告訴發文者有多少人有類似的擔憂。我的目標是傳遞一個強有力的團結訊息：“你並不孤單。”
二十年前，要將一個人的擔憂與另一個人的擔憂進行配對——尤其是在措辭不同的情況下——極其困難。我們只能進行繁瑣的關鍵字配對或耗時的分詞。但如今，有了新一代基於LLMs（LLM）的人工智慧模型，這種語義匹配變得輕而易舉。
推動開始
我從事開發多年，使用過多種語言和技術。我開發過簡單的實用程式、CRM 系統、遊戲，甚至破解過一架無人機，為其加入感測器，使其能夠飛過污水管道。所以，我的本能是從零開始，並密切注意自己的程式碼。即使近年來，人工智慧已成為提升開發者工作流程的絕佳工具，我通常還是會把它留給一些小任務：回答問題、集思廣益開發新功能、閱讀多部分日誌（說實話，這是我發現的人工智慧的最佳用途），以及作為我的第二大腦。讓人工智慧完成所有工作的想法並不令人興奮。我從經驗中知道，繼承一個龐大的程式碼庫是多麼麻煩。我得費心查看別人辛苦工作成果，卻完全不知道他們在建構過程中經歷了怎樣的思考過程。讓人工智慧處理整個程式碼庫，我也會面臨同樣的困境。但是…
我偶然發現了「 Kode with Kiro 」黑客馬拉松，這似乎是實現非營利想法的有趣方式。它給了我開始開發WorryBox所需的動力。由於沒有太多時間自己動手，我考慮嘗試新的方法。雖然黑客馬拉鬆建議和Kiro一起編碼，但我決定擔任專案經理，依靠人工智慧來處理一些複雜的任務，而這些任務我以前需要自己花上好幾天的時間來完成。我從一開始就決定，我負責提供想法、提示、任何設定或外部零件，但最終把程式碼留給人工智慧。至少在比賽期間是如此。這感覺有點“不爽”，但這意味著我不必放棄其他承諾（例如我的工作）。我可以專注於我的工作，而Kiro則專注於建立平台。我只需要偶爾和它互動一下，檢查進度並引導我的想法。
WorryBox－理念
Worrybox 是一個富有同情心的社交平台，旨在透過結構化發布、隱私控制和支持性社群互動來幫助用戶表達他們的擔憂。
它能讓你把自己的擔憂放在一個安全的外部空間，並看看有多少人有類似的擔憂。這項功能得益於與評論審核相同的人工智慧技術，確保平台始終是對每個人都安全且受保護的空間。
在設計使用者體驗時，我們考慮了每一個細節。雖然大多數社群網路都設有「讚」按鈕，但對於一個致力於展現情感脆弱性的平台來說，這感覺完全不合適。你無法「按讚」某個擔憂。因此，我將其替換為“支援”按鈕。這個小小的改變，卻對團結和同理心的感受產生了巨大的影響。
旁邊是“Me Too”按鈕，它由語義AI匹配技術驅動。它簡單卻有效，讓使用者表達自己曾經有過類似的經驗。它直接回答了「只有我有這種感受嗎？」這個問題，也明確地表明了社區成員願意互相支持。
所有這些都指向一個神奇的數字，表明你並不孤單。
旅程
Kiro 作為一款應用，上手極為簡單，並擁有一套從規劃開始的合理工作流程。 Kiro 會根據使用者需求，協助規劃整個系統，並在必要時進行修改。用戶確認計畫後，Kiro 會繼續規劃實現計畫所需的步驟。之後，新功能的發展也遵循同樣的工作流程。使用者同樣需要確認步驟，但只要使用者滿意，Kiro 就會開始第一步的開發。
Kiro 的工作令人印象深刻，準備工作細緻入微也令人欣慰。如此快速地整合所有東西，會讓經驗豐富的開發人員感覺自己不像個程式設計師，而更像個經理（這可不是什麼好事）。不過好在這種情況不會持續太久。
雖然 Kiro 確實是一個出色的工具，並且完全能夠完成大部分工作，但在解決過程中仍然存在一些問題，而程式碼知識和經驗對於解決問題非常有價值。
修復、移除、修復循環
當然，這種放任不管的做法並非沒有挑戰。我必須測試 Kiro 的工作，在測試過程中，我很快就發現了一些 bug。雖然 Kiro 的 Worrybox 初版運作良好，但隨著計劃的推進，我發現頁面會因為語法問題而出錯，有些頁面根本不存在，有些部分的設計也與最初的設計不符。
最後這一點沒辦法。 Kiro 沒有情感，也不真正理解這個計畫的目的。所以，有時候為了得到正確的結果，只好重新解釋。說實話，我並不介意這一點。
然而，最大的問題是語法錯誤。我發現每次 Kiro 陷入循環都是因為一個簡單的 HTML 語法問題。例如，在嘗試尋找頁面錯誤的原因時，Kiro 會發現缺少一個標籤。為了解決這個問題，它會加入這個標籤。但這又會引發另一個問題，Kiro 會認定原因是多餘的標籤，然後乾脆把它刪除。這又會讓我們回到最初的問題。由於 Kiro 能夠編輯程式碼，然後執行它來檢查錯誤，所以有時需要我的介入來結束這種瘋狂的循環。所以，儘管我決定完全不為這個專案編寫程式碼，但最終我還是得做一些事情來維持專案的運作。
但我保證，這只是一點點。 😅
遇到這些循環，或者 Kiro 無法解決問題時，我發現自己必須手動進行必要的修改。如果是我自己的程式碼庫，速度會更快，但由於 Kiro 完成了大部分工作，所以找到問題需要一些時間。但總而言之，這和幫助同事解決問題沒什麼兩樣。有時，即使是最熟練的開發人員也會犯一些簡單到他們自己都無法察覺的錯誤，這時，另一雙眼睛的幫助就顯得彌足珍貴了。
總的來說，這段經歷幾乎和領導開發團隊做專案完全一樣。我以前也管理過類似的團隊，也遇到類似的問題（不過問題不大，只是修復循環比較多）。
傳播：經商成本
搭建平台後，我面臨的下一個主要障礙是營運資金。 WorryBox 是一個業餘專案，因此我沒有任何資金或支援來支付託管、AI 或資料儲存的費用。幸好 Kiro 也幫了我大忙。我告訴 AI 我的預算為零，並請它提供了一份創意清單。
Kiro 的建議分為幾個層次。第一個想法已經過時了，它讓我參考了 Google、Azure 和 AWS 等主流雲端平台的開源資助專案，但這些專案現在已經不存在了。第二個想法建議採用低預算、隨選付費的託管方式。雖然這些方案並非免費，但它們是朝著正確方向邁出的一步。
但第三組想法正是我所需要的：一種真正免費的方式，利用不同提供者提供的慷慨的免費套餐來運作一切：
前端：Vercel
後端：渲染
資料庫：Azure SQL
人工智慧：Google人工智慧工作室
圖片：Cloudinary
這次設定讓我把現有的 PostgreSQL 系統轉換成 MS SQL，這引入了一些 bug。但最終還是解決了。然而，執行了幾天后，我發現 Azure SQL 的啟動速度太慢，以至於有人在登入 WorryBox 之前就放棄了。
當我向 Kiro 提到這個問題時，他推薦了 Neon。這意味著要轉換回 PostgreSQL，但這種改變是值得的。 Neon 的免費版啟動速度非常快。
這樣每次都能讓系統正常運作約 10 天。之後，Neon 的免費運算時間就會耗盡，導致 Worrybox 無法使用。 Google AI Studio 慷慨的每月 AI 使用限制也出現了同樣的情況。對於測試來說，這很棒，但對於一般用途來說，就沒那麼好了。
幸運的是，我最近收到了一筆專門用於資料庫的匿名捐款。這筆捐款加上 Neon 提供的 100 美元積分，意味著 Worrybox 不會在月中停止工作。每個月的 AI 積分用完後，AI 不會再統計類似的擔憂數量，但這並不妨礙用戶與平台互動。能否在比賽期間持續執行是目前的主要挑戰，但我理想情況下希望 WorryBox 能夠盡可能長時間地持續工作並幫助人們。
最後的想法
無論它是如何建構的，這個計畫都是我個人的，其驅動力源自於一個願望：創造一個真正有益於心理健康的工具。 「Kode with Kiro」黑客馬拉松給了我從概念到創作所需的動力。但展望未來，我會努力讓它保持活力，並可能更多地參與程式碼庫的建設。
我誠摯邀請您探索 Worrybox 並分享您的想法。您的回饋對我的旅程至關重要。
Worrybox（Alpha 版）連結：worrybox.gigaelk.com
使用 Kiro 在 Kode 上進行的專案連結：https://devpost.com/software/worrybox
1) --- 會變成分隔線（上一行必須是空白）
2) # 會變成一級標題
3) ## 會變成二級標題
4) ### 會變成三級標題
5) **粗體文字**會顯示粗體文字
6) ```當第一行與最後一行會顯示程式碼
7) 請搜尋 Markdown 語法，了解各種格式
