เปลี่ยนภาพหน้าจอเป็นโค้ดด้วย Qwen 3.7 Plus

ส่งภาพหน้าจอ UI ให้ Qwen 3.7 Plus แล้วมันจะสามารถเขียนโค้ดส่วนหน้าเพื่อสร้างใหม่ได้ โมเดลจะอ่านภาพและโค้ดไปพร้อมกัน ดังนั้น ภาพจำลองการออกแบบ หน้าเพจของคู่แข่ง หรือไฟล์ที่ส่งออกจาก Figma จึงสามารถกลายเป็นคอมโพเนนต์ React หรือ HTML เริ่มต้นได้ในการเรียกใช้เพียงครั้งเดียว คู่มือนี้จะแสดงขั้นตอนการทำงานและวิธีที่จะได้ผลลัพธ์ที่คุณสามารถนำไปใช้งานจริงได้

เราจะครอบคลุมการเรียกใช้พื้นฐาน รายละเอียดของพรอมต์ที่สำคัญ การวนซ้ำการตอบสนองด้วยภาพเพื่อความแม่นยำระดับพิกเซล และวิธีเปลี่ยน UI ที่สร้างขึ้นให้เป็นแอปที่ใช้งานได้จริง สำหรับข้อมูลพื้นฐานของโมเดล โปรดดูที่ ภาพรวม Qwen 3.7 Plus ของเรา และสำหรับรูปแบบคำขอ โปรดดูที่ คู่มือ API ของ Qwen 3.7 Plus คุณจะได้ทดสอบ API และเอนด์พอยต์ที่ UI ของคุณเรียกใช้ใน Apidog ตลอดกระบวนการ

button

สรุปสั้นๆ (TL;DR)

ส่งภาพหน้าจอพร้อมพรอมต์ที่แม่นยำไปยัง Qwen 3.7 Plus และขอโค้ดในเฟรมเวิร์กเป้าหมายของคุณ การดำเนินการครั้งแรกจะช่วยให้คุณเข้าใกล้เป้าหมาย; คุณสามารถปรับปรุงได้โดยการเรนเดอร์ผลลัพธ์ ถ่ายภาพหน้าจอ และขอให้โมเดลแก้ไขความแตกต่างจากต้นฉบับ Qwen 3.7 Plus เหมาะสมกับงานนี้เพราะมันมีความสามารถด้านวิสัยทัศน์ที่แข็งแกร่งควบคู่กับการเขียนโค้ดที่เชื่อถือได้ รองรับบริบทขนาด 1 ล้านโทเค็นสำหรับการออกแบบขนาดใหญ่ และมีค่าใช้จ่ายต่อการเรียกใช้งานที่ต่ำ งานหลักอยู่ที่พรอมต์และการวนซ้ำ ไม่ใช่ที่ API

ทำไมต้องใช้ Qwen 3.7 Plus สำหรับสิ่งนี้

การแปลงภาพหน้าจอเป็นโค้ดต้องใช้สองสิ่งพร้อมกัน: อ่านภาพได้อย่างแม่นยำ แล้วเขียนโค้ดที่ถูกต้อง Qwen 3.7 Plus ทำคะแนนได้ประมาณ 60% บน SWE-Bench Pro และ 70.3 บน Terminal-Bench ดังนั้นความสามารถในการเขียนโค้ดจึงเชื่อถือได้ และวิสัยทัศน์ของมันก็สามารถจัดการกับเลย์เอาต์ UI ที่ซับซ้อนได้ บริบทขนาด 1 ล้านโทเค็นช่วยให้คุณสามารถส่งดีไซน์ที่สูงและมีความละเอียดสูงได้โดยไม่มีการตัดทอน และด้วยค่าใช้จ่าย $0.40 ต่อล้านโทเค็นสำหรับการป้อนข้อมูล คุณสามารถวนซ้ำได้ในราคาถูก สำหรับงานที่คล้ายกันในรูปแบบของ Agent ซึ่งเป็นการขับเคลื่อน UI แทนที่จะสร้างใหม่ โปรดดู คู่มือ Agent สำหรับการใช้งานคอมพิวเตอร์ ของเรา

