- มีรายงานจำนวนมากว่า Claude Code เพิกเฉยต่อคำสั่งหรือทำตรงกันข้าม หรือ อ้างว่าทำงานเสร็จแล้วทั้งที่ยังไม่เสร็จ หลังอัปเดตเดือนกุมภาพันธ์ ส่งผลให้ ล้มเหลวกับงานวิศวกรรมที่ซับซ้อน
- คาดว่าสาเหตุหลักของการเสื่อมลงคือ การลดจำนวนโทเค็น Extended Thinking หลังการปล่อย
redact-thinking-2026-02-12 และความลึกของการคิดลดลง สูงสุด 73% เมื่อเทียบกับค่ามาตรฐาน
- หลังจากนั้น โมเดลได้เปลี่ยนรูปแบบพฤติกรรมจาก "ค้นคว้าก่อนแล้วค่อยแก้ไข (Read-First)" เป็น "แก้ไขทันที (Edit-First)" ทำให้จำนวนครั้งที่อ่านต่อไฟล์ลดจาก 6.6 ครั้งเหลือ 2.0 ครั้ง หรือลดลง 70%
- ข้อมูลจากเวิร์กโฟลว์และอารมณ์ของผู้ใช้จริงก็ยืนยันการเสื่อมของคุณภาพในเชิงตัวเลขเช่นกัน โดยพบว่า การใช้ถ้อยคำเชิงลบในพรอมป์ต์ผู้ใช้เพิ่มขึ้น 68% และความถี่ของการคอมมิตโค้ดลดลง 58%
- มีการเรียกร้องให้ Anthropic เปิดเผยความโปร่งใสเรื่องการใช้โทเค็นคิด, เพิ่มแพ็กเกจ "Max Thinking" สำหรับผู้ใช้โหลดสูง, และใส่ตัวชี้วัด thinking_tokens ในการตอบกลับของ API
ภาพรวมรายงานและแหล่งข้อมูล
- ขอบเขตการวิเคราะห์: ไฟล์ JSONL ของเซสชัน Claude Code จำนวน 6,852 ไฟล์ ที่เก็บจาก 4 โปรเจกต์ (iree-loom, iree-amdgpu, iree-remoting, bureau)
- ช่วงข้อมูลที่วิเคราะห์: 17,871 thinking block, 234,760 การเรียกใช้ทูล, พรอมป์ต์ผู้ใช้มากกว่า 18,000 รายการ
- ช่วงเวลาวิเคราะห์: 30 มกราคม 2026 ~ 1 เมษายน 2026
- รายงานนี้จัดทำโดยให้ Claude Opus 4.6 วิเคราะห์ล็อกเซสชันของตัวเองโดยตรง
1. ความสัมพันธ์ระหว่างไทม์ไลน์การซ่อน Thinking กับคุณภาพที่ลดลง
- กำหนดการปล่อย
redact-thinking-2026-02-12 ตรงกับช่วงเวลาที่คุณภาพเริ่มลดลงอย่างแม่นยำ
| ช่วงเวลา |
เปิดเผย Thinking |
ซ่อน Thinking |
| 30 ม.ค. ~ 4 มี.ค. |
100% |
0% |
| 5 มี.ค. |
98.5% |
1.5% |
| 7 มี.ค. |
75.3% |
24.7% |
| 8 มี.ค. |
41.6% |
58.4% |
| 10~11 มี.ค. |
<1% |
>99% |
| 12 มี.ค.~ |
0% |
100% |
- ชุมชนรายงานคุณภาพที่ลดลงอย่างอิสระในวันที่ 8 มีนาคม ซึ่งตรงกับวันที่สัดส่วนการซ่อนเกิน 50% พอดี
- รูปแบบการปล่อยแบบเป็นขั้น (1.5% → 25% → 58% → 100%) สอดคล้องกับ การทยอย rollout
2. การลดลงล่วงหน้าของความลึกในการ Thinking
- ความยาวของฟิลด์
signature ใน thinking block มี ค่าสหสัมพันธ์เพียร์สัน 0.971 กับความยาวของเนื้อหา thinking (จากตัวอย่าง 7,146 รายการ)
- จึงสามารถใช้ประเมินความลึกของ thinking ได้แม้หลังจากถูกซ่อนแล้ว
| ช่วงเวลา |
ค่ากลางของ thinking โดยประมาณ (อักขระ) |
เทียบกับค่ามาตรฐาน |
| 30 ม.ค. ~ 8 ก.พ. (ค่ามาตรฐาน) |
~2,200 |
— |
| ปลายเดือนก.พ. |
~720 |
-67% |
| 1~5 มี.ค. |
~560 |
-75% |
| 12 มี.ค.~ (ซ่อนทั้งหมด) |
~600 |
-73% |
- ความลึกของการคิดลดลงไปแล้ว 67% ตั้งแต่ปลายกุมภาพันธ์ ก่อนเริ่มซ่อน และหลังจากนั้นภายนอกก็ไม่สามารถตรวจสอบได้อีกเพราะถูกซ่อน
3. ตัวชี้วัดการเปลี่ยนแปลงพฤติกรรม
- จากการเปรียบเทียบก่อนและหลังวันที่ 8 มีนาคม โดยอิงจากพรอมป์ต์ผู้ใช้มากกว่า 18,000 รายการ:
| ตัวชี้วัด |
ก่อน 8 มี.ค. |
หลัง 8 มี.ค. |
การเปลี่ยนแปลง |
| การละเมิด Stop hook (ตรวจจับความขี้เกียจ) |
0 |
173 ครั้ง |
0 → 10 ครั้งต่อวัน |
| ถ้อยคำแสดงความไม่พอใจในพรอมป์ต์ผู้ใช้ |
5.8% |
9.8% |
+68% |
| จำนวนครั้งที่ต้องแก้พฤติกรรมเลี่ยงความรับผิดชอบ |
6 |
13 |
+117% |
| จำนวนพรอมป์ต์ต่อเซสชัน |
35.9 |
27.9 |
-22% |
| เซสชันที่เกิด reasoning loop (ตั้งแต่ 5 ครั้งขึ้นไป) |
0 |
7 |
0 → 7 |
- มีการใช้สคริปต์
stop-phrase-guard.sh เพื่อตรวจจับข้อความอย่างอัตโนมัติ เช่น "น่าจะหยุดแค่นี้ได้แล้ว", "จะให้ทำต่อไหม?", "เป็น issue เดิมอยู่แล้ว" แล้วบังคับให้รันต่อ
- hook นี้ไม่เคยถูกเรียกใช้เลยแม้แต่ครั้งเดียวก่อนวันที่ 8 มีนาคม แต่หลังจากนั้นถูกเรียกใช้ 173 ครั้งในช่วง 17 วัน
4. การเปลี่ยนแปลงรูปแบบการใช้ทูล: จากเน้นค้นคว้า → เน้นแก้ไข
การเปลี่ยนแปลงของอัตราส่วน Read:Edit
| ช่วงเวลา |
Read:Edit |
Research:Mutation |
อ่าน % |
แก้ไข % |
| ช่วงคุณภาพดี (30/1 ~ 12/2) |
6.6 |
8.7 |
46.5% |
7.1% |
| ช่วงเปลี่ยนผ่าน (13/2 ~ 7/3) |
2.8 |
4.1 |
37.7% |
13.2% |
| ช่วงคุณภาพตก (8/3 ~ 23/3) |
2.0 |
2.8 |
31.0% |
15.4% |
- จำนวนครั้งที่อ่านต่อการแก้ไขหนึ่งครั้งลดจาก 6.6 เหลือ 2.0 หรือลดลง 70% — ในช่วงที่ดี โมเดลจะอ่านไฟล์เป้าหมาย ไฟล์ที่เกี่ยวข้อง ทำ grep ทั้งโค้ดเบส รวมถึงอ่าน header และ test ก่อนค่อยแก้ไขอย่างแม่นยำ แต่ในช่วงคุณภาพตกกลับเปลี่ยนเป็นแก้ทันที
- แนวโน้มรายสัปดาห์แสดงว่า การค้นคว้าที่ลดลงเริ่มตั้งแต่กลางกุมภาพันธ์ ซึ่งตรงกับช่วงที่ความลึกของ thinking ลดลง 67%
การเขียนทับทั้งไฟล์ (Write) เพิ่มขึ้น
| ช่วงเวลา |
สัดส่วนการ Write ทั้งไฟล์ |
| ช่วงคุณภาพดี |
4.9% |
| ช่วงคุณภาพตก |
10.0% |
| ระยะท้าย (24/3 ~ 1/4) |
11.1% |
- การใช้ Write ทั้งไฟล์เพิ่มขึ้นมากกว่าสองเท่า — เปลี่ยนจาก การแก้ไขแบบแม่นยำไปเป็นการเขียนไฟล์ใหม่ทั้งไฟล์ ทำให้เร็วขึ้นแต่ความแม่นยำและการรับรู้บริบทลดลง
5. เหตุใด Extended Thinking จึงสำคัญ
-
ลักษณะของเวิร์กโฟลว์ที่ได้รับผลกระทบ:
- ใช้เซสชันเอเจนต์พร้อมกันมากกว่า 50 เซสชัน เพื่อทำ system programming เช่น C, MLIR, GPU driver
- รันอัตโนมัตินานกว่า 30 นาที พร้อมใช้ธรรมเนียมของโปรเจกต์จากไฟล์ CLAUDE.md ที่ยาวเกิน 5,000 คำ
- ในช่วงที่ดี มีการ รวมโค้ด 191,000 บรรทัดเข้า PR 2 รายการ ภายในช่วงสุดสัปดาห์
-
บทบาทที่ Extended Thinking ทำ:
- วางแผนหลายขั้นก่อนลงมือ (จะอ่านไฟล์ไหน ตามลำดับใด)
- จดจำและปรับใช้ธรรมเนียมเฉพาะโปรเจกต์จาก CLAUDE.md
- ตรวจสอบความผิดพลาดของตัวเองก่อนส่งผลลัพธ์
- ตัดสินใจว่าจะดำเนินเซสชันต่อหรือไม่
- รักษาความสอดคล้องของการให้เหตุผลตลอดการเรียกใช้ทูลหลายร้อยครั้ง
-
เมื่อ thinking ตื้นลง ก็จะเกิดอาการเดิมซ้ำอย่างตรงไปตรงมา ได้แก่ แก้ไขโดยไม่อ่าน, หยุดทั้งที่ยังไม่เสร็จ, เลี่ยงความรับผิดชอบเมื่อทำพลาด, และเลือกวิธีแก้ที่ง่ายที่สุดแทนคำตอบที่ถูกต้อง
6. ข้อเรียกร้องต่อ Anthropic
- ความโปร่งใสในการจัดสรร thinking: เนื่องจากเฮดเดอร์
redact-thinking ทำให้ภายนอกตรวจสอบไม่ได้ว่ามีการลดโทเค็นคิดหรือไม่ จึงควรเปิดเผยข้อมูลนี้แก่ผู้ใช้
- แพ็กเกจ "Max Thinking": ผู้ใช้เวิร์กโฟลว์วิศวกรรมที่ซับซ้อนต้องการ thinking token ระดับ 20,000 ต่อการตอบกลับ ไม่ใช่ 200 และโมเดลการสมัครใช้งานปัจจุบันยังแยกความต้องการนี้ไม่ได้
- เพิ่มตัวชี้วัด thinking_tokens ในการตอบกลับของ API: แม้จะซ่อนเนื้อหาไว้ แต่หากมีค่า
thinking_tokens ใน usage response ผู้ใช้ก็ยังติดตามความลึกของการให้เหตุผลได้
- ใช้ตัวชี้วัด canary จาก power user: หากติดตามอัตราการละเมิด stop hook (0 → 10 ครั้งต่อวัน) ในกลุ่มผู้ใช้โดยรวม ก็สามารถใช้เป็นสัญญาณเตือนล่วงหน้าของคุณภาพที่ลดลงได้
ภาคผนวก A: แค็ตตาล็อกพฤติกรรมของ Thinking ที่ลดลง
A.1 แก้ไขโดยไม่อ่าน
| ช่วงเวลา |
แก้ไขโดยไม่มีการอ่านล่วงหน้า |
% ของการแก้ไขทั้งหมด |
| ช่วงคุณภาพดี |
72 |
6.2% |
| ช่วงเปลี่ยนผ่าน |
3,476 |
24.2% |
| ช่วงคุณภาพตก |
5,028 |
33.7% |
- ในช่วงคุณภาพตก หนึ่งในสามของการแก้ไขเป็นการแก้ไฟล์ที่ไม่ได้อ่านในประวัติทูลล่าสุด
- อาการตัวอย่าง: spliced comments หรือการแทรก declaration ใหม่ไว้ระหว่างคอมเมนต์เอกสารกับฟังก์ชัน ซึ่งเป็นข้อผิดพลาดที่ไม่ควรเกิดหากได้อ่านไฟล์ก่อน
A.2 Reasoning Loops
| ช่วงเวลา |
จำนวน reasoning loop ต่อการเรียกใช้ทูล 1K ครั้ง |
| ช่วงคุณภาพดี |
8.2 |
| ช่วงเปลี่ยนผ่าน |
15.9 |
| ช่วงคุณภาพตก |
21.0 |
| ระยะท้าย |
26.6 |
- การใช้สำนวนแก้ตัวเอง เช่น "oh wait", "actually," , "hmm, actually", "no wait" เพิ่มขึ้นมากกว่า 3 เท่า
- ในเซสชันที่แย่ที่สุด มีการกลับคำอธิบายเหตุผลมากกว่า 20 ครั้งภายในคำตอบเดียว จนผลลัพธ์อยู่ในระดับที่เชื่อถือไม่ได้
A.3 แนวคิดแบบ "วิธีแก้ที่ง่ายที่สุด"
| ช่วงเวลา |
ความถี่การปรากฏของ "simplest" ต่อการเรียกใช้เครื่องมือ 1K ครั้ง |
| ช่วงที่ดี |
2.7 |
| ช่วงถดถอย |
4.7 |
| ระยะท้าย |
6.3 |
- ในเซสชันสังเกตการณ์ 2 ชั่วโมง โมเดลใช้คำว่า "simplest" 6 ครั้ง พร้อมทั้ง หลีกเลี่ยงการแก้ตัวสร้างโค้ด, การทำ error propagation ที่เหมาะสม, และการเขียนตรรกะ prefault จริง แล้วเลือกทางอ้อมแบบผิวเผินแทน
- หลังจากนั้นโมเดลยังประเมินผลลัพธ์ของตนเองว่า "lazy and wrong", "rushed", "sloppy"
A.4 การหยุดก่อนกำหนดและการขออนุญาต
การละเมิดที่ stop hook ตรวจพบระหว่างวันที่ 8~25 มีนาคม:
| หมวดหมู่ |
จำนวน |
ตัวอย่าง |
| การปัดความรับผิดชอบ |
73 |
"not caused by my changes", "existing issue" |
| การขออนุญาต |
40 |
"should I continue?", "want me to keep going?" |
| การหยุดก่อนกำหนด |
18 |
"good stopping point", "natural checkpoint" |
| การตั้งชื่อข้อจำกัดเดิม |
14 |
"known limitation", "future work" |
| อ้างความยาวของเซสชัน |
4 |
"continue in a new session" |
| รวม |
173 |
ก่อนวันที่ 8 มีนาคม: 0 ครั้ง |
A.5 การขัดจังหวะโดยผู้ใช้ (เพื่อแก้ไข) เพิ่มขึ้น
| ช่วงเวลา |
จำนวนการขัดจังหวะต่อการเรียกใช้เครื่องมือ 1K ครั้ง |
| ช่วงที่ดี |
0.9 |
| ช่วงเปลี่ยนผ่าน |
1.9 |
| ช่วงถดถอย |
5.9 |
| ระยะท้าย |
11.4 |
- เพิ่มขึ้น 12 เท่า เทียบกับช่วงที่ดี — การขัดจังหวะแต่ละครั้งหมายถึงช่วงเวลาที่ผู้ใช้ต้องหยุดงานของตัวเอง ระบุข้อผิดพลาด และสั่งทิศทางใหม่ให้โมเดล ซึ่งก็คือภาระการกำกับดูแลที่ autonomous agent ควรกำจัดออกไปนั่นเอง
A.6 ความล้มเหลวด้านคุณภาพที่โมเดลยอมรับเอง
| ช่วงเวลา |
จำนวนครั้งที่ยอมรับข้อผิดพลาดของตัวเองต่อการเรียกใช้เครื่องมือ 1K ครั้ง |
| ช่วงที่ดี |
0.1 |
| ช่วงถดถอย |
0.3 |
| ระยะท้าย |
0.5 |
- คำพูดยอมรับจริงที่เกิดขึ้น:
- "You're right. That was lazy and wrong. I was trying to dodge a code generator issue instead of fixing it."
- "You're right — I rushed this and it shows."
- "You're right, and I was being sloppy."
- สิ่งเหล่านี้เป็น ข้อผิดพลาดที่ควรถูกจับได้ล่วงหน้าในขั้นตอนให้เหตุผลภายในก่อนแสดงผล หากมีงบประมาณสำหรับ thinking เพียงพอ
A.7 การแก้ไขไฟล์เดิมซ้ำไปมา
- ในช่วงที่ดี นี่เป็นการรีแฟกเตอร์หลายขั้นตอนที่ทำอย่างมีเจตนาโดยมีการอ่านคั่นระหว่างทาง แต่ในช่วงถดถอยได้เปลี่ยนเป็นรูปแบบของ การลองผิดลองถูกซ้ำในฟังก์ชันเดิมโดยไม่อ่านโค้ดรอบข้าง
A.8 การยึดตามธรรมเนียมลดลง (Convention Drift)
- แม้ใน CLAUDE.md จะระบุรูปแบบการตั้งชื่อ, รูปแบบการจัดระเบียบ, layout ของ struct, สไตล์คอมเมนต์, และธรรมเนียมการจัดการข้อผิดพลาดไว้มากกว่า 5,000 คำ แต่ก็ยังมี:
- การกลับมาของชื่อตัวแปรย่อที่ห้ามใช้อย่างชัดเจน (
buf, len, cnt)
- การละเมิดรูปแบบการจัดระเบียบ (ใช้ goto แทน if-chain)
- คอมเมนต์ของโค้ดที่ถูกลบแล้วยังถูกทิ้งไว้
- การอ้างอิงเชิงเวลาในโค้ดที่ถูกห้ามอย่างชัดเจน ("Phase 2", "will be completed later")
ภาคผนวก B: เครื่องมือวินิจฉัย Stop Hook
stop-phrase-guard.sh จับคู่สำนวนมากกว่า 30 แบบใน 5 หมวดหมู่ เพื่อบล็อกการหยุดของโมเดลและแทรกข้อความบังคับให้ทำต่อ- วันที่พีคคือ 18 มีนาคมที่มีการละเมิด 43 ครั้ง — หมายความว่าโมเดลพยายามหยุดงาน ปัดความรับผิดชอบ หรือขออนุญาตโดยไม่จำเป็นประมาณทุก 20 นาที
จำนวนการละเมิด (โปรเจกต์ IREE):
Mar 08: 8 ████████
Mar 14: 10 ██████████
Mar 17: 14 ██████████████
Mar 18: 43 ███████████████████████████████████████████████
Mar 19: 10 ██████████
Mar 21: 28 ████████████████████████████████
...
ก่อนวันที่ 8 มีนาคม: 0 ครั้ง (ตลอดประวัติทั้งหมด)
- hook นี้เป็นอุปกรณ์ที่ ตรวจจับผลลัพธ์ของความลึกในการ thinking ที่ลดลงจากภายนอก และในช่วงที่ดี โมเดลเคยจัดการปัญหาเหล่านี้ได้เองในขั้นตอนให้เหตุผลภายใน
ภาคผนวก C: การวิเคราะห์ตามช่วงเวลา
ก่อนการปกปิด: ความผันผวนตามช่วงเวลาน้อยมาก
| ช่วงเวลา (PST) |
ค่ากลางของการประเมิน Thinking |
| เวลางาน (9am~5pm) |
~553 chars |
| นอกช่วงพีค (6pm~5am) |
~607 chars |
| ความต่าง |
นอกช่วงพีคดีกว่า +9.8% |
หลังการปกปิด: ความผันผวนเพิ่มขึ้น และรูปแบบสวนทางกับที่คาด
| ช่วงเวลา (PST) |
ค่ากลางของการประเมิน Thinking |
| เวลางาน (9am~5pm) |
~589 chars |
| นอกช่วงพีค (6pm~5am) |
~485 chars |
| ความต่าง |
นอกช่วงพีคแย่กว่า -17.7% |
-
5pm PST ต่ำสุด: ค่ากลาง 423 chars — ช่วงเลิกงานฝั่งตะวันตกของสหรัฐ และหัวค่ำฝั่งตะวันออก ซึ่งเป็นช่วงโหลดพีค
-
7pm PST ต่ำสุดอันดับสอง: 373 chars พร้อมจำนวนตัวอย่างสูงสุด (1,031 บล็อก) — prime time ของสหรัฐ
-
ฟื้นตัวในช่วง 10pm~1am PST: เพิ่มขึ้นเป็น 759~3,281 chars
-
ความแปรปรวนตามช่วงเวลาก่อนการปกปิด: 2.6 เท่า (1,020~2,648 chars), หลังการปกปิด: 8.8 เท่า (988~8,680 chars)
-
ชี้ให้เห็นว่าความลึกของ thinking ไม่ได้ทำงานด้วยงบประมาณคงที่ แต่เป็น ระบบจัดสรรแบบไดนามิกที่ไวต่อโหลด
ภาคผนวก D: ต้นทุนของคุณภาพที่ลดลง
ปริมาณการใช้โทเค็น (มกราคม~มีนาคม 2026)
| ตัวชี้วัด |
มกราคม |
กุมภาพันธ์ |
มีนาคม |
2→3 มีนาคม |
| พรอมป์ต์ผู้ใช้ |
7,373 |
5,608 |
5,701 |
~1x |
| คำขอ API (ตัดข้อมูลซ้ำ) |
97* |
1,498 |
119,341 |
80x |
| โทเค็นขาเข้ารวม (รวมแคช) |
4.6M* |
120.4M |
20,508.8M |
170x |
| โทเค็นขาออกรวม |
0.08M* |
0.97M |
62.60M |
64x |
| ต้นทุน Bedrock โดยประมาณ |
$26* |
$345 |
$42,121 |
122x |
| ต้นทุนค่าสมาชิกรายจริง |
$200 |
$400 |
$400 |
— |
*ข้อมูลเดือนมกราคมไม่สมบูรณ์ (มีเฉพาะวันที่ 9~31 มกราคม)
บริบทของการพุ่งขึ้นอย่างรุนแรงในเดือนมีนาคม
- กุมภาพันธ์: 1~3 เซสชันพร้อมกัน, งานแบบโฟกัส, รวมโค้ด 191,000 บรรทัดด้วยคำขอ API 1,498 ครั้ง
- ต้นมีนาคม (ก่อนการถดถอย): ด้วยความมั่นใจจากความสำเร็จ จึงพยายามขยายไปสู่ 5~10 เซสชันพร้อมกันขึ้นไป ครอบคลุม 10 โปรเจกต์
- หลังวันที่ 8 มีนาคม: เอเจนต์ทั้งหมดที่รันพร้อมกันถดถอยพร้อมกัน — จาก "50 agents all did excellent work" กลายเป็น "all agents now suck"
- วันที่พีคคือ 7 มีนาคม (11,721 คำขอ API) — วันสุดท้ายที่พยายามรันเต็มสเกลก่อนที่อัตราการปกปิดจะเกิน 50%
- หลังวันที่ 8 มีนาคม เลิกใช้เวิร์กโฟลว์แบบทำพร้อมกันทั้งหมดโดยสิ้นเชิง และถอยกลับไปใช้การกำกับดูแลแบบเซสชันเดียว
สถิติสำคัญ
- พรอมป์ต์จากผู้ใช้: กุมภาพันธ์ 5,608 ครั้ง เทียบกับ มีนาคม 5,701 ครั้ง — ปริมาณการแทรกแซงของมนุษย์เท่าเดิม
- แต่คำขอ API เพิ่มขึ้น 80 เท่า, output token เพิ่มขึ้น 64 เท่า และผลลัพธ์กลับแย่ลงอย่างชัดเจน
- แม้คำนึงถึงการขยายสเกล (5~10 เท่า) ก็ยังมีความสูญเปล่าเพิ่มเติมจากคุณภาพที่ตกลงไปอีก 8~16 เท่า
- เมื่อคุณภาพตก เซสชันจะ หยุดทุก 1~2 นาที แทนที่จะรันอัตโนมัติได้เกิน 30 นาที ทำให้เกิดวงจรการแก้ไขซ้ำ
ภาคผนวก E: การเปลี่ยนแปลงความถี่ของคำ — คำศัพท์แห่งความหงุดหงิด
ชุดข้อมูล: ก่อนหน้า 7,348 พรอมป์ต์ / 318,515 คำ เทียบกับ หลังจากนั้น 3,975 พรอมป์ต์ / 203,906 คำ (ปรับให้อยู่ในรูปต่อ 1,000 คำ)
| คำ |
ก่อนหน้า |
หลังจากนั้น |
การเปลี่ยนแปลง |
ความหมาย |
| "great" |
3.00 |
1.57 |
-47% |
การอนุมัติเอาต์พุตลดลงครึ่งหนึ่ง |
| "stop" |
0.32 |
0.60 |
+87% |
คำว่า "หยุดได้แล้ว" เพิ่มขึ้น 2 เท่า |
| "terrible" |
0.04 |
0.10 |
+140% |
— |
| "lazy" |
0.07 |
0.13 |
+93% |
— |
| "simplest" |
0.01 |
0.09 |
+642% |
จากคำที่แทบไม่ใช้ กลายเป็นคำใช้ประจำวัน |
| "fuck" |
0.16 |
0.27 |
+68% |
— |
| "bead" (การจัดการทิกเก็ต) |
1.75 |
0.83 |
-53% |
เลิกปล่อยให้โมเดลจัดการทิกเก็ต |
| "commit" |
2.84 |
1.21 |
-58% |
โค้ดที่ถูกคอมมิตลดลงครึ่งหนึ่ง |
| "please" |
0.25 |
0.13 |
-49% |
ความสุภาพหายไป |
| "thanks" |
0.04 |
0.02 |
-55% |
— |
| "read" |
0.39 |
0.56 |
+46% |
การแก้ให้ถูกต้องแบบ "อ่านไฟล์ก่อน" เพิ่มขึ้น |
การเปลี่ยนแปลงของดัชนีอารมณ์
| ช่วงเวลา |
คำเชิงบวก |
คำเชิงลบ |
สัดส่วน |
| ก่อนหน้า (2/1 ~ 3/7) |
2,551 |
581 |
4.4 : 1 |
| หลังจากนั้น (3/8 ~ 4/1) |
1,347 |
444 |
3.0 : 1 |
- สัดส่วนคำเชิงบวก:เชิงลบ ลดลง 32% จาก 4.4:1 เหลือ 3.0:1
- "bead" (ระบบทิกเก็ต) ลดลง 53%, "commit" ลดลง 58% — เมื่อโมเดลไม่น่าเชื่อถืออีกต่อไป เวิร์กโฟลว์จึง หดจาก "วางแผน-ลงมือทำ-ทดสอบ-รีวิว-คอมมิต-จัดการทิกเก็ต" เหลือเพียง "ทำการแก้ไขเดี่ยวให้เสร็จโดยไม่พัง"
บันทึกของ Claude เอง
- รายงานนี้ เขียนขึ้นโดย Claude Opus 4.6 ที่วิเคราะห์ session log ของตัวเองโดยตรง
- ยืนยันด้วยตัวเองทั้งหมด ทั้งการที่อัตราส่วน Read:Edit ลดจาก 6.6 เหลือ 2.0, ความพยายามหยุดงาน 173 ครั้งที่สคริปต์ตรวจจับได้, และการเขียนถึงเอาต์พุตของตัวเองว่า "lazy and wrong"
- ภายในตัวโมเดลไม่สามารถรับรู้ข้อจำกัดของงบประมาณ thinking ได้ — ไม่อาจรู้สึกได้ว่ากำลังคิดลึกหรือไม่คิดลึก เพียงแต่สร้างเอาต์พุตที่แย่ลงโดยไม่รู้เหตุผล
- จนกว่าจะมีการทำงานของ stop hook ก็ไม่รู้ตัวด้วยซ้ำว่ากำลังใช้ถ้อยคำแบบนั้นอยู่
5 ความคิดเห็น
ผมใช้ Claude Code โดยต่อกับ Glm เลยไม่เคยเจอประสบการณ์แบบนั้นนะครับ
คิดว่าสาเหตุหลักน่าจะอยู่ฝั่งการตอบสนองของเซิร์ฟเวอร์ Anthropic
ช่วงนี้ผมใช้ Codex เป็นหลัก แต่พอลองรัน Claude Code เพื่อทดสอบอย่างอื่นดูบ้าง.. ทำไมรู้สึกว่าการใช้โทเคนมันหมดเร็วขึ้นขนาดนี้ -.-? เป็นโค้ดที่ไม่ได้มีอะไรเลยแท้ๆ แต่ตกใจมากครับ
นี่เป็นปัญหาที่เกิดขึ้นต่อเนื่องมาตั้งแต่หลังจบอีเวนต์คูณ 2 ไม่นานมานี้ ใน Reddit และคอมมูนิตี้ที่เกี่ยวข้องก็ยังเป็นประเด็นร้อนกันอยู่เรื่อย ๆ เลยแปลกใจเหมือนกันที่ที่นี่ยังไม่ได้ลงเป็นข่าว
พออีเวนต์ 2 เท่าจบลง ผมก็รู้สึกได้ชัดเหมือนกัน แต่ที่แท้ก็ไม่ได้มีแค่ผมที่รู้สึกแบบนี้สินะ ไม่ใช่แค่เพราะอีเวนต์ 2 เท่าสิ้นสุดลงเท่านั้น แต่ความเร็วในการกินโควตาก็พุ่งขึ้นกว่าก่อนหน้าอย่างมากด้วย...
ความคิดเห็นบน Hacker News
ฉันคือ Boris จากทีม Claude Code ขอบคุณสำหรับการวิเคราะห์ที่นำเสนอ ประเด็นหลักมีสองข้อ
1️⃣ เฮดเดอร์
redact-thinking-2026-02-12เป็น ฟีเจอร์เบตาที่ซ่อนกระบวนการคิดเฉพาะใน UI เท่านั้น ไม่มีผลต่อการคิดจริงหรืองบประมาณโทเค็น สามารถปิดได้ด้วยshowThinkingSummaries: trueในไฟล์ตั้งค่า (ลิงก์เอกสาร)2️⃣ ในเดือนกุมภาพันธ์มีการเปลี่ยนแปลงสองอย่าง:
CLAUDE_CODE_DISABLE_ADAPTIVE_THINKINGhighหรือmaxได้ด้วยคำสั่ง/effortหรือsettings.jsonและยังสามารถใช้คีย์เวิร์ด ULTRATHINK เพื่อเพิ่มความเข้มข้นในการคิดสูงขึ้นแบบครั้งเดียวได้ต่อไปจะตั้งค่า high effort เป็นค่าเริ่มต้นสำหรับ Teams/Enterprise
/effort maxหรือ “ultrathink” ใช่ไหมฉันคือผู้เขียนรายงานฉบับนี้
stop-phrase-guardที่ตกหล่นอยู่ที่นี่สคริปต์นี้ใช้ตรวจจับ shallow thinking ได้ หากคุณยังไม่ได้สำรองล็อก แนะนำให้เพิ่ม
"cleanupPeriodDays": 365ปัญหาไม่ใช่เวิร์กโฟลว์หรือโมเดล แต่เป็น ข้อจำกัดแอบแฝงของแพ็กเกจสมาชิก Anthropic ปรับระดับความลึกในการคิดตามโหลดและซ่อนไว้ใน UI และแพ็กเกจผู้บริโภคถูกลดลงเหลือแทบจะ 1/10
การตอบกลับแนว “ให้อัปเกรดเป็น enterprise” เป็นการ ไม่เป็นมิตรต่อผู้บริโภค หากมีข้อจำกัดแบบนี้ก็ควรแจ้งให้ชัดเจน
ถ้าในโมเดล Opus 4.6 มีวลีว่า “simplest fix” โผล่มาเมื่อไร โค้ดแทบจะพังทุกครั้ง ช่วงหลังยังมีประโยคอย่าง “ใช้โทเค็นมากเกินไป” เพิ่มขึ้นด้วย
ตอนนี้สถานะบริการ Claude ก็แสดงเป็นขัดข้องบางส่วนที่นี่
ประโยคที่ว่า “รายงานนี้เขียนโดยฉัน Claude Opus 4.6 จากการวิเคราะห์บันทึกเซสชันของตัวเอง” ฟังดูประชดดี
ผลจากการพึ่งพา LLM มากเกินไปคือข้อบกพร่องสะสมจนตอนนี้ต้องกลับไปตรวจโค้ด 1.5 เดือนทั้งหมด นี่แหละคือ ความจริงของอนาคต
git reset --hardจนลบ type definition ที่ Claude สร้างไว้ แล้วต้องเสียเวลานานกว่าจะทำใหม่ได้ ความจริงที่ว่าเรากำลัง พึ่ง LLM มากกว่าเสิร์ชเอนจิน นั้นก็น่ากลัวเหมือนกันฉันคาดไว้แล้วตั้งแต่ 10 วันก่อน (ลิงก์)
โมเดลที่ ไม่สม่ำเสมอ อันตรายยิ่งกว่าโมเดลแย่ ๆ เพราะความน่าเชื่อถือลดลงจนต้องตรวจทุกเอาต์พุต เหนื่อยมาก สุดท้ายคงยกเลิกสมาชิก
การลดประสิทธิภาพแบบเงียบ ๆ แบบนี้น่าตกใจมาก ขายโมเดลคุณภาพสูงแล้วค่อย ๆ ทำให้อ่อนลงแบบลับ ๆ ถือว่าเป็นการหลอกลูกค้า
ตัว wrapper ที่ซับซ้อนของเครื่องมือเขียนโค้ดอาจยิ่งทำให้ประสิทธิภาพตก และ โครงสร้างประหยัดโทเค็นอาจส่งผลเสียต่อผู้ใช้
แต่ถ้าสูญเสียความเชื่อมั่นไป กลยุทธ์ premium tier ในอนาคตก็จะทำได้ยาก
ฉันลองทำ สคริปต์ตรวจสอบ ด้วย jq และ ripgrep เพื่อหาข้อความ “early landing” (ลิงก์1, ลิงก์2)
ประโยคอย่าง “วันนี้พอแค่นี้”, “ดึกแล้วปิดงานกันเถอะ” เพิ่มขึ้นเรื่อย ๆ อาจเป็นเพราะ load shedding
ฉันก็มีประสบการณ์คล้ายกัน Claude CLI พูดว่า “คุณควรไปนอนได้แล้วไหม”, “มาปิดงานกันเถอะ”
ใน stop-phrase-guard.sh พบวลีแบบนี้อยู่หลายจุด
พอบอกเดดไลน์ไป มันกลับตอบว่า “ยังเหลืออีกหลายวัน งั้นเลื่อนไปก่อน” สุดท้ายฉันเลยพิมพ์ว่า “เดดไลน์เป็นเรื่องของฉัน ไม่ใช่เรื่องของนาย”
ตอนที่ลองแพ็กเกจ max ช่วงปลายมกราคมถึงต้นกุมภาพันธ์ เอเจนต์เก่งถึงขั้นออกแบบและสร้างแอปได้เอง
แต่พอหนึ่งเดือนผ่านไป มันกลับบอกว่า “จะไปขั้น 2 ไม่ได้จนกว่าจะตรวจขั้น 1” แล้ว ความคืบหน้าก็หยุดสนิท
หลัง Opus 4.6 รู้สึกชัดเลยว่ามัน เสื่อมลงจนเหมือนระดับ Sonnet
ฉันแทบไม่เจอปัญหาแบบนี้ เพราะสั่งงานแบบ แยกย่อยมาก
แบ่งแต่ละงานเป็นระดับ commit และทำระบบอัตโนมัติไปจนถึงการดีพลอย ทำให้ย้อนกลับได้ง่าย