小編精選 - 技術文章翻譯 · 06月05日

女程式設計師多肉的 AI 小綠書，短短 3 天 220 粉

女程式媛多肉的 AI 小綠書，短短 3 天 220 粉

微信公眾號近 1～2 年，主推貼圖類型作品，並且對這類內容有比較明顯的流量傾斜。再加上這兩年 AI 生圖的成熟，Nano Banana Pro 和 GPT-Image-2 先後出世，既然圖片生產不再是卡點，那很多人會很自然地想到一個專案：用 OpenClaw、Codex、Claude Code 這類 Agent 工具，把公眾號貼圖自動化做起來。

理論上，這聽起來像一個很好且成本不高的生意。AI 負責生圖，Agent 負責寫文案，公眾號負責推薦流。人只要選圖、點發布，甚至再往後一點，連選圖都可以交給 Agent。
但實際上真的有這麼簡單嗎？我自己維護的公眾號《女程式媛多肉》，看起來只是發了幾張漂亮照片，短短 3 天吸引了 220 個左右的粉絲。但真正做下來，我卻花了大量的功夫。AI 小綠書表面是生圖專案，底層其實是一個很典型的 Agent 工程專案。這個過程裡，我們踩了不少坑。下面我做一下總結，希望對你在 AI 工程化的思路上有所幫助。

人物一致性

做 AI 貼圖的第一反應，通常是追求畫面品質和驚豔的感覺，比如更漂亮的人、更乾淨的背景、更精緻的穿搭、更像攝影大片的光線。模型也很願意往這個方向走，因為這些東西在訓練分布裡太常見了。

但對《女程式媛多肉》來說，我們真正要做的不是「生成一個好看的女生」，而是讓固定人物【多肉】持續出現在固定生活半徑裡。這個區別非常關鍵。一開始最容易出現的問題，就是每張圖單獨看都不錯，但放在一起不像同一個人。臉型輕微漂移，髮量變了，瀏海變了，身材比例變了，妝感變了，甚至氣質也從普通女程式員通勤照，慢慢跑成網紅寫真。

更麻煩的是，這種問題不是一句 prompt 能解決的。你寫「same girl」「same face」「保持角色一致」，模型有時候會把一致性理解成角色設定稿，於是畫面開始變得更乾淨、更棚拍、更像 AI 人像。當然，也不是說你生成一張固定的角色資訊卡就可以了，理論上它和 prompt 面臨同樣的問題。

我們後來對這個問題的判斷是：角色一致性不能來自「設定稿強約束」，而應該來自「同一生活序列」。也就是說，不能把主模特錨點當成畫風來源。它只能提供身份邊界，告訴模型不要漂成別人。真正的出圖錨點，應該逐漸遷移到同一人物、同一天、同一場景、同一手機成像分布下的連續生活照。

所以我們在流程裡做了幾個約束：

固定人物身份：22 歲北京女程式員，多肉。
固定生活半徑：出租屋門口、公司電梯、園區、工位附近、樓下取快遞。
固定內容語境：通勤穿搭、程式員日常、出門前的小選擇。
同組連續性：同一套圖裡髮型、瀏海、包、襪子、鞋子、場景、光線和拍攝語境必須一致。
禁止人物鏡子圖：因為鏡中人物和真實人物一旦不一致，一眼假會非常明顯。

這套約束很像開發工作中的工程配置。但它解決的是帳號最核心的問題：使用者關注的不是一張圖，而是一個可以持續出現的人。

衣服經常不是穿上去，而是貼上去

貼圖帳號如果要做穿搭，第二個大坑是服裝。很多 AI 圖第一眼看還行，細看會發現衣服像貼在身體表面。裙擺沒有重量，襪口沒有壓痕，鞋底沒有接觸，口袋沒有厚度，衣服皺褶也不是來自肩膀、腰線、坐姿或包帶，而是模型隨手畫出來的紋理。

這類問題在普通審美裡可能只是瑕疵，但在穿搭內容裡是硬傷。因為使用者看到的是「這件衣服穿在身上是什麼效果」。如果衣服只是像一層貼圖，穿搭展示就不成立。

我們後來把穿搭任務單獨抽成了一個契約：只要使用者給了衣服、褲子、鞋、包或說「穿這個」，系統就必須把一級目標鎖死為：固定模特多肉，穿使用者給定服裝，在已批准場景裡生成真實日常照片。

