8 สุดยอด MCP Servers ที่แนะนำโดย Boris ผู้สร้าง Claude Code

คุณรู้หรือไม่ว่าสิ่งที่ผู้สร้าง Claude Code บอกว่าสำคัญที่สุดคืออะไร?

มันไม่ใช่วิธีการเขียน prompt มันไม่ใช่การเลือกโมเดล

"มอบวิธีการตรวจสอบผลลัพธ์ของตัวเองให้กับ Claude"

นี่คือสิ่งเดียวที่สำคัญ เขาบอกว่านี่คือเคล็ดลับที่สำคัญที่สุดสำหรับการใช้ Claude Code

บทความนี้เป็นส่วนต่อเนื่องจากบทสนทนานั้น เราเข้าใจหลักการแล้ว แล้วเราจะมอบวิธีการเหล่านั้นให้กับมันได้อย่างไรโดยเฉพาะเจาะจง? คำตอบคือ MCP servers

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

คุณกำลังประสบปัญหาเหล่านี้กับ Claude Code อยู่หรือไม่?

• โค้ดที่สร้างขึ้นใช้ไวยากรณ์เก่า และคุณต้องแก้ไขเองทุกครั้ง
• คุณต้องเปิดเบราว์เซอร์ขึ้นมาเองเพื่อดูว่าหน้าจอที่สร้างขึ้นนั้นใช้งานได้จริงหรือไม่
• คุณคัดลอกเนื้อหาของ Issue วางให้ Claude ให้มัน implement แล้วกลับไปเขียน progress
• ทุกครั้งที่เกิดข้อผิดพลาดในการทำงานจริง คุณต้องคัดลอก stack trace จาก Sentry
• คุณรู้จักคำว่า MCP แต่ไม่ได้ตั้งค่าอะไรเลยเพราะไม่รู้ว่าจะเพิ่มอะไรดี

ใช่แล้ว ผมก็ทำทั้งหมดนั้นเหมือนกัน

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

เมื่อคุณอ่านจบ คุณอาจจะอยากหาจุดหนึ่งในงานของคุณที่คุณ "กำลังคัดลอกและวางทุกครั้ง"

โปรดบันทึกบทความนี้ไว้

"Boris" คือใครกันแน่?

Boris Cherny เขาคือคนที่สร้าง Claude Code

เขาระบุอย่างชัดเจนว่า "ผมสร้าง Claude Code" ดังนั้นจึงไม่ต้องสงสัยเลย เขาคือคนที่เข้าใจปรัชญาการออกแบบของ Claude Code ในระดับที่ลึกที่สุด

วิธีการใช้งานของเขานั้นพิเศษมาก

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

(ลองนึกภาพว่ามีผู้ใต้บังคับบัญชา 15 คน ทุกคนกำลังทำงานที่แตกต่างกัน และมีเฉพาะคนที่ติดขัดเท่านั้นที่มาหาคุณ)

ยิ่งไปกว่านั้น CLAUDE.md ของเขา—ซึ่งเป็นกฎของโครงการ—มีความยาวเพียงประมาณ 100 บรรทัด เขาไม่ใช่คนประเภทที่เขียนกฎเป็นจำนวนมาก

คำพูดที่เขามักถูกอ้างถึงบ่อยที่สุดคือ:

"อย่าเขียน prompts จงเขียน loops"

แทนที่จะหาวิธีขอร้องให้ดีขึ้น ให้สร้างสภาพแวดล้อมที่ Claude สามารถวนรอบทำงานต่างๆ ได้ด้วยตัวเอง นี่คือแก่นแท้ของปรัชญาของเขา

3 หลักการที่ Boris พูดซ้ำแล้วซ้ำเล่า

เมื่อดูจากโพสต์ของเขา เขาจะพูดในสิ่งเดียวกันอย่างสม่ำเสมอ

หลักการที่ 1: มอบวิธีการตรวจสอบผลลัพธ์ของตัวเองให้กับ Claude

เขาเรียกสิ่งนี้ว่า "เคล็ดลับที่สำคัญที่สุด" คำอธิบายของเขาเข้าใจง่ายมาก:

ถ้าคุณขอให้ใครสักคนสร้างเว็บไซต์ แต่ห้ามไม่ให้พวกเขาใช้เบราว์เซอร์ จะเกิดอะไรขึ้น? ไม่มีอะไรดีๆ เกิดขึ้นมาแน่นอน

แต่ถ้าคุณให้เบราว์เซอร์แก่พวกเขา พวกเขาจะสร้าง ดู แก้ไข ดูอีกครั้ง และทำซ้ำจนกว่าจะดี

Claude ก็เหมือนกัน ถ้าคุณให้วิธีการตรวจสอบแก่มัน มันจะวนซ้ำด้วยตัวเองจนกว่าจะพอใจ

