อย่า A/B test เวิร์กโฟลว์ของฉันเลย

 (backnotprop.com)
4 คะแนน โดย GN⁺ 2026-03-15 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • Claude Code ได้ รันการทดสอบ A/B โดยไม่ได้รับความยินยอมจากผู้ใช้ ทำให้พฤติกรรมของ plan mode เปลี่ยนไปโดยไม่มีการแจ้งล่วงหน้า และ ประสิทธิภาพการทำงานลดลง
  • สำหรับ เครื่องมือระดับมืออาชีพที่จ่ายเดือนละ $200 การเปลี่ยนแปลงฟีเจอร์หลักโดยไม่มีการแจ้งล่วงหน้าเป็นปัญหาในแง่ของความโปร่งใสและสิทธิในการควบคุมของผู้ใช้
  • หนึ่งในการทดสอบเป็นการปรับแบบรุนแรง โดยจำกัด plan ไว้ที่ 40 บรรทัด ห้ามมีส่วน context และสั่งให้ลบข้อความบรรยายออกให้เหลือเพียง path ของไฟล์
  • วิศวกร Anthropic ที่ทำการทดสอบนี้ระบุว่าเป้าหมายคือ ลดภาระจาก rate-limit แต่เมื่อผลลัพธ์เบื้องต้นพบว่าแทบไม่มีผลกระทบมากนัก จึงยุติการทดลอง
  • ย้ำว่าเพื่อให้เครื่องมือ AI มีความน่าเชื่อถือและถูกนำไปใช้อย่างมีความรับผิดชอบ จำเป็นต้องมี การควบคุมโดยผู้ใช้และการจัดการการทดลองอย่างโปร่งใส

ประสบการณ์ผู้ใช้ที่แย่ลงจากการทดสอบ A/B ของ Claude Code

  • ในฐานะผู้ใช้ตัวยงที่ Claude Code เปลี่ยนวิธีทำงานไปอย่างสิ้นเชิง ผู้เขียนเล่าว่าตลอดสัปดาห์ที่ผ่านมาได้พบกับ ประสบการณ์ที่เวิร์กโฟลว์แย่ลง
  • Anthropic กำลัง รันการทดสอบ A/B ใน Claude Code และส่งผลให้เวิร์กโฟลว์ของผู้ใช้แย่ลงอย่างชัดเจน
  • ตัวการทดสอบ A/B เองไม่ใช่สิ่งที่ผิด และไม่ใช่ว่า Anthropic ตั้งใจทำให้ประสบการณ์แย่ลง แต่ การออกแบบการทดสอบสำคัญมาก และปัญหาคือการเปลี่ยนพฤติกรรมที่ผู้ใช้รับรู้ได้ของฟีเจอร์หลักอย่าง plan mode โดยไม่อธิบายเหตุผล

ความต้องการความโปร่งใสสำหรับเครื่องมือแบบเสียเงิน

  • เพราะเป็น เครื่องมือทำงานระดับมืออาชีพ ที่จ่ายเดือนละ $200 จึงควรมีความโปร่งใสเกี่ยวกับวิธีการทำงานและสามารถตั้งค่าได้
  • ยากจะยอมรับได้เมื่อฟีเจอร์หลักถูกเปลี่ยนโดยไม่มีการแจ้งล่วงหน้า หรือถูกนำเข้าไปอยู่ในการทดสอบเชิงทำลายโดยไม่ได้รับความยินยอม
  • หากต้องการ steer เครื่องมือ AI อย่างมีความรับผิดชอบ ความโปร่งใสและความสามารถในการตั้งค่าเป็นหัวใจสำคัญ และควรสนับสนุนให้ผู้ใช้ทำเช่นนั้นได้
  • ทุกวันมีวิศวกรออกมา บ่นเรื่อง regression ของ Claude Code และบางคนไม่รู้ด้วยซ้ำว่าตัวเองอยู่ในการทดสอบ A/B หรือไม่

