參加多次競賽後，我最常提醒自己的是：別太早愛上第一個點子。以前容易先把故事和畫面想得很完整，後來才學會先把題目與評分表拆開，這一步雖不華麗，卻常決定後面會不會白...
寫完又想到一招：把評分項目的配分也放進工作表，但不要直接照比例分頁。高配分項目要有更強證據，低配分的硬性規定仍不能漏；「分數少」和「可以不做」是兩回事。
把教材轉成概念圖和互動內容，比再做一個摘要器有辨識度。我最想知道的是：視覺化如果變得很好懂，卻偷偷簡化錯了，要怎麼抓？你會讓每個節點都能回到 PDF 的原始段落...
先限制使用者和旅遊情境，比直接叫 AI 開始寫 App 踏實很多。好奇之後泰語句子與發音要怎麼驗收？會找母語者協助、比對可信的語言資料，還是先清楚標示 AI 產...
看到第一版才知道自己在意什麼，真的比一開始硬擠出完整需求自然很多。想問你會怎麼保存這些後來才發現的偏好？哪些會升級成整個專案的固定規則，哪些只算這一篇的修改，才...
「AI 可以設計 Validation，但不能成為 Validation」這句很中。想知道你真正開始驗證產品時，第一步會選訪談、問卷，還是先做一個很小的 Pro...
把 ChatGPT 放在需求釐清、Codex 放在專案修改，分工滿清楚的。我比較好奇交接時怎麼避免資訊走樣：你會把確認過的驗收條件存進 repository，還...
特別開新任務來避免前文影響，這個實驗設計很聰明。想請問你之後會不會拿 Codex 畫出的 repository 地圖逐項對照檔案，記錄哪些是正確引用、哪些只是合...
七項維護契約很完整，尤其是「程式完整不代表需求完整」很有感。如果今天是緊急修復、沒有時間七項全部走完，你會把哪三項列為絕對不能省的最低檢查？我猜影響範圍和回復方...
「所有會員」和「全部都是 P0」真的都是需求會議裡很熟悉的警訊（笑）。我很好奇，你會怎麼控制 AI 挑戰需求的頻率？如果每個回答都被反問，使用者可能很快就累了；...
lin1015的鐵人檔案