ผู้ช่วยเขียนโค้ดคนต่อไปอาจอยู่บน Mac ของคุณ: รู้จัก Flint

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

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

Flint ของ Recursive ทำให้แนวคิดนี้เป็นรูปธรรม ประกาศรองรับตั้งแต่วันแรกของ vLLM ลงวันที่ 21 ตุลาคม 2026 เปิดตัวการรองรับโมเดลเขียนโค้ดใหม่นี้ Recursive อธิบายว่าเป็น โมเดลแบบ mixture-of-experts ที่มีพารามิเตอร์รวมราว 40,000 ล้านตัว และใช้งานประมาณ 2,500 ล้านตัวต่อโทเคน รันไทม์ที่ปรับแต่งสำหรับ Mac ช่วยเชื่อมจากการดาวน์โหลดโมเดลไปสู่โปรแกรมควบคุมเอเจนต์เขียนโค้ดที่ใช้งานได้จริง

มุมมองของเราคือ Flint น่าสนใจเพราะโมเดล ซอฟต์แวร์ให้บริการ และการเชื่อมต่อเอเจนต์มาพร้อมกัน แต่การตัดสินใจซื้อยังต้องพิจารณาเครื่องทั้งระบบ “ทำงาน 2.5B” อธิบายเพียงส่วนหนึ่งของการคำนวณ ไม่ได้หมายความว่าแล็ปท็อปหน่วยความจำน้อยจะเก็บโมเดลทั้งหมดได้ บทความนี้อธิบายความแตกต่างด้านฮาร์ดแวร์ งานเริ่มต้นที่มีประโยชน์สามแบบ และวิธีประเมินการเขียนโค้ดในเครื่องโดยไม่สับสนระหว่างข้อความที่ออกเร็วกับงานแก้ไขที่เสร็จสมบูรณ์

โมเดลในเครื่องมีประโยชน์เมื่อทำงานร่วมกับเครื่องมือของคุณได้

Recursive เป็นบริษัทวิจัย AI ที่กำลังพัฒนา Eureka Machine ซึ่งเป็นระบบวิจัยอัตโนมัติ Flint เป็นผลิตภัณฑ์สาธารณะจากความพยายามนั้น มีน้ำหนักโมเดลให้ดาวน์โหลดและเอนจินอนุมานเฉพาะชื่อ rec สำหรับนักพัฒนาที่ยังไม่รู้จักบริษัท จุดเริ่มต้นใช้งานเข้าใจได้ง่าย นี่คือโมเดลข้อความสำหรับตรวจโค้ด เสนอการแก้ไข และใช้เครื่องมือผ่านแอปพลิเคชันเขียนโค้ด

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

เอกสารตั้งค่าของ Recursive ระบุทางเลือกรันไทม์ในเครื่องควบคู่กับแอปเขียนโค้ด เช่น Pi, OpenCode, Cline และ OpenHands ทำให้ Flint เข้าถึงง่ายกว่าการเปิดตัวที่มีเพียงน้ำหนักให้ดาวน์โหลด ทีมยังเลือกได้ว่าจะใช้ตัวแก้ไขเดิม ใช้ตัวเรียกทำงานที่แนะนำ หรือแยกให้บริการโมเดลต่างหาก

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

พารามิเตอร์สี่หมื่นล้านตัวยังต้องมีที่เก็บ

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

การ์ดโมเดล Flint ที่ตรวจเมื่อ 23 ตุลาคมระบุ พารามิเตอร์รวม 39.8B และ ทำงานประมาณ 2.5B ต่อโทเคน โดยรับและส่งข้อความ เอกสารระบุ การตั้งค่าบริบท 262,144 โทเคน ซึ่งใช้ร่วมกันระหว่างพรอมป์ต์กับผลลัพธ์ ตัวเลขเหล่านี้ตอบคนละคำถาม ป้าย “ขนาดโมเดล” เพียงค่าเดียวจึงไม่พอสำหรับวางแผน

การคำนวณง่าย ๆ ช่วยให้เห็นปัญหาพื้นที่เก็บ หากใช้สี่บิตต่อพารามิเตอร์พอดี พารามิเตอร์ 39,800 ล้านตัวจะมี ข้อมูลบิตพารามิเตอร์ดิบประมาณ 19.9 GB ในหน่วยฐานสิบ หากใช้ 16 บิตจะได้ 79.6 GB ตัวเลขเหล่านี้เป็นเพียงการคำนวณระดับพื้นฐานเพื่ออธิบาย ไม่ใช่ขนาดดาวน์โหลดที่วัดจริงหรือความต้องการ RAM ทั้งหมด เมทาดาทา สเกลควอนไทซ์ การจัดสรรหน่วยความจำขณะรัน และแคชบทสนทนาล้วนเพิ่มยอดรวม

