Giới thiệu

Trong tuần trước, chúng tôi đã giới thiệu cách mà một agent hiểu một codebase và xây dựng một agent thực tế để minh họa cơ chế hoạt động. Trong quá trình này, chúng tôi đã nêu bật một số giới hạn hiện tại của Kiro. Ví dụ, ngay cả với một tệp design.md chi tiết, Kiro thường xuyên lệch khỏi kế hoạch trong quá trình thực thi, dẫn đến những kết quả khác biệt đáng kể so với thiết kế ban đầu.

Vấn đề nằm ở quá trình thực thi của Kiro, nơi mà nó sử dụng design.md làm ngữ cảnh nhưng không đọc toàn bộ tệp. Vấn đề này trở nên nghiêm trọng hơn khi nội dung điều khiển quá dài, vì agent có xu hướng bảo vệ cửa sổ ngữ cảnh của mình. Do đó, nó có thể chỉ đọc vài dòng đầu tiên của một tệp và coi như đã xử lý xong.

Điều này có nghĩa là khi Kiro thực thi các kế hoạch, chúng ta vẫn cần phải nhắc nhở nó liên tục để không lệch khỏi thiết kế. Điều này không chỉ lãng phí nhiều quota yêu cầu vibe mà còn làm giảm hiệu suất phát triển tổng thể. Sau tất cả, chúng ta cần xem xét từng chi tiết một cách cẩn thận hơn.

Vấn đề là Kiro là một sản phẩm mã nguồn đóng, vì vậy chúng ta không thể tinh chỉnh các prompt của nó. Chúng ta chỉ còn cách nhìn chu kỳ này lặp đi lặp lại. Vì vậy, tôi đã tự hỏi liệu có cách nào để sử dụng các prompt để khiến các công cụ như Copilot hay Claude Code thực hiện các quy trình giống như Kiro mà vẫn cho phép điều chỉnh từng chi tiết thực thi.

Sau khi thử nghiệm thực tế, hóa ra nó hoạt động hiệu quả.

GitHub Kiro Workflow Prompts

Mặc dù dự án này được viết theo định dạng của Copilot, nhưng nó có thể được áp dụng cho bất kỳ agent nào, bao gồm cả Claude Code. Tuy nhiên, vì tôi đang sử dụng Copilot, tôi sẽ minh họa quy trình thực tế của nó.

Cài đặt

Việc cài đặt rất đơn giản, chỉ cần đặt các tệp prompt này vào thư mục dự án hoặc một thư mục global prompts để sử dụng trực tiếp trong cửa sổ chat của Copilot.

Tất cả các tệp prompt đều được giải thích chi tiết trong tệp README.md. Bài viết này sẽ tập trung vào cách sử dụng chúng.

Phát triển Dựa trên Đặc tả của Copilot

Lúc đầu, giống như chế độ đặc tả của Kiro, chúng ta cần yêu cầu Copilot tạo một thư mục đặc tả và chuyển đổi yêu cầu của chúng ta thành một tài liệu đặc tả EARS.

/createSpec
Tôi muốn xây dựng một dịch vụ web với xác thực OAuth, tích hợp Google OAuth và cần một cơ sở dữ liệu để lưu trữ thông tin người dùng.

Bằng cách chạy lệnh /createSpec với những yêu cầu này, Agent bắt đầu chuẩn bị tệp requirements.md. Nếu có tài liệu nào dưới thư mục .kiro/steering cung cấp hướng dẫn hành vi cho Agent, nó cũng sẽ tham chiếu đến các nội dung đó.

Trong suốt quá trình tạo yêu cầu, chúng ta có thể tương tác liên tục với Agent để tinh chỉnh chi tiết của toàn bộ tài liệu yêu cầu.

Một quan sát thú vị, tôi nhận thấy Kiro có xu hướng làm quá mọi thứ, thêm một số chi tiết không cần thiết. Vì vậy, tôi đã sử dụng các hướng dẫn hệ thống để làm cho Agent của chúng ta thực tế hơn như Linus Torvalds, tuân thủ nguyên tắc KISS (Keep It Simple, Stupid).

