Preflight Checklist
- Báo cáo này không chứa thông tin nhạy cảm (key API, mật khẩu, v.v.)
Loại Vấn Đề Hành Vi
Hành vi không mong đợi khác
Yêu Cầu Claude Thực Hiện
Claude đã bị suy giảm đến mức không thể tin tưởng để thực hiện các tác vụ kỹ thuật phức tạp.
Thực Tế Claude Đã Thực Hiện
- Bỏ qua hướng dẫn
- Thực hiện “sửa đơn giản” nhưng sai
- Làm ngược lại
- Khẳng định hoàn tất ngược lại với hướng dẫn
Hành Vi Mong Đợi
Claude nên hoạt động như thời điểm tháng một.
Có Tái Hiện Được Không?
Có, mỗi lần với cùng một prompt
Mô Hình Claude
Opus
Tác Động
Cao - Thay đổi không mong muốn đáng kể
Phiên Bản Claude Code
Nhiều loại/tất cả
Nền Tảng
Anthropic API
Bối Cảnh Bổ Sung
Chúng tôi có một môi trường làm việc cực kỳ phức tạp, đã khai thác dữ liệu từ nhiều tháng log để hiểu tại sao – về cơ bản – từ tháng Hai, chúng tôi nhận thấy sự suy giảm khi thực hiện các tác vụ kỹ thuật phức tạp. Phân tích dựa trên log và đã thử mọi giải pháp công khai. Claude đã rất tốt với chúng tôi, và chúng tôi hy vọng rằng Anthropic có thể giải quyết những lo ngại này.
Tư Duy Mở Rộng Là Quan Trọng Đối Với Luồng Công Việc Kỹ Thuật Cao Cấp
Phân tích này được Claude thực hiện bằng cách phân tích dữ liệu log phiên từ tháng Một đến tháng Ba.
Tóm tắt
Phân tích định lượng 17,871 khối tư duy và 234,760 lần gọi công cụ trong 6,852 file phiên Claude Code tiết lộ rằng việc lược bớt nội dung suy nghĩ (redact-thinking) trùng khớp với sự suy giảm chất lượng trong các luồng công việc kỹ thuật dài và phức tạp.
Dữ liệu cho thấy các token suy nghĩ mở rộng không chỉ là “cần có” mà còn cần thiết để mô hình thực hiện nghiên cứu nhiều bước, tuân thủ quy ước và chỉnh sửa mã cẩn thận.
1. Dòng Thời Gian Lược Bớt Suy Nghĩ Khớp Với Suy Giảm Chất Lượng
Sự phân tích các khối suy nghĩ trong các file JSONL phiên:
| Thời Kỳ | Suy Nghĩ Hiển Thị | Suy Nghĩ Bị Lược |
|---|---|---|
| 30 Tháng 1 - 4 Tháng 3 | 100% | 0% |
| 5 Tháng 3 | 98.5% | 1.5% |
| 7 Tháng 3 | 75.3% | 24.7% |
| 8 Tháng 3 | 41.6% | 58.4% |
| 10-11 Tháng 3 | <1% | >99% |
| 12 Tháng 3+ | 0% | 100% |
Ngày 8 tháng 3, suy nghĩ bị lược bớt vượt quá 50% và sự suy giảm chất lượng được báo cáo độc lập đúng ngày hôm đó. Mô hình này nhất quán với một triển khai giai đoạn.
2. Độ Sâu Suy Nghĩ Đã Giảm Trước Khi Lược Bớt
Trường signature trên các khối suy nghĩ có 0.971 Pearson correlation với độ dài nội dung suy nghĩ, cho phép ước tính độ sâu suy nghĩ ngay cả sau khi bị lược bớt.
| Thời Kỳ | Est. Median Suy Nghĩ (ký tự) | so với Cơ Sở |
|---|---|---|
| 30 Tháng 1 - 8 Tháng 2 (cơ sở) | ~2,200 | — |
| Cuối Tháng 2 | ~720 | -67% |
| 1-5 Tháng 3 | ~560 | -75% |
| 12 Tháng 3+ (bị lược hoàn toàn) | ~600 | -73% |
3. Ảnh Hưởng Hành Vi: Các Chỉ Số Chất Lượng Đo Lường
Các chỉ số này được tính toán độc lập từ hơn 18,000 prompt của người dùng trước khi phân tích suy nghĩ được thực hiện.
| Chỉ Số | Trước 8 Tháng 3 | Sau 8 Tháng 3 | Thay đổi |
|---|---|---|---|
| Vi phạm stop hook | 0 | 173 | 0 → 10/ngày |
| Chỉ báo thất vọng trong các prompt | 5.8% | 9.8% | +68% |
| Điều chỉnh né tránh cần thiết | 6 | 13 | +117% |
| Prompt mỗi phiên | 35.9 | 27.9 | -22% |
| Phiên với vòng lặp lý luận (5+) | 0 | 7 | 0 → 7 |
4. Sự Dịch Chuyển Công Cụ: Từ Nghiên Cứu Đến Chỉnh Sửa
Phân tích 234,760 công cụ gọi ra cho thấy mô hình ngừng đọc mã trước khi sửa đổi.
Tỷ Lệ Đọc:Chỉnh Sửa
| Thời Kỳ | Đọc:Chỉnh Sửa | Nghiên Cứu: Đột biến | Đọc % | Chỉnh Sửa % |
|---|---|---|---|---|
| Tốt (30 Tháng 1 - 12 Tháng 2) | 6.6 | 8.7 | 46.5% | 7.1% |
| Chuyển Tiếp (13 Tháng 2 - 7 Tháng 3) | 2.8 | 4.1 | 37.7% | 13.2% |
| Suy Giảm (8 Tháng 3 - 23 Tháng 3) | 2.0 | 2.8 | 31.0% | 15.4% |
Trong giai đoạn tốt, quy trình của mô hình là: đọc tập tin mục tiêu, đọc tập tin liên quan, grep cho các sử dụng trong toàn bộ mã, đọc header và test, sau đó thực hiện chỉnh sửa chính xác. Giai đoạn suy giảm, nó đọc ngay lập tức tập tin và chỉnh sửa, thường không kiểm tra ngữ cảnh.
Xu Hướng Hàng Tuần
Tuần Đọc:Chỉnh Sửa Nghiên Cứu:Đột Biến
──────────────────────────────────────────
26 Tháng 1 21.8 30.0
2 Tháng 2 6.3 8.1
9 Tháng 2 5.2 7.1
16 Tháng 2 2.8 4.1
23 Tháng 2 3.2 4.5
2 Tháng 3 2.5 3.7
9 Tháng 3 2.2 3.3
16 Tháng 3 1.7 2.1 ← thấp nhất
23 Tháng 3 2.0 3.0
30 Tháng 3 1.6 2.6
Sự suy giảm nỗ lực nghiên cứu bắt đầu vào giữa tháng Hai — cùng thời kỳ khi độ sâu suy nghĩ ước tính giảm 67%.
Viết so với Chỉnh Sửa (độ chính xác phẫu thuật)
| Thời Kỳ | Tỷ lệ Viết % |
|---|---|
| Tốt (30 Tháng 1 - 12 Tháng 2) | 4.9% |
| Suy Giảm (8 Tháng 3 - 23 Tháng 3) | 10.0% |
| Muộn (24 Tháng 3 - 1 Tháng 4) | 11.1% |
Sử dụng Viết toàn bộ tập tin đã tăng gấp đôi — mô hình ngày càng chọn viết lại toàn bộ các tập tin thay vì thực hiện chỉnh sửa phẫu thuật, nhanh hơn nhưng mất đi độ chính xác và nhận thức về ngữ cảnh.
5. Tại Sao Tư Duy Mở Rộng Quan Trọng Cho Những Luồng Làm Việc Này
Các luồng công việc bị ảnh hưởng bao gồm:
- 50+ phiên đại lý đồng thời thực hiện lập trình hệ thống (C, MLIR, GPU drivers)
- Chạy tự động trong 30+ phút với các thay đổi nhiều tập tin phức tạp
- Các quy ước riêng của dự án (5,000+ từ trong CLAUDE.md)
- Xem xét code, quản lý vé/ticket, và gỡ lỗi liên tục
- 191,000 dòng mã được hợp nhất trong hai PR vào cuối tuần trong giai đoạn tốt
Tư duy mở rộng là cơ chế giúp mô hình:
- Lên kế hoạch giải pháp nhiều bước trước khi hành động (tập tin nào cần đọc, thứ tự nào)
- Nhớ và áp dụng các quy ước riêng của dự án từ CLAUDE.md
- Phát hiện lỗi trước khi xuất kết quả
- Đưa ra quyết định tiếp tục làm việc hay dừng lại (quản lý phiên)
- Duy trì suy luận mạch lạc qua hàng trăm lượt gọi công cụ
Khi suy nghĩ nông cạn, mô hình mặc định chọn hành động rẻ nhất có sẵn: chỉnh sửa mà không đọc, dừng mà không hoàn thành, trốn tránh trách nhiệm cho sai lầm, chọn sửa đơn giản nhất thay vì sửa đúng. Đây chính là các triệu chứng mà người dùng đã ghi nhận.
6. Những Gì Sẽ Giúp Đỡ
- Minh bạch về phân bổ tư duy: Nếu các token suy nghĩ đang bị giảm hoặc giới hạn, người dùng phụ thuộc vào suy luận sâu cần phải biết. Header
redact-thinkingkhiến cho việc xác thực bên ngoài trở nên không thể. - Một gói “tối đa suy nghĩ”: Người dùng chạy luồng công việc kỹ thuật phức tạp sẵn lòng trả nhiều hơn để đảm bảo suy nghĩ sâu sắc. Mô hình đăng ký hiện tại không phân biệt giữa người dùng cần 200 token suy nghĩ mỗi phản hồi và người dùng cần 20,000.
- Số liệu về token suy nghĩ trong phản hồi API: Ngay cả khi nội dung suy nghĩ bị lược bớt, việc công khai
thinking_tokenstrong phản hồi sử dụng cho phép người dùng theo dõi liệu yêu cầu của họ có đạt được độ sâu suy luận cần thiết hay không. - Cảnh báo từ các người dùng mạnh: Tỷ lệ vi phạm stop hook (0 → 10/ngày) là tín hiệu mà máy có thể đọc được có thể được theo dõi trên toàn bộ người dùng để làm chỉ báo sớm cho suy giảm chất lượng.
Phương Pháp
- Nguồn dữ liệu: 6,852 file JSONL phiên Claude Code từ
~/.claude/projects/trên bốn dự án (iree-loom, iree-amdgpu, iree-remoting, bureau) - Khối suy nghĩ phân tích: 17,871 (7,146 có nội dung, 10,725 bị lược bớt)
- Tương quan chữ ký-suy nghĩ: 0.971 Pearson (r) trên 7,146 mẫu ghép đôi
- Các lượt gọi công cụ phân tích: 234,760 trên tất cả các phiên
- Chỉ số hành vi: 18,000+ prompt của người dùng, chỉ báo thất vọng, tần suất chính sửa, thời gian phiên
- Xác minh proxy: Proxy SSE dòng xác nhận có không có sự kiện
thinking_deltatrong phản hồi API hiện tại - Phạm vi ngày: 30 Tháng 1 – 1 Tháng 4, 2026
Phụ Lục A: Danh Mục Hành Vi — Như Thế Nào Là Suy Giảm Tư Duy
Các mẫu hành vi sau được đo lường qua 234,760 công cụ gọi ra và hơn 18,000 prompt của người dùng. Mỗi mẫu là kết quả dự đoán được của giảm độ sâu suy nghĩ: mô hình sử dụng lối tắt vì không có ngân sách tư duy để đánh giá các lựa chọn thay thế, kiểm tra ngữ cảnh hoặc lập kế hoạch trước.
A.1 Chỉnh Sửa Mà Không Đọc
Khi mô hình có đủ ngân sách tư duy, nó đọc các file liên quan, grep các lần sử dụng, kiểm tra header, và đọc test trước khi chỉnh sửa. Khi suy nghĩ nông cạn, nó bỏ qua nghiên cứu và chỉnh sửa trực tiếp.
| Thời Kỳ | Chỉnh Sửa mà Không Đọc Trước | % của tất cả chỉnh sửa |
|---|---|---|
| Tốt (30 Tháng 1 - 12 Tháng 2) | 72 | 6.2% |
| Chuyển Tiếp (13 Tháng 2 - 7 Tháng 3) | 3,476 | 24.2% |
| Suy Giảm (8 Tháng 3 - 23 Tháng 3) | 5,028 | 33.7% |
Một trong ba chỉnh sửa trong giai đoạn suy giảm được thực hiện trên một file mô hình chưa đọc trong lịch sử công cụ gần đây. Hậu quả thực tế: những chỉnh sửa phá vỡ mã xung quanh, vi phạm quy ước cấp độ file, chèn mã mới vào giữa các khối nhận xét hiện có, hoặc sao chép logic đã có ở nơi khác trong file.
Nhận xét chèn là triệu chứng rõ rệt. Khi mô hình chỉnh sửa một tập tin mà nó chưa đọc, nó không biết nơi các khối nhận xét kết thúc và mã bắt đầu. Nó chèn khai báo mới giữa một nhận xét tài liệu và hàm mà nó tài liệu, phá vỡ mối liên kết ngữ nghĩa. Điều này chưa bao giờ xảy ra trong giai đoạn tốt vì mô hình luôn đọc file trước.
A.2 Vòng Lặp Lý Luận
Khi suy nghĩ sâu, mô hình giải quyết mâu thuẫn nội bộ trước khi sản xuất đầu ra. Khi suy nghĩ nông cạn, mâu thuẫn nổi lên trong đầu ra như các chỉnh sửa tự nhìn thấy: “oh wait”, “actually,”, “let me reconsider”, “hmm, actually”, “no wait.”
| Thời Kỳ | Vòng Lặp Lý Luận mỗi 1K công cụ gọi ra |
|---|---|
| Tốt | 8.2 |
| Chuyển Tiếp | 15.9 |
| Suy Giảm | 21.0 |
| Muộn | 26.6 |
Tỷ lệ này đã tăng hơn ba lần. Trong những phiên tệ nhất, mô hình sản xuất hơn 20+ các điều chỉnh lý luận trong một phản hồi — tạo ra một kế hoạch, mâu thuẫn nó, coi xét lại, mâu thuẫn với sửa đổi và cuối cùng sản xuất đầu ra không thể tin tưởng vì đường dẫn lý luận hiển thị không đồng nhất.
A.3 Tư Duy “Sửa Đơn Giản Nhất”
Từ “đơn giản nhất” trong đầu ra của mô hình là một tín hiệu cho thấy nó đang tối ưu hóa để tiết kiệm công sức hơn là đánh giá cách tiếp cận đúng. Với suy nghĩ sâu, mô hình đánh giá nhiều cách tiếp cận và chọn cái đúng. Với suy nghĩ nông cạn, nó hướng tới bất cứ thứ gì yêu cầu ít lý luận nhất để biện minh.
| Thời Kỳ | ”simplest” mỗi 1K công cụ gọi ra |
|---|---|
| Tốt | 2.7 |
| Suy Giảm | 4.7 |
| Muộn | 6.3 |
Trong một cửa sổ 2 giờ quan sát, mô hình sử dụng “simplest” 6 lần trong khi sản xuất code mà các tự chính sửa của nó mô tả là “lười và sai”, “vội vàng”, và “ẩu tả.” Mỗi lần, mô hình đã chọn một cách tiếp cận tránh một vấn đề khó hơn (sửa code generator, thực hiện xử lý lỗi đúng cách, viết logic prefault thực) thay vì cách giải quyết bề mặt.
A.4 Dừng Làm Và Tìm Kiếm Sự Cho Phép Sớm
Một mô hình với suy nghĩ sâu có thể đánh giá nhiệm vụ đã hoàn thành và tự quyết định tiếp tục. Với suy nghĩ nông cạn, mô hình mặc định dừng và hỏi xin phép — hành động ít tốn công nhất có sẵn.
Một hook stop programmatic đã được xây dựng để bắt các câu này và buộc tiếp tục. Danh mục vi phạm bị bắt:
| Danh Mục | Đếm (8-25 Tháng 3) | Ví dụ |
|---|---|---|
| Né tránh trách nhiệm | 73 | ”not caused by my changes”, “existing issue” |
| Tìm kiếm sự cho phép | 40 | ”should I continue?”, “want me to keep going?” |
| Dừng sớm | 18 | ”good stopping point”, “natural checkpoint” |
| Gán nhãn giới hạn đã biết | 14 | ”known limitation”, “future work” |
| Lý do chiều dài phiên | 4 | ”continue in a new session”, “getting long” |
| Tổng số | 173 | |
| Tổng số trước 8 Tháng 3 | 0 |
Sự tồn tại của hook này là bằng chứng của sự thoái hóa. Không cần thiết trong giai đoạn tốt vì mô hình không bao giờ biểu hiện các hành vi này. Mỗi câu trong hook được thêm vào để phản ứng với một sự cố cụ thể nơi mô hình cố gắng dừng việc quá sớm.
A.5 Ngắt Người Dùng (Sửa)
Ngắt người dùng (Escape key / [Request interrupted by user]) chỉ ra rằng người dùng đã thấy mô hình làm sai và đã dừng nó. Tỷ lệ ngắt cao hơn đồng nghĩa với việc cần nhiều sửa chữa hơn.
| Thời Kỳ | Ngắt người dùng mỗi 1K công cụ gọi ra |
|---|---|
| Tốt | 0.9 |
| Chuyển Tiếp | 1.9 |
| Suy Giảm | 5.9 |
| Muộn | 11.4 |
Tỷ lệ ngắt tăng 12 lần từ giai đoạn tốt đến giai đoạn muộn. Mỗi lần ngắt đại diện cho một khoảnh khắc mà người dùng phải dừng công việc của họ, đọc đầu ra của mô hình, xác định lỗi, công thức một chỉnh sửa, và định hướng lại mô hình — chính xác là loại giám sát mà các đại lý tự quản lý cần phải loại bỏ.
A.6 Thú Nhận Lỗi Chất Lượng Tự Mình
Trong giai đoạn suy giảm, mô hình thường xuyên thừa nhận chất lượng đầu ra kém của nó sau khi bị chỉnh sửa. Những lời nhận này không được yêu cầu — mô hình nhận ra nó đã cắt giảm sau khi người dùng chỉ ra:
- “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. The CPU slab provider’s prefault is real work.”
| Thời Kỳ | Lỗi tự thú nhận mỗi 1K công cụ gọi ra |
|---|---|
| Tốt | 0.1 |
| Suy Giảm | 0.3 |
| Muộn | 0.5 |
Những trường hợp này nơi mô hình tự nhận thấy đầu ra của nó là dưới tiêu chuẩn — nhưng chỉ sau khi chỉnh sửa bên ngoài. Với độ sâu suy nghĩ đủ, những lỗi này sẽ được phát hiện nội bộ trong quá trình suy luận, trước khi sản xuất đầu ra. Mô hình biết hình dáng của công việc tốt; nó chỉ đơn giản không có ngân sách để kiểm tra.
A.7 Chỉnh Sửa Lặp Lại Tệp Tin
Khi mô hình chỉnh sửa cùng một file 3+ lần nhanh chóng, nó chỉ ra hành vi thử và sai thay vì thay đổi có kế hoạch — thay đổi, thấy nó thất bại, thử lại, thất bại khác.
Mẫu này tồn tại trong tất cả các giai đoạn (đôi khi hợp lệ trong khi tinh chỉnh lặp đi lặp lại), nhưng sự khác biệt quan trọng là ngữ cảnh: trong giai đoạn tốt, chỉnh sửa lặp lại là một phần của quá trình tái cấu trúc nhiều bước có chủ ý với các lượt đọc giữa các chỉnh sửa. Trong giai đoạn suy giảm, nó là mô hình đang mắc kẹt trên cùng một chức năng mà không đọc mã xung quanh.
A.8 Sự Trôi Nổi Quy Ước
Các dự án sử dụng các quy ước mã hóa mở rộng trong CLAUDE.md (5,000+ từ bao trùm về cách đặt tên, mẫu dọn dẹp, bố trí cấu trúc, kiểu nhận xét, xử lý lỗi). Trong giai đoạn tốt, mô hình tuân thủ chúng đáng tin cậy — đọc CLAUDE.md là một phần của khởi tạo phiên, và suy nghĩ sâu cho phép mô hình nhớ và áp dụng quy ước cho mỗi chỉnh sửa.
Sau khi suy nghĩ bị giảm, sự tuân thủ quy ước suy giảm đo lường được:
- Tên biến viết tắt (
buf,len,cnt) xuất hiện lại mặc dù có quy tắc rõ ràng chống lại chúng - Mẫu dọn dẹp (if-chain thay vì goto) bị vi phạm
- Nhận xét về mã đã loại bỏ đã bị để lại chỗ
- Tham chiếu thời gian (“Phase 2”, “will be completed later”) xuất hiện trong mã mặc dù bị cấm rõ ràng
Những vi phạm này không phải là mô hình không biết về các quy ước — các quy ước nằm trong cửa sổ ngữ cảnh của nó. Chúng là mô hình không có ngân sách suy nghĩ để kiểm tra mỗi chỉnh sửa theo quy ước trước khi sản xuất nó. Với 2,200 ký tự tư duy, có đủ chỗ để nhớ “kiểm tra cách đặt tên, kiểm tra mẫu dọn dẹp, kiểm tra kiểu nhận xét.” Với 500 ký tự, thì không.
Phụ Lục B: Hook Stop Như một Công Cụ Chẩn Đoán
Hook stop-phrase-guard.sh (bao gồm trong lưu trữ dữ liệu) khớp với hơn 30+ cụm từ qua 5 danh mục hành vi không mong muốn. Khi kích hoạt, nó chặn mô hình dừng và chèn một thông báo điều chỉnh buộc tiếp tục.
Log vi phạm hook cung cấp một tín hiệu chất lượng mà máy có thể đọc:
Vi phạm theo ngày (chỉ dự án IREE):
8 Tháng 3: 8 ████████
14 Tháng 3: 10 ██████████
15 Tháng 3: 8 ████████
16 Tháng 3: 2 ██
17 Tháng 3: 14 ██████████████
18 Tháng 3: 43 ███████████████████████████████████████████████
19 Tháng 3: 10 ██████████
21 Tháng 3: 28 ████████████████████████████████
22 Tháng 3: 10 ██████████
23 Tháng 3: 14 ██████████████
24 Tháng 3: 25 █████████████████████████████
25 Tháng 3: 4 ████
Trước 8 Tháng 3: 0 (không vi phạm trong toàn bộ lịch sử)
Hook tồn tại vì mô hình bắt đầu thể hiện các hành vi chưa từng quan sát trong giai đoạn tốt. Mỗi cụm từ trong hook được thêm sau khi phản ứng với một sự cố cụ thể. Hook là một giải pháp tạm thời cho giảm độ sâu suy nghĩ — nó bắt hậu quả bên ngoài vì mô hình không còn bắt nó nội bộ.
Ngày đạt đỉnh là 18 Tháng 3 với 43 vi phạm — khoảng một vi phạm mỗi 20 phút trên các phiên hoạt động. Vào ngày đó, mô hình cố gắng dừng làm việc, né trách nhiệm, hoặc hỏi xin phép không cần thiết 43 lần và bị buộc tiếp tục mỗi lần.
Số liệu này có thể phục vụ như một tín hiệu cảnh báo cho chất lượng mô hình nếu được theo dõi trên toàn bộ người dùng. Sự gia tăng đột ngột trong các chỉnh sửa loại stop-hook (hoặc các câu gõ tay của người dùng như “no, keep going”, “you’re not done”, “that’s your change, fix it”) sẽ cung cấp cảnh báo sớm về thoái hóa độ sâu suy nghĩ trước khi người dùng gửi báo lỗi.
Phụ Lục C: Phân Tích Thời Gian Trong Ngày
Các báo cáo cộng đồng cho thấy chất lượng thay đổi theo thời gian trong ngày, với các giờ làm việc tại Hoa Kỳ là tệ nhất. Phân tích độ dài chữ ký theo giờ trong ngày (PST) của tất cả các phiên kiểm tra giả thuyết này.
Trước Khi Bị Lược Bớt: Biến Đổi Thời Gian Trong Ngày Tối Thiểu
Trước khi suy nghĩ bị lược bớt (30 Tháng 1 - 7 Tháng 3), độ sâu suy nghĩ tương đối ổn định trong cả ngày:
| Cửa Sổ (PST) | N | Median Sig | ~Suy Nghĩ |
|---|---|---|---|
| Giờ làm việc (9 giờ sáng - 5 giờ chiều) | 2,972 | 1,464 | 553 |
| Ngoài giờ cao điểm (6 giờ tối - 5 giờ sáng) | 2,900 | 1,608 | 607 |
| Khác biệt | +9.8% ngoài giờ cao điểm |
Lợi thế 10% khiêm tốn cho ngoài giờ cao điểm, phù hợp với tải thấp hơn nhẹ.
Sau Khi Bị Lược Bớt: Độ Biến Động Cao Hơn, Mẫu Không Dự Đoán Được
Sau khi bị lược bớt (8 Tháng 3 - 1 Tháng 4), mẫu thời gian trong ngày đảo ngược và trở nên nhiều tiếng ồn hơn:
| Cửa Sổ (PST) | N | Median Sig | ~Suy Nghĩ |
|---|---|---|---|
| Giờ làm việc (9 giờ sáng - 5 giờ chiều) | 5,492 | 1,560 | 589 |
| Ngoài giờ cao điểm (6 giờ tối - 5 giờ sáng) | 5,282 | 1,284 | 485 |
| Khác biệt | -17.7% ngoài giờ cao điểm |
Ngược lại với giả thuyết, suy nghĩ ngoài giờ cao điểm thấp hơn tổng thể. Nhưng chi tiết theo giờ tiết lộ sự biến đổi đáng kể:
Giờ (PST) MedSig ~Think N Chú thích
─────────────────────────────────────────────────────
12am 1948 736 278
1am 8680 3281 13 ← 4x cơ sở (rất ít mẫu)
6am 4508 1704 50 ← gần cơ sở
7am 1168 441 344
8am 1712 647 586
9am 1584 598 678 giờ làm việc bắt
10am 1424 538 654
11am 1292 488 454 ← thấp nhất giờ làm việc
12pm 1736 656 533
1pm 2184 825 559 ← cao nhất giờ làm việc
2pm 1528 577 476
3pm 1592 601 686
4pm 1784 674 788
5pm 1120 423 664 ← thấp nhất tổng thể (kết thúc ngày làm việc Hoa Kỳ)
6pm 1276 482 615
7pm 988 373 1031 ← thấp nhất thứ hai (giờ cao điểm Hoa Kỳ)
8pm 1240 468 1013
9pm 1088 411 1199
10pm 2008 759 601 ← hồi phục buổi tối
11pm 2616 988 532 ← giờ tốt nhất định kỳ
Quan Sát Chính
5 giờ chiều PST là giờ tệ nhất. Median suy nghĩ ước tính giảm xuống 423 ký tự — thấp nhất của bất kỳ giờ nào có số mẫu đáng kể. Đây là cuối ngày làm việc cho bờ tây Hoa Kỳ và giữa buổi tối cho bờ đông, có khả năng là cửa sổ tải đỉnh.
7 giờ tối PST là thứ hai tệ nhất. 373 ký tự suy nghĩ ước tính với số mẫu cao nhất của bất kỳ giờ nào (1,031 khối). Giờ cao điểm của Hoa Kỳ.
Đêm muộn (10 giờ tối-1 giờ sáng PST) cho thấy hồi phục. Trung bình tăng lên 759-3,281 ký tự. Thời kỳ này là sau khi bờ đông Hoa Kỳ đi ngủ và khi tải trên nền tảng tổng thể có lẽ là thấp nhất.
Trước khi bị lược bớt có hồ sơ phẳng; sau khi bị lược bớt có đỉnh và đáy. Phạm vi trung bình chữ ký qua giờ là 1,020-2,648 trước khi bị lược bớt (tỷ lệ 2.6x). Sau khi bị lược bớt nó là 988-8,680 (tỷ lệ 8.8x). Độ sâu suy nghĩ đã trở nên biến động hơn nhiều, phù hợp với hệ thống phân phối tải nhạy hơn là ngân sách cố định.
Giải Thích
Dữ liệu không hỗ trợ rõ ràng “làm việc ngoài giờ cao điểm để có chất lượng tốt hơn.” Thay vào đó nó cho thấy rằng sự phân bổ suy nghĩ là nhạy với tải và biến động trong chế độ sau khi bị lược bớt. Một số giờ ngoài giờ cao điểm (đêm muộn) thì tốt hơn; các giờ khác (buổi tối sớm) lại tệ hơn giờ làm việc. Các thung lũng 5 giờ chiều và 7 giờ chiều PST trùng với giờ sử dụng internet đỉnh điểm ở Hoa Kỳ, không phải đỉnh sử dụng công việc, gợi ý rằng ràng buộc có thể là cấp độ hạ tầng (khả dụng GPU) hơn là cấp độ chính sách (kiểm soát theo người dùng).
Hồ sơ phẳng trước khi bị lược bớt là phát hiện quan trọng hơn: khi suy nghĩ được phân bổ hào phóng, thời gian trong ngày không quan trọng. Thực tế là bây giờ nó quan trọng là bản thân bằng chứng cho thấy suy nghĩ đang được phân phối thay vì cung cấp ở một mức cố định.
Phụ Lục D: Giá Trị Của Sự Suy Giảm
Giảm token suy nghĩ dường như tiết kiệm tính toán mỗi yêu cầu. Nhưng khi suy nghĩ giảm gây ra sự sụp đổ chất lượng, mô hình trở nên rối loạn — sản xuất đầu ra sai, bị ngắt, thử lại và tiêu tốn token cho các chỉnh sửa mà sẽ không cần nếu nó đã nghĩ đúng lần đầu. Hiệu ứng tổng thể là tính toán toàn bộ tiêu thụ tăng lên hàng bậc cỡ.
Sử Dụng Token: Tháng Một đến Tháng Ba 2026
Tất cả việc sử dụng qua tất cả các dự án Claude Code. Định giá Bedrock Opus ước tính để so sánh (đầu vào $15/MTok, đầu ra $75/MTok, đọc cache $1.50/MTok, viết cache $18.75/MTok).
| Chỉ Số | Tháng Một | Tháng Hai | Tháng Ba | Thay đổi Tháng 2→Tháng 3 |
|---|---|---|---|---|
| Ngày hoạt động | 31 | 28 | 28 | |
| Prompt của người dùng | 7,373 | 5,608 | 5,701 | ~1x |
| Yêu cầu API (không trùng lặp) | 97* | 1,498 | 119,341 | 80x |
| Tổng số đầu vào (gồm cache) | 4.6M* | 120.4M | 20,508.8M | 170x |
| Tổng số token đầu ra | 0.08M* | 0.97M | 62.60M | 64x |
| Giá thành Bedrock ước tính (với cache) | $26* | $345 | $42,121 | 122x |
| Giá thành hàng ngày ước tính (với cache) | — | $12 | $1,504 | 122x |
| Giá thuê bao thực tế | $200 | $400 | $400 | — |
- Dữ liệu API tháng một chưa đầy đủ — log phiên chỉ bao trùm từ 9-31 Tháng 1 (8 ngày đầu tiên thiếu). Tháng Một có 31 ngày hoạt động và 7,373 prompt, vì vậy thực sự sử dụng API cao hơn đáng kể so với thể hiện.
Ngữ Cảnh: Tại Sao Tháng Ba Lại Cao Như Vậy
Sự tăng 80 lần trong yêu cầu API không chỉ từ rối loạn do thoái hóa gây ra. Nó cũng phản ánh việc mở rộng hoạt động làm việc của các phiên đại lý đồng thời đã xung đột với sự suy giảm chất lượng ở thời điểm xấu nhất.
Tháng Hai: 1-3 phiên đồng thời thực hiện công việc tập trung vào hai hệ thống con IREE. 1,498 yêu cầu API đã tạo ra 191,000 dòng mã được hợp nhất. Quy trình làm việc đã được chứng minh và hiệu quả.
Đầu Tháng Ba (trước suy giảm): Khích lệ bởi thành công tháng hai, người dùng đã mở rộng quy mô lên 5-10+ phiên đồng thời qua 10 dự án (IREE loom, amdgpu, remoting, batteries, web, fuzzing, và hệ thống đa đại lý của Bureau). Đây là quy trình công việc dự kiến — hàng chục đại lý hợp tác trên một cơ sở mã lớn, mỗi cái chạy tự động trong hơn 30 phút.
Yêu cầu API tháng ba theo dự án (không trùng lặp):
| Dự Án | Chính | Đại Lý Phụ | Tổng Số |
|---|---|---|---|
| Bureau | 20,050 | 9,856 | 29,906 |
| IREE loom | 19,769 | 6,781 | 26,550 |
| IREE amdgpu | 17,697 | 4,994 | 22,691 |
| IREE remoting | 12,320 | 2,862 | 15,182 |
| IREE batteries | 10,061 | 3,951 | 14,012 |
| IREE web | 5,775 | 2,309 | 8,084 |
| Khác | 2,474 | 539 | 2,916 |
| Tổng Số | 88,049 | 31,292 | 119,341 |
26% của tất cả yêu cầu là cuộc gọi đại lý phụ — các đại lý sinh ra các đại lý khác để thực hiện nghiên cứu, xem xét mã, và thăm dò song song. Đây là mẫu đa đại lý hoạt động như thiết kế, nhưng tiêu thụ yêu cầu API ở quy mô.
Sự va chạm thảm khốc: Sự suy giảm chất lượng đã xảy ra trong khi mở rộng hoạt động. Người dùng đã chuyển từ “Tôi có thể chạy 50 đại lý và tất cả họ sản xuất công việc xuất sắc” đến “mỗi người trong số những đại lý này bây giờ đều là ngốc nghếch.” Chế độ thất bại không phải là một phiên duy nhất bị hỏng — đó là trên 10+ phiên đồng thời tất cả suy giảm cùng lúc, mỗi cái yêu cầu can thiệp của con người mà quy trình làm việc đa đại lý đã được thiết kế để loại bỏ.
Ngày đạt đỉnh: 7 Tháng 3 với 11,721 yêu cầu API — ngày trước suy giảm vượt 50% lược bớt suy nghĩ. Đây là ngày cuối cùng của nỗ lực hoạt động toàn thời gian. Sau ngày 8 Tháng 3, số lượng phiên giảm vì người dùng đã bỏ quy trình làm việc đồng thời hoàn toàn.
Giá thành tháng ba là sự kết hợp của:
- Mở rộng hoạt động hợp pháp: nhiều dự án hơn, nhiều đại lý đồng thời hơn (~5-10x)
- Lãng phí suy giảm: rối loạn, thử lại, chỉnh sửa (~10-15x)
- Mất mát thảm khốc: quy trình làm việc đa đại lý đang giao 191K dòng cuối tuần đã trở nên hoàn toàn không khả thi, buộc phải rút lại hoạt động phiên giám sát đơn thân.