我想談談我在這個平台上注意到的事情，也想回應我們一直在想、但在 dev.to 上其實還不太常被討論的話題：AI 的使用。
先別急著反駁我，沒錯，我過去也談過 dev.to 上的人們如何在文章中使用 AI。 很高興看到大家對這個主題的看法，我仍然認為現在談這件事很重要。也許比以往任何時候都更重要……因為 @ben 和 @jess 很快就會推出更接近的版主更新。
話雖如此，當我第一次發表一篇關於自己更積極參與 dev.to 版主工作的貼文時，我聽到很多人討論他們如何使用 AI，例如：
- 用 AI 修正文法和翻譯。
- 產生靈感。
- 完全 100% 使用 AI（不知為何）。
然而，最讓我印象深刻的一點（而且到目前為止也是我看到最常見的留言）是類似這樣的說法：
只要內容夠好，作者有沒有用 AI 根本不重要。
這讓我開始思考：不管有沒有使用 AI，你要怎麼判斷一篇內容是好還是不好？ 我想到《蜘蛛人：全新日》裡 Bruce Banner 對 Peter 說的一句話：「你要怎麼判斷，自然中哪些部分是好的或壞的？」（順帶一提，那是部好電影。）
當然，如果把問題中的「AI」拿掉，這就是個很簡單的問題。每個人對「內容好不好」的標準都不同，例如是否實用、是否有洞見、是否容易閱讀等等。
一旦牽涉到 AI，事情就變得複雜了，因為 AI 可以做到上述所有事情。 事實上，這件事容易到每個人都在用。 每個人都有能力發表文章，而他們也都以某種方式使用 AI。有些方式比其他人更合理。不只如此，有時候人們甚至會用 AI 來寫留言（同樣地，有些方式比其他人更合理）。
我作為開發者學到的一件事
當我查看 GitHub 上人們的個人檔案時，我看到很多專案都是 AI 輔助，或是某種意義上的完全靠「氣氛寫程式（Vibe Coding）」完成，目標是讓招聘方和開發者留下深刻印象。雖然表面上看起來可行，但這裡有一個缺陷……你能解釋你做了什麼嗎？
當然，你可以用文字解釋等等，但大家最常失敗的地方是：當你要即時解釋你做的專案（也就是在通話面試中）時。
我有 99% 的時間都看到一種情況：我請他們解釋自己做的專案以及完成過程，他們看起來就像當機了一樣。 這其實不該發生，因為……那是你做的。
即使是很複雜的專案，你也應該能解釋主要概念和核心功能。然而，現實並不是這樣。
這讓我很驚訝，因為人們累積了那麼多經驗、做了那麼多專案，至少應該能回答關於專案和自身經歷的基本問題。
當然，人們會緊張，尤其是在面試過程中。我也會緊張。 但重點是，我會隨著時間學習。 這就是人性。當然，每個人的學習速度不同，但只要你持續進步，就代表你願意學習，也代表你真的在盡力。
話雖如此，如果你有 10 年以上經驗，我對你的期待會是：不論有沒有用 AI，這個人至少應該能在基本層面上解釋自己做過的專案。 如果你是那種過度依賴 AI、甚至只是為了在市場上脫穎而出而去「氣氛寫程式」的人，不管你的專案品質多高……祝你好運，在即時情境下詳細解釋這個專案吧。 你也許能拿到面試機會，但你能通過嗎？
我的重點是什麼？
我一直對寫作中的 AI 持保留態度，特別是因為我害怕自己過度依賴 AI。 這件事已經對我作為開發者造成影響，而我也很難抗拒不要過度使用 AI，我對此感到後悔。我希望自己能成為一個一邊持續學習、一邊以某種方式使用工具的人。換句話說，把 AI 和自己動手做，取得良好的平衡。
此外，我也想成為那種能夠回答自己寫的內容相關問題的人。 如果我寫了一篇非常複雜、完全由 AI 產生的文章，而別人問了我一些我不懂的問題，那我就會惹上麻煩。
當然，我可以把對方的問題複製貼到 AI，然後把 AI 回答的內容再複製貼給對方，但到頭來，我什麼也沒學到。我會被視為真正的騙子，因為任何人都可以完全用 AI 生成文字。 這樣一來，原本建立特定社群的目的就被破壞了，因為我們一進來就看到每個人都像某個領域的專家，而不是看到有人真的在學習，並把學到的東西分享回這個平台。
值得思考的一種情境
想像一下。 假設你是一位非常知名的作者，現實生活和網路上大家都認識你。你的文章是完全由 AI 生成的，而且沒有人知道。你的末日，就是有人在現實生活中問你一個問題，而你必須即時回答。
我相信這個平台有很大的潛力與影響力，足以帶來改變。這個社群雖然小，但也大到足以讓我們的聲音被聽見。 我相信 AI 不會很快消失，但我覺得我們應該改變使用 AI 的方式。 不要再依賴 AI 替我們寫文章，而是應該用正確的方式，讓我們能學到新東西，同時又能善用工具，而不干擾學習。
以下是我接下來在 dev.to 會做的事，也建議大家這麼做。
1. 提出能延伸思考的問題，而不是用任何形式去背誦內容。
我看到很多留言只是同意某個觀點，因為那樣可以這樣或那樣。 雖然這是很好的起點，但對主題本身的延伸其實不多。相反地，試著用某種方式挑戰作者，提出一個你在文章中找不到、但你自己也想知道的問題。 獨特的問題能讓你和作者都學到東西。這樣一來，你學到新知識，作者也有機會更深入地解釋主題，甚至補充他們原本可能不知道的部分。
當然，別人可能會以某種方式評價你。與其防衛，不如想想他們留言中的某些部分，是否能幫助你成長。如果不能，也沒關係。 每個人對事情都有不同看法，這也反映了他們的立場，這其實是好事！我很樂意聽到別人的意見，因為這能幫助我們更理解當前主題，而不是單純重複作者說過的內容（如果只是重複、沒有其他內容，根據我的經驗，其實沒什麼價值，而且真的很重複）。
舉例來說，假設我在談 Python，其中一個觀點是：「Python 是一門很好的語言，因為它對新手開發者很友善。」
想像一下，某個人留言說：『我同意你提到 Python 很容易學。這讓新開發者能進入程式設計領域，而且學習曲線比較低。它讓新開發者在 AI 時代尤其受到重視。謝啦，兄弟！』
說實話，這樣你真正能學到的最好資訊，大概就是 Python 在 AI 時代很棒。就這樣。即使如此，大多數人應該也早就知道了。
相反地，留言應該像這樣：「我同意 Python 對初學者來說很容易上手。不過我想知道，除了 Python 之外，還有沒有其他同樣適合初學者的替代語言？除了語法之外，你是怎麼判斷一門程式語言是否適合新手的？」
這是一則好留言，因為留言者知道 Python 是一門適合初學者學習的語言，但也想知道其他替代方案，以及除了語法之外，還有哪些作者沒有提到的語言差異。此外，這也能促使作者思考並給出更有深度的回應（也許作者會學到新東西，或是忘了補充某個重點）。總之，留言時要比大家平常的做法多加一些思考。是的，有稱讚性的留言很好，但如果文章已經在深入探討某個主題，我會建議留言內容再更豐富一些。
顯然，如果對方開始洗版或說一些沒有價值的難聽話，那就另當別論了（我想我們都算是理性的大人，在開口前都能先思考）。
2. 以能持續學習的方式使用 AI。
在 dev.to 上，目標是分享知識或作品給平台上的其他人。這個平台是為了讓開發者和世界各地的其他開發者交流而建立的。現在，先跟上我的思路，讓我們拆解一下。
如果你正在做專案，請確保你是自己寫程式，而不是依賴任何 AI。 如果你已經遇到一段時間都想不出解法，這時候再用 AI。但是，請明確要求 AI 不要直接給你完整答案。只要給你能讓你思考出解法的提示就好。
這樣你就能做出真正屬於自己的專案，持續以某種方式學習程式設計，並且以正確的方式使用 AI 加速開發。 此外，有了這種歸屬感，你還是能解釋自己做了什麼，也能說明自己在過程中如何使用 AI，這會比大多數人使用 AI 的方式更好。
如果你正在 dev.to 上寫文章，先練習大聲朗讀。 你會很驚訝，光是大聲唸出來就能抓到多少文法錯誤。如果英文不是你的母語，但你可以用英文寫作，請盡力完整寫出來，就像你真的要正式發表一樣。之後再用 AI 修正文法錯誤，但盡量保持簡單。 留言也是同樣道理。
透過盡可能自己輸入內容來寫作，能幫助你鞏固理解，並讓你對自己作為開發者的知識更有信心，不論主題是什麼。
@codingwithjiro 使用 AI 的方式，大概是我目前看過最好的（而且我也應該跟著學），這是根據 @konark_13 關於 Vibe Coding 的文章：
https://dev.to/codingwithjiro/comment/3c5hb
你可能會注意到，目前為止的主題都是：你要透過做來學，而不是依賴別人。 這樣做，可以讓你在開發技能、英文能力上持續進步，同時也還能以某種健康的方式使用最新的 AI 工具。
此外，這也能讓 dev.to 上真正發生學習，不只是讓使用者透過提問來延伸主題、而不是重複作者的話而學到新東西，也能以專業且正確的方式挑戰作者的知識。
什麼才叫內容好，不在於文章寫得多漂亮或有多少互動，而在於雙方是否都能學到東西，不論主題是什麼；以及它是否能以某種方式挑戰作者與讀者，幫助雙方成長到他們從未想過的程度。
這樣做難嗎？是的。 本來就該難。雖然如此，這也代表你正在學習。如果你在某個主題上感到吃力，這其實是個非常好的跡象，表示你即將學到新東西。重點在於你是否有意願這麼做，並允許自己在過程中脆弱地犯錯。
請記住，我們不是專業寫手，我們是開發者。 當然，你也可以兩者兼具。但關鍵只在於，你是否能從作者和留言者的角度學到新東西。
問題不是「這是不是 AI 生成的？」。問題是：「他們能不能在即時情境下，詳細解釋自己做了什麼、為什麼這麼做，而且方式還很獨特，能在 AI 已經主導的世界裡脫穎而出？」
<center><b>有問題或想法嗎？很想聽聽你對這個主題的看法！</b></center>
原文出處：https://dev.to/francistrdev/how-would-you-decide-whether-the-content-is-good-or-bad-295p
1) --- 會變成分隔線（上一行必須是空白）
2) # 會變成一級標題
3) ## 會變成二級標題
4) ### 會變成三級標題
5) **粗體文字**會顯示粗體文字
6) ```當第一行與最後一行會顯示程式碼
7) 請搜尋 Markdown 語法，了解各種格式
