GLM-5.2 ผลทดสอบและคุณสมบัติ: SWE-bench Pro, Terminal-Bench พร้อมเจาะลึกความหมายของตัวเลข

ถอดรหัสผลเกณฑ์มาตรฐาน GLM-5.2: SWE-bench Pro 62.1, Terminal-Bench 81.0, MCP-Atlas 77.0, พร้อมข้อมูลจำเพาะ, บริบท, ใบอนุญาต และความหมายที่แท้จริงของแต่ละคะแนน

INEZA Felin-Michel

INEZA Felin-Michel

17 June 2026

GLM-5.2 ผลทดสอบและคุณสมบัติ: SWE-bench Pro, Terminal-Bench พร้อมเจาะลึกความหมายของตัวเลข

enterprise.banner.title

enterprise.banner.feature1

enterprise.banner.feature2

enterprise.banner.feature3

enterprise.banner.ctaB

GLM-5.2 จาก Z.ai (Zhipu AI) เปิดตัวพร้อมชุดตัวเลขการวัดประสิทธิภาพ และบางส่วนก็โดดเด่นอย่างแท้จริง หัวข้อข่าวคือ SWE-bench Pro ที่ 62.1 ซึ่งแซงหน้า GPT-5.5 ไปเล็กน้อย เรื่องราวที่ใหญ่กว่าซ่อนอยู่หนึ่งบรรทัดด้านล่าง: Terminal-Bench กระโดดจาก 62.0 เป็น 81.0 ในรุ่นเดียว โพสต์นี้จะอธิบายคะแนนการวัดประสิทธิภาพแต่ละรายการของ GLM-5.2 ว่าการทดสอบแต่ละอย่างวัดอะไร และชี้ให้เห็นว่าส่วนใดที่นำอยู่จริงและส่วนใดที่เป็นแค่ค่าปัดเศษ

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

💡
หากคุณสร้างหรือทดสอบ API ในขณะที่ประเมินโมเดลเช่นนี้ Apidog คือแพลตฟอร์มครบวงจรที่เราใช้ในการออกแบบ ดีบัก จำลอง และจัดทำเอกสารสำหรับเอนด์พอยต์ที่โมเดลเหล่านี้เรียกใช้ จะมีข้อมูลเพิ่มเติมเกี่ยวกับเรื่องนี้ในภายหลัง แต่เป็นสิ่งสำคัญ: ประโยชน์ส่วนใหญ่ของ GLM-5.2 ปรากฏในการทำงานที่เกี่ยวข้องกับตัวแทนและการใช้เครื่องมือ ซึ่งเป็นส่วนสำคัญของ API
ปุ่ม

สรุปสั้นๆ: คะแนนการวัดประสิทธิภาพของ GLM-5.2 โดยสรุป

นี่คือตารางการวัดประสิทธิภาพ GLM-5.2 ฉบับเต็ม พร้อมคู่แข่งที่ใกล้เคียงที่สุดเพื่อเป็นข้อมูลอ้างอิง โปรดถือว่าคอลัมน์เปรียบเทียบเป็นตัวเลขที่ Z.ai รายงานสำหรับโมเดลเหล่านั้น ไม่ใช่การทดสอบซ้ำที่เป็นอิสระ

เกณฑ์มาตรฐาน สิ่งที่วัด GLM-5.2 GLM-5.1 GPT-5.5 Claude Opus 4.8
SWE-bench Pro การแก้ไขข้อผิดพลาดในคลังโค้ดจริง 62.1 58.4 58.6 n/a
Terminal-Bench 2.1 งาน Shell/Agent แบบหลายขั้นตอน 81.0 62.0 n/a n/a
MCP-Atlas การใช้เครื่องมือผ่านเซิร์ฟเวอร์ MCP 77.0 n/a 75.3 77.8
Humanity’s Last Exam (พร้อมเครื่องมือ) การให้เหตุผลของผู้เชี่ยวชาญที่ยาก 54.7 n/a 52.2 n/a
AIME 2026 คณิตศาสตร์เชิงแข่งขัน 99.2 n/a n/a n/a
GPQA-Diamond วิทยาศาสตร์ระดับบัณฑิตศึกษา 91.2 n/a n/a n/a

