Hướng dẫn tối ưu token theo quy trình SDD

Tối ưu token là đưa đúng yêu cầu và ngữ cảnh liên quan để AI tập trung vào phần việc cần làm.

• SDD (Spec-Driven Development) bắt đầu từ yêu cầu và tiêu chí chấp nhận;
• schema/contract là một phần giúp làm rõ ranh giới dữ liệu.
• Đưa đúng phần spec, contract và mã liên quan vào ngữ cảnh có thể giảm nội dung thừa;
• mức tiết kiệm token phụ thuộc task và cách làm việc.

🧭 Mô hình tổng thể

[Input: Spec, contract, mã liên quan]
           │
           ▼
[Phân tầng Model & Reasoning Effort]
 ├─ Năng lực cao: Phân tích kiến trúc, logic khó
 ├─ Năng lực vừa: Viết logic theo boundary
 └─ Nhanh/nhẹ: Boilerplate, type, stub
           │
           ▼
[Output: Diff-Only / Patch] (Chặn tái tạo toàn file)

Mô hình vận hành theo 3 trụ cột: chỉ đưa contract liên quan vào đầu vào, chọn model và mức suy luận theo độ khó, rồi giới hạn đầu ra vào diff/patch khi chỉ sửa một phần.

🗺️ 1. Chọn năng lực model theo tác vụ

Không dùng model flagship đắt đỏ cho công việc lặp lại. Phân chia tác vụ theo 3 tầng năng lực:

Năng lực cao     ──> Kiến trúc, logic khó
        │
Năng lực vừa     ──> Logic theo contract
        │
Nhanh/nhẹ         ──> Stub, mock, tác vụ lặp lại

• Năng lực suy luận cao: Dùng khi cần phân tích kiến trúc, phản biện yêu cầu hoặc truy nguyên lỗi khó.
• Năng lực cân bằng: Dùng để triển khai logic nghiệp vụ và mapping trong contract đã rõ.
• Nhanh/chi phí thấp: Dùng cho tác vụ hẹp, lặp lại như boilerplate, type stub và mock data.

Tên model, mức suy luận và giá thay đổi theo nhà cung cấp. Hãy chọn theo khả năng hiện có, chính sách dữ liệu và chất lượng trên tác vụ thực tế; các nhãn trên là cách phân nhóm công việc, không phải xếp hạng cố định.

⚙️ 2. Quy trình SDD tối ưu token theo từng giai đoạn

Quy tắc cốt lõi: Chọn model theo độ khó của task; giữ spec và tiêu chí chấp nhận làm căn cứ, dùng schema/contract để ràng buộc phần triển khai.

1. Design Contract ──> Năng lực cao
        │
2. Gen Type & Stub ──> Nhanh/nhẹ
        │
3. Implement Logic ──> Năng lực cân bằng
        │
4. Unit Test Mocks ──> Nhanh/nhẹ
        │
5. Deep Debugging  ──> Năng lực cao

1. Giai đoạn 1: Design Schema & Contract: Thiết kế OpenAPI, JSON Schema, Prisma hoặc database architecture. Chọn model có khả năng phân tích phù hợp để rà mâu thuẫn ranh giới dữ liệu trước khi viết code.
2. Giai đoạn 2: Stubbing & DTOs: Sinh type definitions, interfaces và data models từ schema đã thống nhất. Vì đây thường là ánh xạ trực tiếp, có thể chọn model nhanh/nhẹ sau khi kiểm tra đầu ra.
3. Giai đoạn 3: Business Logic Implementation: Hiện thực hóa logic nghiệp vụ bên trong các hàm có ranh giới input/output rõ ràng. Chỉ nạp mã nguồn cần thiết để hiểu module và các phụ thuộc liên quan.
4. Giai đoạn 4: Unit Test & Mocks: Sinh mock data và đề xuất ca kiểm thử biên dựa trên input/output contract. Người viết vẫn cần kiểm tra test có xác nhận đúng behavior hay không.
5. Giai đoạn 5: Deep Root-Cause Debugging: Với lỗi khó như race condition hoặc deadlock, cung cấp log và phạm vi liên quan rồi cân nhắc model có năng lực suy luận cao hơn. Không nạp dữ liệu nhạy cảm nếu chưa được phép.

💡 3. Bốn nguyên tắc vàng tiết kiệm token

 [Input]                [Processing]             [Output]
Cô đọng               Chọn effort phù hợp      Giới hạn phạm vi
   │                         │                      │
   ▼                         ▼                      ▼
Nạp đúng spec,        Dùng model phù hợp      Yêu cầu diff/patch
contract và mã        với độ khó của task     cho sửa đổi cục bộ

3.1. Nguyên tắc “Schema làm mỏ neo” (Contract-First)

Thay vì nạp toàn bộ repository, bắt đầu với yêu cầu, tiêu chí chấp nhận, interface và contract liên quan (schema.prisma, swagger.yaml, types.ts), rồi bổ sung đúng tệp phụ thuộc khi cần. Cách này giảm phần đầu vào không liên quan; mức giảm cụ thể tùy repository và task.

3.2. Kiểm soát Thinking và Reasoning Tokens

Một số model cho phép cấu hình mức suy luận. Với tác vụ hẹp, có tiêu chí và cấu trúc rõ, hãy thử mức thấp hơn hoặc model nhanh hơn rồi kiểm tra kết quả; tác vụ mơ hồ hay rủi ro cao có thể cần phân tích sâu hơn.

3.3. Cơ chế Diff-Only Output

Cấm model sinh lại boilerplate HTML/CSS hoặc toàn bộ file khi chỉ sửa đổi một câu lệnh logic.

• Prompt mẫu:

Chỉ xuất unified diff hoặc đúng function cần sửa, không xuất lại toàn bộ file.

3.4. Kỷ luật Context Window

Không có một ngưỡng token cố định áp dụng cho mọi model và tác vụ. Nghiên cứu về long context ghi nhận một số model truy xuất kém hơn khi thông tin cần thiết nằm giữa ngữ cảnh dài; điều đó không thiết lập ngưỡng chung 100K cho mọi model. Khi lịch sử không còn liên quan hoặc khó điều hướng, hãy tạo phiên mới với mục tiêu, quyết định và contract cần thiết. Nguồn nghiên cứu.

🎯 Kết luận

Yêu cầu + contract liên quan
       ↓
Model và suy luận theo độ khó
       ↓
Diff nhỏ + test phù hợp
       ↓
Ít ngữ cảnh thừa; thay đổi vẫn kiểm chứng được

🧳 Tóm tắt bỏ túi (Take away)