การเรียกใช้งานพื้นฐาน

ส่งรูปภาพเป็นส่วนของ image_url พร้อมกับคำสั่งที่เป็นข้อความ นี่คือตัวสร้างขั้นต่ำ:

import os, base64
from openai import OpenAI

client = OpenAI(
    api_key=os.environ["DASHSCOPE_API_KEY"],
    base_url="https://dashscope-intl.aliyuncs.com/compatible-mode/v1",
)

def screenshot_to_code(png_path, prompt):
    b64 = base64.b64encode(open(png_path, "rb").read()).decode()
    resp = client.chat.completions.create(
        model="qwen3.7-plus",
        messages=[{
            "role": "user",
            "content": [
                {"type": "text", "text": prompt},
                {"type": "image_url",
                 "image_url": {"url": f"data:image/png;base64,{b64}"}},
            ],
        }],
    )
    return resp.choices[0].message.content

print(screenshot_to_code("mockup.png", "Rebuild this UI as a React component."))

ยืนยัน ID โมเดลปัจจุบันใน เอกสาร Model Studio ก่อนนำไปใช้งาน การดำเนินการข้างต้นนั้นได้ผล แต่พรอมต์เพียงบรรทัดเดียวก็ให้ผลลัพธ์ที่มีคุณภาพเพียงบรรทัดเดียว คุณภาพของงานขึ้นอยู่กับพรอมต์

การเขียนพรอมต์ที่ให้โค้ดที่สามารถนำไปใช้งานได้

พรอมต์ที่คลุมเครือจะสร้างมาร์กอัปทั่วไป โปรดระบุรายละเอียดเกี่ยวกับสแต็กและข้อจำกัดให้ชัดเจน:

แปลงภาพหน้าจอ UI นี้ให้เป็นคอมโพเนนต์ React เดี่ยวโดยใช้ Tailwind CSS
ข้อกำหนด:
- จัดเรียงเค้าโครง ระยะห่าง และชุดสีให้ใกล้เคียงที่สุดเท่าที่จะทำได้
- ทำให้ตอบสนองต่อขนาดหน้าจอมือถือที่ 375px
- ใช้ HTML เชิงความหมายและป้ายกำกับที่เข้าถึงได้สำหรับอินพุตและปุ่ม
- ใช้ข้อมูลตัวยึดตำแหน่งในส่วนที่ภาพหน้าจอแสดงเนื้อหาแบบไดนามิก
- ส่งคืนเฉพาะโค้ดคอมโพเนนต์เท่านั้น ไม่ต้องมีคำอธิบายเพิ่มเติม

ระบุเฟรมเวิร์ก ระบบการจัดสไตล์ จุดหยุด (breakpoints) และมาตรฐานการเข้าถึง บอกให้โมเดลจัดการกับเนื้อหาแบบไดนามิกอย่างไรเพื่อที่มันจะได้ไม่ต้องสร้างแบ็กเอนด์ขึ้นมาเอง เอกสาร Tailwind CSS เป็นแหล่งอ้างอิงที่ดีสำหรับคลาสยูทิลิตีที่จะถูกสร้างขึ้น หากคุณให้ข้อมูลจำเพาะของคอมโพเนนต์หรือคำแนะนำการออกแบบสั้นๆ โมเดลจะสร้างผลลัพธ์ที่ใกล้เคียงยิ่งขึ้น บทความของเราเกี่ยวกับ สิ่งที่ design.md มีผลต่อ Agent การเขียนโค้ด อธิบายว่าทำไมข้อมูลจำเพาะที่เป็นลายลักษณ์อักษรจึงเปลี่ยนผลลัพธ์ได้

ปิดช่องว่างด้วยการวนซ้ำการตอบสนองด้วยภาพ

