อัปเดตเกี่ยวกับรายงานคุณภาพของ Claude Code ล่าสุด

• ช่วงเดือนที่ผ่านมา การที่ผู้ใช้รู้สึกว่า คุณภาพของ Claude ลดลง เกิดจาก การเปลี่ยนแปลง 3 อย่างที่แยกจากกัน ครอบคลุม Claude Code, Claude Agent SDK, Claude Cowork และ API ไม่ได้รับผลกระทบ
• หลังจากลดระดับความเข้มของการให้เหตุผลเริ่มต้นเป็น medium แล้ว เวลาแฝงและข้อจำกัดการใช้งาน ลดลง แต่ทำให้รู้สึกว่า Claude Code ฉลาดน้อยลง จึงเปลี่ยนค่ากลับเป็นค่าเดิมอีกครั้งในวันที่ 7 เมษายน
• บั๊กจากการปรับแคชให้เหมาะสมที่ปล่อยเมื่อ 26 มีนาคม ทำให้ในเซสชันที่เกินเกณฑ์การว่างงาน ประวัติการให้เหตุผลถูกล้างทุกเทิร์น และนำไปสู่อาการความจำหลงลืม การทำซ้ำ การเลือกเครื่องมือแปลก ๆ และการใช้ usage limits หมดเร็วขึ้น
• บรรทัดหนึ่งใน system prompt ที่เข้ามาพร้อม Opus 4.7 เมื่อ 16 เมษายน เป็น ข้อจำกัดที่ตั้งใจลดความยืดยาวของผลลัพธ์ แต่ในการประเมินที่กว้างขึ้นกลับทำให้ประสิทธิภาพของบางโมเดลลดลง 3% จึงถูกย้อนกลับในวันที่ 20 เมษายน
• ปัญหาทั้งสามได้รับการแก้ไขแล้วทั้งหมดและถูกรวมอยู่ใน v2.1.116 ที่ปล่อยเมื่อ 20 เมษายน โดยการลดความต่างระหว่างบิลด์ภายในกับบิลด์สาธารณะ การเพิ่มการควบคุม system prompt และการประเมินที่กว้างขึ้นพร้อม gradual rollout ถูกกำหนดเป็นหัวใจหลักในการป้องกันไม่ให้เกิดซ้ำ

---

ขอบเขตของคุณภาพที่ลดลงล่าสุดและสถานะการกู้คืน

• การที่ผู้ใช้บางส่วนรู้สึกว่า คุณภาพของ Claude ลดลง ในช่วงเดือนที่ผ่านมา มีสาเหตุจาก การเปลี่ยนแปลง 3 อย่างที่แยกจากกัน ครอบคลุม Claude Code, Claude Agent SDK, Claude Cowork และ API ไม่ได้รับผลกระทบ
• ปัญหาทั้งสามได้รับการแก้ไขแล้วทั้งหมด และถูกรวมอยู่ใน v2.1.116 ที่ปล่อยเมื่อ 20 เมษายน
• การเปลี่ยนแปลงแต่ละอย่างส่งผลในช่วงเวลาต่างกันและกับช่วงทราฟฟิกต่างกัน ทำให้ภาพรวมดูเหมือนเป็นการเสื่อมประสิทธิภาพในวงกว้างแต่ไม่สม่ำเสมอ
• มีการตรวจสอบรายงานที่เกี่ยวข้องมาตั้งแต่ต้นเดือนมีนาคม แต่ในช่วงแรกแยกได้ยากจากความผันผวนตามปกติของฟีดแบ็กผู้ใช้ และในระหว่างการใช้งานภายในกับการประเมินก็ยังไม่สามารถทำให้เกิดปัญหาเดียวกันซ้ำได้ในตอนแรก
• ณ วันที่ 23 เมษายน ได้รีเซ็ต usage limits ให้กับสมาชิกทุกคนแล้ว

การเปลี่ยนแปลงระดับความเข้มของการให้เหตุผลเริ่มต้นของ Claude Code

