Ưu điểm của Spec Kit của GitHub là có thể dùng ngay cả trong GitHub Copilot.
Vì do GitHub tạo ra nên có lẽ là điều hiển nhiên? nhưng trước giờ nhiều công cụ khác lại dựa trên Claude.

Tự nhiên tôi chợt nghĩ làm như vậy thì có lẽ cũng áp dụng được cho tiếng Hàn... chắc là có thể tạo ra câu đố nhỉ...

Tôi sẽ chỉ dùng tốt cho mục đích sàng lọc thôi

Trong trường hợp đặt lệnh giao dịch, có vẻ như lệnh ngoài ý muốn có thể được xử lý do prompt injection và các yếu tố tương tự, nên có lẽ các tính năng bổ sung như giới hạn đối tượng đặt lệnh hoặc hạn mức số tiền là điều bắt buộc.

Xin lỗi;;

Làm tôi nhớ đến Kiro IDE.

Cảm ơn bạn.

Vâng, tôi cũng nghĩ vậy. T_T

Tôi đã xem thí nghiệm này rất thú vị.

Chắc học ở lò luyện đặt tiêu đề rồi nhỉ..

Vì mạng xã hội là một sự lãng phí thời gian, nên cảm giác đúng hơn là kiểu 'hối hận' hay 'xấu hổ' giống như cờ bạc hoặc ma túy.

Thú vị đấy. Nghe cũng có lý.

Có lẽ cũng vì tiêu đề nói là một dòng prompt duy nhất nên điều người ta muốn xem và nội dung bài viết lại khác nhau, nên cảm giác đó càng rõ hơn.

k9s - Công cụ quản lý cụm Kubernetes bằng giao diện người dùng terminal

Liên kết giới thiệu chi tiết về SDD ở giữa bài khá hay. Dưới đây là bản tôi thử tóm tắt bằng AI.

Phát triển hướng đặc tả (Specification-Driven Development, SDD)

Đảo ngược quyền lực

• Đảo ngược luồng mà trước đây code là trung tâm còn PRD·tài liệu thiết kế chỉ đóng vai trò phụ trợ: đặc tả là bản gốc, còn code là biểu hiện được triển khai bằng ngôn ngữ·framework cụ thể
  • Đưa ra nhận định rằng khoảng cách thường trực giữa đặc tả và triển khai rất khó được xóa bỏ chỉ bằng cách bổ sung tài liệu hay siết chặt quy trình
  • Nếu đặc tả có thể thực thi và kế hoạch triển khai tạo ra code thì khoảng cách đó biến mất, chỉ còn sự chuyển đổi
• AI giúp có thể diễn giải đặc tả phức tạp và lập kế hoạch triển khai, nhưng tạo sinh không có cấu trúc sẽ gây hỗn loạn, vì vậy SDD đảm bảo chất lượng bằng cấu trúc chính xác và guardrail
• Bảo trì là hành vi tiến hóa đặc tả; ý đồ phát triển được biểu đạt bằng ngôn ngữ tự nhiên·tài sản thiết kế·nguyên tắc cốt lõi, còn code giữ vai trò chặng cuối
• Debug ưu tiên sửa đặc tả·kế hoạch triển khai hơn là sửa code sai; refactoring được định nghĩa lại là tái cấu trúc sự rõ ràng

Quy trình làm việc SDD trong thực tế

• Mài giũa ý tưởng thành PRD thông qua tương tác hội thoại với AI, và AI sẽ cụ thể hóa câu hỏi·edge case·tiêu chí chấp nhận
  • Chuyển yêu cầu·thiết kế thành hoạt động liên tục, hỗ trợ làm việc đặc tả theo nhánh ở cấp độ nhóm cùng review·versioning
• Research agent khám phá khả năng tương thích thư viện, hiệu năng, bảo mật và ràng buộc tổ chức (chuẩn DB·xác thực·chính sách triển khai), rồi tự động phản ánh vào đặc tả
• Từ PRD tạo ra kế hoạch triển khai, ánh xạ có thể truy vết giữa yêu cầu và quyết định kỹ thuật, đồng thời AI liên tục kiểm chứng mâu thuẫn·mơ hồ·thiếu sót
• Khi đặc tả·kế hoạch đã đủ ổn định thì bắt đầu sinh code, nhưng ban đầu sẽ dùng tạo sinh mang tính thăm dò để kiểm chứng tính khả thi
  • Khái niệm miền được chuyển thành data model, user story thành API endpoint, kịch bản chấp nhận thành test
