Clean-room với REA và AI: Viết lại tính năng từ SPEC có bằng chứng

Tái xây dựng tính năng bằng AI: vấn đề không chỉ là viết code

Khi cần làm lại một tính năng cũ, cách yêu cầu AI “refactor lại phần này” có thể khiến bản mới kế thừa cả giả định sai, nhánh xử lý khó hiểu hoặc lỗi đã tồn tại trong hệ thống. Một hướng tiếp cận thận trọng hơn là tách quá trình thành hai vùng làm việc: vùng thứ nhất chỉ điều tra hành vi và lập đặc tả có bằng chứng; vùng thứ hai chỉ nhận đặc tả đã được duyệt để xây dựng một triển khai độc lập.

Đây là mô hình clean-room theo hướng spec-first. REA có thể hỗ trợ quá trình điều tra; reviewer độc lập kiểm tra từng nhận định; một phiên làm việc mới triển khai theo SPEC.md; sau đó bộ kiểm thử xác nhận hành vi. Đây là workflow do nhóm phát triển tự thiết kế quanh các công cụ, không phải tuyên bố rằng REA tự động cung cấp sẵn toàn bộ chuỗi REA, Jev, Opus, Haiku.

REA làm gì, và không làm gì?

REA, viết tắt của Reverse Engineer Anything, là dự án cung cấp CLI và MCP để agent khảo sát ứng dụng, mã nhị phân và hành vi runtime. Tài liệu dự án mô tả việc agent gọi REA để kiểm tra mục tiêu, truy vết mã liên quan và nhận kết quả kèm bằng chứng, giới hạn và những điểm chưa rõ. Dữ liệu phân tích được xử lý cục bộ theo tài liệu dự án; phần kết quả vẫn được chuyển cho agent/model đang sử dụng, vì vậy cần xem thêm chính sách dữ liệu của nhà cung cấp model.

REA không nên được xem như một nút bấm tự động tạo ra bản SPEC.md hoàn hảo hoặc bảo đảm tính năng mới không còn lỗi. Đặc tả vẫn cần người chịu trách nhiệm quyết định phạm vi, đánh giá bằng chứng, phân biệt quan sát với suy luận và phê duyệt những phần còn chưa rõ.

Bắt đầu bằng lệnh cài đặt được dự án hướng dẫn:

npx rea-agents setup

Đọc kỹ kế hoạch thay đổi cấu hình trước khi chấp thuận, chọn agent muốn tích hợp và khởi động lại agent sau khi hoàn tất. Hướng dẫn chính thức và gói npm có thể thay đổi, nên hãy kiểm tra hướng dẫn cài đặt mới nhất trước khi chạy lệnh. Trang dự án chính thức: morluto/rea trên GitHub. Gói phát hành: rea-agents trên npm.

Quy trình clean-room đề xuất

1. Xác định phạm vi trước khi điều tra

Ghi rõ ứng dụng, phiên bản, tính năng cần hiểu, hành vi đầu vào/đầu ra và những phần không thuộc phạm vi. Chỉ phân tích phần mềm bạn sở hữu, được phép kiểm tra hoặc có quyền hợp pháp để nghiên cứu. Nếu tính năng phụ thuộc dịch vụ bên ngoài, dữ liệu người dùng hay hệ thống thanh toán, hãy xác định môi trường thử nghiệm và dữ liệu giả lập trước.

2. Room A: điều tra và tạo sổ bằng chứng

Dùng REA cùng các phép kiểm tra cần thiết để thu thập hành vi có thể quan sát được. Không biến phỏng đoán thành quy tắc. Mỗi quy tắc nên có mã định danh và các trường tối thiểu sau:

• Quy tắc: điều kiện, đầu vào, kết quả mong đợi và các trạng thái liên quan.
• Bằng chứng: tham chiếu kết quả REA, vị trí quan sát, log hoặc bước tái hiện; lưu phiên bản/hash artifact nếu phù hợp.
• Phân loại: quan sát trực tiếp, suy luận có căn cứ hoặc chưa xác định.
• Giới hạn: nền tảng, trạng thái runtime hay nhánh chưa kiểm tra được.
• Tiêu chí kiểm thử: cách kiểm tra quy tắc trong bản triển khai mới.

SPEC.md phải mô tả hợp đồng hành vi, không phải bản sao mã nguồn. Tránh đưa đoạn mã gốc hoặc các phần triển khai không cần thiết vào tài liệu bàn giao.

3. Reviewer độc lập: duyệt từng quy tắc

Một reviewer riêng, có thể là người hoặc agent được giao vai trò kiểm duyệt (ví dụ tên vai trò “Jev” trong workflow của nhóm), đánh dấu mỗi quy tắc là pass, return hoặc unclear. Quy tắc thiếu bằng chứng cần được trả về để điều tra tiếp; quy tắc chưa giải quyết được phải được ghi là unknown, không tự điền bằng suy đoán.

Trước khi khóa đặc tả, lưu phiên bản và lịch sử duyệt. Nếu phạm vi thay đổi, cập nhật SPEC và chạy lại bước review thay vì sửa ngầm khi đã bắt đầu triển khai.

4. Room B: phiên xây dựng mới, chỉ nhận SPEC đã duyệt

Tạo phiên làm việc và môi trường mã nguồn riêng. Builder chỉ được cung cấp SPEC.md, tài nguyên được phép sử dụng và yêu cầu kỹ thuật tổng quát. Không mở repository, file dump hay log có chứa mã nguồn gốc. Nếu có thể, dùng quyền truy cập, workspace hoặc tài khoản riêng để giảm khả năng vô tình nhìn thấy tài liệu từ Room A.

Trong mẫu workflow này, có thể chọn Claude Opus 5.5 cho công việc triển khai phức tạp và Claude Haiku 5.5 cho các tác vụ kiểm thử lặp lại. Đây là lựa chọn phân công theo workflow, không phải yêu cầu bắt buộc của REA. Anthropic đã công bố các model này vào tháng 9 và tháng 10 năm 2026; hãy kiểm tra trang model chính thức để xác nhận khả năng, ID và điều kiện sử dụng hiện tại.

5. Viết kiểm thử theo đặc tả, rồi kiểm tra cả kiểm thử

Viết test từ những điều kiện được duyệt, không chỉ từ cách builder hiện thực hóa tính năng. Bao phủ đường đi thành công, dữ liệu biên, đầu vào không hợp lệ, lỗi phụ thuộc, phân quyền, trạng thái bất thường và hồi quy quan trọng.

Sau đó tạo các biến thể có chủ đích bị làm sai, chẳng hạn bỏ một bước xác thực, thay đổi điều kiện biên hoặc bỏ xử lý lỗi. Bộ kiểm thử cần phát hiện và đánh trượt biến thể lỗi, trong khi bản triển khai hợp lệ vẫn vượt qua. Ba biến thể là một sanity check nhỏ, không phải bằng chứng rằng test suite đã đủ mạnh hoặc không còn lỗi. Khi có điều kiện, hãy bổ sung mutation testing có hệ thống, kiểm thử tích hợp và kiểm thử thủ công.

6. Đặt điều kiện dừng rõ ràng

Nếu dùng một vòng lặp agent để sửa lỗi, hãy định nghĩa trước tiêu chí hoàn tất, giới hạn số vòng, ngân sách và điều kiện dừng khi xuất hiện kết quả mơ hồ. Lệnh như /goal chỉ nên được dùng nếu môi trường của bạn thực sự cài đặt và hỗ trợ nó; không nên mặc định đây là chức năng của REA. Trước khi ship, reviewer cần xem lại thay đổi, kết quả test, log lỗi và mọi khác biệt so với SPEC.

Prompt mẫu để bắt đầu

Prompt A: điều tra, chưa viết code