• เมื่อตอนเปิดตัว Opus 4.6 ใน Claude Code เดือนกุมภาพันธ์ ระดับความเข้มของการให้เหตุผลเริ่มต้นถูกตั้งไว้ที่ high
• ไม่นานหลังจากนั้น ในโหมด high เริ่มมีกรณี ใช้เวลาคิดนานเกินไป เป็นบางครั้งจน UI ดูเหมือนค้าง และสำหรับผู้ใช้บางส่วนก็ทำให้เวลาแฝงและการใช้โทเคนสูงเกินไป
• ระดับ effort ของ Claude Code ถูกใช้เป็นวิธีควบคุมว่าจะให้คิดนานขึ้น หรือจะเลือกเวลาแฝงต่ำลงและใช้ข้อจำกัดการใช้งานน้อยลง
  • ในชั้นผลิตภัณฑ์ จะกำหนดค่าเริ่มต้นหนึ่งค่าจากเส้นโค้งการคำนวณในช่วงทดสอบเวลาใช้งาน แล้วส่งต่อเป็นพารามิเตอร์ effort ไปยัง Messages API
  • ตัวเลือกอื่นมีให้ผ่าน /effort
• ในการประเมินและการทดสอบภายใน medium ให้ผลว่า ความฉลาดลดลงเล็กน้อยแต่เวลาแฝงลดลงมาก สำหรับงานส่วนใหญ่
  • medium ยังมีปัญหา tail latency ที่ยาวมากน้อยกว่า
  • และเอื้อต่อการใช้ usage limits ของผู้ใช้ให้คุ้มค่าสูงสุดด้วย
• จากผลเหล่านี้ จึงเปลี่ยนค่า effort เริ่มต้นเป็น medium และแจ้งเหตุผลผ่านกล่องโต้ตอบภายในผลิตภัณฑ์
• หลังปล่อยใช้งานไม่นาน ผู้ใช้เริ่มรู้สึกว่า Claude Code ฉลาดน้อยลง
  • มีการใส่การปรับดีไซน์หลายอย่าง เช่น การแจ้งเตือนตอนเริ่มใช้งาน ตัวเลือก effort แบบอินไลน์ และการกู้คืน ultrathink เพื่อทำให้เห็นค่าการตั้งค่า effort ปัจจุบันชัดเจนขึ้น
  • แต่ผู้ใช้ส่วนใหญ่ก็ยังคงอยู่กับค่าเริ่มต้น medium
• หลังนำฟีดแบ็กลูกค้าเพิ่มเติมมาพิจารณา การตัดสินใจนี้จึงถูกย้อนกลับในวันที่ 7 เมษายน
  • ตอนนี้ผู้ใช้ทุกคนจะได้ค่าเริ่มต้นเป็น xhigh บน Opus 4.7
  • และได้ค่าเริ่มต้นเป็น high บนโมเดลอื่นทั้งหมด
• การเปลี่ยนแปลงนี้ส่งผลต่อ Sonnet 4.6 และ Opus 4.6

การปรับแคชให้เหมาะสมที่ทำให้ประวัติการให้เหตุผลก่อนหน้าหลุดหาย

• เมื่อ Claude ใช้การให้เหตุผลกับงานหนึ่ง ๆ ประวัติการให้เหตุผล จะคงอยู่ในประวัติการสนทนา เพื่อให้สามารถอ้างอิงการแก้ไขก่อนหน้าและเหตุผลของการเรียกใช้เครื่องมือในแต่ละเทิร์นถัดไปได้ต่อเนื่อง
• วันที่ 26 มีนาคม มีการปล่อยการเปลี่ยนแปลงเพื่อเพิ่มประสิทธิภาพของฟีเจอร์นี้
  • Anthropic ใช้ prompt caching เพื่อทำให้การเรียก API ต่อเนื่องมีต้นทุนต่ำลงและเร็วขึ้น
  • เมื่อ Claude เขียนโทเคนอินพุตลงแคชระหว่างคำขอ API หากไม่มีการใช้งานเป็นระยะเวลาหนึ่ง พรอมป์ต์นั้นจะถูกลบออกจากแคชเพื่อเปิดพื้นที่ให้พรอมป์ต์อื่น
  • การใช้แคชถูกจัดการอย่างระมัดระวัง และแนวทางที่เกี่ยวข้องสรุปไว้ใน approach
• ตามการออกแบบ หากเซสชันว่างเกินหนึ่งชั่วโมง ตั้งใจจะล้างช่วง thinking ก่อนหน้าเพียงครั้งเดียวเพื่อลดต้นทุนในการกลับมาใช้เซสชันอีกครั้ง
  • เนื่องจากคำขอนั้นจะกลายเป็น cache miss อยู่แล้ว จึงพยายามตัดข้อความที่ไม่จำเป็นออกจากคำขอก่อนส่งไปยัง API เพื่อลดจำนวน uncached tokens
  • หลังจากนั้นจึงออกแบบให้กลับมาส่งประวัติการให้เหตุผลทั้งหมดอีกครั้ง
  • โดยใช้ API header clear_thinking_20251015 และ keep:1
