DEV Community

Cover image for Cách sử dụng Kimi K3 để lập trình với Kimi Code
Sebastian Petrus
Sebastian Petrus

Posted on • Originally published at apidog.com

Cách sử dụng Kimi K3 để lập trình với Kimi Code

Moonshot AI xây dựng Kimi K3 cho các tác vụ lập trình không thể hoàn thành chỉ bằng một lời nhắc: đọc kho lưu trữ lớn, chỉnh sửa tệp, chạy công cụ, thực thi kiểm thử, phân tích nhật ký và ảnh chụp màn hình, rồi lặp lại đến khi hoàn tất. Để làm việc này, bạn chạy K3 trong Kimi Code — tác nhân lập trình terminal và IDE của Moonshot. Bài viết này hướng dẫn cách thiết lập quy trình, giao việc hiệu quả, kiểm chứng đầu ra và hiểu các giới hạn thực tế của K3.

Dùng thử Apidog ngay hôm nay

TL;DR: Chạy Kimi K3 để lập trình

Kimi K3 là mẫu flagship của Moonshot AI, ra mắt ngày 16 tháng 7 năm 2026, có cửa sổ ngữ cảnh 1 triệu token và được điều chỉnh cho công việc quy mô kho lưu trữ. Bạn sử dụng nó qua Kimi Code bằng cách chọn mô hình với /model, sau đó giao một nhiệm vụ cụ thể.

K3 phù hợp với các tác vụ cần:

  • Điều hướng codebase lớn.
  • Đọc/ghi tệp và chạy lệnh shell.
  • Gỡ lỗi dựa trên log, stack trace và kết quả kiểm thử.
  • Lặp lại sau phản hồi thời gian chạy hoặc ảnh chụp màn hình.
  • Duy trì ngữ cảnh dài trong các phiên kỹ thuật nhiều bước.

K3 có lợi thế chi phí cho các vòng lặp dùng nhiều bộ nhớ đệm, với tỷ lệ cache hit được báo cáo trên 90%. Tuy nhiên, tốc độ khoảng 62 token/giây không phải nhanh nhất, và Moonshot thừa nhận K3 vẫn kém Claude Fable 5 và GPT-5.6 Sol về năng lực thô.

Nếu K3 xây dựng API cho bạn, hãy dùng Apidog để gửi request thật, kiểm tra status code, schema phản hồi và hành vi xác thực. Để xem thông tin nền về mô hình, bắt đầu với Kimi K3 là gì.

Kimi Code là gì?

Kimi Code là tác nhân lập trình của Moonshot. Nó chạy trong terminal, có thể tích hợp IDE, đọc và ghi tệp, thực thi shell command, chạy kiểm thử và quản lý một phiên kỹ thuật hoàn chỉnh thay vì chỉ trả lời câu hỏi về mã.

Quy trình cơ bản:

  1. Mở Kimi Code trong thư mục dự án.
  2. Mô tả nhiệm vụ với tiêu chí hoàn thành rõ ràng.
  3. Để tác nhân đọc codebase và lập kế hoạch.
  4. Cho phép nó chỉnh sửa, chạy kiểm thử và đọc phản hồi.
  5. Kiểm tra diff trước khi merge hoặc triển khai.

Mô hình K3 xử lý văn bản và gọi công cụ; Kimi Code cung cấp môi trường làm việc như filesystem, shell, đầu ra kiểm thử và ảnh chụp màn hình. Kết hợp này biến một mô hình sinh mã thành tác nhân có thể xử lý một ticket kỹ thuật nhiều bước.

Kimi Code

Kimi Code không chỉ hỗ trợ K3; dòng Kimi K2 trước đây cũng dùng cùng tác nhân này. Xem hướng dẫn CLI của Kimi Code để cài đặt từ đầu, hoặc cách sử dụng Kimi CLI để tham khảo thêm về dòng lệnh.

Chạy Kimi K3 trong Kimi Code

Cú pháp cài đặt và cờ lệnh có thể thay đổi khi Moonshot cập nhật công cụ. Hãy dùng quy trình dưới đây như một checklist, sau đó xác nhận câu lệnh hiện tại trong tài liệu chính thức của Kimi hoặc hướng dẫn CLI của Kimi Code.

Thiết lập Kimi Code

1. Cài đặt tác nhân và xác thực

Bạn cần tài khoản Kimi và API key từ nền tảng nhà phát triển Kimi. Không hard-code khóa vào file cấu hình có thể bị commit. Thay vào đó, dùng biến môi trường:

