Khi nào nên dùng V4-Pro? Khi nào nên chọn Opus 4.7?

🔄 Từ bài học trước: Bạn đã xây dựng được phép tính chi phí. Bạn biết chi phí thực tế của V4-Pro và V4-Flash cho mỗi phiên. Bây giờ chúng ta sẽ đưa ra quyết định khó hơn: Khi nào nên sử dụng công cụ nào.

Đây là bài học quyết định liệu hệ thống lai của bạn có hoạt động lâu dài hay âm thầm làm mất lòng tin ngay lần đầu tiên V4-Pro tạo ra một API. Chúng ta sẽ đi sâu vào cả những thành công và thất bại.

Những điều bạn sẽ học được

Đến cuối bài học này, bạn sẽ có một cây quyết định bằng văn bản để định tuyến khối lượng công việc giữa V4-Pro và Opus 4.7, bạn sẽ biết ba chế độ lỗi được ghi nhận của V4 và cách phát hiện chúng sớm, và bạn sẽ có một giao thức kiểm thử song song cho các trường hợp không rõ ràng.

Ba chiến thắng được ghi nhận của V4-Pro

Chiến thắng 1 — Tính nhất quán ngữ cảnh dài hạn trong công việc quy mô monorepo

@TurtleAIHacks (25 tháng 4):

"Chạy hơn 80 Claude Code skill mỗi ngày — ngữ cảnh 1M trên deepseek-v4-pro… Đã thử nghiệm trên phân tích codebase 400K token ngày hôm qua và độ trễ gần như tương đương với Opus gốc một cách đáng ngạc nhiên."

Với mức giá Opus là 25 USD/triệu đầu ra, việc xử lý 400.000 token đầu vào cộng với tạo ra 50.000 token đầu ra có giá khoảng 10-15 USD cho mỗi lần phân tích. Với mức giá V4-Pro, con số này chỉ còn khoảng 0,85 USD. Việc giảm chi phí từ 12 đến 15 lần chính là điều khiến chiến thắng này trở nên hữu ích cho công việc hàng ngày.

Chiến thắng 2 — Tổng hợp, định tuyến và tóm tắt kiến ​​thức trong các vòng lặp agent

@0xmitsui (25 tháng 4), trong một bài kiểm tra hiệu năng quy trình làm việc thực tế bên trong Claude Code:

"V4-Pro đã đánh bại Opus 4.7 về tổng hợp kiến ​​thức, định tuyến bản ghi kiến ​​thức, tóm tắt hội thoại."

Mô hình: Các tác vụ liên quan đến việc kết hợp thông tin từ nhiều nguồn, quyết định điều động agent phụ nào hoặc nén những cuộc hội thoại dài thành các bản tóm tắt hữu ích. Kiến trúc tư duy xen kẽ của V4 bảo toàn ngữ cảnh suy luận trong các lần gọi công cụ, điều này đặc biệt giúp ích cho những tác vụ phối hợp nhiều bước này.

Chiến thắng 3 — Các vòng lặp agent với số lượng gọi công cụ cao, nơi chi phí sẽ quá cao nếu không sử dụng giải pháp này

@Tur24Tur (25 tháng 4):

"Tổng cộng 412 lần gọi công cụ. 3 thử thách web PortSwigger cấp chuyên gia + 1 ứng dụng Android thực tế. Tổng chi phí cho cả ngày: 6,84 USD trên deepseek-v4-pro."

Các nhóm bảo mật multi-agent. Các vòng lặp agent kéo dài với hàng trăm lần gọi công cụ. Bất cứ điều gì mà chi phí mỗi lần gọi của Opus sẽ đặt ra giới hạn về số lần lặp mà bạn có thể chi trả. Giá của V4-Pro về cơ bản thay đổi những gì khả thi về mặt kinh tế.

Ba lỗi được ghi nhận của V4-Pro

Phần này là điều mà hầu hết các bài viết "DeepSeek ra mắt với giá rẻ hơn 7 lần" đều bỏ qua. Các lỗi là có thật và bạn nên lên kế hoạch để đối phó với chúng.

Lỗi 1 — Ảo tưởng API trong quá trình tái cấu trúc sâu rộng của engine tùy chỉnh

Trường hợp điển hình từ @lvdigua:

"V4-Pro đã tạo ra một loạt API không tồn tại trong quá trình tái cấu trúc engine khổng lồ. Đừng sử dụng DeepSeek V4 trong môi trường sản xuất — tôi nghĩ nó còn tệ hơn cả Sonnet 3.5 về vấn đề này."

