เมื่อวานเราตั้งคำถามสั้นๆ ว่า "เราสลับการใช้ claude กับ qlaude แบบที่ไม่ต้องออกจาก session เลยไม่ได้เหรอ" โดย qlaude คือสมองตัวที่สองที่เราทำไว้บนเครื่องเดียวกัน ช่วงแรกของบทความจะเล่าว่ามันคืออะไรและมีไว้ทำไม
คำถามฟังดูเล็ก แต่พอไล่ดูของจริง ก็พาไปเจอเส้นแบ่งที่คนทำระบบ AI หลายคนน่าจะเคยชนเหมือนกัน คือเส้นระหว่างสิ่งที่แก้ได้ด้วยการเขียนโค้ดเพิ่ม กับสิ่งที่ต้องยอมรับว่าเครื่องมือเป็นแบบนั้น แล้วออกแบบวิธีทำงานรอบข้อจำกัดนั้นแทน
บทความนี้เริ่มจากอธิบายก่อนว่าสมองตัวที่สองคืออะไรและมีไว้ทำไม แล้วค่อยเล่าสามอย่าง อย่างแรกคือทำไมการสลับโมเดลกลางทางถึงทำไม่ได้ อย่างที่สองคือสองท่าที่เราใช้จริงแทนปุ่มนั้น และอย่างที่สามคือชั้นที่การเด้งอัตโนมัติทำงานไม่ได้เลย ซึ่งเป็นชั้นที่คนสั่งงานต้องลงมือตรวจเอง
ช่วงที่ 1qlaude คืออะไร และเราทำมันขึ้นมาทำไม
qlaude ไม่ใช่โปรแกรมใหม่ มันคือโปรแกรมช่วยเขียนโค้ดตัวเดิมที่เราเปิดใช้ทุกวัน แต่ถูกเรียกด้วยค่าคนละชุด ให้ไปคุยกับโมเดลคนละตัวที่ปลายทางคนละที่ ชื่อเล่นมาจากตัว q ของ Qwen โมเดลที่มันไปคุยด้วย หน้าตาเวลาใช้เหมือนกันทุกอย่าง ต่างกันแค่ข้างในคิดด้วยสมองคนละก้อน
เหตุผลที่ทำคือเรื่องเงินล้วนๆ งานที่เราป้อนให้ AI ทั้งวันไม่ได้ยากเท่ากันหมด อ่านไฟล์ยาวแล้วสรุป จัดหมวดของกองใหญ่ แปลงข้อมูลจากรูปแบบหนึ่งไปอีกรูปแบบ งานพวกนี้ต้องการความอึดกับความสม่ำเสมอ ไม่ได้ต้องการการตัดสินใจที่คมที่สุดในตลาด
การจ่ายราคาสมองที่แพงที่สุดให้กับงานที่ไม่ต้องใช้มัน เป็นค่าใช้จ่ายที่มองไม่เห็นง่ายๆ เพราะไม่เคยโผล่มาเป็นบิลก้อนเดียวให้ตกใจ แต่ค่อยๆ กินไปทีละงานเล็กๆ ที่เราไม่ได้คิดอะไร
เราเลยแยกโควตาของโมเดลถูกไว้อีกก้อนหนึ่ง แล้วทำทางเข้าที่สองไว้บนเครื่องเดียวกัน งานประเภทอึดๆ ส่งไปทางนั้น ส่วนสมองหลักเก็บไว้กับงานที่ผิดแล้วเสียหาย เช่น ตัดสินใจเรื่องโครงสร้าง แก้บั๊กที่พันกันหลายไฟล์ หรืออะไรก็ตามที่จะถึงมือคนอื่นต่อ
พอมีสองสมองอยู่บนเครื่องเดียวกัน คำถามถัดมาก็โผล่ขึ้นเอง คือระหว่างที่ทำงานอยู่ จะย้ายจากตัวหนึ่งไปอีกตัวยังไงโดยไม่ต้องทิ้งงานที่ค้างอยู่
ช่วงที่ 2สลับโมเดลกลาง session ได้ไหม
ไม่ได้ และเหตุผลอยู่ที่ลำดับการอ่านค่า ไม่ใช่ที่ฟีเจอร์ที่ยังไม่มีใครทำ ตัวโปรแกรมอ่านที่อยู่ปลายทางกับกุญแจตอนที่มันเริ่มทำงาน จากนั้นก็ถือค่าชุดนั้นไว้ทั้งรอบ ถ้าอยากเปลี่ยนปลายทาง ก็ต้องมีโปรแกรมตัวใหม่ที่เริ่มต้นด้วยค่าอีกชุด
สิ่งที่ทำให้ qlaude กลายเป็นคนละสมอง คือค่าสามตัวที่วางไว้หน้าคำสั่งเดิม
| ค่าที่ตั้ง | มันบอกอะไร |
|---|---|
ANTHROPIC_BASE_URL | ยิงคำถามไปที่ไหน |
ANTHROPIC_AUTH_TOKEN | ใช้กุญแจดอกไหนเข้า |
ANTHROPIC_MODEL | ขอโมเดลตัวไหน |
สามบรรทัดนี้วางไว้หน้าคำสั่งเดิม ก็ได้โปรแกรมเดิมที่สมองเปลี่ยนไปแล้ว วิธีนี้เป็นทางที่คู่มือเขียนไว้เองสำหรับการต่อผ่านทางเข้าของทีมหรือของผู้ให้บริการอื่น
แล้วทำไมไม่เขียน hook ให้มันสลับตามชนิดงาน
เพราะ hook วิ่งอยู่ในโปรแกรมที่เริ่มทำงานไปแล้ว มันสั่งให้โปรแกรมที่กำลังรันอยู่เปลี่ยนปลายทางของตัวเองไม่ได้ สิ่งที่ hook ทำได้จริงคือดักคำสั่งแล้วส่งงานออกไปให้โปรแกรมตัวอื่นทำแทน นั่นไม่ใช่การสลับสมอง แต่เป็นการจ่ายงานต่างหาก และการจ่ายงานเป็นคนละเรื่องกับการเปลี่ยนตัวเอง
ท่าที่ฟังดูฉลาดที่สุดมักเป็นท่าที่ยังไม่ได้ถามว่ากลไกข้างล่างยอมไหม
ตอนตอบรอบแรกเราเองก็เสนอตัวห่อ (โค้ดที่ครอบคำสั่งเดิมไว้อีกชั้น) ที่จะหา session เดิมให้อัตโนมัติ ทั้งที่คำสั่งมาตรฐานมีตัวเลือกทำสิ่งนั้นอยู่แล้ว กว่าจะเจอก็ตอนไล่ดูรอบสอง ความรู้สึกตอนนั้นคือเหมือนเตรียมกุญแจสำรองให้ประตูที่ไม่ได้ล็อก
และเราตัดอีกทางออกไปด้วย คือทางที่ออกจากรอบแล้วเปิดใหม่ต่อจากเดิม เหตุผลตรงไปตรงมา งานที่ค้างอยู่ในความจำของโปรแกรมที่กำลังรันอยู่มีมูลค่า การออกแล้วเข้าใหม่คือการยอมจ่ายค่าตั้งต้นทุกครั้ง เมื่อทางนั้นถูกตัด โจทย์ก็เหลือชัดขึ้น คือทำยังไงให้มีสองสมองใช้ได้ โดยไม่ต้องฆ่าอันไหนเลย
ช่วงที่ 3ท่าที่หนึ่ง เปิดสองสมอง ไว้ข้างกัน
ถ้าสลับไม่ได้ ก็ไม่ต้องสลับ เปิดทั้งสองตัวไว้พร้อมกันคนละช่อง แล้วย้ายสายตาแทนที่จะย้ายกระบวนการ
เราเขียนคำสั่งสั้นๆ ตัวหนึ่งที่ทำสองอย่าง ถ้าในหน้าต่างนี้มีช่องที่รัน qlaude อยู่แล้ว ให้กระโดดไปที่ช่องนั้น ถ้ายังไม่มี ให้ผ่าหน้าต่างเปิดช่องใหม่ที่โฟลเดอร์เดียวกัน ผลคือกดครั้งแรกได้ช่องใหม่ กดครั้งที่สองได้กระโดดกลับไปช่องเดิม ไม่ใช่ช่องที่สาม
ข้อดีที่ไม่ได้ตั้งใจออกแบบ คือบทสนทนาสองสายไม่ปนกัน ฝั่งหนึ่งคุยเรื่องสถาปัตยกรรมอยู่ อีกฝั่งไล่แก้ไฟล์ config ไปเรื่อยๆ ต่างคนต่างจำเรื่องของตัวเอง
บั๊กที่เทสของตัวเอง จับได้ก่อนใครจะเจอ
รอบแรกที่เขียน ตัวหาช่องเดิมมันอ่านผิดคอลัมน์ ผลคือหาไม่เจอทุกครั้ง แล้วเปิดช่องใหม่เรื่อยๆ กดสามทีได้สามช่อง เราเจอเพราะทดสอบสองด้าน ด้านหนึ่งคือกดตอนยังไม่มีช่อง ต้องได้ช่องใหม่ อีกด้านคือกดตอนมีช่องอยู่แล้ว ต้องไม่ได้ช่องเพิ่ม
ด้านที่สองนี่แหละที่จับบั๊กได้ ถ้าทดสอบแต่ด้านที่คาดว่าจะผ่าน ตัวเลขจะเขียวสวยตั้งแต่รอบแรก แล้วบั๊กจะไปโผล่ตอนมีคนกดใช้จริง การทดสอบที่บอกได้แค่ว่าของทำงาน ยังไม่ได้บอกว่าของทำงานถูก
ช่วงที่ 4ท่าที่สอง ให้ตัวสั่งงาน เด้งเอง
ท่าแรกแก้เรื่องคนนั่งทำงาน ท่าที่สองแก้เรื่องงานที่จ่ายออกไปแบบสั่งครั้งเดียวจบ ซึ่งเป็นงานส่วนใหญ่ที่เราให้โมเดลถูกทำ เช่น อ่านไฟล์ยาวแล้วสรุป จัดหมวดของกองใหญ่ แปลงรูปแบบข้อมูล
ตัวสั่งงานของเราสั้นมาก ตรรกะทั้งหมดมีสามบรรทัด
- ยิงงานไปที่โมเดลถูกก่อน แบบสั่งครั้งเดียวจบ
- ถ้ามันจบด้วยรหัสสำเร็จ และมีคำตอบกลับมาจริง ก็ส่งคำตอบนั้นออกไป
- ถ้าไม่ใช่ทั้งสองอย่าง พิมพ์บอกว่ากำลังเด้ง แล้วยิงงานเดิมไปที่โมเดลหลักแทน
สองรายละเอียดในนั้นสำคัญกว่าที่หน้าตามันบอก
อย่างแรก เงื่อนไขไม่ได้ดูแค่รหัสสำเร็จ แต่ดูว่ามีคำตอบกลับมาด้วยไหม เพราะโปรแกรมที่จบสวยแต่คืนค่าว่าง คือโปรแกรมที่ล้มโดยไม่บอก ถ้าเชื่อรหัสอย่างเดียว เราจะส่งความว่างเปล่าต่อไปให้คนถามโดยไม่มีใครรู้
อย่างที่สอง ตัวสั่งงานไม่จำสถานะ ทุกครั้งที่เรียกใหม่ ก็ลองโมเดลถูกก่อนเสมอ ตอนออกแบบเราเถียงกับตัวเองอยู่พักหนึ่ง ว่าถ้ารู้แล้วว่าโควตาหมด จะยังลองซ้ำทำไม คำตอบคือเพราะสถานะที่จำไว้จะเก่าโดยไม่มีใครไปบอก โควตารีเซ็ตกลางดึกแล้วเราไม่รู้ ก็จะใช้ของแพงข้ามวันไปฟรีๆ การลองใหม่ทุกครั้งเสียเวลาไม่กี่วินาที แต่ได้ความจริงที่สดเสมอ
ตัวล่อที่เราไม่ต้องสร้าง เพราะมันเกิดขึ้นเอง
ปกติเวลาเขียนกลไกสำรอง เราต้องแกล้งทำให้ของหลักพังเพื่อดูว่าตัวสำรองทำงานไหม เพราะกลไกสำรองที่ไม่เคยถูกเรียกใช้ กับกลไกสำรองที่พังอยู่ หน้าตาเหมือนกันเป๊ะ ทั้งคู่เงียบเหมือนกัน
รอบนี้เราไม่ต้องแกล้ง วันแรกที่เขียนเสร็จ โควตาของแผนที่ซื้อไว้หมดพอดี งานถัดไปที่ยิงออกไปจึงโดนปฏิเสธจริง ตัวสั่งงานพิมพ์บรรทัดบอกว่ากำลังเด้ง แล้วงานก็เดินต่อจนจบด้วยโมเดลหลัก
กลไกสำรองที่ไม่เคยถูกเรียกใช้ ยังไม่นับว่ามีอยู่ มันเป็นแค่โค้ดที่เราหวังว่าจะทำงาน
เราจดเรื่องนี้ไว้ในบันทึกของวันนั้นด้วยคำว่าพิสูจน์แล้ว ต่างจากอีกหลายอย่างในวันเดียวกันที่จดได้แค่ว่าเขียนเสร็จแล้วแต่ยังไม่มีใครกด สองคำนี้ไม่เท่ากัน และเวลาผ่านไปสองสัปดาห์เราจะแยกไม่ออกเลยถ้าไม่เขียนแยกไว้ตั้งแต่แรก
ช่วงที่ 5แล้วลูกน้องล่ะ เด้งเองได้ไหม
ไม่ได้ และนี่คือชั้นที่ต่างจากสองท่าข้างบนที่สุด ตัวช่วยย่อยที่ตัวหลักปั่นออกมาไม่ได้เป็นโปรแกรมใหม่ที่อ่านค่าเองรอบหนึ่ง มันเกิดอยู่ในบ้านของตัวหลัก แปลว่ามันจะเด้งไปหาปลายทางอื่นด้วยตัวเองไม่ได้เลย
ที่หนักกว่านั้นคือเวลามันไปไม่รอด มันไม่ได้ส่งเสียง เราเจอตอนสั่งลูกน้องหกตัวให้ช่วยกันอ่านหนังสือทั้งเล่ม ตัวที่ถูกกำหนดให้ใช้โมเดลระดับที่ปลายทางนั้นไม่มี จะตายตั้งแต่วินาทีแรกด้วยข้อความว่าไม่มีโมเดลนี้ ส่วนตัวที่ถูกกำหนดให้ใช้โมเดลที่ปลายทางนั้นมีจริง ก็ทำงานได้ปกติทั้งคืน
ความเงียบของลูกน้องที่กำลังคิดอยู่ กับความเงียบของลูกน้องที่ตายไปแล้ว หน้าตาเหมือนกันจากที่นั่งของคนสั่ง เพราะฉะนั้นตัวสั่งงานต้องมีสัญญาณที่สาม
ของเราใช้สัญญาณง่ายที่สุดเท่าที่จะหาได้ คือไฟล์บันทึกของลูกน้องแต่ละตัวต้องโตขึ้นภายในสองถึงสามนาที ตัวไหนไฟล์นิ่ง สั่งใหม่ทันที แล้วเปลี่ยนไปใช้โมเดลอีกตัวที่อยู่ในแผนเหมาจ่ายที่จ่ายไปแล้ว จะได้ไม่มีค่าใช้จ่ายเพิ่ม
วันเดียวกันนั้น เราเกือบวัดผิดตัว
ตอนไปดูขนาดไฟล์รอบแรก เราได้เลข 115 ไบต์เท่ากันหมดทั้งหกตัว สมองกระโดดไปที่คำว่าตายยกชุดทันที เพราะรูปนี้ตรงกับปัญหาที่เคยเจอมาก่อนพอดี
เราพิมพ์ประโยครายงานออกไปแล้วด้วยซ้ำ สิ่งที่ช่วยไว้คือเปิดไฟล์ 115 ไบต์นั้นดูจริง แล้วพบว่ามันเป็นทางลัดที่ชี้ไปหาไฟล์จริงอีกที ไฟล์จริงตัวละสองสามแสนไบต์ และกำลังโตอยู่ทุกตัว
เลขที่เท่ากันเป๊ะทุกตัวอย่าง คือสัญญาณว่าเรากำลังวัดกล่อง ไม่ได้วัดของข้างใน
ช่วงที่ 6หลักที่เหลืออยู่ กับห้าข้อ ที่เอาไปใช้ได้
สิ่งที่เหลือจากวันนั้นไม่ใช่โค้ดสามสิบบรรทัด แต่เป็นการยอมรับข้อหนึ่งที่ตอนแรกฟังดูเหมือนแพ้ คือการเลือกโมเดลเป็นกติกาของคนสั่งงาน ไม่ใช่ความสามารถของโครงสร้าง
เรารู้เรื่องนี้อยู่แล้วโดยไม่รู้ตัว เพราะอีกสายงานหนึ่งที่เราส่งงานให้ AI คนละค่ายช่วยรีวิวโค้ด ไม่มีกลไกอัตโนมัติอะไรเลยสักอย่าง มีแค่ประโยคที่จดไว้ในคู่มือว่างานแบบนี้ส่งให้ใคร แล้วเราก็ทำตามมาตลอด สายนั้นไม่เคยพัง ไม่ใช่เพราะระบบแข็งแรง แต่เพราะกติกาชัดและมีคนถือ
ห้าข้อที่ยกออกมาใช้กับระบบอื่นได้เลย
- แยกให้ออกว่าอะไรอ่านตอนเปิด อะไรอ่านตอนสั่ง ค่าที่อ่านตอนเปิดจะเปลี่ยนกลางทางไม่ได้ ไม่ว่าจะเขียนโค้ดเก่งแค่ไหน
- วางกลไกสำรองไว้ที่ฝั่งที่สั่ง ไม่ใช่ฝั่งที่ถูกสั่ง คนที่รู้ว่างานล้มคือคนที่กดสั่ง ไม่ใช่คนที่ล้มต่างหาก
- อย่าให้มันจำว่าเมื่อกี้ล้ม ลองของถูกใหม่ทุกครั้ง สถานะที่จำไว้จะเก่าเงียบๆ แล้วพาไปใช้ของแพงเกินจำเป็น
- รหัสสำเร็จอย่างเดียวยังไม่พอ ต้องมีคำตอบกลับมาด้วย ของที่จบสวยแต่ว่างเปล่าคือของที่ล้มโดยไม่บอก
- ชั้นที่เด้งเองไม่ได้ ต้องมีคนคอยจับชีพจร เลือกสัญญาณที่โกหกยาก เช่น ไฟล์โตขึ้นจริงไหมในสองสามนาที และตรวจให้แน่ว่ากำลังวัดของจริง ไม่ใช่วัดทางลัดที่ชี้ไปหามัน
เริ่มจากตรงไหนดี
ถ้าอยากลองวันนี้โดยไม่แตะระบบจริง หยิบงานที่พลาดได้มาหนึ่งอย่าง เช่น สรุปไฟล์บันทึกการรัน แล้วเขียนตัวสั่งงานสั้นๆ ที่ลองโมเดลถูกก่อนและเด้งไปโมเดลหลักเมื่อล้ม จากนั้นทำสิ่งที่สำคัญที่สุด คือแกล้งใส่กุญแจผิดหนึ่งรอบ แล้วดูว่ามันเด้งจริงไหม ถ้ายังไม่เคยเห็นมันเด้ง ก็ยังไม่รู้ว่ามันเด้งเป็น
เรื่องว่างานไหนควรคู่กับโมเดลไหน กับกติกาที่เราใช้แบ่งงบระหว่างของเหมาจ่าย ของฟรีในเครื่อง และของจ่ายตามใช้ เราเขียนแยกไว้แล้วที่ 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 ไม่ใช่ตัวเลขที่ยกมาจากที่อื่น