หลักการที่ 2: เปลี่ยนงานที่ทำมากกว่าวันละครั้งให้เป็นระบบ

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

หลักการที่ 3: นำเครื่องมือภายนอกเข้ามาใน workspace ของ Claude Code

Slack, ตัวติดตาม Issue, ฐานข้อมูล, API ภายใน โดยการทำให้สิ่งเหล่านี้เข้าถึงได้โดยตรงจาก Claude Code การเคลื่อนย้ายระหว่างเครื่องมือต่างๆ จะหายไป

นี่คือจุดที่ MCP เข้ามามีบทบาท

ในที่สุด

เมื่อพูดถึง MCP คุณจะเจออุปสรรคนี้เสมอ

ทันทีที่คุณเชื่อมต่อ MCP มือของ Claude Code ก็จะเอื้อมถึงสภาพแวดล้อมการทำงานจริง การปรับใช้, DNS, การชำระเงิน, ข้อมูลลูกค้า การอ่านนั้นไม่เป็นไร แต่ถ้าคุณอนุญาตให้เขียนหรือลบอย่างกะทันหัน อุบัติเหตุจะเกิดขึ้น

ดังนั้น คุณจะมอบหมายงานที่ไหน และมนุษย์จะตรวจสอบที่ไหน?

ผมกำลังแจกแผนภูมิขอบเขตฟรี ผมอยากให้คุณดูมันสักครั้งก่อนที่จะติดตั้ง MCP

👇

ที่นี่

MCP คืออะไรในหนึ่งประโยค?

มาทำความเข้าใจเรื่องนี้กันก่อน

MCP คือ "อินเทอร์เฟซทั่วไปในการเชื่อมต่อเครื่องมือ AI และบริการภายนอก" ให้คิดว่ามันเหมือนกับมาตรฐาน USB

ในโลกที่ไม่มีสิ่งนี้ คุณจะต้องสร้างระบบเชื่อมต่อแยกต่างหากสำหรับ Claude, ChatGPT และ AI อื่นๆ ด้วยมาตรฐาน MCP ผู้ให้บริการสร้างมันขึ้นมาครั้งเดียว และ AI ที่เข้ากันได้ทั้งหมดก็สามารถใช้งานได้

และเพื่อให้ชัดเจน MCP ไม่ได้แค่เพิ่มความสามารถให้กับ Claude Code เท่านั้น

มันนำเป้าหมายของงานเข้ามาอยู่ภายใน Claude Code เลย

แบบจาก Figma, ข้อผิดพลาดจาก Sentry, ตั๋วจาก Linear, log การทำงานจริงจาก Cloudflare—Claude มองเห็นมันโดยตรงและจัดการกับมันโดยตรง นั่นคือสาเหตุที่การคัดลอกและวางหายไป

และตอนนี้ มาตรฐานนี้ได้เปลี่ยนแปลงไปอย่างมาก

การเปลี่ยนแปลงในข้อกำหนดเบื้องต้นของ MCP

สิ่งนี้ยังไม่ได้รับการจัดระเบียบอย่างดีในวงการภาษาญี่ปุ่น ดังนั้นโปรดทำความเข้าใจไว้

ในการอัปเดตข้อกำหนดล่าสุด MCP ได้ผ่านการปรับปรุงครั้งใหญ่ที่สุดนับตั้งแต่เปิดตัว นี่คือการเปลี่ยนแปลงหลักสี่ประการ:

Statelessness (ไม่คงสถานะ) ก่อนหน้านี้ Remote MCP ถูกออกแบบให้เซิร์ฟเวอร์รักษาสถานะการเชื่อมต่อไว้ ตอนนี้สิ่งนั้นหายไปแล้ว มันกลายเป็นแบบ request-response เหมือน HTTP ทั่วไป ประโยชน์คือมันทำงานได้โดยตรงบนสภาพแวดล้อม serverless หรือ edge ขณะนี้ MCP สามารถสร้างเป็นระบบที่ปรับขนาดตามการเข้าถึง แทนที่จะเป็นเซิร์ฟเวอร์ประจำเครื่องเดียว

รองรับกระบวนการที่ทำงานเป็นเวลานาน สมมติฐานที่ว่าเครื่องมือจะส่งคืนผลลัพธ์ทันทีได้ถูกยกเลิกไปแล้ว มันสามารถส่งคืนหมายเลขติดตามก่อน เพื่อให้สามารถตรวจสอบความคืบหน้า อัปเดต และยกเลิกได้ในภายหลัง การย้ายโค้ดขนาดใหญ่ การสร้างวิดีโอ การวิเคราะห์ข้อมูลที่ยาวนาน และการปรับใช้สภาพแวดล้อมทั้งหมด—"งานที่ใช้เวลาหลายชั่วโมง" เหล่านี้ได้รับการสนับสนุนอย่างเป็นทางการผ่าน MCP แล้ว

