Vibe Coding效率翻倍技巧：寫程式碼前必看！先用AI幫尋找最優方案

這兩天有個朋友問我，怎麼用Codex效率能高一點。

我说你想做的东西，GitHub 上大概率已经有人做过了，而且不少方案已经很成熟。能直接参考、修改，为什么还要从头写一遍？

我說那你把下面這段提示字複製進去，每次開專案前先跑一遍。

他试了一下，回来跟我说，确实省了好多时间。

我想了想，好像確實挺多人都不知道這個操作。就是很多人用AI寫程式碼，上來就開始Vibe Coding，直接讓AI生成網站、寫App。

其實真的不用這麼急。

你想做的東西，GitHub上大機率已經有人做了

你想做的東西，GitHub上大機率已經有人做了。而且很多方案已經很成熟，程式碼品質可能比你自己寫的還要高。能直接參考、修改，為什麼還要從頭寫一次？

我自己的習慣是，每次想搞一個新項目，先不寫程式碼。先把這段提示詞丟給Codex：

我要做一个XXX。先不要写代码。去GitHub找能直接使用或二次开发的开源项目，确认是否还在维护、部署是否麻烦、哪些功能可以复用。最后告诉我，应该直接用、基于现有项目改，还是自己开发，并给出最简单的MVP方案。等我确认后再动手。

就這麼一段話。

這個提示詞做了三件事

你想想看，這段提示詞做了三件事。

第一，它讓AI先去GitHub上找現成的解決方案，而不是直接開寫。很多人可能不知道，Codex接了GitHub插件之後，是真的能即時搜尋開源專案的，不是編的。

第二，它讓AI幫你評估這些專案的質量，是不是還在維護、部署麻不麻煩、哪些功能能直接拿過來用。這些事情如果你自己去GitHub上一個一個翻，可能要花一兩個小時。讓AI跑一遍，幾分鐘就出結果了。

第三，它讓AI給你一個明確的決策建議，是直接用、改一改、還是自己從頭寫，而且還幫你規劃最簡單的MVP方案。

為什麼能省一堆Token

我跟你說，這個操作真的可以省一堆Token。

為什麼呢？因為如果你直接讓AI開始寫程式碼，它不知道你想要的東西其實已經有現成的了，它會從零開始幫你產生一大堆程式碼。這些程式碼可能跟現有的開源專案功能重疊，最後你還要自己去清理。

但如果先讓AI幫你找答案，它給你的建議會基於已有的生態，你再寫的時候，程式碼量至少可以砍掉一半。

我自己就是這麼幹的。每次做新項目，先跑這個提示詞，再根據AI給的建議再決定下一步。效率真的高很多。

說實話我也不確定這個方法對每個人都有用，可能有些項目確實找不到現成的方案。但你想想看，大部分你想做的東西，GitHub上幾億個倉庫，真的大概率有人已經做了。

站在巨人的肩膀上

你不是程式設計師，不需要從零寫程式碼。你不是做內容的，不需要天天原創。你就是一個想搞點事情的人，最聰明的做法就是先看看別人已經搞了什麼，然後站在巨人的肩膀上。

我有時候覺得，AI時代最聰明的用法不是讓AI幫你做所有事情，而是讓AI幫你做資訊檢索和決策分析，然後你再去做執行。

這跟以前用搜尋引擎的差別是什麼呢？以前你搜一個需求，出來一堆鏈接，你得自己一個個點進去看，看哪個能用、哪個不能用。現在你把需求告訴AI，它幫你篩選好了，直接給你結論。

你敢信？ ？ ？

這個提示詞應該要刻進DNA錶款系列裡

反正我覺得，這個提示詞應該要刻進DNA裡。每次開新項目，先跑一遍，真的可以省很多時間。

而且這樣還有一個好處，就是你不會重複造輪子。 AI幫你找現成的，你只需要專注在那些真正需要客製化的部分。這樣你的精力才能花在最有價值的地方。

我自己的感受是，剛開始用AI寫程式的時候，確實很興奮，什麼都想讓AI從頭生成。但用久了就會發現，很多時候這樣做反而慢。因為AI生成的程式碼你得調試、得修改、得維護，而現成的開源專案經過很多人驗證，品質更有保障。

這話聽起來有點反直覺對吧，但你想想看，代碼這東西，最重要的不是寫出來，而是寫對。現成的方案已經被驗證過了，你直接用，出問題的機率會低很多。

所以我的建議是，下次你用Codex或任何AI寫程式碼的時候，先別急著開始。先跑一遍那個提示詞，讓AI幫你找答案。

搞不好你會發現，你要做的東西，早就有人做好了。

你只要拿過來用就好了。

省下來的時間，去做點更有意思的事。

以上，既然看到這裡了，如果覺得不錯，隨手點讚、轉發吧，如果想第一時間收到推送，也可以給我個關注～

謝謝你看我的文章，我們，下次再見。