อินโฟกราฟิกที่จัดทำเอง การคำนวณบิตพารามิเตอร์ใช้เพื่ออธิบาย พารามิเตอร์ที่ทำงานไม่ได้ระบุหน่วยความจำอุปกรณ์ทั้งหมด ยังมีหน่วยความจำรันไทม์และบริบทเพิ่มเติม

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

ข้อกำหนด rec ปัจจุบัน ของ Recursive ระบุ Mac M4 Pro, M5 Pro หรือ M5 Max พร้อมหน่วยความจำแบบรวมอย่างน้อย 48 GB และพื้นที่ดิสก์ว่างราว 30 GB นี่คือข้อกำหนดสำหรับเส้นทางรันไทม์ที่ปรับแต่งนี้ ไม่ใช่คำรับรองสำหรับ Apple Silicon ทุกเครื่อง ผู้ใช้เครื่องเล็กกว่าควรตรวจข้อกำหนดของรันไทม์อื่นที่รองรับ แทนการตีความพารามิเตอร์ที่ทำงานเป็นคำแนะนำเรื่องความเข้ากันได้

ตัวเลขความเร็วต้องมีอุปกรณ์และความยาวบริบทกำกับ

หน้าเปิดตัวของ Recursive รายงานความเร็วมากกว่า 125 โทเคนที่สร้างต่อวินาทีบน MacBook Pro M4 Pro เมื่อใช้บริบทสั้น ผ่านเอนจินที่ปรับแต่ง นี่คือผลอนุมานที่บริษัทเป็นผู้รายงาน หน้านั้นมีผลประเมินการเขียนโค้ดด้วย แต่ทั้งคำกล่าวเรื่องอัตราส่งออกและอันดับทดสอบไม่ได้ทำนายว่าชุดทดสอบแอปของคุณจะทำงานเร็วเพียงใด ประกาศเปิดตัวของ Recursive

บทความเปิดตัวของ vLLM อธิบายอีกสภาพแวดล้อม คือ GB200 หนึ่งตัว การถอดรหัสแบบแบตช์หนึ่งคำขอ และ บริบท 100K โทเคน โดยรายงานประมาณ 485 โทเคนต่อวินาทีตลอดกระบวนการ ในการตั้งค่านั้น ผลจาก GPU เซิร์ฟเวอร์กับแล็ปท็อปไม่ควรถูกวางในแถวเปรียบเทียบเดียวกันโดยไม่ระบุเงื่อนไข ฮาร์ดแวร์และชุดซอฟต์แวร์อนุมานมีผลอย่างมาก

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

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

เริ่มจากการแก้ไขที่มีขอบเขต แทนการย้ายระบบทั้งหมด

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

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

สถานการณ์ที่สองคือเรียนรู้โมดูลส่วนตัว ขอแผนผังเส้นทางคำขอพร้อมอ้างอิงไฟล์ แล้วตรวจอ้างอิงบางส่วนด้วยตนเอง จากนั้นตามด้วยงานแคบ เช่น เพิ่มกฎตรวจสอบข้อมูลหนึ่งข้อที่ขาดไป คุณค่าคือบทสนทนาที่อิงคลังโค้ดจริง แทนคำอธิบายทั่วไปที่แยกจากข้อกำหนดพฤติกรรมของโครงการ

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

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

Mac ที่รองรับมีเส้นทางสั้นสู่งานแรก

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

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

rec doctor
rec launch pi

4. ให้งานเฉพาะหนึ่งอย่าง พร้อมพฤติกรรมที่คาดหวัง ขอบเขตที่เกี่ยวข้อง และคำสั่งตรวจสอบ เช่น อธิบายว่าทำไมการทดสอบอินพุตว่างจึงล้มเหลว เพิ่มการทดสอบป้องกันการเกิดซ้ำเฉพาะจุด และแก้เพียงฟังก์ชันที่รับผิดชอบพฤติกรรมนั้น
5. ตรวจ diff และผลทดสอบจริง เมื่อเสร็จแล้วตรวจสถานะเซิร์ฟเวอร์ และหยุดรันไทม์หากไม่ควรครองหน่วยความจำต่อ:

rec status
rec stop