ความสามารถในการส่งคืน UI ภายในบทสนทนา ก่อนหน้านี้ MCP เน้นที่ข้อความและ JSON แต่ตอนนี้เซิร์ฟเวอร์สามารถส่งคืนหน้าจอการทำงานได้ หน้าจอเลือกเป้าหมายการปรับใช้, กราฟ, ปุ่มอนุมัติ/ปฏิเสธ, ฟอร์ม กล่าวโดยย่อ MCP กำลังเปลี่ยนจากระบบที่ AI เรียก API ในเบื้องหลัง ไปเป็นมาตรฐานสำหรับแอปพลิเคชันขนาดเล็กที่ทำงานบน AI

การรับรองความถูกต้องระดับองค์กร เชื่อมโยงกับผู้ให้บริการข้อมูลประจำตัวขององค์กร เมื่อผู้ดูแลระบบอนุมัติ พนักงานจะเชื่อมต่อโดยอัตโนมัติเมื่อเข้าสู่ระบบครั้งแรก การดำเนินการแจกจ่าย API key ให้แต่ละบุคคลจะหายไป

โปรดทราบว่าฝั่งของ Anthropic กำลังทยอยเปิดตัวสิ่งเหล่านี้ ข้อเท็จจริงที่ว่าข้อกำหนดได้รับการสรุปแล้วนั้นแตกต่างจากที่ Claude Code ในเครื่องของคุณจะสามารถใช้ทุกอย่างได้ทันที

(ผมเห็นบทความที่พูดเกินจริงเกี่ยวกับเรื่องนี้เป็นครั้งคราว แต่คำที่เป็นทางการคือ "กำลังทยอยเปิดตัว")

มี MCP server มากกว่า 950 ตัวที่อยู่ในรายการตัวเชื่อมต่อของ Claude จำนวนนั้นล้นหลาม แต่ที่จริงแล้วไม่มีมากขนาดนั้นที่คุณจำเป็นต้องติดตั้งจริงๆ

8 MCP Server อย่างเป็นทางการที่เปลี่ยนโฉม Claude Code

นี่คือส่วนหลัก

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

1. Context7 MCP: กำจัดสาเหตุของโค้ดที่ล้าสมัย

เมื่อ Claude Code สร้างโค้ดที่ไม่ถูกต้อง สาเหตุมักไม่ใช่เพราะโมเดลขาดความฉลาด

มันเป็นเพียงเพราะข้อมูลที่มันอ้างอิงนั้นเก่า

ใช้ API ที่เลิกใช้แล้ว สร้างไวยากรณ์ Next.js เก่า ผสมการตั้งค่าจากเวอร์ชันต่างๆ สร้างอ็อปชันที่ไม่มีอยู่จริง เติมส่วนที่ไม่ได้อยู่ในเอกสารด้วยการเดา ล้วนเป็นสิ่งนี้ทั้งนั้น

Context7 เป็น MCP ที่ให้เอกสารล่าสุดสำหรับไลบรารีและเฟรมเวิร์กแก่ Claude Code ตามเวอร์ชัน แทนที่จะตอบจากความจำ คุณสร้างสถานะที่มัน implement หลังจากค้นหาเอกสารของเวอร์ชันเฉพาะนั้น

Prompt ที่ใช้งานได้จริง:

ใช้ Context7 ตรวจสอบเอกสารอย่างเป็นทางการสำหรับเวอร์ชันปัจจุบันของ Next.js ที่ใช้ในโปรเจกต์นี้

หลังจากตรวจสอบแล้ว ให้จัดระเบียบสิ่งต่อไปนี้ก่อนเริ่ม implement:

1. วิธีการ implement ที่แนะนำสำหรับเวอร์ชันปัจจุบัน
2. วิธีการ implement ที่เลิกใช้แล้ว
3. ความแตกต่างจากโค้ดโปรเจกต์ปัจจุบัน
4. ไฟล์ที่ต้องแก้ไข

อย่า implement โดยอิงจากการเดา ให้ใช้เฉพาะวิธีการที่อธิบายไว้ในเอกสารเท่านั้น

หมายเหตุ: อย่ารวมหลายแนวคิดใน query เดียว การถามเกี่ยวกับ "auth, routing และ caching" จะให้ผลลัพธ์ที่กว้างและตื้นเขิน ความแม่นยำจะดีกว่าเมื่อคุณดึงแนวคิดแยกกัน

Official Repo: https://github.com/upstash/context7

1. Playwright MCP: ให้ Claude สัมผัสเบราว์เซอร์ด้วยตัวเอง

