Hiểu về phát triển hướng đặc tả (SDD): Kiro, Spec-Kit, Tessl

 (martinfowler.com)
27 điểm bởi GN⁺ 2025-10-20 | 3 bình luận | Chia sẻ qua WhatsApp
  • Spec-Driven Development (SDD) là cách tiếp cận trong lập trình với AI, trong đó viết đặc tả (spec) trước khi viết mã, và đặc tả đóng vai trò là nguồn chân lý (source of truth) cho cả lập trình viên lẫn AI
  • SDD được chia thành ba mức độ triển khai và phát triển theo từng nấc: spec-first (viết đặc tả trước), spec-anchored (giữ lại đặc tả để bảo trì), và spec-as-source (dùng đặc tả làm tệp nguồn chính, lập trình viên không chỉnh sửa mã trực tiếp)
  • Kiro cung cấp quy trình 3 bước đơn giản gồm yêu cầu → thiết kế → tác vụ; spec-kit dùng quy trình dựa trên luật mạnh với khái niệm hiến pháp (constitution); còn Tessl thử nghiệm cách tiếp cận spec-as-source với ánh xạ 1:1 giữa đặc tả và mã
  • Cả ba công cụ đều đòi hỏi quy trình quá nặng cho các bản sửa lỗi nhỏ, việc review tệp Markdown phiền hơn review mã, và dù cửa sổ ngữ cảnh lớn hơn thì AI vẫn có giới hạn trong việc tuân thủ đầy đủ mọi chỉ dẫn
  • SDD gợi nhớ đến những thất bại trước đây của phát triển hướng mô hình (MDD), và có nguy cơ mang cả nhược điểm của tính không xác định lẫn tính thiếu linh hoạt, nên vẫn cần được kiểm chứng về tính hữu ích trong các dự án thực tế

Định nghĩa của phát triển hướng đặc tả (SDD)

  • SDD là cách tiếp cận “ưu tiên tài liệu” trong đó viết đặc tả trước khi viết mã, và đặc tả đóng vai trò là nguồn chân lý duy nhất (single source of truth) cho cả lập trình viên và AI
  • GitHub định nghĩa rằng “bảo trì phần mềm nghĩa là sự tiến hóa của đặc tả, ngôn ngữ chung của phát triển được nâng lên mức trừu tượng cao hơn và mã trở thành bước cuối cùng”
  • Tessl mô tả đây là “một cách tiếp cận phát triển trong đó đặc tả trở thành hiện vật chính thay vì mã; đặc tả diễn đạt ý định bằng ngôn ngữ có cấu trúc và có thể kiểm thử, còn agent tạo mã theo đó”
  • SDD được chia thành ba mức độ triển khai
    • Spec-first: viết trước một bản đặc tả được cấu trúc tốt và dùng nó trong quy trình phát triển có AI hỗ trợ
    • Spec-anchored: vẫn duy trì đặc tả sau khi hoàn thành công việc để tiếp tục dùng cho quá trình tiến hóa và bảo trì tính năng đó
    • Spec-as-source: đặc tả tiếp tục là tệp nguồn chính theo thời gian; lập trình viên chỉ chỉnh sửa đặc tả và không đụng trực tiếp vào mã
  • Mọi cách tiếp cận SDD đều là spec-first, nhưng không phải tất cả đều hướng tới spec-anchored hay spec-as-source, và chiến lược duy trì đặc tả theo thời gian thường mơ hồ hoặc để ngỏ hoàn toàn

Đặc tả (spec) là gì

  • Đặc tả là một hiện vật có cấu trúc, định hướng hành vi, được viết bằng ngôn ngữ tự nhiên để biểu diễn chức năng phần mềm và làm hướng dẫn cho các agent lập trình AI
  • Định nghĩa nhất quán nhất là xem đặc tả như một tài liệu yêu cầu sản phẩm (PRD)
  • Cần phân biệt đặc tả với các tài liệu ngữ cảnh chung cho codebase
    • Ngữ cảnh chung gồm các file quy tắc, mô tả cấp cao về sản phẩm và codebase; một số công cụ gọi đây là memory bank
    • Các file memory bank liên quan đến mọi phiên lập trình AI trong codebase, còn đặc tả chỉ liên quan đến các tác vụ tạo mới hoặc thay đổi một tính năng cụ thể
  • Mỗi biến thể SDD định nghĩa cách tiếp cận riêng về cấu trúc, mức độ chi tiết và cách tổ chức đặc tả trong dự án

