Chương 9: Luật Sắt & Anti-Pattern
Các Luật Sắt là những quy tắc không thể thương lượng chi phối mọi phiên làm việc với một agent được kích hoạt Superpowers. Chúng không phải là hướng dẫn, mặc định, hay đề xuất. Chúng là các ràng buộc cứng không thể bị ghi đè bởi hướng dẫn, sự khẩn cấp, hoặc sự tiện lợi.
Hiểu tại sao những luật này tồn tại — và điều gì xảy ra khi chúng bị vi phạm — là điều cần thiết để sử dụng Superpowers hiệu quả.
4 Luật Sắt
Luật Sắt 1: TDD
"KHÔNG CÓ CODE SẢN XUẤT MÀ KHÔNG CÓ TEST THẤT BẠI TRƯỚC"
Mỗi tính năng, mỗi sửa lỗi, mỗi thay đổi hành vi phải được đi trước bởi một test thất bại mô tả hành vi mong muốn. Đây là Test-Driven Development (TDD) được áp dụng nghiêm ngặt.
Tại sao điều này không thể thương lượng:
Không có test thất bại trước, bạn không có bằng chứng rằng code của bạn làm những gì bạn nghĩ nó làm. Bạn đang implement và hy vọng. Với test thất bại trước, bạn có một thông số chính xác mà implementation của bạn phải thỏa mãn — và một cơ chế xác minh chạy mãi mãi.
Điều này ngăn chặn:
- Implement sai thứ với sự tự tin
- Các test luôn đạt vì chúng không test gì cả
- "Tôi chắc nó hoạt động" như là xác minh duy nhất
- Regression khi code thay đổi sáu tháng sau
Cách áp dụng:
1. Viết test → nó thất bại (RED)
2. Viết code tối thiểu để làm nó đạt (GREEN)
3. Refactor mà không phá vỡ test (REFACTOR)
Nếu bạn không thể viết một test thất bại, bạn chưa hiểu yêu cầu đủ để implement nó. Dừng lại và làm rõ.
Luật Sắt 2: Xác Minh
"KHÔNG CÓ TUYÊN BỐ HOÀN THÀNH MÀ KHÔNG CÓ BẰNG CHỨNG XÁC MINH MỚI"
Bạn không được tuyên bố rằng công việc hoàn chỉnh, đã sửa, hoặc đang đạt trừ khi bạn vừa chạy xác minh và có output trước mặt bạn.
Tại sao điều này không thể thương lượng:
Các mô hình tinh thần không đáng tin cậy. Một thay đổi "sẽ hoạt động" thường không. Code "đã hoạt động trước đó" có thể bị phá vỡ bởi một thay đổi tiếp theo. Bằng chứng hợp lệ duy nhất là output của việc chạy lệnh xác minh thực tế ngay bây giờ.
Điều này ngăn chặn:
- Giao code bị hỏng với sự tự tin cao
- Mô hình thất bại "nó hoạt động trên máy tôi"
- Kết quả test cũ được xem là hiện tại
- Đảm bảo bằng lời nói thay thế cho bằng chứng
Xác minh phải mới: Chạy test năm commit trước và tuyên bố trạng thái hiện tại ổn không phải là xác minh. Chạy test trên trạng thái hiện tại, đọc output, sau đó đưa ra tuyên bố.
Luật Sắt 3: Debug
"KHÔNG CÓ SỬA LỖI MÀ KHÔNG CÓ ĐIỀU TRA NGUYÊN NHÂN GỐC TRƯỚC"
Trước khi viết bất kỳ code sửa lỗi nào, bạn phải hoàn thành điều tra nguyên nhân gốc như được mô tả trong Chương 6. Bạn phải có khả năng nêu, trong một câu, chính xác điều gì đang gây ra bug.
Tại sao điều này không thể thương lượng:
Sửa triệu chứng mà không hiểu nguyên nhân là nguyên nhân chính của việc tích lũy nợ kỹ thuật. Mỗi lần sửa triệu chứng thêm sự phức tạp, che giấu vấn đề thực sự, và làm cho nguyên nhân gốc khó tìm hơn sau này. Codebase trở thành một tập hợp các patch mà không ai hiểu.
Điều này ngăn chặn:
- Bug tương tự tái xuất hiện ở dạng khác
- Chuỗi sửa lỗi mà mỗi lần sửa phá vỡ thứ khác
- Mất sự rõ ràng về kiến trúc
- Mô hình 3 Lần Thất Bại (xem Chương 6)
Kiểm tra tuyên bố nguyên nhân gốc: Trước khi thực hiện sửa lỗi, bạn phải có khả năng hoàn thành câu này mà không do dự: "Bug được gây ra bởi [thứ cụ thể] vì [bằng chứng]." Nếu bạn không thể, điều tra chưa hoàn chỉnh.
Luật Sắt 4: Skills
"KHÔNG CÓ SKILL MÀ KHÔNG CÓ TEST THẤT BẠI TRƯỚC"
Khi tạo hoặc sửa đổi một Superpowers skill, cùng quy tắc TDD áp dụng. Viết một test chứng minh hành vi dự kiến của skill, xác minh nó thất bại, sau đó implement skill.
Tại sao điều này không thể thương lượng:
Skills là code. Chúng có hành vi có thể đúng hoặc sai. Không có test, phát triển skill cũng không đáng tin cậy như bất kỳ code nào khác chưa được test — nó hoạt động cho đến khi không, và bạn không có cách nào biết khi nào nó ngừng hoạt động hoặc tại sao.
Bảng Dấu Hiệu Đỏ Tổng Hợp
Đây là các dấu hiệu cảnh báo rằng một Luật Sắt sắp bị vi phạm. Khi bạn quan sát thấy bất kỳ dấu hiệu nào trong số này, DỪNG hành động hiện tại và quay lại giao thức đúng.
| # | Dấu Hiệu Đỏ | Tín Hiệu | Hành Động DỪNG |
|---|---|---|---|
| 1 | "Cái này sẽ hoạt động" | Xác minh đã bị bỏ qua | Chạy lệnh xác minh ngay bây giờ |
| 2 | "Có lẽ ổn" | Giả định không có bằng chứng | Tìm bằng chứng hoặc thừa nhận sự không chắc chắn |
| 3 | "Các test sẽ đạt" | Test chưa được chạy | Chạy test |
| 4 | "Hãy để tôi thử cách sửa này" | Không có điều tra nguyên nhân gốc | Hoàn thành Giai đoạn 1 của debug trước |
| 5 | "Tôi sẽ thêm test sau" | Vi phạm TDD đang tiến hành | Viết test thất bại trước, ngay bây giờ |
| 6 | "Đây là thay đổi nhỏ, không cần test" | Ngoại lệ TDD đang được phát minh | Không có ngoại lệ. Viết test. |
| 7 | "Bạn hoàn toàn đúng!" (ngay lập tức) | Đồng ý mang tính hình thức | Đọc → Hiểu → Xác minh → Đánh giá trước |
| 8 | Sửa test để khớp với hành vi bị hỏng | Che giấu bug | Sửa code, không phải test |
| 9 | Commit trực tiếp vào main | Bỏ qua giao thức cách ly | Tạo một worktree và branch |
| 10 | Lần sửa lỗi thứ tư cùng bug | Vấn đề kiến trúc đang bị che giấu | Dừng lại. Thiết kế lại. Đừng tiếp tục vá lỗi. |
| 11 | Tóm tắt output test thay vì hiển thị nó | Có thể ảo giác hoặc đọc có chọn lọc | Hiển thị output thực tế |
| 12 | Bỏ qua test baseline trong worktree mới | Trạng thái bắt đầu không rõ ràng | Chạy toàn bộ bộ test trước khi viết bất kỳ code nào |
Tóm Tắt Anti-Pattern
Các anti-pattern sau xuất hiện trên tất cả các chương của hướng dẫn này. Chúng được thu thập ở đây như một tài liệu tham khảo.
Từ Chương 1: Nền Tảng
- Cấu Hình Tool Sai: Sử dụng Superpowers mà không đọc CLAUDE.md hoặc tài liệu thiết lập. Skills yêu cầu cấu hình đúng để trigger chính xác.
- Bỏ Qua Skill: Yêu cầu agent "cứ làm đi" mà không gọi skill phù hợp. Skills tồn tại vì một lý do; bỏ qua chúng tạo ra output chất lượng thấp hơn.
Từ Chương 2: Viết Kế Hoạch
- Implementation Không Có Kế Hoạch: Bắt đầu viết code trước khi một kế hoạch được viết và review. Kế hoạch bắt các vấn đề kiến trúc một cách rẻ tiền; code thì không.
- Kế Hoạch Mơ Hồ: Viết kế hoạch theo kết quả hơn là các bước cụ thể. "Implement xác thực" không phải là một kế hoạch. Một chuỗi đánh số các hành động cụ thể là một kế hoạch.
Từ Chương 3: Thực Thi Kế Hoạch
- Thực Thi Tuần Tự Các Nhiệm Vụ Độc Lập: Chạy các nhiệm vụ từng cái một khi chúng có thể được song song hóa. Điều này nhân thời gian thực tế không cần thiết.
- Trạng Thái Chia Sẻ Giữa Các Nhiệm Vụ Song Song: Chạy các nhiệm vụ song song sửa đổi cùng một file hoặc trạng thái. Điều này tạo ra merge conflict và race condition.
Từ Chương 4: TDD
- Test Sau Implementation: Viết test sau khi code đã được viết. Các test này có khả năng được định hình xung quanh implementation hơn là yêu cầu.
- Test Chi Tiết Implementation: Viết test phá vỡ mỗi lần code được refactor, ngay cả khi hành vi không thay đổi. Test hành vi, không phải implementation.
Từ Chương 5: Brainstorming
- Bỏ Qua Brainstorm Trước Implementation: Đi thẳng đến coding mà không khám phá không gian vấn đề. Brainstorm là bắt buộc trước bất kỳ công việc sáng tạo nào.
- Xem Brainstorm Như Một Hình Thức: Thực hiện các động tác brainstorm mà không thực sự khám phá các lựa chọn thay thế. Giá trị nằm ở việc khám phá, không phải nghi lễ.
Từ Chương 6: Debug
- Đoán Mò và Kiểm Tra: Thử sửa lỗi mà không điều tra nguyên nhân gốc. Đây là nguồn chính của mô hình 3 Lần Thất Bại.
- Sửa Nhiều Thứ Cùng Lúc: Thực hiện nhiều thay đổi để giải quyết một bug, khiến không thể biết thay đổi nào đã hoạt động.
- Tuyên Bố Hoàn Thành Sớm: Nói "đã sửa" trước khi chạy xác minh.
Từ Chương 7: Code Review
- Đồng Ý Mang Tính Hình Thức: Ngay lập tức đồng ý với phản hồi review mà không đánh giá nó. Điều này áp dụng các đề xuất xấu vào code đang hoạt động.
- Bỏ Qua Mức Độ Nghiêm Trọng: Xem tất cả phản hồi như nhau về mức độ khẩn cấp. Các vấn đề Critical thì chặn; các vấn đề Minor được ghi lại.
Từ Chương 8: Git Worktrees
- Commit Trực Tiếp Vào Main: Bất kỳ thay đổi nào vào main ngoài merge hoặc PR. Main luôn là trạng thái có thể triển khai.
- Làm Việc Không Có Test Baseline: Bắt đầu công việc tính năng mà không trước tiên xác minh rằng tất cả test đạt trên branch base.
Thực Thi
Các Luật Sắt được thực thi bởi hành vi agent, không phải bởi tooling. Khi bạn quan sát thấy một vi phạm — dù bởi agent hay bởi các hướng dẫn sẽ gây ra vi phạm — phản hồi đúng là đặt tên cho luật đang bị vi phạm và quay lại giao thức đúng.
Điều này không phải là cản trở. Đây là cách chất lượng được duy trì. Mỗi ngoại lệ đối với một Luật Sắt là một cược rằng trường hợp cụ thể này đặc biệt đủ để bảo hành nó. Cược đó hầu như luôn sai.