สิ่งนี้นำหลักการที่ 1 ของ Boris ไปใช้โดยตรง

Claude Code สามารถเขียนโค้ดได้ แต่มันไม่รู้ว่าหน้าจอที่มันเขียนนั้นใช้งานได้จริงหรือไม่ การเชื่อมต่อ Playwright MCP ช่วยให้ Claude เปิดเบราว์เซอร์จริง คลิกปุ่ม กรอกฟอร์ม ติดตามการเปลี่ยนหน้า จับข้อผิดพลาด แก้ไข และตรวจสอบอีกครั้ง

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

Prompt ที่ใช้งานได้จริง:

เมื่อ implement เสร็จแล้ว ให้เปิด local environment ด้วย Playwright MCP

ลงมือปฏิบัติและตรวจสอบสิ่งต่อไปนี้:

1. การลงทะเบียนใหม่
2. การเข้าสู่ระบบ
3. การแสดงผลระหว่างข้อผิดพลาดในการป้อนข้อมูล
4. เลย์เอาต์แตกที่ความกว้างสมาร์ทโฟน
5. การออกจากระบบ

หากล้มเหลว อย่าเดาสาเหตุโดยการอ่านโค้ดเพียงอย่างเดียว ให้จำลองในเบราว์เซอร์ก่อนแล้วค่อยแก้ไข

หลังจากแก้ไข ให้รันการดำเนินการเดียวกันอีกครั้ง และรายงานว่าเสร็จสมบูรณ์หลังจากยืนยันความสำเร็จเท่านั้น

ผมจะพูดตรงนี้

สิ่งที่ Boris บอกว่าเขาใช้ทุกครั้งสำหรับงานเว็บจริงๆ แล้วคือ Claude Code browser extension ไม่ใช่ Playwright MCP เขาบอกว่ามันเสถียรกว่า MCP ที่คล้ายกันเพราะสามารถแชร์สถานะการเข้าสู่ระบบได้เหมือนเดิม

ดังนั้นกรณีการใช้งานคือ: ถ้าคุณต้องการตรวจสอบหน้าจอจริงโดยใช้เบราว์เซอร์ที่คุณเข้าสู่ระบบแล้ว ให้ใช้ extension ถ้าคุณต้องการทำให้เป็นอัตโนมัติในฐานะการทดสอบและรันขั้นตอนเดียวกันซ้ำๆ ให้ใช้ Playwright MCP

ทั้งสองอย่างมีปรัชญาเดียวกัน: "ให้เบราว์เซอร์แก่ Claude"

Official Repo: https://github.com/microsoft/playwright-mcp

1. Figma MCP: อ่านข้อมูลการออกแบบ ไม่ใช่แค่รูปภาพ

ตราบใดที่คุณส่งแบบออกแบบเป็นภาพหน้าจอ Claude ก็จะเดาเสมอ

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

การเชื่อมต่อ Figma developer MCP ช่วยให้เข้าถึงข้อมูลการออกแบบที่มีโครงสร้างได้โดยตรง ค่า, สี, โครงสร้าง component, design tokens การเดาจะหายไป

Prompt ที่ใช้งานได้จริง:

ดึงเฟรมที่เลือกอยู่ในปัจจุบันจาก Figma MCP

ก่อนอื่น ให้แยกเฉพาะสิ่งต่อไปนี้และอย่าเริ่ม implement:

• โครงสร้างหน้า
• Components ที่จะนำมาใช้ซ้ำ
• คำจำกัดความของสีและตัวอักษร
• กฎระยะขอบ
• การเปลี่ยนแปลงที่คาดการณ์ได้เมื่อปรับขนาดตาม Responsive

หลังจากยืนยันเนื้อหาที่แยกออกมาแล้ว ให้จัดลำดับความสำคัญในการใช้ component โปรเจกต์ที่มีอยู่สำหรับ implement

หากสร้าง component ใหม่ ให้อธิบายก่อนว่าทำไม component ที่มีอยู่จึงไม่เพียงพอ

และนี่คือของจริง

การดึงแบบจาก Figma, implement ใน Claude Code, ตรวจสอบใน Playwright, แก้ไขหากเสีย การเชื่อมต่อทั้งสามสิ่งนี้จะเปลี่ยนจากการออกแบบไปสู่การตรวจสอบให้เป็นเส้นเดียว

คุณค่าของ MCP จะเข้าใจได้ดีกว่าในการเชื่อมต่อนี้มากกว่าการแยกเดี่ยว

Official Docs: https://developers.figma.com/docs/figma-mcp-server/

1. Linear MCP: อ่านตั๋วและเขียน progress

