Hệ thống tốt không cần bắt đầu thật lớn

Gần đây, trong một lần brainstorm về việc có thể học gì từ một bộ gồm nhiều “skill” chuyên biệt cho quảng cáo, tôi có một phản xạ khá rõ: đừng vội nghĩ tới việc xây một hệ thống thật to.

Một hệ thống lớn nghe rất hấp dẫn. Nó cho cảm giác đầy đủ, chuyên nghiệp và có tầm nhìn. Nhưng trong thực tế, phần khó nhất không phải là vẽ ra một kiến trúc lớn. Phần khó hơn là làm cho từng phần bên trong thật sự hữu ích, dùng được nhiều lần và không làm cả hệ thống trở nên nặng nề.

Tôi bắt đầu thích một cách nhìn khác hơn:

Hệ thống không nhất thiết phải được “xây xong” rồi mới dùng. Nó có thể lớn lên từ những phần nhỏ đã chạy được.

Điều này nghe đơn giản, nhưng lại thay đổi khá nhiều cách tôi nhìn vào automation, AI, dashboard, content hay thậm chí một dự án cá nhân.

Cái bẫy của việc muốn thiết kế mọi thứ từ đầu

Khi bắt đầu một dự án mới, tôi thường thấy rất dễ bị hút vào phần kiến trúc.

Nếu làm một hệ thống content, ta có thể nghĩ ngay tới lịch nội dung, taxonomy, prompt, workflow, database, dashboard, review, versioning, automation và hàng loạt rule.

Nếu làm một hệ thống marketing, ta có thể chia ngay theo funnel, kênh, audience, creative, attribution, measurement, experimentation, reporting, budget allocation.

Nếu làm một AI workflow, ta có thể nghĩ tới agent, memory, tool, guardrail, routing, logging, evaluation, permission và nhiều lớp khác.

Nhìn trên sơ đồ, mọi thứ rất hợp lý.

Nhưng sơ đồ có một nhược điểm: nó làm cho những thứ chưa chạy được trông giống như đã tồn tại.

Một ô có tên “Customer Research Skill” chưa có nghĩa là ta đã có một cách nghiên cứu khách hàng tốt.

Một ô có tên “Creative Testing System” chưa có nghĩa là team đã biết cách thiết kế thử nghiệm.

Một node “AI Agent” chưa có nghĩa là agent đó đủ đáng tin để giao việc.

Một dashboard có đủ tab chưa có nghĩa là người xem biết phải quyết định gì sau khi nhìn vào nó.

Tôi nghĩ đây là lý do nhiều hệ thống dễ trở thành một dạng “kiến trúc trên giấy”: cấu trúc rất đẹp, nhưng phần bên trong chưa đủ trưởng thành.

Một mô-đun nhỏ chạy được có giá trị hơn một hệ thống lớn chưa chạy

Trong buổi brainstorm đó, điều tôi thấy hợp lý hơn là coi mỗi phần như một skill nhỏ, một workflow nhỏ hoặc một mô-đun có nhiệm vụ rõ.

Ví dụ, thay vì nói “xây hệ thống Digital Marketing toàn diện”, có thể bắt đầu bằng một số năng lực nhỏ hơn:

• một skill để phân tích chân dung khách hàng;
• một skill để bóc tách quảng cáo đối thủ;
• một skill để tạo angle;
• một skill để kiểm tra hook;
• một skill để đọc dữ liệu sau thử nghiệm;
• một skill để gợi ý bước tiếp theo dựa trên kết quả.

Mỗi phần không cần “thông minh toàn diện”. Nó chỉ cần làm tốt một việc.

Điểm quan trọng là đầu vào và đầu ra phải rõ.

Nếu một skill nhận đầu vào là dữ liệu khách hàng và trả ra một bộ insight có cấu trúc, phần sau có thể dùng lại kết quả đó.

Nếu một workflow nhận một creative brief đã chuẩn hóa và trả ra danh sách hook theo một format cố định, một bước khác có thể review hoặc test tiếp.

Khi ranh giới rõ, việc ghép nối trở nên dễ hơn.

Và lúc đó, hệ thống bắt đầu xuất hiện không phải vì ta ép nó thành hệ thống, mà vì các phần nhỏ bắt đầu có quan hệ với nhau.

Hệ thống nằm ở mối nối, không chỉ ở số lượng thành phần

Có một điểm tôi thấy khá thú vị: nhiều phần nhỏ đặt cạnh nhau chưa chắc đã thành một hệ thống.

Một thư viện 50 prompt có thể vẫn chỉ là 50 prompt.

Một bộ 20 dashboard có thể vẫn chỉ là 20 dashboard.

Một folder chứa rất nhiều automation có thể vẫn chỉ là một folder chứa script.

Thứ biến chúng thành hệ thống là quy tắc kết nối.

Đầu ra của phần này có dùng được cho phần kia không?

Có format chung không?

