Lập trình Vibe với AI và Arduino

| Created: Tháng Năm 30, 2025

Lập trình vibe đã trở thành một từ khóa phổ biến trong lĩnh vực AI và gần đây nó đã được hiểu theo nhiều nghĩa khác nhau. Trong bài viết này, chúng tôi sẽ chỉ cho bạn cách lập trình vibe hoạt động với phần cứng thực tế được kết nối với AI Agent của bạn. Để tránh nhầm lẫn, chúng tôi sẽ định nghĩa lập trình vibe là “trò chuyện qua lại với AI agent của bạn để đạt được kết quả mong muốn nhất định.” Thông thường, điều này được thực hiện hoàn toàn bằng giọng nói nhưng cho mục đích của bài viết này, chúng tôi sẽ in ra lời nhắc “được nói” đưa cho mô hình ngôn ngữ lớn (LLM). Chúng tôi sẽ sử dụng Visual Studio Code với Copilot ở chế độ Agent và cắm một Arduino Uno R4 vào cổng USB của máy tính (được kết nối với một MacBook trong trường hợp này).

Bắt đầu

Giống như bất kỳ con người nào bắt đầu một dự án, việc bắt đầu với AI agent của chúng ta với bối cảnh phù hợp là rất quan trọng. Trong ảnh chụp màn hình này, bạn sẽ thấy rằng tôi có Visual Studio Code đang chạy với Copilot ngay ở trung tâm của màn hình.

Figure 1: Screenshot of initial discussion with Copilot Agent — *Hình 1: Ảnh chụp màn hình của cuộc thảo luận ban đầu với Đại lý Copilot*

Lưu ý lời nhắc ban đầu: “Tôi đã kết nối Arduino Uno R4 với MacBook ở đây. Sử dụng arduino-cli, tôi cần bạn giao tiếp và xác nhận rằng một Arduino đã được kết nối.” Tôi đã in đậm một số từ khóa quan trọng cần lưu ý. Hãy chia nó thành hai phần.

Tôi có một Arduino Uno R4 kết nối với MacBook ở đây: Tôi bắt đầu bằng cách nói rõ với LLM chính xác thiết bị mà tôi đang sử dụng, rằng nó đã được kết nối “ở đây”, và tôi đang sử dụng MacBook. Có thể nó đã biết tôi đang chạy trên MacOS nhưng việc cung cấp thêm ngữ cảnh không bao giờ là thừa. Ngay cả khi nó có thể lấy ngữ cảnh đó từ môi trường, có lẽ sẽ cần một lần tra cứu khác—điều này có thể tránh được. Đây là những thông tin quan trọng để bắt đầu.

Sử dụng arduino-cli, tôi cần bạn giao tiếp và xác nhận rằng một Arduino đã được kết nối: Tôi đang đưa ra hướng dẫn cụ thể về công cụ/lệnh nào để sử dụng (gói arduino-cli được cài đặt bằng cách sử dụng brew). Điều này, một lần nữa, tạo ra một lối tắt tránh ít nhất (nếu không phải nhiều) việc tìm kiếm/gọi để xác định công cụ nào để sử dụng. Tôi cũng hoài nghi liệu công cụ có thể tự cấu hình đúng cách nếu được giao toàn bộ nhiệm vụ nên tôi yêu cầu nó xác nhận rằng nó có thể giao tiếp với Arduino. Điều này có vẻ như không quan trọng nhưng thực sự rất hữu ích để tách biệt khỏi nhiệm vụ thực tế để chúng ta có thể đảm bảo mọi thứ đều ổn trước khi bắt đầu viết mã.

Phản hồi của nó là ngay lập tức chạy lệnh arduino-cli (bằng cách đầu tiên tìm kiếm vị trí) để đảm bảo mọi thứ liên quan đến công cụ Arduino và giao tiếp với bảng mạch được cấu hình đúng cách. Một khi tôi xác nhận mọi thứ đều hoạt động tốt, tôi sẵn sàng đưa ra bộ hướng dẫn tiếp theo nhưng nó chặn trước tôi bằng cách tạo một bản phác thảo cơ bản và đảm bảo rằng nó có thể tải lên một chương trình cơ bản vào thiết bị:

Figure 2: Copilot attempting to create, compile, and upload a new sketch — *Hình 2: Copilot cố gắng tạo, biên dịch và tải lên một bản phác thảo mới*

Như bạn có thể thấy trong bản ghi, có một số vấn đề mà Copilot Agent gặp phải. Đừng lo lắng - một trong những điểm đẹp của quy trình làm việc theo hướng đại lý là nó có thể "tự chữa lành" bằng cách xem xét đầu ra lỗi và tự sửa chữa. Cuối cùng, nó đã làm được và tải lên thành công bản sketch đã biên dịch cho thiết bị Arduino Uno R4.

Vibe Coding with Feedback

