如果你讓AI撰寫你所有的Qiita文章，地獄就在等著你。

前言

前次公開的以下文章完全由生成AI撰寫。
我本人僅參與了想法發想、評論與Markdown標記的調整，文章則全由生成AI完成。

使用的LLM如下所示。

LLM	版本	課金的有無
Grok	Grok 4	無
ChatGPT	GPT 5	無
Gemini	Gemini 2.5 Flash	無
Claude	Claude 3.7 Sonnet	有

本文將闡述使用生成AI撰寫文章的過程。

1. 想法探索

在10/8因對Spanner設計論文的興趣，開始讓Grok摘要論文。
Grok的錯誤率相當高，因此我要求其提供每個資訊的來源，並檢查我自己理解的內容與論文是否存在不一致。如果仍感到不安，則使用Gemini和ChatGPT進行事實核查。
其間，我回想起Oracle AI Database 26ai在水平擴展上的功能強化，也讓Grok進行關於Oracle Database 23ai與26ai進化功能的交流，進一步加深了我的理解並提供了對Grok的上下文。同樣的方式我也與Grok探討了MySQL和PostgreSQL，直到10/21為止。
Grok按照聊天室單位保留上下文，即使跨天也能在同一聊天室中進行交流，這對後續過程的幫助很大。

雖然在文章中沒有提及，但我與Grok對SAP HANA及Mongo DB等技術也進行了深入探討。

2. 文章創作

啟發我想讓生成AI撰寫文章的契機，是廣木大地（@hirokidaichi）的講座。

聽到他提到即將於2025年11月13日發售的AIエージェント人類と協働する機械中的內容，與我所說的完全相同—「全由生成AI撰寫」，我便決定也來挑戰一下。

在10/22，我委託Grok創作文章。主題從一開始就決定為「Oracle AI DB 26ai的進化與Spanner設計中的RDBMS進化論」，不過初稿大約只有400字。
之後，我進行了約20次的審核→修改與補充。每次迭代後，文字量增加，到最多時超過4000字（包括mermaid的描述和腳註）。
過程中，我讓Grok閱讀我以前撰寫的Qiita文章，模仿我的文風，結果成為了一篇相當隨性的文章，因此需要對其進行修正。
順便提一下，截至目前為止的所有步驟都是透過手機操作完成的。

3. LLM的轉換

當我多次審核超過4000字的文章感到疲倦時，開始將提示輸入及審核從手機轉到電腦上。
隨著Grok的聊天室因使用過久而變得龐大，開啟PC時的內存需求也相當高，因而迫使我需要導出上下文，同時也考慮切換LLM。
於是，我首先試用ChatGPT，結果僅僅兩次交互便達到一天的使用上限。隨後我也嘗試使用Gemini，但因mermaid的代碼區塊干擾，無法生成可複製的格式。

Gemini的免費方案無法生成md檔，只能以聊天文本格式進行互動。如果想要的內容不含代碼區塊，Markdown或純文本格式仍然足以應用。

另一個選擇是考慮使用Cursor或Claude，於是我決定使用Claude，因為「不如嘗試未曾使用過的LLM」。我也讓Claude讀取我的文風，並將所有上下文保存在本地檔案中，繼續進行工作。
由於文章已經開始在本地md檔上交流，因此變更差異能夠輕鬆查看，審核速度大幅提升。在開始使用Claude後，文章大框架在兩天內基本完成。

脫去生成AI的味道

當文章出現一定程度時，細節，特別是一些不自然的句子或生成AI產生的常見表現便會引起注意。
除了文章表達外，過多使用冒號、過度強調也變得明顯，因此讓生成AI分析「生成AI生成的文章特徵」，多次對文章進行檢討和修正。

4. 品質保證的地獄

關於文章的正確性，從一開始我便與Gemini及ChatGPT進行事實核查，並透過閱讀參考一次來源來保障其準確性。然而，在最後確認相對不受檢查的腳註時，發現超過30個連結URL及其頁面標題幾乎全部錯誤。
即使是從一開始就作為腳註記錄的Spanner論文，其連結也不當（雖未錯誤，但需再從連結中尋找論文）。
訪問時出現HTTP狀態404錯誤的URL也屢見不鮮。
將此修正工作交由Gemini及Claude處理都無法成功，因此我不得不逐一搜尋網絡上的來源，並以「指正」的形式來請Claude進行修正。最終，這項工作耗費了約4小時的時間。這一步驟幾乎讓我感到不需要生成AI參與（不指示直接修正）反而更輕鬆，但我已決定由生成AI撰寫，因此也堅持到底。

正如Qiita社群指導方針中所述，生成的內容確保準確是發布文章的必要步驟。對於文章人類將承擔責任的事實，務必不忘。

感想

除了需要清楚表達對生成AI的期待外，初次創作時也需邊建立上下文，讓我感到比預期更艱難。
此外，除了文章本身，連腳註的URL是否正確也需仔細檢查，這在我檢查的4小時裡不斷讓我產生「自己寫文章肯定更快」的感觸。
然而，經過這些艱辛，卻能讓我看清生成AI的強項與弱點。雖然「生成」的能力出色，但事實確認如URL檢驗與事實核查目前仍然需要人類來完成。正因為堅持到底，我才深切體會到這一現實。

這在編程中同樣適用，使用生成AI時不應全部依賴，而是要平衡地讓AI負責其擅長的部分，這樣才是最好的方式。