Cảm hứng từ lăng Minh Mạng: Một trục thần đạo cho kiến trúc phần mềm

Trong một chuyến đến Huế, tôi ghé thăm lăng Minh Mạng. Trước khi bước vào, tôi nghĩ về vị hoàng đế quyền uy đã để lại nhiều dấu ấn trong việc tổ chức triều chính, củng cố và mở rộng phạm vi ảnh hưởng của đất nước. Cương vực dưới thời ông thường được nhắc đến là một trong những giai đoạn rộng lớn nhất của lịch sử quân chủ Việt Nam.

Đứng trước lăng của một vị vua như thế, tôi bỗng tự hỏi: Làm sao mình có thể nắm quyền kiểm soát đối với “giang sơn” phần mềm do chính mình xây dựng?

Rồi tôi bước vào lăng. Các công trình chính lần lượt hiện ra trên một trục thần đạo thẳng tắp, xuyên suốt. Từng hạng mục có vị trí riêng, nhưng tất cả cùng thuộc về một bố cục rõ ràng, uy nghiêm. Chính trục ấy gợi cho tôi câu trả lời: muốn kiểm soát một hệ thống nhiều tính năng, trước hết phải tìm ra logic cốt lõi xuyên suốt tất cả tính năng đó.

Trục thần đạo của một ứng dụng AI CV Maker

Khi thiết kế ứng dụng AI CV Maker, tôi xác định một luồng nghiệp vụ chính:

Thu thập thông tin CV → Thu thập thông tin JD → Tìm hiểu mong muốn của người dùng và khai thác thêm dữ liệu → Tạo CV.

Đó là trục thần đạo của sản phẩm.

Muốn tạo một CV phù hợp, hệ thống cần biết người dùng đã làm gì và có năng lực gì. Tiếp đó, nó cần hiểu vị trí người dùng muốn ứng tuyển. Sau khi đối chiếu hai phía, AI có thể hỏi thêm: Dự án này bạn đóng vai trò gì? Kết quả nào có thể đo lường? Bạn muốn nhấn mạnh kinh nghiệm quản lý hay chiều sâu kỹ thuật? Cuối cùng, hệ thống mới tổng hợp thông tin để tạo CV.

Trên giao diện, ứng dụng có thể thiên biến vạn hóa. Nhưng nhìn từ nghiệp vụ, các tính năng chủ yếu thuộc ba cụm.

1. Tạo CV từ đầu

Người dùng có thể điền form, trò chuyện với AI hoặc voice chat. Ba trải nghiệm rất khác nhau, nhưng đều phục vụ bước đầu tiên của trục chính: thu thập thông tin CV.

Form thu thập thông tin qua các trường dữ liệu. Chat khai thác thông tin qua câu hỏi. Voice chat nhận lời kể của người dùng rồi chuyển thành dữ liệu có cấu trúc. Khi đã thu thập đủ, cả ba cùng đưa dữ liệu vào những bước tiếp theo: tìm hiểu JD, làm rõ mong muốn, khai thác chi tiết còn thiếu và tạo CV.

2. Cải tiến CV có sẵn

Người dùng tải lên một CV cũ. Hệ thống đọc, phân tích và trích xuất kinh nghiệm, kỹ năng, học vấn, dự án từ tài liệu ấy.

Thoạt nhìn, đây giống một tính năng khác hẳn tạo CV từ đầu. Một bên là “tạo mới”, một bên là “cải tiến”. Nhưng CV được tải lên thực chất chỉ giúp hệ thống đi nhanh hơn qua bước thu thập thông tin CV. Thay vì hỏi lại toàn bộ từ đầu, ứng dụng có sẵn một bản thông tin ban đầu để kiểm tra và bổ sung.

Sau đó, người dùng vẫn có thể cung cấp JD, nói rõ mong muốn, trả lời những câu hỏi AI cần khai thác thêm, rồi nhận một CV mới phù hợp hơn với mục tiêu ứng tuyển.

3. Điều chỉnh CV cho phù hợp với JD

Ở cụm tính năng này, người dùng tải lên CV và JD cùng một lần. AI đọc CV để thu thập thông tin về ứng viên, đồng thời đọc JD để hiểu yêu cầu của vị trí. Sau đó, hệ thống đối chiếu hai phía, hỏi thêm nếu cần và tạo phiên bản CV nhấn mạnh những kinh nghiệm, kỹ năng phù hợp với công việc ấy.

Trên giao diện, đây có thể là một tính năng riêng mang tên “Fit CV với JD”: chỉ một lần upload để bắt đầu quá trình tối ưu. Nhưng ở tầng nghiệp vụ, lần upload ấy đơn giản là cách cung cấp sẵn dữ liệu cho hai bước đầu tiên của trục thần đạo. Người dùng đi nhanh hơn qua phần thu thập thông tin; các bước tìm hiểu mong muốn, khai thác dữ liệu còn thiếu và tạo CV vẫn đi theo cùng một logic.