Khó khăn khi đánh giá công cụ SDD

  • Việc đánh giá các công cụ và cách tiếp cận SDD sát với thực tế sử dụng rất tốn thời gian
    • Cần thử trên các bài toán ở nhiều quy mô khác nhau, trong dự án greenfield lẫn brownfield, và cần thời gian để xem xét, chỉnh sửa kỹ lưỡng các hiện vật trung gian thay vì chỉ lướt qua
  • Bài blog về spec-kit của GitHub nhấn mạnh rằng “điều quan trọng là vai trò của bạn không chỉ là định hướng mà còn là xác minh, và bạn cần phản ánh, cải thiện ở từng bước”
  • Hai trong ba công cụ có vẻ đòi hỏi nhiều công sức hơn để đưa vào codebase sẵn có, khiến việc đánh giá tính hữu ích trên các codebase brownfield càng khó hơn
  • Trước khi nghe được các báo cáo sử dụng từ những người đã dùng trong codebase thực một thời gian, vẫn còn nhiều câu hỏi chưa có lời giải về cách chúng thật sự hoạt động

Kiro

  • Kiro là công cụ đơn giản và nhẹ nhất trong ba công cụ, và phần lớn thuộc nhóm tiếp cận spec-first
    • Chỉ thấy các ví dụ dùng cho task hoặc user story, chưa thấy đề cập đến cách dùng tài liệu yêu cầu theo kiểu spec-anchored qua nhiều tác vụ theo thời gian
  • Quy trình: Yêu cầu → Thiết kế → Tác vụ
    • Mỗi bước trong quy trình được biểu diễn bằng một tài liệu Markdown, và Kiro hướng dẫn 3 bước này trong bản phân phối dựa trên VS Code

  • Các thành phần chính của Kiro

    • Yêu cầu (Requirements)
      • Được cấu trúc thành danh sách yêu cầu, trong đó mỗi yêu cầu biểu diễn một “user story” (theo dạng As a...)
      • Tiêu chí chấp nhận dùng định dạng GIVEN... WHEN... THEN...
    • Thiết kế (Design)
      • Gồm các phần như sơ đồ kiến trúc thành phần, luồng dữ liệu, mô hình dữ liệu, xử lý lỗi, chiến lược kiểm thử, cách tiếp cận triển khai, chiến lược migration...
      • Chưa rõ cấu trúc này có nhất quán hay thay đổi theo từng tác vụ
    • Tác vụ (Tasks)
      • Danh sách tác vụ được truy vết theo số hiệu yêu cầu
      • Cung cấp các thành phần UI bổ sung để thực thi từng tác vụ một và review thay đổi theo từng tác vụ

  • Memory bank của Kiro

    • Kiro gọi khái niệm memory bank là steering
      • Nội dung khá linh hoạt, và quy trình dường như không phụ thuộc vào sự tồn tại của các file cụ thể
    • Cấu trúc mặc định mà Kiro tạo ra khi được yêu cầu sinh tài liệu steering là product.md, structure.md, tech.md

Spec-kit

  • spec-kit là phiên bản SDD của GitHub, được phân phối dưới dạng CLI có thể tạo thiết lập workspace cho nhiều coding assistant phổ thông khác nhau
  • Sau khi thiết lập cấu trúc, người dùng tương tác với spec-kit thông qua slash command của coding assistant
  • Vì mọi hiện vật đều được đặt trực tiếp trong workspace, đây là công cụ dễ tùy biến nhất trong ba công cụ được bàn tới

  • Quy trình của Spec-kit

    • Quy trình: Constitution → 𝄆 Specify → Plan → Tasks 𝄇
    • Khái niệm memory bank của spec-kit là điều kiện tiên quyết của cách tiếp cận spec-driven
      • Nó được gọi là constitution, gồm các nguyên tắc cấp cao “bất biến” phải luôn áp dụng cho mọi thay đổi
      • Đây là một file quy tắc rất mạnh và được dùng nhiều trong toàn bộ quy trình

  • Cách Spec-kit hoạt động

    • Ở mỗi bước quy trình (specify, plan, tasks), nó dùng script bash và template để khởi tạo tập hợp file và prompt
    • Quy trình tận dụng nhiều checklist trong file để theo dõi các yêu cầu làm rõ từ người dùng, vi phạm constitution, tác vụ nghiên cứu...
      • Chúng hoạt động như “định nghĩa hoàn thành” (definition of done) cho từng bước quy trình (dù vì AI là bên diễn giải nên không thể đảm bảo 100%)
    • Một đặc tả gồm nhiều file
      • Ví dụ: data-model, plan, tasks, spec, research, api, component và tổng cộng 8 file

  • Cách tiếp cận của Spec-kit

    • Ban đầu GitHub có vẻ hướng tới cách tiếp cận spec-anchored
      • “Đặc tả không còn là tài liệu tĩnh mà là hiện vật sống, có thể thực thi, cùng tiến hóa với dự án; đặc tả trở thành nguồn chân lý chung”
    • Tuy nhiên, spec-kit tạo branch cho mọi đặc tả được sinh ra, nên có thể hiểu rằng nó xem đặc tả là hiện vật sống trong vòng đời của một yêu cầu thay đổi, chứ không phải trong vòng đời của tính năng
    • Các cuộc thảo luận trong cộng đồng cũng nói đến sự mơ hồ này, và spec-kit dường như hiện vẫn chỉ là spec-first chứ chưa thực sự là spec-anchored theo thời gian