# Chỉ mang tính minh họa. Kiểm tra tài liệu Kimi để có cú pháp hiện tại.
export KIMI_API_KEY="your-key-here"

# Khởi chạy tác nhân trong thư mục hiện tại
kimi-code
Enter fullscreen mode Exit fullscreen mode

Khuyến nghị thực tế:

  • Lưu API key trong secret manager hoặc file .env đã được thêm vào .gitignore.
  • Không gửi API key vào prompt.
  • Chỉ cấp quyền cần thiết cho thư mục dự án đang xử lý.

2. Khởi chạy trong thư mục gốc của dự án

Mở terminal tại repository cần làm việc:

cd path/to/your-project
kimi-code
Enter fullscreen mode Exit fullscreen mode

Thư mục hiện tại là workspace của tác nhân. Nếu bạn khởi chạy sai cấp thư mục, Kimi Code có thể không nhìn thấy các tệp cấu hình, package workspace hoặc module liên quan.

3. Chọn Kimi K3

Trong phiên Kimi Code, chọn K3:

/model kimi-k3
Enter fullscreen mode Exit fullscreen mode

Bạn có thể dùng cùng cơ chế này để chuyển sang các mô hình khác, chẳng hạn Kimi K2.7 Code, khi cần so sánh chất lượng hoặc tốc độ trên cùng một nhiệm vụ.

4. Chọn mức nỗ lực suy luận phù hợp

K3 hỗ trợ cấu hình nỗ lực suy luận, bao gồm mức “tối đa”.

Dùng mức cao hơn cho:

  • Gỡ lỗi lỗi khó tái tạo.
  • Refactor nhiều module.
  • Phân tích dependency phức tạp.
  • Sửa lỗi cần đọc log, test và code ở nhiều lớp.

Dùng mức thấp hơn cho:

  • Đổi tên biến hoặc hàm.
  • Chỉnh sửa tài liệu.
  • Thay đổi nhỏ, có phạm vi rõ ràng.
  • Tạo test case đơn giản.

Sau khi chọn mô hình và workspace, bạn có thể giao nhiệm vụ. Nếu muốn thử K3 mà không cần cài Kimi Code hoặc cần lựa chọn miễn phí, xem cách sử dụng Kimi K3 miễn phí.

Quy trình lập trình tác nhân thực tế

Dù bạn sửa bug hay xây tính năng, quy trình nên luôn có ba phần:

  1. Mô tả nhiệm vụ cụ thể.
  2. Cho tác nhân thu thập ngữ cảnh và thực thi.
  3. Yêu cầu bằng chứng khách quan: test, build, log hoặc HTTP response.

Giao nhiệm vụ có thể kiểm thử

Tránh prompt chung chung như:

Cải thiện mô-đun xác thực.

Thay vào đó, cung cấp lỗi, phạm vi và tiêu chí hoàn thành:

Endpoint /login trả về HTTP 500 khi trường password rỗng.

Hãy:
1. Tái tạo lỗi.
2. Xác định nguyên nhân gốc.
3. Sửa lỗi theo quy ước hiện có của dự án.
4. Thêm test cho trường hợp password rỗng.
5. Chạy toàn bộ test liên quan.
6. Tóm tắt các tệp đã thay đổi và kết quả test.
Enter fullscreen mode Exit fullscreen mode

Một prompt tốt nên trả lời được các câu hỏi:

  • Lỗi hoặc yêu cầu chính xác là gì?
  • Phạm vi code nào có thể bị ảnh hưởng?
  • Điều kiện hoàn thành là gì?
  • Những kiểm thử nào phải chạy?
  • Có ràng buộc nào về API, tương thích ngược hoặc bảo mật không?

Ngữ cảnh 1M token của K3 giúp việc làm việc với toàn bộ repository trở nên thực tế hơn. Tác nhân có thể theo dõi luồng gọi từ route handler qua service layer mà không yêu cầu bạn chỉ định thủ công từng tệp.

Cho phép tác nhân dùng công cụ và đọc phản hồi

Trong Kimi Code, K3 có thể chạy shell command, tìm kiếm codebase, build dự án, khởi động dịch vụ và chạy test. Vòng lặp tiêu chuẩn là:

  1. Đọc các tệp liên quan.
  2. Hình thành giả thuyết về nguyên nhân lỗi.
  3. Chỉnh sửa mã.
  4. Chạy test hoặc khởi động ứng dụng.
  5. Đọc lỗi, log hoặc stack trace.
  6. Điều chỉnh giải pháp.
  7. Lặp lại đến khi kiểm tra thành công.