Ba cụm tính năng, nhiều cách bắt đầu, nhưng chỉ một trục nghiệp vụ. “Tạo mới”, “cải tiến” hay “fit CV với JD” mô tả điều người dùng muốn làm; chúng không nhất thiết phải trở thành ba bộ máy tạo CV riêng biệt.

Nếu dựng nhiều trục, chuyện gì sẽ xảy ra?

Giả sử đội phát triển coi “tạo CV từ đầu”, “cải tiến CV có sẵn” và “fit CV với JD” là ba sản phẩm tách biệt.

Nhánh tạo mới có bộ câu hỏi khai thác kinh nghiệm và prompt tạo CV riêng. Nhánh cải tiến cũng có những thứ tương tự, nhưng được viết lại cho luồng upload CV. Nhánh fit CV lại có cách phân tích JD và chọn nội dung riêng. Một thời gian sau, đội ngũ cải thiện cách AI hỏi về thành tựu có số liệu. Nhánh tạo mới được cập nhật, hai nhánh còn lại thì chưa. Người dùng cung cấp cùng một kinh nghiệm nhưng nhận ba chất lượng CV khác nhau, chỉ vì họ bắt đầu bằng ba cách khác nhau.

Rồi sản phẩm thêm voice chat. Ta lại phải quyết định: voice chat chỉ thuộc tạo mới, hay người đã upload CV cũng được dùng? Nếu người dùng upload cả CV và JD rồi muốn bổ sung thành tựu bằng giọng nói thì phải đi nhánh nào? Mỗi tính năng mới lại buộc ta nối những luồng vốn bị tách rời. Logic bắt đầu chồng chéo, còn ranh giới giữa các nhánh ngày càng khó giải thích.

Đó là lúc giang sơn phần mềm có nhiều triều đình cùng ban luật. Bề ngoài, giao diện vẫn hoạt động. Bên trong, cùng một việc lại được quyết định ở nhiều nơi. Người xây dựng hệ thống mất dần khả năng nhìn toàn cục.

Muốn thấy trục chính, cần giữ cái đầu của một vị minh quân

Trong các cuộc họp sản phẩm, mọi người thường nói bằng tên tính năng: “làm luồng tạo CV mới”, “làm luồng cải tiến CV”, “làm luồng fit CV với JD”. Cách gọi ấy hữu ích để thảo luận trải nghiệm người dùng, nhưng cũng dễ khiến người nghe mặc nhiên xem chúng là ba nghiệp vụ độc lập.

Để nhìn ra trục thần đạo, tôi phải lùi lại khỏi những tên gọi ấy và tự hỏi: Người dùng đã cung cấp thông tin gì? Hệ thống còn thiếu gì? Quyết định nghiệp vụ nào thực sự khác nhau? Một vị minh quân không thể chỉ nghe tên từng tấu chương rồi lập ra một cơ quan mới cho mỗi việc. Người thiết kế hệ thống cũng cần đủ tỉnh táo để nhìn qua ngôn từ trong cuộc họp, nhận ra những yêu cầu khác tên nhưng cùng bản chất.

Nhờ vậy, “upload CV”, “chat với AI” và “điền form” trở thành những cách thu thập thông tin. “Fit CV với JD” trở thành cách cung cấp nhanh cả thông tin CV lẫn JD. Những tên tính năng vẫn tồn tại trên giao diện; còn bên dưới, ta nhìn thấy một trật tự chung.

Một trục không có nghĩa là một hàm khổng lồ

Trục thần đạo là trật tự nghiệp vụ, không phải lời kêu gọi nhét tất cả vào một service.

Ứng dụng vẫn có thể có thành phần phân tích CV tải lên, thành phần xử lý giọng nói, bộ phân tích JD, cơ chế xác định thông tin còn thiếu và bộ tạo CV. Mỗi thành phần đảm nhiệm một việc rõ ràng. Điểm quan trọng là chúng cùng đưa dữ liệu về một mô hình thông tin CV chung và tham gia vào một quy trình tạo CV nhất quán.

Nhờ vậy, khi thay đổi cách khai thác thành tựu hoặc tiêu chí đối chiếu CV với JD, ta biết nơi cần sửa và những trải nghiệm nào sẽ được hưởng lợi. Khi thêm một cách nhập liệu mới, ta tập trung giải quyết cách thu thập và chuẩn hóa thông tin, thay vì viết lại toàn bộ quá trình tạo CV.

Tư duy này có trái với nguyên tắc đầu tiên của SOLID?