การดำเนินการครั้งแรกมักจะไม่สามารถกำหนดระยะห่างและสีได้อย่างแม่นยำ นี่คือจุดที่วิสัยทัศน์ของ Qwen 3.7 Plus มีประโยชน์เป็นครั้งที่สอง เรนเดอร์คอมโพเนนต์ที่สร้างขึ้น ถ่ายภาพหน้าจอ แล้วส่งภาพทั้งสองกลับไป และขอให้โมเดลแก้ไขความแตกต่าง:

นี่คือการออกแบบเป้าหมาย (ภาพที่ 1) และการเรนเดอร์ปัจจุบันของฉัน (ภาพที่ 2)
แสดงรายการความแตกต่างทางภาพ จากนั้นส่งคืนโค้ดคอมโพเนนต์ที่แก้ไขแล้ว
ซึ่งตรงกับภาพที่ 1 มากขึ้น

การวนซ้ำสองหรือสามรอบนี้มักจะได้ผลลัพธ์ที่แทบจะแยกไม่ออกจากต้นฉบับ มันเป็นแนวคิดเดียวกันของการรับรู้และแก้ไขที่อยู่เบื้องหลัง Agent สำหรับการใช้งานคอมพิวเตอร์ ซึ่งนำมาประยุกต์ใช้กับโค้ดแทนการคลิก

การจัดการกับการออกแบบจริง

แบบจำลองการผลิตมีขนาดใหญ่และมีรายละเอียด ซึ่งมีผลกระทบสองประการ:

ค่าใช้จ่ายโทเค็น รูปภาพแบบเต็มหน้าจอที่มีความละเอียดสูงอาจใช้โทเค็นหลายพันรายการ ปรับขนาดลงให้เล็กที่สุดเท่าที่จะอ่านข้อความในการออกแบบได้ และตัดภาพให้เหลือเฉพาะส่วนที่คุณกำลังสร้าง
ขอบเขต อย่าขอให้สร้างแดชบอร์ดทั้งหมดในการเรียกใช้ครั้งเดียว แบ่งหน้าออกเป็นส่วนๆ เช่น ส่วนหัว แถบด้านข้าง ตาราง และสร้างแต่ละส่วนแยกกัน จากนั้นนำมารวมกัน บริบท 1M โทเค็นช่วยได้ แต่การขอในส่วนที่เล็กลงจะสร้างโค้ดที่สะอาดกว่า

การได้ผลลัพธ์ที่ดีขึ้น

การปรับแต่งพรอมต์เล็กน้อยสามารถแก้ไขปัญหาที่พบบ่อยที่สุดได้:

สีผิดพลาด โมเดลจะประมาณค่าเฉดสี วางค่า hex ที่แน่นอนจากการออกแบบของคุณและบอกให้มันใช้ค่านั้น
ไอคอนที่สร้างขึ้นเอง โมเดลจะเดารูปร่างของไอคอน ระบุชุดไอคอน เช่น Lucide หรือ Heroicons และขอให้มันใช้คอมโพเนนต์เหล่านั้น
ข้อความที่สร้างขึ้นเอง หากมันเติมข้อความที่ดูเหมือนจริง ให้บอกให้มันใช้เนื้อหาตัวยึดตำแหน่งที่ทำเครื่องหมายไว้อย่างชัดเจนแทน
Div ที่ซับซ้อนเกินไป ขอให้ใช้องค์ประกอบเชิงความหมายและโครงสร้างที่เรียบง่ายอย่างชัดเจน มิฉะนั้นมันมักจะซ้อน wrapper div มากเกินไป

แต่ละข้อเป็นการเพิ่มพรอมต์เพียงบรรทัดเดียว และเมื่อรวมกันแล้วจะช่วยลดรอบการปรับแต่งของคุณได้อย่างเห็นได้ชัด

จาก UI สู่แอปที่ใช้งานได้จริง