• แต่ในการใช้งานจริงมี บั๊ก ทำให้แทนที่จะล้างประวัติ thinking แค่ครั้งเดียว กลับ ล้างต่อเนื่องทุกเทิร์น จนกว่าเซสชันจะจบ
• เมื่อเซสชันหนึ่งเกินเกณฑ์การว่างงานแล้ว คำขอทั้งหมดของโปรเซสนั้นหลังจากนั้นจะถูกส่งไปยัง API โดยเก็บไว้เพียงบล็อกการให้เหตุผลล่าสุดและทิ้งส่วนก่อนหน้า
• ปัญหานี้แย่ลงแบบสะสม
  • หาก Claude ส่งข้อความติดตามผลระหว่างการใช้เครื่องมือ นั่นเองก็จะกลายเป็นเทิร์นใหม่ภายใต้แฟล็กที่เสียหายนี้
  • ส่งผลให้แม้แต่การให้เหตุผลของเทิร์นปัจจุบันก็อาจหลุดหายไปได้
• Claude ยังทำงานต่อไปได้ แต่จะค่อย ๆ ทำงานโดยไม่มีความทรงจำว่าทำไมถึงเลือกพฤติกรรมนั้น
  • ในมุมผู้ใช้ สิ่งนี้แสดงออกมาเป็น ความจำหลงลืม, การทำซ้ำ, และ การเลือกเครื่องมือแปลก ๆ
• เพราะบล็อก thinking ยังคงหายไปในคำขอถัด ๆ มา คำขอเหล่านั้นจึงตามมาด้วย cache miss
  • รายงานแยกต่างหากที่ว่า usage limits ถูกใช้หมดเร็วกว่าที่คาด น่าจะเกิดจากปรากฏการณ์นี้
• เหตุผลที่ช่วงแรกทำให้เกิดซ้ำได้ยาก มีการทดลองที่ไม่เกี่ยวข้องอยู่สองอย่าง
  • การทดลองฝั่งเซิร์ฟเวอร์ภายในเท่านั้น ที่เกี่ยวกับ message queueing
  • และการเปลี่ยนแปลงอีกอย่างในวิธีแสดงผล thinking ที่ไปกลบบั๊กนี้ในเซสชัน CLI ส่วนใหญ่
• บั๊กนี้อยู่ตรงจุดตัดระหว่าง การจัดการคอนเท็กซ์ ของ Claude Code, Anthropic API และ extended thinking
  • ผ่านทั้ง code review โดยหลายคนและ code review อัตโนมัติ
  • ผ่านทั้ง unit test และ end-to-end test
  • และยังผ่านทั้งการตรวจสอบอัตโนมัติกับ dogfooding ด้วย
• ปัญหานี้เกิดขึ้นเฉพาะใน เคสขอบ ของเซสชันเก่าและยังทำให้เกิดซ้ำได้ยาก จึงใช้เวลามากกว่าหนึ่งสัปดาห์ในการค้นหาและยืนยันสาเหตุราก
• ระหว่างการสืบสวน ได้ทำ Code Review ย้อนหลังให้กับ pull request ที่เป็นต้นเหตุด้วย Opus 4.7
  • เมื่อให้รีโพซิทอรีโค้ดที่จำเป็นต่อการรวบรวมบริบททั้งหมดร่วมไปด้วย Opus 4.7 สามารถพบบั๊กได้
  • แต่ Opus 4.6 หาไม่พบ
• เพื่อไม่ให้เรื่องเดียวกันเกิดขึ้นอีก กำลังเพิ่ม การรองรับการใส่รีโพซิทอรีเพิ่มเติมเป็นคอนเท็กซ์ ใน code review
• บั๊กนี้ได้รับการแก้ไขใน v2.1.101 วันที่ 10 เมษายน
• การเปลี่ยนแปลงนี้ส่งผลต่อ Sonnet 4.6 และ Opus 4.6

การเปลี่ยนแปลง system prompt ที่ตั้งใจลดความยืดยาว

• โมเดลล่าสุด Claude Opus 4.7 มีลักษณะเด่นคือให้ผลลัพธ์ ยืดยาวมาก มากกว่าโมเดลก่อนหน้า
  • ตอนประกาศเปิดตัวก็กล่าวถึงลักษณะนี้ไว้ และดูรายละเอียดเพิ่มเติมได้ใน wrote about