這裡面有幾個優先級非常硬：第一，必須是多肉本人。第二，衣服必須穿在她身上。第三，第一張圖必須清楚展示服裝。第四，一組圖必須像同一天同一套衣服的連續照片，而不是不同批次拼出來的好看圖。

這個約束解決了一個很常見的漂移：使用者明明要穿搭圖，Agent 卻很容易跑去做帳號策劃、場景圖、海報、泛日常內容，或者生成一張「氛圍很好但衣服看不清」的圖。

我們現在會在生成前強制寫 generation-packet.md。裡面不只寫「生成一張真實照片」，而是要把主體服裝身分、攝影事件、構圖透視、光源曝光、投影接觸、頭髮皮膚表情、服裝材質受力、環境生活細節、檔案質感瑕疵和負向熔斷都寫進去。

可能你覺得這個太重了？但做久了發現，AI 生圖最怕的就是目標太軟。你給它一個軟目標，它就會用訓練分布裡最安全、最漂亮的方式把你糊弄過去。

還有，要先定義失敗條件，再讓模型生成。比如：

鞋底漂浮，失敗。
裙擺沒有接觸暗部，失敗。
衣服像貼圖，失敗。
包帶和手臂沒有遮擋關係，失敗。
給定服裝看不清，失敗。
只生成環境不生成人，失敗。

這比寫一堆「高品質、真實、自然」有效得多。

不懂攝影、繪圖和光影，AI 只會更快地犯錯

這也是我做這個專案之後一個很強烈的感受：想用好 AI，首先你必須對 AI 正在做的那個領域足夠熟。否則，你無法判斷 AI 的產物是否達標。一旦這樣的作品發出去，結果可想而知。

不要以為 AI 生圖的門檻是 prompt，其實不是。prompt 只是表達方式，真正起作用的是你有沒有能力判斷一張圖為什麼真，為什麼假，哪裡不符合攝影邏輯，哪裡不符合人體和服裝邏輯。

比如「光影真實」這四個字，模型聽不懂。你要能拆成更具體的問題：

主光從哪裡來？
鞋底接觸陰影落在哪個面上？
裙擺、襪口、包帶和手臂有沒有遮擋暗部？
背景裡的桌腳、鞋架、門把手、瓶罐有沒有同一光源下的影子？
頭髮是不是一整片假髮殼，還是有髮束、遮擋和局部暗部？
皮膚是不是塑膠磨皮，還是保留了毛孔、黑眼圈、鼻翼微紅和環境光影響？
衣服皺褶是不是來自肩袖、腰線、坐姿、包帶、重力和接觸，還是隨機雜訊？

不懂這些，Agent 就只能寫「真實、自然、高品質、手機隨手拍」。聽起來對，但生成出來大概率還是錯。

所以，我們後來把攝影、繪圖、光影、服裝材質這些專業知識都放進了輸入包和門禁裡。它們不只是審查標準，也要進入真正提交給生成器的 prompt。
這點很重要。如果專業知識只停留在「生成後挑圖」，那 AI 仍然是在亂抽。只有把專業知識前置到生成包裡，模型才有機會朝正確方向走。
這也是我現在對 AI 的一個基本判斷：AI 會降低執行成本，但不會取消領域知識的價值。恰恰相反，它會放大領域知識的差距。
一個懂攝影、懂繪圖、懂光影、懂內容平台的人，用 AI 是在加速生產。一個完全不懂這些東西的人，用 AI 只是更快地產出大量看起來完整、實際上經不起檢查的內容。
這件事放到程式碼裡也一樣。你不懂工程，AI 寫出程式碼你也不知道哪裡危險。你不懂內容，AI 生成圖文你也不知道哪裡假。你不懂平台，AI 寫出標題你也不知道為什麼沒有二跳訊號。
AI Native 不是把人變成按鈕操作員。真正的 AI Native，是把人的專業判斷拆成機器能執行、能檢查、能複用的流程。

朱雀不是玄學，真實相機鏈路才是關鍵

做公眾號圖片，繞不開 AI 味。我們內部有一個硬門禁：最終展示照和生活照必須過騰訊朱雀，檢測狀態為綠色，也就是 AI probability 小於 40%。
這個門禁一加上，很多看起來不錯的圖直接被淘汰。
這裡有個很有意思的現象：不是「穿搭題材」容易紅，也不是「人物一致」天然會紅。我們做過真實照片對照，真實捷運照、真實碎花裙照片、使用者 iPhone 原生照片都能過綠色，甚至隱私處理後仍然能保持很低的 AI 機率。
反過來，Codex 內建生成的乾淨人像，或者強角色設定稿風格的參考圖，經常會直接紅到 90% 以上。這給我們的啟發很大。
朱雀真正敏感的，不只是畫面裡有沒有美女，而是整張圖有沒有真實相機分布：曝光、雜訊、壓縮、白平衡、邊緣畸變、局部過曝、背景雜物、自然遮擋、動作瞬間、檔案鏈路。
所以我們的解決思路不是繼續堆「realistic」「8K」「high quality」。這些詞沒有用，甚至經常有反效果。
我們後來把低 AI 味拆成幾類可執行約束：