Có tiêu chuẩn chất lượng chung không?

Có ai biết khi nào dùng mô-đun nào không?

Khi một mô-đun thay đổi, phần khác có bị vỡ không?

Có cách quan sát kết quả sau khi chạy không?

Theo cách nhìn này, một hệ thống tốt không nhất thiết phải có rất nhiều thành phần. Nó cần các thành phần có vai trò rõ và tương tác có chủ đích.

Tôi thấy nguyên tắc này khá gần với cách phần mềm được thiết kế tốt: không phải module càng nhiều càng hay, mà module cần đủ độc lập để thay đổi, đủ rõ để dùng lại và đủ nhất quán để ghép với phần khác.

Bắt đầu nhỏ không có nghĩa là nghĩ nhỏ

Có một phản biện dễ gặp: nếu chỉ làm từng phần nhỏ, liệu có rơi vào tình trạng chắp vá và thiếu tầm nhìn tổng thể không?

Tôi nghĩ có, nếu “làm nhỏ” đồng nghĩa với làm tùy tiện.

Nhưng tôi không hiểu modular theo nghĩa đó.

Vẫn cần một bức tranh tổng quan.

Chỉ là thay vì cố xây toàn bộ bức tranh trong một lần, ta dùng nó như bản đồ định hướng. Sau đó chọn một phần đáng làm nhất để đưa vào thực tế.

Ví dụ, với một hệ thống Marketing AI, bức tranh lớn có thể gồm Research → Strategy → Creative → Media → Measurement → Learning.

Ta vẫn biết sáu lớp này tồn tại.

Nhưng không nhất thiết phải xây cả sáu lớp ngay.

Nếu vấn đề hiện tại là creative đang thiếu insight, có thể bắt đầu từ Research + Angle. Khi hai phần đó chạy tốt, ta mới nối sang Brief hoặc Testing.

Nếu vấn đề là dữ liệu sau quảng cáo không tạo ra bài học, có thể bắt đầu từ Measurement + Learning thay vì lao vào tạo thêm content bằng AI.

Tầm nhìn lớn giúp biết mình đang đi đâu.

Mô-đun nhỏ giúp có thứ chạy được hôm nay.

Hai thứ không đối lập nhau.

Một lợi ích quan trọng: dễ biết cái gì đang không hiệu quả

Hệ thống càng lớn, khi kết quả không tốt càng khó biết lỗi nằm ở đâu.

Nếu một “agent marketing toàn diện” nghiên cứu, viết nội dung, chọn audience, phân tích dữ liệu và đưa ra quyết định trong cùng một flow, khi kết quả sai ta rất khó biết bước nào sai.

Do input kém?

Do prompt nghiên cứu?

Do cách tổng hợp insight?

Do logic chọn angle?

Do dữ liệu thiếu?

Hay do bước đánh giá cuối cùng?

Khi tách hệ thống thành những mô-đun nhỏ, việc kiểm tra dễ hơn nhiều.

Ta có thể đánh giá riêng từng phần.

Research có tìm đúng vấn đề không?

Angle có bám insight không?

Hook có đúng mục tiêu không?

Creative brief có đủ thông tin không?

Phân tích sau test có chỉ ra bài học thật không?

Điều này quan trọng đặc biệt khi dùng AI, vì AI có thể tạo ra đầu ra rất tròn trịa dù logic bên trong chưa chắc đúng.

Một hệ thống nhỏ giúp đặt checkpoint rõ hơn.

Mô-đun tốt nên có ranh giới đủ chặt nhưng không quá cứng

Tôi nghĩ một phần nhỏ đủ tốt thường cần ít nhất bốn thứ.

Thứ nhất là mục tiêu rõ: nó tồn tại để giải quyết vấn đề gì.

Thứ hai là đầu vào rõ: cần dữ liệu gì để chạy.

Thứ ba là đầu ra có cấu trúc: kết quả trả về ở dạng nào để bước tiếp theo dùng được.

Thứ tư là tiêu chuẩn kiểm tra: thế nào là một kết quả đủ tốt.

Nếu thiếu một trong bốn phần, mô-đun dễ biến thành một prompt “hỏi gì cũng được”. Khi đó nó rất linh hoạt nhưng khó tin cậy và khó tích hợp.

Ngược lại, nếu ràng buộc quá chặt, mô-đun lại trở thành một template cứng, chỉ chạy được đúng một tình huống.

Có lẽ phần thiết kế thú vị nằm ở giữa: đủ chặt để không chạy lung tung, đủ mở để vẫn dùng được trong nhiều bối cảnh gần nhau.

Đây cũng là cách tôi đang nhìn rộng hơn về AI agent: lợi thế không hẳn nằm ở việc làm ra một agent “biết hết”, mà ở việc thiết kế một hệ gồm nhiều khả năng nhỏ, có quyền rõ, tool rõ và điểm bàn giao rõ.