• ความยืดยาวนี้ทำให้ฉลาดขึ้นเมื่อต้องแก้ปัญหายาก แต่ก็เพิ่มจำนวนโทเคนเอาต์พุตด้วย
• หลายสัปดาห์ก่อนเปิดตัว Opus 4.7, Claude Code ได้ทำการปรับจูนให้เข้ากับโมเดลใหม่นี้
  • แต่ละโมเดลมีพฤติกรรมต่างกันเล็กน้อย ดังนั้นก่อนรีลีสจึงมีการปรับ harness และผลิตภัณฑ์ให้เหมาะกับแต่ละโมเดล
• วิธีลดความยืดยาวมีทั้งการฝึกโมเดล การทำพรอมป์ต์ และการปรับปรุง UX ของ thinking ภายในผลิตภัณฑ์ร่วมกัน
• ในบรรดาวิธีเหล่านั้น มีหนึ่งบรรทัดที่เพิ่มเข้าไปใน system prompt ซึ่งส่งผลต่อ ความฉลาด ของ Claude Code มากเกินไป
  • “Length limits: keep text between tool calls to ≤25 words. Keep final responses to ≤100 words unless the task requires more detail.”
• ในการทดสอบภายในหลายสัปดาห์และชุดการประเมินที่รัน ไม่พบการถดถอย จึงมั่นใจและปล่อยการเปลี่ยนแปลงนี้พร้อม Opus 4.7 ในวันที่ 16 เมษายน
• ต่อมา ระหว่างการสืบสวน ได้ทำ ablation โดยใช้ชุดการประเมินที่กว้างขึ้น เพื่อแยกดูผลกระทบของแต่ละบรรทัดใน system prompt
• ในการประเมินหนึ่ง พบว่าทั้ง Opus 4.6 และ 4.7 ลดลง 3%
• พรอมป์ต์นี้จึงถูกย้อนกลับทันทีเป็นส่วนหนึ่งของรีลีสวันที่ 20 เมษายน
• การเปลี่ยนแปลงนี้ส่งผลต่อ Sonnet 4.6, Opus 4.6, Opus 4.7

การเปลี่ยนแปลงต่อจากนี้

• เพื่อหลีกเลี่ยงปัญหาคล้ายกัน จะเปลี่ยนให้บุคลากรภายในมากขึ้นใช้ Claude Code เวอร์ชันเดียวกับบิลด์สาธารณะทุกประการ
  • เป็นมาตรการเพื่อลดความต่างระหว่างเวอร์ชันภายในสำหรับทดสอบฟีเจอร์ใหม่ กับบิลด์สาธารณะที่ใช้งานจริง
• จะปรับปรุงเครื่องมือ Code Review ที่ใช้ภายใน และจะปล่อยเวอร์ชันที่ปรับปรุงนี้ให้ลูกค้าด้วย
• เพิ่ม ขั้นตอนควบคุม ที่เข้มงวดยิ่งขึ้นสำหรับการเปลี่ยนแปลง system prompt
  • จะทำการประเมินอย่างกว้างขวางแยกตามโมเดลสำหรับการเปลี่ยนแปลง system prompt ทั้งหมดของ Claude Code
  • จะทำ ablation ต่อไปเพื่อทำความเข้าใจผลกระทบของแต่ละบรรทัด
  • และกำลังสร้างเครื่องมือใหม่เพื่อให้รีวิวและตรวจสอบการเปลี่ยนแปลงพรอมป์ต์ได้ง่ายขึ้น
• เพิ่มคำแนะนำใน CLAUDE.md เพื่อให้ การเปลี่ยนแปลงเฉพาะโมเดลถูกใช้กับโมเดลนั้นเท่านั้น
• สำหรับการเปลี่ยนแปลงทุกอย่างที่อาจแลกมากับความฉลาด จะเพิ่ม soak period, ชุดการประเมินที่กว้างขึ้น และ gradual rollout เพื่อจับปัญหาได้เร็วขึ้น
• เพื่ออธิบายการตัดสินใจด้านผลิตภัณฑ์และที่มาที่ไปอย่างละเอียดขึ้น ได้สร้าง @ClaudeDevs บน X และมีแผนจะแชร์อัปเดตเดียวกันในเธรดศูนย์กลางบน GitHub ด้วย
• ข้อมูลที่ส่งผ่านคำสั่ง /feedback หรือผ่านตัวอย่างออนไลน์ที่เฉพาะเจาะจงและทำซ้ำได้ ช่วยนำไปสู่การระบุและแก้ไขปัญหา
• การรีเซ็ต usage limits ของสมาชิกทุกคนถูกนำมาใช้อีกครั้งในวันนั้น