Tessl Framework

  • Tessl Framework đang ở giai đoạn beta kín, và giống spec-kit, nó được phát hành dưới dạng CLI có thể tạo workspace và cấu trúc cấu hình cho nhiều coding assistant
  • Các lệnh CLI cũng hoạt động như một máy chủ MCP

  • Đặc điểm của Tessl

    • Đây là công cụ duy nhất trong ba công cụ công khai nhắm rõ ràng đến cách tiếp cận spec-anchored, đồng thời cũng đang khám phá SDD ở mức spec-as-source
    • Đặc tả của Tessl có thể đóng vai trò là hiện vật chính được bảo trì và chỉnh sửa, còn mã sẽ có chú thích // GENERATED FROM SPEC - DO NOT EDIT ở đầu file
      • Hiện tại là ánh xạ 1:1 giữa đặc tả và file mã, tức một đặc tả được chuyển thành một file trong codebase
      • Vì vẫn đang ở giai đoạn beta và thử nghiệm nhiều biến thể khác nhau, về sau nó cũng có thể phát triển đến mức một đặc tả ánh xạ thành một thành phần mã gồm nhiều file

  • Cấu trúc đặc tả của Tessl

    • Các thẻ như @generate hay @test dùng để chỉ thị cho Tessl cần sinh gì
    • Phần API cho thấy ý tưởng định nghĩa trong đặc tả giao diện tối thiểu được lộ ra cho các phần khác của codebase, bảo đảm rằng những phần quan trọng của thành phần được tạo ra vẫn nằm dưới sự kiểm soát đầy đủ của người bảo trì
    • Chạy tessl build sẽ tạo file mã JavaScript tương ứng

  • Mức độ trừu tượng của Tessl

    • Nếu đặt đặc tả cho spec-as-source ở mức trừu tượng khá thấp, gần với từng file mã, thì số bước và lượng diễn giải mà LLM phải thực hiện sẽ giảm, kéo theo giảm khả năng lỗi
    • Ngay cả ở mức trừu tượng thấp như vậy, vẫn quan sát thấy tính không xác định khi sinh mã nhiều lần từ cùng một đặc tả
      • Quá trình liên tục tinh chỉnh đặc tả để làm cho việc sinh mã lặp lại được hơn gợi nhớ đến cái bẫy và thách thức của việc viết một đặc tả hoàn chỉnh, không mơ hồ

