Chọn workflow theo model: khi nào brainstorm, khi nào advise, khi nào bỏ luôn bước plan

Bài 12 trong bộ onboarding AgentKit v3. Đọc khoảng 9 phút.

Mấy bữa nay trên Discord, tui chia sẻ workflow mới của tui với Opus 5.5: không cần plan → clear → cook nữa. Vậy là anh em hỏi dồn liền 😂 "Vậy /ak-brainstorm để chỗ nào?", "Dùng /ak-advise thay brainstorm hay dùng chung?", "Có cần worktree cho mỗi session không?".

Bài này trả lời gọn mấy câu đó một lần cho xong.

1/ Tại sao model mạnh không cần bước plan riêng nữa?

Lý do đơn giản: Opus 5.5 bám mục tiêu quá tốt. Đưa nó một cái đích rõ ràng là nó tự chia việc, tự kiểm tra, tự đi tới cuối. Bắt nó viết plan ra file, /clear context rồi đọc lại plan để cook, nhiều khi chỉ tốn thêm token mà không thêm chất lượng.

Nhưng có một cái bẫy. Model giỏi bám mục tiêu, mà mục tiêu mơ hồ thì nó bám cái mơ hồ. Garbage in, garbage out. Prompt lơ mơ thì kết quả cũng lơ mơ, chỉ là lơ mơ một cách rất tự tin 😁

Nên với model mạnh, việc quan trọng nhất không còn là viết plan. Việc quan trọng nhất là chốt DoD (Definition of Done): lúc nào thì coi như xong, kiểm chứng bằng cái gì. Bạn với agent phải nhìn cùng một vạch đích.

2/ AI build được gần như mọi thứ, không có nghĩa là bạn nên build mọi thứ

AI làm cho việc build dễ tới mức nguy hiểm. Nghĩ ra cái gì là có code cái đó trong vài phút. Nhưng dễ build không có nghĩa là cần build 😁

Nên tui luôn mở đầu mọi session với AI bằng việc brainstorm, và chia thành 4 câu hỏi theo thứ tự:

1. Ý tưởng là [...], mục tiêu là [...]. Hãy phỏng vấn tôi cho tới khi bạn hiểu chính xác tôi đang nghĩ gì, sau đó rà soát, research, phân tích và đề xuất.

2. Có điều gì tôi đã bỏ lỡ không? Có điều gì tôi chưa nghĩ tới không?

3. Theo bạn, tôi có thực sự cần build thứ này không? Có rủi ro hay đánh đổi nào tôi cần biết không? Có cách tiếp cận nào tốt hơn không? Dẫn chứng đâu?

4. Nếu vẫn quyết định build: mọi thứ đã đủ đơn giản để triển khai và đủ dễ để thay đổi khi cần chưa? Có nợ kỹ thuật không? Khi nào nên dừng lại?

Đừng hỏi cả 4 câu cùng lúc. Câu trả lời của câu trước ảnh hưởng tới câu sau. Hỏi từng câu để AI tập trung hoàn toàn vào một việc mỗi lần và đưa ra đề xuất tốt nhất. Câu 3 là câu quan trọng nhất, vì nhiều khi câu trả lời đúng là "khỏi build".

Trình tự tui đi luôn là:

vấn đề → kiểm chứng → phản biện → quyết định → chốt yêu cầu → triển khai

Tới bước chốt yêu cầu thì cho AI phỏng vấn bạn lần 2. Lần 1 là để hiểu ý tưởng. Lần 2 là để chắc cả hai đang on the same page: AI hiểu đúng thứ bạn kỳ vọng trong đầu, khoá scope of work và DoD. Đây chính là việc của /ak-advise.

Sau đó mới triển khai, tốt nhất là ở một context mới tinh, với input là decision brief (bản tóm tắt quyết định và DoD vừa chốt). Context sạch thì agent không bị kéo lệch bởi mấy hướng đã bàn rồi bỏ.

Hai lời khuyên nữa:

• Đừng hỏi "tôi nên dùng skill nào để làm việc này". Hãy học cách đặt câu hỏi. Câu hỏi tốt thì skill nào cũng ra kết quả tốt.

• Hãy linh hoạt. Sửa màu cái button thì không cần áp cả quy trình cồng kềnh này. Quy trình là để phục vụ những việc đáng làm kỹ, không phải để làm mọi việc chậm lại.

3/ Hai workflow, chọn theo model

Workflow cũ vẫn đúng cho model nhỏ. Model nhỏ dễ lạc đề khi context dài, nên plan ra file rồi /clear để nó đọc lại với context sạch vẫn là cách an toàn nhất.

Workflow cho model mạnh, từng bước

Bước 1: chạy /ak-advise. Nó sẽ phỏng vấn bạn vài câu, mỗi lần một câu, để hiểu kỳ vọng, yêu cầu và khoá phạm vi công việc. Trả lời thật, đừng trả lời cho có.

Bước 2: đọc kỹ phần advice và DoD nó in ra. Trong đó có mục Done means: danh sách trạng thái cuối kiểm chứng được, kiểu "mọi endpoint dùng client mới, client cũ đã xoá, test suite pass". Những chữ như "tốt hơn", "gọn hơn" không được tính là DoD. Thấy chỗ nào chưa đúng ý thì sửa ngay lúc này, vì đây là chỗ rẻ nhất để sửa.

Bước 3: nhảy thẳng vô /ak-cook. Không plan, không clear. Muốn đi một mạch tới PR thì dùng /ak-vibe --ship thay cho cook.

/ak-advise thêm đăng nhập bằng Google cho app, giữ nguyên đăng nhập email hiện tại
# trả lời phỏng vấn, đọc lại DoD, sửa nếu cần
/ak-cook

4/ Vậy /ak-brainstorm còn chỗ nào?

Còn chứ. Cách tui phân biệt:

• /ak-brainstorm: khi bạn chưa chắc nên làm gì. Nó giúp khám phá ý tưởng, đưa ra các hướng làm, so pros/cons, trade-off.

• /ak-advise: khi bạn đã biết mình muốn gì, và muốn agent hiểu chính xác cái đang nằm trong đầu bạn.

Hai cái dùng chung được. Ý tưởng còn mù mờ thì brainstorm trước để chọn hướng, rồi advise để khoá phạm vi và DoD, rồi cook:

/ak-brainstorm → /ak-advise → /ak-cook   (hoặc /ak-vibe --ship)

Còn đã rõ việc rồi thì bỏ brainstorm, đi thẳng advise cho lẹ.

5/ Có cần /ak-worktree cho mỗi session không?

Không cần cho mỗi session. Quy tắc tui xài:

• Một session làm một việc trên một repo: khỏi worktree, làm thẳng trên branch.

• Nhiều session chạy song song trên cùng một repo: nên dùng /ak-worktree, mỗi session một worktree, một branch. Lý do là hai agent sửa cùng một thư mục thì dễ đạp file của nhau, đổi branch của nhau, hoặc commit lẫn thay đổi của nhau.

Một lưu ý nhỏ: worktree nào có dev server hay watcher thì nhớ tắt process trước khi xoá worktree, kẻo máy đầy process mồ côi.

Tóm lại

1/ Model mạnh: /ak-advise → đọc lại DoD → /ak-cook. Thời gian bạn bỏ ra nằm ở việc chốt DoD, không nằm ở plan.

2/ Model nhỏ: giữ brainstorm → plan → clear → cook.

3/ Chưa biết làm gì thì brainstorm. Biết rồi thì advise.

4/ Worktree chỉ cần khi nhiều session chạy song song trên cùng repo.

5/ Trước khi build, hỏi "có thực sự cần build không?". Hỏi từng câu một, rồi triển khai ở context mới với decision brief. Việc nhỏ thì khỏi quy trình.

Nguồn

• Thảo luận trên Discord AgentKit, 29–30/10/2026.

• Mô tả skill ak-advise, ak-brainstorm, ak-cook, ak-vibe, ak-worktree trong kit ak 3.0.0.