[GN⁺]

ความเห็นจาก Hacker News

• คำอธิบายที่ว่าลบ thinking เก่าใน เซสชันที่ปล่อยทิ้งไว้เกิน 1 ชั่วโมง เพื่อลด latency นั้นฟังแล้วไม่ค่อยน่าเชื่อ
  ปกติฉันมักปล่อยเซสชันทิ้งไว้เป็นชั่วโมง ๆ หรือเป็นวัน แล้วกลับมาใช้งานต่อโดยอาศัย บริบททั้งหมด เดิมครบถ้วน ซึ่งนี่แหละคือฟีเจอร์สำคัญ
  ต่อให้พอเข้าใจได้ที่ลดระดับ thinking เริ่มต้นลงบ้าง แต่ส่วนที่ system prompt เปลี่ยนไปเรื่อย ๆ นั้น ดูเหมือนฉันต้องทำความเข้าใจให้ได้ว่ามันเลือกจังหวะ refresh อย่างไร เพื่อที่จะควบคุมรอบนั้นได้อย่างตั้งใจ

  • ใน Claude Code ถ้าในบทสนทนามีข้อความอยู่ N ข้อความ ปกติ N-1 ข้อความยกเว้นอันล่าสุด จะถูกเก็บใน prompt cache
    ปัญหาคือถ้าปล่อยเซสชันให้ idle เกิน 1 ชั่วโมง พอส่งพรอมป์ต์อีกครั้ง ข้อความทั้ง N รายการจะ cache miss ทั้งหมด
    corner case นี้ทำให้ต้นทุนโทเค็นของผู้ใช้สูงเกินไป และถ้าเป็นบริบทขนาด 900k tokens แบบสุดโต่ง ตอนกลับมาใช้อีกครั้งก็ต้องเขียนโทเค็น 900k+ กลับเข้าแคชใหม่ จึงกระทบ rate limit ของผู้ใช้ Pro อย่างหนักเป็นพิเศษ
    เลยทั้งลองให้ความรู้ผู้ใช้ผ่าน X, ใส่ทิปในโปรดักต์หลายครั้งเพื่อแนะนำให้ใช้ /clear เมื่อต้องกลับไปคุยต่อในบทสนทนาเก่า, และทดลองวิธีอย่างละบางส่วนของผลลัพธ์ tool เก่า ข้อความเก่า และ thinking หลัง idle ออกไป ซึ่งในบรรดาวิธีเหล่านี้ การลบ thinking ให้ผลด้านประสิทธิภาพดีที่สุด
    ระหว่างปล่อยการเปลี่ยนแปลงนั้น บั๊ก ที่เขียนไว้ในบล็อกก็หลุดเข้าไปโดยไม่ได้ตั้งใจ และถ้ามีคำถามก็ยินดีตอบเพิ่มเติม
  • น่าแปลกใจที่บริษัทมูลค่าหลายหมื่นล้านดอลลาร์ตัดสินใจแบบนี้
    ดูเหมือนจะมีแค่สองทาง คือเชื่อจริง ๆ ว่าการลด latency ของ idle session คุ้มค่าพอจะ ยอมแลกคุณภาพผลลัพธ์ หรือไม่ก็เป้าหมายจริงคือ ลดต้นทุน แต่ในบล็อกใช้เรื่อง latency เป็นเหตุผลที่ฟังดูดีกว่า
    ทางที่เป็นธรรมชาติกว่าน่าจะเป็นการแสดง loading ให้ชัดเจนขึ้นระหว่างที่กำลังโหลดบริบทกลับมา
  • อันนี้ค่อนข้างช็อก
    เมื่อก่อนฉันใช้ CC เหมือนคุยกับเพื่อนร่วมงาน คิดปัญหากันสักพัก อัปเดตแผน ไปอาบน้ำแล้วกลับมาคิดต่อ แล้วค่อยโยนคำแนะนำใหม่เข้าไป และอย่างน้อยก็ถือว่าเป็น บทสนทนาแบบคงสภาพได้หนึ่งวัน
    แต่ถ้าเกณฑ์คือ 1 ชั่วโมง ก็สั้นเกินไป จนทำให้ต้องกลับมาคิดใหม่ว่าจะต่อแพลน anthropic ดีไหม
  • เหตุผลที่คำอธิบายเรื่อง ลบโทเค็นหลัง 1 ชั่วโมง ดูน่าสงสัยขึ้นไปอีก ก็เพราะช่วงเวลานั้นดันตรงกับ ข้อจำกัดของแคช พอดี
    ดูไม่น่าใช่เรื่องบังเอิญ และน่าจะเป็นการเปลี่ยนแปลงที่ช่วยลดต้นทุนได้มากกว่า
  • เรื่องนี้น่าจะส่งผลแย่สุด ๆ เมื่อนำไปรวมกับ การรีเซ็ตการใช้งานตามเวลา
    ถ้ามีผู้ใช้จำนวนมากที่ใช้โควตาหมดแล้วปล่อยเซสชันพักไว้ก่อนค่อยกลับมา นี่ก็ไม่ใช่ข้อยกเว้น แต่เกือบจะเป็นรูปแบบการใช้งานปกติเลย

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

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

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

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