Quan sát và câu hỏi

  • Một quy trình có thể xử lý mọi quy mô bài toán không?

    • Kiro và spec-kit mỗi công cụ đều đưa ra một quy trình khá giáo điều, nhưng cả hai có thể không phù hợp với phần lớn các bài toán lập trình thực tế
    • Chưa rõ chúng có cung cấp đủ sự đa dạng để phù hợp với nhiều quy mô vấn đề hay không
      • Khi thử sửa một lỗi nhỏ bằng Kiro, quy trình này giống như dùng búa tạ để đập quả óc chó
      • Tài liệu yêu cầu đã biến một lỗi nhỏ thành 4 “user story” với tổng cộng 16 tiêu chí chấp nhận
    • Khi dùng spec-kit cũng khó biết nên áp dụng cho bài toán cỡ nào
      • Khi thử một tính năng mà trước đây trong đội có lẽ chỉ là story 3–5 point, số bước spec-kit thực hiện và lượng file Markdown nó tạo ra có cảm giác quá mức so với quy mô bài toán
      • Trong cùng khoảng thời gian đó, có lẽ đã có thể triển khai tính năng bằng kiểu lập trình AI hỗ trợ “thông thường” và cảm thấy kiểm soát tốt hơn nhiều
    • Một công cụ SDD hiệu quả cần linh hoạt hơn với ít nhất vài quy trình cốt lõi khác nhau cho các thay đổi ở nhiều quy mô và loại hình

  • Review Markdown thay vì review mã?

    • spec-kit tạo ra rất nhiều file Markdown cần review
      • Chúng lặp lại lẫn nhau và còn lặp lại cả với mã đã tồn tại
      • Một số file thậm chí đã chứa sẵn mã, khiến toàn bộ trở nên rất dài dòng và mệt mỏi khi review
    • Với Kiro, chỉ có 3 file và mô hình tư duy “yêu cầu > thiết kế > tác vụ” trực quan hơn, nên có phần dễ hơn
      • Nhưng ngay cả Kiro cũng quá dài dòng nếu chỉ để xử lý một lỗi nhỏ được yêu cầu sửa
    • Thành thật mà nói, review mã còn tốt hơn review tất cả đống file Markdown này
    • Một công cụ SDD hiệu quả cần mang lại trải nghiệm review đặc tả thật sự tốt

  • Cảm giác kiểm soát giả tạo?

    • Dù có đủ loại file, template, prompt, quy trình và checklist, vẫn thường xuyên thấy agent rốt cuộc không tuân theo toàn bộ chỉ dẫn
    • Cửa sổ ngữ cảnh lớn hơn thường được xem là một yếu tố kích hoạt SDD, nhưng cửa sổ lớn hơn không có nghĩa là AI sẽ hiểu đúng mọi thứ nằm trong đó
    • Ví dụ
      • spec-kit có bước nghiên cứu trong lúc lập kế hoạch và đã nghiên cứu khá nhiều về mã hiện có, nhưng cuối cùng agent lại bỏ qua thực tế rằng đó là mô tả của một lớp đã tồn tại, rồi coi đó là đặc tả mới và sinh lại toàn bộ thành phần, dẫn đến trùng lặp
      • Không chỉ có trường hợp bỏ qua chỉ dẫn, còn có cả những agent làm quá mức vì cố tuân thủ chỉ dẫn quá sát (ví dụ một điều khoản trong constitution)
    • Theo kinh nghiệm trước đây, cách tốt nhất để kiểm soát thứ chúng ta xây dựng là những bước nhỏ và lặp lại, nên có lý do để rất hoài nghi việc đầu tư nhiều công sức vào thiết kế đặc tả từ trước
    • Một công cụ SDD hiệu quả cần chấp nhận cách tiếp cận lặp lại, nhưng các gói công việc nhỏ dường như lại gần như trái ngược với chính ý tưởng SDD

  • Làm sao tách bạch hiệu quả giữa đặc tả chức năng và đặc tả kỹ thuật?

    • Trong SDD, việc cố ý tách biệt giữa đặc tả chức năng và triển khai kỹ thuật là một ý tưởng phổ biến
      • Khát vọng cốt lõi là rốt cuộc AI có thể tự điền toàn bộ lời giải và chi tiết, thậm chí chuyển cùng một đặc tả sang stack công nghệ khác
    • Nhưng khi thử spec-kit trong thực tế, thường xuyên thấy khó biết khi nào nên dừng ở mức chức năng và khi nào nên thêm chi tiết kỹ thuật
      • Các tutorial và tài liệu cũng không nhất quán về điểm này, và tồn tại nhiều cách hiểu khác nhau về việc “thuần chức năng” thực sự nghĩa là gì
    • Nếu nhớ lại rất nhiều user story vốn không tách bạch tốt giữa yêu cầu và cách triển khai, thì nhìn rộng ra cả nghề này cũng không có thành tích tốt trong việc làm điều đó

  • Người dùng mục tiêu là ai?

    • Nhiều bản demo và tutorial của các công cụ phát triển hướng đặc tả có nhắc đến việc định nghĩa mục tiêu sản phẩm và tính năng, đồng thời dùng cả các thuật ngữ như “user story”
    • Ý tưởng ở đây có thể là dùng AI như công cụ thúc đẩy cross-skilling để lập trình viên tham gia tích cực hơn vào phân tích yêu cầu
      • Hoặc lập trình viên sẽ làm việc cặp đôi với người phụ trách sản phẩm trong quy trình này?
    • Không điều nào trong số đó được giải thích rõ ràng, mà thay vào đó mọi thứ được trình bày như thể việc lập trình viên tự làm toàn bộ phần phân tích là điều hiển nhiên
    • Vậy thì SDD dành cho quy mô và loại bài toán nào?
      • Có lẽ nó không phù hợp với các tính năng lớn mà bản thân còn rất mơ hồ; trong những trường hợp đó chắc chắn còn cần nhiều bước khác như kỹ năng sản phẩm và đặc tả yêu cầu chuyên sâu hơn, nghiên cứu và sự tham gia của các bên liên quan

  • Spec-anchored và spec-as-source: có đang học từ quá khứ không?

    • Nhiều người liên hệ SDD với TDD hoặc BDD, nhưng đặc biệt với spec-as-source, có một phép tương đồng quan trọng khác đáng xem xét là MDD (phát triển hướng mô hình)
    • Tác giả từng làm ở vài dự án dùng MDD khá nhiều trong giai đoạn đầu sự nghiệp, và khi thử Tessl Framework thì liên tục nhớ đến điều đó
      • Các mô hình trong MDD về cơ bản chính là đặc tả, nhưng được biểu diễn bằng UML tùy biến hoặc DSL dạng văn bản chứ không phải ngôn ngữ tự nhiên
      • Để biến các đặc tả này thành mã, người ta xây dựng các bộ sinh mã tùy chỉnh

  • So sánh MDD và SDD

    • Rốt cuộc, MDD không thành công trong các ứng dụng nghiệp vụ, vì ở mức trừu tượng gượng ép và tạo ra quá nhiều overhead lẫn ràng buộc
    • Tuy vậy, LLM có thể loại bỏ một phần overhead và ràng buộc của MDD, nên nay xuất hiện niềm hy vọng mới rằng ta có thể tập trung viết đặc tả và để AI sinh mã
    • Khi dùng LLM, ta không còn bị trói buộc vào một ngôn ngữ đặc tả được định nghĩa trước và có thể parse, cũng không cần xây dựng bộ sinh mã quá tinh vi
      • Cái giá phải trả dĩ nhiên là tính không xác định của LLM
    • Mặt khác, cấu trúc có thể parse được trước đây cũng có lợi thế là cung cấp rất nhiều công cụ hỗ trợ để người viết đặc tả tạo ra đặc tả hợp lệ, đầy đủ và nhất quán, và giờ ta đang đánh mất điều đó
    • spec-as-source, thậm chí cả spec-anchoring, có thể rốt cuộc mắc cả nhược điểm của MDD lẫn LLM: thiếu linh hoạt và không xác định
    • Cần nhìn lại các nỗ lực spec-from-code trong quá khứ và rút kinh nghiệm khi khám phá hướng spec-driven ngày nay

