Codex + เครื่องมือลับอีกหนึ่งตัว คือเวิร์กโฟลว์การออกแบบที่เราใช้ในเอเจนซี่ของเรา... และผลลัพธ์ที่ได้นั้นแตกต่างในอีกระดับจริงๆ
ผมพูดแบบนี้มาหลายเดือนแล้ว ถ้าแอปของคุณดูเหมือน AI slop นั่นไม่ใช่ปัญหาของ Codex แต่เป็นปัญหาของเวิร์กโฟลว์ต่างหาก
นักพัฒนาส่วนใหญ่ติดอยู่ในลูปเดิม พวกเขาส่งฟีเจอร์ด้วย AI แบ็คเอนด์ใช้งานได้ ตรรกะแน่น แต่หน้าตากลับเหมือนแอปที่ถูกโค้ดแบบไร้ทิศทางทุกอัน ผู้ใช้ตัดสินใจในสองวินาทีว่ามันดูสมจริงหรือเปล่า
ทางแก้แบบเก่าคือจ้างนักออกแบบ รอเป็นอาทิตย์เพื่อให้ได้ไฟล์ Figma แล้วดูนักพัฒนาแปลความหมายจากดีไซน์นั้นแล้วสร้างใหม่ในโค้ด พอดีไซน์ออนไลน์จริง คุณก็เสียโมเมนตัมและเผาเงินที่ไม่จำเป็นต้องเผาไปแล้ว
กระบวนการทั้งหมดนั้นตอนนี้กลายเป็นทางเลือกแล้ว
สำหรับตัวอย่างนี้ ผมสร้าง Haven ซึ่งเป็นคอนเซ็ปต์แอปมือถืออสังหาริมทรัพย์ ระบบดีไซน์ทั้งหมดเสร็จใน 20 นาที ทุกหน้าจอออกแบบเสร็จในเวลาไม่ถึงหนึ่งชั่วโมง โค้ดสำหรับโปรดักชั่นถูกส่งผ่าน Codex โดยไม่ต้องเขียน CSS ซ้ำแม้แต่บรรทัดเดียว
นี่คือเวิร์กโฟลว์ที่ผมใช้อยู่ตอนนี้ และนักพัฒนาทุกคนที่ shipping ด้วย AI ต้องเข้าใจว่ามันทำงานยังไง
Moonchild คืออะไรกันแน่
เครื่องมือลับคือ Moonchild
ผมทดสอบเครื่องมือออกแบบ AI แทบทุกตัวที่เปิดตัวในปีที่แล้ว ส่วนใหญ่ดูดีในหน้าแรก แต่พังทันทีที่คุณสร้างหน้าที่สอง ปัญหาคือความสม่ำเสมอ Moonchild แก้ปัญหานี้ได้ในแบบที่ไม่มีเครื่องมืออื่นทำได้
มันคือแคนวาสออกแบบที่ขับเคลื่อนด้วยแชท ซึ่งเริ่มต้นจากระบบดีไซน์ของคุณ ไม่ใช่จากพรอมป์เปล่าๆ ไม่ใช่จากสกรีนช็อต แต่จากระบบจริงของคุณ คุณสามารถนำเข้าระบบของคุณได้สามวิธี:
→ นำเข้าจาก Figma, GitHub หรือ URL ที่ใช้งานจริง
→ อธิบายแบรนด์ของคุณให้ Agentic Design System Builder
→ วางแรงบันดาลใจในการออกแบบจาก Dribbble หรือที่อื่นๆ
เมื่อระบบนั้นเข้ามาแล้ว คุณจะไม่ใช้วิธีพรอมป์แบบเก่าเพื่อให้ได้ดีไซน์อีกต่อไป คุณวาง PRD มันจะสร้างหน้าจอเต็มตามระบบของคุณ จากนั้นคุณก็คุมทิศทางดีไซน์จากตรงนั้น
และเส้นทางการส่งออกคือสิ่งที่ปิดลูป Moonchild ส่ง MCP connector ที่ส่งดีไซน์ของคุณไปยัง Codex โดยตรงในรูปแบบ structured output ไม่ใช่สกรีนช็อตให้ Codex ตีความ แต่เป็นข้อมูลดีไซน์จริง คอมโพเนนต์ โทเคน เลย์เอาต์ ทุกอย่าง
นั่นคือเวิร์กโฟลว์ ตอนนี้มาดูวิธีใช้จริงกัน
ปัญหาของวิธีที่นักพัฒนาส่วนใหญ่ใช้ AI ในการออกแบบ
นี่คือสิ่งที่นักพัฒนาส่วนใหญ่ทำ
พวกเขาพรอมป์ให้ Codex สร้างฟีเจอร์ใหม่ มันส่งออกมา ดูโอเค แล้วพวกเขาก็พรอมป์ฟีเจอร์ถัดไป ดูต่างออกไปเล็กน้อย พอถึงฟีเจอร์ที่ห้า แอปก็ดูเหมือนผลิตภัณฑ์ห้าชนิดที่ถูกเย็บติดกัน
นี่คือสิ่งที่คนหมายถึงเวลาพูดว่าดีไซน์จาก AI ไม่ดี
โมเดลไม่ได้แย่ เวิร์กโฟลว์ต่างหากที่แย่
Codex ไม่รู้เลยว่าภาษาดีไซน์ของคุณคืออะไร ทุกพรอมป์คือบริบทใหม่ ทุกหน้าจอคือการเดา ทุกคอมโพเนนต์ลอยห่างจากอันก่อนหน้า สีเปลี่ยน ฟอนต์เปลี่ยน ทุกอย่างทับทวี
วิธีแก้ง่ายๆ ให้ Codex มีระบบที่ต้องทำตาม แล้วให้ดีไซน์จริงที่ต้องสร้าง
เวิร์กโฟลว์ส่วนใหญ่ให้อย่างใดอย่างหนึ่ง Moonchild รวมกับการเชื่อมต่อ MCP ให้ทั้งสองอย่างพร้อมกัน
ขั้นตอนที่ 1: สร้างระบบดีไซน์ของคุณก่อน เสมอ
นี่คือขั้นตอนที่ทุกคนข้าม และมันก็สำคัญที่สุด
ที่ @ignytlabs เราสร้างระบบดีไซน์ให้ลูกค้าทุกรายก่อนที่จะแตะหน้าจอใดๆ เมื่อก่อนใช้เวลานักออกแบบสองวัน ตอนนี้ Moonchild ทำในประมาณ 20 นาที
สำหรับตัวอย่างนี้ ผมสร้าง Haven คอนเซ็ปต์แอปมือถืออสังหาริมทรัพย์ มีหลายวิธีในการนำระบบดีไซน์เข้าไปใน Moonchild คุณสามารถนำเข้าจาก Figma, GitHub หรือ URL ที่ใช้งานจริง คุณสามารถอธิบายแบรนด์ของคุณให้ Agentic Design System Builder สำหรับ Haven ผมทำสิ่งที่ผมมักทำเมื่อเริ่มจากความรู้สึก แรงบันดาลใจในการออกแบบจาก Dribbble ผมวางสกรีนช็อตสามภาพของแอปอสังหาริมทรัพย์มือถือที่ให้ความรู้สึกที่ผมต้องการ และคำอธิบายสั้นๆ ว่า Haven คืออะไรและเหมาะกับใคร เครื่องมือดึงภาษาดีไซน์ออกมาและสร้างระบบตั้งแต่ต้น
สิ่งที่ทำให้ผมประหลาดใจคือทุกอย่างสามารถดูตัวอย่างได้ เครื่องมือ AI ส่วนใหญ่ รวมถึง Google Stitch workflow ที่ผมเขียนถึงในบทความก่อนหน้า ให้แค่ไฟล์โทเคนแบบเรียบ สี ฟอนต์ อาจจะมีการจัดระยะห่าง อันนี้ทำสิ่งที่แตกต่าง มันสร้างคลังคอมโพเนนต์เต็มรูปแบบและแกลเลอรี ทุก badge, button, card, และ chip แสดงผลตามที่มันจะดูในแอปของคุณจริงๆ คลิกที่คอมโพเนนต์ใดก็ได้ คุณจะเห็นมันจริง พร้อมตัวควบคุมเพื่อทดสอบรูปแบบและขนาด ใต้ตัวอย่างคุณจะได้ JavaScript, CSS, ตัวอย่าง และ dependencies สำหรับคอมโพเนนต์นั้น พร้อมดึงเข้าไปในโค้ดเบส
แกลเลอรีคือส่วนที่เปลี่ยนวิธีการออกแบบของคุณจริงๆ แทนที่จะเดาว่า "brand badge" หรือ "rating badge" ควรมีลักษณะอย่างไรในบริบท คุณจะเห็นทั้งหมดเรียงกัน ขาย ให้เช่, รายการเด่น ทั้งครอบครัวในคราวเดียว คุณตัดสินใจออกแบบอย่างมีข้อมูลก่อนที่หน้าจอแรกจะถูกสร้างขึ้น
นี่คือความแตกต่างระหว่างสไตล์ชีทกับระบบจริง
ขั้นตอนที่ 2: จาก PRD สู่ UI
เมื่อระบบดีไซน์ของคุณพร้อมแล้ว คุณจะไม่พรอมป์เพื่อให้ได้ดีไซน์ด้วยวิธีเก่า
คุณวาง PRD
สรุปฟีเจอร์หนึ่งหน้า ข้อกำหนดผลิตภัณฑ์ เป้าหมาย อะไรก็ได้ที่คุณมี
สำหรับ Haven ผมวาง PRD แบบมีโครงสร้างที่ครอบคลุมการแนะนำผลิตภัณฑ์ วัตถุประสงค์ ผู้ใช้และบทบาทเป้าหมาย ฟีเจอร์หลักและขอบเขต MVP เส้นทางการใช้งานผู้ใช้ทั้งหมด สแต็คเทคนิค และทิศทางการออกแบบ ประมาณหนึ่งหน้า เจาะจงพอที่จะให้เครื่องมือมีบริบทจริง มีโครงสร้างพอที่จะดึงรายละเอียดที่ถูกต้องไปยังหน้าจอที่ถูกต้อง
จากนั้นผมทำสิ่งที่คนส่วนใหญ่ข้าม
ผม brainstorm กับมันก่อนที่จะสร้างหน้าจอใดๆ
นี่คือจุดเปลี่ยนที่นักพัฒนาส่วนใหญ่พลาด โหมดแชทเก็บบริบท PRD ทั้งหมด แทนที่จะทิ้ง PRD แล้วกดสร้าง คุณพูดคุยเกี่ยวกับผลิตภัณฑ์ก่อน ยืนยันรายการหน้าจอ ล็อกรูปแบบการนำทาง กำหนดลำดับความสำคัญของหน้าจอหลักก่อนที่จะมีพิกเซลใดๆ
สำหรับ Haven ผมถาม:
→ "จาก PRD นี้ คุณแนะนำให้สร้างหน้าจอไหนก่อน มีอะไรที่ฉันพลาดไปสำหรับแอปอสังหาริมทรัพย์ไหม"
→ "การนำทางหลักควรเป็นแท็บด้านล่างที่มีหน้า Home, Search, Favorites, Profile หรืออย่างอื่น"
→ "ก่อนสร้าง ให้ฉันทราบลำดับความสำคัญของหน้าจอ Property Detail หน่อย รูปก่อน แล้วชื่อและราคา จากนั้นสเปก สิ่งอำนวยความสะดวก แล้วเอเย่นต์ ยืนยันหรือปรับปรุง"
→ "โอเค ตอนนี้ดำเนินการสร้างหน้าจอเหล่านี้ทั้งในโหมดสว่างและโหมดมืด โดยยึดตามระบบดีไซน์ที่ฉันมีอยู่ ตรวจสอบให้แน่ใจว่าคุณทำเส้นทางการใช้งานผู้ใช้ทั้งหมดเสร็จและสร้างทุกหน้าจอ"
เมื่อถึงเวลาที่ผมกดสร้าง เครื่องมือรู้จักผลิตภัณฑ์ดีกว่านักออกแบบส่วนใหญ่หลังจากการโทรหาลูกค้าครั้งแรกแล้ว
หมายเหตุสั้นๆ เรื่อง variants อ่านให้ดี
ฟีเจอร์เจ๋งอย่างหนึ่ง: คุณสามารถสร้าง variants ที่แตกต่างกันของหน้าจอ คุณแค่ต้องบอก Moonchild อย่างชัดเจน แล้วมันจะจัดการให้ สำหรับ Haven ผมต้องการทิศทางความสวยงามสามแบบที่แตกต่างกันสำหรับทั้งแอปก่อนที่จะเลือกแบบใดแบบหนึ่ง นี่คือพรอมป์ที่ผมใช้:
“ฉันต้องการให้คุณสร้างคอนเซ็ปต์การออกแบบ UI มือถือ 3 แบบที่สมบูรณ์สำหรับ Haven:
คอนเซ็ปต์ที่ 1 - Warm Editorial: พื้นหลังสีครีม ระยะห่างมากมาย หัวเรื่องแบบ serif สำหรับชื่อทรัพย์สิน เงานุ่ม การจัดภาพสไตล์นิตยสาร
คอนเซ็ปต์ที่ 2 - Bold Modern: โหมดมืด คอนทราสต์สูง sans-serif ตลอด มุมคม เน้นภาพแบบเต็มจรดขอบ
คอนเซ็ปต์ที่ 3 - Premium Minimal: จานสีกลาง (off-white, charcoal, single accent) ตัวอักษรประณีต พื้นที่ว่างมากมาย micro-interaction เล็กน้อย
ใช้ระบบดีไซน์ที่เชื่อมต่อเป็นพื้นฐาน แต่ให้แต่ละคอนเซ็ปต์ดึงระบบไปในทิศทางที่แตกต่างกัน สร้างหน้าจอเต็ม ไม่ใช่แค่ส่วน คุณจะทำอย่างไร”
สังเกต "คุณจะทำอย่างไร" ตอนท้าย นั่นคือรายละเอียดเล็กๆ ที่ทำให้สิ่งนี้ใช้งานได้ แทนที่จะสร้างทุกอย่างแบบสุ่มสี่สุ่มห้า เครื่องมือกลับมาพร้อมแผน
มันบอกว่าจะสร้างหน้าจอตัวแทน 5 หน้าต่อคอนเซ็ปต์ก่อน ผมจะตรวจสอบสามทิศทางเคียงข้างกัน เมื่อผมเลือกแบบที่ต้องการ มันก็จะออกแบบทั้งแอปในทิศทางนั้น
นั่นเปลี่ยนสมการต้นทุนอย่างสิ้นเชิง คุณไม่ได้จ่ายเพื่อสร้างทั้งสามแบบเต็ม คุณจ่ายเพื่อตัวอย่างสามแบบรวดเร็ว จากนั้นสร้างแบบเต็มในทิศทางที่คุณเลือกจริงๆ
ผมเลือกแบบ Warm Editorial ชุดหน้าจอเต็มกลับมาในครั้งถัดไป
ตอนนี้ส่วนที่ทำให้ผมประหลาดใจจริงๆ
ทุกหน้าจอที่ Moonchild สร้างสามารถโต้ตอบได้ในโหมดพรีวิว ไม่ใช่ mockup นิ่ง แต่สามารถโต้ตอบได้จริง
คุณสามารถคลิกเข้าไปในช่องกรอกข้อมูล กดปุ่ม เคลื่อนที่ระหว่างหน้าจอเหมือนผู้ใช้จริงที่ทดสอบต้นแบบก่อนที่จะเขียนโค้ดใดๆ สำหรับ Haven ผมพบปัญหาการไหลสองอย่างในพรีวิวที่อาจจะถูกส่งไปยัง Codex ถ้าไม่ได้พรีวิว หน้าจอรายละเอียดทรัพย์สินไม่มีทางกลับไปยังหน้ารวมที่ชัดเจน ปุ่ม CTA ติดต่อเอเย่นต์อยู่ต่ำเกินไป ทั้งสองอย่างอาจถูกส่งไปถ้าผมส่งดีไซน์ให้ Codex โดยไม่คลิกผ่านก่อน
นั่นคือจุดเปลี่ยน คุณทดสอบผลิตภัณฑ์ก่อนที่จะเขียนโค้ดใดๆ
ลูปการปรับแต่งคือส่วนสุดท้าย
เมื่อหน้าจอต้องการการปรับปรุง คุณไม่ต้องพรอมป์ใหม่ตั้งแต่ต้น คุณเลือกหน้าจอ บอกเครื่องมือว่าต้องการเปลี่ยนอะไร แล้วมันจะสร้าง v2 ในที่นั้น ต้องการ hero ที่ดูเหมือนภาพยนตร์มากขึ้น? v2 ต้องการเปลี่ยนเค้าโครง card เป็น list view? v3 variants จะซ้อนกันเพื่อให้คุณเปรียบเทียบและเลือกแบบที่ดีที่สุด
สำหรับหน้าจอรายละเอียดทรัพย์สินของ Haven ผมผ่านสามครั้ง รอบแรกบล็อกเอเย่นต์สูงเกินไป v2 แก้ลำดับความสำคัญได้แต่แกลเลอรีรูปภาพดูเล็ก v3 ถูกต้องทั้งสองอย่าง ใช้เวลาประมาณ 8 นาทีในการปรับเปลี่ยน
คุณไม่ได้คัดสรรจากกระดานว่างเปล่า คุณกำลังปรับแต่งทิศทางที่แท้จริง นี่คือส่วนที่ใกล้เคียงที่สุดกับการทำงานกับนักออกแบบอาวุโส
ขั้นตอนที่ 3: เชื่อมต่อ Moonchild กับ Codex ผ่าน MCP
นี่คือจุดที่เวิร์กโฟลว์เจ๋งสุดๆ
ระบบดีไซน์ให้กฎแก่ Codex การเชื่อมต่อ MCP ให้สิ่งที่ทรงพลังกว่าแก่ Codex: การเข้าถึงโดยตรงไปยังผลลัพธ์การออกแบบจริง ไม่ใช่สกรีนช็อต ไม่ใช่คำอธิบายข้อความของดีไซน์ แต่เป็นข้อมูลดีไซน์แบบมีโครงสร้างที่ Codex สามารถอ่านและสร้างใหม่ได้
นี่คือการตั้งค่า:
→ ไปที่ Moonchild Settings จากนั้น MCP
→ คัดลอกคำสั่งติดตั้งสำหรับการตั้งค่าของคุณ
→ เปิด Codex CLI
→ วางคำสั่งติดตั้ง
→ ยืนยันตัวตนด้วยบัญชี Moonchild ของคุณ
→ เสร็จ
เมื่อเชื่อมต่อแล้ว Codex จะเห็นทั้งระบบดีไซน์ของคุณและหน้าจอ Haven เฉพาะที่คุณออกแบบ
ขั้นตอนที่ 4: Codex ส่งโค้ด
ตอนนี้คุณพรอมป์ Codex แบบนี้:
ดึงโปรเจกต์ Haven Real Estate Mobile App โดยใช้ Moonchild MCP และแจ้งให้ฉันทราบว่ามีหน้าจออะไรบ้างในนั้น
พรอมป์แรกนี้ทำงานสองอย่าง: ยืนยันว่า MCP เชื่อมต่อถูกต้อง และให้ Codex มองเห็นทุกหน้าจอที่คุณออกแบบอย่างเต็มที่
เคล็ดลับด่วนก่อนที่คุณจะให้ Codex ทำอะไรที่หนักกว่านี้ อยู่ในโหมดวางแผน Codex จะแสดงสิ่งที่มันกำลังจะทำก่อนดำเนินการ อ่านแผนทุกครั้ง ตรวจสอบให้แน่ใจว่ามันเข้าใจว่าคุณต้องการหน้าจอไหน ลำดับไหน และความละเอียดเท่าไหร่ นี่คือความแตกต่างระหว่าง Codex ที่เขียนโค้ดตามที่คุณต้องการจริงๆ กับ Codex ที่เขียนโค้ดตามที่มันคิดว่าคุณต้องการ
เมื่อคุณตรวจสอบแผนแล้วและชี้ไปยังหน้าจอที่ต้องการ Codex ดึงข้อมูลดีไซน์จาก Moonchild โดยตรง อ้างอิงระบบดีไซน์ของคุณ และเขียนโค้ด มันยังเพิ่ม hover states, transitions, และการจัดการกรณีขอบ เพราะมันทำงานจากข้อมูลดีไซน์จริงแทนที่จะเดาจากพรอมป์
ผลลัพธ์: UI ระดับโปรดักชั่นในโค้ดเบสจริงของคุณ ตรงกับดีไซน์ทุกประการ ในเวลาไม่กี่นาที
ที่ @ignytlabs เราเคยจัดสรรเวลาสองสัปดาห์สำหรับการออกแบบในทุก MVP ของลูกค้า นักออกแบบจะสร้างไฟล์ Figma นักพัฒนาจะตีความมัน การตีความจะคลาดเคลื่อน เราจะแก้ไข วนไปมา ด้วยเวิร์กโฟลว์นี้ ทั้งลูปยุบเหลือแค่ช่วงบ่ายเดียวของการทำงาน คุณภาพเท่าเดิม อัตรากำไรสูงขึ้น สลับบริบทน้อยลงมาก
เมื่อใดควรใช้เวิร์กโฟลว์นี้
นี่ไม่ใช่เวิร์กโฟลว์ที่เหมาะสำหรับทุกทีม จงซื่อสัตย์ว่าเมื่อไรมันเหมาะสม
ใช้เมื่อ:
→ คุณกำลังส่ง MVP ในฐานะผู้สร้างคนเดียวหรือทีมเล็ก
→ ความสม่ำเสมอของดีไซน์พังทลายระหว่างหน้าจอ
→ คุณไม่ต้องการรักษาไปป์ไลน์แยก Figma สู่ดีไซเนอร์สู่ดีเวลลอปเปอร์
→ คุณมีระบบดีไซน์อยู่แล้วและต้องการให้มันถูกนำไปใช้ทุกที่
ข้ามไปเมื่อ:
→ คุณอยู่ในระดับใหญ่ที่มีทีมออกแบบใน-house เต็มรูปแบบและคลัง Figma ที่โตเต็มที่
→ คุณต้องการส่งมอบที่สมบูรณ์แบบระดับพิกเซลสำหรับไซต์การตลาดหรืองานแบรนด์ที่ทุกเงามีความสำคัญ
→ โค้ดเบสของคุณมีรูปแบบ UI ที่ปรับแต่งสูงซึ่งต้องการงานออกแบบเฉพาะ
สำหรับนักพัฒนา 80% ที่ส่ง MVP และผลิตภัณฑ์ SaaS เวิร์กโฟลว์นี้ครอบคลุมทุกสิ่งที่คุณต้องการ
สิ่งที่ควรระวัง
ข้อเท็จจริงที่ซื่อสัตย์สองสามข้อก่อนที่คุณจะเริ่มใช้
คุณภาพของระบบดีไซน์ของคุณกำหนดคุณภาพของผลลัพธ์ ขยะเข้าก็ขยะออก ไฟล์ Figma ที่ทำครึ่งๆ กลางๆ มีโทเคนสีสามสีจะสร้างหน้าจอที่ mediocre ใช้เวลากับระบบตั้งแต่แรก มันจะให้ผลตอบแทนในทุกหน้าจอ
คุณภาพของ PRD มีความสำคัญ บรีฟที่คลุมเครือทำให้ได้หน้าจอทั่วไป PRD ที่เฉพาะเจาะจงพร้อมเส้นทางการใช้งานผู้ใช้ กรณีขอบ และลำดับความสำคัญที่ชัดเจนจะทำให้ได้ดีไซน์ที่มีประโยชน์ นี่ไม่ใช่ข้อจำกัดของเครื่องมือ มันเป็นข้อจำกัดของความคิด
คุณยังต้องมีรสนิยม เครื่องมือสร้าง คุณเป็นผู้กำกับ การเลือก variant ที่ถูกต้องและปรับแต่งมันคือที่ที่การตัดสินใจของคุณอยู่ ถ้าคุณข้ามขั้นตอนการคัดสรร คุณก็กลับไปออกแบบแบบไร้ทิศทาง
บางคอมโพเนนต์ต้องการการปรับแต่งด้วยมือ สถานะแอนิเมชันที่ซับซ้อน รูปแบบการโต้ตอบแบบกำหนดเอง อะไรก็ตามที่นอกเหนือระบบดีไซน์ต้องการการปรับแต่งด้วยตนเองใน Codex MCP พาคุณไปถึง 90% ที่เหลือ 10% คือรสนิยมของคุณ
นี่หมายถึงอะไรจริงๆ
นี่คือความเห็นที่ตรงไปตรงมาของผม
คอขวดในการ shipping ผลิตภัณฑ์ที่สร้างด้วย AI ไม่เคยอยู่ที่โค้ด AI เขียนโค้ดได้ คอขวดอยู่ที่เลเยอร์การออกแบบเสมอ ความสม่ำเสมอ รสนิยม ระบบที่เชื่อมทุกอย่างเข้าด้วยกัน
คอขวดนั้นเพิ่งจะพังทลาย
ที่เอเจนซี่ของเรา เราเคยจัดสรรเวลาสองสัปดาห์สำหรับการออกแบบในทุก MVP ของลูกค้า จ้างนักออกแบบ รอไฟล์ Figma ดูนักพัฒนาตีความมัน วนไปมา สิ่งที่เคยใช้เวลาสองสัปดาห์ตอนนี้ใช้เวลาสองวัน คุณภาพเท่าเดิม การส่งมอบเร็วขึ้น อัตรากำไรสูงขึ้น
นี่คือเวิร์กโฟลว์ที่ทีมที่มีทุนมีอยู่แล้วกับไปป์ไลน์ Figma + ดีไซเนอร์ + ดีเวลลอปเปอร์ ความแตกต่างคือตอนนี้ผู้สร้างเดี่ยว เอเจนซี่อิสระ และสตูดิโอเล็กๆ ได้รับอานิสงส์เดียวกันโดยไม่ต้องมีพนักงานประจำ
ปี 2026 จะไม่ยุติธรรมสำหรับเอเจนซี่และนักพัฒนาที่เข้าใจสิ่งนี้ก่อน
TLDR
→ หยุดโทษ Codex สำหรับ UI ที่แย่ Codex ไม่ใช่ปัญหา เวิร์กโฟลว์ของคุณต่างหากคือปัญหา
→ ขั้นตอนที่ 1: สร้างระบบดีไซน์ของคุณภายใน Moonchild นำเข้าจาก Figma, GitHub หรือ URL ที่ใช้งานจริง หรืออธิบายแบรนด์ของคุณ หรือวางแรงบันดาลใจจาก Dribbble อย่างที่ผมทำกับ Haven
→ ขั้นตอนที่ 2: วาง PRD ของคุณ brainstorm ในโหมดแชทก่อนสร้าง ล็อกรายการหน้าจอและรูปแบบการนำทางก่อน
→ ค่าเริ่มต้นสร้าง variant เดียว ขอหลาย variant อย่างชัดเจนบนหน้าจอ hero โดยระบุความรู้สึกที่แตกต่างกัน
→ ใช้พรีวิวแบบโต้ตอบเพื่อทดสอบการไหลก่อนที่จะเขียนโค้ดใดๆ ปรับแต่งหน้าจอด้วย v2, v3 ตามลำดับ
→ ขั้นตอนที่ 3: เชื่อมต่อ Moonchild กับ Codex ผ่าน MCP นี่ทำให้ Codex มีข้อมูลดีไซน์จริง ไม่ใช่สกรีนช็อต
→ ขั้นตอนที่ 4: พรอมป์ Codex ให้สร้างแต่ละหน้าจอโดยใช้ MCP UI ระดับโปรดักชั่นถูกส่งในไม่กี่นาที
→ คุณภาพของระบบดีไซน์ของคุณกำหนดคุณภาพของผลลัพธ์ ลงทุนที่นั่น
→ วงจร Figma สู่ส่งมอบสู่ดีเวลลอปเปอร์ตายแล้ว เวิร์กโฟลว์เดียวตอนนี้รันทั้งดีไซน์และโค้ดไปด้วยกัน
LFG.
