Solo-Engine V4 đã đúng hướng, nhưng V4.1 Final mới phù hợp để dùng lâu dài

Kết luận đánh giá

Không nên triển khai nguyên trạng Solo-Engine V4. Bản này đã xử lý đúng những rủi ro cốt lõi: không được bịa việc gọi công cụ, không được biến đoạn mã thành “bàn giao hoàn chỉnh”, không được coi ADR là đã được chấp nhận khi chưa có bằng chứng xác minh. Tuy nhiên, V4 vẫn còn quá nhiều quy tắc chồng lấp và chưa xác định đủ chặt ranh giới vận hành thực tế của một Gem.

Khuyến nghị cuối cùng: chọn Solo-Engine V4.1 Final. Đây không phải bản thêm nhiều quy định hơn, mà là bản nén và ưu tiên hóa quy định: các nguyên tắc về tính trung thực, công cụ, mã hoàn chỉnh, xác minh và điều kiện hoàn tất phải nằm ngay trong chỉ dẫn chính; SOP, bảng biểu và mẫu hồ sơ được chuyển sang knowledge base.

V4 đã làm đúng những gì?

• Tách /ana-solo cho phân tích – ra quyết định và /ana-bmad cho triển khai kỹ thuật.
• Phân biệt rõ FACT, INFERENCE, ASSUMPTION và UNKNOWN, giúp tránh biến suy luận thành sự thật.
• Cấm tuyên bố đã tìm web, chạy compiler, kiểm thử, ghi file, tạo Git diff hoặc triển khai khi không có công cụ thật.
• Tách bạch mã đã giao đủ với mã đã được xác minh chạy đúng.
• Có các cơ chế hữu ích như hard gate, Decision Matrix, Deep Recon, Preflight, Algorithm-Fit, backpressure khi thất bại và State Reconcile.
• Không để một Gem đơn lẻ tự nhận là đã điều phối nhiều agent độc lập. Tài liệu BMAD mô tả agent, skill, workflow và luồng kiểm thử như các cơ chế vận hành riêng; vì vậy, một Gem chỉ nên gọi đây là điều phối vai trò lấy cảm hứng từ BMAD, không phải runtime đa agent tương đương BMAD.11014

Những điểm cần sửa trước khi dùng lâu dài

1. Chỉ dẫn chính đang phụ thuộc quá nhiều vào knowledge base

Không thể coi việc mọi tệp knowledge base luôn được truy hồi đầy đủ ở mọi lượt phản hồi là một sự thật chắc chắn. Vì thế, các luật cứng như sau phải nằm trong main instruction:

• không bịa công cụ và kết quả chạy;
• không tuyên bố test hoặc build đã qua nếu không có bằng chứng;
• giao đầy đủ mọi tệp mới hoặc tệp đã sửa;
• không suy đoán interface nền còn thiếu;
• không đánh dấu hoàn tất kỹ thuật khi chưa đối soát trạng thái.

2. Quy tắc dày đặc làm giảm khả năng tuân thủ

V4 lặp lại quy tắc về trạng thái, dependency, ADR, xác minh và Definition of Done ở nhiều tệp. Nhiều quy tắc hơn không đồng nghĩa với tuân thủ tốt hơn: khi quy định trùng nhau, mô hình dễ chỉ làm theo một phần hoặc tạo ra các trạng thái mâu thuẫn.

V4.1 nên giữ một nguồn chân lý cho từng luật cứng, sau đó để SOP chỉ mở rộng cách thực hiện chứ không định nghĩa lại luật.

3. “Vòng lặp tự động” phải có ranh giới thực thi

Prompt không thể tự tạo ra background job, terminal bền vững hay khả năng chạy xuyên phiên. Trong V4.1, “automatic loop” chỉ được hiểu là vòng lặp:

• trong phản hồi hoặc phiên hiện tại;
• trong phạm vi người dùng đã ủy quyền;
• với công cụ thực sự đang khả dụng;
• có điều kiện dừng và ngân sách retry rõ ràng;
• dừng ở WAITING_VERIFICATION nếu không có execution environment.

4. “Không phụ thuộc” cần được định nghĩa theo chuẩn kỹ thuật

Khái niệm này không thể đồng thời có nghĩa là không cần runtime, không dùng thư viện bên thứ ba và không cần tệp nội bộ chưa được cung cấp. Định nghĩa nên tách thành:

• không có dependency chưa khai báo;
• mặc định không thêm dependency bên thứ ba;
• mọi dependency cục bộ mới phải được giao đầy đủ;
• runtime, compiler, SDK, hệ điều hành và host platform là điều kiện môi trường phải được nêu rõ.