Mô hình: Một codebase với các API nội bộ, tùy chỉnh, chỉ dành riêng cho nội bộ. V4-Pro tạo ra các tên phương thức trông có vẻ hợp lý (viết hoa đúng, tham số hợp lý, không gian tên hợp lý) nhưng không tồn tại. Opus 4.7 của Anthropic có cơ sở chặt chẽ hơn về định nghĩa công cụ và nội dung file mà agent có thể nhìn thấy — khi nó không biết một API, nó có xu hướng đọc file liên quan thay vì tự tạo ra.

Cách phát hiện sớm: Nếu codebase của bạn dựa vào các framework độc quyền nội bộ, hãy chạy thử nghiệm sớm bằng cách yêu cầu V4-Pro viết code sử dụng 3-5 phương thức nội bộ cụ thể. Đừng cho nó biết các phương thức đó là gì. Hãy kiểm tra xem V4 có đọc các file liên quan trước hay tạo ra những file giả. Nếu nó tạo ra các file giả, đó là dấu hiệu cho thấy V4-Pro tiềm ẩn rủi ro khi thực hiện những chỉnh sửa codebase sâu rộng.

Giải pháp: Giữ Opus 4.7 làm công cụ chính cho các dự án API tùy chỉnh quan trọng trong môi trường sản xuất. Sử dụng V4-Pro cho codebase mới hoàn toàn, các framework codebase mở được tài liệu hóa tốt (React, Django, Express, Postgres standard SQL) và phân tích thăm dò khi chi phí rủi ro thấp.

Lỗi 2 — Sự sai lệch trong lập luận ở các phiên tích lũy rất dài

Cửa sổ ngữ cảnh 1 triệu là có thật, nhưng nhiều người vận hành báo cáo rằng chất lượng lập luận không hoàn toàn đồng nhất trên toàn bộ cửa sổ. Vượt quá khoảng 500.000 token trạng thái agent tích lũy, V4-Pro có thể mất tính nhất quán theo những cách mà Opus không gặp phải.

Ví dụ thực tế: Một phiên Claude Code kéo dài 6 giờ, trong đó bạn đã xây dựng ngữ cảnh một cách tăng dần (đọc nhiều file, thực hiện nhiều phân tích trung gian, gửi nhiều công cụ). Đến giờ thứ 5, V4-Pro bắt đầu mất dấu các quyết định được đưa ra ở giờ thứ 1.

Cách phát hiện sớm: Hãy chú ý nếu V4 bắt đầu mâu thuẫn với các quyết định trước đó hoặc "quên" những mẫu mà nó đã tuân theo. Đây là sự sai lệch trong lập luận, không phải là vấn đề về cửa sổ bộ nhớ.

Giải pháp khắc phục: Đối với các phiên mà bạn dự kiến ​​chạy hơn 4 giờ trạng thái tích lũy, hãy khởi động lại các phiên mới định kỳ (mỗi 2-3 giờ), hoặc quay lại Opus 4.7 cho những phiên chạy dài và sử dụng các sub-agent V4-Flash cho những lần gọi nội bộ tiết kiệm chi phí.

Lỗi 3 — Các kiểu từ chối khác nhau từ việc tinh chỉnh an toàn của Anthropic

V4 có các kiểu từ chối riêng, được huấn luyện vào mô hình của nó. Chúng không giống hệt với việc tinh chỉnh Constitutional-AI của Anthropic. Nếu quy trình làm việc của bạn phụ thuộc vào hành vi cụ thể của Claude liên quan đến việc từ chối — các công cụ bảo mật, nghiên cứu lưỡng dụng, những trường hợp ngoại lệ liên quan đến quyền riêng tư hoặc thông tin nhận dạng cá nhân — bạn sẽ thấy hành vi khác nhau trên V4.

Cách phát hiện sớm: Xác định 2-3 điểm tiếp xúc từ chối/an toàn cụ thể trong quy trình làm việc thực tế của bạn. Kiểm tra chúng trên V4 trong một môi trường ít rủi ro. Nếu V4 từ chối trong trường hợp Opus có thể hỗ trợ, hoặc ngược lại, bạn sẽ có dữ liệu về việc liệu sự khác biệt đó có quan trọng đối với công việc của bạn hay không.

Giải pháp khắc phục: Điều này phụ thuộc vào khối lượng công việc. Một số nhóm thấy các kiểu từ chối của V4 dễ dãi hơn (dễ dàng hơn cho nghiên cứu bảo mật), những nhóm khác lại thấy chúng hạn chế hơn (khó khăn hơn đối với một số trường hợp ngoại lệ hợp pháp). Không có quy tắc chung — hãy kiểm tra trực tiếp với công việc của bạn.

