Workflow ngữ cảnh dài cho cửa sổ 1 triệu token

Những gì 1 triệu token thực sự cho phép bạn làm

🔄 Từ bài học trước: Bạn đã có một sơ đồ quyết định để định tuyến công việc giữa V4-Pro và Opus. Bây giờ, chúng ta sẽ tập trung vào khả năng đặc biệt của V4-Pro — cửa sổ ngữ cảnh 1 triệu token thực sự mở ra các danh mục workflow mới.

Trong phần lớn hai năm qua, "cửa sổ ngữ cảnh 1 triệu token" chỉ là một khẩu hiệu tiếp thị. Giá cả khiến nó không thực tế. Với giá 25 USD/triệu token đầu ra của Opus 4.6, một cuộc điều tra cần 600.000 token ngữ cảnh có giá từ 30 đến 60 USD mỗi lần thử — quá đắt cho việc sử dụng thường xuyên. V4-Pro với giá 3,48 USD/triệu token đầu ra giảm workflow tương tự xuống còn 4-8 USD mỗi lần thử. Đột nhiên, đó là điều bạn có thể làm mỗi ngày.

Bài học này sẽ hướng dẫn các workflow trở nên tiết kiệm hơn ở mức giá này.

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

Đến cuối bài học này, bạn sẽ biết cách điều chỉnh kích thước cửa sổ ngữ cảnh cho phù hợp, cách cấu trúc các cuộc điều tra monorepo và đánh giá kiến ​​trúc đa dịch vụ, cách sử dụng tính năng lưu cache prompt để giảm đáng kể chi phí cho những truy vấn lặp lại trên cùng một ngữ cảnh, và cách nhận biết khi nào workflow đã đi vào vùng suy luận lệch hướng và cần khởi động lại phiên.

Điều chỉnh kích thước cửa sổ ngữ cảnh

V4-Pro với [1m] hỗ trợ 1 triệu token đầu vào. Trên thực tế, bạn muốn chừa chỗ cho:

• Tạo đầu ra (~50-100K token cho các phản hồi có nội dung)
• Chi phí gọi công cụ (~50-100K cho việc trao đổi qua lại)
• Token suy luận/suy nghĩ (~50K, nhiều hơn nếu EFFORT_LEVEL=max)

Điều đó để lại 600-800K token không gian đầu vào có thể sử dụng được. Để tham khảo:

Dịch: Hầu hết các codebase cấp dịch vụ (10K-50K dòng code) đều vừa vặn. Các monorepo cỡ trung bình (50K-100K dòng code) cũng vừa vặn với dung lượng dự phòng hợp lý. Các monorepo rất lớn (trên 100K dòng code) yêu cầu lựa chọn file chiến lược — bạn không thể load tất cả cùng một lúc.

Đối với các codebase vượt quá ngân sách, mô hình phù hợp là:

1. Sử dụng mô hình nhỏ hơn, nhanh hơn (V4-Flash hoặc claude --model deepseek-v4-flash) để tóm tắt trước từng dịch vụ hoặc thư mục.
2. Đưa các bản tóm tắt cộng với nội dung file liên quan nhất vào V4-Pro.
3. Giữ tổng dung lượng đầu vào dưới 600K.

Workflow 1: Điều tra kiến ​​trúc đa dịch vụ

Đây là ví dụ điển hình về "1 triệu ngữ cảnh mở khóa công việc mới".

Tình huống: Bạn có một kiến ​​trúc gồm 5 dịch vụ (xác thực, thanh toán, thông báo, tìm kiếm, lập hóa đơn). Một báo cáo lỗi cho biết "người dùng bị tính phí hai lần khi phiên xác thực của họ hết hạn trong quá trình thanh toán". Lỗi này xảy ra trên cả 5 dịch vụ.

Cách tiếp cận trước V4: Điều tra từng dịch vụ riêng lẻ, ghi chú, đối chiếu thủ công các phát hiện. Mất 4-6 giờ làm việc.

Cách tiếp cận V4-Pro: Load code của cả 5 dịch vụ vào ngữ cảnh cùng một lúc, yêu cầu V4-Pro theo dõi luồng yêu cầu và xác định nơi trạng thái có thể trở nên không nhất quán.

Bạn đang điều tra một lỗi liên quan đến nhiều dịch vụ, load code liên quan từ 5 dịch vụ vào ngữ cảnh. Vui lòng:

