用30天回顧一個小工具如何「失控」越長越大、成為一套公司內部團隊正式使用的系統。同時回溯從一開始以專案管理的角色與工程師協作,到後來開始越界、自己用vibe coding栽進開發的過程。除了實務開發工作的學習以外,也想試著寫寫一個非技術背景的人文社科生,在這整個速度飛快的開發過程中腦內出現的自我提問和用vibe coding產出過去不可能做到的成果的體感。事情到底是怎麼越滾越大的,想好好來回想一下。
第一次寫 code,是因為工作gap year進修時的一堂課上了p5.js, 對programming的理解大概很粗淺地停留在如何用JavaScript做出動態...
這個專案一開始很簡單。 「我們需要一個方法,讓業務團隊能有個一致的標準能夠衡量一場客戶提案會議的品質到底怎麼樣?」 接了這個來自業務團隊的需求後,我們開始著手開...
一切都是從一個商務端的痛點開始的。 業務團隊的每個同仁每天都可能有多場客戶提案會議,主管絕不可能親自參與每場提案、review 提案表現。但是會議中與客戶的問答...
一開始在設計這個提案會議評量工具的雛形時,我們想得相對簡單。 如果目標是讓AI幫忙審視一場客戶提案會議的品質的話,那首先我們必須先拿到會議的素材,也就是會議的錄...
在前一篇裡提到這套工具系統的第一個階段,是把業務的客戶提案會議的錄音或錄影檔,轉換成可被系統進一步分析的逐字稿。 一開始真的覺得這件事情應該不難,但實際開始測試...
接下來進入這個專案裡,我覺得最有趣、但也最有挑戰性的一段:到底要怎麼讓 AI 穩定判斷一場提案會議做得好不好?首先我們做的就是訪談資深業務主管,請他歸納出一個好...
在開始設計 scoring rubric 的時候,我們沒有一套現成的標準可以直接拿來使用。 我們確實有業務主管多年累積下來的經驗,但這些經驗從來沒有被明確地定義...
今天想先跳出來寫一下在整個工具系統開發過程中常被沒有實際參與專案開發的人員忽略、但實際上卻極不可或缺的測試驗證環節。在前幾天的文章中有提到,這套系統在設計過程中...