BananaX2.0研究紀錄
今日提示詞

RESEARCH NOTE 000 2026.09.22

提示詞有沒有改善, 用圖片來確認。

製作今日提示詞時,我們記錄改了什麼、結果如何。有效的結果,以及還無法判斷的比較,都會留下。

這期準備號介紹兩個既有製作案例。內容的顯示日期與實際生成日期不同。

瀏覽今日提示詞 ↗
01

修改條件的比較 · 9/8 內容紀錄

先決定什麼情況下不放文字。

過去使用同一張虛構書店圖片進行的 Gemini 瀏覽器測試。請看右下方留白;點開圖片可查看全圖。

修改前:右下角新增了輸入中沒有的三行文字
修改前:右下角新增了輸入中沒有的三行文字
修改後:加入無文字條件的版本,未觀察到額外標題
修改後:加入無文字條件的版本,未觀察到額外標題
改了什麼
加入條件:輸入沒有文字時,文字資訊為零,以留白構成畫面。
觀察到什麼
在這個輸入中,前一張的三行自創文案沒有出現在後一張。構圖與繪製細節也有變化。
還不能下的結論
這是單一輸入、少量次數的歷史測試,尚未確立因果效果;也不能代表目前內部圖片生成或其他語言的成功率。
02

同一稿件重新生成 · 9/16 內容紀錄

結果變好,不一定代表提示詞變好了。

向 Codex 內部圖片生成提交兩次完全相同的稿件。保存的檢查紀錄將第一張的一個城市標題判定為拼字錯誤。

第一次:紀錄將 BUSAN 標題判讀為 RUSAN
第一次:紀錄將 BUSAN 標題判讀為 RUSAN
第二次:確認含 BUSAN 的四個城市標題後採用
第二次:確認含 BUSAN 的四個城市標題後採用
改了什麼
沒有修改稿件。紀錄明確記載兩次提交的文字相同。
觀察到什麼
採用了第二張。即使指示相同,圖像與文字結果仍會變動。
還不能下的結論
我們不把這個案例算成提示詞結構的改善成果。只有兩張圖片,也無法估計生成變異或成功率。

METHOD

在日常製作中,逐步檢驗。

  1. 生成前先訂出主題、構圖、文字、輸入保留程度等檢查條件。
  2. 每天最多兩個候選,每個候選最多呼叫兩次,失敗也計入;足夠好就提早結束。
  3. 修改時只調整一個結構元素,並與相同稿件的重新生成分開記錄。
  4. 在後續製作中繼續確認,保留反例,不用一張成功圖片就制定通用規則。

RECORD AUDIT

先確認紀錄裡實際留下了什麼。

檢查了 9/13~9/29 中有內部生成紀錄的 16 天內容。這是包含未來顯示日期的製作台帳,並非依日期排序的品質趨勢。

16天的紀錄
26個候選
47張圖片雜湊一致

紀錄有 47 張成功圖片及 1 次無輸出呼叫,至少呼叫了 48 次。確認 1 個候選超出呼叫上限。9/30 的台帳引用了 1 個缺失的生成紀錄檔,因此未納入集計。

採用與品質合格不同。共同標準的評分紀錄不足,因此不計算品質提升率或首次合格率。金額也未知。

集計與圖片核對資料 ↗

接下來要驗證的問題

無文字條件在不同題材中,是否也能減少多餘文字?後續日常製作有合適案例時再確認,惡化或沒有變化的結果也會保留。

不為研究額外生成圖片。約累積 10 個新的可評估候選且有新發現時,再整理下一期。