1. Lập sơ đồ luồng yêu cầu khi người dùng bắt đầu thanh toán (các dịch vụ liên quan, theo thứ tự)
2. Xác định trạng thái được chia sẻ giữa các dịch vụ (token phiên, ý định thanh toán, bản ghi thanh toán)
3. Tìm mọi nơi mà một dịch vụ giả định trạng thái của dịch vụ khác nhưng không xác minh nó
4. Cụ thể tìm kiếm chế độ lỗi: "Phiên xác thực của người dùng hết hạn trong quá trình thanh toán, dịch vụ thanh toán vẫn tính phí cho họ"

5 dịch vụ như sau:
[dán auth-service/src/ - bỏ qua các bài kiểm tra, ~30K token]
[dán payments-service/src/ - bỏ qua các bài kiểm tra, ~40K token]
[dán notifications-service/src/ - bỏ qua các bài kiểm tra, ~20K token]
[dán search-service/src/ - bỏ qua các bài kiểm tra, ~20K token]
[dán billing-service/src/ - bỏ qua các bài kiểm tra, ~50K token]

Tổng ngữ cảnh: ~160K token
Kết quả mong muốn: Một báo cáo điều tra bằng văn bản với các tham chiếu file:line

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

1. Nơi dán: Mở Claude Code (chạy claude) — dán vào REPL sau khi chạy claude trong thư mục gốc của monorepo. Hoặc dán vào file .md và chạy lệnh claude < investigation.md để sử dụng hàng loạt.
2. Cách sao chép: Nhấp vào block code, nhấn Cmd+A / Ctrl+A, Cmd+C / Ctrl+C.
3. Điền thông tin chi tiết của bạn: Thay thế các khối trong ngoặc vuông [paste service-name/src/] bằng nội dung file thực tế. Sử dụng công cụ Read của Claude Code để load chúng — Claude Code sẽ tự động xử lý việc đếm token. Ước tính kích thước dự kiến ​​chỉ là gần đúng; hãy kiểm tra mức sử dụng thực tế của bạn trong REPL.
4. Những gì bạn sẽ thấy: Trong vòng 2-5 phút, V4-Pro sẽ trả về một báo cáo điều tra có cấu trúc: Sơ đồ luồng yêu cầu ở dạng văn bản, danh sách trạng thái được chia sẻ, các điểm lỗi tiềm năng, tham chiếu file:dòng. Chi phí: ~$0.40-1 cho phân tích 160K token.
5. Cách sử dụng kết quả: Sử dụng các tham chiếu file:line để kiểm tra những ứng viên theo cách thủ công. Đừng tin tưởng V4-Pro sẽ xác nhận lỗi tồn tại — hãy sử dụng nó như một công cụ tạo giả thuyết. Sau khi đã thu hẹp các ứng viên, bạn có thể sửa lỗi thủ công hoặc đưa những ứng viên đó trở lại một phiên làm việc nhỏ hơn, tập trung hơn.
6. Nếu có vẻ không ổn: Nếu V4-Pro trả về phản hồi chung chung "đây là những điều kiện tranh chấp phổ biến trong kiến ​​trúc microservice", nghĩa là bạn chưa load đủ code thực tế — hãy tăng lựa chọn file. Nếu nó cho rằng có lỗi trong code rõ ràng là chính xác, hãy coi đó là lỗi cảnh báo giả và kiểm tra lại file:line.

Workflow 2: Lập kế hoạch tái cấu trúc quy mô Monorepo

Tình huống: Bạn đang di chuyển một codebase TypeScript 50.000 dòng từ Express sang Fastify. Bạn cần xác định tất cả các điểm tiếp xúc trong quá trình di chuyển, ưu tiên chúng và lập kế hoạch bằng văn bản.

Cách tiếp cận của V4-Pro: Load toàn bộ thư mục src/ cùng với các file gói liên quan, yêu cầu V4-Pro tạo kế hoạch di chuyển với độ chi tiết ở cấp độ file.

Tôi đang lên kế hoạch di chuyển từ Express sang Fastify trong một codebase TypeScript. Vui lòng lập kế hoạch di chuyển code:

