เจาะลึกวิธีแก้ปัญหาซิงค์ไฟล์ Claude Design เผยเคล็ดลับประหยัดโทเค็นหลักแสน
โปรแกรมเมอร์ไอเดียเจิดสร้างเครื่องมือ CLI แบบไร้พึ่งพาภายนอก เพื่อดึงโปรเจกต์จาก Claude Design ลงเครื่อง local แบบไม่ต้องผ่านโมเดล LLM ให้เปลืองค่าใช้จ่าย
ภาพประกอบจากคลังภาพสต็อก ไม่ใช่ภาพจากเหตุการณ์จริง
- ซิงค์โปรเจกต์จาก Claude Design ผ่านตัวแทน AI ปกติเปลืองโทเค็นสูงถึง 665,000 โทเค็นต่อครั้ง
- พัฒนาเครื่องมือ CLI ตัวใหม่ชื่อ dsx ช่วยซิงค์ข้อมูลเหมือน Git โดยที่ไบต์ของไฟล์ไม่ผ่าน context ของโมเดล
- แกะรอย API ที่ไม่มีเอกสารทางการ (undocumented) ผ่านการทดสอบสดกับเซิร์ฟเวอร์จริงเพื่อป้องกันข้อผิดพลาด
- ออกแบบระบบความปลอดภัยแบบ zero third-party dependencies และเขียนไฟล์แบบ atomic writes ป้องกันข้อมูลสูญหาย
การจัดเก็บบันทึกการพัฒนาโปรแกรมและการแกะรอยโปรโตคอล (protocol archaeology) มักเริ่มต้นจากข้อสันนิษฐานที่ผิดพลาดได้เสมอ นักพัฒนาซอฟต์แวร์รายหนึ่งได้แชร์ประสบการณ์การสร้างเครื่องมือแก้ไขปัญหาการซิงค์ข้อมูลจาก Claude Design ที่ตั้งอยู่บนเซิร์ฟเวอร์คลาวด์ลงมายังฮาร์ดไดรฟ์ในเครื่องคอมพิวเตอร์ local
โดยปกติแล้ว วิธีการที่ง่ายที่สุดในการดึงไฟล์เหล่านี้คือการสั่งให้ AI ช่วยอ่านทุกไฟล์ในโปรเจกต์และเขียนลงเครื่อง ซึ่งจากการวัดผลในโปรเจกต์ขนาดใหญ่พบว่ามีค่าใช้จ่ายสูงถึง 665,000 โทเค็น เนื่องจากการส่งผ่านข้อมูลทุกไบต์ต้องวิ่งผ่าน context ของโมเดลเอไอทั้งขาไปและขากลับ
ตัวเลขดังกล่าวถือว่าสูงเกินความจำเป็นอย่างมาก เพราะการย้ายข้อมูลไบต์จากจุด A ไปจุด B นั้นไม่ใช่กระบวนการใช้เหตุผล (reasoning task) การให้โมเดลทำหน้าที่นี้จึงไม่ต่างจากการใช้คำสั่ง copy (cp) ที่มีราคาแพงลิบลิ่ว ความตั้งใจจึงเกิดขึ้นในการสร้าง Command Line Interface (CLI) แบบง่าย เพื่อทำหน้าที่ซิงค์โปรเจกต์ Claude Design มายังไดเรกทอรี local ในลักษณะเดียวกับการทำงานของ Git เช่น คำสั่ง clone, pull, push, status และ diff โดยที่ข้อมูลไบต์ของไฟล์ไม่ต้องสัมผัสกับ context ของโมเดลเลยแม้แต่น้อย
ปัญหาสำคัญคือ เอ็นด์พอยต์ที่ Claude Designใช้งานอยู่นั้นไม่มีเอกสารประกอบ (undocumented) และไม่มีสเปกสาธารณะเปิดเผย แม้รูปแบบการขนส่งจะเป็นเซิร์ฟเวอร์ MCP ที่ใช้ JSON-RPC และ tool calls แต่ทว่าเครื่องมือใดบ้างที่มีอยู่ อาร์กิวเมนต์ที่รับคืออะไร และส่งค่าอะไรกลับมา สิ่งเหล่านี้ไม่มีการบันทึกไว้ วิธีเดียวที่จะเรียนรู้ได้คือการเรียกใช้งานจริงแล้วจดบันทึกสิ่งที่ตอบกลับมา
การพัฒนาเครื่องมือที่ต้องเชื่อมต่อกับ API ที่ไม่มีเอกสารทางการ (undocumented API) มักมีความเสี่ยงสูงที่เซิร์ฟเวอร์ฝั่งผู้ให้บริการจะอัปเดตและทำให้ระบบพังได้ทันที การสร้างระบบทดสอบแบบ live test ที่ยิงตรงไปยังเซิร์ฟเวอร์จริงจึงเป็นแนวทางสำคัญที่ช่วยป้องกันไม่ให้เครื่องมือทำงานผิดพลาดโดยไม่รู้ตัว พร้อมทั้งช่วยลดความเสี่ยงเรื่องการสูญหายของข้อมูลในเครื่องของผู้ใช้งาน
ภาพประกอบจากคลังภาพสต็อก ไม่ใช่ภาพจากเหตุการณ์จริง
นักพัฒนาท่านนี้พบข้อเท็จจริงของโปรโตคอลที่เคยคาดเดาผิดไป 3 จุดก่อนจะทำการวัดผลจริง ซึ่งหากใช้ข้อมูลจำลอง (mock) ทดสอบอย่างเดียวคงไม่มีทางจับผิดได้ ได้แก่ ฟังก์ชัน write_files ส่งคืนค่าเป็นแผนผัง (map) ไม่ใช่รายการ (list), กรณีไม่มีสิทธิ์เข้าถึงโปรเจกต์จะแสดงผลเป็น HTTP 403 แทนที่จะเป็นข้อผิดพลาดระดับเครื่องมือ และการตรวจจับไฟล์ไบนารีจะพิจารณาจากเนื้อหาภายในไม่ใช่ing นามสกุลไฟล์
"write_files returns a map, not a list. I assumed a list of results, one per file. It's keyed by path. A mock returning a list would have passed my tests and mis-parsed the real server."
ผู้พัฒนาโปรเจกต์ dsx
เครื่องมือตัวนี้มีชื่อว่า dsx ถูกพัฒนาขึ้นเป็น Go binary เดี่ยวๆ ที่ไม่มีการพึ่งพาไลบรารีภายนอกเลย (zero third-party dependencies) รองรับระบบปฏิบัติการ macOS และ Linux ภายใต้สัญญาอนุญาตแบบ MIT เพื่อให้มั่นใจในความโปร่งใสและการตรวจสอบโค้ดได้อย่างปลอดภัยสูงสุด
ที่มา: Dev.to
พบข้อมูลผิดพลาดในบทความนี้? แจ้งปัญหาบทความนี้
ความคิดเห็น
แสดงความคิดเห็น