Nguyên tắc đầu tiên của SOLID là Single Responsibility Principle (SRP): một thành phần nên có một trách nhiệm rõ ràng, hay nói cách khác, có một lý do chính để thay đổi. Nhìn vào trục thần đạo dài từ thu thập dữ liệu đến tạo CV, ta có thể lo rằng nó đang ôm quá nhiều trách nhiệm.

Điều cần phân biệt là luồng nghiệp vụ và thành phần thực thi từng bước. Trục thần đạo mô tả trình tự và quy tắc phối hợp để hoàn thành mục tiêu “tạo một CV phù hợp”. Nó không yêu cầu một class vừa nhận giọng nói, vừa đọc PDF, vừa phân tích JD, vừa viết nội dung CV. Xử lý giọng nói thay đổi vì công nghệ nhận diện âm thanh; phân tích JD thay đổi vì cách đọc yêu cầu tuyển dụng; bộ tạo CV thay đổi vì cách trình bày nội dung. Chúng có những lý do thay đổi khác nhau nên được tách thành những thành phần riêng.

Nếu có một thành phần điều phối trục chính, trách nhiệm của nó là đưa yêu cầu qua các bước nghiệp vụ đúng thứ tự và xác định bước tiếp theo. Nó gọi các thành phần chuyên trách, thay vì làm thay công việc của họ. Như vậy, một trục nghiệp vụ thống nhất và những thành phần tuân thủ SRP hoàn toàn có thể cùng tồn tại: trục giữ cho toàn bộ hành trình nhất quán, còn mỗi thành phần giữ trách nhiệm của mình rõ ràng.

Giữ trục chính khi yêu cầu mới xuất hiện

Vẽ ra trục thần đạo đã khó; bảo vệ nó qua các vòng phát triển sản phẩm còn khó hơn.

Có lúc PO muốn luồng “fit CV với JD” bỏ qua toàn bộ câu hỏi bổ sung để người dùng nhận kết quả ngay. Có lúc một bên liên quan muốn luồng “cải tiến CV” dùng prompt riêng vì cho rằng người đã có CV sẽ có nhu cầu khác người tạo mới. Những đề xuất ấy có thể xuất phát từ nhu cầu thật. Ta cần lắng nghe và đánh giá tác động của chúng, thay vì bác bỏ chỉ để giữ sơ đồ ban đầu.

Nhưng trước khi tạo một nhánh nghiệp vụ riêng, tôi sẽ hỏi: Khác biệt này nằm ở trải nghiệm, ở dữ liệu đầu vào, hay thực sự là một quy tắc tạo CV khác? Nếu người dùng muốn có kết quả nhanh, hệ thống có thể cho phép tạo bản nháp với dữ liệu đang có và hỏi tiếp khi họ muốn hoàn thiện. Nếu CV có sẵn cần cách đặt câu hỏi khác, thành phần khai thác thông tin có thể dựa trên dữ liệu đã biết để chọn câu hỏi phù hợp. Cả hai trường hợp đều có thể giữ trục chính.

Bảo vệ kiến trúc không phải là từ chối mọi ngoại lệ. Đó là làm rõ lý do của ngoại lệ, đưa nó vào đúng vị trí và tránh để một yêu cầu riêng trên giao diện âm thầm biến thành một bộ luật song song. Khi quả thật có một mục tiêu nghiệp vụ khác, ta có thể thiết kế luồng khác. Còn khi bản chất vẫn là tạo CV dựa trên thông tin ứng viên, JD và mong muốn của họ, trục thần đạo là thứ đáng giữ.

Quyền uy đến từ việc hiểu rõ hệ thống của mình

Lăng Minh Mạng có một lối vào và một trục thần đạo xuyên suốt. Ứng dụng AI CV Maker có nhiều cách để người dùng bắt đầu, nhưng từ cảm hứng về trục ấy, tôi chọn cho các trải nghiệm cùng hội tụ vào một logic nghiệp vụ.

Form, chat, voice chat, upload CV hay upload đồng thời CV và JD là những cách tiếp cận khác nhau. Tạo mới, cải tiến hay fit CV với JD là những tên gọi hữu ích trên giao diện. Nhưng ở tầng cốt lõi, tất cả đều phục vụ một hành trình: hiểu ứng viên, hiểu công việc, làm rõ điều ứng viên muốn thể hiện, rồi tạo nên một CV phù hợp.

Một vị quân vương nắm được giang sơn khi hiểu trật tự vận hành của nó. Với người làm phần mềm cũng vậy. Khi nhìn xuyên qua những màn hình và tên tính năng để thấy một trục logic rõ ràng, ta mới thực sự nắm quyền kiểm soát hệ thống mình tạo ra.

Xem video