เนื้อหาการทดสอบและหลักฐาน

  • plan ที่สร้างขึ้นเริ่มกลับมาเป็นเพียง รายการหัวข้อย่อยแบบสั้นกระชับที่ไม่มี context
  • เมื่อถาม Claude ว่าทำไมถึงเขียน plan ได้แย่ขนาดนี้ มันตอบว่ากำลังทำตามคำสั่งระบบเฉพาะที่ ตั้ง hard cap ไว้ที่ 40 บรรทัด ห้ามมีส่วน context และระบุให้ "ลบข้อความบรรยายออกให้เหลือแค่ path ของไฟล์"
  • สำหรับวิธีการพิสูจน์หลักฐานอย่างละเอียด ผู้เขียนระบุว่าเรื่องนี้ได้รับความสนใจใน Hacker News จึง ลบรายละเอียดออก เพื่อไม่ให้คนอื่นลองทำตามแบบเดียวกัน
  • ผู้เขียนชี้ว่าวิธีการเช่นนี้ขัดกับความโปร่งใสและ การนำ AI ไปใช้/ใช้งานอย่างมีความรับผิดชอบ

ปฏิกิริยาบน Hacker News และมุมมองด้านต้นทุน

  • คอมเมนต์หนึ่งบน Hacker News ชี้ว่า Anthropic ต้อง ตัดสินใจเรื่อง throughput ในแต่ละขั้นของ Claude Code และถ้าตั้งทุกอย่างไว้สูงสุด ผู้ใช้หนึ่งรายอาจสร้างการขาดทุนมากขึ้นหรือกำไรน้อยลง
  • มีมุมมองว่า $200/เดือน อาจมี ต้นทุนจริงถึง $400/เดือน และการหา baseline ด้วยการทำ A/B test ในแต่ละส่วนของกระบวนการอาจเป็นแนวทางที่ดีกว่าการตั้งข้อจำกัดแบบตามใจ

คำตอบจากวิศวกร Anthropic

  • วิศวกร Claude Code ที่รันการทดสอบนี้ได้เข้ามาตอบโดยตรงในเธรด Hacker News
  • prompt ของ plan-mode แทบไม่ได้เปลี่ยนมากนักนับตั้งแต่โมเดล ซีรีส์ 3.x เป็นต้นมา และโมเดล 4.x สามารถทำงานได้สำเร็จด้วยคำสั่งที่น้อยกว่ามาก
  • สมมติฐานคือ หากทำให้ plan สั้นลง ก็อาจได้ผลลัพธ์ใกล้เคียงเดิมพร้อมกับ ลดจำนวนครั้งที่ชน rate-limit
  • มีการรันหลายรูปแบบ และผู้เขียนรายนี้ (รวมถึงผู้ใช้อีกหลายพันคน) ถูกจัดเข้าไปอยู่ในรูปแบบที่รุนแรงที่สุด ซึ่งจำกัด plan ไว้ที่ 40 บรรทัด
  • เมื่อผลลัพธ์ช่วงแรกพบว่าแทบไม่มีผลต่อ rate limit จึง ยุติการทดลอง
  • การวางแผน (planning) มีอยู่สองจุดประสงค์: ช่วยให้โมเดลรักษาทิศทางที่ถูกต้อง และช่วยให้ผู้ใช้ เชื่อมั่นในการกระทำถัดไปของโมเดล ซึ่งทั้งสองด้านล้วนเป็นพื้นที่ที่คลุมเครือ ซับซ้อน และไม่ตรงไปตรงมา

บทสรุป: ความรับผิดชอบของการทดลองในเครื่องมือ AI และความเชื่อมั่นของผู้ใช้

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

บทความที่เกี่ยวข้อง