Z.ai ยังรายงานว่า GLM-5.2 เป็นโมเดลโอเพนซอร์สที่ได้คะแนนสูงสุดใน FrontierSWE, PostTrainBench และ SWE-Marathon เราจะมาดูกันว่าคุณสมบัติ ("โอเพนซอร์ส") นี้มีความหมายอย่างไร

สำหรับเวอร์ชันที่อธิบายโมเดลนี้ด้วยภาษาที่เข้าใจง่าย โปรดดูที่ ภาพรวมของ GLM-5.2 สำหรับการเปรียบเทียบแบบตัวต่อตัวกับโมเดลกรรมสิทธิ์ โปรดดูที่ การวิเคราะห์ GLM-5.2 เทียบกับ GPT-5.5, Opus และ Gemini โดยเฉพาะ

SWE-bench Pro: 62.1 และสิ่งที่บอกคุณจริงๆ

SWE-bench Pro เป็นเวอร์ชันที่ยากขึ้นและคัดสรรมาเป็นอย่างดีของ SWE-bench ดั้งเดิม โดยจะมอบปัญหา GitHub จริงพร้อมกับคลังข้อมูลทั้งหมดให้แก่โมเดล และขอให้สร้างแพตช์ที่ทำให้ชุดทดสอบที่ซ่อนอยู่ของโปรเจกต์ผ่าน ไม่มีคำถามแบบเลือกตอบ ไม่มีฟังก์ชันของเล่น คุณต้องแก้ไขข้อผิดพลาดในไฟล์จริง หรือไม่ก็ไม่แก้ไขเลย

GLM-5.2 ทำคะแนนได้ 62.1 GPT-5.5 อยู่ที่ 58.6 และ GLM-5.1 อยู่ที่ 58.4 ตามข้อมูลของ Z.ai ดังนั้นจึงมีข้อสรุปที่ตรงไปตรงมาสองประการ:

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

Terminal-Bench 2.1: 81.0 คือตัวเลขที่เป็นดาวเด่น

หากคุณจะอ่านข้อมูลเพียงแถวเดียวในตาราง โปรดอ่านแถวนี้ Terminal-Bench ประเมินโมเดลในฐานะ Agent ใน Shell จริง: ติดตั้ง Dependencies, รันคำสั่ง, แยกวิเคราะห์ Output, กู้คืนจากข้อผิดพลาด และทำงานหลายขั้นตอนให้เสร็จสมบูรณ์ตั้งแต่ต้นจนจบ มันให้รางวัลแก่ความพยายามอย่างต่อเนื่องและการใช้งานเครื่องมืออย่างมีวินัย ไม่ใช่ความฉลาดแบบครั้งเดียว

GLM-5.1 ทำคะแนนได้ 62.0 GLM-5.2 ทำคะแนนได้ 81.0 นั่นคือการกระโดดขึ้นถึง 19 คะแนนในรุ่นเดียว และเป็นสถิติประสิทธิภาพที่โดดเด่นของ GLM-5.2 ด้วยเหตุผลบางประการ การเปลี่ยนจาก "ล้มเหลวประมาณสี่ในสิบงาน" เป็น "ทำงานได้สำเร็จประมาณสี่ในห้า" คือความแตกต่างระหว่างโมเดลที่คุณต้องดูแลอย่างใกล้ชิดกับโมเดลที่คุณสามารถมอบ Terminal ให้ได้เลย