Cây quyết định

Đối với một kỹ sư đang làm việc, đây là framework sẽ sử dụng:

BẮT ĐẦU
│
├─ Đây có phải là công việc tái cấu trúc API tùy chỉnh quan trọng đối với sản xuất không?
│ └─ Có → Opus 4.7 (Rủi ro ảo giác V4 quá cao)
│
├─ Đây có phải là phiên bạn dự kiến ​​sẽ vượt quá 500.000 token tích lũy không?
│ └─ Có → Opus 4.7 (Rủi ro lệch hướng suy luận V4)
│
├─ Quy trình làm việc này có phụ thuộc vào việc điều chỉnh an toàn/từ chối Anthropic cụ thể không?
│ └─ Có → Opus 4.7 (kiểm tra V4 trước, nhưng mặc định là Opus cho đến khi được chứng minh)
│
├─ Bạn có đang thực hiện phân tích monorepo / codebase lớn (>200.000 token ngữ cảnh) không? 
│ └─ Có → V4-Pro với hậu tố [1m] (chênh lệch chi phí là yếu tố quyết định)
│
├─ Bạn có đang chạy các vòng lặp agent với >100 lệnh gọi công cụ mỗi phiên không?
│ └─ Có → V4-Pro (mẫu Tur24Tur; định tuyến sub-agent đến V4-Flash)
│
├─ Đây có phải là công việc tổng hợp/định tuyến/tóm tắt kiến ​​thức không?
│ └─ Có → V4-Pro (chuẩn 0xmitsui)
│
└─ Đây có phải là việc lập trình hàng ngày (các framework nổi tiếng, thư viện codebase mở, ngữ cảnh kích thước bình thường) không?
└─ Mặc định là V4-Pro vì chi phí thấp; chuyển sang Opus nếu chất lượng giảm sút

Sử dụng nó như một khung sườn ban đầu và điều chỉnh dựa trên ma trận chi phí mỗi nhiệm vụ của riêng bạn từ Bài học 3.

Giao thức thử nghiệm song song

Khi cây quyết định không rõ ràng đối với một khối lượng công việc cụ thể — thường xảy ra trong tháng đầu tiên sử dụng V4 — hãy chạy thử nghiệm song song.

Chọn MỘT loại quy trình công việc lặp đi lặp lại cụ thể từ công việc thực tế của bạn.

Ví dụ:
- "Tái cấu trúc một hàm và viết các bài kiểm thử cho nó"
- "Điều tra một lỗi thực tế từ trình theo dõi sự cố"
- "Tạo tài liệu API từ code hiện có"
- "Xem xét một PR về bảo mật và chất lượng code"

Trong MỘT TUẦN, hãy luân phiên công cụ nào xử lý từng trường hợp:
- Thứ Hai: V4-Pro
- Thứ Ba: Opus 4.7
- Thứ Tư: V4-Pro
- Thứ Năm: Opus 4.7
- Thứ Sáu: V4-Pro

Đối với mỗi phiên, hãy ghi lại:
- Thời gian thực tế
- Tổng chi phí
- Chất lượng chủ quan (1-5)
- Kết quả đầu ra có cần làm lại không? (Có/Không)
- Một câu: điều gì hiệu quả, điều gì không hiệu quả

Sau một tuần, bạn có 5 điểm dữ liệu cho mỗi công cụ đối với loại quy trình công việc cụ thể đó.
Các con số cho bạn biết công cụ nào chiến thắng cho công việc NÀY.

Cách sử dụng prompt này:

1. Nơi dán: Trước tiên, hãy mở terminal — đây là một giao thức quy trình công việc, hãy đọc nó như một danh sách kiểm tra và thực hiện thủ công trong suốt tuần làm việc thực tế của bạn. Theo dõi dữ liệu trong nhật ký kỹ thuật, Notion, Obsidian hoặc thậm chí là bảng tính.
2. Cách sao chép: Nhấp vào block code, Cmd+A / Ctrl+A, Cmd+C / Ctrl+C — dán vào hệ thống theo dõi tác vụ của bạn.
3. Điền thông tin chi tiết của bạn: Thay thế các quy trình công việc ví dụ bằng một quy trình từ công việc định kỳ thực tế của bạn. Đừng chọn các tiêu chuẩn giả tạo; điểm mấu chốt là dữ liệu quy trình công việc thực tế.
4. Những gì bạn sẽ thấy: Một ma trận 5×2 vào cuối tuần. Công cụ nào chiến thắng về thời gian, chi phí, chất lượng, tỷ lệ thực hiện lại. Đôi khi tùy chọn chiến thắng rất rõ ràng; đôi khi đó là một kết quả hòa và sự khác biệt về chi phí là yếu tố quyết định. Cách xử lý kết quả: Sử dụng ma trận để cập nhật cây quyết định của bạn. Nếu V4-Pro luôn thắng trong loại quy trình công việc này, hãy định tuyến nó đến đó vĩnh viễn. Nếu Opus thắng, hãy giữ quy trình công việc đó trên Opus và định tuyến các quy trình khác.
5. Nếu kết quả không ổn: Nếu V4-Pro luôn hoạt động kém hiệu quả trên tất cả các quy trình công việc của bạn, hãy kiểm tra lại hậu tố [1m] trong những biến môi trường của bạn (nếu không có nó, V4-Pro sẽ bị hạn chế một cách giả tạo). Nếu Opus luôn hoạt động kém hiệu quả, bạn có thể đang gặp phải các hình phạt giới hạn tỷ lệ từ báo cáo sự cố ngày 23 tháng 4 — V4 có thể thực sự tốt hơn trong trường hợp của bạn.

Lưu ý cụ thể về các đường dẫn quan trọng trong sản xuất

Đối với bất kỳ trường hợp nào mà việc thay đổi mô hình gây ra lỗi hồi quy sẽ là sự cố sản xuất, đừng chuyển sang V4 trong cùng tuần bạn chuyển sang V4 ở mọi nơi khác. Quy trình đúng:

1. Tuần 1: Sử dụng V4-Pro cho công việc phi sản xuất (dự án mới, khám phá, công cụ nội bộ)
2. Tuần 2-3: Xây dựng cơ sở chi phí mỗi nhiệm vụ và sơ đồ quyết định
3. Tuần 4: Thử nghiệm V4-Pro trên một quy trình làm việc gần với sản xuất (ví dụ: tạo bài test cho một dịch vụ hiện có)
4. Tuần 5 trở đi: Mở rộng sang sản xuất dựa trên chất lượng quan sát được

Việc triển khai theo từng giai đoạn này là cách các nhóm đã giới thiệu những công cụ mới trong nhiều thập kỷ. Sự hào hứng trong tuần ra mắt không làm thay đổi những nguyên tắc cơ bản.

Kiểm tra nhanh

Đối với ba loại quy trình làm việc thường xuyên nhất của bạn, hiện tại mỗi loại nằm ở vị trí nào trên sơ đồ quyết định? Hãy ghi lại. Kiểm tra lại sau một tuần sử dụng thực tế. Trực giác ban đầu của hầu hết các kỹ sư sẽ thay đổi sau một tuần sử dụng dữ liệu thực tế — thường nghiêng về V4-Pro nhiều hơn so với dự kiến ​​ban đầu, bởi vì sự chênh lệch chi phí khiến "chất lượng chấp nhận được với 1/7 chi phí" trở thành một sự lựa chọn có lợi cho nhiều khối lượng công việc hơn so với suy nghĩ ban đầu.

Những điểm chính cần ghi nhận

• Những thành công của V4-Pro đã được ghi nhận: Tính nhất quán ngữ cảnh dài hạn trên quy mô monorepo (phân tích TurtleAIHacks 400K), tổng hợp/định tuyến/tóm tắt kiến ​​thức (chuẩn mực 0xmitsui), vòng lặp agent với số lượng gọi công cụ cao (Tur24Tur 412 lần gọi/$6.84)
• Những thất bại của V4-Pro đã được ghi nhận: Ảo giác API khi tái cấu trúc sâu công cụ tùy chỉnh (trường hợp (@lvdigua), sự lệch hướng suy luận vượt quá ~500K token tích lũy, các mẫu từ chối khác nhau từ việc điều chỉnh an toàn Anthropic
• Cây quyết định là mặc định trước, không phải là quy tắc cứng nhắc — hãy ghi đè dựa trên ma trận chi phí mỗi tác vụ của riêng bạn
• Giao thức thử nghiệm song song: 5 phiên cho mỗi công cụ trên cùng một loại quy trình làm việc trong một tuần sẽ cho bạn biết sự thật cho công việc cụ thể của bạn
• Đối với các đường dẫn quan trọng trong sản xuất: Hãy lên kế hoạch triển khai trong 4-5 tuần; đừng thay thế mọi thứ cùng một lúc
• Kiểm tra lại trực giác hàng tuần — hầu hết các kỹ sư chuyển sang sử dụng V4-Pro nhiều hơn so với dự kiến ​​ban đầu khi dữ liệu chi phí thực sự có sẵn