Đả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ẽ
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ó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."
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.
Đ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?”
Tôi không hiểu rõ lắm ý anh/chị đang nói trong phần bình luận. Ý của tôi là nếu muốn so sánh công bằng hai phương pháp thì chẳng phải nên so sánh tổng số token tiêu thụ hay sao? Việc refactoring chẳng phải cũng tiêu tốn token sao?
Ngoài ra, những gì anh/chị trả lời dường như cũng không được viết trong bài, và có vẻ cũng là nội dung chưa được thực nghiệm. Có vẻ ý anh/chị là không nên so sánh token cho mỗi lần truy vấn, mà khi truy vấn nhiều lần thì overhead của refactoring sẽ giảm xuống, đồng thời số token kỳ vọng cho mỗi truy vấn cũng giảm nên tổng số token sẽ có lợi hơn. Nhưng điều đó có lẽ chỉ đúng khi chi phí giảm vẫn được duy trì qua nhiều lần truy vấn như anh/chị nghĩ, tức là đang giả định một tình huống rất lý tưởng. Không thể đảm bảo rằng mức giảm chi phí do refactoring sẽ được giữ nguyên bất kể số lượng truy vấn tiếp theo là bao nhiêu, và cũng không thể giả định như vậy nếu không có thực nghiệm. Nếu muốn bảo vệ ý định đó, có lẽ anh/chị nên cho thấy bằng thực nghiệm mức giảm chi phí với nhiều hơn 1 lần truy vấn. Nhưng chẳng phải thí nghiệm chỉ được thực hiện 1 lần rồi đem ra so sánh thôi sao?
Nói thêm, đây chỉ là giả định của riêng tôi, nhưng nếu cứ lặp lại truy vấn vô hạn lần để đạt cùng một mục tiêu (đầu ra cuối cùng lý tưởng), thì trong điều kiện lý tưởng, dù có refactoring hay không, mã nguồn cuối cùng có lẽ cũng phải hội tụ về cùng một dạng. (đầu ra cuối cùng lý tưởng là duy nhất)
Nếu giả định này là hợp lý, thì khi số lần truy vấn tăng lên, khác biệt giữa việc có và không có refactoring sẽ giảm đi, nên lợi ích cost down về token có vẻ cũng sẽ dần giảm theo. Vì vậy, xét ở góc độ vĩ mô, nếu lợi ích từ việc giảm chi phí này không duy trì đủ lâu, thì chênh lệch về tổng số token dùng cho các truy vấn có thể cũng không có ý nghĩa thống kê đáng kể, đúng không?
Bài viết này mang tính chất gần với một nghiên cứu "thực nghiệm",
nên mọi số liệu có trong bài đều tập trung vào việc giúp tất cả những ai đọc bài này có thể "tái hiện" lại.
Vì vậy, tôi đã ghi lại toàn bộ mã nguồn gốc được sử dụng và mọi quy trình dùng trong thử nghiệm,
để cung cấp thông tin sao cho mọi người làm thí nghiệm đều có thể thu được cùng một kết quả.
Nhìn vào không khí trong phần bình luận thì tôi cảm nhận rằng,
về sau có lẽ tôi nên tách thành hai bài: một bài theo kiểu tóm tắt 3 dòng,
và một bài dành cho những người muốn biết chi tiết.
Nếu bạn cho tôi biết phần nào của bài viết này khiến bạn cảm thấy quá phức tạp hoặc quá dài dòng,
thì điều đó sẽ là sự giúp đỡ rất lớn cho việc viết các bài sau này của tôi.
Phụ đề có vẻ không thật sự khớp với nội dung. Nếu sắp xếp lại, thì phụ đề như “cần phân tích rõ hơn các yếu tố cụ thể gây ra việc giảm token” có vẻ phù hợp hơn.
Tôi đồng ý với khá nhiều điểm trong nội dung này. Tuy nhiên, tính chất của bài viết này cũng bao hàm yếu tố “đề xuất cách áp dụng thực tế cho những người đang đọc bài này”.
Chỉ cần nhìn vào các bình luận đã có dưới bài này cũng có thể cảm nhận được bầu không khí chung; và đây cũng là điều tôi mới biết gần đây, có vẻ trong số những người dùng AI có khá nhiều người không phải lập trình viên nhưng vẫn làm vibe coding.
Nếu tạo ra kết quả ấn tượng từ đoạn mã do chính tác giả trực tiếp tinh chỉnh mà không thông qua AI,
thì rất dễ bị nhìn nhận là tác giả đang khoe kỹ năng lập trình của mình và hạ thấp năng lực của AI.
Vì vậy, tôi đã chọn đề cập đến ví dụ mà bất kỳ ai cũng có thể tự cảm nhận kết quả thông qua yếu tố “prompt”, thứ mà các vibe coder nói chung đều có thể tận dụng.
Tiếp nối nghiên cứu này, tôi hy vọng sẽ có thêm những nghiên cứu phân tách chi tiết hơn các yếu tố ảnh hưởng đến mức sử dụng token của AI.
Vibe coding không hoàn thiện đầu ra chỉ với 1 prompt.
Nếu thông qua 1 lần chỉnh sửa cấu trúc mà mang lại hiệu quả giảm mức tiêu hao token của n lần prompt, thì lượng token giảm được sẽ được phản ánh xuyên suốt n lần thực hiện giống nhau đó.
n là chỉ số được quyết định bởi mục tiêu của dự án, số lượng chức năng, cũng như lượng và độ phức tạp của mã nguồn cần cho chúng,
và gần đây do các code agent của Cursor / Claude đang có các bản cập nhật theo hướng chia nhỏ đơn vị thực thi để giải quyết vấn đề lặp vô hạn hoặc việc AI sử dụng token bừa bãi,
Tôi cho rằng việc nghiên cứu riêng về chỉ số n liên quan đến độ phức tạp của dự án là đúng đắn.
Để giúp mọi người dễ hiểu nhất có thể, tôi đã lấy ví dụ về việc cải thiện mã từ đoạn code do AI viết mà có vấn đề về cấu trúc, trong trường hợp không có chỉ thị riêng.
Điểm không nên bỏ qua ở đây là việc cải thiện cấu trúc tuyệt đối không phải là hành vi diễn ra độc lập với quá trình phát triển mã.
Đó có thể là phần chịu ảnh hưởng như một base context thông qua prompt ban đầu, hoặc qua các ràng buộc như ruleset của AI (.cursorrules),
và trong suốt chu kỳ phát triển dự án, 1 lần cải thiện cấu trúc không thể giải quyết mọi thứ.
Nói cách khác, thay vì lên kế hoạch cải thiện mã theo chu kỳ cố định, việc định hướng cấu trúc đúng ngay từ base context là hướng tốt hơn.
Ngoài ra, tôi cho rằng việc nghiên cứu riêng trường hợp có và không có quy tắc chỉ thị định hướng cấu trúc như một base context là phù hợp hơn.
Tóm lại đối với mục 1,
Khi có quy tắc chỉ thị định hướng cấu trúc như một base context, tổng mức sử dụng token cũng có khả năng giảm, và
vì tồn tại biến số là việc thu được đầu ra cuối cùng thông qua n lần lệnh prompt,
cho nên lập luận rằng phải cộng thêm mức sử dụng token của 1 lệnh prompt cải thiện cấu trúc vào để tính toán là không thật sự chuẩn xác.
Tôi cũng có cảm giác tương tự.
Tôi hiểu ý định của tác giả, nhưng so với những gì đã làm thì bài viết có vẻ phức tạp quá mức.
Có lẽ anh/chị muốn đưa tối đa các chi tiết dùng trong thí nghiệm vào bài nên mới viết như vậy,
nhưng nếu chỉ chắt lọc ngắn gọn phần cốt lõi thì những người quan tâm đến chủ đề này chắc cũng sẽ hiểu được.
Nếu mạnh dạn lược bớt chi tiết và chỉ tóm gọn ý chính thì có lẽ sẽ tốt hơn.
Cá nhân tôi thấy ý đồ và kết quả của tác giả khá thú vị.
Luận điểm chính dường như là mã nguồn tốt hơn sẽ dẫn đến mức tiêu thụ token ít hơn,
và có vẻ anh/chị đã thiết kế rồi thực hiện một thí nghiệm liên quan đến điều đó.
Nếu liệt kê theo phần tôi hiểu về thí nghiệm thì có vẻ là như sau:
Chuẩn bị 2 phiên bản: mã nguồn để truy vấn cho AI, và mã nguồn đã được tiền xử lý bằng prompt (?) từ chính mã nguồn đó
Chạy lần lượt hai mã nguồn này trên GPT5 và Sonnet, mỗi bên 5 lần, rồi so sánh lượng token tiêu thụ
Có lẽ là như vậy.
Và nếu cách hiểu của tôi là đúng, thì kết luận dường như là mã nguồn đã được tiền xử lý bằng prompt nhìn chung tiêu thụ ít token hơn.
Đây là một kết luận thú vị, nhưng ý kiến của tôi về thí nghiệm như sau.
Đây không phải là một phép so sánh công bằng
Nhìn về mặt số liệu thì có vẻ đã giảm, nhưng có lẽ nên so sánh bằng tổng số token dùng để xử lý mã nguồn mới đúng.
Nói cách khác, số token đã dùng cho bước tiền xử lý cũng nên được tính đến.
Nếu số token dùng để tiền xử lý quá lớn thì thực chất lại tiêu tốn nhiều token hơn và trở nên vô nghĩa; còn kể cả khi ít đi nữa thì chênh lệch mức tiêu thụ token thực tế có lẽ cũng sẽ nhỏ hơn đáng kể so với những gì bài viết thể hiện.
Cần so sánh mã nguồn trước và sau tiền xử lý
Nếu loại trừ token đã dùng cho tiền xử lý, thì lượng token tiêu thụ khi truy vấn có vẻ đã giảm một cách đáng kể.
Tuy nhiên, nếu phân tích được chính xác sự khác biệt nào trong mã nguồn đã tạo ra mức chênh lệch này, thì ý nghĩa của bài viết sẽ lớn hơn nhiều.
Vì điều đó cũng có nghĩa là có thể tối ưu prompt tiền xử lý để khuếch đại tối đa sự khác biệt đó.
Tác giả nói rằng việc refactor cấu trúc mã đã dẫn đến kết quả này, nhưng tôi không đồng ý và cho rằng hiện vẫn chưa thể biết chắc.
Bởi nếu yêu cầu AI cải thiện những phần khác ngoài refactor, thì cũng có thể vẫn làm giảm lượng token tiêu thụ.
Cần thêm các thí nghiệm đa dạng hơn
Tôi nghĩ nên chạy cùng một thí nghiệm này trên các codebase khác chứ không chỉ với đoạn mã hiện tại.
Vì cần phải đánh giá xem kết quả này có tốt một cách nhất quán hay không.
Tuy nhiên, tôi hiểu rằng trên thực tế việc kiểm thử như vậy có thể khó, nên có lẽ chỉ cần xem đây như một ý tham khảo là được.
Xin gửi phần tổng hợp bổ sung liên quan đến prompt đã được sử dụng.
Dù sao thì cách này cũng đặc biệt có lợi cho các lập trình viên khi viết prompt để cải thiện cấu trúc. Vì mỗi chương trình có đặc tính khác nhau, nên để tối ưu hiệu quả cải tiến ở mức cao sẽ cần một mức độ kiến thức phát triển phần mềm nhất định.
Tuy vậy, điều đó không có nghĩa là các vibe coder không phải lập trình viên không thể sử dụng phương pháp này. Dù hiệu quả có thể khác nhau, chỉ với những lệnh đơn giản như "Hãy dọn dẹp mã nguồn của dự án. Hãy xóa những đoạn mã không được sử dụng." thì AI cũng sẽ thực hiện việc phân tách và sắp xếp tệp cũng như class.
Tuy nhiên, vì sự khác biệt về mức độ chi tiết trong cải thiện cấu trúc có thể tạo ra chênh lệch về hiệu quả, nên cần cẩn trọng khi tham khảo tài liệu.
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
Quy trình làm việc SDD trong thực tế
Vì sao SDD quan trọng lúc này
Các nguyên tắc cốt lõi
Các cách tiếp cận triển khai
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: đọcplan.mdvà 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ànSức mạnh của tự động hóa có cấu trúc
Chất lượng dựa trên template
[NEEDS CLARIFICATION]giúp cấm phỏng đoán và thúc đẩy câu hỏi tường minhimplementation-details/để giữ khả năng đọcNền tảng hiến pháp
memory/constitution.mdđể giữ mọi triển khai nhất quán·đơn giản·chất lượng caoSự chuyển đổi
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ưngtừ 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.
Đ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?”
Tôi không hiểu rõ lắm ý anh/chị đang nói trong phần bình luận. Ý của tôi là nếu muốn so sánh công bằng hai phương pháp thì chẳng phải nên so sánh tổng số token tiêu thụ hay sao? Việc refactoring chẳng phải cũng tiêu tốn token sao?
Ngoài ra, những gì anh/chị trả lời dường như cũng không được viết trong bài, và có vẻ cũng là nội dung chưa được thực nghiệm. Có vẻ ý anh/chị là không nên so sánh token cho mỗi lần truy vấn, mà khi truy vấn nhiều lần thì overhead của refactoring sẽ giảm xuống, đồng thời số token kỳ vọng cho mỗi truy vấn cũng giảm nên tổng số token sẽ có lợi hơn. Nhưng điều đó có lẽ chỉ đúng khi chi phí giảm vẫn được duy trì qua nhiều lần truy vấn như anh/chị nghĩ, tức là đang giả định một tình huống rất lý tưởng. Không thể đảm bảo rằng mức giảm chi phí do refactoring sẽ được giữ nguyên bất kể số lượng truy vấn tiếp theo là bao nhiêu, và cũng không thể giả định như vậy nếu không có thực nghiệm. Nếu muốn bảo vệ ý định đó, có lẽ anh/chị nên cho thấy bằng thực nghiệm mức giảm chi phí với nhiều hơn 1 lần truy vấn. Nhưng chẳng phải thí nghiệm chỉ được thực hiện 1 lần rồi đem ra so sánh thôi sao?
Nói thêm, đây chỉ là giả định của riêng tôi, nhưng nếu cứ lặp lại truy vấn vô hạn lần để đạt cùng một mục tiêu (đầu ra cuối cùng lý tưởng), thì trong điều kiện lý tưởng, dù có refactoring hay không, mã nguồn cuối cùng có lẽ cũng phải hội tụ về cùng một dạng. (đầu ra cuối cùng lý tưởng là duy nhất)
Nếu giả định này là hợp lý, thì khi số lần truy vấn tăng lên, khác biệt giữa việc có và không có refactoring sẽ giảm đi, nên lợi ích cost down về token có vẻ cũng sẽ dần giảm theo. Vì vậy, xét ở góc độ vĩ mô, nếu lợi ích từ việc giảm chi phí này không duy trì đủ lâu, thì chênh lệch về tổng số token dùng cho các truy vấn có thể cũng không có ý nghĩa thống kê đáng kể, đúng không?
Bài viết này mang tính chất gần với một nghiên cứu "thực nghiệm",
nên mọi số liệu có trong bài đều tập trung vào việc giúp tất cả những ai đọc bài này có thể "tái hiện" lại.
Vì vậy, tôi đã ghi lại toàn bộ mã nguồn gốc được sử dụng và mọi quy trình dùng trong thử nghiệm,
để cung cấp thông tin sao cho mọi người làm thí nghiệm đều có thể thu được cùng một kết quả.
Nhìn vào không khí trong phần bình luận thì tôi cảm nhận rằng,
về sau có lẽ tôi nên tách thành hai bài: một bài theo kiểu tóm tắt 3 dòng,
và một bài dành cho những người muốn biết chi tiết.
Nếu bạn cho tôi biết phần nào của bài viết này khiến bạn cảm thấy quá phức tạp hoặc quá dài dòng,
thì điều đó sẽ là sự giúp đỡ rất lớn cho việc viết các bài sau này của tôi.
Tôi hoàn toàn đồng ý. Tôi rất hoan nghênh những lời phê bình theo kiểu này.
Con người không sống một mình, và năng lực hay hoàn cảnh của mỗi cá nhân đều khác nhau.
Bản thân tôi cũng chỉ là một lập trình viên bình thường, và không thể tự bỏ chi phí cá nhân để thực hiện mọi bài kiểm thử.
Tôi hy vọng bài viết này sẽ trở thành hạt giống, tạo ảnh hưởng tích cực đến nhiều người và là điểm khởi đầu cho nhiều nghiên cứu tiếp theo.
Phụ đề có vẻ không thật sự khớp với nội dung. Nếu sắp xếp lại, thì phụ đề như “cần phân tích rõ hơn các yếu tố cụ thể gây ra việc giảm token” có vẻ phù hợp hơn.
Tôi đồng ý với khá nhiều điểm trong nội dung này. Tuy nhiên, tính chất của bài viết này cũng bao hàm yếu tố “đề xuất cách áp dụng thực tế cho những người đang đọc bài này”.
Chỉ cần nhìn vào các bình luận đã có dưới bài này cũng có thể cảm nhận được bầu không khí chung; và đây cũng là điều tôi mới biết gần đây, có vẻ trong số những người dùng AI có khá nhiều người không phải lập trình viên nhưng vẫn làm vibe coding.
Nếu tạo ra kết quả ấn tượng từ đoạn mã do chính tác giả trực tiếp tinh chỉnh mà không thông qua AI,
thì rất dễ bị nhìn nhận là tác giả đang khoe kỹ năng lập trình của mình và hạ thấp năng lực của AI.
Vì vậy, tôi đã chọn đề cập đến ví dụ mà bất kỳ ai cũng có thể tự cảm nhận kết quả thông qua yếu tố “prompt”, thứ mà các vibe coder nói chung đều có thể tận dụng.
Tiếp nối nghiên cứu này, tôi hy vọng sẽ có thêm những nghiên cứu phân tách chi tiết hơn các yếu tố ảnh hưởng đến mức sử dụng token của AI.
Nếu thông qua 1 lần chỉnh sửa cấu trúc mà mang lại hiệu quả giảm mức tiêu hao token của n lần prompt, thì lượng token giảm được sẽ được phản ánh xuyên suốt n lần thực hiện giống nhau đó.
n là chỉ số được quyết định bởi mục tiêu của dự án, số lượng chức năng, cũng như lượng và độ phức tạp của mã nguồn cần cho chúng,
và gần đây do các code agent của Cursor / Claude đang có các bản cập nhật theo hướng chia nhỏ đơn vị thực thi để giải quyết vấn đề lặp vô hạn hoặc việc AI sử dụng token bừa bãi,
Tôi cho rằng việc nghiên cứu riêng về chỉ số n liên quan đến độ phức tạp của dự án là đúng đắn.
Điểm không nên bỏ qua ở đây là việc cải thiện cấu trúc tuyệt đối không phải là hành vi diễn ra độc lập với quá trình phát triển mã.
Đó có thể là phần chịu ảnh hưởng như một base context thông qua prompt ban đầu, hoặc qua các ràng buộc như ruleset của AI (.cursorrules),
và trong suốt chu kỳ phát triển dự án, 1 lần cải thiện cấu trúc không thể giải quyết mọi thứ.
Nói cách khác, thay vì lên kế hoạch cải thiện mã theo chu kỳ cố định, việc định hướng cấu trúc đúng ngay từ base context là hướng tốt hơn.
Ngoài ra, tôi cho rằng việc nghiên cứu riêng trường hợp có và không có quy tắc chỉ thị định hướng cấu trúc như một base context là phù hợp hơn.
Tóm lại đối với mục 1,
cho nên lập luận rằng phải cộng thêm mức sử dụng token của 1 lệnh prompt cải thiện cấu trúc vào để tính toán là không thật sự chuẩn xác.
Tôi cũng có cảm giác tương tự.
Tôi hiểu ý định của tác giả, nhưng so với những gì đã làm thì bài viết có vẻ phức tạp quá mức.
Có lẽ anh/chị muốn đưa tối đa các chi tiết dùng trong thí nghiệm vào bài nên mới viết như vậy,
nhưng nếu chỉ chắt lọc ngắn gọn phần cốt lõi thì những người quan tâm đến chủ đề này chắc cũng sẽ hiểu được.
Nếu mạnh dạn lược bớt chi tiết và chỉ tóm gọn ý chính thì có lẽ sẽ tốt hơn.
Cá nhân tôi thấy ý đồ và kết quả của tác giả khá thú vị.
Luận điểm chính dường như là mã nguồn tốt hơn sẽ dẫn đến mức tiêu thụ token ít hơn,
và có vẻ anh/chị đã thiết kế rồi thực hiện một thí nghiệm liên quan đến điều đó.
Nếu liệt kê theo phần tôi hiểu về thí nghiệm thì có vẻ là như sau:
Có lẽ là như vậy.
Và nếu cách hiểu của tôi là đúng, thì kết luận dường như là mã nguồn đã được tiền xử lý bằng prompt nhìn chung tiêu thụ ít token hơn.
Đây là một kết luận thú vị, nhưng ý kiến của tôi về thí nghiệm như sau.
Đây không phải là một phép so sánh công bằng
Nhìn về mặt số liệu thì có vẻ đã giảm, nhưng có lẽ nên so sánh bằng tổng số token dùng để xử lý mã nguồn mới đúng.
Nói cách khác, số token đã dùng cho bước tiền xử lý cũng nên được tính đến.
Nếu số token dùng để tiền xử lý quá lớn thì thực chất lại tiêu tốn nhiều token hơn và trở nên vô nghĩa; còn kể cả khi ít đi nữa thì chênh lệch mức tiêu thụ token thực tế có lẽ cũng sẽ nhỏ hơn đáng kể so với những gì bài viết thể hiện.
Cần so sánh mã nguồn trước và sau tiền xử lý
Nếu loại trừ token đã dùng cho tiền xử lý, thì lượng token tiêu thụ khi truy vấn có vẻ đã giảm một cách đáng kể.
Tuy nhiên, nếu phân tích được chính xác sự khác biệt nào trong mã nguồn đã tạo ra mức chênh lệch này, thì ý nghĩa của bài viết sẽ lớn hơn nhiều.
Vì điều đó cũng có nghĩa là có thể tối ưu prompt tiền xử lý để khuếch đại tối đa sự khác biệt đó.
Tác giả nói rằng việc refactor cấu trúc mã đã dẫn đến kết quả này, nhưng tôi không đồng ý và cho rằng hiện vẫn chưa thể biết chắc.
Bởi nếu yêu cầu AI cải thiện những phần khác ngoài refactor, thì cũng có thể vẫn làm giảm lượng token tiêu thụ.
Cần thêm các thí nghiệm đa dạng hơn
Tôi nghĩ nên chạy cùng một thí nghiệm này trên các codebase khác chứ không chỉ với đoạn mã hiện tại.
Vì cần phải đánh giá xem kết quả này có tốt một cách nhất quán hay không.
Tuy nhiên, tôi hiểu rằng trên thực tế việc kiểm thử như vậy có thể khó, nên có lẽ chỉ cần xem đây như một ý tham khảo là được.
Quà tặng vô dụng đang khá được ưa chuộng... có vẻ sẽ hay để khám phá thêm những món quà vô dụng mới.
Xin gửi phần tổng hợp bổ sung liên quan đến prompt đã được sử dụng.
Dù sao thì cách này cũng đặc biệt có lợi cho các lập trình viên khi viết prompt để cải thiện cấu trúc. Vì mỗi chương trình có đặc tính khác nhau, nên để tối ưu hiệu quả cải tiến ở mức cao sẽ cần một mức độ kiến thức phát triển phần mềm nhất định.
Tuy vậy, điều đó không có nghĩa là các vibe coder không phải lập trình viên không thể sử dụng phương pháp này. Dù hiệu quả có thể khác nhau, chỉ với những lệnh đơn giản như "Hãy dọn dẹp mã nguồn của dự án. Hãy xóa những đoạn mã không được sử dụng." thì AI cũng sẽ thực hiện việc phân tách và sắp xếp tệp cũng như class.
Tuy nhiên, vì sự khác biệt về mức độ chi tiết trong cải thiện cấu trúc có thể tạo ra chênh lệch về hiệu quả, nên cần cẩn trọng khi tham khảo tài liệu.
Nếu bạn cần tận dụng thông tin không gian, thì đây là một lựa chọn tốt.