นี่คือจุดที่เรื่องราวของสถาปัตยกรรมเชื่อมโยงกับเรื่องราวของการวัดประสิทธิภาพ Z.ai ให้เครดิต "IndexShare" Sparse Attention ของ GLM-5.2 ซึ่งนำ Indexer ตัวเดียวมาใช้ซ้ำในทุกๆ สี่ชั้นของ Sparse Attention เพื่อลดต้นทุน Attention ในบริบทที่ยาวนาน งาน Agent ที่มีขอบเขตยาวนานจะสร้างบันทึกการทำงานที่ยาวนาน: คำสั่ง, ผลลัพธ์, คำสั่ง, ผลลัพธ์ ซ้ำไปซ้ำมาหลายสิบครั้ง โมเดลที่สามารถรักษาบริบทนั้นไว้ได้ในราคาถูกและแม่นยำคือโมเดลที่ไม่หลงทางกลางคันในระหว่างการสร้าง Terminal-Bench ที่พุ่งขึ้นอย่างก้าวกระโดดนี้คือผลตอบแทนเชิงปฏิบัติของการออกแบบนั้น สำหรับการเปรียบเทียบรุ่นสู่รุ่นแบบเต็ม โปรดดูที่ GLM-5.2 vs GLM-5.1

ข้อควรระวังที่ตรงไปตรงมา: Terminal-Bench เป็นตัวเลขที่ Z.ai รายงาน และเกณฑ์มาตรฐาน Agent นั้นมีความละเอียดอ่อนต่อโครงสร้างรอบๆ โมเดล (เช่น ข้อจำกัดเวลาที่กำหนด, การอนุญาตให้ลองใหม่, prompt ของชุดทดสอบ) การกระโดดที่สูงพอสมควรนี้ไม่น่าจะอธิบายได้ด้วยโครงสร้างเพียงอย่างเดียว แต่โปรดตรวจสอบกับภาระงานของคุณเองก่อนที่จะเดิมพัน Pipeline ทั้งหมดกับมัน

MCP-Atlas: 77.0 และผลเสมออย่างตรงไปตรงมาในอันดับต้น

MCP-Atlas วัดการใช้เครื่องมือผ่าน Model Context Protocol ซึ่งเป็นวิธีการมาตรฐานที่โมเดลใช้เรียกเครื่องมือและเซิร์ฟเวอร์ภายนอก เป็นเกณฑ์มาตรฐานที่เชื่อมโยงโดยตรงที่สุดกับงาน Agent และ API: โมเดลสามารถเลือกเครื่องมือที่ถูกต้อง จัดรูปแบบการเรียกได้อย่างถูกต้อง อ่านผลลัพธ์ และดำเนินการต่อไปได้หรือไม่

GLM-5.2 ทำคะแนนได้ 77.0 GPT-5.5 อยู่ที่ 75.3 และ Claude Opus 4.8 อยู่ที่ 77.8 ตามข้อมูลของ Z.ai นี่คือแถวที่คุณควรต้านทานความต้องการที่จะประกาศผู้ชนะ GLM-5.2 เอาชนะ GPT-5.5 ไป 1.7 คะแนน และตามหลัง Opus 4.8 อยู่ 0.8 คะแนน ซึ่งเป็นขอบเขตความคลาดเคลื่อนจากการปัดเศษ คำกล่าวที่ยุติธรรมคือในการใช้เครื่องมือแบบ MCP ทั้งสามโมเดลอยู่ในสภาพสูสีกัน และ GLM-5.2 ก็ได้รับตำแหน่งในกลุ่มนั้นแล้ว

นั่นเป็นสิ่งสำคัญเพราะการใช้เครื่องมือคือจุดที่โมเดลการเขียนโค้ดมาบรรจบกับ Stack ของคุณ การเรียก MCP ทุกครั้งในทางปฏิบัติแล้วคือการโต้ตอบกับ API: คำขอที่มีโครงสร้าง, การตอบสนองเพื่อแยกวิเคราะห์, ข้อผิดพลาดที่ต้องจัดการ หากคุณกำลังเชื่อมต่อโมเดลเข้ากับบริการจริง คุณต้องการสุขอนามัยแบบเดียวกับที่คุณใช้กับการผสานรวมใดๆ นี่คือจุดที่ Apidog เข้ามาช่วย คุณสามารถกำหนดและจำลองเอนด์พอยต์ที่ Agent จะเรียกใช้ จากนั้นดีบัก Request และ Response Payload จริงที่โมเดลสร้างขึ้น ก่อนที่จะปล่อยให้มันทำงานใน Production ดาวน์โหลด Apidog หากคุณต้องการทดสอบการเรียกใช้เครื่องมือเหล่านั้นในลักษณะเดียวกับการทดสอบ API อื่นๆ

