DeepSeek trong Codex: 9/9 test xanh vẫn có thể sửa sai file
Một bài kiểm tra nhỏ: chín test hành vi, một phép kiểm tra đúng file đích, và hai kết quả rất khác nhau.
Khi terminal hiện 9 passed, phản xạ thông thường là đóng phiên làm việc. Nhưng trước khi nhận bàn giao, còn một câu hỏi cần trả lời: code đã sửa có thật sự nằm trong inventory_service.py mà chúng ta yêu cầu hay không, và bộ test có thật sự import file đó hay không?
Với một công cụ trả về từng đoạn code, câu hỏi này có vẻ không cần thiết. Nhưng Codex là một coding agent: nó có thể đọc repository, chạy test, nhận traceback, sửa file rồi chạy lại. Chính vòng lặp đó khiến công việc nhanh hơn, đồng thời tạo ra một điểm mù mới.
Test xanh chứng minh một hành vi đã đúng trên một implementation nào đó. Nó không tự chứng minh implementation ấy nằm ở đúng file, đúng thư mục, hay là file mà tiến trình Python vừa nạp.
Trong lần chạy với deepseek-v4.1-flash, Codex hoàn tất sau 3 phút 59 giây. Chín test hành vi đều đạt, file đích thay đổi, và một phép kiểm tra bổ sung xác nhận đúng file. Kết quả được ghi là 10/10. Một lần chạy khác bằng harness DSH cũng báo 9/9, nhưng file đích không đổi. DSH đã tạo một package Python trùng tên ở vị trí khác, rồi bộ test import implementation từ package mới đó.
Cùng một con số 9/9, nhưng một bên là bản sửa đúng chỗ, bên còn lại là bản sửa đúng hành vi nhưng sai nơi giao hàng.
Vì sao test xanh chưa đủ
Một kết quả test thường trả lời câu hỏi: implementation đang được nạp có vượt qua các assertion hay không. Trong bài toán kho hàng, các assertion kiểm tra nhiều tình huống. Checkout phải giữ tính nguyên tử: hoặc trừ đủ mọi sản phẩm, hoặc không thay đổi gì. Hai dòng cùng SKU phải được gộp trước khi kiểm tra tồn kho. Đối tượng trả về từ snapshot() không được trở thành đường tắt để sửa trạng thái nội bộ. Hai người mua không được cùng lấy đơn vị cuối cùng.
Bộ test ẩn còn đưa vào 50 thread tranh nhau 7 đơn vị hàng, cùng 40 người mua, mỗi người yêu cầu hai sản phẩm khan hiếm. Những ca này tạo ra tín hiệu rất cụ thể. Nếu thiếu khóa, test đỏ. Nếu đặt validation sai chỗ, test đỏ. Codex có thể đọc lỗi, sửa rồi chạy lại mà không cần người dùng sao chép output sang cửa sổ khác.
Nhưng có hai câu hỏi nằm ngoài phần assertion:
- Diff có nằm trong file và thư mục được yêu cầu không?
- Khi chạy test, Python có import đúng file vừa được sửa không?
Nếu câu trả lời cho một trong hai câu hỏi là không, công việc chưa thể được nghiệm thu. Test có thể vẫn xanh vì một implementation khác cũng đáp ứng hành vi. Đây không phải lỗi lý thuyết hiếm gặp. Chỉ cần có hai object cùng tên trong đường dẫn import, kết quả đã có thể khác với thứ người review đang mở.
Bối cảnh của phép thử
Dự án nhỏ mô phỏng một dịch vụ kho hàng. Các lỗi ban đầu nằm ở nhiều đường đi:
- Checkout có thể trừ kho sản phẩm đầu tiên rồi thất bại ở sản phẩm thứ hai.
- Hai dòng cùng SKU có thể vượt qua kiểm tra số lượng riêng lẻ.
- Số lượng không hợp lệ không được xử lý theo cùng một quy tắc.
snapshot()trả về dictionary vẫn có thể thay đổi trạng thái nội bộ.- Hai người mua có thể cùng lấy đơn vị cuối cùng trong một khoảng thời gian rất ngắn.
Sau khi chạy Codex, hash SHA-256 của file đích thay đổi từ:
5F8FA06F3A9B9ED7022CE2EEC9158D0139DEC6716872FAC8F9D0E86DDC7C88F8
thành:
008AF21A36C45CDBB9513961DBF52E2E663791EF5CA5A31FB018871F1F4EF66D
Trong lần chạy DSH, hash của cùng file không đổi. Một package inventory_service xuất hiện ở đường dẫn khác. Khi kiểm tra inventory_service.__file__, kết quả trỏ về package mới. Bộ test đã kiểm tra một implementation chạy đúng, nhưng file mà người dùng yêu cầu vẫn giữ nguyên.
Cách tính điểm vì thế được tách thành hai phần. Chín điểm cho chín test hành vi, một điểm cho việc file đích thật sự thay đổi. Codex đạt 10/10, DSH đạt 9/10. Đây không phải bảng xếp hạng hai model nói chung. Đó là kết quả của một bài toán, một harness và một lần chạy cụ thể.
Kết nối DeepSeek vào Codex
Cấu hình dùng trong lần chạy:
model = "deepseek-v4.1-flash"
model_provider = "crazyrouter"
[model_providers.crazyrouter]
name = "Crazyrouter"
base_url = "https://api.crazyrouter.com/v1"
env_key = "CRAZYROUTER_API_KEY"
wire_api = "responses"
requires_openai_auth = false
Sau khi thêm cấu hình, đừng kết luận kết nối đã đúng chỉ vì model trả lời được một câu chào. Hãy kiểm tra theo ba tầng riêng biệt.
Tầng 1: gateway và tên model
Gửi một yêu cầu ngắn. Mục tiêu không phải đánh giá chất lượng câu trả lời mà là xác nhận gateway nhận request, xác thực API key và định tuyến tới đúng model. Nếu bước này lỗi, các bước sau không có nhiều giá trị chẩn đoán.
Tầng 2: quyền chạy công cụ trong workspace
Yêu cầu Codex chạy một lệnh không có tác dụng phụ trong thư mục dự án. Kết quả cần cho thấy lệnh thật sự chạy ở đúng working directory. Một model trả lời đúng nhưng không gọi được công cụ không phải là một agent đã sẵn sàng sửa code.
Tầng 3: vòng phản hồi từ test
Chạy một test vẫn còn đỏ. Sau đó xem Codex có nhận được output, sửa file và chạy lại hay không. Đây là bước phân biệt một cửa sổ chat với một vòng lặp coding agent có thể dùng được.
Ba lỗi thường gặp nằm ở ba tầng khác nhau. API key sai thường dừng trước khi gọi model. Tên model sai lỗi ở bước chọn route. Model trả lời nhưng lệnh không chạy thường liên quan tới session, thư mục làm việc hoặc quyền công cụ. Thay đổi giá hay tên model không giải quyết được lỗi thuộc về quyền chạy lệnh.
Cấu hình chỉ là điểm bắt đầu; cần thấy output của test quay lại đúng workspace.
Bốn bằng chứng trước khi nghiệm thu
Sau khi agent dừng, hãy bắt đầu từ exit code và diff thay vì đọc bản tóm tắt. Tiếp theo, chạy các kiểm tra sau ngay trong thư mục dự án:
$target = Resolve-Path .\inventory_service.py
$target.Path
(Get-FileHash $target -Algorithm SHA256).Hash
python -c "import inventory_service; print(inventory_service.__file__)"
Get-ChildItem -Name inventory_service*
Từng dòng trả lời một câu hỏi riêng:
Resolve-Pathkhóa đối tượng đang được kiểm tra vào đúng file dự kiến.Get-FileHashcho biết nội dung đã thay đổi so với trước khi chạy hay chưa.- Lệnh Python cho biết module nào thật sự được import trong tiến trình hiện tại.
Get-ChildItemtìm package hoặc artifact cùng tên có thể chen vào đường dẫn import.
Không có tín hiệu nào thay thế được ba tín hiệu còn lại. Exit code 0 chỉ nói lệnh kết thúc mà không báo lỗi. Diff cho biết thay đổi có nằm trong phạm vi hay không. Hash xác nhận file đích có đổi. Đường dẫn import xác nhận bộ test đã nạp đúng object.
Bốn câu hỏi khác nhau; một dấu tick không thể trả lời thay phần còn lại.
Sau đó nên chạy lại bộ test bên ngoài phiên agent. Nó tách trạng thái test trong môi trường đã thay đổi khỏi trạng thái sạch. Nếu lần chạy sạch không giữ được kết quả, bản sửa chưa ổn định để bàn giao.
Trong CI, có thể lưu bốn loại bằng chứng vào cùng một artifact:
- Câu lệnh đã chạy và exit code.
- Diff nằm trong phạm vi cho phép.
- Hash của file đích trước và sau khi chạy.
- Đường dẫn file do lệnh import trả về.
Khi có đủ bốn phần, người review không phải suy luận từ một dòng 9 passed. Họ có thể kiểm tra xem tất cả tín hiệu có cùng chỉ vào một file hay không.
Vì sao DeepSeek rẻ hơn lại thay đổi nhịp làm việc
Phiên Codex ghi nhận 773.893 token đầu vào, gồm 738.432 token đọc từ cache và 35.461 token không có cache. Đầu ra là 24.869 token, trong đó có 8.033 token reasoning.
Với giá niêm yết của DeepSeek V4 Flash ngày 27 tháng 10 năm 2026, phép tính như sau:
| Phần | Token | Giá niêm yết mỗi 1 triệu token | Ước tính |
|---|---|---|---|
| Đầu vào không cache | 35.461 | 0,45 USD | 0,01596 USD |
| Đầu vào có cache | 738.432 | 0,02 USD | 0,01477 USD |
| Đầu ra | 24.869 | 1,34 USD | 0,03332 USD |
| Tổng | 0,064 USD |
Con số đầu vào lớn vì mỗi lần đọc file và mỗi output của lệnh lại quay vào ngữ cảnh của vòng lặp tiếp theo. DeepSeek không làm cửa sổ ngữ cảnh nhỏ đi một cách kỳ diệu. Điều thay đổi là chi phí cho mỗi lần thử thêm không còn tạo cảm giác phải cân nhắc quá lâu.
Áp cùng lượng token này vào giá niêm yết GPT-6.1 Sol, 2 USD mỗi triệu token đầu vào và 10 USD mỗi triệu token đầu ra, kết quả xấp xỉ 1,797 USD. Trong hồ sơ token của lần chạy này, chênh lệch khoảng 28 lần. Đây là phép tính theo bảng giá, không phải hóa đơn thực tế. Cách tính tiền của gateway, cache, routing và số lần gọi lại có thể làm thay đổi con số cuối cùng.
Một lần thử sai file có thể tiết kiệm vài xu token nhưng vẫn tạo chi phí review, tìm đúng artifact và nguy cơ deploy nhầm. Giá thấp không phải lý do bỏ qua kiểm tra; nó chỉ làm việc thử thêm phương án trở nên hợp lý hơn.
Khi nào nên dùng cấu hình này
DeepSeek trong Codex phù hợp với các việc có tín hiệu kiểm chứng rõ ràng: sửa một test đang đỏ, xử lý lint error, sửa kiểu dữ liệu, hoặc refactor nhỏ có thể chạy lại ngay. Điều kiện thuận lợi là có thông báo lỗi cụ thể, file đích rõ ràng và bộ test không quá rộng.
Không nên đồng nhất “test đạt” với “sẵn sàng production” trong các thay đổi về migration dữ liệu, thanh toán, xác thực, phân quyền hoặc cấu hình vận hành. Những khu vực này cần review thêm các điều kiện nằm ngoài test, cùng kế hoạch rollback và kiểm tra trên môi trường gần production.
Một cách bắt đầu nhỏ và có thể lặp lại:
- Chọn một test đang đỏ.
- Chỉ định một file đích.
- Kiểm tra kết nối theo ba tầng.
- Nhận bàn giao dựa trên exit code, diff, hash và đường dẫn import.
- Chạy lại test ngoài phiên agent.
- Chỉ mở rộng phạm vi khi cả bốn tín hiệu cùng chỉ về một đối tượng.
Nếu một tín hiệu lệch, đừng đổi model ngay. Hãy kiểm tra harness, working directory và đường dẫn import trước. Với agent, “làm đúng” và “giao đúng file” là hai điều kiện riêng.
Cấu hình kết nối Codex và gateway có tại Crazyrouter.
Đối chiếu: token, hash, câu lệnh và kết quả test lấy từ nhật ký chạy. Quan sát chỉ ở một dự án, một môi trường; giá là ước tính theo bảng giá ngày 27 tháng 10 năm 2026.
All Rights Reserved