Ví dụ prompt cho lỗi backend:

Kiểm tra lỗi timeout khi POST /orders với payload lớn.

Yêu cầu:
- Tái tạo lỗi bằng test hoặc request cục bộ.
- Theo dõi request từ route đến service và database layer.
- Không thay đổi public API nếu không cần thiết.
- Thêm regression test.
- Chạy test module liên quan.
- Báo cáo nguyên nhân gốc, thay đổi và kết quả xác minh.
Enter fullscreen mode Exit fullscreen mode

Điểm quan trọng: đừng yêu cầu mô hình “đúng ngay lần đầu”. Hãy yêu cầu nó quan sát, kiểm tra và sửa lại như một kỹ sư đang làm việc trong repository.

Lặp lại dựa trên ảnh chụp màn hình và đầu ra thời gian chạy

Phản hồi không chỉ là text.

Với frontend, bạn có thể yêu cầu tác nhân:

Cập nhật form đăng nhập để hiển thị lỗi validation dưới từng trường.

Tiêu chí:
- Không thay đổi layout trên màn hình desktop.
- Password rỗng phải hiển thị thông báo rõ ràng.
- Chụp ảnh màn hình sau khi render.
- Điều chỉnh CSS nếu thông báo bị tràn hoặc lệch.
Enter fullscreen mode Exit fullscreen mode

Vòng lặp UI thường là:

  1. Chỉnh sửa HTML/CSS/JS.
  2. Render giao diện.
  3. Chụp ảnh màn hình.
  4. Kiểm tra hiển thị.
  5. Điều chỉnh và lặp lại.

Với backend, phản hồi tương ứng là:

  • Test report.
  • Application log.
  • Stack trace.
  • HTTP response.
  • Database error.
  • Metrics hoặc trace cục bộ.

Giữ vòng lặp đáng tin cậy bằng kiểm thử

Test là tiêu chí “xong” rõ ràng nhất cho một tác nhân.

Trước khi giao tác vụ, hãy xác định:

  • Test hiện có nào cần chạy.
  • Test mới nào phải được thêm.
  • Những hành vi không được regression.
  • Lệnh build hoặc lint nào là bắt buộc.

Ví dụ:

Trước khi hoàn tất:
- Chạy unit test của auth module.
- Chạy lint cho các tệp đã sửa.
- Thêm test regression cho password rỗng.
- Không bỏ qua test hoặc xóa assertion để làm test xanh.
Enter fullscreen mode Exit fullscreen mode

Nếu không có test, vòng lặp tự động có thể đi lệch hướng và gây lỗi ở module khác mà không phát hiện.

Kimi K3 so với Claude Code và Cursor

Dưới đây là so sánh thực tế giữa ba cách chạy tác nhân trên codebase vào giữa năm 2026.

Tiêu chí Kimi Code (Kimi K3) Claude Code (Fable 5) Cursor
Yếu tố hình thức Tác nhân lập trình terminal và IDE Tác nhân lập trình terminal Trình chỉnh sửa mã AI-native
Mô hình mặc định Kimi K3, chuyển qua /model Claude Fable 5 và các mô hình Claude khác Tự mang mô hình hoặc dùng mô hình tích hợp
Cửa sổ ngữ cảnh 1M token Lớn, tùy mô hình Tùy mô hình
Điều hướng repository Mạnh, hướng tới tác vụ quy mô lớn và dài hạn Mạnh, có quyền truy cập tệp và shell theo tác nhân Lập chỉ mục và truy xuất mạnh trong editor
Sử dụng công cụ Tool calling, shell, test, ảnh chụp màn hình Tool calling, shell, MCP Công cụ editor, terminal, MCP
Đòn bẩy chi phí Có lợi cho vòng lặp cache-heavy với cache hit 90%+ Tính phí theo token Claude Đăng ký cộng chi phí sử dụng mô hình
Trọng số mở Dự kiến khoảng 27 tháng 7 năm 2026 Đóng Editor độc quyền, mô hình đa dạng
Phù hợp nhất Tác vụ agent dài, repository lớn, tối ưu chi phí Suy luận và độ tin cậy hàng đầu Developer muốn agent hoạt động trong editor