1. Liệt kê mọi file nhập từ 'express' (với các lệnh nhập cụ thể được sử dụng)
2. Phân loại từng file theo mức độ khó khăn của việc di chuyển: đơn giản (thay thế 1:1), trung bình (API khác nhưng cấu trúc tương tự), phức tạp (khác biệt về ngữ nghĩa)
3. Xác định các vấn đề xuyên suốt: các mẫu middleware, trình xử lý lỗi, định nghĩa tuyến đường, bổ sung yêu cầu/phản hồi
4. Đề xuất thứ tự di chuyển — nên di chuyển cái gì trước để giảm thiểu rủi ro
5. Đánh dấu các vấn đề cụ thể của Fastify dựa trên các mẫu code thực tế của tôi

Codebase như sau. Các file được đánh dấu [skip] là những file kiểm thử / cấu hình bản build không cần di chuyển:

[dán toàn bộ nội dung thư mục src/ — ~250K token]
[dán package.json]
[dán tsconfig.json]

Định dạng đầu ra: markdown với các phần rõ ràng.

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

1. Nơi dán: Mở Claude Code — trong REPL, lý tưởng nhất là được chuyển từ một file. Sử dụng công cụ Read một cách rộng rãi để điền vào ngữ cảnh.
2. Cách sao chép: Nhấn Cmd+A / Ctrl+A bên trong khối, sau đó nhấn Cmd+C / Ctrl+C.
3. Điền thông tin chi tiết của bạn: Kế hoạch này được thiết kế để tùy chỉnh cho quá trình chuyển đổi cụ thể của bạn. Express→Fastify chỉ là một ví dụ; mẫu tương tự cũng áp dụng cho React class→hooks, Webpack→Vite, REST→GraphQL, JS→TS, v.v...
4. Những gì bạn sẽ thấy: Một kế hoạch định dạng Markdown với các phần dành cho những quá trình chuyển đổi đơn giản/trung bình/phức tạp, các vấn đề xuyên suốt, thứ tự được đề xuất. Chi phí: Khoảng 1-2 USD cho phân tích 250.000 token với kết quả chi tiết.
5. Cách sử dụng kết quả: Sử dụng nó như lộ trình chuyển đổi của bạn. Theo dõi từng file khi bạn chuyển đổi. Đánh dấu các mục đã hoàn thành. Chạy lại kế hoạch sau các mốc quan trọng để phát hiện sự sai lệch.
6. Nếu thấy không ổn: Nếu bản kế hoạch trông giống như tài liệu chung về so sánh Express và Fastify hơn là cụ thể cho code của bạn, nghĩa là bạn đã load quá ít file. Hãy load lại với nhiều code hơn. Nếu nó đề xuất những thay đổi trái ngược với quy ước của nhóm bạn, hãy chỉnh sửa lại — V4-Pro không biết quy ước của bạn cho đến khi bạn cho nó biết.

Workflow 3: Đánh giá kiến ​​trúc cho quá trình hội nhập tuần đầu tiên của nhân viên mới

Tình huống: Bạn có một kỹ sư cao cấp mới bắt đầu làm việc vào thứ Hai. Bạn muốn cung cấp cho họ một hướng dẫn được ghi lại "cách thức hoạt động thực tế của codebase này" — không phải là README (luôn lỗi thời), mà là một bản đồ kiến ​​trúc thực sự.

Hãy tạo một tài liệu tham khảo kiến ​​trúc cho một kỹ sư cao cấp mới. Đối tượng mục tiêu: Người có hơn 5 năm kinh nghiệm về TypeScript/Node nhưng mới làm quen với code nguồn cụ thể này. Bao gồm:

1. Bài giới thiệu ngắn gọn 30 giây (ứng dụng này làm gì?)
2. 5 khái niệm cốt lõi của lĩnh vực ứng dụng, mỗi khái niệm được giải thích trong một đoạn văn
3. Mô hình dữ liệu: các thực thể chính, mối quan hệ giữa chúng và nơi lưu trữ
4. Luồng yêu cầu cho 3 endpoint có lưu lượng truy cập cao nhất
5. 5 file "chịu tải" nhất (chạm vào chúng có thể gây ra nhiều lỗi)
6. Các quy ước cần tuân theo mà không thể hiện rõ ràng chỉ trong một file
7. 3 khoản nợ kỹ thuật lớn nhất — chúng là gì, tại sao chúng tồn tại và ai chịu trách nhiệm
8. 3 điều bạn KHÔNG BAO GIỜ nên động vào mà không hỏi ý kiến ​​người khác trước