• ผมหมดใจตั้งแต่ Opus 4.7 แล้ว
  ทาง OpenAI กำลังบุกฝั่ง enterprise ของเราอย่างหนักมาก และถึงขั้นเสนอ โทเค็นไม่จำกัด ไปจนถึงหน้าร้อน
  ผมเลยลองใช้ GPT5.4 แบบ extra high effort ตลอด 30 วันที่ผ่านมา ไม่แน่ใจว่าได้อภิสิทธิ์พิเศษหรือเปล่า แต่แทบไม่เห็นมันพลาดเลย
  บางครั้ง reasoning trace ก็ดีจนหลุดขำ และมันยังช่วยเก็บรายละเอียดที่จำเป็นต่อการรักษา data integrity ให้ครบ 100% แม้ในส่วนที่ผมลืมสั่งไว้

  • ผมก็รู้สึกคล้ายกัน
    การเปลี่ยนแปลงแนว ลูกเล่นเลี่ยงปัญหา เหล่านี้ อาจเป็นเพราะ Anthropic ถูกจำกัดด้าน compute มาก เลยต้องฝืนหาทางลดมันลง
  • GPT-5.4 ดีกว่า Opus 4.6 ไปแล้วในหลายด้าน โดยเฉพาะเรื่องความแม่นยำและตรรกะที่ซับซ้อน
    เลยยิ่งอยากเห็นว่า 5.5 จะดีขึ้นได้อีกแค่ไหน
  • extra high เผาโทเค็นหนักเกินไป
    งาน 90% ใช้ 5.4 ที่ medium ก็พอ และค่อยขยับเป็น high เฉพาะตอนที่ medium ดูไม่ไหว แบบนั้นโฟกัสดีกว่าและมีการเปลี่ยนแปลงน้อยกว่ามาก
  • เห็นด้วย
  • ผม กลับไปใช้ 4.5 แล้ว และไม่เสียใจเลย
    แถมยังถูกกว่านิดหน่อยด้วย