การให้เหตุผลและคณิตศาสตร์: HLE 54.7, AIME 99.2, GPQA-Diamond 91.2

การเขียนโค้ดไม่ใช่เรื่องราวทั้งหมด GLM-5.2 ยังทำคะแนนการให้เหตุผลได้ดีอีกด้วย

รูปแบบที่เห็นได้จากข้อมูลเหล่านี้: GLM-5.2 ไม่ใช่ผู้เชี่ยวชาญด้านโค้ดที่แคบ ซึ่งจะล้มเหลวเมื่อเจอโจทย์คณิตศาสตร์หรือวิทยาศาสตร์ ระดับความพยายามในการคิดสองระดับ (High และ Max โดย Max แนะนำสำหรับการเขียนโค้ด) ช่วยให้คุณสามารถแลกเปลี่ยนความหน่วงกับความลึกในการแก้ปัญหาที่ยากขึ้น หากคุณต้องการมุมมองเชิงลึกด้านคณิตศาสตร์และการให้เหตุผลควบคู่ไปกับการเขียนโค้ด บทความ เกณฑ์มาตรฐาน GLM-5.2 เทียบกับคู่แข่ง จะเปรียบเทียบในเชิงลึกยิ่งขึ้น

คำกล่าวอ้างว่า “โอเพนซอร์สสูงสุด” อธิบายโดยละเอียด

Z.ai รายงานว่า GLM-5.2 เป็นโมเดลโอเพนซอร์สอันดับต้นๆ ใน FrontierSWE, PostTrainBench และ SWE-Marathon โปรดอ่านคำคุณศัพท์นั้นอย่างละเอียด เพราะมันมีความหมายสำคัญ

“โอเพนซอร์สสูงสุด” เป็นการกล่าวอ้างที่แคบกว่า “สูงสุดอย่างแท้จริง” ในที่นี้ขอบเขตที่เกี่ยวข้องคือโมเดลที่มีน้ำหนักเปิด (Open-weights): GLM-5.2 มาพร้อมกับใบอนุญาต MIT โดยมีน้ำหนักเปิดและไม่มีข้อจำกัดทางภูมิภาค ซึ่งแตกต่างจากโมเดล API แบบปิดที่คุณต้องเช่า เมื่อเทียบกับโมเดลที่มีน้ำหนักเปิดอื่นๆ การเป็นอันดับต้นๆ ใน FrontierSWE (งานซอฟต์แวร์ที่มีความยากระดับแนวหน้า), PostTrainBench (ความสามารถหลังการฝึก) และ SWE-Marathon (งานซอฟต์แวร์ที่ยาวนานและต่อเนื่อง) ถือเป็นคำกล่าวอ้างที่แข็งแกร่ง และเป็นคำกล่าวอ้างที่สำคัญหากข้อจำกัดของคุณคือ "ต้องสามารถโฮสต์ด้วยตัวเองได้"

มันไม่เหมือนกับการทำคะแนนเหนือกว่าโมเดลกรรมสิทธิ์ทุกตัวในการทดสอบเหล่านั้น ในกรณีที่ GLM-5.2 เอาชนะ GPT-5.5 ได้จริง เช่นใน SWE-bench Pro และ HLE ทาง Z.ai ระบุไว้อย่างตรงไปตรงมาโดยไม่มีข้อจำกัดของโอเพนซอร์ส ดังนั้นแนวคิดคือ: โดยรวมแล้วอยู่ในระดับแนวหน้าหรือใกล้เคียง และเป็นอันดับแรกอย่างชัดเจนในหมู่โมเดลที่คุณสามารถดาวน์โหลดและรันเองได้ VentureBeat ได้อธิบายคุณค่านี้อย่างตรงไปตรงมา โดยรายงานว่า GLM-5.2 “เอาชนะ GPT-5.5 ในการเขียนโค้ดแบบ Long-horizon ได้ด้วยต้นทุนประมาณหนึ่งในหก” นั่นคือการระบุลักษณะของ VentureBeat ซึ่งควรให้เครดิตมากกว่าที่จะยืนยันว่าเป็นข้อเท็จจริงที่วัดได้

