現在一大堆針對 chatGPT 提問的 prompts
恰恰說明只要給的指令夠精確他就能做事
而瀑布式開發雖然近年被唾棄，但它的一大特點就是一開始就會有盡可能明確的規格書
尤其是接案產業為了驗收標準，幾乎定規格時連 schema 與流程圖都會有
優質一點的甚至附畫面以及定義每個互動的 input 與 expections
這種有明確的 test cases 正是 chatGPT 的強項
所以我猜測最快產生的取代工程師的情景:
1. 從 0 到 1 的專案，因為 chatGPT 不用了解現有系統
2. 瘋狂 CRUD 型的專案，例如內部系統，較少外部不明確 Dependencies
達到這步之前 chatGPT 需要先可以針對 spec 模糊與矛盾之處提問，
但目前的技術傾向於硬給解答，不曉得有沒有辦法改進
然後會產生操作 chatGPT 工程師需求，專門寫給 chatGPT 看的 spec/test cases
以及針對產出的 source code 微調與 QA 後交貨

你忘了這類公司的問題就就在於不寫spec或文件，或是只寫驗收交差用的，gpt時代他們還是一樣啊XD合約文件寫的是最模糊的那種，最多就是驗收階段文件會慢慢補上去，但驗收的項目跟一開始的spec大部分也不相同了

瀑布流跟敏捷各有其適用的場景

你想多了 接案一樣需求會在開發前後持續修改你說的完善spec 但多數場景連客戶自己都不清楚他要什麼coding只佔軟體開發非常小的比例 而AI目前只加快了這小塊

所以我文中才說需要 chatGPT 能回頭釐清問題

被樓上說完了XD接案本質上就是通靈，簽約的高層跟使用系統end user認知差距很大，而user大部分真的不知道自己要什麼，所以要應用在spec文件比較難，用在test cases比較有機會

客戶連他自己想要什麼都不知道 要怎麼寫規格？

所以才說通靈 有時候就是一些敘述而已你就要開始開發了

合約只會寫建置xxx系統，要符合什麼法規，驗收要哪些單位，其他內容要嘛接案公司本來就是深耕客戶產業的，知道要幹嘛再依照客戶調整，不然都是要pm ba去一直開會問出來後，交給開發團隊開發

推接案本質上就是通靈XD

等chatgpt能出來撕逼再說吧敏捷就是為了撕逼輸的時候 頻繁改需求才出現的

@foreverk

噗

除非gpt會通靈XDD

連客戶都不知道自己要什麼商業邏輯，你要GPT通靈?

我的想法是反過來，gpt是幫助寫完結案所需文件，文件能自動從程式自動不斷修改

良好的文化不是不能根基於瀑布模型 但成功的關鍵仍在於即時的回饋與修正 這不是任何初期的精確能夠解決的前期精確就是中後期的僵硬 AI介入輔助也不能改變這點

你想多了 多的是scrum誤用成瀑布式的再加上需求變更在專案中本來就很常見定義上完成最小價值產品 還是使用者的偏好

一堆公司都不寫文件或是文件跟成品落差很大沒更新的吧

想法蠻有趣的耶

呵呵，每篇都在用GPT通靈。waterfall,的問題又不是在寫規格書，waterfall也沒有硬要人寫完整的規格書。