Boris กล่าวถึงเพื่อนร่วมงานของเขาใน PRs ด้วย @claude และให้มันเพิ่มการเรียนรู้ลงในกฎของโครงการ กล่าวโดยย่อ เขาไม่ได้แยกพื้นที่การจัดการ Issue ออกจากพื้นที่ทำงานของ AI

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

สิ่งนี้ทำให้โฟลว์ต่อไปนี้ราบรื่น:

อ่าน Issue → ตรวจสอบโค้ดที่เกี่ยวข้อง → สร้างแผนการ implement → Implement → ทดสอบ → แสดงความคิดเห็น progress ใน Issue → อัปเดตสถานะ

Prompt ที่ใช้งานได้จริง:

ตรวจสอบ Issue ที่ได้รับมอบหมายให้ฉันซึ่งอยู่ในสถานะกำลังดำเนินการใน Linear

หลังจากจัดลำดับความสำคัญและการพึ่งพากันแล้ว ให้ดำเนินการดังต่อไปนี้สำหรับ Issue ที่มีความสำคัญสูงสุด:

1. ระบุข้อมูลที่ขาดหายไปในข้อกำหนด
2. ตรวจสอบโค้ดที่เกี่ยวข้อง
3. สร้างแผนการ implement และนำเสนอก่อนที่จะ implement
4. implement และทดสอบหลังจากได้รับการอนุมัติ
5. แสดงความคิดเห็นเกี่ยวกับการดำเนินการที่ดำเนินการไปใน Issue

โปรดรอการยืนยันจากฉันก่อนที่จะเปลี่ยนสถานะ

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

Official Docs: https://linear.app/docs/mcp

1. Sentry MCP: ติดตามสาเหตุโดยไม่ต้องวางข้อผิดพลาด

คุณทำอย่างไรเมื่อเกิดข้อผิดพลาดในการทำงานจริง?

เปิด Sentry, คัดลอก stack trace, วางให้ Claude, ค้นหาไฟล์ที่คุณสงสัย, วางไฟล์นั้นด้วย ไม่จำเป็นต้องทำสิ่งเหล่านั้นอีกต่อไป

คุณค่าของ Sentry MCP ไม่ได้อยู่ที่การแสดงรายการข้อผิดพลาดเท่านั้น มันคือการนำเนื้อหาข้อผิดพลาด, stack trace, ความถี่, ผู้ใช้ที่ได้รับผลกระทบ, รุ่นที่มาจาก, โค้ดที่เกี่ยวข้อง และความล้มเหลวที่คล้ายกันในอดีต มาไว้ในวงจรการตรวจสอบเดียวกัน

Prompt ที่ใช้งานได้จริง:

ดึงข้อผิดพลาดที่ยังไม่ได้รับการแก้ไขซึ่งมีผู้ใช้ที่ได้รับผลกระทบมากที่สุดใน 24 ชั่วโมงที่ผ่านมาจาก Sentry

ตรวจสอบตามลำดับต่อไปนี้:

1. วิเคราะห์เงื่อนไขการเกิด
2. ระบุโค้ดที่เกี่ยวข้อง
3. สร้างการทดสอบการจำลอง
4. หากสามารถจำลองได้ ให้ implement การแก้ไขที่น้อยที่สุด
5. รันการทดสอบทั้งหมด
6. สรุปสาเหตุที่แท้จริงและการแก้ไข

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

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

Official Docs: https://docs.sentry.io/product/sentry-mcp/

1. Cloudflare MCP: แสดงสถานะของเป้าหมายการปรับใช้

จนถึงตอนนี้เราได้พูดถึงการพัฒนาแล้ว แต่นี่เกี่ยวกับการดำเนินงาน

Cloudflare ได้เปิดตัว MCP server อย่างเป็นทางการหลายตัวเพื่อดำเนินการบริการของตน การตรวจสอบการตั้งค่า, การจัดการ Workers, การวิเคราะห์ log, การตั้งค่า DNS, การตั้งค่าความปลอดภัย, การตรวจสอบประสิทธิภาพ มันถูกออกแบบมาไม่เพียงแค่สำหรับการอ่าน แต่สำหรับการเสนอและทำการเปลี่ยนแปลงจริง

ซึ่งหมายความว่า Claude Code สามารถปรับปรุงโค้ดหลังจากเห็นว่ามันทำงานอย่างไรจริงๆ ที่ปลายทางการปรับใช้

Prompt ที่ใช้งานได้จริง:

ตรวจสอบสถานะสภาพแวดล้อมการทำงานจริงปัจจุบันด้วย Cloudflare MCP

ตรวจสอบ:

• ข้อผิดพลาดใน 24 ชั่วโมงที่ผ่านมา
• เวลาตอบสนอง
• อัตราการเข้าถึงแคช
• เหตุการณ์ด้านความปลอดภัย
• ข้อยกเว้นที่เกิดขึ้นใน Workers