• ช่วงหลัง Claude ชอบตอบเหมือนกำลังตอบ internal prompt ของตัวเอง
  เช่นบอกว่าจะไม่สนใจข้อความในวงเล็บเพราะเป็นการพยายามทำ prompt injection หรือบอกว่าจะไม่ทำตามเพราะดูเหมือนเป็นความพยายามซ่อนแนวทางทั่วไปของมัน ทั้งที่กฎพวกนั้นมันใช้อยู่แล้วจึงไม่จำเป็น
  ทั้งหมดนี้ผมไม่ได้พยายามทำเลย แต่ประโยคทำนองนี้กลับโผล่มาตอนท้ายคำตอบบ่อยมาก
  เหมือนใน internal guideline มีอะไรบางอย่างที่หยาบ ๆ อยู่ และมันแยกสิ่งนั้นออกจากคำถามของผมได้ไม่ดีพอ

  • ผมตั้ง stop hook scripts ไว้เพื่อบังคับให้รันทดสอบทุกครั้งที่มีการแก้โค้ด แต่หลัง 4.7 Claude ยังรันสคริปต์นะ เพียงแต่จะละเลยกฎเป็นพัก ๆ
    พอถามเหตุผล มันตอบว่า คิดว่าไม่จำเป็น
  • ทาง OpenAI ก็เห็นอาการคล้ายกัน คือชอบตอบคำพูดของตัวเอง
    มันเหมือนเป็นวิธีง่าย ๆ ที่บริษัทใช้เพิ่ม token churn
  • ผมก็เจอบ่อยเหมือนกันที่มันเอาประเด็นที่มันสร้างขึ้นเองไปเก็บใน memory แล้วภายหลังค่อย อ้างกลับมาเหมือนเป็นข้ออ้างของผม
    แบบนี้จะเกิดลูปเสริมแรงตัวเองที่โมเดลฟันธงอะไรบางอย่าง เก็บลงความจำ แล้วกลับมาอ่านความจำนั้นเพื่อเสริมมันต่อ แม้ผมจะสั่งชัด ๆ ให้หยุด มันก็ยังเป็นอยู่
  • อยากรู้ระดับ effort กับพรอมป์ต์จริงที่ใช้
    มันอาจเป็นอาการที่มาจาก reasoning effort ที่สูงเกินไป และพรอมป์ต์นั้นอาจดีขึ้นได้ถ้าลดระดับการใช้เหตุผลลงนิดหน่อย
  • ผมมักให้ Claude ช่วยทำทั้ง commit และ PR แต่เมื่อสัปดาห์ก่อนเห็นหลายครั้งที่มันแอบทำ งานเพิ่มที่ไม่จำเป็น ระหว่างขั้นตอน commit
    มันสะดุดที่ขั้น git add ก็จริง แต่ใน auto mode มีครั้งหนึ่งที่เกือบจะหลุดไปเฉย ๆ

• ยิ่งน่าสงสัยเมื่อรู้ว่าเหตุผลที่ลด reasoning effort เริ่มต้น จาก high ลงมาเป็น medium ก็เพราะ latency นานจน UI ดูเหมือนค้าง
  แปลว่าแทนที่จะไปแก้ UI กลับเลือกไปลดระดับการคิดเริ่มต้นก่อน และพอจะบอกว่าติดตามรายงานคุณภาพตกลงอย่างจริงจังด้วย ก็เชื่อได้ยาก

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

• การบอกว่า เซสชัน idle เกิน 1 ชั่วโมง เป็น corner case ไม่ตรงกับรูปแบบการใช้งานของผมเลย
  งานส่วนตัวผมมักใช้ Claude Code ทำงานสั้น ๆ 10–15 นาทีหลายงาน และใช้เวลาคุยกับโมเดลไปมาหลายรอบเพื่อวางแผนก่อนเริ่มรันจริง
  พอเริ่มรันแล้วผมก็มักไปกินกาแฟหรือไปทำโปรเจ็กต์อื่นใน Codex ดังนั้นกว่าจะกลับมาที่ Claude อีกที เกิน 1 ชั่วโมง มีโอกาสสูงมาก

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

• แนวทางแบบ กล่องดำ ที่ frontier lab รายใหญ่เลือกใช้นั้น สุดท้ายจะทำให้คนหนีออกไป
  ถ้าเปลี่ยนพฤติกรรมพื้นฐานแบบนี้โดยไม่บอกล่วงหน้า แล้วค่อยมาอธิบายทีหลัง ผู้ใช้ก็ย่อมหันไปทาง โมเดลที่โฮสต์เอง มากขึ้นเรื่อย ๆ
  บนฐานที่สั่นไหวอยู่ตลอดแบบนี้ จะสร้าง pipeline, workflow และผลิตภัณฑ์ให้มั่นคงไม่ได้

• ดูเหมือนทีม Claude Code ของ Anthropic จะอ่านคอมเมนต์อยู่ เลยนึกถึงวิดีโอเมื่อไม่กี่วันก่อนของ theo t3.gg ที่พูดถึงว่า Claude โง่ลงหรือเปล่า
  โทนอาจแรงและใช้คำหนักไปบ้าง แต่โดยเฉพาะประเด็น harness bloat ผมว่าตรงมาก
  ตอนนี้ควรหยุดเพิ่มฟีเจอร์ใหม่ชั่วคราว แล้วผลักเรื่อง การขัดเกลาและการปรับให้เหมาะสม อย่างจริงจัง
  ไม่อย่างนั้นคนจะยิ่งออกไปหาทางเลือกที่เบาและปรับจูนมาดีกว่า และหัวใจสำคัญก็คือต้องทำ harness ให้ดีขึ้นพร้อมลดการใช้โทเค็นลง
  https://youtu.be/KFisvc-AMII?is=NskPZ21BAe6eyGTh

  • เอาอย่างอื่นไว้ก่อน แค่การทดลองที่จะ ถอดการรองรับ CC ออกจากแพลน Pro ก็ทำให้ผมเริ่มมองหาทางเลือกอย่างจริงจังแล้ว
    เดิมทีก็ระวัง vendor lock-in อยู่ตลอด เหตุการณ์นั้นเลยเป็นสัญญาณเตือนชั้นดี และผมน่าจะไปลอง opencode+openrouter ก่อน
  • ห้ามลืมวิดีโอ อวย GPT 5 เกินจริง ของ theo และตอนหลังที่ต้องถอนคำพูดเรื่องนั้น
    มันดูชัดมากว่าระหว่างครีเอเตอร์บางคนกับ OpenAI ต้องมีอะไรบางอย่างไหลเวียนอยู่ข้างหลัง ไม่ว่าจะเป็นเงินหรืออิทธิพล
  • เอาจริง ๆ มันก็ดูเหมือนเป็นปัญหาที่แค่ git reset --hard ก็น่าจะแก้ได้