Hãy cụ thể. Sử dụng tham chiếu file:line. Không dùng những lời lẽ sáo rỗng chung chung về kỹ thuật.

Codebase sẽ được trình bày sau.

[dán toàn bộ thư mục src/ — ~200K từ]
[dán thư mục docs/ nếu có — ~10K từ]
[dán prisma/schema.prisma hoặc ORM schema tương đương]
[dán 3 tài liệu kiểu ADR gần đây nhất từ ​​bất kỳ thư mục /decisions/ nào]

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

1. Nơi dán: Trong Claude Code REPL với codebase làm ngữ cảnh. Công cụ Read sẽ xử lý việc load file. Xuất ra file markdown: claude > onboarding-doc.md.
2. Cách sao chép: Cmd+A / Ctrl+A, sau đó Cmd+C / Ctrl+C bên trong khối.
3. Điền thông tin chi tiết của bạn: Đây là prompt hiếm hoi hầu như không thay đổi — cấu trúc hoạt động với hầu hết các codebáe. Các lựa chọn file trong ngoặc cần phải khớp với bố cục dự án của bạn.
4. Những gì bạn sẽ thấy: Một tài liệu markdown dài 2.000-3.000 từ bao gồm tất cả 8 phần, với các tham chiếu file:line xuyên suốt. Chi phí: Khoảng 1,50-3 USD cho một phân tích 200.000 token với mức đầu ra này.
5. Cách xử lý đầu ra: Đọc kỹ trước khi gửi cho nhân viên mới — V4-Pro đôi khi sẽ mắc lỗi về quy ước hoặc liệt kê các file "chịu tải" mà thực chất không quan trọng. Chỉnh sửa. Sau đó, lưu lại dưới dạng docs/onboarding/architecture.md trong kho lưu trữ của bạn để nó trở thành tài liệu sống chứ không phải là tài liệu chỉ dùng một lần.
6. Nếu kết quả không ổn: Nếu tài liệu đọc giống như "đây là cách các ứng dụng Node hoạt động", V4 không nhận được đủ tín hiệu cụ thể — bạn có thể cần thêm tài liệu/ngữ cảnh, hoặc cung cấp cho nó các file test của bạn (các bài test tiết lộ logic nghiệp vụ thực tế). Nếu nó đưa ra các quyết định kiến ​​trúc sai, những quyết định đó có thể không được ghi lại ở bất kỳ đâu mà V4 có thể đọc được — hãy ghi lại chúng ngay bây giờ trong ADR.

Lưu cache prompt cho các truy vấn lặp lại

Nếu bạn định hỏi nhiều câu hỏi về cùng một ngữ cảnh lớn, việc lưu cache prompt là rất quan trọng.

Mức phí nhập liệu được lưu cache của DeepSeek là 0,03 USD/triệu token — rẻ hơn khoảng 58 lần so với mức phí 1,74 USD/triệu token của V4-Pro. Bí quyết: Hãy cấu trúc các câu hỏi của bạn sao cho nội dung tham khảo lớn luôn nằm ở phần đầu của mỗi truy vấn, chỉ có câu hỏi thay đổi ở cuối.

Ví dụ về cấu trúc cho quy trình hỏi đáp hàng ngày trên monorepo:

[TIỀN TỐ ỔN ĐỊNH — tự động lưu vào cache]
Bạn là chuyên gia về codebase này. Tài liệu tham khảo bên dưới.

[dán toàn bộ codebase — 600.000 token]

[ĐUÔI BIẾN ĐỔI — khác nhau cho mỗi truy vấn]
Câu hỏi: Middleware xác thực quyết định refresh token như thế nào?

Truy vấn đầu tiên: Giá nhập liệu đầy đủ của V4-Pro (1,74 USD × 0,6 = ~1,05 USD chi phí nhập liệu) + đầu ra. Truy vấn 2-N: giá nhập liệu được lưu vào bộ nhớ cache (0,03 USD × 0,6 = ~0,02 USD chi phí nhập liệu) + đầu ra.

Với mô hình họp giao ban hàng ngày kiểu "hỏi 10 câu hỏi về monorepo này", phương pháp lưu cache giúp giảm tổng chi phí từ khoảng 15 USD xuống còn khoảng 1 USD. Mức giảm đáng kể.