• Metric·incident ở giai đoạn vận hành sẽ cập nhật lại đặc tả để phản ánh vào lần tái tạo tiếp theo; nút thắt hiệu năng được nâng thành yêu cầu phi chức năng, lỗ hổng bảo mật thành ràng buộc toàn cục

Vì sao SDD quan trọng lúc này

• Ngưỡng năng lực AI: giờ đã có thể tạo code hoạt động một cách đáng tin cậy từ đặc tả ngôn ngữ tự nhiên, đồng thời tự động hóa phần cơ học của việc dịch triển khai để hỗ trợ khám phá·khuếch đại sáng tạo
• Độ phức tạp bùng nổ: với nhiều dịch vụ·framework·dependency, việc duy trì sự nhất quán giữa ý đồ và triển khai ngày càng khó, nên cần căn chỉnh theo đặc tả của SDD
• Thay đổi tăng tốc: trong bối cảnh pivot thường xuyên, SDD xử lý thay đổi bằng tái tạo có hệ thống thay vì lan truyền thủ công qua tài liệu-thiết kế-code
  • Ví dụ, nó cho phép mô phỏng what-if và triển khai song song để mang lại độ linh hoạt trong ra quyết định

Các nguyên tắc cốt lõi

• Đặc tả = ngôn ngữ chung: đặc tả là sản phẩm hạng nhất, code là biểu hiện của stack cụ thể, và bảo trì là hành vi tiến hóa đặc tả
• Đặc tả có thể thực thi: tạo ra hệ thống vận hành được từ đặc tả ở mức chính xác·đầy đủ·không mơ hồ
• Tinh chỉnh liên tục: thực hiện kiểm chứng tính nhất quán thường trực chứ không phải cổng kiểm duyệt một lần
• Ngữ cảnh dựa trên nghiên cứu: liên tục thu thập hiệu năng·bảo mật·ràng buộc tổ chức để đưa vào đặc tả
• Phản hồi hai chiều: thực tế vận hành trở thành đầu vào cập nhật đặc tả
• Phân nhánh để khám phá: hỗ trợ tạo nhiều cách triển khai từ cùng một đặc tả theo các mục tiêu tối ưu như hiệu năng·khả năng bảo trì·UX·chi phí

Các cách tiếp cận triển khai

• Việc áp dụng hiện nay cốt lõi là kết hợp công cụ sẵn có và duy trì kỷ luật, có thể triển khai bằng các thành phần sau
  • AI assistant để lặp lại quá trình tinh chỉnh đặc tả
  • Research agent để thu thập ngữ cảnh kỹ thuật
  • Công cụ sinh code để chuyển đổi đặc tả → triển khai
  • Quản lý phiên bản phù hợp với workflow đặc tả trước
  • Kiểm tra dựa trên phân tích tính nhất quán bằng AI cho tài liệu đặc tả
• Nguyên tắc chung là coi đặc tả là nguồn chân lý duy nhất, còn code là đầu ra mà đặc tả yêu cầu

Tinh gọn SDD bằng command

• /specify: chuyển mô tả tính năng thành đặc tả có cấu trúc, đồng thời tự động hóa đánh số tự động, tạo nhánh, và cấu trúc thư mục dựa trên template
• /plan: tạo chuỗi gồm phân tích đặc tả → rà soát tuân thủ hiến pháp → dịch kỹ thuật → tài liệu hóa data model·API contract·test scenario → xác minh quickstart
• /tasks: đọc plan.md và các thiết kế liên quan để tạo danh sách tác vụ có thể thực thi, đồng thời đánh dấu tác vụ có thể song song và nhóm song song an toàn
• Ví dụ: tính năng chat
  • Đưa ra ví dụ về luồng rút ngắn khoảng ~12 giờ làm tài liệu theo cách truyền thống xuống còn khoảng 15 phút thiết lập nhờ tự động hóa đặc tả·kế hoạch·tác vụ
  • Các đầu ra gồm đặc tả, kế hoạch triển khai và cơ sở lý giải, API contract·data model, kịch bản quickstart, tasks.md đều được quản lý phiên bản trên nhánh

Sức mạnh của tự động hóa có cấu trúc