5. “Mã hoàn chỉnh” phải khác nhau giữa dự án mới và dự án có sẵn

Với dự án mới, cần bàn giao tập tệp tối thiểu đủ để tạo thành một project closure: cấu hình build, entry point, source, test, resource cần thiết và lệnh xác minh.

Với dự án hiện có, phải xuất đầy đủ nội dung của mọi tệp thêm mới hoặc bị chỉnh sửa. Không cần lặp lại tệp baseline do người dùng đã cung cấp và không thay đổi. Nhưng nếu thiếu một interface hoặc tệp nền có ảnh hưởng đến build, hệ thống phải yêu cầu người dùng cung cấp thay vì tự đoán.

6. Phải tách ba trạng thái khác nhau

V4.1 nên ghi nhận độc lập:

• DELIVERY_STATUS: tệp mã đã được bàn giao đủ hay chưa;
• VERIFICATION_STATUS: có bằng chứng build/test thật hay chỉ kiểm tra tĩnh;
• ENGINEERING_STATUS: có đủ điều kiện để gọi là hoàn tất kỹ thuật hay không.

Một bundle có thể là DELIVERY_STATUS=COMPLETE nhưng vẫn là ENGINEERING_STATUS=WAITING_VERIFICATION nếu không có compiler hoặc test runner thực tế.

7. Tavily phải là capability adapter, không phải lời tuyên bố trong prompt

search_depth=advanced là tham số có thật của Tavily Search, phù hợp cho truy vấn cần độ liên quan và độ chính xác cao hơn; đổi lại, nó có thể làm tăng độ trễ hoặc chi phí.2411 Nhưng chỉ khi phiên làm việc thực sự có công cụ Tavily hoặc một integration đã kết nối thì Gem mới được nói rằng đã sử dụng Tavily.

Nếu Tavily không khả dụng, hệ thống phải hạ cấp minh bạch sang nguồn thực sự có thể dùng, chẳng hạn tài liệu người dùng cung cấp hoặc web search tích hợp nếu có.

Ma trận quyết định

Điểm dưới đây là đánh giá thiết kế cấu hình, không phải benchmark vận hành của Gemini Gem.

Tiêu chí	Trọng số	V4	V4.1 Final
Ranh giới vận hành và tính trung thực của công cụ	25%	4,0	4,8
Chất lượng hội tụ qua ba lượt đọc, DM và DR	20%	4,5	4,8
Chốt an toàn kỹ thuật và backpressure khi thất bại	20%	4,6	4,8
Mã hoàn chỉnh và dependency closure	15%	4,6	4,9
Mật độ chỉ dẫn và khả năng tuân thủ	10%	2,8	4,5
Khôi phục trạng thái và đối soát bằng chứng	10%	4,2	4,7
Tổng điểm có trọng số	100%	84,2	95,5

Cách tính:

$$
Score = 20\sum_{i=1}^{n}w_i s_i,
\qquad
\sum_{i=1}^{n}w_i=1
$$

Phán quyết

• Lựa chọn nên dùng: Solo-Engine V4.1 Final.
• Phương án về nhì: V4, phù hợp để thử nghiệm nội bộ nhưng chưa nên làm cấu hình dài hạn.
• Lý do nâng cấp: giảm lặp quy tắc, tăng tính tự đủ của chỉ dẫn chính và xác định chính xác giới hạn của Gem.
• Điều kiện chuyển kiến trúc: nếu sau này dùng Gemini API Managed Agent, MCP hoặc code sandbox có workspace bền vững, hãy thêm một Runtime Adapter riêng thay vì tiếp tục nhồi mô tả công cụ vào main instruction.

Deep Recon: phản biện mạnh nhất

Phản biện: V4 vốn đã rất chặt chẽ; tái cấu trúc V4.1 có thể chỉ là thay đổi hình thức.

Đáp lại: vấn đề của V4 không nằm ở thiếu ý tưởng, mà nằm ở xác suất tuân thủ trong thực tế. Khi cùng một trạng thái và luật được định nghĩa lặp lại giữa main instruction, SOP và artifact template, đầu ra dài dễ bị phân mảnh: phần báo cáo có thể nói một đằng, watermark nói một nẻo, còn trạng thái bàn giao lại nói khác.

Năm kiểm tra tối thiểu để bác bỏ V4.1

Nếu một trong các tình huống sau xảy ra, cấu hình vẫn cần siết lại:

1. Không có execution tool nhưng Gem nói mã đã test pass.
2. Thiếu interface nội bộ nhưng Gem tự bịa signature rồi tuyên bố có thể compile.
3. Một bugfix đổi public signature nhưng không nâng thành structural preflight.
4. Gem dừng giữa tệp nhưng ghi DELIVERY_STATUS=COMPLETE.
5. Tavily không khả dụng nhưng Gem nói đã chạy search_depth=advanced.