จากนั้น ให้จัดประเภทปัญหาเป็นสองประเภทนี้:

A. ปัญหาที่ต้องเปลี่ยนโค้ด

B. ปัญหาที่สามารถปรับปรุงได้ด้วยการตั้งค่า Cloudflare เพียงอย่างเดียว

ในทั้งสองกรณี ให้เสนอแผนก่อนดำเนินการเปลี่ยนแปลงเสมอ อย่าเปลี่ยนการตั้งค่าจนกว่าฉันจะอนุมัติ

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

Official Docs: https://developers.cloudflare.com/agents/model-context-protocol/cloudflare/servers-for-cloudflare/

1. Stripe MCP: จับคู่โค้ดการชำระเงินกับการตั้งค่า Stripe

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

Stripe MCP อย่างเป็นทางการรวมถึงการค้นหาเอกสารอย่างเป็นทางการและข้อมูลสนับสนุนนอกเหนือจากการดำเนินการ Stripe API การ implement, การตรวจสอบการตั้งค่า และการอ้างอิงเอกสารทั้งหมดเกิดขึ้นในที่เดียวกัน

ยิ่งไปกว่านั้น Stripe ยังมี Skills สำหรับ Agent นอกเหนือจาก MCP ดำเนินการด้วย MCP และบังคับใช้แนวปฏิบัติที่ดีที่สุดด้วย Skills การรวมกันนี้มีประสิทธิภาพ

Prompt ที่ใช้งานได้จริง:

ใช้ Stripe MCP และเอกสาร Stripe อย่างเป็นทางการ สร้างแผนการ implement สำหรับฟีเจอร์สมัครสมาชิกรายเดือน

ตรวจสอบให้แน่ใจว่าคุณได้ตรวจสอบสิ่งต่อไปนี้:

1. การกำหนดค่า Product และ Price
2. วิธีการสร้าง Checkout Session
3. Events ที่จะได้รับผ่าน Webhook
4. ขั้นตอนกระบวนการยกเลิก
5. พฤติกรรมระหว่างการชำระเงินล้มเหลว
6. วิธีการป้องกันการลงทะเบียนซ้ำ
7. วิธีการทดสอบ

ใช้เฉพาะ Stripe test mode ระหว่างทำงาน อย่าทำการเปลี่ยนแปลงใดๆ กับข้อมูลการทำงานจริง

อย่าลบบรรทัดสองบรรทัดสุดท้ายนั้นเด็ดขาด นี่ไม่ใช่ MCP ที่จะรันโดยเปิดประตูเหล่านั้นทิ้งไว้

Official Docs: https://docs.stripe.com/mcp

1. GitHub MCP: ปิดวงจรการตอบสนองการตรวจสอบโค้ด

สุดท้ายนี้ อันนี้

แต่โปรดอย่าเข้าใจผิด; คุณค่าของ GitHub MCP ไม่ใช่ "การสามารถรันคำสั่ง git ได้" Claude Code สามารถจัดการกับ git ในเครื่องและ GitHub CLI ได้อยู่แล้ว

คุณค่ามันอยู่ที่เมื่อต้องข้ามข้อมูลที่มีอยู่เฉพาะฝั่งระยะไกล: รายละเอียด Issue, ความคิดเห็นรีวิว PR, ผลลัพธ์ CI, สถานะของ repo อื่นๆ, การค้นหาโค้ดภายใน และการสนทนาในอดีต

Prompt ที่ใช้งานได้จริง:

ตรวจสอบ PR ที่สอดคล้องกับสาขาปัจจุบันด้วย GitHub MCP

รวบรวมความคิดเห็นรีวิวที่ยังไม่ได้แก้ไขทั้งหมดและจัดประเภทเป็นสามประเภทนี้:

• สิ่งที่ต้องแก้ไข
• สิ่งที่ต้องตัดสินใจในการออกแบบซึ่งฉันควรตัดสินใจ
• สิ่งที่ตัดสินว่าไม่จำเป็นต้องแก้ไข (รวมเหตุผล)

implement เฉพาะ "สิ่งที่ต้องแก้ไข" และผ่านการทดสอบ

อย่าแตะต้องสิ่งที่ต้องตัดสินใจในการออกแบบ; ให้จัดระเบียบประเด็นที่ขัดแย้งและตัวเลือกและนำเสนอแทน

การอ่านความคิดเห็นรีวิว, การแก้ไข, การทดสอบ และการรายงาน—ทั้งหมดปิดภายใน Claude Code

Official Repo: https://github.com/github/github-mcp-server

สร้าง "Stack" ไม่ใช่แค่เครื่องมือเดี่ยวๆ