Khi chúng ta có tệp requirements.md, chúng ta chuyển sang giai đoạn thiết kế.

/design
Tôi phê duyệt tài liệu yêu cầu. Hãy bắt đầu giai đoạn thiết kế.

Giai đoạn thiết kế không cần phải có prompt, như Kiro đã chứng minh. Chúng ta chỉ cần phê duyệt requirements.md, sau đó Agent sẽ tự động khởi động quá trình thiết kế. Tất nhiên, Agent vẫn sẽ tham chiếu các tài liệu điều khiển để hướng dẫn thiết kế, và chúng ta có thể tiếp tục tinh chỉnh quá trình này.

Sau khi hoàn thành thiết kế, Agent sẽ tạo ra tệp design.md tương ứng, cho phép chúng ta tiến tới bước tiếp theo, giai đoạn lập kế hoạch.

/createTask
Tôi phê duyệt tài liệu thiết kế. Hãy bắt đầu lập kế hoạch.

Tại đây, sự phê duyệt rõ ràng vẫn cần thiết; nếu không, Agent sẽ không tiến hành.

Sau giai đoạn này, chúng ta sẽ có ba đặc tả quan trọng nhất: requirements.md, design.md và tasks.md. Thú vị thay, các đầu ra này hoàn toàn tuân theo quy tắc của Kiro. Do đó, việc quay lại Kiro để thực hiện các nhiệm vụ từ giai đoạn này không thành vấn đề.

Sau khi phê duyệt tasks.md, bước cuối cùng là vào giai đoạn thực thi.

/executeTask task1

Bạn có thể chỉ định rõ ràng nhiệm vụ nào để bắt đầu, hoặc bỏ qua số nhiệm vụ hoàn toàn. Trong trường hợp đó, Agent sẽ cố gắng bắt đầu với nhiệm vụ chưa hoàn thành đầu tiên.

Quy trình này hoàn tất khi toàn bộ tệp tasks.md được đánh dấu là hoàn thành. Chúng ta có thể thấy rằng quy trình này về cơ bản giống như quy trình của Kiro.

Kết luận

Trong các prompt này, tôi đã yêu cầu rõ ràng rằng tất cả các tài liệu phải được xem xét kỹ lưỡng trước khi tiến hành. Tuy nhiên, các bước trước đó không cần phải tỉ mỉ như vậy, vì con người sẽ hợp tác với Agent để đồng tạo ra những tài liệu đặc tả đó.

Tuy nhiên, /executeTask hoạt động trong chế độ thực thi headless, vì vậy chúng ta bắt buộc phải đảm bảo rằng Agent hiểu được mục đích của nó. Do đó, trong prompt executeTask, tôi không chỉ yêu cầu nó xem xét tất cả các tệp mà còn yêu cầu nó tóm tắt từng tệp. Chỉ bằng cách yêu cầu tóm tắt, chúng ta mới có thể thực thi đủ nghiêm ngặt để đảm bảo Agent thực sự đọc mọi thứ một cách cẩn thận.

Khám phá này xuất hiện trong quá trình triển khai agent codebase của tôi. Lợi ích lớn nhất của quy trình này là chúng ta có thể đạt được kết quả tương tự như Kiro, hoặc thậm chí tốt hơn. Bằng cách sử dụng các công cụ mà chúng ta quen thuộc (và đã trả tiền), chúng ta có thể tùy chỉnh các prompt để đáp ứng nhu cầu cụ thể. Giống như tôi đã yêu cầu agent đọc kỹ các tệp, có rất nhiều không gian để điều chỉnh, cho phép chúng ta khai thác tối đa sự sáng tạo của mình.

Nếu bạn có bất kỳ ý tưởng nào hay, hãy cảm thấy tự do để đóng góp vào dự án của tôi. Hiện tại, tôi đã điều chỉnh các prompt dựa trên thói quen và nhu cầu của riêng mình, nhưng bạn có thể có những hiểu biết sâu sắc hơn để chia sẻ.