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

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

ลองใช้ Apidog วันนี้

เราจะโฟกัสที่ขั้นตอนปฏิบัติ: วิธีส่งภาพเข้าโมเดล วิธีบังคับรูปแบบโค้ด วิธีปรับผลลัพธ์ให้ใกล้ต้นฉบับ และวิธีเปลี่ยน component ที่ได้ให้เป็นส่วนหนึ่งของแอปจริง หากต้องการพื้นฐานของโมเดล อ่านต่อได้ที่ ภาพรวม Qwen 3.7 Plus และหากต้องการรายละเอียด request format ดู คู่มือ API ของ Qwen 3.7 Plus ระหว่างพัฒนา คุณสามารถใช้ Apidog เพื่อออกแบบ mock และทดสอบ API ที่ UI เรียกใช้ได้

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

Workflow หลักคือ:

1. ส่งภาพหน้าจอพร้อมพรอมต์ที่ระบุ stack ชัดเจน
2. ให้ Qwen 3.7 Plus สร้างโค้ด UI เช่น React + Tailwind
3. Render โค้ดที่ได้แล้วถ่ายภาพหน้าจอผลลัพธ์
4. ส่งภาพต้นฉบับกับภาพ render กลับไปให้โมเดลเปรียบเทียบ
5. ให้โมเดลแก้ layout, spacing, สี และรายละเอียด UI
6. เชื่อม component กับ API จริงหรือ mock API

Qwen 3.7 Plus เหมาะกับงานนี้เพราะรวมความสามารถด้าน vision และ coding ไว้ด้วยกัน รองรับบริบทขนาดใหญ่ 1 ล้านโทเค็น และมีต้นทุนต่อการเรียกใช้งานต่ำ งานสำคัญไม่ได้อยู่ที่ API call แต่อยู่ที่พรอมต์และการวนซ้ำผลลัพธ์ให้แม่นขึ้น

ทำไมต้องใช้ Qwen 3.7 Plus สำหรับงาน Screenshot-to-Code

การแปลงภาพหน้าจอเป็นโค้ดต้องทำสองอย่างพร้อมกัน:

• อ่านองค์ประกอบภาพ เช่น layout, spacing, สี, typography, hierarchy
• เขียนโค้ดที่ใช้งานได้ใน framework ที่ต้องการ

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

หากต้องการใช้โมเดลในลักษณะ Agent เพื่อควบคุม UI แทนการสร้างโค้ดใหม่ ดู คู่มือ Agent สำหรับการใช้งานคอมพิวเตอร์

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

ส่งภาพเป็น image_url พร้อมข้อความพรอมต์ ตัวอย่างด้านล่างใช้ OpenAI-compatible API ของ DashScope:

