Knowledge Base System · v0.8
PMAX không thiếu kho kiến thức — đã có docs và sheets. Thứ đang thiếu là cái “băng chuyền” giữ cho kiến thức luôn mới, có bằng chứng thực chiến và được duyệt đàng hoàng. Bản này thiết kế đúng cái băng chuyền đó, lắp lên hai tài sản PMAX đã có: innovation system và đội builder champion giỏi agent.
Tóm tắt điều hành
KB cũ của PMAX gặp đúng năm câu hỏi không trả lời được: tài liệu này còn dùng được không, cũ hay mới, đã áp dụng bao nhiêu dự án, kết quả ra sao, và đẩy lên / duyệt bằng cơ chế nào. Đó không phải vấn đề lưu trữ — đó là vấn đề kiến thức không được nuôi sống.
May mắn là PMAX đã có sẵn hai thứ mà hầu hết công ty phải xây rất khổ mới có:
Nên bản thiết kế này không xây KB mới từ đầu. Nó lắp một “băng chuyền” lên tài sản đã có: kiến trúc phân lớp (dữ liệu nền → học hỏi → kiến thức → audit — mục 03), “hộ chiếu sống” gắn bằng chứng vào từng section, và cơ chế đẩy–duyệt rõ ràng. Ngoài innovation system, hai nguồn dữ liệu bằng số làm nền: Paxy (benchmark mọi dự án) và ad accounts qua MCP (thực tế campaign live để audit).
Ở bản trước tôi đoán PMAX ít công nghệ nên đề xuất cắt agent và cắt Git. Với thực tế PMAX, điều đó sai — agent là thế mạnh cần tận dụng, không phải rào cản cần bỏ. Bản v0.2 đảo lại hướng đó.
Phản biện cốt lõi
Mô hình mẫu pmaxmediasystem thiết kế rất kỹ phần tĩnh: 3 trục phân loại, 5 nhóm file, 8 nhãn, ma trận quyền. Đó là một cái tủ hồ sơ đẹp. Nhưng cả nó lẫn KB cũ của PMAX đều nói rất mờ về phần động — thứ quyết định kho sống hay chết:
Đây đúng là ba câu hỏi PMAX đang đau đầu. Vậy trọng tâm thiết kế phải dời từ “sắp xếp cho gọn” sang “vận hành cho sống”.
Mô hình mẫu trả lời “cái tủ hoàn hảo trông thế nào?”. Bản này trả lời “làm sao mỗi tài liệu luôn cho tôi biết nó còn đáng tin không, và tự cập nhật từ dòng thử nghiệm đang chảy?”
Kiến trúc phân lớp · Cập nhật với Paxy & ad accounts
Có hai loại thứ chảy vào KB: Kiến thức (do người tạo & chắt lọc) và Dữ liệu (do máy/nền tảng sinh — Paxy và ad accounts). KB tốt = kiến thức bám chặt vào dữ liệu. Vì vậy kiến trúc gồm bốn lớp:
Paxy — kho số liệu mọi dự án → benchmark theo Kênh × Giải pháp × Ngành: cho biết một kết quả là tốt hay tệ. Ad accounts (qua MCP) — trạng thái setup & hiệu suất LIVE của campaign thật: cho biết thực tế đang chạy thế nào. Đây không phải kiến thức — là số & thực tế để kiến thức bám vào.
Kinh nghiệm thô từ con người. Nay mỗi kết quả được đối chiếu benchmark Paxy — “−22% CPL” kèm luôn “so với ngành tốt hơn ~1.4×”, thay vì một con số trơ.
Ít mà tinh. Hộ chiếu nay giàu hơn: kết quả so với benchmark Paxy + độ phủ (mấy ad account đang áp dụng đúng — đếm từ MCP).
Agent đọc account qua MCP → so với playbook kiểm-chứng: account có làm đúng không? lệch chỗ nào? kết quả vs benchmark? Hai chiều: đẩy xuống (khuyến nghị sửa account) và kéo lên (account làm khác mà tốt → thành initiative mới, quay về Lớp 1).
Dữ liệu nền → học hỏi → kiến thức → audit áp dụng → sinh dữ liệu & bài học mới → lặp lại. Kiến thức không nằm chết trên kệ mà liên tục được thực tế kiểm tra ngược.
Paxy và ad account là dữ liệu khách. Tách hai mức: Benchmark ẩn danh (chia sẻ rộng, đã gỡ danh tính) vs Dữ liệu account cụ thể (chỉ nhóm dự án liên quan, truy cập qua MCP có kiểm soát & ghi log).
Hai cỡ nguyên liệu · Mới
Innovation hiện chạy theo ticket — mỗi initiative là một mảnh nhỏ: một giả thuyết, một kết quả. Nhưng khi tổng kết cả một dự án, ta có thứ quý hơn hẳn: có chiều sâu, bối cảnh, và nối nhiều initiative lại. Hai cỡ này khác chất, nên đi hai làn (mục 03) và đóng hai vai bổ sung nhau.
| Initiative (ticket) — đã có | Project Learning — tài liệu quý | |
|---|---|---|
| Cỡ | Nhỏ, lẻ: 1 giả thuyết → 1 kết quả | Lớn: tổng kết cả 1 dự án, gói nhiều initiative |
| Số lượng | Nhiều | Ít, nhưng sâu & bao quát |
| Cho biết | “Chạy có ra số không?” | “Hoàn cảnh nào nên dùng, vì sao work?” |
| Vai trò | Nuôi con số bằng chứng trong hộ chiếu + để agent phát hiện cụm | Nuôi nội dung & bối cảnh playbook + tự làm lộ ra playbook mới |
| Nguồn | Innovation system (có sẵn) | Buổi tổng kết dự án (cần mẫu nộp riêng) |
Thiếu initiative → playbook không có số để tin. Thiếu project learning → playbook thành “công thức khô”, người ta áp dụng bừa vì không rõ điều kiện. Playbook tốt = số liệu từ ticket + bối cảnh từ project.
Bối cảnh khách/ngành → chiến lược → các initiative liên quan (gắn link) → cái gì work/không → số liệu tổng → bài học tái dùng.
Không băm nhỏ. Bản thân nó đã là tài liệu quý, có “hộ chiếu” riêng (mục 05) và tra cứu được nguyên vẹn.
Champion đọc để rút pattern → codify. Project learning ở lại làm bối cảnh + bằng chứng phía sau playbook.
Project Learning ↔ các initiative bên trong nó; Playbook ↔ project learning + initiative. Nhờ vậy từ một playbook có thể lần ngược ra cả SỐ (ticket) lẫn CHUYỆN (project) — đúng thứ tạo niềm tin sâu mà KB cũ không có.
“Hộ chiếu sống” · Mới
Đây là bộ phận trả lời trực tiếp năm câu hỏi đau đầu. Mỗi tài liệu ở Lớp 2 gắn một khối thông tin ngắn — phần lớn tự điền từ dữ liệu liên kết, không phải gõ tay.
Bảng dưới cho thấy từng câu hỏi đau đầu được đóng bởi trường nào, và dữ liệu lấy từ đâu:
| Câu hỏi đau đầu hiện tại | Trường trong hộ chiếu | Lấy từ đâu |
|---|---|---|
| Cũ hay mới? | Cập nhật gần nhất + Rà soát tiếp theo | Tự động, hệ thống nhắc khi quá hạn |
| Còn dùng được không? | Trạng thái (vòng đời) | Champion duyệt · auto-hạ cấp nếu bỏ rà soát |
| Áp dụng bao nhiêu dự án? | Đã áp dụng (số dự án) | Tự đếm từ thử nghiệm liên kết |
| Kết quả thế nào? | Kết quả điển hình + khoảng | Tự tổng hợp từ kết quả các thử nghiệm |
| Ai chịu trách nhiệm? | Chủ sở hữu | Gán khi codify |
Một playbook gồm nhiều section (VD leadgen Meta: “Cấu trúc chiến dịch”, “Creative”, “Targeting”, “Đo lường”). Mỗi section mang hộ chiếu riêng — trạng thái, bằng chứng, chủ sở hữu, ngày rà soát của chính nó. Nhờ vậy người đọc thấy rõ phần nào đã kiểm chứng để dùng tự tin, phần nào còn thử nghiệm/nháp — thay vì đánh đồng cả playbook một cục.
Kéo theo: việc duyệt cũng ở cấp section (mục 06 & 12) — một section chín trước được lên “kiểm-chứng” trước, không phải chờ cả playbook. Về lưu trữ: mỗi section = một file Markdown (nội dung) + một hộ chiếu (bản ghi con có cấu trúc trong DB).
Vì hộ chiếu liên kết ngược về các thử nghiệm gốc trong innovation system, con số “7 dự án, CPL −22%” không phải tự khai — nó truy vết được. Đó là thứ tạo niềm tin thật, và là thứ KB cũ hoàn toàn thiếu.
Cơ chế đẩy lên & duyệt · Mới
Đây là “cơ chế đẩy lên và approve” mà bạn nói đang thiếu. Mỗi bước lên trạng thái có điều kiện rõ ràng và người bấm nút rõ ràng — không còn mơ hồ.
| Trạng thái | Điều kiện để lên mức này | Ai duyệt |
|---|---|---|
| Nháp | Một thử nghiệm/bài học được nộp (tự vào từ innovation system) | Tự động |
| Thử nghiệm | Champion thấy một cụm ≥ vài initiative cùng hướng, hoặc một project learning nêu bật một cách làm — gom thành 1 giả thuyết đáng thử rộng | Champion |
| Kiểm chứng | Đủ bằng chứng: ví dụ ≥ 3 dự án kết quả tích cực ổn định → codify thành playbook có hộ chiếu | Người kiểm chứng (product/champion cấp cao) |
| Ngừng dùng | Quá hạn rà soát mà không ai bảo vệ, hoặc có bằng chứng nó hết hiệu quả | Auto-hạ cấp → chủ sở hữu xác nhận |
Điểm khác biệt lớn so với mô hình mẫu: nó dùng cổng vào là Git + pull request — quá kỹ thuật cho người đóng góp phổ thông. Ở đây, đẩy lên là việc tự động (đã nộp innovation là đã vào Lớp 1); công sức con người dồn vào đúng chỗ đáng giá nhất: cửa duyệt lên “kiểm chứng”.
≥ 3 dự án là để minh họa. PMAX nên tự chốt ngưỡng theo từng loại giải pháp — cái này nên bàn trong buổi phản biện.
Project Learning định kỳ · Giữ & cụ thể hóa ý của bạn
Ý của bạn rất đúng: mở cho mọi người đóng góp, gom định kỳ làm đầu vào cho champion tổng hợp — y như cách innovation system đang chạy. Ta biến nó thành một nghi thức có nhịp để không phụ thuộc hứng thú cá nhân.
Mỗi đội nộp bài học từ dự án theo mẫu ngắn: bối cảnh, việc đã làm, kết quả, số liệu. Chảy thẳng vào Lớp 1.
Mọi người · như KPIAgent tự nhóm các bài học cùng chủ đề (mục 08), làm sẵn “giỏ nguyên liệu” cho champion — họ không phải đọc thủ công hàng trăm mục.
Agent hỗ trợChampion/product duyệt các cụm, quyết định cái nào nâng lên thử nghiệm/kiểm chứng, cái nào bỏ. Đây là nơi nguyên liệu thành kiến thức.
Champion · ProductPlaybook mới (hoặc bản cập nhật) được công bố cho toàn công ty, đưa vào đào tạo. Vòng lặp quay lại bước 1.
Cả tổ chứcNếu đóng góp kiến thức là việc thêm, người ta sẽ lơ. Nếu nó trùng với KPI innovation đã bắt buộc, dòng nguyên liệu tự chảy đều — đây là lợi thế lớn nhất của PMAX so với công ty khác.
Tận dụng sức mạnh agent · Đảo hướng v0.1
Mô hình mẫu sai ở chỗ bắt người dùng lấy kiến thức chỉ qua Agent — nếu agent kém thì cả kho vô dụng. Nhưng cắt agent (như bản v0.1) cũng phí, vì builder champion PMAX rất giỏi khoản này. Cách đúng: dùng agent để gánh phần nặng nhọc của việc curation, còn người vẫn tra cứu trực tiếp được.
Tự gắn 3 trục, gom các thử nghiệm cùng chủ đề, gợi ý champion: “5 thử nghiệm này đang nói cùng một chuyện, nên codify chưa?”
Đếm số dự án đã áp dụng, tính kết quả điển hình + khoảng dao động, cập nhật thẳng vào “hộ chiếu”.
Theo dõi ngày rà soát; quá hạn thì nhắc chủ sở hữu, không ai bảo vệ thì tự chuyển sang “ngừng dùng”.
Lớp thêm vào cho tiện, luôn kèm link tài liệu gốc + trạng thái. Không phải cửa bắt buộc — vẫn duyệt/tìm trực tiếp được.
Đọc account qua MCP → so với playbook kiểm-chứng: đúng chưa, lệch đâu, kết quả vs benchmark. Đây là Lớp 3 — kiến thức gặp thực tế (mục 03).
Bốn agent này biến curation từ việc “champion đọc tay hàng trăm mục” thành việc “champion duyệt các gợi ý đã được dọn sẵn” — đúng thứ đội builder PMAX làm giỏi.
Vai trò & công cụ
| Vai trò | Làm gì trong băng chuyền |
|---|---|
| Người đóng góp (mọi người) | Nộp thử nghiệm & bài học qua innovation system / Project Learning → vào Lớp 1. |
| Champion | Gom cụm, nâng lên “thử nghiệm”, codify thành playbook Lớp 2. |
| Người kiểm chứng (nhiều người, theo domain) | Duyệt lên “kiểm chứng” phần thuộc domain mình (kênh/giải pháp/ngành); giữ chuẩn bằng chứng — xem mục 12. |
| Builder | Xây & nuôi 4 agent, nối dữ liệu innovation ↔ hộ chiếu. |
Vì PMAX advance về công nghệ, ta không né Git nữa — mà đặt đúng chỗ:
Git tốt cho người biên tập kiến thức chuẩn (số ít, kỹ thuật), nhưng là rào cản cho người đóng góp phổ thông (số đông). Tách 2 lớp cho phép dùng Git ở nơi nó mạnh mà không chặn dòng đóng góp.
Techstack đề xuất · Mới
Nguyên tắc chọn stack: mua phần đã chuẩn hóa (lưu trữ, phân quyền, quy trình duyệt) để khỏi tự viết, và tự build phần khác biệt (agent + liên kết bằng chứng) — đúng thế mạnh của đội builder PMAX. Tận dụng tối đa thứ PMAX đã có: Supabase, Netlify, innovation system.
| Thành phần | Đề xuất | Vì sao |
|---|---|---|
| Xương sống dữ liệu | Supabase (Postgres + pgvector + Auth + RLS + Edge Functions) | Bảng + quan hệ hai chiều là native; đếm số dự án & tổng hợp kết quả bằng SQL view (tự động cập nhật hộ chiếu); có sẵn tìm kiếm ngữ nghĩa (pgvector) cho agent gom cụm; phân quyền 4 vai trò × 2 mức bằng RLS. |
| Nạp Lớp 1 — initiative | Connector đồng bộ từ innovation system → Supabase (webhook/API) | Không xây lại innovation system; chỉ hút ticket sang. |
| Nạp Lớp 1 — project learning | Form nộp riêng + nút manager approve (trong app hoặc Slack) | Mẫu riêng, duyệt nhẹ đúng như đã chốt. |
| Lớp nền — Paxy (benchmark) | Connector đồng bộ Paxy → Supabase (bảng benchmark theo Kênh×Giải pháp×Ngành) + SQL view chấm điểm kết quả | Để hộ chiếu tự so kết quả với chuẩn ngành, không phải con số trơ. |
| Lớp nền — Ad accounts | MCP các nền tảng (Meta / Google / TikTok) — agent gọi để đọc setup & hiệu suất live; có kiểm soát quyền & ghi log | Để audit account thật so với playbook (Lớp 3) mà không cần export thủ công. |
| Nội dung Lớp 2 (playbook) | Markdown lưu trong Supabase, có bảng lịch sử phiên bản (versioning trong DB — mục 11) | Ít tài liệu, cần lịch sử; “hộ chiếu” = các cột trong DB để agent ghi vào; xem/khôi phục phiên bản ngay trên Hub, không cần Git. |
| Lớp agent | Claude API: Opus 4.8 cho tổng hợp, Haiku 4.5 cho việc nhẹ/nhiều + embeddings (Voyage) + orchestration của đội builder | Đúng thế mạnh PMAX; chọn model theo độ khó để tối ưu chi phí. |
| Lịch & tự động | Supabase pg_cron / Edge Functions | Agent canh hạn rà soát, auto-hạ cấp tài liệu quá hạn. |
| Cửa vào người dùng | Web app (Next.js) trên Netlify + bot Slack hỏi–đáp | Vừa duyệt/tìm trực tiếp, vừa hỏi AI; sống trong Slack nơi đội làm việc. |
Initiative và project learning chảy vào.
Postgres lưu, pgvector đánh chỉ mục để tìm & gom cụm.
Agent gom cụm, tính bằng chứng, canh hạn; người đọc tra trên web hoặc hỏi bot.
Claude API không có sẵn embeddings (thứ để máy “hiểu” và gom các tài liệu giống nhau). Dùng nhà cung cấp riêng — Voyage AI (Anthropic khuyến nghị) — rồi lưu vector vào pgvector của Supabase. Đây là mảnh ghép nhỏ nhưng cần biết trước.
1) Innovation system hiện chạy trên tool gì? (Jira, Notion, hay tool nội bộ) — quyết định cách viết connector. 2) PMAX đã dùng Supabase chưa? Nếu rồi thì stack này lắp gần như tức thì; nếu chưa, Supabase vẫn là lựa chọn nhẹ và nhanh để bắt đầu.
Ba cơ chế vận hành · Làm rõ
Khi đơn giản hóa, bản trước đã làm mờ ba cơ chế mà mô hình mẫu vốn rất rõ. Đây là bản chốt: giữ đúng giá trị của Git/pull-request/hub, nhưng chạy trên giao diện dễ để dân không-code vẫn dùng được.
| Mô hình mẫu | Vấn đề | Cách của ta (cụ thể) |
|---|---|---|
| Git giữ mọi phiên bản | Git khó với người không code | Mỗi playbook có bảng lịch sử phiên bản trong Supabase. Mỗi lần sửa & được duyệt = 1 phiên bản mới, ghi rõ: ai sửa, ngày nào, đổi gì. Trên Hub bấm Xem lịch sử để so sánh v1/v2/v3 và khôi phục. Không cần biết Git. |
Nếu đội builder muốn một bản sao kỹ thuật, có thể đồng bộ ngầm sang Git — nhưng nguồn sự thật và cái người dùng thấy là bảng phiên bản trong DB.
Mô hình mẫu bắt tạo pull request trên Git rồi review — quá kỹ thuật cho account/creative. Ta giữ nguyên tinh thần “review trước khi vào” nhưng gói thành một “Đề xuất duyệt” trên giao diện dễ:
Champion bấm Đề xuất lên Kiểm chứng cho một tài liệu.
Thẻ hiện: bản xem trước + thay đổi (diff) + bằng chứng gắn kèm (initiative + project learning) + người đề xuất.
Thẻ vào hàng chờ duyệt của người kiểm chứng, kèm thông báo Slack.
Người duyệt bấm Duyệt / Yêu cầu sửa / Từ chối kèm nhận xét.
Duyệt xong: phiên bản mới lên, trạng thái đổi, ghi vào nhật ký kiểm chứng.
Đây chính là một “pull request” — có diff, có review, có phê duyệt — nhưng bỏ Git, đặt trên giao diện bấm-là-xong.
| Mô hình mẫu | Vấn đề | Cách của ta (cụ thể) |
|---|---|---|
| “Chỉ truy cập qua Agent” | Agent kém → cả kho vô dụng (một điểm chết) | Hub web là cửa chính duy nhất (một đường link). Trong Hub có tất cả: duyệt/tìm KB, xem hộ chiếu, nộp project learning, hàng chờ duyệt, và trợ lý AI nhúng ngay trong Hub (một ô hỏi–đáp, không phải cửa riêng). Slack chỉ là cửa phụ — thông báo + hỏi nhanh, mọi link đều dẫn về Hub. |
Ba cơ chế trên vẫn là versioning thật, cổng review thật, hub thật — không mất gì so với bản gốc. Khác biệt duy nhất: chúng chạy trên giao diện dễ thay vì Git + agent-only, nên cả người không-code lẫn champion đều dùng được ngay.
Liên kết đa trục & duyệt đa domain · Mới
Một tài liệu hiếm khi thuộc đúng một trục. Một initiative “form 3 trường” vừa thuộc Kênh: Facebook vừa phục vụ Giải pháp: leadgen. Thiết kế phải phản ánh điều đó — cả ở cách hiển thị lẫn cách duyệt.
Đây chính là lý do dùng cơ sở dữ liệu quan hệ chứ không phải các file rời: tài liệu ↔ nhãn là quan hệ, nên một bản ghi hiện ở nhiều “view” mà vẫn là một. File rời (mỗi kênh một thư mục) sẽ đẻ ra bản sao và lệch nhau.
Validator không phải một người. Mỗi domain (mỗi kênh, mỗi giải pháp, mỗi ngành) có validator riêng am hiểu lĩnh vực đó. Khi một tài liệu chạm nhiều domain:
Thẻ “Đề xuất duyệt” tự tách thành các phần duyệt theo domain nó chạm (VD: Kênh Meta · Giải pháp ra-đơn · Ngành BĐS).
Mỗi phần được gửi tới validator của domain đó, kèm thông báo. Ai chỉ duyệt phần thuộc chuyên môn mình.
Tài liệu chỉ lên “kiểm-chứng” khi đủ chữ ký của mọi domain liên quan. Theo dõi tiến độ N/M domain đã duyệt.
Tránh một người duyệt thứ ngoài chuyên môn (validator Meta không nên gật đầu cho phần chiến lược ngành ngân hàng). Chất lượng được đảm bảo bởi đúng người cho đúng phần — nhưng vẫn là một tài liệu, một hộ chiếu.
Lộ trình triển khai
Vì đã có KB và innovation system, lộ trình là “lắp băng chuyền” lên nền sẵn có.
Chốt 4 trạng thái, mẫu “hộ chiếu”, ngưỡng duyệt. Rà KB cũ: cái nào gắn hộ chiếu & giữ, cái nào đánh dấu “ngừng dùng”. Ngay bước này đã trả lời được “cái nào còn dùng được”.
Builder nối submission innovation chảy tự động vào dòng học hỏi. Chạy buổi Project Learning đầu tiên để có nguyên liệu thật.
Champion tổng hợp cụm đầu tiên thành playbook có hộ chiếu đầy đủ. Bật agent gom cụm, tính bằng chứng, canh hạn.
Thêm Agent 4 (hỏi–đáp). Khi có nhu cầu thật mới tính phân khúc Enterprise/SME, phân quyền chi tiết hơn.
Đối chiếu
| Thành phần | Quyết định | Lý do |
|---|---|---|
| 3 trục & vòng đời 4 trạng thái (mô hình mẫu) | Giữ | Phần tĩnh tốt, giữ nguyên. |
| Kiến trúc phân lớp: dữ liệu nền → học hỏi → kiến thức → audit | Mới | Kiến thức bám vào dữ liệu; có vòng audit khép kín (mục 03). |
| Paxy làm lớp nền benchmark | Giữ | Giữ ý “data layer” của mô hình mẫu; benchmark hóa mọi kết quả. |
| Ad accounts qua MCP để audit | Mới | Kiến thức gặp thực tế; đóng vòng phản hồi (Lớp 3). |
| “Hộ chiếu sống” gắn bằng chứng | Mới | Trả lời trực tiếp 5 câu hỏi đau đầu. |
| Cơ chế đẩy–duyệt có ngưỡng rõ ràng | Mới | Cái KB cũ thiếu hẳn. |
| Nối với innovation system (KPI) | Mới | Tận dụng dòng đóng góp có sẵn. |
| Hai cỡ nguyên liệu: initiative + project learning | Mới | Ticket cho số; project learning cho bối cảnh & ứng viên playbook. |
| Liên kết đa trục — một bản ghi hiện nhiều nơi | Mới | Một nguồn sự thật; sửa một chỗ, mọi trục đổi theo (mục 12). |
| Duyệt đa domain — nhiều validator theo chuyên môn | Mới | Đủ chữ ký mọi domain liên quan mới lên kiểm-chứng (mục 12). |
| Agent để curation (không phải cửa duy nhất) | Đổi | Đảo lại “bỏ agent” của v0.1; tận dụng builder PMAX. |
| Versioning bằng Git | Đổi | Bảng lịch sử phiên bản trong DB, xem trên Hub (mục 11). |
| Duyệt bằng pull request + CI | Đổi | Thẻ “Đề xuất duyệt” giống PR nhưng trên giao diện dễ (mục 11). |
| “Chỉ truy cập qua Agent” (mô hình mẫu) | Bỏ | Một Hub web duy nhất; AI nhúng trong Hub, không phải cửa riêng (mục 11). |
| Tách sẵn Enterprise/SME/Global | Bỏ | Để Giai đoạn 3, khi có nhu cầu thật. |
Rủi ro & cách phòng
| Rủi ro | Cách phòng |
|---|---|
| Nghẽn ở khâu tổng hợp | Nguyên liệu chảy vào nhiều mà champion không đủ giờ codify → phân bổ giờ chính thức cho synthesis; agent gom cụm để giảm tải. |
| Cảnh báo quá hạn bị phớt lờ | Auto-hạ cấp có răng: quá hạn không ai bảo vệ thì tự chuyển “ngừng dùng” — im lặng = mất chuẩn. |
| Bằng chứng bị “làm đẹp” | Hộ chiếu liên kết ngược về thử nghiệm gốc, truy vết được; người kiểm chứng độc lập với người codify. |
| Innovation submission chất lượng thấp | Mẫu nộp có ô số liệu bắt buộc; agent lọc mục thiếu kết quả trước khi vào giỏ tổng hợp. |
| Xây agent trước, quy trình sau | Bám lộ trình: chuẩn hóa & quy trình con người chạy được trước, agent chỉ tự động hóa cái đã rõ. |
PMAX không cần một cái tủ hồ sơ đẹp hơn. PMAX cần một băng chuyền biến dòng thử nghiệm đang chảy thành playbook có bằng chứng, luôn biết mình còn đáng tin tới đâu.