Một số lựa chọn thực tế:

  • Nếu ưu tiên độ tin cậy thô cho tác vụ khó, Fable 5 trong Claude Code là lựa chọn Moonshot cũng thừa nhận vượt K3.
  • Nếu muốn agent tích hợp sâu trong editor, Cursor hoặc Cline thường phù hợp hơn.
  • Nếu cần chạy mô hình mở trong các môi trường này, xem hướng dẫn GLM-5.2 trong Claude Code, Cline và Cursor.
  • Nếu cần xử lý repository lớn với vòng lặp dài và quan tâm đến chi phí, K3 có lợi thế nhờ context 1M token và cơ chế cache.

Điểm mạnh và hạn chế thực tế

K3 giỏi về điều gì?

Ngữ cảnh quy mô repository.

Cửa sổ 1M token giúp tác nhân giữ nhiều phần của codebase trong cùng một phiên, đặc biệt hữu ích với monorepo hoặc thay đổi xuyên nhiều package.

Sử dụng công cụ và tự chủ dài hạn.

K3 được điều chỉnh để duy trì phiên kỹ thuật kéo dài, chạy terminal command, đọc output và tự điều chỉnh theo phản hồi.

Chi phí trong vòng lặp nặng bộ nhớ đệm.

Lập trình tác nhân thường gửi lại cùng ngữ cảnh ở mỗi bước: cấu trúc tệp, system instruction và lịch sử nhiệm vụ. Giá input cache hit của K3 là 0,30 USD cho mỗi triệu token, so với 3,00 USD khi cache miss — chênh lệch 10 lần. Mooncake inference của Moonshot được báo cáo đạt cache hit trên 90% trong tác vụ lập trình. Xem phân tích giá Kimi K3 để biết thêm số liệu.

Những hạn chế của K3

Không phải mô hình dẫn đầu tuyệt đối.

Moonshot cho biết K3 vẫn kém các mô hình độc quyền mạnh nhất như Claude Fable 5 và GPT-5.6 Sol. Theo các benchmark Moonshot công bố:

  • Terminal Bench 2.1: K3 đạt 88.3, GPT-5.6 Sol đạt 88.8.
  • DeepSWE: K3 đạt 67.5, Fable 5 đạt 70.0, GPT-5.6 Sol đạt 73.0.

Kết quả cạnh tranh, nhưng K3 không đứng đầu. Xem phân tích benchmark Kimi K3 để xem chi tiết.

Không phải lựa chọn nhanh nhất.

Theo Artificial Analysis, K3 tạo khoảng 62 token/giây, thấp hơn trung bình trong phân khúc giá của nó. Nếu cần phản hồi tương tác nhanh, hãy benchmark thêm mô hình khác trên chính tác vụ của bạn.

Khả năng “mở” vẫn phụ thuộc lịch phát hành.

Trọng số đầy đủ dự kiến vào khoảng ngày 27 tháng 7 năm 2026, không phải ngày ra mắt. Nếu chiến lược của bạn phụ thuộc vào self-hosting, đây là mốc cần theo dõi.

Để so sánh trực tiếp, xem:

Các trường hợp sử dụng thực tế

K3 phù hợp nhất khi nhiệm vụ có nhiều bước, cần đọc nhiều ngữ cảnh và có tín hiệu xác minh rõ ràng.

Refactor lớn trong monorepo

Ví dụ:

Tách module billing khỏi package monolith hiện tại.

Yêu cầu:
- Xác định toàn bộ import và dependency liên quan.
- Không thay đổi API công khai.
- Cập nhật test, build config và tài liệu nội bộ nếu cần.
- Chạy build và test cho tất cả package bị ảnh hưởng.
- Liệt kê các thay đổi có rủi ro cần review thủ công.
Enter fullscreen mode Exit fullscreen mode

Gỡ lỗi kéo dài

Có memory leak khi worker xử lý queue chạy liên tục hơn 30 phút.

Hãy:
- Tìm code khởi tạo worker và lifecycle cleanup.
- Kiểm tra timer, event listener, connection và cache.
- Tái tạo bằng test hoặc script tối thiểu nếu khả thi.
- Đề xuất và triển khai bản vá nhỏ nhất.
- Đưa ra bằng chứng từ test, log hoặc profiling output.
Enter fullscreen mode Exit fullscreen mode

Xây dựng API có kiểm chứng

K3 có thể tạo handler, route, validation và test. Nhưng sau khi test code chạy xanh, bạn vẫn nên xác minh API như một client thực.

Xác minh API mà K3 xây dựng