import os
import 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):
    with open(png_path, "rb") as f:
        b64 = base64.b64encode(f.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

prompt = "Rebuild this UI as a React component."

print(screenshot_to_code("mockup.png", prompt))

ก่อนนำไปใช้จริง ให้ตรวจสอบ model ID ปัจจุบันจาก เอกสาร Model Studio

โค้ดนี้เพียงพอสำหรับเริ่มต้น แต่พรอมต์สั้นแบบ Rebuild this UI มักได้ผลลัพธ์กว้างเกินไป หากต้องการโค้ดที่นำไปใช้ได้จริง ควรระบุ stack, constraint และ output format ให้ชัดเจน

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

พรอมต์ที่ดีควรบอกอย่างน้อย 5 อย่าง:

• framework ที่ต้องการ
• วิธีจัด style
• responsive breakpoint
• accessibility requirement
• วิธีจัดการข้อมูล dynamic

ตัวอย่างพรอมต์ภาษาไทย:

แปลงภาพหน้าจอ UI นี้ให้เป็นคอมโพเนนต์ React เดี่ยวโดยใช้ Tailwind CSS

ข้อกำหนด:
- จัด layout, spacing, typography และชุดสีให้ใกล้ภาพต้นฉบับที่สุด
- รองรับหน้าจอ desktop และ mobile ที่ความกว้าง 375px
- ใช้ semantic HTML เช่น header, main, section, nav, button, form
- ใส่ aria-label หรือ label สำหรับ input และปุ่มที่จำเป็น
- ใช้ข้อมูล placeholder สำหรับส่วนที่เป็นข้อมูล dynamic เช่น ชื่อผู้ใช้ รายการ ตาราง หรือกราฟ
- ห้ามสร้าง backend หรือ API ใหม่
- ส่งคืนเฉพาะโค้ด component เท่านั้น ไม่ต้องอธิบาย

หากใช้ Tailwind ให้โมเดลสร้าง class utility ตาม convention ของ เอกสาร Tailwind CSS ได้ แต่ควรระบุ constraint เพื่อไม่ให้เกิด wrapper div ซ้อนกันมากเกินไป

ถ้าคุณมี design spec, component spec หรือไฟล์ design.md ให้ส่งไปพร้อมภาพด้วย โมเดลจะเข้าใจ token สี spacing scale และข้อกำหนดของ component ได้ดีขึ้น อ่านเพิ่มได้ที่ สิ่งที่ design.md มีผลต่อ Agent การเขียนโค้ด

ตัวอย่างพรอมต์สำหรับ React + Tailwind

ใช้พรอมต์นี้เป็น template ได้:

คุณคือ frontend engineer ที่เชี่ยวชาญ React และ Tailwind CSS

งาน:
สร้าง UI จากภาพหน้าจอที่แนบมาเป็น React component เดี่ยว

Stack:
- React
- Tailwind CSS
- ไม่มี external CSS file
- ใช้ lucide-react สำหรับ icon หากจำเป็น

ข้อกำหนดด้าน UI:
- layout ต้องใกล้ภาพต้นฉบับ
- spacing ต้องใกล้เคียงระดับ pixel
- ใช้สีจากภาพให้ใกล้ที่สุด
- ถ้ามีสีที่ไม่แน่ใจ ให้ใช้ค่า hex ที่เหมาะสมและสม่ำเสมอ
- รองรับ responsive ที่ 375px, 768px และ 1024px

ข้อกำหนดด้านโค้ด:
- ใช้ semantic HTML
- หลีกเลี่ยง div ซ้อนกันเกินจำเป็น
- แยกข้อมูล mock เป็น array/object ด้านบน component
- ห้ามสร้าง API หรือ logic ฝั่ง server
- ส่งคืนเฉพาะโค้ดเท่านั้น

ปิดช่องว่างด้วย Visual Feedback Loop

รอบแรกมักได้ layout ใกล้เคียง แต่สี spacing และรายละเอียดเล็กๆ อาจยังไม่ตรง วิธีแก้คือทำ visual feedback loop:

1. ให้โมเดลสร้าง component จากภาพต้นฉบับ
2. นำโค้ดไป render ใน browser
3. ถ่าย screenshot ของผลลัพธ์
4. ส่งภาพต้นฉบับและภาพผลลัพธ์กลับไป
5. ขอให้โมเดลเปรียบเทียบและแก้โค้ด

พรอมต์สำหรับรอบแก้ไข:

ภาพที่ 1 คือดีไซน์ต้นฉบับ
ภาพที่ 2 คือผลลัพธ์ที่ render จากโค้ดปัจจุบัน

ให้ทำ 2 ขั้นตอน:
1. แสดงรายการความแตกต่างทางภาพ เช่น layout, spacing, สี, typography, ขนาดปุ่ม และ alignment
2. ส่งคืนโค้ด React component เวอร์ชันแก้ไขที่ใกล้ภาพที่ 1 มากขึ้น

ข้อกำหนด:
- คงโครงสร้าง React เดิมเท่าที่ทำได้
- แก้เฉพาะส่วนที่จำเป็น
- ส่งคืนเฉพาะโค้ดสุดท้าย

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

การจัดการกับดีไซน์จริงที่มีขนาดใหญ่

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

1. ลดขนาดภาพแต่ยังอ่านข้อความได้

ภาพความละเอียดสูงใช้โทเค็นมากขึ้น ให้ resize ลงเท่าที่ยังอ่านข้อความและรายละเอียด UI ได้ชัดเจน

แนวทางปฏิบัติ:

• crop เฉพาะ section ที่ต้องการสร้าง
• หลีกเลี่ยงการส่ง full-page screenshot หากทำแค่ navbar หรือ card
• ถ้าหน้ายาว ให้แบ่งเป็นหลายภาพ เช่น header, sidebar, table, footer

2. แบ่งงานเป็น component ย่อย

แทนที่จะสั่งว่า “สร้าง dashboard ทั้งหน้า” ให้แยกเป็น:

• Header
• Sidebar
• MetricCard
• DataTable
• FilterBar
• EmptyState
• Pagination

จากนั้นค่อยประกอบเป็นหน้าเต็ม วิธีนี้ช่วยให้โมเดลสร้างโค้ดที่ maintain ได้ง่ายกว่า แม้บริบท 1M โทเค็นจะรองรับงานใหญ่ แต่ prompt ที่ scope เล็กกว่าจะให้ผลลัพธ์แม่นกว่า

ปรับพรอมต์เพื่อแก้ปัญหาที่พบบ่อย

ใช้บรรทัดเสริมเหล่านี้ในพรอมต์ตามปัญหาที่เจอ

สีไม่ตรง

ใช้ค่าสีต่อไปนี้เท่านั้น:
- primary: #2563EB
- background: #F8FAFC
- border: #E2E8F0
- text: #0F172A
- muted text: #64748B

โมเดลมักประมาณสีจากภาพ หากมี design token หรือ hex code ให้ใส่ลงไปโดยตรง

ไอคอนเพี้ยน

ใช้ lucide-react สำหรับ icon ทั้งหมด และเลือก icon ที่ใกล้กับภาพที่สุด ห้ามวาด icon ด้วย CSS เอง

หรือหากใช้ Heroicons:

ใช้ Heroicons เท่านั้นสำหรับ icon และ import เฉพาะ icon ที่จำเป็น

ข้อความถูกแต่งขึ้นเอง

ถ้าข้อความในภาพอ่านไม่ชัด ให้ใช้ placeholder ที่ระบุชัดเจน เช่น "Placeholder title", "Sample user", "Mock description" ห้ามสร้างข้อความ marketing ใหม่

โค้ดมี div ซ้อนมากเกินไป

ใช้ semantic HTML และลด wrapper div ที่ไม่จำเป็น โครงสร้างควรอ่านง่ายและ maintain ได้

Responsive ยังไม่ดี

เพิ่ม responsive behavior:
- mobile 375px: stack layout เป็นแนวตั้ง
- tablet 768px: ใช้ 2 columns หากเหมาะสม
- desktop 1024px+: ใช้ layout ตามภาพต้นฉบับ

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

โค้ด UI ที่สร้างขึ้นเป็นเพียงครึ่งหนึ่งของฟีเจอร์ ในแอปจริง component ต้อง:

• ดึงข้อมูลจาก API
• submit form
• แสดง loading state
• แสดง error state
• ใช้ mock data ระหว่าง backend ยังไม่เสร็จ
• validate response shape

ดังนั้นควรออกแบบ API contract ควบคู่กับ UI ตั้งแต่ต้น Apidog ช่วยให้คุณกำหนด API spec, mock response, ทดสอบ endpoint และตรวจสอบ response ก่อน backend เสร็จได้

ตัวอย่าง workflow:

1. ใช้ Qwen 3.7 Plus สร้าง component จากภาพ
2. แยก mock data ที่โมเดลสร้างออกมาเป็น schema
3. ออกแบบ endpoint ใน Apidog เช่น GET /dashboard/metrics
4. สร้าง mock response จาก schema
5. เปลี่ยน component ให้ fetch จาก mock API
6. ทดสอบ request/response ก่อนเชื่อม backend จริง

อ่านขั้นตอนเพิ่มเติมได้ใน คู่มือโหมด spec-first แนวทางนี้ใช้ร่วมกับ frontend ที่สร้างด้วย AI ได้ดี เช่นเดียวกับ API ที่สร้างใน Cursor

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

ตัวอย่างการเปลี่ยน Mock Data เป็น API Call

ถ้าโมเดลสร้างข้อมูล mock แบบนี้:

const users = [
  { id: 1, name: "Sample User", role: "Admin", status: "Active" },
  { id: 2, name: "Demo User", role: "Editor", status: "Pending" },
];

ให้แยกเป็น API contract เช่น:

GET /users

ตัวอย่าง response:

{
  "data": [
    {
      "id": 1,
      "name": "Sample User",
      "role": "Admin",
      "status": "Active"
    },
    {
      "id": 2,
      "name": "Demo User",
      "role": "Editor",
      "status": "Pending"
    }
  ]
}

แล้วปรับ component ให้ fetch ข้อมูล:

import { useEffect, useState } from "react";

export default function UsersTable() {
  const [users, setUsers] = useState([]);
  const [loading, setLoading] = useState(true);

  useEffect(() => {
    async function loadUsers() {
      try {
        const res = await fetch("/users");
        const json = await res.json();
        setUsers(json.data);
      } finally {
        setLoading(false);
      }
    }

    loadUsers();
  }, []);

  if (loading) {
    return <p className="text-sm text-slate-500">Loading users...</p>;
  }

  return (
    <table className="w-full text-sm">
      <thead>
        <tr className="border-b text-left">
          <th className="py-2">Name</th>
          <th className="py-2">Role</th>
          <th className="py-2">Status</th>
        </tr>
      </thead>
      <tbody>
        {users.map((user) => (
          <tr key={user.id} className="border-b">
            <td className="py-2">{user.name}</td>
            <td className="py-2">{user.role}</td>
            <td className="py-2">{user.status}</td>
          </tr>
        ))}
      </tbody>
    </table>
  );
}

จุดสำคัญคืออย่าปล่อยให้ UI ที่สร้างจาก AI ค้างอยู่กับ mock data ถาวร ให้เปลี่ยน mock data เป็น API contract ให้เร็วที่สุด

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

Qwen 3.7 Plus สร้างโค้ดสำหรับ framework ใดได้บ้าง?

ขึ้นอยู่กับพรอมต์ที่คุณระบุ เช่น React, Vue, Svelte, HTML/CSS ธรรมดา, Tailwind CSS หรือ component library อื่นๆ หากไม่ระบุชัดเจน โมเดลมักคืนมาร์กอัปทั่วไป

ผลลัพธ์รอบแรกแม่นแค่ไหน?

โดยทั่วไปโครงสร้างจะใกล้เคียง แต่ spacing, สี และรายละเอียดเล็กๆ อาจยังไม่ตรง หากต้องการความแม่นยำใกล้ pixel-level ให้ใช้ visual feedback loop โดย render ผลลัพธ์ ถ่าย screenshot แล้วส่งกลับไปให้โมเดลแก้

ใช้กับดีไซน์จาก Figma ได้หรือไม่?

ได้ หาก export frame จาก Figma เป็นรูปภาพแล้วส่งให้โมเดล โมเดลอ่านภาพที่ render แล้ว ไม่ได้อ่านไฟล์ Figma โดยตรง

ลดค่าใช้จ่ายโทเค็นอย่างไร?

resize ภาพให้เล็กลงเท่าที่ยังอ่านได้ crop เฉพาะส่วนที่ต้องสร้าง และแบ่งหน้าใหญ่เป็น component ย่อย แทนที่จะส่งทั้งหน้าในครั้งเดียว

โมเดลสร้าง backend ให้ด้วยหรือไม่?

ไม่ควรใช้ workflow นี้เพื่อให้โมเดลสร้าง backend โดยอัตโนมัติจากภาพ UI ให้มองว่าโมเดลสร้าง frontend component จากนั้นคุณออกแบบ API, mock response และทดสอบ endpoint แยกต่างหาก ซึ่งเป็นส่วนที่ Apidog ช่วยจัดการได้

สรุป

การแปลง screenshot เป็นโค้ดด้วย Qwen 3.7 Plus ทำได้ดีที่สุดเมื่อคุณใช้ workflow ที่ชัดเจน: ส่งภาพพร้อมพรอมต์ที่ระบุ stack, สร้าง component, render ผลลัพธ์, ส่งภาพกลับไปให้โมเดลแก้ และทำซ้ำจนใกล้ต้นฉบับ

หลังจากได้ UI แล้ว ขั้นตอนถัดไปคือทำให้ใช้งานได้จริงด้วย API contract, mock data และ endpoint test ใช้ Qwen 3.7 Plus สำหรับสร้าง frontend และใช้ Apidog สำหรับออกแบบ จำลอง และทดสอบ API ที่อยู่เบื้องหลัง เพื่อให้ฟีเจอร์ทั้งชุดทำงานร่วมกันได้อย่างมั่นคง