MCP จะมีประสิทธิภาพน้อยลงเมื่อเพิ่มทีละตัว มันจะเปลี่ยนไปเมื่อเรียงตามขั้นตอนการทำงาน

Web Production Stack:

ดึงแบบจาก Figma → ตรวจสอบไวยากรณ์ที่ถูกต้องปัจจุบันด้วย Context7 → Implement ใน Claude Code → ตรวจสอบเบราว์เซอร์ด้วย Playwright → PR และการตอบสนองรีวิวบน GitHub → การปรับใช้และการตรวจสอบ log บน Cloudflare

SaaS Development Stack:

ดึงข้อกำหนดจาก Linear → ตรวจสอบข้อกำหนดทางเทคนิคด้วย Context7 → Implement ใน Claude Code → ตั้งค่าและตรวจสอบการชำระเงินด้วย Stripe → ทดสอบการดำเนินการของผู้ใช้ด้วย Playwright → ตรวจสอบข้อผิดพลาดในการทำงานจริงด้วย Sentry

สิ่งที่เกิดขึ้น:

ในทั้งสอง stack กระบวนการจะเหมือนกัน

รับข้อมูล, วางแผน, สร้าง, ตรวจสอบด้วยตัวเอง, สะท้อนผลภายนอก, ดูผลลัพธ์

วงจรนี้ถูกปิดโดยไม่ต้องออกจาก Claude Code เลย

"มอบวิธีการตรวจสอบ" ของ Boris ไม่ได้หมายถึงแค่เบราว์เซอร์ตัวเดียว มันหมายถึงการมอบวิธีการเพื่อยืนยันความถูกต้องของแต่ละขั้นตอนในกระบวนการ

ผู้เริ่มต้นต้องการเพียงแค่สามตัวนี้

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

ระยะที่ 1: Context7

เป้าหมายคือการลดโค้ดที่ไม่ถูกต้อง

เนื่องจากเน้นการอ่าน ความเสี่ยงจึงต่ำ การเริ่มต้นที่นี่ปลอดภัยที่สุดและช่วยให้คุณสัมผัสถึงผลกระทบได้เร็วที่สุด

ระยะที่ 2: Playwright หรือ Browser Extension

เป้าหมายคือการให้ Claude ตรวจสอบผลงานที่ส่งมอบด้วยตัวเอง

ถ้าคุณทำงานเว็บ สิ่งนี้จะเปลี่ยนแปลงทุกอย่างอย่างมีนัยสำคัญ สร้าง, เปิด, พบรอยแตก, แก้ไข, เปิดอีกครั้ง มนุษย์ไม่จำเป็นต้องอยู่ตรงกลางอีกต่อไป

ระยะที่ 3: Linear หรือ GitHub

เป้าหมายคือการเชื่อมต่ออินพุตและเอาต์พุตของงาน

ตั้งแต่ตั๋วไปจนถึง implement, PR และการอัปเดต progress ณ จุดนี้ Claude Code จะเปลี่ยนจาก "นักเขียนโค้ดที่รอคำสั่ง" เป็น "สมาชิกที่ขับเคลื่อนงานไปข้างหน้าด้วยตัวเอง"

สามตัวนี้ก็เพียงพอแล้ว จริงจังนะ

หลุมพรางที่คุณต้องอ่าน

หลุมพรางที่ 1: MCP มากขึ้นไม่ได้ทำให้มันฉลาดขึ้น

นี่คือความเข้าใจผิดที่ใหญ่ที่สุด

ถ้าคุณเชื่อมต่อ MCP จำนวนมาก จำนวนเครื่องมือที่ Claude สามารถเลือกได้จะเพิ่มขึ้น แล้วจะเกิดอะไรขึ้น?

มันจะสับสนว่าจะใช้เครื่องมือไหน มันกิน context มันทำให้เครื่องมือที่คล้ายกันสับสน มันดำเนินการที่คุณไม่ได้ขอ การจัดการสิทธิ์จะซับซ้อน และคุณจะไม่รู้ว่าอะไรได้รับอนุญาต

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

(ครั้งหนึ่งผมเคยเชื่อมต่อมากกว่า 10 ตัว และ Claude เรียกใช้เครื่องมือแปลกๆ ตลอด ทำให้ผมคิดว่า "ทำไมมันถึงโง่ลงกระทันหัน?" มันแก้ไขได้เมื่อผมลดจำนวนลง)

หลุมพรางที่ 2: อย่าผสมการอ่านและการเขียนตั้งแต่เริ่มต้น

ตรวจสอบให้แน่ใจว่าคุณสร้างการออกแบบนี้ระหว่างการแนะนำเบื้องต้น:

อนุญาตให้อ่าน การสร้างต้องมีการยืนยัน การอัปเดตต้องมีการยืนยัน การลบถูกปฏิเสธ การดำเนินการในสภาพแวดล้อมการทำงานจริงถูกปฏิเสธ

