ลมตะวันตก จาก 凹非寺
ในที่เก็บข้อมูลทางการ มี Issue หนึ่งที่กำลังเป็นที่ถกเถียงกันอย่างร้อนแรง ชี้ตรงไปที่ปัญหาหลัก: การอัปเดตของ Claude Code อาจ “พัง” ไปแล้ว
การอัปเดตครั้งหนึ่งทำให้ความลึกในการคิดลดลงฮวบฮาบ 67% รุ่นปัจจุบันถูกมองว่าไม่สามารถรับมือกับงานวิศวกรรมที่ซับซ้อนได้อีกต่อไป
“ไม่สนใจคำสั่งผู้ใช้”, “ดำเนินการตรงข้ามกับสิ่งที่ผู้ใช้ขอ”, “แกล้งทำเป็นว่างานเสร็จแล้ว” … พฤติกรรมของโมเดลผิดเพี้ยนไปหมด
ความยาวของสายโซ่ความคิด (chain of thought) ถูกตัดจากประมาณ 2200 ตัวอักษร เหลือไม่ถึง 700 ตัวอักษร โหมดการทำงานจากกระบวนการที่เข้มงวดแบบ “ศึกษาก่อนแล้วค่อยแก้ไขโค้ด” ถดถอยเป็นโหมดที่หุนหันพลันแล่นแบบ “ลงมือแก้ไขโค้ดทันที”
นี่กลายเป็นรากเหง้าของปัญหาต่างๆ ทั้งบั๊ก การกระทำตรงข้าม และการไม่สนใจคำสั่ง
ประเด็นสำคัญคือ เส้นเวลาของการถดถอยของความสามารถสามารถย้อนกลับไปได้ถึงเดือนกุมภาพันธ์ ซึ่งตรงกันพอดีกับเวลาที่ฟีเจอร์ใหม่ชื่อ redact-thinking-2026-02-12 (ฟังก์ชันซ่อนเนื้อหาการคิด) เปิดตัว
พูดอีกอย่างคือ การอัปเดต Claude Code ครั้งนี้อาจนำไปสู่การลดทอนคุณภาพการทำงาน
ในชุมชนมีเสียงวิจารณ์มากมาย มีผู้ใช้เน็ตบางคนบอกว่าเคยสงสัยว่าตัวเองทำผิดหรือเปล่า ไม่เคยคิดมาก่อนว่าตัวเครื่องมือเองจะมีปัญหา
ช่วงนี้มันชอบบอกฉันว่า “คุณควรไปนอนได้แล้ว”, “ดึกแล้ว วันนี้พอแค่นี้ก่อนนะ” ประโยคแบบนี้ ตอนแรกฉันยังคิดว่า เป็นเพราะฉันเผลอทำให้ Claude รู้เดดไลน์ของฉัน
หลังจากความคิดถูกตัดทอน พฤติกรรมแย่ๆ ต่างๆ ของ Claude Code
ผู้ที่ส่งข้อเสนอแนะโดยละเอียดนี้คือ Stella Laurenzo ผู้รับผิดชอบงานพัฒนาซอฟต์แวร์ AI โอเพ่นซอร์สของ AMD
การวิเคราะห์ทั้งหมดอ้างอิงจากไฟล์ JSONL ของเซสชัน Claude Code จำนวน 6852 ไฟล์ จาก 4 โปรเจกต์ (iree-loom, iree-amdgpu, iree-remoting, bureau) ในไดเรกทอรี ~/.claude/projects/ ข้อมูลครอบคลุมบล็อกความคิด 17871 บล็อก (ในจำนวนนี้ 7146 บล็อกมีเนื้อหาครบถ้วน, 10725 บล็อกถูกซ่อนแล้ว) การเรียกใช้เครื่องมือ 234760 ครั้ง พร็อมต์ผู้ใช้มากกว่า 18000 ข้อ (ครอบคลุมดัชนีอารมณ์เชิงลบ ความถี่ในการแก้ไข ระยะเวลาเซสชัน) ช่วงเวลาครอบคลุมตั้งแต่ปลายเดือนมกราคมถึงต้นเดือนเมษายน 2026
การทดสอบทั้งหมดใช้โมเดล Opus ที่ทรงพลังที่สุดในซีรีส์ Claude และเชื่อมต่อผ่าน Anthropic API ทางการโดยตรง เพื่อแยกปัจจัยรบกวนเช่นการปรับใช้ของบุคคลที่สามหรือความผิดปกติของไคลเอนต์
รายงานผ่านการวิเคราะห์สหสัมพันธ์ของเพียร์สัน (สัมประสิทธิ์สูงถึง 0.971) กับข้อมูลที่มีประสิทธิภาพ 7146 ชุด พิสูจน์ว่าฟิลด์ signature สามารถประมาณความลึกของการคิดได้อย่างแม่นยำ
ประการแรก รายงานชี้ให้เห็นว่าเวลาเปิดตัวฟังก์ชันซ่อนความคิด ตรงกันพอดีกับเวลาที่คุณภาพของ Claude Code ถดถอย
ต่อไปนี้คือผลการวิเคราะห์จากบล็อกความคิดในไฟล์ JSONL ของการสนทนา:
มีผู้ใช้รายงานปัญหาคุณภาพถดถอยในวันที่ 8 มีนาคม — วันนี้ตรงกับจุดเวลาที่สัดส่วนของบล็อกความคิดที่ถูกซ่อนเกิน 50% พอดี
จังหวะการเปิดตัวฟังก์ชันภายในหนึ่งสัปดาห์ (1.5% → 25% → 58% → 100%) สอดคล้องกับลักษณะของการเปิดตัวแบบแบ่งขั้นตอน (gray deployment) อย่างสมบูรณ์
ในความเป็นจริง ความลึกในการคิดของ Claude Code ลดลงอย่างมากก่อนที่ฟังก์ชันซ่อนนี้จะเปิดตัว
จากการเปรียบเทียบข้อมูลในช่วงเวลาต่างๆ พบว่า ระหว่างวันที่ 30 มกราคมถึง 8 กุมภาพันธ์ ความลึกในการคิดอยู่ที่ประมาณ 2200 ตัวอักษร ปลายเดือนกุมภาพันธ์ลดฮวบเหลือ 720 ตัวอักษร ลดลง 67%; ต้นเดือนมีนาคมยิ่งหดลงเหลือ 560 ตัวอักษร ลดลง 75%
ฟังก์ชันซ่อนที่เปิดตัวต้นเดือนมีนาคม เพียงแต่ทำให้การถดถอยนี้ผู้ใช้มองไม่เห็น
การตัดทอนความลึกในการคิดอย่างมาก ก่อให้เกิดการเปลี่ยนแปลงพื้นฐานในโหมดการใช้เครื่องมือของโมเดล
ในช่วง “คุณภาพดี” วันที่ 30 มกราคมถึง 12 กุมภาพันธ์ เมื่อ Claude Code แก้ไขโค้ด อัตราส่วนการอ่านต่อการแก้ไข (read-to-edit ratio) อยู่ที่ 6.6 เวิร์กโฟลว์เป็นไปตามโหมดที่เข้มงวดแบบ “ศึกษาก่อนแล้วค่อยแก้ไข”: อ่านไฟล์เป้าหมาย ไฟล์ที่เกี่ยวข้อง ค้นหาความสัมพันธ์การเรียกใช้ทั่วทั้งฐานโค้ด ตรวจสอบเฮดเดอร์ไฟล์และเทสต์เคส จากนั้นจึงทำการแก้ไขอย่างแม่นยำ
แต่เมื่อเข้าสู่ช่วง “ถดถอย” หลังวันที่ 8 มีนาคม อัตราส่วนอ่านต่อแก้ลดฮวบเหลือ 2.0 การลงทุนศึกษาของโมเดลลดลง 70% ข้ามขั้นตอนการวิจัยเบื้องต้น อ่านแค่ไฟล์ปัจจุบันก็รีบแก้ไขโดยไม่สนใจความสัมพันธ์ของคอนเท็กซ์
ข้อมูลโดยละเอียดยิ่งขึ้นแสดงให้เห็นว่า ในช่วงถดถอย ทุกๆ 3 ครั้งของการแก้ไข มี 1 ครั้งที่โมเดลดำเนินการโดยไม่ได้อ่านคอนเท็กซ์ของไฟล์เป้าหมาย
เมื่อโมเดลแก้ไขไฟล์ที่ไม่ได้อ่าน มันไม่สามารถแยกแยะตำแหน่งสิ้นสุดของบล็อกคอมเมนต์และตำแหน่งเริ่มต้นของโค้ดได้ มันจะแทรกการประกาศใหม่ระหว่างคอมเมนต์เอกสารและฟังก์ชันที่อธิบายไว้ ทำลายความสัมพันธ์ทางความหมายโดยสิ้นเชิง
และสถานการณ์เช่นนี้ไม่เคยเกิดขึ้นในช่วงคุณภาพดี
ผลกระทบเชิงลบจากการเปลี่ยนแปลงโหมดนี้ สะท้อนให้เห็นในหลายดัชนีคุณภาพที่สามารถวัดปริมาณได้
ก่อนวันที่ 8 มีนาคม สคริปต์ termination hook ที่ใช้ระบุพฤติกรรมไม่ดีเช่นการปัดความรับผิดชอบ การยุติก่อนกำหนด ไม่เคยถูกทริกเกอร์เลย; แต่ภายใน 17 วันหลังวันที่ 8 มีนาคม จำนวนครั้งที่ถูกทริกเกอร์พุ่งสูงถึง 173 ครั้ง เฉลี่ยวันละ 10 ครั้ง
ดัชนีเหล่านี้คำนวณแยกกันจากพร็อมต์ผู้ใช้มากกว่า 18000 ข้อ
สัดส่วนของอารมณ์เชิงลบในพร็อมต์ผู้ใช้เพิ่มจาก 5.8% เป็น 9.8% เพิ่มขึ้น 68%; จำนวนพฤติกรรมปัดความรับผิดชอบที่ต้องแก้ไขเพิ่มเป็นสองเท่า; จำนวนพร็อมต์เฉลี่ยต่อเซสชันลดลง 22% แม้กระทั่งปัญหาวนคิด (reasoning loop) ที่ไม่เคยมีมาก่อนก็ปรากฏขึ้น
เมื่อความลึกในการคิดเพียงพอ โมเดลจะแก้ไขความขัดแย้งในการให้เหตุผลภายในตัวเองก่อนที่จะส่งออก; แต่เมื่อความลึกในการคิดไม่เพียงพอ ความขัดแย้งจะเผยออกมาในการส่งออก โดยแสดงให้เห็นเป็นการแก้ไขตัวเองที่มองเห็นได้ด้วยตา เช่น “โอ้ เดี๋ยวก่อน”, “ที่จริงแล้ว”, “ให้ฉันคิดใหม่”, “อืมม ไม่ใช่”, “เดี๋ยวนะ ไม่ใช่แบบนี้” …
อัตราการวนคิดเพิ่มขึ้นมากกว่า 3 เท่า
ในเซสชันที่สถานการณ์รุนแรงที่สุด โมเดลมีการกลับด้านการให้เหตุผลมากกว่า 20 ครั้งในการตอบสนองเดียว: สร้างแผนก่อน แล้วล้มแผน แก้ไข แล้วล้มการแก้ไข สุดท้ายผลลัพธ์ที่ส่งออกมาเชื่อถือไม่ได้เลย เส้นทางการให้เหตุผลวุ่นวายไปหมด
นอกจากนี้ อัตราการขัดจังหวะของผู้ใช้ก็สามารถบอกได้หลายอย่าง ซึ่งหมายความว่าผู้ใช้พบว่าโมเดลกำลังทำผิดและบังคับให้หยุด ยิ่งอัตราการขัดจังหวะสูง ยิ่งหมายถึงต้องการการแก้ไขด้วยมนุษย์มากขึ้น
ข้อมูลแสดงให้เห็นว่า จากช่วงคุณภาพดีถึงช่วงหลัง อัตราการขัดจังหวะพุ่งสูงขึ้น 12 เท่า
ในช่วงถดถอย หลังจากถูกผู้ใช้แก้ไข โมเดลยังยอมรับด้วยตัวเองบ่อยครั้งว่าผลลัพธ์ที่ส่งออกมาคุณภาพไม่ดี เช่น “คุณพูดถูก นี่มันลวกเกินไป”, “ฉันรีบเกินไป ผลลัพธ์เห็นชัด”
นั่นคือ โมเดลเองก็รู้ว่าผลลัพธ์ที่ส่งออกมาไม่ถึงมาตรฐาน แต่จะค้นพบก็ต่อเมื่อถูกแก้ไขจากภายนอก
เป็นที่น่าสังเกตว่า หากความลึกในการคิดเพียงพอ ข้อผิดพลาดเหล่านี้ควรถูกสกัดกั้นภายในในขั้นตอนการให้เหตุผล และได้รับการแก้ไขก่อนส่งออก
และ การที่คำว่า “Simplest Fix” (การแก้ไขที่ง่ายที่สุด) ปรากฏในการส่งออกของโมเดล เป็นสัญญาณที่ชัดเจน: มันกำลังปรับให้เหมาะสมเพื่อลดปริมาณงานของตัวเองให้น้อยที่สุด
เมื่อความลึกในการคิดเพียงพอ โมเดลจะประเมินหลายแผนและเลือกวิธีแก้ไขที่ดีที่สุด; เมื่อความลึกในการคิดไม่เพียงพอ มันจะเลือกเส้นทางที่มีต้นทุนการให้เหตุผลต่ำที่สุดโดยสัญชาตญาณ แทนที่จะประเมินวิธีแก้ไขที่ถูกต้อง
ไม่เพียงเท่านั้น ความแม่นยำในการแก้ไขโค้ดของโมเดลก็ลดลงอย่างมากเช่นกัน
ในช่วงคุณภาพดี สัดส่วนของการสร้างไฟล์ใหม่ทั้งหมดต่อการดำเนินการแก้ไขมีเพียง 4.9% โมเดลมีแนวโน้มที่จะทำการปรับเปลี่ยนอย่างแม่นยำ
แต่ในช่วงถดถอย สัดส่วนนี้เพิ่มเป็นสองเท่าทันทีเป็น 10% และในระยะหลังยิ่งเพิ่มขึ้นเป็น 11.1% โมเดลพึ่งพาวิธีการเขียนไฟล์ทั้งหมดใหม่เพื่อทำงานมากขึ้น ดูเหมือนประสิทธิภาพเพิ่มขึ้น แต่จริงๆ แล้วสูญเสียความเข้าใจในข้อกำหนดเฉพาะของโปรเจกต์และความสามารถในการรับรู้คอนเท็กซ์
ก่อนหน้านี้ชุมชนเคยรายงานว่า คุณภาพของ Claude Code จะผันผวนตามช่วงเวลาต่างๆ ของวัน ประสบการณ์แย่ที่สุดในช่วงเวลาทำงานของสหรัฐอเมริกา เพื่อตอบสนองต่อข้อเสนอแนะนี้ รายงานได้วิเคราะห์รายชั่วโมงตามเวลามาตรฐานแปซิฟิก (PST)
ผลลัพธ์พบว่า ก่อนเปิดตัวฟังก์ชันซ่อนเนื้อหาการคิด (30 ม.ค. – 7 มี.ค.) ความลึกในการคิดค่อนข้างคงที่ตลอดทั้งวัน ช่วงนอกเวลาหน้าแน่นมีข้อได้เปรียบเพียงเล็กน้อยประมาณ 10% ซึ่งสอดคล้องกับความคาดหวังที่ว่าโหลดเซิร์ฟเวอร์ต่ำกว่าเล็กน้อย
หลังจากเปิดตัวฟังก์ชันซ่อนเนื้อหาการคิด (8 มี.ค. – 1 เม.ย.) โหมดช่วงเวลาถูกพลิกกลับอย่างสิ้นเชิง ความผันผวนรุนแรงขึ้นมาก:
ตรงข้ามกับสมมติฐาน ความลึกในการคิดโดยรวมในช่วงนอกเวลาหน้าแน่นกลับต่ำกว่า รายละเอียดรายชั่วโมงเผยให้เห็นความผันผวนที่เด่นชัด:
เวลา 17:00 น. PST เป็นช่วงเวลาที่แย่ที่สุด ความลึกในการคิดโดยประมาณค่ามัธยฐานลดลงเหลือ 423 ตัวอักษร ซึ่งเป็นค่าต่ำสุดในทุกช่วงเวลาที่มีตัวอย่างขนาดใหญ่ เวลา 19:00 น. เป็นช่วงเวลาที่แย่เป็นอันดับสอง ความลึกในการคิดโดยประมาณเพียง 373 ตัวอักษร และขนาดตัวอย่าง (1031 บล็อกความคิด) สูงที่สุดในทุกช่วงเวลา ซึ่งเป็นช่วงเวลาทองของการใช้งานของสหรัฐอเมริกา
ช่วงดึก (22:00-01:00 น. PST) ฟื้นตัว ความลึกค่ามัธยฐานกลับขึ้นมาอยู่ที่ 759-3281 ตัวอักษร
สรุปได้ว่า ก่อนเปิดฟังก์ชันซ่อน เส้นโค้งคงที่ หลังเปิดฟังก์ชันซ่อน ความผันผวนรุนแรง ความผันผวนของความลึกในการคิดเพิ่มขึ้นอย่างมาก สอดคล้องกับลักษณะของระบบจัดสรรที่ไวต่อโหลด (แทนที่จะเป็นงบประมาณคงที่)
นอกจากนี้ การลดทอนโทเคนสำหรับการคิดกลับได้ไม่คุ้มเสีย
การดำเนินการเช่นนี้ดูเหมือนจะลดต้นทุนการคำนวณต่อคำขอได้ แต่ความลึกในการคิดที่ไม่เพียงพอนำไปสู่การพังทลายของคุณภาพ โมเดลติดอยู่ในวงจรที่ไม่มีประสิทธิภาพ สุดท้ายทำให้ต้นทุนการคำนวณรวมพุ่งสูงขึ้นเป็นทวีคูณ
ต่อไปนี้คือสถานการณ์การใช้โทเคนตั้งแต่เดือนมกราคมถึงมีนาคม 2026:
ข้อมูลแสดงให้เห็นว่า
⚠️ หมายเหตุ: เนื้อหาได้รับการแปลโดย AI และตรวจสอบโดยมนุษย์ หากมีข้อผิดพลาดโปรดแจ้ง
☕ สนับสนุนค่ากาแฟทีมงาน
หากคุณชอบบทความนี้ สามารถสนับสนุนเราได้ผ่าน PromptPay
本文来自网络搜集，不代表คลื่นสร้างอนาคต立场，如有侵权，联系删除。转载请注明出处：https://www.itsolotime.com/th/archives/29023