人物為什麼在這裡？
她正在做什麼？
誰在拍？
手機在哪個高度？
光從哪裡來？
哪些地方應該糊一點？
哪些生活瑕疵應該保留？
哪些背景細節說明這不是棚拍？

比如同樣是「出門前穿搭照」，我們不會只寫「真實手機照」。而會寫成：

同一位 22 歲的北京女程式員多肉，早上出門前站在出租屋門口，正在把水杯和門卡放進電腦 tote 包。朋友在胸口高度隨手拍到她低頭整理包的一瞬間。手機廣角，有輕微邊緣畸變，廉價頂燈混合窗邊弱光，牆面局部過曝。穿搭輪廓是視覺焦點，臉部不需要完美正臉。保留輕微黑眼圈、髮絲凌亂、針織毛邊、鞋面使用痕跡、桌上的線纜和門口鞋子不齊。
這段話看起來囉嗦，但它不是修辭。它是在描述這張照片是怎麼被拍到的。
這也是我們後來對「低 AI 味」的技術理解：不要用結果形容詞，要寫攝影事件。

測試驅動生產

如果你讓一個 Agent 負責從生成到驗收，它大概率會變成一個很會誇自己的員工。它會告訴你：圖像真實，人物一致，服裝展示清楚，適合發布。
但你一看圖，手指錯了，包帶斷了，腳沒有落地，臉跟上一張不像，場景像樣板間，評論入口也不存在。這不是某個模型的問題，而是職責設計的問題。
生產 Agent 天然傾向於讓任務繼續往前走。它剛生成完一批圖，很容易用語言把結果解釋成合格。所以我們後來把測試／品質門禁提高到了最高優先級。
它不是事後背書，而是全過程參與：

brief 階段，判斷目標是否清晰。
generation packet 階段，判斷輸入包有沒有填完整。
raw output 階段，判斷圖片類型、人物、衣服、場景、一眼假。
group candidate 階段，判斷同組人物、髮型、配飾、襪子、鞋子、光線是否連續。
final candidate 階段，判斷朱雀、隱私處理、營運風險和觀眾感受。

只要測試 Agent 判失敗，生產 Agent 必須返工。使用者喜歡、單張好看、朱雀綠色、隱私處理完成，都不能替代測試通過。
這個規則看起來有點反直覺。很多人會說，使用者都覺得好看了，為什麼還不能過？
原因很簡單：我們要做的是長期帳號資產，不是單張滿意圖。單張圖好看但人物漂移，會傷害帳號一致性。朱雀綠色但服裝不清楚，會傷害穿搭目標。圖片漂亮但標題沒有點擊理由，會傷害發布效果。

測試驅動生產的價值，就是阻止「主觀滿意」變成流程通行證。

上下文會污染生成

做 Agent 專案的人應該都遇到過類似問題：一個上下文聊久了，模型會把歷史裡無關的東西帶進當前任務。圖像生成裡這個問題更明顯。
你前面討論過海報，它可能把人物圖生成成海報。你前面討論過帳號策劃，它可能突然輸出一張設定頁。你前面看過失敗圖，它可能把失敗圖裡的構圖繼續帶進去。
所以我們把圖像生成也當作一個不可靠外部系統來管理。核心原則是：生成提示必須從 08-generation-packet.md 派生，而不是從長會話臨時拼接。
如果第一張輸出已經跨領域偏航，比如人物圖變成海報、UI、科普圖、無人物圖，立刻熔斷。不能在同一上下文裡繼續「再試一次」。
熔斷後要寫 09-generation-debug.md：

本次輸入包摘要是什麼？
實際輸出是什麼？
偏離類型是什麼？
是否疑似上下文污染？
下一步是新視窗隔離，還是補參考，還是明確授權 fallback？