ข้อมูลจำเพาะของ GLM-5.2 โดยสรุป

การวัดประสิทธิภาพจะมีความหมายก็ต่อเมื่อเทียบกับฮาร์ดแวร์และเงื่อนไขการอนุญาตใช้งานจริง นี่คือข้อมูลจำเพาะของ GLM-5.2 ที่กำหนดว่าคะแนนเหล่านี้จะแปลไปสู่การตั้งค่าของคุณได้อย่างไร

ข้อมูลจำเพาะ ค่า
พารามิเตอร์ รวม ~753B, แบบ Mixture-of-Experts (MoE)
ความแม่นยำ BF16
Attention IndexShare sparse attention (Indexer หนึ่งตัวใช้ร่วมกันสำหรับทุกๆ 4 Sparse Layers)
Window บริบท 1M โทเค็น (1,048,576)
Output สูงสุด สูงสุด 128K ตามเอกสารของ z.ai (ตรวจสอบข้อมูลล่าสุด; OpenRouter ไม่ได้ระบุตัวเลข)
รูปแบบข้อมูล ข้อความเข้า, ข้อความออก (ไม่มีรุ่น Vision ที่ยืนยันแล้ว)
ความพยายามในการคิด สูง (High) และ สูงสุด (Max); สามารถปิดใช้งานได้
ใบอนุญาต MIT, น้ำหนักเปิด, ไม่มีข้อจำกัดทางภูมิภาค
รหัสโมเดล HF zai-org/GLM-5.2, API glm-5.2, Ollama glm-5.2, OpenRouter z-ai/glm-5.2

ข้อควรทราบบางประการเกี่ยวกับการอ่านข้อมูลเสริมนี้ จำนวนพารามิเตอร์ ~753B คือขนาด MoE ทั้งหมด ไม่ใช่จำนวนที่ใช้งานต่อโทเค็น ดังนั้นอย่าอ่านว่า "ต้องใช้การคำนวณหนาแน่นขนาด 753B ต่อ Forward Pass" นั่นคือจุดประสงค์ของ MoE บริบท 1M โทเค็นเป็นข้อมูลจำเพาะที่ทำให้ผลลัพธ์ของ Terminal-Bench น่าเชื่อถือ: การรัน Agent ที่ยาวนานต้องการพื้นที่เพื่อเก็บประวัติทั้งหมดนั้น สำหรับ Output สูงสุด โปรดระมัดระวัง เอกสารของ Z.ai ระบุไว้สูงสุด 128K (ณ เดือนมิถุนายน 2026 โปรดตรวจสอบขีดจำกัดปัจจุบันที่ z.ai) แต่ไม่ได้ระบุไว้สอดคล้องกันในผู้ให้บริการหลายราย ดังนั้นให้ถือว่าเป็นขีดจำกัดที่ระบุไว้ในเอกสารมากกว่าที่จะรับประกันได้ และไม่มีโมเดล GLM-5.2 Vision หากคุณเห็น "GLM-5.2V" ที่ไหนก็ตาม นั่นไม่ใช่สิ่งที่ Z.ai ยืนยัน

ราคาเป็นไปตามหลักการของ Open-weights: OpenRouter ระบุ $1.40 ต่อ 1M โทเค็นนำเข้า และ $4.40 ต่อ 1M Output โดยที่ Input ที่แคชไว้จะอยู่ที่ประมาณ $0.26 ต่อ 1M (ตัวเลขจาก VentureBeat) โครงสร้างต้นทุนนั้นเป็นแกนหลักของคำว่า "ต้นทุนเพียงหนึ่งในหก" สำหรับรายละเอียดต้นทุนทั้งหมด รวมถึงระดับแพลน GLM Coding โปรดดูที่หน้า ราคา GLM-5.2 และหากคุณต้องการรันโดยไม่ต้องจ่ายตามจำนวนโทเค็น วิธีใช้ GLM-5.2 ฟรี จะครอบคลุมเส้นทางการโฮสต์ด้วยตัวเอง