• Ngăn thiếu sót: template bao quát cả yêu cầu phi chức năng·xử lý lỗi
• Khả năng truy vết quyết định: mọi lựa chọn kỹ thuật đều được gắn với yêu cầu cụ thể
• Tài liệu sống: vì đặc tả tạo ra code, nên việc duy trì đồng bộ trở nên dễ dàng
• Lặp nhanh: khi yêu cầu thay đổi, có thể phản ứng trong đơn vị phút·giờ bằng tái tạo kế hoạch

Chất lượng dựa trên template

• Ngăn chi tiết triển khai xâm nhập quá sớm: duy trì mức trừu tượng bằng quy tắc tập trung vào WHAT/WHY, loại bỏ HOW
• Buộc đánh dấu điểm chưa chắc chắn: marker [NEEDS CLARIFICATION] giúp cấm phỏng đoán và thúc đẩy câu hỏi tường minh
• Tự rà soát theo checklist: triển khai quality gate bằng cách kiểm tra độ đầy đủ·độ rõ ràng·tiêu chí chấp nhận đo lường được
• Cổng hiến pháp: áp dụng kiểm tra ở giai đoạn trước (-1) như cổng đơn giản hóa (≤3 project), cổng chống trừu tượng hóa quá mức (dùng trực tiếp framework), cổng ưu tiên tích hợp (hợp đồng·contract test đi trước)
• Quản lý chi tiết theo lớp: phần code·chi tiết quá mức được tách vào implementation-details/ để giữ khả năng đọc
• Ưu tiên test: đảm bảo khả năng kiểm chứng bằng quy tắc tạo file·ưu tiên test theo thứ tự contract → integration → E2E → unit
• Kiềm chế giả định·tính năng suy đoán: tăng cường quản lý phạm vi bằng việc cấm tính năng suy đoán và nêu rõ điều kiện tiên quyết theo từng giai đoạn

Nền tảng hiến pháp

• Áp dụng hiến pháp phát triển với các nguyên tắc bất biến trong memory/constitution.md để giữ mọi triển khai nhất quán·đơn giản·chất lượng cao
  • Article I: Library-First — mọi tính năng bắt đầu như một thư viện độc lập để đảm bảo tính mô-đun
  • Article II: CLI Mandate — mọi thư viện phải cung cấp giao diện CLI hỗ trợ văn bản vào/ra·JSON để đảm bảo khả năng quan sát và dễ kiểm thử
  • Article III: Test-First — cấm triển khai trước khi test được phê duyệt và xác nhận thất bại (red), áp dụng nguyên tắc định nghĩa hành vi trước
  • Articles VII & VIII: Đơn giản hóa·chống trừu tượng hóa quá mức — tối thiểu số lượng project và tin cậy trực tiếp vào framework để kiềm chế over-engineering
  • Article IX: Test ưu tiên tích hợp — ưu tiên test gần với môi trường thực, đồng thời buộc contract test đi trước triển khai
• Dùng cổng Phase -1 của template để biến việc tuân thủ hiến pháp thành checklist, còn ngoại lệ sẽ ghi cơ sở nêu rõ trong Complexity Tracking
• Thông qua quy trình sửa đổi, cách áp dụng các nguyên tắc có thể tiến hóa nhưng triết lý cốt lõi vẫn được giữ nguyên

Sự chuyển đổi

• Mục tiêu không phải thay thế lập trình viên mà là tự động hóa bản dịch mang tính cơ học để khuếch đại năng lực con người và duy trì tính nhất quán giữa ý đồ và triển khai
• SDD thực hành chuyển đổi liên tục bằng cách để đặc tả tạo ra code, từ đó đặc tả·nghiên cứu·code cùng tiến hóa trong vòng phản hồi chặt chẽ

Mã nguồn Big Brother bị rò rỉ!

Và bạn cũng đã hỏi về nội dung liên quan đến thí nghiệm về số lần liên kết prompt.

Thực ra, theo chiều ngược lại thì đây là một yếu tố rất dễ để tác giả, nói nôm na, "làm trò".

Bản thân việc phát triển đã có rất nhiều lựa chọn về hướng triển khai, và nếu cứ tích lũy prompt theo hướng khiến mức sử dụng token tăng mạnh hơn, thì con số đó sẽ phình to ra như quả cầu tuyết.

Trong nghiên cứu có một triết lý gọi là 'Cumulative Science'.