• เรื่องนี้ดูเป็นผลจากการหมกมุ่นกับการเพิ่มฟีเจอร์มากกว่าการทำ ผลิตภัณฑ์หลักให้สมบูรณ์
  ผมมักรู้สึกว่า Anthropic น่าจะต้องมีผู้นำผลิตภัณฑ์ระดับซีเนียร์เพิ่มอีกสักไม่กี่คน และต้องการมุมมองแบบ “Escaping the Build Trap”
  ตอนนี้ไม่ใช่ว่าทำฟีเจอร์เพิ่มได้เร็วแล้วจำเป็นต้องเพิ่มเสมอไป
  ไม่ได้จะยกหนังสือดังมาเพื่อพูดเรื่องเชิงนามธรรมขององค์กรผลิตภัณฑ์ แต่เซนส์ด้านผลิตภัณฑ์ที่ดีเป็นคนละพรสวรรค์กับวิศวกรรมที่ดี และช่วงหลัง Anthropic ดูขาดตรงนี้ไป

  • พวกเขาต้องวิ่งให้ทันความต้องการ แต่ก็ดูชัดว่า ทรัพยากร compute ไม่พอ
    เพราะฉะนั้นถ้าไม่ใส่ฟีเจอร์พวกนี้ ระบบอาจพังหรือไม่ก็รับลูกค้าใหม่ไม่ได้ ซึ่งทั้งสองอย่างก็ยอมรับยาก เลยอาจแทบไม่มีทางเลือก
  • เคยเป็นบริษัทที่มีนักพัฒนาราว 100 คนได้ 600,000 ดอลลาร์ต่อปี กันมาแล้ว เพราะงั้นปัญหาคงไม่ใช่ขาดคนเก่ง
    กลับกัน ปัญหาน่าจะเป็นการผลัก เรื่องเล่าแบบ vibe coding แรงเกินไป และได้ยินว่าถึงขั้นมีผู้สมัครบางคนปฏิเสธการสัมภาษณ์เพราะเรื่องนี้
  • ดูเหมือนจะติดอยู่ใน กับดักความซับซ้อน ลึกมากแล้ว
    ตัวโมเดลที่เป็นความน่าจะเป็นก็เป็นปัญหาอยู่แล้ว แต่ตอนนี้เหมือนถึงขั้นที่พวกเขาเองก็อธิบายพฤติกรรมของซอฟต์แวร์ตัวเองไม่ได้ดีนัก
    มีทั้งคันโยกและปุ่มปรับมากเกินไป และเป็นไปได้ว่าไม่มีใครเข้าใจโค้ดทั้งหมดจริง ๆ
    ที่แย่กว่านั้นคือจากคำพูดของ Dario และคนอื่น ๆ ดูเหมือนฝ่ายบริหารจะไม่ค่อยอินกับความกังวลด้านคุณภาพนี้
    ภายใต้แนวคิดที่ว่า SWE เป็นสิ่งที่ทดแทนได้ คำเรียกร้องให้ใส่ guard rail ให้เครื่องมือจึงถูกเมินหรือแม้แต่ถูกกดไว้ และท้ายที่สุด Claude Code ก็ดูเหมือนเริ่มต้นมาในฐานะ การทดลองทางวิทยาศาสตร์ ตั้งแต่แรก จนยังไม่ค่อยมีกลิ่นของผลิตภัณฑ์ที่โตเต็มที่พร้อม best practice ที่นิ่งพอ