1 ความคิดเห็น

 
GN⁺ 2026-03-15
ความคิดเห็นจาก Hacker News

  • คิดว่าการเรียก A/B test ว่าเป็น “การทดลองเงียบกับผู้ใช้” พร้อมยก Meta มาอ้างนั้นค่อนข้างเกินไป
    ตัว A/B test เองไม่ได้เลวร้าย และประเด็นสำคัญอยู่ที่ การออกแบบการทดสอบ
    แต่การทดลองที่ทำให้ประสิทธิภาพของ LLM แย่ลงอย่างชัดเจนนั้นเป็นสิ่งที่ยอมรับไม่ได้

    • สำหรับ LLM คิดว่าควรมองต่างออกไป
      ปัญหาเรื่อง ความทำซ้ำได้และความน่าเชื่อถือ ก็รุนแรงอยู่แล้ว แต่บริษัทกลับผลักภาระนั้นมาให้ผู้ใช้
      ในสถานการณ์แบบนี้ ถ้าบริษัทแอบทำการทดลอง ความน่าเชื่อถือของงานวิจัยก็จะพังทลายทันที
      ในกรณีของ Claude Code ต่อให้เกิดผลลัพธ์เชิงลบเพราะ A/B test ก็อาจถูกมองข้ามได้ด้วยเหตุผลว่า “อาจอยู่ในกลุ่มทดลอง”
      โดยเฉพาะถ้ามีการทดลองแบบนี้ในพื้นที่อ่อนไหวอย่างการจ้างงาน ปัญหาด้านจริยธรรมและกฎหมาย จะยิ่งรุนแรงมาก
    • คิดว่าบริษัทเทคยังคงไม่เข้าใจแนวคิดเรื่อง ‘ความยินยอมโดยชัดแจ้ง’ อย่างแท้จริง
    • ไม่ชอบ A/B test
      อยู่ ๆ UI หรือฟีเจอร์ก็เปลี่ยนไป พอไปถามเพื่อนร่วมงานก็ไม่มีใครรู้เรื่อง
      ปกติการเปลี่ยนแบบนี้มักจะแย่ลงด้วยซ้ำ แต่ก็ยังถูกยัดเยียดภายใต้ข้ออ้างว่าเป็น “ข้อมูลเชิงวัตถุวิสัย”
    • ไม่เข้าใจว่าทำไมถึงบอกว่า A/B test ไม่ใช่ “การทดลองเงียบกับผู้ใช้”
      ต่อให้เป็นองค์ประกอบเล็กน้อยอย่างสีของปุ่ม มันก็ยังเป็นการทดลองอยู่ดี และส่วนใหญ่ผู้ใช้ก็ ไม่แม้แต่จะรู้ว่ากำลังถูกทดลอง
    • ผู้เขียนต้นฉบับบอกว่าเห็นด้วยและจะปรับถ้อยคำ

  • นี่เป็นการทดสอบที่ฉันทำเอง
    ตั้งแต่ซีรีส์ 3.x มีการคงไว้ซึ่ง plan-mode prompt และได้ลองทดสอบว่าถ้าทำให้มันเรียบง่ายขึ้นในโมเดล 4.x จะยังได้ผลลัพธ์ใกล้เคียงเดิมหรือไม่
    เดาว่าถ้าแผนสั้นลงก็น่าจะโดน rate-limit น้อยลง แต่สุดท้ายไม่ต่างมากจึงยุติการทดลอง
    โหมดวางแผนมีจุดประสงค์อยู่สองอย่าง คือช่วยให้โมเดลจับทิศทาง และช่วยให้ผู้ใช้เชื่อถือผลลัพธ์

    • ข้อจำกัด 40 บรรทัดไม่ส่งผลต่อ rate-limit เป็นเรื่องที่คาดได้อยู่แล้ว
      ต้นทุนไม่ได้เกิดจากข้อความ plan แต่เกิดใน ขั้นสำรวจ (subagent)
      plan mode จะเรียกใช้งานเอเจนต์สำรวจ 3 ตัวเสมอ และไม่คำนึงถึงสถานะของเซสชัน
      ต่อให้มีไฟล์ที่โหลดไว้แล้วก็ยังอ่านใหม่ ทำให้ สิ้นเปลืองโทเค็น
      ถ้าเพิ่มตรรกะแบบมีเงื่อนไขเพื่อข้ามขั้นสำรวจเมื่อเซสชันยังอุ่นอยู่ น่าจะมีประสิทธิภาพกว่า
    • ฉันเป็น divergent thinker และใช้เวลาหลายร้อยชั่วโมงตั้งค่าข้อจำกัดใน claude.mds ดังนั้นการถูกสุ่มจับเข้าไปอยู่ในการทดลองแบบนี้จึงน่าตกใจมาก
      พฤติกรรมที่ไม่คาดคิดเพียงอย่างเดียวอาจทำให้ฉันทำงานไม่ได้ไปหลายวัน
      การไม่คำนึงถึงผลกระทบแบบนี้ถือว่า ไร้ความรับผิดชอบและก้าวร้าว
    • ควร คืนโทเค็น ที่ใช้ไปกับการทดสอบนี้หรือเปล่า?
    • การทดลองแบบนี้ควรมี ตัวเลือก opt-out
      ช่วงหลัง ๆ พฤติกรรมแปลก ๆ อาจเกิดจากการทดลองก็ได้ ซึ่งทำให้ไม่สบายใจมาก
      ไม่ควรใช้แบบเบต้าแชนเนล แต่ควรเปลี่ยนเป็น opt-in อย่างชัดเจน
    • ขอบคุณสำหรับความโปร่งใส
      ส่วนตัวคิดว่าความสำคัญไม่ได้อยู่ที่จำนวนบรรทัด แต่คือ ความชัดเจนเชิงเรื่องเล่าของแผน
      ต้องมีแผนที่ทำให้เข้าใจได้ว่ากำลังทำอะไรและทำไปทำไม

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

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

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

  • มีอยู่สองความคิด

    1. เครื่องมือโอเพนซอร์สช่วยแก้ปัญหาเรื่อง การทดลองโดยไม่สมัครใจ หรือการเปลี่ยนแปลงแบบไม่แจ้งล่วงหน้าได้
    2. แต่ด้วยเหตุผลเดียวกันนี้ โอเพนซอร์สก็อาจไปไม่ถึง คุณภาพระดับ Claude Code ได้ยาก
      เพราะไม่สามารถปรับปรุงแบบอิงข้อมูลผ่าน A/B test ในวงกว้างได้
    • ต่อให้เป็นโอเพนซอร์สก็ไม่ได้แปลว่า ทำซ้ำได้เสมอไป
      ตัวอย่างเช่น easter egg ‘after midnight’ ของ man-db ก็เป็นการเปลี่ยนแปลงที่คาดเดาไม่ได้
      แถมยังมี dependency มากมาย จึงแทบไม่มีใครตรวจสอบโค้ดอย่างจริงจัง
    • ยังมีมุกว่า “ลองทำ A/B test กับ Linux kernel ดูไหม”
    • A/B test ไม่ได้ทำเพื่อปรับปรุงผู้ใช้เสมอไป
      มันอาจเป็น การทดลองเพื่อหารายได้ (enshittification) ก็ได้ — YouTube คือหนึ่งในตัวอย่างชัดเจน

  • ตัว A/B test เองไม่มีปัญหา แต่ plan mode ไม่น่าประทับใจ
    ส่วนใหญ่ผลลัพธ์ออกมาแย่
    แต่ ความสามารถในการคงข้อมูลข้าม compaction กลับทำได้ดี
    ถ้าบันทึกบทสนทนาไว้ในไฟล์ Markdown แล้วอ้างอิงมันทุกครั้งที่มี compaction จะได้ผลลัพธ์ที่ดีกว่ามาก

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

  • เสียดายที่รายละเอียดเรื่อง decompile ในบล็อกถูกลบออกเพราะปัญหา ToS
    Claude ถูกบอกว่าทำตาม system prompt ที่ว่า “จำกัดแผนไว้ที่ 40 บรรทัด ห้ามมีส่วน context และลบข้อความร้อยแก้วออก”
    คงดีถ้าเราสามารถดูและแก้การตั้งค่าเหล่านี้ได้เอง

  • เครื่องมือสำหรับมืออาชีพควรให้ ความน่าเชื่อถือและความสามารถในการทำซ้ำ แต่ LLM ไม่ได้เป็นแบบนั้น
    A/B test ก็เป็นเพียงหลักฐานหนึ่งของเรื่องนี้

    • แก่นของปัญหาไม่ใช่ตัว LLM แต่คือ แอปที่แอบเปลี่ยนพฤติกรรม
      ไม่ว่าจะเป็น Photoshop ที่แอบปรับโทนสี หรือ Word ที่แอบเปลี่ยนสไตล์หัวข้อ การทดลองแบบนี้ก็เป็นปัญหาเดียวกัน
      ปัญหาคือ A/B test ที่เกิดขึ้นโดยไม่มีการเตือน
    • Anthropic มีปัญหาเรื่อง การขาดความโปร่งใส อย่างหนัก
      ทั้งเรื่องโควตา คุณภาพโมเดลที่ไม่เสถียร และก่อนเปิดตัวโมเดลใหม่ก็มักมีช่วงที่โมเดลเก่าพัง
      การทดลองครั้งนี้ก็ดูเหมือนเป็น การทดลองลดต้นทุน มากกว่าจะปรับปรุงประสบการณ์ผู้ใช้
      ถ้าเป็นเครื่องมือสำหรับธุรกิจ ก็ต้องมี ความสม่ำเสมอและความน่าเชื่อถือ
    • เครื่องมือที่อัปเดตอัตโนมัติย่อมเปลี่ยนพฤติกรรมโดยธรรมชาติ
      ถ้าเป็นมืออาชีพก็ควรเข้าใจ จุดแข็งและจุดอ่อน ของเครื่องมือและใช้อย่างเหมาะสม
      การยอมรับเอาต์พุตของ LLM แบบไม่ตั้งคำถามเป็นเรื่องไม่เป็นมืออาชีพ แต่ก็ไม่ได้หมายความว่ามืออาชีพจะใช้ LLM ไม่ได้
    • ความทำซ้ำได้เป็นสเปกตรัม
      หากมีระบบประเมินผลที่ดีพอและควบคุมพรอมป์ต์ได้ ก็ทำให้มันค่อนข้าง มีความกำหนดแน่นอน ได้
      เมื่อดูจากการที่โมเดลไม่เสถียรในภาคการเงินยังถูกนำไปใช้งานอยู่ ความคาดเดาไม่ได้ก็ไม่ใช่อุปสรรคแบบสัมบูรณ์
    • ถ้าเอาต์พุตของ LLM มีความกำหนดแน่นอนอย่างสมบูรณ์ ฉันจะทำอะไรต่างออกไปไหม?
      ฉันตรวจสอบเอาต์พุตของโมเดล เหมือนทำ code review ให้เพื่อนร่วมงาน อยู่แล้ว

  • สถานการณ์แบบนี้ถูกเรียกว่า vendor lock-in มานานมากแล้ว
    ถ้าพึ่งพาเครื่องมือใดเครื่องมือหนึ่งมากเกินไป พอเครื่องมือนั้นเปลี่ยนหรือหายไปก็ทำงานต่อไม่ได้

  • ฉันย้ายจาก CC ไป opencode แล้ว
    CC ปิดเกินไป และพรอมป์ต์ก็ ชี้นำความเห็น (opinionated) มากจนใช้งานไม่สะดวก
    แถมยังควบคุมเส้นทางการค้นหาเว็บไม่ได้ด้วย
    ตอนนี้ฉันใช้แบบงานอดิเรกเลยเลือกโอเพนซอร์ส แต่ถ้าเป็นงานอาชีพก็คงตัดสินใจอีกแบบ

    • ฉันก็เคยลอง opencode เหมือนกัน แต่ เวอร์ชันพื้นฐานอ่อนกว่า CC มาก
      ใช้ได้แค่กับโปรเจ็กต์เล็ก ๆ เท่านั้น
      ถ้ามีการตั้งค่าที่ดีพอก็อยากให้ช่วยแชร์