Hệ thống nên lớn lên theo ma sát thật

Một điểm khác tôi muốn giữ lại là: đừng thêm thành phần chỉ vì thấy nó hợp lý trên sơ đồ.

Nên thêm khi thực tế tạo ra ma sát.

Nếu mỗi lần làm customer research đều phải xử lý một bước giống nhau, đó là tín hiệu có thể tách thành skill.

Nếu creative team liên tục hiểu khác nhau về angle, có thể cần một format chuẩn ở giữa.

Nếu report luôn phải chỉnh tay trước khi gửi, có thể cần một lớp validation.

Nếu automation thường lỗi ở cùng một chỗ, có thể cần guardrail hoặc logging.

Hệ thống lúc đó lớn lên theo vấn đề thật chứ không theo trí tưởng tượng của người thiết kế.

Tôi thấy cách này có một ưu điểm rất thực dụng: mỗi phần mới thêm vào đều có lý do tồn tại.

Không phải vì “một hệ thống chuẩn phải có”.

Mà vì nếu không có nó, một ma sát cụ thể cứ lặp lại.

Có những thứ không nên biến thành module

Tất nhiên, không phải mọi thứ đều nên được tách nhỏ và chuẩn hóa.

Một số quyết định cần giữ nguyên tính tổng thể.

Ví dụ, định vị thương hiệu không nên bị chia thành hàng chục prompt độc lập rồi kỳ vọng ghép lại sẽ tự thành chiến lược.

Một quyết định về ngân sách cũng không thể chỉ lấy kết quả từ từng kênh rồi cộng cơ học lại; nó cần nhìn mục tiêu kinh doanh, biên lợi nhuận, giai đoạn funnel và chi phí cơ hội.

Một bài viết cá nhân cũng không nên được sản xuất bằng cách ghép hook module + outline module + paragraph module + CTA module rồi nghĩ rằng kết quả sẽ có giọng riêng.

Có những phần cần một người nhìn toàn cục.

Modular giúp giảm phức tạp trong thực thi, nhưng không thay thế judgment ở tầng hệ thống.

Tôi nghĩ đây là giới hạn quan trọng. Nếu không, ta rất dễ biến “tư duy hệ thống” thành “chia mọi thứ thành nhiều ô”.

Cách tôi muốn áp dụng nguyên tắc này

Nếu phải biến ý này thành một cách làm thực tế, tôi sẽ bắt đầu bằng ba câu hỏi.

Một: vấn đề lặp lại nào đang đủ rõ để tách ra thành một mô-đun?

Không cần bắt đầu từ “tôi muốn xây hệ thống gì”. Bắt đầu từ “việc gì đang lặp lại và đáng chuẩn hóa”.

Hai: đầu vào và đầu ra của mô-đun đó là gì?

Nếu chưa nói được rõ, có lẽ chưa nên tự động hóa.

Ba: kết quả của nó sẽ được dùng tiếp ở đâu?

Nếu đầu ra chỉ nằm lại trong một file rồi không ai dùng, phần đó chưa thật sự nằm trong một hệ thống.

Sau đó mới nghĩ tới việc nối các phần lại với nhau.

Có thể bước đầu chỉ là một prompt tốt.

Rồi thành một skill.

Rồi thành một workflow.

Rồi nhiều workflow dùng chung dữ liệu, tiêu chuẩn và logging.

Đến lúc đó, ta có một hệ thống.

Không phải vì đã đặt tên cho nó từ đầu, mà vì các phần nhỏ đã đủ trưởng thành để tạo thành một cấu trúc lớn hơn.

Điều tôi muốn giữ lại

Tôi vẫn thích những bức tranh lớn. Chúng giúp nhìn thấy mối quan hệ giữa nhiều phần và tránh tối ưu cục bộ.

Nhưng tôi ngày càng ít muốn bắt đầu bằng việc xây toàn bộ bức tranh đó.

Một hệ thống tốt có lẽ giống việc xây một khu phố hơn là dựng một bức tượng.

Ta cần quy hoạch, cần nguyên tắc chung và cần biết các phần sẽ kết nối ra sao. Nhưng từng căn vẫn phải sử dụng được. Đường phải đi được. Điện nước phải chạy được. Một khu phố không trở nên tốt chỉ vì bản quy hoạch nhìn đẹp.

Với AI, automation hay marketing cũng vậy.

Thay vì hỏi “làm sao xây một hệ thống thật toàn diện?”, có lẽ câu hỏi hữu ích hơn là:

Phần nhỏ nào, nếu làm tốt ngay bây giờ, vừa giải quyết được một việc thật vừa có thể trở thành viên gạch cho hệ thống lớn hơn?

Nếu trả lời được câu đó, hệ thống có thể bắt đầu rất nhỏ.

Và đôi khi chính vì bắt đầu nhỏ, nó mới có cơ hội lớn lên mà vẫn giữ được tính hữu ích.