วิธีตรวจสอบเกณฑ์มาตรฐานเหล่านี้ด้วยตนเอง

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

  1. อ่านแหล่งข้อมูลปฐมภูมิ. บล็อก GLM-5.2 ของ Z.ai และ เอกสารของ Z.ai มีระเบียบวิธีอย่างเป็นทางการ การ์ดโมเดลบน Hugging Face มีน้ำหนักและ Config หากคุณต้องการตรวจสอบสถาปัตยกรรมโดยตรง
  2. ตรวจสอบรายชื่อจากบุคคลที่สาม. หน้า OpenRouter ยืนยันราคาและรหัสโมเดล และ รายการในไลบรารี Ollama ยืนยันเส้นทางการรันแบบ Local บทความของ VentureBeat เพิ่มมุมมองภายนอกเกี่ยวกับเรื่องราวต้นทุน
  3. ดำเนินการประเมินผลของคุณเอง. เกณฑ์มาตรฐานเดียวที่สำคัญอย่างแท้จริงคือภาระงานของคุณ เชื่อมต่อ GLM-5.2 เข้ากับงานจริง โดยเฉพาะงาน Agentic ที่มีการเรียกใช้เครื่องมือ และสังเกตว่ามันทำงานอย่างไรในหลายๆ รอบ สำหรับบริบทของรุ่นก่อนหน้าในการทดสอบแบบเดียวกันนี้ บทความ GLM-5.1 และ การเปรียบเทียบความเร็วและต้นทุนของ GLM-5 vs DeepSeek vs GPT-5 เป็นข้อมูลพื้นฐานที่เป็นประโยชน์

เมื่อคุณดำเนินการประเมินภาระงานของคุณเอง การเรียกใช้เครื่องมือคือจุดที่โมเดลมักจะล้มเหลวอย่างเงียบๆ เช่น JSON ที่ไม่ถูกต้อง การเลือกเครื่องมือผิดพลาด การจัดการข้อผิดพลาดที่ตกหล่น การจำลองเอนด์พอยต์เหล่านั้นใน Apidog ช่วยให้คุณสามารถดู Request และ Response จริงของโมเดลได้โดยไม่ต้องไปรบกวนบริการจริง ซึ่งเป็นวิธีที่เร็วที่สุดในการแยกแยะฮีโร่ตามเกณฑ์มาตรฐานออกจากโมเดลที่ใช้งานได้จริงใน Stack ของคุณ

ประเด็นสำคัญ

เอกสารเกณฑ์มาตรฐานของ GLM-5.2 สามารถตรวจสอบได้อย่างละเอียดกว่าตารางคะแนนการเปิดตัวส่วนใหญ่ การกระโดดของ Terminal-Bench จาก 62.0 เป็น 81.0 เป็นตัวเลขที่ยิ่งใหญ่อย่างแท้จริง การนำหน้า GPT-5.5 ใน SWE-bench Pro นั้นเป็นเรื่องจริงแม้จะเล็กน้อย และผลลัพธ์ของ MCP-Atlas คือการเสมอกันสามทางอย่างตรงไปตรงมาในอันดับต้นๆ เมื่อนำคะแนนเหล่านั้นมารวมกับน้ำหนักที่เปิดเผย ใบอนุญาต MIT บริบท 1M โทเค็น และเศรษฐกิจที่มีต้นทุนประมาณหนึ่งในหก คุณจะได้โมเดลที่สมควรได้รับการประเมินอย่างจริงจังมากกว่าการมองผ่านๆ

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

ฝึกการออกแบบ API แบบ Design-first ใน Apidog

ค้นพบวิธีที่ง่ายขึ้นในการสร้างและใช้ API