Kết luận

  • Về mặt cá nhân, khi dùng lập trình có AI hỗ trợ, tác giả thường dành thời gian viết cẩn thận dạng đặc tả sẽ cung cấp cho coding agent
    • Vì vậy, nguyên tắc chung của spec-first rõ ràng có giá trị trong nhiều tình huống
  • Các cách tiếp cận khác nhau về việc cấu trúc đặc tả là rất cần thiết, và hiện đây là một trong những câu hỏi mà tác giả nhận được nhiều nhất từ người thực hành
    • “Làm sao cấu trúc memory bank?”, “Làm sao viết tài liệu đặc tả và thiết kế tốt cho AI?”
  • Tuy nhiên, thuật ngữ “spec-driven development” vẫn chưa được định nghĩa rõ ràng, và đã bắt đầu bị loãng nghĩa
    • Gần đây thậm chí còn nghe người ta dùng “spec” gần như như từ đồng nghĩa của “prompt chi tiết”

  • Đánh giá về các công cụ

    • Một số công cụ cố gắng áp nguyên xi quy trình hiện có sang cho AI agent, và rốt cuộc có thể khuếch đại các vấn đề vốn đã tồn tại như quá tải review hay hallucination
    • Đặc biệt với những cách tiếp cận phức tạp hơn tạo ra nhiều file, người ta dễ nghĩ tới từ ghép tiếng Đức “Verschlimmbesserung” (cố cải thiện nhưng lại làm mọi thứ tệ hơn)
      • Tức là tự hỏi liệu trong nỗ lực làm cho mọi thứ tốt hơn, ta có đang khiến chúng tệ đi hay không

Bài viết liên quan

3 bình luận

 
aer0700 2025-10-20

Trông khá giống với những câu chuyện trước đây như phát triển theo tài liệu hoặc phát triển theo README.
https://vi.news.hada.io/topic?id=15502
 
