Bài 2 nói về tư duy giao từng việc, bài 3 nói về xây một bộ luật chơi cố định, bài 4 nói về việc dạy AI kiến thức chuyên môn mà nó không có sẵn. Bài này đặt cả ba vào bối cảnh trọn vẹn hơn: một dự án, từ lúc chỉ là ý tưởng tới lúc thành thứ dùng được.
Cần nói trước để bạn khỏi hiểu lầm: đây không phải bài dạy công nghệ, kỹ thuật xây dựng (HTML, Firebase, hay bất kỳ công cụ nào chỉ là phần thực thi). Nguyên tắc dưới đây áp dụng được cho bất kỳ loại "sản phẩm" nào, một app, một file Excel tự động hoá, hay một quy trình làm việc mới, không riêng gì phần mềm. Cái quyết định sản phẩm có dùng được hay không là ý tưởng rõ ràng và cách làm việc có phương pháp, không phải kỹ thuật. Kỹ thuật vẫn rất quan trọng, nhưng với hầu hết bài toán, luôn có nhiều giải pháp kỹ thuật khác nhau cùng giải quyết được vấn đề. Cái làm sản phẩm này khác sản phẩm kia không nằm ở chọn đúng công nghệ, mà ở việc bạn biết mình cần gì và làm có phương pháp hay không.
Ý tưởng tốt quan trọng hơn kỹ thuật
AI viết code giỏi, nhưng không biết bạn thực sự cần gì nếu chính bạn cũng chưa hình dung rõ. Việc đầu tiên, trước khi giao AI dòng nào, là tự làm rõ bài toán: ai dùng, dùng để làm gì, "đủ tốt" là như thế nào. Đây là bản mở rộng của nguyên tắc "đặt task rõ ràng, có tiêu chí xong" ở bài 2, chỉ khác là áp dụng cho cả một dự án chứ không phải một task lẻ.
Thực ra việc giao ý tưởng cho AI triển khai không khó như nhiều người nghĩ. Bạn chỉ cần tập trung chọn lọc những ý bạn thấy thực sự cần thiết, hoặc nếu đã hình dung được kết quả cuối cùng, có thể suy ngược lại thành yêu cầu (với những thứ bạn muốn AI tự động hoá giúp). Không cần lo ý tưởng của mình còn lộn xộn, chưa mạch lạc, AI sẽ giúp hệ thống hoá lại những gì bạn đưa ra.
Ví dụ của tôi là dự án "Heo đất thông minh". Ý tưởng ban đầu chỉ ở mức sơ khai: tôi muốn dạy con (9-12 tuổi) về giáo dục tài chính, nhưng chưa biết triển khai cụ thể ra sao. Tôi đưa ý tưởng đó vào Claude, AI gợi ý hướng một ứng dụng tiết kiệm/chi tiêu, và chúng tôi cùng xây ra một bộ tính năng khá đầy đủ: phân biệt "Cần" và "Muốn", một khu chợ ảo để bé tự thêm món, những tình huống bất ngờ (thủng lốp xe, sinh nhật bạn, ốm phải mua thuốc) buộc bé phải chọn lấy tiền từ đâu, cơ chế heo đất và ngân hàng để dạy về lãi suất và rủi ro, biểu đồ lạm phát cho thấy tiền để yên mua được ít dần, và huy hiệu cho từng thói quen tốt.
Nhưng tới lúc xong, tôi vẫn chưa hài lòng và chưa đưa vào dùng thật, một phần vì thấy khô khan, thiếu yếu tố hấp dẫn với trẻ con, một phần vì gần đây con tôi cũng có nhiều thứ mới cuốn hút hơn. Bài học tôi rút ra: ý tưởng sơ khai ban đầu của tôi mới chỉ là mục tiêu (dạy con về tiền), còn AI dựa vào đó tự lấp đầy phần cách thực hiện (dạng ứng dụng nào, tính năng gì). Nếu tôi không hình dung rõ thêm yếu tố "hấp dẫn với trẻ con" nghĩa là gì ngay từ đầu, AI cũng không tự biết cần đưa vào, và không ai kiểm tra lại điều đó cho tới khi sản phẩm đã xong xuôi.
Một ví dụ khác cho thấy rõ hơn việc này: dù làm game cho con chơi, tôi luôn chủ động đưa vào giới hạn kỹ thuật để con không mải mê chơi. Với game xếp hình hay bắn bóng, cứ 15 phút màn chơi tự khoá lại, yêu cầu lưu tiến trình, nghỉ 10 phút mới chơi tiếp, một ngày chơi tối đa 60 phút. Với "Triệu phú tri thức", chỉ chơi được từ 7h sáng tới 22h, chơi ngoài khung giờ đó thì không được tính phần thưởng. Đây là những ràng buộc AI sẽ không bao giờ tự đề xuất, vì nó xuất phát từ giá trị của riêng tôi với tư cách phụ huynh, không phải từ yêu cầu chức năng thông thường của một app trò chơi.
💡 Mẹo hay: Đôi khi bạn phân vân giữa vài cách thức, phương án hay hướng đi khác nhau. Lúc đó có thể nhờ AI phác hoạ cụ thể hơn từng phương án để có cơ sở so sánh trước khi quyết định, hoặc thậm chí hỏi thẳng AI nên chọn hướng nào cho phù hợp với định hướng ban đầu của bạn. Ngay cả khi bí ý tưởng hoàn toàn, chưa có phương án nào trong đầu, bạn vẫn có thể nhờ AI phác thảo vài hướng đi khác nhau, từ đó khơi nguồn cho ý tưởng của riêng mình. AI không thay bạn quyết định cuối cùng, nhưng giúp bạn nhìn rõ hơn từng lựa chọn trước khi tự quyết.
Bắt đầu đơn giản, phức tạp hoá dần khi có nhu cầu thật
Đừng chọn giải pháp phức tạp chỉ vì trông "chuyên nghiệp hơn". Một công cụ cá nhân không cần nhiều người dùng chung dữ liệu ngay từ đầu, chỉ nên thêm tính năng đồng bộ dữ liệu khi thực sự có nhu cầu đó. Đúng tinh thần "thành thật với chính mình" đã nói ở bài 4, không phải lúc nào cũng cần tự động hoá, giờ mở rộng thành nguyên tắc chung hơn cho cả việc chọn độ phức tạp của giải pháp, không riêng chuyện có tự động hoá hay không.
💡 Mẹo hay: Dấu hiệu để biết mình đang tăng độ phức tạp không cần thiết: nếu bạn phải tự hỏi "tính năng này để làm gì" mà không trả lời được bằng một nhu cầu cụ thể đang có, nhiều khả năng nó chỉ đang tồn tại vì "nghe có vẻ nên có", chứ không phải vì thực sự cần.
Bài 6 sẽ nói kỹ hơn về việc dự án lớn dần thì lúc nào mới thực sự cần thêm độ phức tạp. Ở đây tôi chỉ nêu nguyên tắc nền: bắt đầu từ bản đơn giản nhất giải quyết được vấn đề trước mắt, đừng lo trước cho những nhu cầu chưa xuất hiện.
Đưa sản phẩm ra dùng thật: đôi nét về GitHub và Vercel
Nếu bạn làm một app chạy trên web, tới lúc nào đó sẽ cần đưa nó lên mạng để dùng được ở bất kỳ đâu, không chỉ trên máy của mình. Hai công cụ tôi hay dùng cùng Claude cho việc này là GitHub (nơi lưu trữ code) và Vercel (nơi biến code đó thành một trang chạy online). Tôi không đi sâu cách dùng ở đây, phần đó bạn hoàn toàn có thể nhờ chính AI hướng dẫn từng bước một lúc thực hiện, dễ theo dõi hơn nhiều so với đọc một bài hướng dẫn tĩnh không đúng với tình huống cụ thể của bạn.
Câu chuyện chọn công cụ của tôi cũng là một ví dụ cho đúng nguyên tắc "bắt đầu đơn giản, phức tạp hoá dần" ở trên. Ban đầu tôi dùng GitHub Pages (tính năng đưa trang web lên mạng có sẵn trong GitHub, miễn phí và đơn giản) cho vài app đầu tiên, vì lúc đó chỉ cần vậy là đủ. Nhưng GitHub Pages muốn dùng miễn phí thì repo (kho lưu code) phải để public, ai cũng xem được code. Sau này, khi có app tôi không muốn công khai code, tôi chuyển hướng: để repo ở chế độ private, rồi đẩy sang Vercel để chạy online (Vercel hỗ trợ triển khai từ repo private miễn phí ở gói cá nhân). Đây đúng là ví dụ về việc đổi công cụ khi nhu cầu thật xuất hiện, không phải chọn công cụ "xịn hơn" ngay từ đầu vì nghe có vẻ nên dùng.
Gu thẩm mỹ và chất lượng là của bạn, AI không quyết thay được
AI không có gu thay bạn. Vai trò của bạn là mô tả rõ điều mình muốn: cảm giác, phong cách, mức độ chi tiết, màu sắc... rồi phản hồi cụ thể trên kết quả AI đưa ra, thay vì chấp nhận bản đầu tiên cho xong. Bạn không cần nghĩ ra tất cả, như tôi đã nhắc ở bài trước, bạn hoàn toàn có thể học hỏi từ những thứ tốt đã có sẵn. Một điều tôi cũng hay tự nhắc mình: nếu bạn có thể mô tả điều bạn muốn một cách rõ ràng, mạch lạc, thì AI hoàn toàn có thể biến nó thành thực tế hoàn chỉnh.
Ví dụ của tôi là một ứng dụng dịch thuật tôi làm, dùng API dịch trả phí, cài trên máy tính. Bản đầu giao diện rất xấu, kiểu cũ kỹ, lúc đó tôi chọn nhầm base/thư viện giao diện không hợp, và phải làm lại gần như từ đầu phần giao diện. Bài học ở đây: nếu chỉ nói "làm giao diện cho ứng dụng dịch" mà không mô tả rõ phong cách mong muốn, AI sẽ tự chọn một hướng mặc định, không đảm bảo đúng gu của mình. Nhiều khi phải làm lại mới nhận ra vấn đề nằm ở chỗ mình chưa mô tả rõ ngay từ đầu, chứ không phải AI "làm ẩu".
Mô tả tổng thể trước, rồi mới chia giai đoạn
Khác với chia nhỏ một task đơn lẻ đã nói ở bài 2, ở quy mô một dự án, nên mô tả bức tranh tổng thể cho AI trước, để AI ước lượng được độ phức tạp thật sự, rồi mới chia giai đoạn có điểm dừng kiểm tra. Không nên chia nhỏ ngay từ đầu khi chưa ai, kể cả AI, hình dung hết dự án lớn tới đâu.
💡 Mẹo hay: Trước khi chia giai đoạn, thử mô tả toàn bộ dự án cho AI trong một đoạn ngắn và hỏi thẳng: "nếu làm hết những thứ này, theo bạn nên chia thành mấy giai đoạn, và vì sao chia như vậy". Câu trả lời thường lộ ra ngay những phần bạn chưa nghĩ tới, trước khi bắt tay vào làm.
App "Bài tập về nhà" tôi kể ở bài 2, chia thành 6 giai đoạn, chính là kết quả của bước mô tả tổng thể này. Bước đó giúp việc chia 6 giai đoạn hợp lý ngay từ đầu, chứ không phải chia mò rồi giữa chừng mới phát hiện thiếu.
Ý tưởng → Làm rõ yêu cầu → Chia giai đoạn → Kiểm tra → Hoàn thiện
Sai lầm thường gặp
- Giao việc quá lớn một lần rồi thất vọng vì kết quả không như ý.
- Không tự kiểm tra/dùng thử thực tế trước khi coi là xong, nối lại nguyên tắc "tự kiểm tra" ở bài 2.
- Để AI tự quyết định thay mình những việc lẽ ra mình phải quyết định: gu, phạm vi, mức độ phức tạp.
Chốt lại
Sản phẩm dùng được là kết quả của ý tưởng rõ và những quyết định đúng lúc. Kỹ thuật chỉ là công cụ thực thi những quyết định đó. Bài tiếp theo tôi sẽ nói về việc khi dự án lớn dần, làm sao biết lúc nào thực sự cần tăng độ phức tạp, thay vì thêm chỉ vì "chắc sẽ cần".