เมื่อวานเราตั้งคำถามสั้นๆ ว่า "เราสลับการใช้ claude กับ qlaude แบบที่ไม่ต้องออกจาก session เลยไม่ได้เหรอ" โดย qlaude คือสมองตัวที่สองที่เราทำไว้บนเครื่องเดียวกัน ช่วงแรกของบทความจะเล่าว่ามันคืออะไรและมีไว้ทำไม
คำถามฟังดูเล็ก แต่พอไล่ดูของจริง ก็พาไปเจอเส้นแบ่งที่คนทำระบบ AI หลายคนน่าจะเคยชนเหมือนกัน คือเส้นระหว่างสิ่งที่แก้ได้ด้วยการเขียนโค้ดเพิ่ม กับสิ่งที่ต้องยอมรับว่าเครื่องมือเป็นแบบนั้น แล้วออกแบบวิธีทำงานรอบข้อจำกัดนั้นแทน
บทความนี้เริ่มจากอธิบายก่อนว่าสมองตัวที่สองคืออะไรและมีไว้ทำไม แล้วค่อยเล่าสามอย่าง อย่างแรกคือทำไมการสลับโมเดลกลางทางถึงทำไม่ได้ อย่างที่สองคือสองท่าที่เราใช้จริงแทนปุ่มนั้น และอย่างที่สามคือชั้นที่การเด้งอัตโนมัติทำงานไม่ได้เลย ซึ่งเป็นชั้นที่คนสั่งงานต้องลงมือตรวจเอง
ช่วงที่ 1qlaude คืออะไร และเราทำมันขึ้นมาทำไม
qlaude ไม่ใช่โปรแกรมใหม่ มันคือโปรแกรมช่วยเขียนโค้ดตัวเดิมที่เราเปิดใช้ทุกวัน แต่ถูกเรียกด้วยค่าคนละชุด ให้ไปคุยกับโมเดลคนละตัวที่ปลายทางคนละที่ ชื่อเล่นมาจากตัว q ของ Qwen โมเดลที่มันไปคุยด้วย หน้าตาเวลาใช้เหมือนกันทุกอย่าง ต่างกันแค่ข้างในคิดด้วยสมองคนละก้อน
เหตุผลที่ทำคือเรื่องเงินล้วนๆ งานที่เราป้อนให้ AI ทั้งวันไม่ได้ยากเท่ากันหมด อ่านไฟล์ยาวแล้วสรุป จัดหมวดของกองใหญ่ แปลงข้อมูลจากรูปแบบหนึ่งไปอีกรูปแบบ งานพวกนี้ต้องการความอึดกับความสม่ำเสมอ ไม่ได้ต้องการการตัดสินใจที่คมที่สุดในตลาด
การจ่ายราคาสมองที่แพงที่สุดให้กับงานที่ไม่ต้องใช้มัน เป็นค่าใช้จ่ายที่มองไม่เห็นง่ายๆ เพราะไม่เคยโผล่มาเป็นบิลก้อนเดียวให้ตกใจ แต่ค่อยๆ กินไปทีละงานเล็กๆ ที่เราไม่ได้คิดอะไร
เราเลยแยกโควตาของโมเดลถูกไว้อีกก้อนหนึ่ง แล้วทำทางเข้าที่สองไว้บนเครื่องเดียวกัน งานประเภทอึดๆ ส่งไปทางนั้น ส่วนสมองหลักเก็บไว้กับงานที่ผิดแล้วเสียหาย เช่น ตัดสินใจเรื่องโครงสร้าง แก้บั๊กที่พันกันหลายไฟล์ หรืออะไรก็ตามที่จะถึงมือคนอื่นต่อ
พอมีสองสมองอยู่บนเครื่องเดียวกัน คำถามถัดมาก็โผล่ขึ้นเอง คือระหว่างที่ทำงานอยู่ จะย้ายจากตัวหนึ่งไปอีกตัวยังไงโดยไม่ต้องทิ้งงานที่ค้างอยู่
ช่วงที่ 2สลับโมเดลกลาง session ได้ไหม
ไม่ได้ และเหตุผลอยู่ที่ลำดับการอ่านค่า ไม่ใช่ที่ฟีเจอร์ที่ยังไม่มีใครทำ ตัวโปรแกรมอ่านที่อยู่ปลายทางกับกุญแจตอนที่มันเริ่มทำงาน จากนั้นก็ถือค่าชุดนั้นไว้ทั้งรอบ ถ้าอยากเปลี่ยนปลายทาง ก็ต้องมีโปรแกรมตัวใหม่ที่เริ่มต้นด้วยค่าอีกชุด
สิ่งที่ทำให้ qlaude กลายเป็นคนละสมอง คือค่า 3 ตัวที่วางไว้หน้าคำสั่งเดิม
| ค่าที่ตั้ง | มันบอกอะไร |
|---|---|
ANTHROPIC_BASE_URL | ยิงคำถามไปที่ไหน |
ANTHROPIC_AUTH_TOKEN | ใช้กุญแจดอกไหนเข้า |
ANTHROPIC_MODEL | ขอโมเดลตัวไหน |
3 บรรทัดนี้วางไว้หน้าคำสั่งเดิม ก็ได้โปรแกรมเดิมที่สมองเปลี่ยนไปแล้ว วิธีนี้เป็นทางที่คู่มือเขียนไว้เองสำหรับการต่อผ่านทางเข้าของทีมหรือของผู้ให้บริการอื่น
แล้วทำไมไม่เขียน hook ให้มันสลับตามชนิดงาน
เพราะ hook วิ่งอยู่ในโปรแกรมที่เริ่มทำงานไปแล้ว มันสั่งให้โปรแกรมที่กำลังรันอยู่เปลี่ยนปลายทางของตัวเองไม่ได้ สิ่งที่ hook ทำได้จริงคือดักคำสั่งแล้วส่งงานออกไปให้โปรแกรมตัวอื่นทำแทน นั่นไม่ใช่การสลับสมอง แต่เป็นการจ่ายงานต่างหาก และการจ่ายงานเป็นคนละเรื่องกับการเปลี่ยนตัวเอง
ท่าที่ฟังดูฉลาดที่สุดมักเป็นท่าที่ยังไม่ได้ถามว่ากลไกข้างล่างยอมไหม
ตอนตอบรอบแรกเราเองก็เสนอตัวห่อ (โค้ดที่ครอบคำสั่งเดิมไว้อีกชั้น) ที่จะหา session เดิมให้อัตโนมัติ ทั้งที่คำสั่งมาตรฐานมีตัวเลือกทำสิ่งนั้นอยู่แล้ว กว่าจะเจอก็ตอนไล่ดูรอบสอง ความรู้สึกตอนนั้นคือเหมือนเตรียมกุญแจสำรองให้ประตูที่ไม่ได้ล็อก
และเราตัดอีกทางออกไปด้วย คือทางที่ออกจากรอบแล้วเปิดใหม่ต่อจากเดิม เหตุผลตรงไปตรงมา งานที่ค้างอยู่ในความจำของโปรแกรมที่กำลังรันอยู่มีมูลค่า การออกแล้วเข้าใหม่คือการยอมจ่ายค่าตั้งต้นทุกครั้ง เมื่อทางนั้นถูกตัด โจทย์ก็เหลือชัดขึ้น คือทำยังไงให้มีสองสมองใช้ได้ โดยไม่ต้องฆ่าอันไหนเลย
ช่วงที่ 3ท่าที่หนึ่ง เปิดสองสมอง ไว้ข้างกัน
ถ้าสลับไม่ได้ ก็ไม่ต้องสลับ เปิดทั้ง 2 ตัวไว้พร้อมกันคนละช่อง แล้วย้ายสายตาแทนที่จะย้ายกระบวนการ
เราเขียนคำสั่งสั้นๆ ตัวหนึ่งที่ทำสองอย่าง ถ้าในหน้าต่างนี้มีช่องที่รัน qlaude อยู่แล้ว ให้กระโดดไปที่ช่องนั้น ถ้ายังไม่มี ให้ผ่าหน้าต่างเปิดช่องใหม่ที่โฟลเดอร์เดียวกัน ผลคือกดครั้งแรกได้ช่องใหม่ กดครั้งที่สองได้กระโดดกลับไปช่องเดิม ไม่ใช่ช่องที่สาม
ข้อดีที่ไม่ได้ตั้งใจออกแบบ คือบทสนทนาสองสายไม่ปนกัน ฝั่งหนึ่งคุยเรื่องสถาปัตยกรรมอยู่ อีกฝั่งไล่แก้ไฟล์ config ไปเรื่อยๆ ต่างคนต่างจำเรื่องของตัวเอง
บั๊กที่เทสของตัวเอง จับได้ก่อนใครจะเจอ
รอบแรกที่เขียน ตัวหาช่องเดิมมันอ่านผิดคอลัมน์ ผลคือหาไม่เจอทุกครั้ง แล้วเปิดช่องใหม่เรื่อยๆ กดสามทีได้ 3 ช่อง เราเจอเพราะทดสอบสองด้าน ด้านหนึ่งคือกดตอนยังไม่มีช่อง ต้องได้ช่องใหม่ อีกด้านคือกดตอนมีช่องอยู่แล้ว ต้องไม่ได้ช่องเพิ่ม
ด้านที่สองนี่แหละที่จับบั๊กได้ ถ้าทดสอบแต่ด้านที่คาดว่าจะผ่าน ตัวเลขจะเขียวสวยตั้งแต่รอบแรก แล้วบั๊กจะไปโผล่ตอนมีคนกดใช้จริง การทดสอบที่บอกได้แค่ว่าของทำงาน ยังไม่ได้บอกว่าของทำงานถูก
ช่วงที่ 4ท่าที่สอง ให้ตัวสั่งงาน เด้งเอง
ท่าแรกแก้เรื่องคนนั่งทำงาน ท่าที่สองแก้เรื่องงานที่จ่ายออกไปแบบสั่งครั้งเดียวจบ ซึ่งเป็นงานส่วนใหญ่ที่เราให้โมเดลถูกทำ เช่น อ่านไฟล์ยาวแล้วสรุป จัดหมวดของกองใหญ่ แปลงรูปแบบข้อมูล
ตัวสั่งงานของเราสั้นมาก ตรรกะทั้งหมดมี 3 บรรทัด
- ยิงงานไปที่โมเดลถูกก่อน แบบสั่งครั้งเดียวจบ
- ถ้ามันจบด้วยรหัสสำเร็จ และมีคำตอบกลับมาจริง ก็ส่งคำตอบนั้นออกไป
- ถ้าไม่ใช่ทั้งสองอย่าง พิมพ์บอกว่ากำลังเด้ง แล้วยิงงานเดิมไปที่โมเดลหลักแทน
สองรายละเอียดในนั้นสำคัญกว่าที่หน้าตามันบอก
อย่างแรก เงื่อนไขไม่ได้ดูแค่รหัสสำเร็จ แต่ดูว่ามีคำตอบกลับมาด้วยไหม เพราะโปรแกรมที่จบสวยแต่คืนค่าว่าง คือโปรแกรมที่ล้มโดยไม่บอก ถ้าเชื่อรหัสอย่างเดียว เราจะส่งความว่างเปล่าต่อไปให้คนถามโดยไม่มีใครรู้
อย่างที่สอง ตัวสั่งงานไม่จำสถานะ ทุกครั้งที่เรียกใหม่ ก็ลองโมเดลถูกก่อนเสมอ ตอนออกแบบเราเถียงกับตัวเองอยู่พักหนึ่ง ว่าถ้ารู้แล้วว่าโควตาหมด จะยังลองซ้ำทำไม คำตอบคือเพราะสถานะที่จำไว้จะเก่าโดยไม่มีใครไปบอก โควตารีเซ็ตกลางดึกแล้วเราไม่รู้ ก็จะใช้ของแพงข้ามวันไปฟรีๆ การลองใหม่ทุกครั้งเสียเวลาไม่กี่วินาที แต่ได้ความจริงที่สดเสมอ
ตัวล่อที่เราไม่ต้องสร้าง เพราะมันเกิดขึ้นเอง
ปกติเวลาเขียนกลไกสำรอง เราต้องแกล้งทำให้ของหลักพังเพื่อดูว่าตัวสำรองทำงานไหม เพราะกลไกสำรองที่ไม่เคยถูกเรียกใช้ กับกลไกสำรองที่พังอยู่ หน้าตาเหมือนกันเป๊ะ ทั้งคู่เงียบเหมือนกัน
รอบนี้เราไม่ต้องแกล้ง วันแรกที่เขียนเสร็จ โควตาของแผนที่ซื้อไว้หมดพอดี งานถัดไปที่ยิงออกไปจึงโดนปฏิเสธจริง ตัวสั่งงานพิมพ์บรรทัดบอกว่ากำลังเด้ง แล้วงานก็เดินต่อจนจบด้วยโมเดลหลัก
กลไกสำรองที่ไม่เคยถูกเรียกใช้ ยังไม่นับว่ามีอยู่ มันเป็นแค่โค้ดที่เราหวังว่าจะทำงาน
เราจดเรื่องนี้ไว้ในบันทึกของวันนั้นด้วยคำว่าพิสูจน์แล้ว ต่างจากอีกหลายอย่างในวันเดียวกันที่จดได้แค่ว่าเขียนเสร็จแล้วแต่ยังไม่มีใครกด สองคำนี้ไม่เท่ากัน และเวลาผ่านไปสองสัปดาห์เราจะแยกไม่ออกเลยถ้าไม่เขียนแยกไว้ตั้งแต่แรก
ช่วงที่ 5แล้วลูกน้องล่ะ เด้งเองได้ไหม
ไม่ได้ และนี่คือชั้นที่ต่างจากสองท่าข้างบนที่สุด ตัวช่วยย่อยที่ตัวหลักปั่นออกมาไม่ได้เป็นโปรแกรมใหม่ที่อ่านค่าเองรอบหนึ่ง มันเกิดอยู่ในบ้านของตัวหลัก แปลว่ามันจะเด้งไปหาปลายทางอื่นด้วยตัวเองไม่ได้เลย
ที่หนักกว่านั้นคือเวลามันไปไม่รอด มันไม่ได้ส่งเสียง เราเจอตอนสั่งลูกน้อง 6 ตัวให้ช่วยกันอ่านหนังสือทั้งเล่ม ตัวที่ถูกกำหนดให้ใช้โมเดลระดับที่ปลายทางนั้นไม่มี จะตายตั้งแต่วินาทีแรกด้วยข้อความว่าไม่มีโมเดลนี้ ส่วนตัวที่ถูกกำหนดให้ใช้โมเดลที่ปลายทางนั้นมีจริง ก็ทำงานได้ปกติทั้งคืน
ความเงียบของลูกน้องที่กำลังคิดอยู่ กับความเงียบของลูกน้องที่ตายไปแล้ว หน้าตาเหมือนกันจากที่นั่งของคนสั่ง เพราะฉะนั้นตัวสั่งงานต้องมีสัญญาณที่สาม
ของเราใช้สัญญาณง่ายที่สุดเท่าที่จะหาได้ คือไฟล์บันทึกของลูกน้องแต่ละตัวต้องโตขึ้นภายในสองถึงสามนาที ตัวไหนไฟล์นิ่ง สั่งใหม่ทันที แล้วเปลี่ยนไปใช้โมเดลอีกตัวที่อยู่ในแผนเหมาจ่ายที่จ่ายไปแล้ว จะได้ไม่มีค่าใช้จ่ายเพิ่ม
วันเดียวกันนั้น เราเกือบวัดผิดตัว
ตอนไปดูขนาดไฟล์รอบแรก เราได้เลข 115 ไบต์เท่ากันหมดทั้ง 6 ตัว สมองกระโดดไปที่คำว่าตายยกชุดทันที เพราะรูปนี้ตรงกับปัญหาที่เคยเจอมาก่อนพอดี
เราพิมพ์ประโยครายงานออกไปแล้วด้วยซ้ำ สิ่งที่ช่วยไว้คือเปิดไฟล์ 115 ไบต์นั้นดูจริง แล้วพบว่ามันเป็นทางลัดที่ชี้ไปหาไฟล์จริงอีกที ไฟล์จริงตัวละสองสามแสนไบต์ และกำลังโตอยู่ทุกตัว
เลขที่เท่ากันเป๊ะทุกตัวอย่าง คือสัญญาณว่าเรากำลังวัดกล่อง ไม่ได้วัดของข้างใน
ช่วงที่ 6หลักที่เหลืออยู่ กับ 5 ข้อ ที่เอาไปใช้ได้
สิ่งที่เหลือจากวันนั้นไม่ใช่โค้ด 30 บรรทัด แต่เป็นการยอมรับข้อหนึ่งที่ตอนแรกฟังดูเหมือนแพ้ คือการเลือกโมเดลเป็นกติกาของคนสั่งงาน ไม่ใช่ความสามารถของโครงสร้าง
เรารู้เรื่องนี้อยู่แล้วโดยไม่รู้ตัว เพราะอีกสายงานหนึ่งที่เราส่งงานให้ AI คนละค่ายช่วยรีวิวโค้ด ไม่มีกลไกอัตโนมัติอะไรเลยสักอย่าง มีแค่ประโยคที่จดไว้ในคู่มือว่างานแบบนี้ส่งให้ใคร แล้วเราก็ทำตามมาตลอด สายนั้นไม่เคยพัง ไม่ใช่เพราะระบบแข็งแรง แต่เพราะกติกาชัดและมีคนถือ
5 ข้อที่ยกออกมาใช้กับระบบอื่นได้เลย
- แยกให้ออกว่าอะไรอ่านตอนเปิด อะไรอ่านตอนสั่ง ค่าที่อ่านตอนเปิดจะเปลี่ยนกลางทางไม่ได้ ไม่ว่าจะเขียนโค้ดเก่งแค่ไหน
- วางกลไกสำรองไว้ที่ฝั่งที่สั่ง ไม่ใช่ฝั่งที่ถูกสั่ง คนที่รู้ว่างานล้มคือคนที่กดสั่ง ไม่ใช่คนที่ล้มต่างหาก
- อย่าให้มันจำว่าเมื่อกี้ล้ม ลองของถูกใหม่ทุกครั้ง สถานะที่จำไว้จะเก่าเงียบๆ แล้วพาไปใช้ของแพงเกินจำเป็น
- รหัสสำเร็จอย่างเดียวยังไม่พอ ต้องมีคำตอบกลับมาด้วย ของที่จบสวยแต่ว่างเปล่าคือของที่ล้มโดยไม่บอก
- ชั้นที่เด้งเองไม่ได้ ต้องมีคนคอยจับชีพจร เลือกสัญญาณที่โกหกยาก เช่น ไฟล์โตขึ้นจริงไหมในสองสามนาที และตรวจให้แน่ว่ากำลังวัดของจริง ไม่ใช่วัดทางลัดที่ชี้ไปหามัน
เริ่มจากตรงไหนดี
ถ้าอยากลองวันนี้โดยไม่แตะระบบจริง หยิบงานที่พลาดได้มาหนึ่งอย่าง เช่น สรุปไฟล์บันทึกการรัน แล้วเขียนตัวสั่งงานสั้นๆ ที่ลองโมเดลถูกก่อนและเด้งไปโมเดลหลักเมื่อล้ม จากนั้นทำสิ่งที่สำคัญที่สุด คือแกล้งใส่กุญแจผิด 1 รอบ แล้วดูว่ามันเด้งจริงไหม ถ้ายังไม่เคยเห็นมันเด้ง ก็ยังไม่รู้ว่ามันเด้งเป็น
เรื่องว่างานไหนควรคู่กับโมเดลไหน กับกติกาที่เราใช้แบ่งงบระหว่างของเหมาจ่าย ของฟรีในเครื่อง และของจ่ายตามใช้ เราเขียนแยกไว้แล้วที่ LLM 14 ตัว เงินก้อนเดียว แบ่งงานยังไงให้ถูกตัว บทความนี้คือส่วนที่ต่อจากตรงนั้น คือพอแบ่งงานเสร็จแล้ว ตัวที่ควรทำมันดันไม่ว่าง จะทำยังไงต่อ
ที่มาและอ้างอิง
- Anthropic, Connect to an LLM gateway ที่มาของการตั้ง
ANTHROPIC_BASE_URLคู่กับANTHROPIC_AUTH_TOKENทั้งแบบตั้งในเชลล์และแบบเขียนลงไฟล์ตั้งค่า - Anthropic, Third-party integrations รายการค่าที่ใช้ชี้ปลายทางไปหาทางเข้าของทีมหรือของผู้ให้บริการอื่น
- Anthropic, Claude Code settings ที่มาของ
ANTHROPIC_MODELดึงเมื่อ 7 ส.ค. 2026 - เรื่องโควตาหมดกลางทาง การเด้งที่ยิงติดจริง บั๊กช่องซ้ำที่เทสของตัวเองจับได้ ลูกน้องที่ตายเงียบเพราะปลายทางไม่มีโมเดลนั้น และเคสวัดขนาดทางลัดผิดตัว ทั้งหมดวัดเองจากงานจริงเมื่อ 7 ส.ค. 2026 ไม่ใช่ตัวเลขที่ยกมาจากที่อื่น