Lưu cache có thời gian tồn tại (thường từ vài phút đến vài giờ). Đối với các phiên làm việc dài hoặc các công việc thường ngày, phương pháp này hoạt động tốt. Đối với các cuộc điều tra riêng lẻ trải dài nhiều ngày, cache sẽ hết hạn và truy vấn đầu tiên của ngày thứ hai sẽ phải trả toàn bộ chi phí đầu vào một lần nữa.

Nhận biết sự sai lệch trong lập luận

Cửa sổ ngữ cảnh 1 triệu từ của V4-Pro là có thật, nhưng chất lượng không hoàn toàn đồng nhất trên toàn bộ cửa sổ. Nhiều người dùng đã báo cáo sự sai lệch trong lập luận khi số lượng từ ngữ cảnh tích lũy vượt quá khoảng 500.000 từ.

Cách nhận biết:

• V4 bắt đầu mâu thuẫn với các quyết định trước đó trong cùng một phiên làm việc
• Nó "quên" các mẫu mà nó đã tuân theo một cách chính xác
• Nó khẳng định điều gì đó nằm trong ngữ cảnh trong khi thực tế không có, hoặc khẳng định điều gì đó không có trong khi thực tế có
• Các lệnh gọi công cụ trở nên dư thừa hơn — đọc lại những file mà nó đã đọc

Giải pháp đúng: Đừng tiếp tục. Sự sai lệch sẽ tích lũy. Khởi động lại với một tập hợp con được tập trung:

1. Tóm tắt những gì bạn đã học được cho đến nay trong 1-2 đoạn văn
2. Xác định 2-3 file liên quan nhất đến phần công việc tiếp theo
3. Bắt đầu một phiên làm việc Claude mới chỉ với những file đó cộng với bản tóm tắt của bạn
4. Lặp lại

Hầu hết các kỹ sư có kinh nghiệm giới hạn các phiên làm việc V4-Pro ở mức 2-3 giờ trạng thái tích lũy trước khi khởi động lại. Chi phí khởi động lại là nhỏ; chi phí của việc tiếp tục làm việc khi có sự sai lệch là công việc không chính xác mà bạn phải làm lại.

Kiểm tra nhanh

Chọn một workflow từ công việc thực tế của bạn mà bạn cho là "quá tốn kém để thực hiện thường xuyên". Có thể đó là một bài đánh giá kiến ​​trúc mà bạn định viết. Có thể là một kế hoạch di chuyển cho một dịch vụ cũ. Có thể là một phiên gỡ lỗi yêu cầu load 5 dịch vụ. Hãy chạy nó qua V4-Pro với ngữ cảnh 1M. Theo dõi chi phí. Chi phí có thể sẽ chỉ bằng 1/10 đến 1/15 so với bạn tưởng tượng — và workflow sẽ chuyển từ "làm mỗi quý một lần" thành "làm bất cứ khi nào cần thiết".

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

• Cửa sổ ngữ cảnh 1M với [1m] là có thật; Không gian đầu vào khả dụng là 600-800K token sau khi đã tính đến dung lượng dự phòng cho đầu ra, các lệnh gọi công cụ và suy luận.
• Điều tra kiến ​​trúc đa dịch vụ là workflow "tiết kiệm chi phí" điển hình ở mức giá V4-Pro.
• Lập kế hoạch tái cấu trúc quy mô Monorepo giảm từ 30-60 USD mỗi lần thử (Opus) xuống còn 1-3 USD (V4-Pro) — về cơ bản thay đổi tần suất bạn thực hiện việc này.
• Lưu cache prompt ở mức 0,03 USD/triệu token đầu vào được lưu vào cache làm giảm workflow truy vấn lặp lại khoảng 58 lần — hãy cấu trúc prompt của bạn với tiền tố ổn định + đuôi biến đổi.
• Hiện tượng trôi lệch suy luận bắt đầu xảy ra khi tích lũy được khoảng 500K token; hãy khởi động lại các phiên mới sau mỗi 2-3 giờ thay vì tiếp tục chạy.
• Cách kiểm tra tốt nhất: Chọn một workflow mà bạn đã "để dành" vì lý do chi phí. Chạy nó. Theo dõi hóa đơn.