ความสะดวกของตัวเรียกทำงานเป็นสิ่งที่ควรเข้าใจ Recursive ระบุว่าเซิร์ฟเวอร์โมเดลอาจยังทำงานหลังโปรแกรมควบคุมหรือ terminal ปิด การหยุดเซสชันโต้ตอบกับการคืนหน่วยความจำโมเดลเป็นคนละการกระทำ เรื่องนี้สำคัญกับเครื่องที่ใช้บิลด์ เปิดเบราว์เซอร์ และแอปประจำวันด้วย

เก็บการตั้งค่าสร้างผลลัพธ์ไว้กับผลการประเมิน

คู่มือการตั้งค่าสร้างผลลัพธ์ แนะนำเริ่มด้วย temperature 1.0, top-p 0.95 และ top-k 20 และอธิบายว่าการให้เหตุผลใช้งบโทเคนผลลัพธ์ เมื่อคำตอบหยุดเพราะถึงเพดาน คำตอบที่ยังไม่เสร็จเป็นคนละปัญหากับคำตอบที่เสร็จแล้วแต่ผิด

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

บทความ vLLM ระบุ parser เครื่องมือและเหตุผลแบบ GLM-4.7 สำหรับเส้นทางให้บริการนั้น นี่คือตัวอย่างชัดเจนว่าการมีชื่อโมเดลในเมนูเลือกยังไม่ใช่การผสานทั้งหมด แอปต้องรักษาโครงสร้างบทสนทนาที่เกี่ยวข้องและเรียกเครื่องมือตามเจตนาอย่างถูกต้อง คำตอบแชตที่ดูปกติเพียงอย่างเดียวไม่ได้แสดงว่าการแก้ไฟล์ทำงานได้

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

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

การอนุมานในเครื่องเปลี่ยนบิล แต่ไม่ได้ทำให้ต้นทุนหายไป

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

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

การทำงานพร้อมกันก็ควรใส่ใจ เอกสาร rec ปัจจุบันระบุว่าเอนจินจัดการ การสร้างผลลัพธ์ได้ครั้งละหนึ่งงาน คำขอซ้อนอาจได้รับ HTTP 429 ประสบการณ์ที่ดีสำหรับนักพัฒนาคนเดียวจึงไม่ได้แปลว่าเซิร์ฟเวอร์ร่วมของทีมจะทำงานแบบเดียวกัน การให้บริการหลายเอเจนต์เป็นภาระงานต่างออกไปและอาจต้องใช้รันไทม์อื่น

พัฒนาการที่น่าจับตาคือการเขียนโค้ดในเครื่องกำลังเป็นตัวเลือกขั้นตอนทำงานที่ครบวงจร การคำนวณส่วนที่ทำงานขนาดเล็ก น้ำหนักที่เข้าถึงได้ และรันไทม์เฉพาะของ Flint แก้คนละส่วนของปัญหา สิ่งที่ควรตามมาคือหลักฐานกว้างขึ้นเรื่องงานแก้ไขที่เสร็จบนโครงการทั่วไป การรองรับรันไทม์ที่มั่นคง และพฤติกรรมชัดเจนในเซสชันยาว สิ่งเหล่านี้จะเปลี่ยนเดโมน่าประทับใจให้เป็นเครื่องมือประจำวันที่ไว้ใจได้

เครื่องทำงานกำลังกลายเป็นส่วนหนึ่งของผู้ช่วยเขียนโค้ด

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

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

แหล่งข้อมูล

• Recursive: เปิดตัว Flint ประกาศเปิดตัว ตรวจเมื่อ 23 ตุลาคม 2026 หน้าแยกไม่ได้แสดงวันเปิดตัวที่เชื่อถือได้
• vLLM และ Recursive: รองรับ Flint ตั้งแต่วันแรก วันที่ 21 ตุลาคม 2026
• การ์ดโมเดลและข้อมูลจำเพาะ Flint ทางการ ตรวจเมื่อ 23 ตุลาคม 2026
• Recursive: เอกสาร Flint, การตั้งค่าและข้อกำหนด rec และการตั้งค่าสร้างผลลัพธ์ ตรวจเมื่อ 23 ตุลาคม 2026
• คลัง rec ทางการ ตรวจเมื่อ 23 ตุลาคม 2026

เก็บเหตุผลเบื้องหลังการตัดสินใจทางเทคนิค

หากต้องการพื้นที่แยกสำหรับลิงก์ต้นทางและบันทึกทางเทคนิคที่ตรวจทานแล้ว Telli.sh เป็นทางเลือกหนึ่ง เปิดพื้นที่บันทึกของคุณ