最近跟很多朋友交流,他原本不會寫 code,是做規劃和整合的人,但開始 Vibe Coding 後做出了成果,反而變成期待通膨,工作吃不消。
這就是職場常見的陷阱:能力強的人,事情會越來越多,搞死自己。但 Vibe Coding 這波,陷阱比以前更深,因為大家對 AI 的想像太美好了。
不是不要 vibe coding,因為我自己也在做,也樂在其中,但是這其中難免有很多令人不舒服的地方。
閱讀全文
最近跟很多朋友交流,他原本不會寫 code,是做規劃和整合的人,但開始 Vibe Coding 後做出了成果,反而變成期待通膨,工作吃不消。
這就是職場常見的陷阱:能力強的人,事情會越來越多,搞死自己。但 Vibe Coding 這波,陷阱比以前更深,因為大家對 AI 的想像太美好了。
不是不要 vibe coding,因為我自己也在做,也樂在其中,但是這其中難免有很多令人不舒服的地方。
閱讀全文
現在越來越多 PM 開始用 Vibe Coding 做產品開發。如果你用 SDD(Spec-Driven Development)框架,像是 Spec Kit,流程大概是這樣:人類寫 User Story、輸入設計稿,然後 AI 會根據這些東西產出 Spec 和開發計劃,最後再依照計劃去實作。
這時候一個很自然的問題就出現了:反正出來的東西會動就好,我幹嘛要去看、甚至看懂 AI 寫的 Spec 和開發計劃?
老實說,這個觀點也不能說錯。但在回答這個問題之前,我想先把 SDD 和 AI 拔掉,回到一個更基本的情境來看。
閱讀全文
自己寫過快 300 篇 blog,還有 22 小時含逐字稿的課程,好處就是,從中抽取 skill 會很方便。
我把我的產品企劃實作框架,變成 skill 並在 GitHub 開源了,歡迎大家 fork / 使用。
閱讀全文
真的該好好釐清一件事:我們要請 AI 幫忙的目的是什麼。一旦目的搞錯,AI 就會從助力變成拖油瓶。
舉例來說,很多 PM 在用 vibe coding 做 prototype 的時候,常常犯下一些嚴重的錯誤。像是「略過了用手思考的步驟」
什麼是「用手思考」?
閱讀全文