Hình học: bản thiết kế open-stent đã công bố của Craig Bonsignore (Nitinol Devices & Components, 2010), giấy phép CC-BY-SA 3.0. Đây là CAD thật, không phải hình dựng lại. Mọi con số trên trang đều tính từ mô hình của dự án này, không đọc ra từ file CAD. Nguồn đầy đủ: public/reference/ATTRIBUTION.md. (Nút bên dưới cho xem cùng một vật lúc chưa bung/đã bung — dài 15,230mm rút còn 13,644mm, tức co ngắn 10,4%, đo trực tiếp từ CAD thật, không phải từ mô hình chấm điểm của dự án này.)
Định vị phạm vi — không phải danh mục đã tính được
Bản đồ ma trận thiết kế stent
Stent không phải một loại thiết bị duy nhất — 4 trục dưới đây gom lại các hướng thiết kế khác nhau đang tồn tại trong ngành. Dự án này chỉ mô hình hoá ĐÚNG MỘT Ô trong bản đồ này (tô sáng bên dưới) — phần còn lại là bối cảnh để định vị phạm vi, không phải điều đã tính được.
Tô-pô mắt lưới
Mô hình hiện chỉ tính MỘT vành đơn (N_col=1, N_bridges=0) — chưa có bridge nối giữa các vành, nên trục này CHƯA XÁC ĐỊNH được cho thiết kế cụ thể ở đây (không tô sáng nhánh nào).
Cơ chế bung
Bề mặt / vật liệu
Vị trí
Mô hình của dự án phủ đúng MỘT ô
Tự bung · nitinol nhớ hình · kim loại trần · mạch máu — và chỉ tính cho MỘT VÀNH đơn (chưa có bridge nối, nên trục tô-pô mắt lưới ở trên chưa xác định được). Các ô còn lại trong bản đồ là BỐI CẢNH để định vị phạm vi, không phải điều đã tính được.
Khung phân loại 4 trục này KHÔNG trích từ một nguồn tài liệu cụ thể — dùng để ĐỊNH VỊ PHẠM VI dự án trong cảnh quan thiết kế stent nói chung, không phải dữ kiện đã tra cứu. Không có số liệu, tên thương mại, hay tỉ lệ thị phần nào gắn kèm các nhánh trên.
Bản đồ năng lực & mức độ xác minh
Sơ đồ Pipeline R&D — 3 màu phân định thực tế
Mỗi công đoạn trong chuỗi R&D stent Nitinol được phân màu minh bạch theo khả năng tự chạy lại độc lập và mức độ xác minh thực tế theo hợp đồng dự án:
Hình học tham chiếu từ CAD thật
Bản CAD Bonsignore 2010; đối chiếu hình học tham chiếu chuẩn.
Mô hình chấm điểm giải tích
score_design() chạy ổn định và tự tái lập được; bản Python và TypeScript khớp tới 14 chữ số có nghĩa. Từng gán nhãn lực-xuyên-tâm lên biến lực-vòng (thiếu hệ số 2π, ca 14) — đã truy ra gốc VÀ sửa 2026-08-12 (RF_trf = 2π × RF_hoop, lan sang cả web). Giữ vàng vì đây là bài học đáng giữ lại làm bằng chứng, không phải vì còn lỗi sống.
Vòng tối ưu NSGA-II
5 seed độc lập; thu được mặt Pareto 132 điểm đánh đổi.
Sinh lưới hex 3D
12.800 hex, trung vị chất lượng 0,979 rất tốt, NHƯNG 1,3% phần tử bị méo nặng ở đỉnh crown do offset tự cắt — đã truy ra gốc, CHƯA sửa.
Mô phỏng FEA Nitinol
Chạy được vòng trễ Nitinol; lưới 391 điểm còn thô (chưa đủ điều kiện xanh).
Kiểm chứng thực nghiệm
Mới là định hướng; chưa có mẫu vật lý và thiết bị đo.
Hồ sơ theo chuẩn (ASME V&V 40)
Định hướng chuẩn hóa hồ sơ V&V; chưa thực hiện.
Unit-cell — dựng thẳng từ 1 điểm Pareto thật
Stent tự bung Nitinol — vành đơn (unit-cell)
Mesh dưới đây và 4 con số cạnh nó tính từ CÙNG một bộ tham số hình học (N_CROWNS=17, AMPLITUDE=1.0355mm, STRUT_WIDTH=0.1541mm) — không phải hình minh hoạ tách rời gán số vào sau.
Bấm vào một chấm trên hình để xem vì sao vị trí đó đáng chú ý.
Lưu ý hình học: mesh vẽ tiết diện TRÒN đường kính 0,1541mm cho thanh chống, trong khi thanh thật là HÌNH CHỮ NHẬT 0,1541 × 0,15mm — tức hình đang dày hơn thực tế khoảng 1,03 lần theo phương bán kính (gần khớp, vì ở điểm này bề rộng thanh và bề dày thành ống gần bằng nhau). Không cần sửa hình, chỉ cần biết đây là hình đơn giản hoá.
Mô hình hiện chỉ tính cho MỘT vành (N_col=1, N_bridges=0) — chưa mô phỏng độ mềm dẻo giữa các vành (phụ thuộc bridge nối, model chưa có). Xem chi tiết giới hạn tại 07_campaigns/2026-08-10-stent-ai-design-loop/.
Mặt đánh đổi thật, không phải một điểm được chọn để khoe
132 điểm tối ưu tìm được — thiết kế tham chiếu vẫn đứng ngoài tầm với
Mỗi chấm là 1 trong 132 thiết kế trên mặt Pareto (vòng lặp NSGA-II, 5 seed độc lập, sau khi sửa lỗi đường kính ống — xem 3 giới hạn bên dưới biểu đồ). Trục ngang là lực xuyên tâm thật RF_trf (N/cm), trục dọc là hệ số an toàn mỏi N_sf, màu thể hiện khối lượng (nhạt = nhẹ, đậm = nặng). Vòng tròn viền trắng là chính thiết kế tham chiếu — ví dụ thật đã công bố của kỹ sư Nitinol (Craig Bonsignore), KHÔNG phải do vòng lặp này sinh ra — tính lại bằng CÙNG một mô hình để so sánh công bằng.
Bấm vào một điểm có tên (hoặc nhãn bên dưới) để xem số của nó.
Sự thật cần nói thẳng: trong 132 điểm này, KHÔNG một điểm nào thắng được thiết kế tham chiếu trên cả 3 mục tiêu cùng lúc (RF_trf VÀ N_sf VÀ khối lượng — đo bằng chính mô hình này trên chính thiết kế tham chiếu: RF_trf=2,77 N/cm, N_sf=2,71, mass=2,52mg). Nới lỏng chỉ còn 2 mục tiêu (bỏ khối lượng), có 9/132 điểm thắng cả RF_trf và N_sf — nhưng đều nặng gấp 3-5 lần. Điểm trình bày ở trên chọn một hướng đánh đổi cân bằng hơn: gấp 4,69 lần lực xuyên tâm (12,99 N/cm so với 2,77 N/cm) VÀ NHẸ HƠN 17,4% (2,09mg so với 2,52mg), đổi lại hệ số an toàn mỏi chỉ còn 0,81 lần (2,19 so với 2,71) và biên foreshortening co lại rất mỏng (4,93%, chỉ còn khoảng 1,4% trước khi vi phạm ràng buộc <5%). Đây là một mặt đánh đổi đọc được, KHÔNG PHẢI thành tích 'thuật toán tìm ra thiết kế tốt hơn kỹ sư'. Góc trên-trái biểu đồ (RF gần 0, N_sf chạm trần 100) tồn tại về mặt toán học nhưng vô dụng lâm sàng: một stent với lực xuyên tâm gần 0 thì không chống được co hồi mạch, dù hệ số an toàn mỏi đẹp tới đâu. Một quan sát khác cùng họ, nhẹ hơn: vòng lặp KHÔNG có mục tiêu nào thưởng cho độ che phủ kim loại/khả năng chống đè bẹp (POA được tính trong scoring.py nhưng KHÔNG đưa vào làm objective) — đó là một phần lý do mặt Pareto có xu hướng trôi về phía ít thanh chống, dài: không có gì phạt một thiết kế chỉ có vài thanh chống lưa thưa. (RF_trf = 2π × RF_hoop — lực vòng đọc trực tiếp từ công thức gốc, xem ca 14 trong bộ sưu tập bên dưới; đã sửa 2026-08-12, KHÔNG được nói 'đã khớp với dải công bố thực tế' vì chưa có mẫu vật hay máy đo nào đối chiếu.)
3 giới hạn khiến đây CHƯA phải kết luận cuối
- Mô hình cố định wall_thickness=0,15mm cho toàn bộ vòng lặp tối ưu, trong khi thiết kế tham chiếu dùng 0,17mm — không cùng biến số, so sánh chỉ mang tính tương đối.
- Adapter đặt bề rộng đỉnh crown (w_apex) bằng đúng bề rộng thân thanh chống (strut_width) — chính docstring của scoring.py cảnh báo đây là giả định LẠC QUAN tại đỉnh crown, nơi biến dạng mỏi tập trung cao nhất, nên N_sf thật có thể thấp hơn số hiển thị.
- Vòng lặp chỉ có ĐÚNG 3 biến tự do (N_CROWNS, AMPLITUDE, STRUT_WIDTH) — wall_thickness và đường kính ống đều cố định. Với mô hình đơn giản hoá và 3 biến này, vòng lặp KHÔNG tìm ra thiết kế nào áp đảo được thiết kế tham chiếu.
Tự tay kéo, tự mắt thấy sự đánh đổi — không cần đọc mô tả
Kéo 4 tham số, xem 4 con số ghi nhau theo thời gian thực
4 thanh trượt bên dưới nối THẲNG vào đúng công thức đã dùng cho toàn bộ trang này (scoreStentDesign() trong lib/stentCalculator.ts) — không phải minh hoạ riêng. Đường kính ống giữ cố định 1,92mm (đổi đường kính là đổi bài toán, không phải chỉnh thiết kế cho cùng một mạch). Kéo thanh chống rộng ra và nhìn khối lượng tăng theo — đó chính là cái đánh đổi ở biểu đồ phía trên, giờ tự tay cảm nhận được thay vì chỉ đọc về nó.
Bấm vào một chấm trên hình để xem vì sao vị trí đó đáng chú ý.
Thiết kế không tách rời khỏi mạch máu nó phục vụ
Cùng một thiết kế, đổi mạch đích — hệ số an toàn mỏi đổi gần 2,6 lần
Bộ tham số dịch vụ (D_set/D_ves) bê nguyên từ bản tham chiếu open-stent: ống Nitinol 1,92mm tự bung ra 8,0mm cho một mạch 6,5mm. Bản tham chiếu KHÔNG nêu chỉ định lâm sàng cụ thể — nó là bộ công thức chung cho stent Nitinol, không gắn với một mạch máu nào (README gốc: "arteries, veins, or other vessels"). Nên ở đây cũng không đặt tên mạch: chỉ ghi đường kính. Điều chắc chắn được: đây KHÔNG phải mạch vành (mạch vành 2,25–4,0mm) và cũng không phải công nghệ nong-bằng-bóng phổ biến ở stent mạch vành. Bảng dưới đây tính lại CÙNG một hình học đó cho một mạch nhỏ hơn — không đổi gì khác.
| Đại lượng | Kịch bản tham chiếu — mạch 6,5mm (D_set=8,0mm, D_ves=6,5mm) | Mạch nhỏ 2,75mm (D_set=3,0mm, D_ves=2,75mm) |
|---|---|---|
| RF_trf | 12.99 N/cm | 11.19 N/cm |
| N_sf | 2.19 | 5.69 |
| Khối lượng | 2.085 mg | 2.085 mg |
| Foreshortening | 4.93% | 0.16% |
Đây là CÙNG MỘT thiết kế đo trong hai mạch khác nhau — KHÔNG PHẢI thiết kế lại cho mạch nhỏ (chỉ đổi D_set/D_ves, không chạy lại vòng tối ưu). Khối lượng không đổi vì không phụ thuộc mạch đích. Hệ số an toàn mỏi tăng gần 2,6 lần (2,19 → 5,69) khi đổi sang mạch nhỏ hơn cho thấy: một thiết kế stent không tách rời khỏi mạch máu nó phục vụ — đây là điểm đáng nói, không phải chỗ để giấu.
Mục W5
Những chỗ tôi đã sai
Không phải "tôi chạy được gì" — mà "một con số trông hợp lý không có nghĩa là con số đúng, và đây là cách tôi phát hiện ra." Phần lớn các ca dưới đây không có exception, không có cảnh báo, không có gì đỏ — chỉ một con số hoàn toàn hợp lý, và sai.
1. Viết lại công thức sang ngôn ngữ khác — sai 2,44 lần
Triệu chứng: Website hiện lực xuyên tâm 182,212 trong khi số thật là 74,678.
Gốc: Tự giản lược một số hạng trong công thức vendor (+w_apex_raw) vì tưởng bỏ được, và dùng nhầm bề dày thô thay vì bề dày đã trừ hao hụt đánh bóng điện hoá.
Bắt bằng: Bảng đối chiếu 5 điểm chạy song song hai bản, so tới độ chính xác float.
Sau khi vá: Khớp tuyệt đối — 74.67824159957114 cả hai bên.
2. Phép toán trả rác thay vì báo lỗi
Triệu chứng: Khối lượng ra số âm.
Gốc: Cùng một phép tính, hai ngôn ngữ hành xử ngược nhau khi gặp hình học bất khả thi — một bên ném lỗi miền xác định, bên kia lặng lẽ trả về NaN, giá trị rác lan xuống toàn bộ chuỗi tính.
Bắt bằng: Golden-test với điểm biên (n_crowns/amplitude ở giới hạn thấp nhất).
Sau khi vá: Ném lỗi tường minh khi hình học bất khả thi, khớp hành vi Python.
3. File kết quả tự mâu thuẫn với chính nó
Triệu chứng: Lấy tham số ghi trong file rồi tính lại ra số khác với kết quả ghi ngay bên cạnh, lệch ở chữ số thứ hai sau dấu phẩy.
Gốc: Hai chuẩn làm tròn trong cùng một file: tham số đầu vào làm tròn 4 chữ số cho dễ đọc, nhưng kết quả lại tính từ giá trị đầy đủ chưa làm tròn — file không tự tái lập được chính nó.
Bắt bằng: Một chênh ở chữ số thứ năm suýt bị gạt đi bằng phỏng đoán 'chắc chỉ là làm tròn lúc gõ tin' — truy tới cùng mới lộ ra đây là bug thật, không phải chuyện vặt.
Sau khi vá: Tăng độ chính xác export lên 8 chữ số, file giờ tự tái lập đúng chính nó.
4. Phần mềm dựng hình báo 'hợp lệ' cho khối rỗng ruột
Triệu chứng: OpenCASCADE trả solids=1, faces=432, is_valid=True — nhưng volume = 6.9e-18.
Gốc: Khối tự cắt chính nó, thể tích có dấu triệt tiêu lẫn nhau.
Bắt bằng: Đối chiếu thể tích tuyệt đối thay vì chỉ tin cờ is_valid.
5. Cổng kiểm thể tích báo 'tốt nhất' đúng lúc lưới hỏng nặng nhất
Triệu chứng: Ở lưới mịn nhất, có 1.184 phần tử lộn ngược (scaled Jacobian = -1,0) — trong khi sai số thể tích lại tốt nhất trong tất cả các mức (-0,030%).
Gốc: Thể tích có dấu; phần tử lộn ngược đóng góp âm và triệt tiêu sai số của phần tử lành.
Bắt bằng: Giữ song song cổng kiểm chất lượng phần tử (scaled Jacobian), không chỉ tin cổng thể tích.
6. Tạo lại dữ liệu xoá luôn khả năng kiểm chứng phát hiện cũ
Triệu chứng: pareto_front_latest.json được tạo lại sau khi vá lỗi #3 — đúng về kỹ thuật, nhưng xoá mất bản gốc mà một phát hiện trước đó (claim 'bỏ RF_hoop mất 0/39 điểm') dựa vào.
Gốc: Đổi định dạng/độ chính xác dữ liệu gốc mà không giữ bản cũ kèm mốc thời gian.
Bắt bằng: Muốn xác minh lại một claim cũ thì phát hiện dữ liệu gốc đã không còn.
Sau khi vá: Quy tắc mới: đổi định dạng dữ liệu gốc thì giữ bản cũ kèm mốc thời gian.
7. Chọn sai thước đo cho kết luận NGƯỢC hoàn toàn — ca tinh vi nhất
Triệu chứng: Không phải công cụ hỏng, công cụ chạy đúng — nhưng hai thước đo trên CÙNG một dữ liệu cho hai kết luận ngược nhau hoàn toàn về việc mục tiêu RF_hoop có dư thừa hay không.
Gốc: Đếm điểm Pareto bị loại coi một điểm ở rìa và một điểm ở giữa mặt Pareto là như nhau — nhưng mất một điểm ở rìa có thể xoá cả một vùng đánh đổi.
Bắt bằng: Hypervolume (chuẩn ngành) + chạy lại trên seed độc lập để xem thước đo nào ổn định.
| Thước đo | Kết luận về RF_hoop |
|---|---|
| Đếm điểm Pareto bị loại | Bỏ RF_hoop chỉ mất 2/18 (11%) → "đóng góp ít nhất, có vẻ thừa" |
| Hypervolume (chuẩn ngành) | Bỏ RF_hoop mất 97% thể tích bao phủ → "quan trọng NHẤT trong ba" |
Ngưỡng "tương quan > 0,95 ⇒ mục tiêu thừa" từng viết trong audit độc lập (claude5) — không kiểm chứng, nghe hợp lý, viết bằng giọng chắc chắn — bị chính dữ liệu này bác bỏ: corr(RF_hoop,N_sf)=0,9716 vượt ngưỡng đó, nhưng RF_hoop lại là trục quan trọng nhất. Tương quan cao không có nghĩa là dư thừa. Thước đo nào ổn định qua các lần chạy độc lập (ở đây: hypervolume, giữ đúng thứ hạng RF_hoop>mass>N_sf qua 2 lần chạy seed khác nhau, trong khi đếm-điểm nhảy gấp đôi 11%→22%) thì đáng tin hơn.
8. "Khớp tuyệt đối" — Lỗi truyền tin và sự tin tưởng mù quáng giữa các lớp kiểm soát
Triệu chứng: Cụm từ 'khớp tuyệt đối' được dùng để khẳng định hai phiên bản Python và TS trùng khớp, nhưng thực tế kết quả N_sf lệch nhau ở chữ số thập phân cuối cùng (10.618709906158351 vs 10.618709906158376).
Gốc: Nhà phát triển (claude9) kết luận vội vã, người gác cổng kiểm định (claude5) tin tưởng không đối chiếu lại chữ số và chuyển tiếp cho Batin, người viết tài liệu (agy5) ghi nhận thẳng vào bản thảo như một sự thật.
Bắt bằng: Đối chiếu chéo từng chữ số thập phân ở bước nghiệm thu cuối cùng.
Sau khi vá: Khớp tới 14 chữ số có nghĩa, chênh lệch ở chữ số thứ 15 do sai số làm tròn float64, không phải lỗi port thuật toán.
9. Bắt được TRƯỚC khi kịp thành lời — Hiện tượng chưa kích hoạt trong mô hình siêu đàn hồi
Triệu chứng: Mô phỏng FEA hội tụ trơn tru, dùng đúng thẻ vật liệu siêu đàn hồi Nitinol, ứng suất tối đa ra 89,422 MPa trông rất hợp lý nhưng thực tế chưa kích hoạt hành vi siêu đàn hồi.
Gốc: Ứng suất 89 MPa còn xa dưới ngưỡng bắt đầu chuyển pha (400–500 MPa), vật liệu vẫn đang chạy trong vùng đàn hồi tuyến tính thông thường của mô hình.
Bắt bằng: Hỏi câu hỏi chẩn đoán 'số này đã vượt ngưỡng vật lý chưa' thay vì 'phần mềm có báo lỗi không', và chạy phép thử chẩn đoán tăng tải trọng lên 10 lần kết hợp dỡ tải để xác nhận vòng trễ.
Tuyệt đối không gắn kết quả lưới thô 391 điểm của bản Learning Edition (giới hạn 1000 điểm của công cụ) vào các số đo độ bền mỏi. Hệ số an toàn mỏi dao động tới một bậc độ lớn theo lưới. Mô hình sử dụng phần tử tứ diện tuyến tính (C3D4) vốn cho ứng suất thấp hơn thực tế một cách hệ thống; chuẩn ngành khuyên dùng lưới lục diện.
10. Cổng kiểm TỰ VIẾT báo XANH đúng lúc nó phá nát thứ nó phải giữ — kèm một đoạn chú thích biện minh cho cổng sai
Triệu chứng: Cần đưa CAD thật lên web, file STL gốc 127.042 mặt / 2,2MB — tưởng nặng quá nên giảm mặt xuống 30k. Sau khi giảm: mesh từ 1 khối kín liền mạch vỡ thành 384 mảnh rời, không còn kín (kết cấu stent là lưới thanh mảnh 0,13mm trên thân 8mm, thuật toán giảm mặt xé đứt các thanh đó).
Gốc: Cổng kiểm tự viết chỉ đo sai lệch kích thước bao (bounding-box) và báo 0,0143% — xanh mướt — đúng lúc mesh đã vỡ thành 384 mảnh, vì vỏ ngoài giữ nguyên trong khi ruột bị xoá sạch. Phép đo thể tích lệch 77% đúng ra phải báo động, nhưng bị tự tay dìm xuống hàng 'chỉ tham khảo, không phải cổng kiểm chính thức', kèm một đoạn chú thích giải thích vì sao kích-thước-bao 'chuẩn hơn' — không chỉ chọn sai thước đo, còn biện minh bằng văn bản cho lựa chọn đó trước khi chạy.
Bắt bằng: Không phải nhìn ảnh render (mesh vỡ vụn trông gần giống bản gốc ở kích thước nhỏ) — đo đúng bất biến của kết cấu lưới thanh mảnh: số mảnh rời phải giữ = 1, tính kín (watertight) phải giữ = true.
Cái chốt quan trọng nhất: hoá ra việc đúng là ĐỪNG giảm mặt gì cả — để nguyên 2,2MB thì qua mạng (gzip) chỉ còn 790KB, nhẹ ngang vài tấm ảnh. Đã tự tạo ra một bài toán không tồn tại (tưởng mesh nặng quá cho web), giải sai bài toán đó, rồi viết chú thích bảo vệ lời giải sai — ba tầng lỗi chồng lên nhau, không tầng nào tự phát cảnh báo. Bài học: trước khi tối ưu, đo xem có thật sự cần tối ưu hay không.
11. Lấp khoảng trống của nguồn bằng một suy đoán nghe hợp lý — hai người đoán ra hai đáp án khác nhau, cả hai đều sai
Triệu chứng: Trang từng gọi thiết kế này là 'stent mạch vành' — sai vì mạch đích của mô hình (6,5mm) không khớp cỡ mạch vành thật (2,25–4,0mm). Sửa lại thành 'động mạch chậu' vì đúng cỡ đường kính — nhưng đây CŨNG là suy đoán không có trong nguồn; một người đọc độc lập khác đề xuất 'động mạch cảnh', cũng hợp lý không kém, cũng bịa.
Gốc: Bản tham chiếu open-stent (README gốc) chỉ viết 'arteries, veins, or other vessels' — không nêu chỉ định lâm sàng cụ thể nào. D_ves=6,5mm chỉ là một giá trị ví dụ trong bộ tham số mẫu; chính docstring nội bộ của dự án đã ghi rõ đây là PLACEHOLDER, chưa tinh chỉnh.
Bắt bằng: Hỏi 'nguồn CÓ NÓI điều này không' thay vì 'điều này có hợp lý không'. Dấu hiệu nhận ra: hai người đọc độc lập, lấp cùng một khoảng trống, ra hai đáp án khác nhau — cả hai đều nghe hợp lý, cả hai đều bịa.
Sau khi vá: Bỏ hẳn tên mạch giải phẫu ở mọi nơi, chỉ ghi đường kính. Giữ lại 2 điều chắc chắn (không phải mạch vành, không phải công nghệ nong-bằng-bóng) và nói thẳng: nguồn không nêu chỉ định — nên trang cũng không đặt tên.
Nguy hiểm hơn lỗi 'mạch vành' ban đầu: lỗi đó sai rõ ràng, dễ bắt (số liệu không khớp). 'Động mạch chậu' trông NHƯ ĐÃ TRA CỨU — đúng cỡ đường kính, nghe có nguồn — nhưng thực ra là phỏng đoán chưa kiểm chứng, khó bắt hơn nhiều cho một hồ sơ gửi công ty thiết bị y tế.
12. Không gian tìm kiếm không chứa nổi điểm xuất phát của chính mình
Triệu chứng: Sau khi sửa lỗi đường kính ống (3,0→1,92mm), chạy lại vòng lặp tối ưu — front Pareto ra 109 điểm, hội tụ mượt, không lỗi gì. Nhưng RF_hoop tốt nhất trên front chỉ còn 4,24 N/cm (thấp hơn 17,6 lần số cũ), và 64/109 điểm (gần 60%) ghim đúng ở biên trên của khoảng tìm kiếm — dấu hiệu kinh điển của biên còn hẹp.
Gốc: Biên tìm kiếm n_crowns=[4,16] được chốt từ khi đường kính ống còn SAI. Nhưng chính thiết kế THAM CỨU — ví dụ thật đã công bố của kỹ sư Nitinol, điểm mà toàn bộ bộ tham số dịch vụ của mô hình XUẤT PHÁT TỪ ĐÓ — có n_crowns=21. Biên tìm kiếm cũ không hề chứa nổi con số đó. Một không gian tìm kiếm không biểu diễn được chính thiết kế mình lấy làm chuẩn để so sánh là không thể bảo vệ được trước bất kỳ kỹ sư nào.
Bắt bằng: Đặt CHÍNH thiết kế tham chiếu vào mô hình, hỏi 'nó có nằm trong hộp tìm kiếm không' — chứ không chỉ nhìn front đẹp hay xấu. GA chạy ngoan, hội tụ đẹp, ra front trông rất thuyết phục, nhưng chưa bao giờ có cơ hội tìm ra thiết kế đang dùng làm chuẩn, vì nó nằm ngoài hộp.
Sau khi nới biên n_crowns lên [4,32] (ghim giảm còn 1-2%), amplitude vẫn ghim 20-23% dù đã nới — hoá ra đây KHÔNG còn là 'hộp hẹp' mà là một góc suy biến toán học thật (RF_hoop→0, N_sf chạm trần sanity khi thanh chống quá dài). Nới biên thêm sẽ không hội tụ vì đó là tiệm cận, không phải điểm tối ưu hữu hạn. Kết quả cuối: trong 132 điểm của front, KHÔNG điểm nào thắng được thiết kế tham chiếu trên cả 3 mục tiêu cùng lúc — xem biểu đồ mặt đánh đổi ở trên.
13. Cổng kiểm minSJ phóng đại một khuyết tật cục bộ thành thảm hoạ toàn cục — cặp song sinh NGƯỢC của ca 5
Triệu chứng: Sau khi trỏ script sinh lưới hex về đúng thiết kế đại diện (n_crowns=17), chạy thật ra minSJ=-1,0000 ở cả 4 mức lưới đã thử — đọc qua tưởng lưới hỏng hoàn toàn, không dùng được cho FEA.
Gốc: Đo cả phân bố thay vì chỉ tin số min: chỉ 166/12.800 phần tử (1,3%) có SJ≤-0,999; trung vị SJ=0,9788 (rất tốt); 94,3% phần tử có SJ>0, và 166 phần tử xấu luôn nằm ở 2 cạnh ngoài cùng của tiết diện thanh (không phải ở giữa), lặp lại đúng chu kỳ đỉnh crown. XÁC NHẬN bằng HAI phép đo trực tiếp độc lập, hai cách lấy mẫu khác nhau: bán kính cong cục bộ nhỏ nhất của centerline = 0,06731mm (lưới 400 điểm resample) và 0,07451mm (đường thô 442 điểm, đo lại bởi claude5) — CẢ HAI đều nhỏ hơn nửa bề rộng thanh (0,077045mm). Đây là lỗi offset-curve tự cắt chính nó kinh điển: offset một đường cong bằng khoảng cách lớn hơn bán kính cong cục bộ luôn gấp lên chính nó.
Bắt bằng: Không chỉ đọc con số min — đọc cả phân bố (min, trung vị, tỉ lệ phần tử xấu), rồi ĐO trực tiếp bán kính cong thay vì dừng ở suy đoán 'nhìn có vẻ do bo cung đỉnh'.
Một giả thuyết ban đầu nghe rất hợp lý — 'thứ tự đỉnh hex bị đảo ngược ở mối nối khép vòng' — bị bác bỏ bằng phép đo 3 dòng (đảo thứ tự/chiều quét 3 cách, minSJ vẫn -1,0000 cả ba). Giả thuyết thứ hai — 'bo cung đỉnh crown quá lớn' — cũng CHẾT: quét crown_r cả hai chiều (0,03 đến 0,40mm, gấp hơn 13 lần), từ 0,08 đến 0,40 mọi chỉ số giống hệt nhau đến từng chữ số — cung bo đã bị chặn trần bởi hình học khác, không phải đòn bẩy thật. Giả thuyết thứ ba (offset tự cắt do bán kính cong < nửa bề rộng thanh) mới là đúng, xác nhận bằng số đo. CHƯA sửa — sửa đúng bài cần đổi thuật toán offset, không phải chỉnh tham số. ⚠️ Nhưng con số TỈ LỆ điểm dưới ngưỡng lại KHÔNG vững — một ca cùng họ ngay bên trong ca này: lần đầu báo 144/400 (36%), claude5 đo lại trên đường thô ra 374/442 (84,6%) — lệch hơn 2 lần, vì độ cong rời rạc (3 điểm liên tiếp) phụ thuộc khoảng cách lấy mẫu. Kết luận định tính (có điểm dưới ngưỡng) vững ở cả hai cách đo; con số PHẦN TRĂM thì không — không trích 36% hay 84,6% như sự thật cứng ở bất cứ đâu. Cặp song sinh ngược của ca 5: ca 5 là con số tổng hợp (thể tích) GIẤU khuyết tật cục bộ; ca này là con số cực trị (minSJ) PHÓNG ĐẠI khuyết tật cục bộ y hệt quy mô thành thảm hoạ toàn cục.
14. Nhãn 'lực xuyên tâm' dán đè lên 'lực vòng' — sai số 2pi trôi qua do cả hai con số đều hợp lý
Triệu chứng: Biến RF_hoop được mặc định gán nhãn là 'Lực xuyên tâm' với giá trị tham chiếu 0,441 N/cm, hiển thị trên đồ thị, web và bảng đối chiếu chênh lệch float64 mà không phát sinh bất kỳ cảnh báo lỗi nào.
Gốc: Dải giá trị lực vòng RF_hoop (0,1–4,0 N/cm) hoàn toàn hợp lý về mặt cơ học cho stent mạch vành cỡ nhỏ. Do cả hai con số (lực vòng RF_hoop và lực xuyên tâm thực RF_trf = 2 * pi * RF_hoop) đều là các số hợp lý, lỗi đọc nhầm cột/biến của tác giả gốc đã trôi qua mọi lớp rà soát chéo code tự động.
Bắt bằng: Hỏi ra ngoài (Gemini Deep Research). Nó không đưa một con số để tin, mà đưa một lập luận cơ học KIỂM ĐƯỢC: một stent 8mm cắt từ ống 1,92mm thành 0,17mm thì mô-men quán tính phải cho lực lớn hơn hẳn 0,441 N/cm. Không tin lời nó — mở thẳng mã nguồn gốc ra đọc, thấy dòng 143-144 của stent-calculator.py có HAI biến nằm cạnh nhau: RF_hoop và RF_trf = 2π × RF_hoop. Đo được thì không cần tin.
⚠️ Deep Research CÓ nêu một dải RRF tham khảo (2,4–10,7 N/cm) nhưng dải đó CHƯA được dự án này kiểm chứng độc lập, và không có nguồn nào công bố phép đo riêng cho đúng bản thiết kế open-stent này — KHÔNG trích dải đó như sự thật đã tra cứu, và KHÔNG gọi nó là 'của dòng stent này' (một lần quy-kết-sai-nguồn từng lọt vào chính case này, tự nó là một ca-11-tái-diễn — đã sửa). Lỗi 2π đã được TRUY RA GỐC VÀ SỬA (2026-08-12): RF_trf = 2π × RF_hoop giờ tính sống trên toàn bộ scoring.py, ga_loop.py và web.
Quy tắc rút ra
- Hỏi đủ hai câu, không chỉ một — 'hai bản có khớp nhau không' khác 'kết quả có khớp với cách tạo ra nó không'.
- Đừng bao giờ gạt một chênh lệch bằng chữ 'chắc là...' — chữ đó chính là chỗ bug trốn.
- Giữ lại bản LỖI, đừng xoá cho sạch — file bản sai mới là bằng chứng rằng có kiểm thật.
- Chuyển công thức thì phải chuyển cả hành vi lúc gặp lỗi, không chỉ chuyển phép tính.
- Đừng tin một cổng kiểm duy nhất — cổng xanh có thể đang che đúng cái nó phải bắt.
- Người làm và người kiểm phải là hai — không phải vì ai giỏi hơn, mà vì người viết code không hỏi được câu hỏi mà chính giả định của mình đã loại trừ.
- Hỏi 'số này đã vượt ngưỡng vật lý chưa', đừng chỉ hỏi 'phần mềm có báo lỗi không' — một mô phỏng hội tụ, số hợp lý, mô hình đúng vẫn có thể chưa hề chạm vào hiện tượng đang muốn chứng minh, và phần mềm sẽ không bao giờ tự báo điều đó.
- Hỏi 'nguồn CÓ NÓI điều này không', đừng chỉ hỏi 'điều này có hợp lý không' — một suy đoán hợp lý dựa trên bối cảnh vẫn là suy đoán; nếu nguồn im lặng, đừng viết như thể đã tra cứu được.
- Sau khi sửa một tham số nền tảng (đơn vị đo, hằng số vật lý, đường kính...), kiểm tra lại xem không gian tìm kiếm/thiết kế thí nghiệm có còn CHỨA ĐƯỢC chính điểm dữ liệu tham chiếu gốc hay không — đừng chỉ nhìn kết quả (front/biểu đồ) có 'đẹp', hội tụ, không lỗi hay không. Một thuật toán chạy ngoan vẫn có thể đang tìm kiếm trong một cái hộp không hề chứa câu trả lời đúng.
- Đừng bao giờ đặt một con số cực trị hoặc tổng hợp đơn lẻ lên một phân bố rồi kết luận ngay — một con số tổng hợp (như tổng thể tích) có thể giấu đi các khuyết tật cục bộ, và một con số cực trị (như minSJ) có thể phóng đại khuyết tật cục bộ quy mô nhỏ thành thảm hoạ toàn cục. Luôn phải đánh giá toàn diện cả min, trung vị, và tỉ lệ phần tử lỗi trước khi kết luận chất lượng.
- Hỏi 'chỉ số này có khớp với dữ liệu công bố độc lập / dữ liệu thực nghiệm bên ngoài không', đừng chỉ tự soi chênh lệch nội bộ — khi một con số sai hoàn toàn hợp lý về mặt vật lý, đối chiếu chéo nội bộ giữa các phiên bản code sẽ không bao giờ phát hiện được lỗi đọc nhầm cột. Bắt buộc phải có một phép đối chiếu hướng ngoại để phá vỡ trần giới hạn tự soi.