Hãy điều tra tính năng [FEATURE] trong ứng dụng [APP] bằng REA và các bước kiểm tra được cho phép. Nhiệm vụ hiện tại CHỈ là điều tra và tạo SPEC.md, không viết hoặc sửa mã triển khai.

Với mỗi quy tắc, ghi: ID; điều kiện/đầu vào; hành vi quan sát được; kết quả mong đợi; trường hợp lỗi và biên; tham chiếu bằng chứng cụ thể; phân loại là quan sát, suy luận hay chưa rõ; giới hạn chưa kiểm tra; tiêu chí kiểm thử.

Không trình bày suy luận như sự thật. Quy tắc thiếu bằng chứng phải được đánh dấu để điều tra lại hoặc ghi rõ là chưa xác định. Không sao chép đoạn mã nguồn vào SPEC nếu không cần thiết. Trước hết hãy hiển thị toàn bộ SPEC.md để tôi duyệt. Không bắt đầu triển khai cho đến khi tôi ra lệnh chính xác: BẮT ĐẦU.

Prompt B: builder trong phiên riêng

Bạn đang ở một phiên clean-room mới. Nguồn thông tin được phép cho hành vi sản phẩm là SPEC.md đã được phê duyệt cùng các tài nguyên được cấp phép kèm theo. Không tìm, mở hoặc yêu cầu mã nguồn, dump, log hay tài liệu nội bộ từ ứng dụng gốc.

Trước khi code, lập kế hoạch triển khai và ma trận liên kết giữa từng quy tắc SPEC với test tương ứng. Hãy triển khai độc lập, ghi rõ điểm nào trong SPEC chưa đủ để quyết định và không tự bịa quy tắc sản phẩm. Chạy toàn bộ test; dùng các biến thể lỗi có chủ đích để kiểm tra khả năng phát hiện lỗi. Báo cáo rõ test pass/fail, biến thể nào bị phát hiện, các unknown còn tồn tại và giới hạn của kết quả. Không khẳng định hoàn tất nếu có tiêu chí chưa đáp ứng.

Dùng hai prompt trong hai ngữ cảnh thực sự tách biệt. Nếu builder đã nhìn thấy mã nguồn gốc thì không thể khắc phục điều đó chỉ bằng cách yêu cầu model “quên” nội dung đã xem.

Lợi ích và giới hạn cần hiểu

Cách tiếp cận spec-first giúp reviewer truy ngược quyết định về bằng chứng, làm rõ các quy tắc chưa chắc chắn trước khi code và giảm xu hướng sao chép nguyên thiết kế cũ theo quán tính. Việc tạo test từ hợp đồng hành vi cũng giúp nhóm nhận ra sớm khi đặc tả bị thiếu hoặc mâu thuẫn.

Tuy vậy, quy trình không đảm bảo bản mới sạch bug, ngắn hơn hay hợp pháp trong mọi bối cảnh. Bằng chứng có thể thiếu; một số hành vi chỉ xuất hiện ở runtime hoặc môi trường không kiểm tra được; đặc tả có thể bỏ sót nhánh hiếm. Việc tách môi trường kỹ thuật cũng không tự nó chứng minh tính độc lập pháp lý. Với phần mềm thương mại, thư viện, giao thức hoặc giao diện thuộc bên thứ ba, hãy rà soát giấy phép, điều khoản sử dụng, quyền sở hữu trí tuệ và yêu cầu pháp lý tại khu vực liên quan trước khi triển khai.

Nguồn chính thức

• REA: Reverse Engineer Anything và hướng dẫn về bằng chứng.
• Gói rea-agents trên npm.
• Anthropic: Claude Opus 5.5.
• Anthropic: Claude Haiku 5.5.

Thông tin về REA và model được đối chiếu ngày 20/10/2026. Tính năng, lệnh cài đặt và điều kiện sử dụng có thể thay đổi; hãy tham khảo tài liệu chính thức trước khi triển khai.