Unit test xác nhận mã có chạy. Tuy nhiên, chúng không luôn đảm bảo endpoint hoạt động đúng theo kỳ vọng của client:

  • Status code có đúng không?
  • Response body có đúng schema không?
  • Header có đầy đủ không?
  • Token không hợp lệ có bị từ chối không?
  • Payload sai có trả lỗi validation nhất quán không?

Đây là lúc Apidog hữu ích. Sau khi K3 tạo hoặc chỉnh sửa API, hãy gửi request thực đến endpoint và thêm assertion cho status code, header và JSON body.

Ví dụ checklist kiểm thử endpoint /login:

POST /login

Kiểm tra:
- Password rỗng trả về lỗi validation, không phải HTTP 500.
- Sai mật khẩu trả về status code phù hợp.
- Response không chứa dữ liệu nhạy cảm.
- Token hợp lệ được trả về theo schema đã định nghĩa.
- Header Content-Type đúng.
Enter fullscreen mode Exit fullscreen mode

Nếu tác nhân tạo OpenAPI spec, hãy import spec vào Apidog để tạo request collection và kiểm thử theo contract thay vì kiểm tra thủ công.

Khi làm việc với môi trường chia sẻ:

  • Lưu secret trong biến môi trường của Apidog.
  • Không hard-code token vào collection.
  • Không commit API key vào repository.
  • Tách biến môi trường local, staging và production.

Apidog cũng cung cấp giao diện MCP, giúp kết nối công cụ API vào ngữ cảnh tác nhân. Xem hướng dẫn gỡ lỗi trực quan bằng client MCP của ApidogApidog trong VS Code để giữ vòng lặp kiểm thử gần với code mà K3 viết. Bạn có thể tải Apidog để kiểm tra đầu ra API ngay khi được tạo.

Bạn sẽ nhận được gì?

Kimi K3 trong Kimi Code là lựa chọn thực tế cho các repository lớn, vòng lặp tự động dài và tác vụ cần lặp lại theo test, log hoặc ảnh chụp màn hình. Context 1M token và mô hình chi phí dựa trên cache giúp nó phù hợp với công việc nhiều bước mà các mô hình tính token khác có thể trở nên đắt đỏ.

Để bắt đầu hiệu quả:

  1. Khởi chạy Kimi Code tại thư mục gốc của repository.
  2. Chọn K3 bằng /model kimi-k3.
  3. Giao một nhiệm vụ có thể kiểm thử.
  4. Yêu cầu tác nhân chạy test, build hoặc request thật.
  5. Review diff trước khi merge.
  6. Xác minh API bằng Apidog trước khi triển khai.

Các câu hỏi thường gặp

Làm cách nào để sử dụng Kimi K3 để lập trình?

Chạy K3 trong Kimi Code, tác nhân lập trình terminal và IDE của Moonshot. Cài đặt tác nhân, mở nó trong thư mục dự án, chọn mô hình bằng:

/model kimi-k3
Enter fullscreen mode Exit fullscreen mode

Sau đó giao một nhiệm vụ cụ thể, có thể kiểm thử. Để tác nhân đọc tệp, chạy công cụ, thực thi test và lặp lại dựa trên kết quả. Xem hướng dẫn CLI của Kimi Code để cài đặt.

Kimi K3 có tốt cho lập trình tác nhân không?

Có. K3 được điều chỉnh cho việc điều hướng repository lớn, dùng công cụ, gỡ lỗi và lặp lại dựa trên test, log và phản hồi thời gian chạy trong context 1M token. Nó cạnh tranh trên benchmark lập trình, dù vẫn kém Fable 5 và GPT-5.6 Sol ở một số chỉ số.

Kimi K3 có hỗ trợ gọi công cụ cho quy trình tác nhân không?

Có. K3 API hỗ trợ tool calling, ràng buộc lựa chọn công cụ, JSON mode, structured output, tìm kiếm internet, tải công cụ động và nỗ lực suy luận có thể cấu hình. Những khả năng này cho phép tác nhân chạy test, thực thi shell command và điều phối vòng lặp kỹ thuật trong Kimi Code. Xem hướng dẫn API Kimi K3 để biết chi tiết.

Tôi có thể kiểm thử API mà Kimi K3 viết không?

Có, và nên làm như vậy. Test của tác nhân chỉ xác nhận code chạy; chúng không luôn xác nhận endpoint trả đúng status code, schema phản hồi và hành vi xác thực như client thực mong đợi. Hãy gửi request thật trong Apidog, thêm assertion và import OpenAPI spec do tác nhân tạo để xác thực theo contract.

Top comments (0)