Khi nói đến việc lập trình vibe chung cho các ứng dụng web, việc nhận phản hồi từ đại lý khá dễ dàng. Giả sử đại lý có quyền truy cập vào dòng lệnh (điều này đúng trong trường hợp của chúng tôi), nó có thể yêu cầu ứng dụng cung cấp phản hồi sau khi script hoàn thành. Lấy một ví dụ đơn giản khi chúng ta yêu cầu đại lý của chúng ta viết một ứng dụng đọc một tệp CSV, chuyển đổi nội dung thành một bảng markdown, và sau đó ghi nội dung vào một tệp .md. Có một vài cách để xác nhận rằng script đã hoạt động. Cách tiếp cận phổ biến nhất có thể là viết các bài kiểm tra (điều mà đại lý có thể dễ dàng thực hiện) hoặc đại lý chỉ cần kiểm tra sự tồn tại của tệp mới và xem xét nội dung của tệp. Một ứng dụng web với giao diện người dùng cũng có thể hoạt động theo cách tương tự. Đại lý có thể thực hiện một thao tác curl trên trang web và đọc nội dung HTML. Trong một ví dụ khi chúng ta chỉ viết một backend web, chúng ta có thể yêu cầu đại lý viết các bài kiểm tra hoặc cũng thực hiện các yêu cầu curl và kiểm tra các mã phản hồi, văn bản nội dung, v.v.

Khi nói đến Hệ thống Nhúng, việc xác nhận (đặc biệt là trong quá trình khởi động bảng mạch) thường được thực hiện một cách trực quan hoặc thông qua một loạt các kiểm tra thủ công. Hãy xem xét cách thức xác nhận cơ bản nhất là kiểm tra một ví dụ về đèn LED nhấp nháy bằng cách nhìn trực tiếp vào đèn LED và xác minh rằng nó đang nhấp nháy. Việc đưa tín hiệu vào một ADC và quan sát dữ liệu telemetri phát ra thường không được lập trình tự động ngay từ đầu - điều này thường được thực hiện sau khi chúng ta đã viết các bài kiểm tra tự động. Khi lập trình với một quy trình làm việc có tính chất đại lý cho hệ thống nhúng, chúng ta cần tích hợp telemetri như một cơ chế phản hồi. Đại lý sẽ không biết mã có hoạt động hay không vì nó không thể nhìn thấy đèn LED (ít nhất là với công nghệ đại lý hiện nay). Đây là lúc quan trọng cần nhấn mạnh rằng nó tạo ra thứ gì đó mà chúng ta có thể đọc qua dòng lệnh và xác nhận nó:

Figure 3: Request to create an example with telemetry and validation — *Hình 3: Yêu cầu tạo một ví dụ với telemetry và xác thực*

Tại điểm này, nó tạo ra một ví dụ không chỉ bật đèn LED mà còn cung cấp telemetri qua đầu ra nối tiếp với thông báo “LED_ON” và “LED_OFF.” Nó tự động biết cách lấy những phản hồi này cũng như:

Figure 4: Telemetry over serial but with open-ended process — *Hình 4: Telemetry qua cổng nối tiếp nhưng với quy trình mở*

Một vấn đề phổ biến với loại yêu cầu này (cũng được tìm thấy với các yêu cầu lệnh “SSH”) là quá trình sẽ không bao giờ kết thúc sau khi đại lý phát lệnh trong terminal. Bộ giám sát CLI của Arduino sẽ chạy vô thời hạn, nghĩa là đại lý sẽ bị treo mãi mãi. Rất hợp lý khi giả định rằng một loại hình thời gian chờ nào đó sẽ được giới thiệu vào các đại lý trong các bản cập nhật tương lai nhưng trong ví dụ này, với quy trình làm việc này, điều đó không tồn tại. Tôi phải thông báo cho đại lý rằng terminal của nó đã bị treo và nó cần phải tính đến điều đó:

Figure 5: Fix for hung terminal — *Hình 5: Sửa lỗi cho terminal bị treo*

Và như vậy lệnh đã được sửa và đại lý giờ đây có thể tiếp tục lặp lại với những ví dụ mã phức tạp hơn. Đến thời điểm này, chúng ta đã thiết lập một cách để đại lý không chỉ nhận phản hồi về việc mã đã được biên dịch và tải lên mà còn rằng nó đã chạy đúng trên thiết bị mục tiêu.

Kết luận

Bắt đầu với việc lập trình vibe cho một hệ thống nhúng có thể có vẻ không trực quan và đôi khi thậm chí là “phép thuật đen”. Chìa khóa để có một phiên lập trình vibe thành công với một đại lý và thiết bị nhúng của bạn là đảm bảo rằng đại lý luôn nhận được phản hồi đủ. Không chỉ cần biết rằng mã được biên dịch/tải lên mà còn phải đảm bảo rằng nó hoạt động chính xác trên thiết bị mục tiêu nữa. Mặc dù một số ví dụ này có vẻ cơ bản nhưng chúng là nền tảng cho sự phát triển phức tạp, tinh vi hơn với AI trong vòng lặp và phần cứng trong vòng lặp. Vũ khí với những ví dụ và hướng dẫn này, bạn giờ đây nên có thể bắt đầu viết, biên dịch và chạy mã nhúng được tạo ra bởi AI mà không cần phải động tay chân.

About Author

Ari is an engineer with broad experience in designing, manufacturing, testing, and integrating electrical, mechanical, and software systems. He is passionate about bringing design, verification, and test engineers together to work as a cohesive unit.