這一步很重要。因為很多 AI 內容生產失敗，不是模型完全不會做，而是上下文已經髒了。你繼續改 prompt，只是在污染環境裡做隨機抽卡。
我們後來的做法是漸進披露：每個階段只讀必要資訊。生成前只讀本次 packet 和必要資產卡，門禁階段只讀候選圖和檢查表，發布包階段只讀通過門禁的作品和文案。歷史 runs 可以參考，但不能變成當前上下文的垃圾場。
這套思路其實和軟體工程裡的隔離很像。不要讓一個髒環境承擔生產任務。

貼圖不是發圖，是設計二跳訊號

回到公眾號貼圖本身。如果只從技術角度看，我們很容易沉迷生成品質。但貼圖內容能不能被推薦流繼續放大，還要看另一層：使用者有沒有理由點開、停留、評論、收藏。
這也是我們後來專門加貼圖增長門禁的原因。每篇貼圖進入發布包前，都要回答幾個問題：

首圖點擊理由是什麼？
目標人群和垂直標籤是什麼？
和近 7 天內容相比，資訊增量在哪裡？
評論觸發點是否安全且具體？
有沒有準備 3 條安全評論引子？
發布後 15/60/180 分鐘分別看什麼數據？
什麼情況下使用流量券，什麼情況下不救？

這裡面最重要的，不是學標題黨。恰恰相反，我們明確禁止搬運、洗稿、低俗擦邊、誘導私訊、無意義評論堆疊。
貼圖增長真正要解決的是：這張圖為什麼值得被推薦系統繼續測試。比如標題只是「粉紅上衣 + 牛仔短裙」，它就是服裝陳列。但標題如果是「上班穿粉紅會不會太學生氣」，使用者就能進入一個具體場景：公司氛圍、年齡感、通勤、同事眼光、自己的衣櫃。
這個差別不是文案技巧，而是內容結構。我們的技術思考是：Agent 不應該只生成圖片，還應該生成發布前的增長證據。
如果它說這篇適合發布，就必須給出首圖點擊理由、評論觸發點、差異化和復盤指標。否則就是空判斷。

最終我們怎麼組織這條生產線

現在這條線大概被拆成幾個角色。這不是為了顯得複雜，而是因為單 Agent 很難同時承擔「創造、執行、審查、營運、復盤」這些互相衝突的職責。
一個 Agent 既負責生產，又負責驗收，就會自證成功。一個 Agent 既負責圖片真實感，又負責增長判斷，就會把「圖好看」誤判成「適合發布」。一個 Agent 既負責長期帳號資產，又負責短期流量，就很容易為了點擊犧牲邊界。
所以我們更願意把它做成多 Agent 設計。
第一個是上下文 Agent。它負責當天背景：北京天氣、季節、通勤實用性、流行穿搭線索、可用場景建議。它不直接生成最終圖，只負責把當天語境補齊。
第二個是主生產 Agent。它負責寫生產計畫和 generation-packet.md。這裡最重要的是把目標寫死：固定模特，多肉，穿給定服裝，在已批准場景裡展示。不能漂移成海報、帳號策劃、泛日常或者無人物場景。
第三個是生成執行。生成只吃 packet，不吃長會話裡的隨口描述。輸出第一張就偏航，立刻熔斷，不盲目重試。
第四個是測試／品質門禁 Agent。它有最高否決權。它檢查人物、服裝、場景、光影、材質、手、鞋、包、朱雀、隱私和組圖連續性。沒有證據就沒有通過。
第五個是貼圖增長門禁。它檢查這篇內容有沒有推薦流二跳訊號：首圖、標題、評論點、差異化、關鍵詞、復盤指標。
第六個是發布包。只有通過前面門禁的作品，才能進入最終包。微信公眾號也只允許自動建立草稿，不替使用者點最終發布。

這就是我理解的 Agent Native 工程化。不是把一個大 prompt 寫得越來越長，也不是把所有任務都塞給一個超級 Agent，而是把人的專業流程拆成多個職責明確的 Agent：誰負責補上下文，誰負責生產，誰負責失敗熔斷，誰負責攝影和真實感門禁，誰負責貼圖增長，誰負責最終發布邊界。
每個 Agent 都有自己的輸入、輸出和否決條件。它們之間不是聊天接力，而是工程鏈路。
這套流程看起來很重。但它的目的不是把簡單事情複雜化，而是把不穩定的 AI 能力放進穩定系統裡。
以前我們靠感覺判斷「這張能不能發」。現在我們至少能說清楚：它在哪個門禁失敗，失敗原因是什麼，下次要改輸入包、場景、prompt、圖像策略還是增長結構。

這就是工程化的價值。