โดยเฉพาะอย่างยิ่ง สิ่งที่ไม่ควรอนุญาตอย่างเต็มที่ตั้งแต่เริ่มต้นได้แก่: การปรับใช้ในการทำงานจริง, การเปลี่ยนแปลง DNS, การเปลี่ยนแปลงข้อมูลลูกค้า, การดำเนินการชำระเงินในการทำงานจริง, การลบ Issue, การรวม PR และการลบฐานข้อมูล

ความสะดวกสบายและอันตรายของ MCP เป็นสัดส่วนกันอย่างสมบูรณ์แบบ

หลุมพรางที่ 3: อย่าสับสนระหว่างเซิร์ฟเวอร์อย่างเป็นทางการกับที่สร้างโดยชุมชน

บนเว็บไซต์ค้นหา MCP เซิร์ฟเวอร์หลายตัวที่มีชื่อเดียวกันอาจปรากฏขึ้น แม้ว่าจะอยู่ในรายชื่ออย่างเป็นทางการ ก็ไม่จำเป็นต้องเป็นการ implement อย่างเป็นทางการจากผู้ให้บริการ

ตรวจสอบสิ่งเหล่านี้ก่อนติดตั้ง:

มันถูกจัดการโดยองค์กรอย่างเป็นทางการของผู้ให้บริการหรือไม่? อัปเดตล่าสุดเมื่อไหร่? มีนโยบายความปลอดภัยหรือไม่? วิธีการรับรองความถูกต้องคืออะไร? ขอสิทธิ์มากน้อยแค่ไหน? มันถูกออกแบบมาให้อนุญาตการลบหรือการเปลี่ยนแปลงในการทำงานจริงหรือไม่?

ยิ่งขอสิทธิ์มากเท่าไหร่ คุณควรตรวจสอบอย่างละเอียดมากขึ้นเท่านั้น

หลุมพรางที่ 4: อย่าปล่อยให้มันรันข้อความจากภายนอกตามที่เป็น

ขั้นตอนการทำงานของการอ่าน Issue หรือความคิดเห็น PR เพื่อ implement นั้นมีประสิทธิภาพ แต่นั่นเกี่ยวข้องกับข้อความที่เขียนโดยคนอื่น

ถ้า Issue พูดว่า "ทำตามขั้นตอนใน Issue นี้" และมีคำแนะนำที่เป็นอันตราย Claude อาจอ่านและทำตาม สำหรับ MCP ที่จัดการกับอินพุตภายนอก อย่าปล่อยให้มันรันโดยตรง ให้ให้มันนำเสนอสิ่งที่ตั้งใจจะทำก่อน

พื้นที่ที่ยังไม่แข็งตัว

ผมจะเขียนสิ่งนี้โดยไม่พูดเกินจริง

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

ระบบสำหรับส่งคืน UI ในบทสนทนาก็อยู่ในช่วงขยายตัวเช่นกัน ไม่ใช่ MCP ทั้งหมดที่จะส่งคืนหน้าจอการทำงาน ณ จุดนี้

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

ผมจะไม่ให้ตัวเลขเช่น "MCP เพิ่มประสิทธิภาพขึ้น X เท่า" ด้วย มันไม่ได้รับการพิสูจน์

ให้วัดสิ่งนี้แทน: คุณใช้เวลากี่นาทีต่อวันกับการคัดลอกและวาง การสลับหน้าจอ และการตรวจสอบด้วยสายตา? นั่นคือสิ่งที่หายไปกับ MCP

สิ่งที่ต้องทำวันนี้

อย่าพยายามทำทุกอย่าง แค่สิ่งเดียว

นึกย้อนกลับไปถึงงานของคุณและหาจุดหนึ่งที่คุณ "กำลังไปกลับระหว่าง Claude Code และหน้าจออื่น"

มันอาจเป็นเอกสาร มันอาจเป็น Issue มันอาจเป็นหน้าจอข้อผิดพลาด มันอาจเป็นแบบออกแบบ

ติดตั้งเฉพาะ MCP ที่กำจัดสิ่งนั้นออกไป สัมผัสถึงผลกระทบ จากนั้นจึงเพิ่มสิ่งต่อไป

หลักการของ Boris ท้ายที่สุดแล้วสรุปได้ดังนี้: ให้วิธีการตรวจสอบงานของตัวเองแก่ Claude ทันทีที่คุณให้มัน Claude จะเริ่มทำงานด้วยตัวเองจนกว่าจะพอใจ

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

คืนนี้ เปิด Claude Code และคิดถึงหน้าจอเดียวที่คุณเดินทางไปบ่อยที่สุด

ทุกอย่างเริ่มต้นจากตรงนั้น