โค้ดส่วนหน้าที่สร้างขึ้นเป็นเพียงครึ่งหนึ่งของฟีเจอร์ คอมโพเนนต์จะดึงข้อมูล ส่งแบบฟอร์ม และเรียกใช้เอนด์พอยต์ที่ต้องมีอยู่และทำงานได้ นั่นคือจุดที่ทางลัดการแปลงภาพหน้าจอเป็นโค้ดมาบรรจบกับวิศวกรรมจริง

ออกแบบเอนด์พอยต์เหล่านั้นก่อน แล้ว UI ที่สร้างขึ้นก็จะมีบางอย่างที่มั่นคงสำหรับพูดคุยด้วย Apidog ช่วยให้คุณสามารถกำหนดสัญญา API, จำลอง (mock) มันเพื่อให้คอมโพเนนต์ใหม่เรนเดอร์ด้วยข้อมูลที่สมจริงได้ทันที และทดสอบการตอบสนองก่อนที่จะสร้างแบ็กเอนด์ คู่มือโหมด spec-first ของเราจะอธิบายขั้นตอนดังกล่าว และแนวทางนี้เข้ากันได้ดีกับส่วนหน้า (front ends) ที่สร้างด้วย AI เช่นเดียวกับ API ที่สร้างใน Cursor

ดาวน์โหลด Apidog เพื่อจำลองและทดสอบ API ที่อยู่เบื้องหลัง UI ที่ Qwen 3.7 Plus สร้างขึ้น

คำถามที่พบบ่อย (FAQ)

Qwen 3.7 Plus สามารถกำหนดเป้าหมายเฟรมเวิร์กใดได้บ้าง? สิ่งที่คุณระบุในพรอมต์: React, Vue, Svelte, HTML และ CSS ธรรมดา, Tailwind หรือไลบรารีคอมโพเนนต์ โปรดระบุให้ชัดเจน เนื่องจากค่าเริ่มต้นคือมาร์กอัปทั่วไป

ความแม่นยำของการดำเนินการครั้งแรกเป็นอย่างไร? ใกล้เคียงในโครงสร้าง แต่คร่าวๆ ในเรื่องระยะห่างและสีที่แน่นอน การวนซ้ำการตอบสนองด้วยภาพ การเรนเดอร์และส่งซ้ำ คือสิ่งที่ทำให้ได้ความแม่นยำใกล้เคียงระดับพิกเซล

สามารถทำงานจากการออกแบบใน Figma ได้หรือไม่? ได้ หากคุณส่งออกเฟรมเป็นรูปภาพ โมเดลจะอ่านการออกแบบที่เรนเดอร์แล้ว ไม่ใช่ไฟล์ Figma เอง

ฉันจะรักษาค่าใช้จ่ายโทเค็นให้ต่ำได้อย่างไร? ปรับขนาดรูปภาพให้เล็กลงจนสามารถอ่านได้ ตัดภาพให้เหลือเฉพาะส่วนที่คุณกำลังสร้าง และสร้างหน้าทีละส่วนแทนที่จะสร้างทั้งหมดพร้อมกัน

มันสร้างแบ็กเอนด์ด้วยหรือไม่? ไม่ มันสร้างโค้ดส่วนหน้าที่คาดหวัง API ออกแบบและจำลอง API เหล่านั้นแยกต่างหาก ซึ่งเป็นส่วนที่ Apidog จัดการ

สรุป

การแปลงภาพหน้าจอเป็นโค้ดด้วย Qwen 3.7 Plus นั้นประกอบด้วยพรอมต์ที่แม่นยำ การเรียกใช้แบบหลายโมดอลที่ประหยัด และการวนซ้ำการตอบสนองด้วยภาพที่รวดเร็ว มันช่วยให้คุณได้คอมโพเนนต์ที่ใช้งานได้รวดเร็ว แต่ UI ยังคงต้องการ API ที่แท้จริงอยู่เบื้องหลัง สร้างส่วนหน้าด้วย Qwen 3.7 Plus จากนั้นออกแบบ จำลอง และทดสอบเอนด์พอยต์ใน Apidog เพื่อให้ฟีเจอร์ที่สมบูรณ์ทำงานร่วมกันได้อย่างลงตัว

button