Brainstorming & Design
Quy tắc đầu tiên và quan trọng nhất: KHÔNG THỂ VIẾT CODE CHO ĐẾN KHI NGƯỜI DÙNG PHÊ DUYỆT THIẾT KẾ.
Tại Sao Brainstorming Phải Đến Trước
Sai lầm tốn kém nhất trong phát triển phần mềm là xây dựng đúng cái sai. Bạn có thể có code hoàn hảo, coverage test đầy đủ, kiến trúc sạch — và vẫn giao ra thứ gì đó không giải quyết được vấn đề thực sự.
Brainstorming không phải là thủ tục. Đây là giai đoạn để những hiểu nhầm nổi lên trước khi chúng trở thành bug. Đây là nơi scope được làm rõ, các cách tiếp cận được so sánh, và mọi người đồng nhất về ý nghĩa thực sự của "hoàn thành".
Trong Superpowers, brainstorming được thực thi bởi một hard gate: AI bị cấm rõ ràng không được viết bất kỳ production code nào cho đến khi người dùng đã review và phê duyệt thiết kế. Đây không phải khuyến nghị mềm. Đây là ràng buộc hành vi.
The Hard Gate
╔══════════════════════════════════════════════════════════════╗
║ HARD GATE: NO CODE MAY BE WRITTEN UNTIL THE USER ║
║ HAS EXPLICITLY APPROVED THE PROPOSED DESIGN. ║
╚══════════════════════════════════════════════════════════════╝
Khi bạn gọi skill brainstorming, AI vào chế độ mà việc tạo code bị chặn. Nó có thể viết pseudocode, diagram, phác thảo cấu trúc file, hoặc đoạn ví dụ để minh họa một cách tiếp cận — nhưng không có implementation code thực sự cho đến khi bạn nói "đồng ý" hoặc xác nhận tương đương.
Gate này tồn tại vì code viết sớm là nguồn gốc chính của lãng phí công sức. Khi code đã tồn tại, nó tạo áp lực tâm lý để giữ lại. Mọi người tranh luận ủng hộ code họ đã viết. Các quyết định thiết kế bị ràng buộc bởi các lựa chọn implementation được đưa ra quá sớm. Hard gate ngăn chặn cái bẫy này.
Quy Trình Brainstorming 7 Bước
Bước 1: Explore (Khám Phá)
AI bắt đầu bằng cách diễn đạt lại yêu cầu bằng ngôn ngữ của mình để xác nhận sự hiểu biết. Nó xác định vấn đề cốt lõi đang được giải quyết — không chỉ là tính năng được yêu cầu.
Ví dụ: "Có vẻ như vấn đề thực sự là người dùng không thể theo dõi trạng thái đơn hàng sau khi thanh toán. Điều đó có đúng không?"
Bước 2: Question (Đặt Câu Hỏi)
AI đặt các câu hỏi làm rõ — từng câu một. Không phải danh sách 10 câu hỏi ngay từ đầu. Một câu hỏi, chờ câu trả lời, rồi câu hỏi tiếp theo nếu cần.
Quy tắc này tồn tại vì các câu hỏi hàng loạt thường quá tải và thường dẫn đến các câu trả lời nửa vời. Các câu hỏi tuần tự dẫn đến thông tin chính xác hơn và cuộc trò chuyện tự nhiên hơn.
Bước 3: Approaches (Các Cách Tiếp Cận)
Khi AI có đủ thông tin, nó trình bày 2–3 cách tiếp cận khác nhau để giải quyết vấn đề. Mỗi cách tiếp cận bao gồm:
- Mô tả ngắn gọn
- Các quyết định kỹ thuật chủ chốt liên quan
- Trade-off (ưu và nhược điểm, không chỉ là lời khen)
- Ước tính sơ bộ về độ phức tạp
Bước 4: Present (Trình Bày)
Các cách tiếp cận được trình bày rõ ràng kèm theo khuyến nghị khi phù hợp. AI không ẩn sau "tùy thuộc" — nó đưa ra ý kiến trong khi làm rõ các giả định đằng sau ý kiến đó.
Bước 5: Spec (Đặc Tả)
Sau khi bạn chọn hoặc sửa đổi một cách tiếp cận, AI viết một design specification — một tài liệu ngắn gọn mô tả những gì sẽ được xây dựng, những gì sẽ không được xây dựng, và cách các phần kết hợp với nhau. Đây trở thành kim chỉ nam cho kế hoạch implementation.
Bước 6: Review (Xem Xét)
Bạn review spec. Bạn có thể yêu cầu thay đổi, làm rõ, hoặc một cách tiếp cận khác. AI lặp lại cho đến khi spec chính xác.
Bước 7: Transition (Chuyển Giao)
Khi bạn phê duyệt spec, brainstorming kết thúc. AI xác nhận gate đã được mở và chuyển sang giai đoạn lập kế hoạch. Spec đã được phê duyệt trở thành đầu vào cho Viết Kế Hoạch.
Quy Tắc Một Câu Hỏi Mỗi Lần
Quy tắc này đủ quan trọng để nhắc đến rõ ràng.
Cách tiếp cận sai:
"Trước khi tôi có thể giúp bạn, tôi cần biết: (1) Bạn đang dùng database nào? (2) Bạn có cần authentication không? (3) Đây nên là REST hay GraphQL API? (4) Target deployment của bạn là gì? (5) Bạn có cần caching không?"
Điều này quá tải và thường tạo ra các câu trả lời mơ hồ vì người dùng cố gắng trả lời tất cả cùng một lúc.
Cách tiếp cận đúng:
"Bạn đang dùng database nào?"
Chờ câu trả lời, sau đó:
"Bạn có cần user authentication cho tính năng này không?"
Chờ câu trả lời, rồi tiếp tục.
Các câu hỏi tuần tự cảm giác như một cuộc trò chuyện. Các câu hỏi hàng loạt cảm giác như một biểu mẫu. Các cuộc trò chuyện tạo ra thông tin tốt hơn.
Multiple Choice Khi Có Thể
Bất cứ khi nào một câu hỏi có các câu trả lời phổ biến đã biết, AI nên trình bày chúng dưới dạng tùy chọn thay vì câu hỏi mở.
Ít hữu ích hơn:
"Bạn cần loại lưu trữ dữ liệu nào?"
Hữu ích hơn:
"Để lưu trữ dữ liệu, cái nào phù hợp nhất? A) PostgreSQL (quan hệ, ACID compliant) B) MongoDB (document store, schema linh hoạt) C) Redis (in-memory, caching/sessions) D) Thứ khác (vui lòng chỉ định)"
Multiple choice giảm tải nhận thức, neo cuộc trò chuyện vào các tùy chọn thực tế, và tăng tốc giai đoạn brainstorming.
Trình Bày 2–3 Cách Tiếp Cận Với Trade-off
Khi AI trình bày các cách tiếp cận, nó nên theo cấu trúc này:
## Approach A: [Tên]
**Description:** [Cách tiếp cận này làm gì]
**Technical decisions:** [Các lựa chọn chủ chốt mà cách tiếp cận này đưa ra]
**Pros:** [Những gì tốt về nó]
**Cons:** [Những gì không tốt về nó, một cách trung thực]
**Best for:** [Khi nào cách tiếp cận này hợp lý]
## Approach B: [Tên]
...
## Recommendation
[Cách tiếp cận được AI khuyến nghị và lý do đằng sau nó]
AI không bao giờ nên trình bày chỉ một cách tiếp cận (đó không phải là lựa chọn) hoặc nhiều hơn ba (đó là tê liệt quyết định). Hai đến ba là phạm vi hữu ích.
Visual Companion (Tính Năng v5.0)
Superpowers v5.0 giới thiệu Visual Companion — khả năng AI tạo ra các ASCII diagram, flow chart, và phác thảo kiến trúc như một phần của output brainstorming.
Các hình ảnh trực quan này giúp truyền đạt các thiết kế phức tạp mà không cần các công cụ bên ngoài. Ví dụ:
User → [API Gateway] → [Auth Service]
↘
[Order Service] → [Database]
↗
[Inventory Service]
Khi một thiết kế liên quan đến nhiều component, luồng dữ liệu, hoặc chuyển đổi trạng thái, hãy yêu cầu AI đưa vào visual companion trong spec của nó.
Anti-Pattern Cần Tránh
Giai đoạn brainstorming thường thất bại theo những cách sau:
| Anti-Pattern | Trông như thế nào | Tại sao nó có hại |
|---|---|---|
| Vội vàng viết code | "Tôi sẽ bắt đầu implement và chúng ta có thể điều chỉnh" | Sunk cost fallacy ngay lập tức |
| False agreement | AI nói "đã hiểu" nhưng chưa xác nhận yêu cầu | Hiểu nhầm tồn tại đến implementation |
| Single approach | AI đề xuất một tùy chọn và xin phê duyệt | Không phải lựa chọn thiết kế thực sự |
| Over-specification | Tài liệu thiết kế bao gồm mọi edge case trước khi luồng cơ bản được đồng ý | Analysis paralysis |
| Scope creep acceptance | AI thêm tính năng "khi chúng ta đang làm" | Phình to implementation, trì hoãn giao hàng |
| Vague approval | Người dùng nói "nghe có vẻ ổn" với spec họ chưa đọc | Gate trở thành màn trình diễn |
Pre-Planning Checklist
Trước khi chuyển từ brainstorming sang planning, hãy xác minh:
Nếu bất kỳ mục nào chưa được đánh dấu, không tiến hành planning. Quay lại brainstorming và lấp đầy khoảng trống.
Bắt Đầu Một Phiên Brainstorming
Để gọi skill brainstorming một cách rõ ràng:
"I want to add [tính năng]. Let's brainstorm before writing any code."
Hoặc dùng slash command nếu có:
/brainstorm I want to build a notification system
AI sẽ vào chế độ brainstorming và hard gate sẽ được kích hoạt. Không có gì được xây dựng cho đến khi bạn nói thiết kế đã được phê duyệt.
Kỷ luật brainstorming mang lại lợi nhuận kép. Mỗi giờ dành để đồng nhất yêu cầu trước khi viết code tiết kiệm 3–5 giờ làm lại sau này. Hard gate không phải là rào cản thủ tục — đó là một khoản đầu tư.