GN⁺ 2025-10-20
Ý kiến trên Hacker News

  • Gần đây tôi đang theo dõi xu hướng SDD (phát triển hướng đặc tả), và thấy hướng đi này có lý, nhưng cũng mang cảm giác như đang quay lại thời kỳ tiền-agile với các bản đặc tả tính năng và tài liệu thiết kế, tuy chưa hẳn là Big Design Up Front hoàn toàn, nhưng dường như đang dần tiến tới kiểu “phần mềm hoạt động được == tài liệu hoàn hảo”
    Tham khảo Big Design Up Front, Tham khảo Agile Manifesto

    • Bản đặc tả tính năng và tài liệu thiết kế rốt cuộc cũng giống như việc lập trình bằng ngôn ngữ tự nhiên, trước đây con người phải viết lại chúng bằng ngôn ngữ lập trình, nhưng giờ các "trình biên dịch" tự động như LLM (mô hình ngôn ngữ lớn) đã bắt đầu làm thay việc đó, nên ta có thể bỏ qua một bước trong quy trình này (tỷ lệ thành công thì rất khác nhau)<br /> Trong khi đó, agile không quan tâm phần mềm được tạo ra bằng ngôn ngữ nào, bản chất của nó là “loại bỏ quản lý” và để lập trình viên trực tiếp làm cả phần việc quản trị, 12 nguyên tắc nói rõ hơn về những việc lập trình viên phải làm khi không có quản lý

    • Behaviour Driven Design cũng như Test Driven Design có thể tạo ra một “đặc tả sống”, để lại dưới dạng tài liệu con người có thể đọc được, từ tiêu chí khám phá miền nghiệp vụ cho đến việc test có pass hay không, và có thể nối trực tiếp với test harness để kiểm chứng chức năng hiện hành, như vậy có thể có tài liệu đặc tả được kiểm chứng rõ ràng, cộng tác được và lặp lại được thông qua báo cáo BDD, đồng thời vẫn đảm bảo agile, JIT và YAGNI mà không cần làm việc thừa từ đầu, không nhất thiết phải quay lại waterfall

    • Cũng có thể bắt đầu từ thiết kế quy mô nhỏ, ví dụ viết đặc tả một hai trang rồi dùng LLM sinh code và test, sau đó cải tiến lặp đi lặp lại, nếu thực sự tin tưởng 100% vào việc LLM viết code thì việc quản lý có hệ thống phần nhập đặc tả (prompt tiếng Anh) là điều hợp lý, thay vì vứt prompt đi thì nên sắp xếp lại để sau này có thể tái sử dụng hoặc bổ sung ràng buộc rõ ràng hơn<br /> Tuy nhiên tôi vẫn chưa yên tâm dùng LLM cho code production quan trọng, nên mới chỉ thử nghiệm cho mục đích sandbox/test/demo, tức là chỉ dùng ở những nơi chất lượng code không cần quá khắt khe

    • Bản thân spec driven development là một ý tưởng tốt, nhưng các cách triển khai hiện tại chỉ đưa các file markdown không có cấu trúc cho agent, rồi vì kết quả không ra hồn nên thực tế hoàn toàn không có tính tái lập, nếu agent còn viết cả đặc tả thì nó phải là đặc tả có cấu trúc, có thể tự động chuyển thành stub code và test code, thay vì chỉ dùng markdown một cách lãng phí, nếu liên kết nó với code generator thì tính tái lập sẽ tốt hơn rất nhiều, và nếu làm vậy thật thì có thể rút ngắn đáng kể thời gian dành cho việc sinh mã lặp lại

  • Tôi đã dùng thử SpecKit và thấy thực sự thú vị, khá hài lòng, nhưng lại gặp khó khi tìm các ví dụ hay cách dùng phức tạp trong thực tế, phần lớn tutorial chỉ dừng ở mức cài đặt đơn giản rồi “làm app todo list”, tôi rất muốn thấy các trường hợp thực tế như cải tiến hoặc refactor từng bước một codebase legacy sẵn có, hoặc cách tiếp cận với dự án lớn vốn không áp dụng spec driven development ngay từ đầu

    • Bản thân tôi cũng nhận ra khi kết hợp cách làm BDD với coding qua CLI thì việc ghi lại chức năng trực tiếp bằng code thật hiệu quả hơn nhiều so với markdown dài dòng, nếu cần checklist để AI bám theo thì chỉ cần một file như agents.md là đủ, chỉ cần ghi lại pattern coding và các yêu cầu phi chức năng (NFR) một lần là agent có thể tuân theo khá rõ ràng

    • Muốn ứng dụng thật thì cuối cùng vẫn phải đọc trực tiếp template hoặc source code thì mới hiểu được thực sự cái gì đang chạy, và tôi nghĩ trong các dự án kiểu này đó thậm chí còn là điều hiển nhiên

  • Ngay khi thấy sau phần giới thiệu về một chuyên gia delivery dùng AI xuất thân từ Thoughtworks là tới câu chuyện về memory banks, tôi lập tức đồng cảm, vì chúng tôi cũng làm việc trong môi trường “AI là xu thế”, và khi memory bank phình to thì AI lại càng mất phương hướng, kết quả cũng trở nên lộn xộn, cuối cùng vẫn phải có người thực sự hiểu sản phẩm trực tiếp dẫn dắt AI thì mới áp dụng được vào thực tế, tôi đã trải qua vô số lần AI đánh lừa mình, và khi con người trực tiếp chỉ lại thì nó lúc nào cũng xin lỗi và tỏ ra hiểu ra, nhưng rốt cuộc chẳng có gì thay đổi, còn việc để AI đọc và kiểm chứng hàng đống tài liệu mà chính nó viết ra thì thực tế là bất khả thi, nghĩ kỹ thì thà dành thời gian đó để tự làm còn tốt hơn nhiều

    • Tôi tò mò memory bank ở đây cụ thể có nghĩa là gì, và người ta thật ra muốn nói cụ thể điều gì về vai trò của nó

    • Ở thời điểm hiện tại, chức năng memory lại còn gây hại nhiều hơn, nếu dùng mà không có chiến lược “search/retrieval” tử tế thì chỉ khuếch đại thêm kết quả tệ, đa số hệ thống memory được thiết kế cho mô hình một cuộc chat duy nhất nên sang các môi trường đa dạng là phát sinh vấn đề, “ký ức” thật sự nên là kiểu “agent-based memory”, tức là thông qua một “siêu nhận thức/default mode network” tách biệt với agent chính để thiết kế cấu trúc tác vụ và ngữ cảnh theo kiểu bất đồng bộ, rồi ở mỗi prompt siêu mô hình này sẽ định hướng cho tác vụ

    • Tôi cũng không hiểu mấy cái chức danh như “thought leader” trên LinkedIn nghĩa là gì nữa, dạo này thật sự rất khó hiểu những title kiểu đó còn có ý nghĩa gì

  • Tôi muốn chia sẻ trải nghiệm thử nghiệm với SpecKit và Claude Code trong hai tuần gần đây trên hai dự án mới, vì cả hai dự án đều do một mình tôi phát triển nên cũng không áp lực lắm khi đem ra thử nghiệm, với dự án đầu tiên tôi gần như giao nguyên cho SpecKit xử lý, mất 10 ngày để hoàn thành toàn bộ task nhưng phần lớn test của kết quả đều fail và build cũng vỡ, tôi lại phải tốn từng ấy thời gian để sửa lỗi, mà Claude cứ sửa được chỗ này thì lại phá chỗ khác nên độ tin cậy giảm mạnh<br /> Ở dự án thứ hai, để lặp theo đơn vị nhỏ hơn, sau phần planning của SpecKit tôi thêm slash command để tạo backlog.md, rồi dùng plan-sprint để sinh file có mục tiêu sprint và chi tiết công việc, sau đó dùng implement-sprint để xử lý hàng loạt. Nhưng ngay cả quy trình này cũng không tuân thủ lệnh triển khai, dù sửa quy trình nhiều lần nó vẫn không tạo test hoặc bỏ sót task<br /> Thế là tôi lại đổi setup, chuyển sang dạng có subagent chỉ xử lý từng task cụ thể, còn implement-sprint chỉ đóng vai trò orchestrator. Làm vậy thì ở mỗi sprint tôi có thể xem lại trạng thái code nên độ tin cậy cao hơn nhiều. Dù bây giờ nó vẫn có lúc bảo là xong trong khi test còn fail, nhưng vẫn đỡ hơn việc tôi phải tự xem toàn bộ từ đầu đến cuối<br /> Giả thuyết hiện tại của tôi là Claude yếu ở TDD, nó luôn gặp vấn đề ở bước viết test trước, lần tới tôi định thử đổi sang cách viết test sau khi hoàn tất triển khai, tuy không lý tưởng nhưng nếu vậy mà tăng năng suất thì có lẽ vẫn hơn tự code hoàn toàn bằng tay

  • Tôi thấy thú vị ở chỗ phần lớn công cụ đều được thiết kế theo chiến lược “đặc tả trước”, còn cách duy trì đặc tả thì lại khá mơ hồ, cá nhân tôi đang cùng cofounder dốc toàn lực cho hướng “spec as source”, và xem việc coi đặc tả như source thật sự là cách dùng thú vị nhất nên đang thử hiện thực hóa, nhưng để nó bám rễ trong thực tế thì khó hơn rất nhiều. Nếu ai có trải nghiệm hay phản hồi liên quan thì tôi rất muốn được nghe<br /> Dự án thử nghiệm của chúng tôi là specific.dev, nếu ai quan tâm thì mong hãy dùng thử rồi cho biết cảm nhận

    • Nếu đặc tả thực sự là source thì điều đó có nghĩa là bản đặc tả ấy tự nó phải là một ngôn ngữ hình thức có thể thực thi được (ngôn ngữ lập trình), nếu không thì đặc tả vẫn chỉ là đặc tả, còn source code vẫn là source code, rốt cuộc ai cũng vẫn phải học thế nào là “code tốt” mà thôi

  • Tôi đã thử workflow spec-driven của Kiro và nó tạo ra một đống danh sách công việc khổng lồ (mỗi task có hơn 4 subtask, tổng cộng hơn 12 task), bản thân workflow thì ổn nhưng nó xóa code một cách khó lường và cũng không rollback lại, có vẻ vì được làm thành IDE nên tài nguyên bị hút vào xử lý các case ngoại lệ của UI, thay vì chia nhỏ phức tạp như vậy thì cứ lặp đơn giản rồi cải tiến còn dễ hơn, đúng kiểu “dùng búa tạ để đập quả óc chó”

  • Tôi thích cách dùng slash command tùy chỉnh để gói input thành prompt có cấu trúc tốt, và cũng thấy hay ở chỗ nó bơm thêm làm context những phần được tách ra từ agents.md hay các file tương tự<br /> Tuy nhiên, tôi không thích việc cứ cố gỡ hết mọi nút thắt theo kiểu lại thành “lấy búa đập quả óc chó” như vậy, tức là tự sinh ra thêm độ phức tạp, nhưng nếu chỉ thêm các slash command khi thật sự cần (/experiment, /stub, v.v.) để quản lý context theo kiểu chọn lọc thì có thể nhẹ hơn, rồi cuối cùng dùng một lệnh chuyên để kết thúc như "/wrap-up" để gom mọi thứ lại một lần, giống như bác sĩ tổng kiểm tra sau khi kết thúc ca mổ

  • Khi dùng SpecKit tôi luôn có câu hỏi là “đến bao giờ thì tất cả các spec này mới được hợp nhất thành một chuẩn đúng duy nhất (ground truth)?” và thấy tiếc vì dường như không hề có bước đó<br /> Giờ đây vẫn còn bài toán phải định nghĩa và thiết kế xem đặc tả giao tiếp (spec) giữa con người và agent nên có hình dạng ra sao, tôi đang suy nghĩ về cách hiện thực hóa khái niệm “spec anchored” mà Birgitta đã nói đến

    • Từ khi AI xuất hiện, tôi cảm thấy giờ đúng là lúc phải định nghĩa nghiêm túc các tiêu chuẩn kiểu này, đặc tả cần được chuẩn hóa đến mức con người còn đọc và quản lý được, đồng thời cũng đủ để có thể đưa vào context của LLM ít nhất là một phần chứ không nhất thiết toàn bộ, và ngay cả khi chỉ ingest một phần thông tin thì vẫn phải giữ được ý đồ cốt lõi và thiết kế, dưới dạng có thể thực hiện công việc thực tế Tôi cho rằng các nỗ lực kiểu UML hay Rational Rose đã thất bại vì chúng không chứa ý đồ một cách cụ thể mà chỉ dừng ở sơ đồ, nên chỉ được dùng ở giai đoạn tài liệu hóa, bảo trì, refactor, thành ra đến lúc có ích thì sản phẩm đã phát hành xong nên trở nên vô nghĩa Giờ tôi bắt đầu chú ý đến những cách tiếp cận mới như mô hình C4

  • Tôi không rõ vì sao SDD đột nhiên trở thành xu hướng, nhưng cá nhân tôi chỉ đơn giản thấy việc tạo file đặc tả giúp “hình dung trước kết quả đầu ra cuối cùng”, và khi chia nhỏ dự án thì cũng tiện để theo dõi tiến độ, tôi không dùng công cụ hay framework nào riêng cả, chỉ dùng file markdown, còn hệ thống phức tạp hơn thế thì tôi không thấy có nhiều giá trị

  • Khi lần đầu dùng spec-kit tôi thật sự rất kỳ vọng, nhưng trên thực tế nó cứ cố tạo ra những việc đến mức như “chế tạo robot trong hang động”, ngay cả việc chỉ cần siết một con ốc cũng bị nó mở rộng quá đà, khiến tôi sửa mãi rồi mệt quá mà bỏ cuộc, tôi thấy workflow phức tạp quá mức đến độ không đáng để bỏ công hiệu chỉnh nữa
 
jjw9512151 2025-10-20

Thực ra, nếu nghĩ đơn giản thì đây là việc làm những gì đã học trong kỹ nghệ phần mềm bằng Markdown, nên khá thực dụng. Chỉ cần viết tốt tài liệu đặc tả yêu cầu là được.