Cursor Composer 2.5 รวดเร็วและราคาถูกพอที่จะให้เอเจนต์เขียนไคลเอนต์ API ทั้งหมดและตัวจัดการเส้นทางให้คุณได้ ข้อเสียจะปรากฏขึ้นทันทีที่โค้ดสัมผัสกับบริการจริง: โมเดลเขียนคำขอที่ดูสะอาดตาไปยัง /v2/orders ทั้งที่บริการของคุณจริง ๆ แล้วเปิดเผย /orders และคาดหวังเพย์โหลดที่แตกต่างกัน โค้ดคอมไพล์ได้ แต่มันใช้งานไม่ได้ และคุณจะค้นพบหลังจากผ่านไปสามไฟล์แล้ว
คู่มือนี้จะแสดงเวิร์กโฟลว์ที่แก้ไขปัญหานั้น: ชี้ Composer 2.5 ไปยังข้อกำหนด API จริงของคุณผ่าน MCP ปล่อยให้มันสร้างโค้ดตามสัญญาจริง จากนั้นตรวจสอบผลลัพธ์ใน Apidog ก่อนที่จะส่งถึงเพื่อนร่วมทีม หากคุณยังใหม่กับโมเดลนี้ คู่มือ Cursor Composer 2.5 จะอธิบายว่ามันคืออะไรและเข้าถึงได้อย่างไร
ทำไมโมเดลเอเจนต์จึงเดารูปแบบ API
Composer 2.5 ถูกสร้างขึ้นสำหรับงานเอเจนต์ที่ซับซ้อนหลายขั้นตอน ขอให้มัน "เพิ่มไคลเอนต์สำหรับบริการการเรียกเก็บเงินของเราและเชื่อมต่อเข้ากับขั้นตอนการชำระเงิน" แล้วมันจะวางแผน แก้ไขหลายไฟล์ และรันการทดสอบจนกว่าจะผ่าน นั่นคือการอัปเกรดจาก Composer 2 และมันมีประโยชน์อย่างแท้จริง
จุดอ่อนนี้เป็นโครงสร้าง ไม่ใช่ข้อผิดพลาด เมื่อโมเดลไม่มีสัญญา API ของคุณอยู่ในบริบท มันจะเติมช่องว่างด้วยรูปแบบที่มีความเป็นไปได้ทางสถิติมากที่สุด: ชื่อฟิลด์ทั่วไป ข้อตกลง REST คำนำหน้าเวอร์ชันที่เห็นบ่อยที่สุดในการฝึกอบรม ผลลัพธ์ดูถูกต้อง มันผ่านการตรวจสอบ Lint แต่มันล้มเหลวเมื่อเทียบกับเซิร์ฟเวอร์ของคุณ เพราะเซิร์ฟเวอร์ของคุณไม่ใช่ค่าเฉลี่ยของทุก API บนอินเทอร์เน็ต
สามอาการของปัญหานี้:
- เอนด์พอยต์ที่เกือบจะตรงกัน (
/api/users/{id}เทียบกับ/users/{userId}ของคุณ) - ฟิลด์ที่คิดขึ้นมาเองหรือผิดพลาดในส่วนเนื้อหาคำขอ
- การจัดการการยืนยันตัวตนด้วยวิธีทั่วไป แทนที่จะเป็นรูปแบบจริงของบริการของคุณ
คุณสามารถใช้ Prompt เพื่อแก้ไขปัญหาบางส่วนได้ แต่การวางไฟล์ OpenAPI ทั้งหมดของคุณลงในแชทนั้นเปราะบางและสิ้นเปลืองบริบท วิธีแก้ไขที่ยั่งยืนคือการให้โมเดลเข้าถึงข้อกำหนด API ได้อย่างมีโครงสร้าง
วิธีแก้ไข: อ้างอิง Composer 2.5 กับข้อกำหนด API จริงของคุณผ่าน MCP
Model Context Protocol (MCP) คือมาตรฐานแบบเปิดสำหรับการป้อนเครื่องมือและข้อมูลไปยังโมเดล AI Cursor รองรับเซิร์ฟเวอร์ MCP และ เซิร์ฟเวอร์ Apidog MCP จะเปิดเผยข้อกำหนด API ของ Apidog ของคุณต่อโมเดลในฐานะแหล่งข้อมูลที่มีโครงสร้างที่สามารถสอบถามได้ในขณะที่เขียนโค้ด
ความแตกต่างในการปฏิบัติ: แทนที่จะเดา Composer 2.5 จะอ่านเอนด์พอยต์ สคีมา พารามิเตอร์ และรูปแบบการตอบสนองจริงของคุณ จากนั้นจึงเขียนโค้ดตามข้อมูลเหล่านั้น นี่คือแนวคิดเดียวกันเบื้องหลัง การเขียนโค้ดแบบ Vibe ด้วย Apidog MCP server ซึ่งนำมาใช้กับโมเดลที่แข็งแกร่งพอที่จะทำงานทั้งหมดได้แล้ว
ขั้นตอนที่ 1: เตรียมข้อกำหนด API ของคุณใน Apidog
สัญญา API ของคุณต้องอยู่ในที่ที่โมเดลสามารถอ่านได้ ออกแบบหรือนำเข้า API ของคุณใน Apidog เพื่อให้สคีมา, เอนด์พอยต์ และตัวอย่างเป็นปัจจุบัน หากคุณเริ่มต้นจากเอกสารที่มีอยู่ Apidog สามารถนำเข้าคอลเลกชัน OpenAPI และ Postman ได้โดยตรง ข้อกำหนดนี้คือแหล่งความจริงที่โมเดลจะใช้ ดังนั้นการทำให้มันถูกต้องแม่นยำจึงเป็นสิ่งสำคัญที่สุด
ขั้นตอนที่ 2: เชื่อมต่อเซิร์ฟเวอร์ Apidog MCP เข้ากับ Cursor
Cursor อ่านเซิร์ฟเวอร์ MCP จากไฟล์คอนฟิกในโปรเจกต์ของคุณ (โดยทั่วไปคือ .cursor/mcp.json) เซิร์ฟเวอร์ Apidog MCP ทำงานผ่าน npx และชี้ไปยังโปรเจกต์ของคุณ การตั้งค่าทั่วไปมีลักษณะดังนี้:
{
"mcpServers": {
"apidog-api-spec": {
"command": "npx",
"args": ["-y", "apidog-mcp-server@latest", "--project=<your-project-id>"],
"env": { "APIDOG_ACCESS_TOKEN": "<your-access-token>" }
}
}
}
ใช้คำสั่ง, ID โปรเจกต์ และโทเค็นที่แน่นอนจาก คู่มือการตั้งค่า Apidog MCP เนื่องจากค่าเหล่านั้นเฉพาะสำหรับบัญชีและเวอร์ชันเซิร์ฟเวอร์ของคุณ รีสตาร์ท Cursor หลังจากบันทึกเพื่อให้มันรับรู้เซิร์ฟเวอร์ใหม่
ขั้นตอนที่ 3: ยืนยันว่า Composer 2.5 สามารถเห็นข้อกำหนด API ได้
เปิดเซสชันเอเจนต์ เลือก composer-2.5 ในตัวเลือกโมเดล และลองถามคำถามแบบอ่านอย่างเดียวดูก่อน:
“ใช้เซิร์ฟเวอร์ apidog-api-spec MCP เพื่อแสดงรายการเอนด์พอยต์ภายใต้ทรัพยากร orders และฟิลด์ที่จำเป็นสำหรับการสร้างคำสั่งซื้อ”
หากมันคืนค่าเอนด์พอยต์และฟิลด์จริงของคุณ แสดงว่าการเชื่อมต่อใช้งานได้ หากมันตอบจากความรู้ทั่วไป แสดงว่าเซิร์ฟเวอร์ไม่ได้เชื่อมต่ออยู่ ให้ตรวจสอบการตั้งค่าอีกครั้งแล้วรีสตาร์ท
ขั้นตอนที่ 4: ปล่อยให้มันสร้างตามสัญญา
ตอนนี้ให้งานจริงแก่โมเดลและระบุชื่อข้อกำหนด API อย่างชัดเจน:
“ใช้เซิร์ฟเวอร์ apidog-api-spec เป็นแหล่งความจริง เขียนไคลเอนต์ TypeScript ที่มีการระบุประเภทสำหรับ Orders API ซึ่งรวมถึงการเรียกใช้ create-order และ get-order จับคู่สคีมาคำขอและการตอบกลับให้ตรงกันทุกประการ เพิ่มการจัดการข้อผิดพลาดสำหรับการตอบกลับการตรวจสอบ 422 ที่ข้อกำหนด API กำหนดไว้”
เนื่องจาก Composer 2.5 รองรับงานที่ซับซ้อนได้ดี จึงสามารถทำงานนี้ได้ในหลายไฟล์และรักษาสัญญาให้สอดคล้องกัน การระบุแหล่งที่มาของ MCP ใน Prompt ช่วยให้มันยึดติดอยู่กับความจริง แทนที่จะกลับไปใช้การคาดเดา
ตรวจสอบก่อนที่คุณจะเชื่อ: วงจรการทดสอบ Apidog
การอ้างอิงโมเดลกับข้อมูลจริงช่วยลดการสร้างข้อมูลที่ผิดพลาดลงอย่างมาก แต่นั่นไม่ได้หมายความว่าการตรวจสอบเป็นทางเลือก ข้อกำหนด API อาจล่าช้ากว่าบริการที่ทำงานอยู่เล็กน้อย และโมเดลก็ยังสามารถตีความกรณีพิเศษผิดพลาดได้
ปิดวงจร:
- ส่งการเรียกใช้ที่สร้างขึ้นเป็นคำขอจริง นำเอนด์พอยต์ที่ Composer 2.5 เขียนขึ้นมาทดลองใช้งานใน Apidog เทียบกับสภาพแวดล้อมจริงหรือจำลอง ตรวจสอบว่าโค้ดสถานะ, เนื้อหาการตอบกลับ และการยืนยันตัวตนทำงานตามที่โค้ดคาดการณ์ไว้หรือไม่
- เปลี่ยนการเรียกใช้งานที่ถูกต้องให้เป็นชุดทดสอบ บันทึกคำขอที่ตรวจสอบแล้วเป็นสถานการณ์ทดสอบอัตโนมัติ เพื่อให้ข้อบกพร่องที่เกิดขึ้นในภายหลังถูกตรวจจับโดย CI ไม่ใช่โดยผู้ใช้
- จำลองสิ่งที่ยังสร้างไม่เสร็จ หากโมเดลเขียนไคลเอนต์สำหรับเอนด์พอยต์ที่แบ็กเอนด์ยังไม่ได้นำออกใช้ เซิร์ฟเวอร์จำลองของ Apidog จะคืนค่าการตอบกลับที่สมจริง เพื่อให้งานส่วนหน้าดำเนินต่อไปได้ ซึ่งสอดคล้องกับรูปแบบใน AI agents and API testing เป็นอย่างดี
หลักการ: โมเดลเขียนฉบับร่างแรกตามสัญญา และคุณยืนยันว่าฉบับร่างนั้นทำงานได้ตามเซิร์ฟเวอร์จริง ความรวดเร็วจากเอเจนต์จะเพิ่มขึ้นก็ต่อเมื่อคุณไม่ต้องเสียเวลาไปกับการแก้ไขข้อบกพร่องในภายหลัง
ตัวอย่างจริงแบบครบวงจร
สมมติว่าคุณกำลังเพิ่มคุณสมบัติการคืนเงินให้กับบริการชำระเงิน
- เอนด์พอยต์และสคีมาการคืนเงินมีอยู่ในโปรเจกต์ Apidog ของคุณตั้งแต่ขั้นตอนการออกแบบแล้ว
- Apidog MCP เชื่อมต่อกับ Cursor; Composer 2.5 ถูกเลือกไว้
- คุณใช้ Prompt: “ใช้ apidog-api-spec สร้างไคลเอนต์คืนเงินและ React hook ที่เรียกใช้มัน ทำตามสคีมาอย่างเคร่งครัด รวมถึงเฮดเดอร์ idempotency-key ที่ข้อกำหนด API กำหนด”
- Composer 2.5 อ่านสัญญาจริง เขียนไคลเอนต์, Hook และ Types แล้วรันการทดสอบของโปรเจกต์
- คุณเปิด Apidog ส่งคำขอ create-refund จริง ยืนยันพฤติกรรมการทำงานซ้ำได้ (idempotency) และรหัส 409 เมื่อเกิดการซ้ำซ้อน จากนั้นบันทึกทั้งสองเป็นสถานการณ์ทดสอบ
สิ่งที่คุณหลีกเลี่ยงได้: ไคลเอนต์ที่ลืมเฮดเดอร์ idempotency ถูกนำไปใช้ และคืนเงินลูกค้าซ้ำซ้อนในสภาพแวดล้อม Staging นั่นคือประเภทของข้อบกพร่องที่การอ้างอิงข้อมูลจริงบวกกับการตรวจสอบจะช่วยขจัดออกไปได้
คำถามที่พบบ่อย
Composer 2.5 รองรับ MCP หรือไม่? ใช่ มันสามารถเข้าถึงชุดเครื่องมือเอเจนต์ทั้งหมดของ Cursor รวมถึงเซิร์ฟเวอร์ MCP เลือกมันในตัวเลือกโมเดลและกำหนดค่าเซิร์ฟเวอร์ในโปรเจกต์ของคุณ คู่มือ Composer 2.5 ครอบคลุมการเลือกโมเดล
ฉันจำเป็นต้องใช้ Apidog เพื่อใช้ MCP กับ Composer 2.5 หรือไม่? คุณต้องมีแหล่งข้อมูลข้อกำหนดที่มีโครงสร้าง เซิร์ฟเวอร์ Apidog MCP เป็นเส้นทางที่ครอบคลุมในที่นี้เนื่องจากมันยังให้การทดสอบและการจำลองในที่เดียวกันด้วย ตัวเลือกอื่น ๆ มีอยู่ใน การรวบรวมเซิร์ฟเวอร์ MCP ที่ดีที่สุดสำหรับ Cursor
การอ้างอิงโมเดลกับข้อกำหนด API จะหยุดการสร้างข้อมูลที่ผิดพลาดทั้งหมดหรือไม่? มันช่วยขจัดข้อผิดพลาดประเภทที่ใหญ่ที่สุด คือเอนด์พอยต์และสคีมาที่ผิดพลาดออกไป เนื่องจากโมเดลอ่านสัญญาจริงแทนที่จะเดา แต่มันไม่ได้มาแทนที่การทดสอบ ข้อกำหนด API อาจแตกต่างจากบริการที่กำลังทำงานอยู่ ดังนั้นคุณยังคงต้องตรวจสอบ
สิ่งนี้คุ้มค่าสำหรับโปรเจกต์ขนาดเล็กหรือไม่? หากโมเดลสัมผัสกับ API จริงใดๆ ใช่ การตั้งค่าเป็นไฟล์คอนฟิกครั้งเดียว ผลตอบแทนคือการเรียกใช้ที่สร้างขึ้นทุกครั้งจะตรงกับสัญญาของคุณ แทนที่จะเป็นการเดาที่ดูสมเหตุสมผล
สรุป
Composer 2.5 รวดเร็วและราคาถูกพอที่จะให้เอเจนต์จัดการงาน API จริงได้ ซึ่งจะคุ้มค่าก็ต่อเมื่อโมเดลเขียนโค้ดตามสัญญาจริงของคุณ แทนที่จะเป็นการเดาโดยเฉลี่ย เชื่อมต่อข้อกำหนดของคุณผ่านเซิร์ฟเวอร์ Apidog MCP เพื่อให้ Composer 2.5 อ่านข้อมูลที่ถูกต้อง จากนั้น ดาวน์โหลด Apidog เพื่อส่งคำขอจริง ยืนยันการตอบกลับ และบันทึกการเรียกใช้งานที่ถูกต้องลงในการทดสอบและ Mock อัตโนมัติ การสร้างโค้ดโดยอ้างอิงข้อมูลจริงพร้อมการตรวจสอบคือเวิร์กโฟลว์ที่เปลี่ยนความเร็วของเอเจนต์ให้เป็นคุณสมบัติที่พร้อมใช้งานจริง