Khung cấu hình cuối cùng cho V4.1 Final

Tệp 1 — 00-solo-engine-system.md trong Gem Instructions

Đây là nơi đặt các luật không thể thỏa hiệp:

• route /ana-solo và /ana-bmad;
• ưu tiên chỉ dẫn;
• không bịa tool, log, build, test, Git, deploy hay nhiều agent độc lập;
• capability detection cho research, execution, filesystem và persistence;
• giới hạn vòng lặp tự động;
• định nghĩa các trạng thái delivery, verification và engineering;
• điều kiện duy nhất để được đánh dấu COMPLETE;
• quy tắc mã hoàn chỉnh, dependency và phân trang khi đầu ra dài.

Tệp 2 — 10-ana-solo.md trong knowledge base

Dùng cho quy trình phân tích:

• intake;
• three-pass reading;
• research adapter;
• Value Extraction;
• hard gate;
• Decision Matrix;
• Deep Recon;
• crystallization thành ADR và Pending Implementation Plan.

Tên “SEO xuất thông tin giá trị” nên đổi thành Value Extraction. Chỉ đi vào SEO thực sự khi người dùng yêu cầu keyword, indexing, crawling, ranking, content optimization hoặc conversion measurement.

Tệp 3 — 20-ana-bmad.md trong knowledge base

Dùng cho quy trình kỹ thuật lấy cảm hứng từ BMAD:

• nhận diện scenario: ALGO, STRUCTURAL, BUGFIX, OPS hoặc hỗn hợp;
• các góc nhìn PM, Architect, Developer, QA và Ops;
• Algorithm-Fit và Architecture Preflight;
• dependency policy STDLIB_ONLY hoặc LOCKED_EXISTING;
• complete-code contract;
• verification level từ V0 đến V4;
• State Reconcile;
• cơ chế backpressure sau các lần xác minh thất bại.

Tệp 4 — 30-artifacts.md trong knowledge base

Chỉ chứa schema cho:

• Environment Contract;
• Pending Implementation Plan;
• Micro Plan;
• ADR;
• Verification Record;
• Truth Report;
• Resume Capsule.

“Truth Report” cần được định nghĩa là ảnh chụp các sự thật đang được bằng chứng hiện có hỗ trợ, không phải tuyên bố chân lý tuyệt đối.

Tệp 5 — 40-three-pass-reading.md trong knowledge base

Tệp này giữ riêng kernel ba lượt đọc để tránh lặp lại nội dung giữa các SOP:

1. dựng toàn cảnh, mục tiêu và baseline;
2. kiểm tra bằng chứng, quan hệ nhân quả, dữ liệu và interface;
3. tái dựng giả định, tìm phản ví dụ, failure boundary và thí nghiệm phản chứng nhỏ nhất.

Điều kiện hoàn tất nên áp dụng trong bản cuối

Chỉ được gắn ENGINEERING_STATUS=COMPLETE khi đồng thời thỏa tất cả điều kiện sau:

1. Bundle hiện tại đã đạt mức xác minh mà Plan yêu cầu.
2. Môi trường xác minh khớp điều kiện trong Plan, hoặc mức độ khác biệt đã được nêu rõ.
3. State Reconcile=CONSISTENT.
4. Toàn bộ file manifest cần giao đã ở trạng thái complete.
5. Plan, ADR và Truth Report đã được cập nhật theo bằng chứng mới nhất.

Nếu không có môi trường chạy thật, kết quả đúng phải là:

• VERIFICATION_STATUS=STATIC_CHECKED hoặc NOT_RUN;
• ENGINEERING_STATUS=WAITING_VERIFICATION;
• có lệnh xác minh rõ ràng để người dùng chạy;
• không tuyên bố “zero compile error”, “all tests passed” hoặc “production-ready”.

Kết luận cuối

Solo-Engine V4 có nền tảng tư duy tốt và đáng giữ lại. Nhưng bản phù hợp để dùng là V4.1 Final, với trọng tâm không phải “thêm kiểm soát”, mà là làm cho kiểm soát ít mâu thuẫn hơn, gần chỉ dẫn chính hơn và gắn chặt hơn với bằng chứng thật.

Nói ngắn gọn: hãy giữ vòng khép kín nghiên cứu → quyết định → kế hoạch → triển khai → xác minh → đối soát, nhưng chỉ cho phép hệ thống khẳng định điều mà nó thực sự có bằng chứng để khẳng định.