Ít nhất theo tiêu chuẩn của tôi, tôi vẫn chưa từng tìm thấy một nghiên cứu nào về mức sử dụng token cho một lệnh đơn lẻ,

nên thay vì lập tức nghiên cứu N lần, tôi tập trung vào việc xử lý bài kiểm thử và kết luận thật chắc chắn cho 1 lần,

còn nghiên cứu N lần thì có thể được tiếp nối sau thí nghiệm này.

Nếu học các ngành như kỹ thuật dân dụng thì ngay trong các môn ở đại học cũng đã dùng rồi.

Ngoài ra, trong một bài viết khác, tôi cũng từng đề cập đến sự khác biệt trong cách AI hoạt động tùy theo sự khác nhau của codebase.
(Chủ đề này cũng từng được giới thiệu trên GeekNews: https://modgo.org/aineun-hyeonjae-kodeu-gujoyi-byeoge-maghyeoissda/)

Nói ngắn gọn, bài viết đó bàn về các bài kiểm thử và kết quả cho thấy chất lượng đầu ra thay đổi tùy theo codebase được đưa vào cho AI.

Điều này có nghĩa là, tùy vào chất lượng và định hướng của codebase ban đầu, chất lượng mã được viết tiếp theo có thể được duy trì, hoặc cũng có thể tiếp tục xấu đi.

Tức là chi phí refactoring ở giai đoạn đầu của dự án và chi phí refactoring của một dự án đã tiến triển rất xa có thể khác nhau rất lớn.

Nếu người đặt câu hỏi là một lập trình viên, có lẽ bạn đã từng nghe câu "tàu sân bay trên thuyền buồm" ít nhất một lần.

Refactoring là một chủ đề sâu sắc mà chi phí có thể thay đổi khổng lồ tùy vào việc nên thực hiện ở thời điểm nào, hoặc tùy theo tư tưởng và thiết kế được áp vào ngay từ giai đoạn đầu của dự án.

Thay vì đưa biến số đó vào để khiến kết luận trở nên thiếu ổn định,

thì ở đây người ta đã tiến hành một bài kiểm thử có thể giải thích chắc chắn ít nhất ở mức: "À, nếu chất lượng codebase tốt thì lượng token sử dụng sẽ giảm."

Xin phép giải thích lại.

Người thực hiện vibe coding có phổ rất rộng, từ người không phải lập trình viên đến lập trình viên giàu kinh nghiệm. Tùy theo mức độ kiến thức họ đang có, chất lượng đầu ra có thể khác biệt một trời một vực, hoàn toàn không liên quan đến nội dung bài viết này.
Ai đó có thể tự nhiên vận hành theo tiền đề dùng Cursor, đưa các quy ước OOP cơ bản và quy tắc tách class/method vào .cursorrules, từ đó làm việc theo cách gần như không cần refactor thêm; nhưng
từ một ai khác, có thể đang xảy ra tình trạng sản sinh hàng loạt mã cấp thấp do thiếu khả năng nắm bắt những nội dung cốt lõi vốn quá cơ bản.

Thậm chí, trước đó đã có rất nhiều bài viết và trải nghiệm nhấn mạnh rằng về cơ bản cần duy trì chất lượng code tốt thông qua thiết lập rule cho project.

• Giữ kích thước file nhỏ: https://medium.com/realworld-ai-use-cases/…
• Cách giữ tốc độ chạy của codebase luôn nhanh: https://forum.cursor.com/t/…
• Best practice và guideline cho Windsurf: https://gist.github.com/muratkeremozcan/…

Điều này gợi ý khả năng rằng có những người đang hưởng lợi về mặt mức sử dụng token ngay cả khi không refactor một cách tường minh.

Tuy nhiên, các trường hợp trên không tổng hợp rõ ràng mức giảm sử dụng token theo từng đơn vị thực thi thông qua việc định nghĩa các rule đó. Vì vậy, bài viết này kiểm thử sự khác biệt về mức sử dụng token tùy theo chất lượng codebase và tổng hợp lại kết quả.

Nói cách khác, tùy theo người dùng, số lần refactor tường minh bản thân nó lại trở thành một biến số từ 0 đến n lần,

và có lẽ nên hiểu rằng ý định cốt lõi của bài viết này là giải thích cho câu hỏi: “Vì sao nên quan tâm đến một codebase có chất lượng tốt?”