Creating Presentation Slides with AI

Các tài liệu do AI tạo ra có những điểm yếu: chúng trông “giống AI” và ngữ nghĩa khó hiểu. dưới đây sẽ là cách tạo slide theo hướng dẫn của Uchita.

Link: https://note.com/uchita_success/n/na5babdc58b0e

Tình huống giả định trong brief là gì?

Brief này được xây dựng từ một tình huống giả định để làm đầu vào cho việc thử tạo slide bằng AI. Công ty ABC, quy mô nhóm và các số liệu trong brief đều là thông tin minh họa.

Giả sử ABC có 15 developer, chia thành ba nhóm nhỏ (squad). Nhóm thiếu checklist review chung, trong khi nhiều PR quan trọng cần Tech Lead tham gia. Bài toán đặt ra trong brief là chuẩn hóa thông tin trước khi review và phân công người phụ trách rõ ràng hơn.

Phương án minh họa là thử PR template, checklist, kiểm tra tự động và quy tắc phân công reviewer trong một squad suốt bốn tuần. Bộ slide cần trình bày phương án này, lịch thử nghiệm và tiêu chí để Tech Lead xem xét việc mở rộng.

Mục tiêu của lần thực hành là đánh giá cách AI tạo slide từ brief. Kế hoạch cải tiến code review là nội dung của tình huống giả định, chưa được triển khai trong nhóm thực tế.

Plan B của Uchita hoạt động thế nào?

Trong bài hướng dẫn của Uchita trên note, Plan B là lựa chọn tạo slide dưới dạng file HTML để mở bằng trình duyệt. Trước khi tạo file, cần xác định mỗi trang sẽ nói gì, dùng thông tin nào làm căn cứ và trình bày ra sao. Những nội dung này được ghi thành một bản thiết kế gọi là blueprint.

Quy trình trong bài hướng dẫn của Uchita gồm năm bước. Dưới đây là cách hiểu từng bước, kèm ví dụ áp dụng vào brief code review giả định trong project:

1. Viết rõ điều muốn người xem hiểu ở mỗi slide. Từ brief, chọn một ý chính cho từng trang và viết thành câu kết luận, kèm thông tin hỗ trợ.Ví dụ, slide mở đầu có câu: “Nhóm nên thử quy trình review mới trong một squad trước khi mở rộng.” Câu này thể hiện đề xuất mà Tech Lead cần xem xét. Đầu ra của bước này: câu thông điệp chính cho mỗi slide.
2. Sắp xếp các slide thành một câu chuyện dễ theo dõi. Đọc riêng các câu thông điệp theo thứ tự để kiểm tra xem trang sau có giải thích hoặc tiếp nối trang trước hay không.Với brief này, mạch trình bày là: đề xuất thử quy trình → thống nhất cách đo → phân công người review → chuẩn bị thông tin trong PR → quyết định điều kiện mở rộng. Đầu ra: bảng thông điệp ghi thứ tự các trang và mối liên hệ giữa chúng.
3. Chọn cách trình bày phù hợp với nội dung. Xác định người xem cần so sánh, hiểu các bước thực hiện hay đưa ra quyết định, rồi chọn mẫu bố cục tương ứng.Ví dụ, trang phân công reviewer dùng sơ đồ để thể hiện các bước xử lý; trang mở đầu dùng bảng để trình bày các quyết định cần chốt. Đầu ra: blueprint ghi nội dung, bố cục và dữ liệu cần có trên từng trang.
4. Dùng AI dựng file slide theo bản thiết kế. Với đầu ra B, yêu cầu AI viết HTML theo blueprint, áp dụng thống nhất cỡ chữ, màu sắc và khoảng cách.Trong project, bộ slide được dựng thành năm trang 1920×1080, gồm chữ, bảng và sơ đồ. Đầu ra: file slides.html có thể mở bằng trình duyệt để xem từng trang.
5. Mở slide, kiểm tra và sửa lỗi. Đối chiếu nội dung với brief, kiểm tra số liệu và dùng công cụ đo bố cục để tìm chữ bị tràn, chồng nhau hoặc khó đọc.Ví dụ, lần render đầu trong project phát hiện nội dung slide 2 đè lên chú thích. Bố cục được sửa rồi mở lại để kiểm tra. Đầu ra: bản slide đã chỉnh sửa và ảnh PNG để xem, chia sẻ hoặc đưa vào bài viết.

Như vậy, ba bước đầu giúp xác định nội dung và cách trình bày; hai bước sau biến bản thiết kế thành slide có thể xem và kiểm tra. Phần tiếp theo trình bày cụ thể các file đầu vào và thao tác đã thực hiện trong project.

Tôi đã thực hiện như thế nào?

Tôi yêu cầu AI dùng brief giả định trong meetings/brief.md để tạo năm slide tiếng Việt cho Tech Lead. Công việc được chia thành ba phần: lập dàn ý cho từng slide, tạo file HTML, rồi mở file để kiểm tra và chụp ảnh kết quả.

Để AI có hướng dẫn cụ thể, project cung cấp prompt của Uchita trong prompts/ultimate_prompt.md và ảnh mẫu bố cục trong prompts/template_samples.png .Các file tạo ra được lưu ở outputs/code-review để đối chiếu.

1. Kiểm tra brief và lập dàn ý từng slide

Một điểm cần xử lý ngay trong brief là cách gọi thời gian review. Đầu vào ghi trung bình 18 giờ để “review xong”, nhưng phần kỳ vọng lại nêu giảm từ 18 xuống 6 giờ “chờ review”. Thời gian đến phản hồi đầu tiên và thời gian đến approval có thể khác nhau. Vì vậy, bộ slide dành một trang để thống nhất cách đo trước khi đánh giá mục tiêu.

Hai con số này cần cùng định nghĩa trước khi dùng để tính mức giảm. Những thông tin còn thiếu, như ngưỡng chất lượng, được giữ là xx để dễ nhận ra phần phải bổ sung.

Kết luận chung của bộ tài liệu là nên thử quy trình review có phân công, đầu vào chuẩn hóa và cách đo thống nhất trong một squad trước khi mở rộng. Ba quyết định theo xuyên suốt gồm phạm vi pilot, cách vận hành và cách đánh giá.

AI tạo bảng thông điệp để sắp xếp thứ tự năm trang: đề xuất thử nghiệm → cách đo → phân công reviewer → thông tin cần có trong PR → tiêu chí mở rộng. Sau đó, bản thiết kế (blueprint) ghi cụ thể mỗi trang sẽ có câu kết luận nào, bảng hoặc sơ đồ gì và dùng dữ liệu nào từ brief

2. Tạo file HTML từ bản thiết kế

Toàn bộ yêu cầu của lần thực hành có thể rút gọn như sau:

Đọc AGENTS.md, prompts/ultimate_prompt.md và ảnh mẫu trong prompts/.
Dùng meetings/brief.md để tạo 5 slide tiếng Việt cho Tech Lead.
Xuất bảng thông điệp và blueprint trước khi dựng đầu ra B: HTML.
Ghi rõ tình huống ABC và mục tiêu pilot là giả định.
Tách thời gian chờ phản hồi đầu tiên khỏi thời gian hoàn tất review.
Giữ phạm vi pilot một squad trong bốn tuần.
Mở HTML trong trình duyệt, kiểm tra bố cục, xuất PNG và lưu lỗi cần sửa.

HTML gồm năm trang 1920×1080, dùng văn bản, bảng và sơ đồ SVG. File có nút chuyển trang, hỗ trợ phím mũi tên và mở offline. Bản tiếng Việt dùng font Arial có sẵn trên máy; tiêu đề được kiểm tra theo chiều rộng thực tế và giới hạn hai dòng.

3. Render và kiểm tra sản phẩm

Chrome headless mở chính file HTML để đo vùng chữ, kiểm tra tràn trang và xuất ảnh PNG. Sau vòng sửa bố cục, công cụ chạy lại trên bản cuối. Các ảnh dưới đây được lấy từ lần render này; ảnh trước sửa được giữ riêng để so sánh.

Kết quả: bộ 5 slide về code review

Năm trang lần lượt trình bày đề xuất pilot, cách đo KPI, phân công reviewer, ví dụ PR và điều kiện mở rộng. Ảnh slide 2 được đặt cùng bản trước sửa ở phần tiếp theo để dễ đối chiếu.

Trang mở đầu đưa các quyết định cần chốt lên trước. Người xem có thể nhận ra ngay phạm vi thử nghiệm, cách vận hành đề xuất và yêu cầu về đo lường.

Trang quy trình giữ cùng các cột chuẩn bị, kiểm tra, phân công và phản hồi. Cách trình bày này giúp đối chiếu các bước và vai trò reviewer. Nét đứt đánh dấu phần đề xuất, còn nội dung phân loại PR giải thích khi nào Tech Lead cần tham gia.

Trang tiếp theo đưa ra hai PR tự soạn để minh họa: thay đổi trạng thái danh sách rỗng và thay đổi phân quyền API. Cả hai dùng cùng cấu trúc để reviewer thấy ngữ cảnh và điểm cần tập trung. Phần kiểm thử nêu yêu cầu cần kiểm chứng, không phải kết quả test đã chạy.

Trang cuối thu lại các quyết định đã nêu ở đầu, bổ sung lịch pilot và tiêu chí đánh giá. Những ngưỡng chưa có dữ liệu vẫn để xx, nên tài liệu cho thấy rõ phần phải bổ sung trước khi phê duyệt triển khai.

AI đã sai ở đâu?

Lần render đầu có lỗi bố cục: nội dung cuối slide 2 đè lên chú thích, còn thân slide 4 lấn vùng chú thích. Báo cáo đo ghi mức lấn lần lượt là 39px và 11px. Project giữ lại HTML, ảnh và báo cáo của lần đầu để đối chiếu.

Theo nhật ký, phần nội dung ban đầu được đặt ở cùng một tọa độ dọc dù tiêu đề có chiều cao khác nhau. Vòng sửa chuyển điểm bắt đầu nội dung theo chiều cao tiêu đề, giữ khoảng cách 44px và điều chỉnh ngắt dòng ở các tiêu đề dài. Chữ không bị thu nhỏ dưới 18px để nhét nội dung.

Hạng mục	Bằng chứng ghi nhận
Sản phẩm	Năm trang HTML và năm ảnh PNG, mỗi slide 1920×1080.
Lần render đầu	Slide 2 chồng chữ với chú thích; thân slide 4 lấn vùng cuối trang.
Sau một vòng sửa	Bộ đo không còn phát hiện tràn trang hoặc chồng chữ trên năm slide.
Hoạt động	Không ghi nhận lỗi JavaScript; nút Tiếp chuyển đến slide 2.
Hai kích thước màn hình	Ở chiều rộng 1440px và 390px, tài liệu không tràn ngang. Trên điện thoại, slide thu nhỏ nên cần mở ảnh lớn để đọc chi tiết.

Cặp ảnh trước/sau cho thấy bước render là một phần cần thiết của quy trình. Đo vùng chữ giúp tìm lỗi bố cục, còn việc đọc lại bảng KPI giúp kiểm tra ý nghĩa của dữ liệu.

Tôi đánh giá phương pháp này thế nào?

Điểm hữu ích nhất là cấu trúc lập luận có thể xem xét trước khi slide được dựng. Bảng thông điệp cho thấy mỗi trang đóng góp gì vào đề xuất, còn blueprint giúp truy lại lý do chọn bố cục. Với tài liệu kỹ thuật, cách tổ chức này giúp người viết kiểm tra xem nội dung có phục vụ quyết định cần đưa ra hay không.

Về thao tác, HTML/SVG có lợi thế với người quen đọc và chỉnh mã: văn bản, vị trí và màu sắc nằm trong file, có thể lưu phiên bản cùng đầu vào. Người quen kéo thả trong PowerPoint sẽ cần làm quen với cách chỉnh này. Với tôi, phương pháp hữu ích cho việc tổ chức lập luận và bố cục, nhưng vẫn cần một vòng rà soát trước khi trình bày.

Về hiệu quả, nhật ký ghi 17 phút 12 giây từ lúc bắt đầu thực hiện đến báo cáo render cuối. Đây là thời gian trôi qua của tác nhân AI và công cụ, gồm cả chờ quyền thực thi; không đo thao tác tay hay bao gồm chuẩn bị trước phiên và viết blog.

Kết quả có thể đánh giá là một bộ slide hoàn chỉnh, bản thiết kế để đối chiếu và một vòng sửa có lưu bằng chứng. Để tính mức tiết kiệm thời gian, tôi cần thêm một lần làm thủ công với cùng yêu cầu làm đối chứng.

Tôi sẽ áp dụng vào công việc thế nào?

Tôi sẽ bắt đầu thử với một báo cáo sprint, sau đó mở rộng sang đề xuất kỹ thuật và chuẩn bị PR. Mỗi trường hợp đều cần đầu vào rõ ràng và một bước kiểm tra của người viết.

Báo cáo sprint: từ ghi chú công việc đến quyết định cần hỗ trợ

Tôi có thể gom trạng thái issue/PR, kết quả bàn giao và vướng mắc thành một brief ngắn. AI đề xuất các câu kết luận, sắp xếp phần đã hoàn thành, phần còn vướng và việc cần hỗ trợ; sau khi tôi đối chiếu trạng thái thực tế, AI mới tạo blueprint và slide HTML. Đầu ra cần giúp buổi báo cáo chốt được ưu tiên hoặc người hỗ trợ.

Để thử ở quy mô nhỏ, tôi sẽ chọn một báo cáo sprint, ghi riêng thời gian chuẩn bị dữ liệu, sửa nội dung và sửa bố cục. Khi cập nhật trạng thái issue, tôi cần kiểm tra lại các con số và quyết định trong blueprint trước khi xuất phiên bản mới.

Đề xuất kỹ thuật: làm rõ căn cứ lựa chọn phương án

Với một thay đổi kiến trúc, đầu vào có thể gồm yêu cầu, các phương án, ràng buộc và kết quả thử nghiệm đã có. AI hỗ trợ dựng bảng so sánh theo cùng tiêu chí, sau đó chuyển thành slide phục vụ thảo luận. Tôi kiểm tra lại giả định, chi phí và rủi ro; thông tin chưa xác minh phải được đánh dấu rõ trước khi đề nghị lựa chọn.

Chuẩn bị PR: dùng AI để soạn ngữ cảnh và checklist

Từ diff, yêu cầu và các bài test liên quan, AI có thể tạo bản nháp mô tả PR gồm lý do thay đổi, phạm vi ảnh hưởng và điểm cần reviewer chú ý. Hai thẻ PR trong bộ slide là ví dụ về cấu trúc có thể tái sử dụng. Tôi cần kiểm tra nội dung có khớp diff hay không, bổ sung trường hợp biên và lấy kết quả lint/test từ lần chạy thực tế.

Với ghi chú họp hoặc transcript, tôi có thể thử nhánh quy trình đang cấu hình trong project: trích xuất dữ kiện, quyết định và đầu việc, tạo blueprint rồi dừng để người dùng kiểm tra.

Tôi sẽ theo dõi thời gian đến bản có thể dùng, số lỗi phải sửa và độ rõ ràng của quyết định cần đưa ra. Các lần thử tiếp theo sẽ giúp đánh giá mức cải thiện trong công việc thực tế.

Tham khảo phương pháp: bài viết của Uchita về tạo slide bằng AI trên note. Ảnh trong bài được lấy từ bộ HTML code review đã render trong project. Thời gian và lỗi trình bày được đối chiếu với nhật ký cùng báo cáo kiểm tra trước/sau của lần thực hành ngày 09/09/2026.

Kết luận

Với tôi, giá trị lớn nhất của Plan B là giúp người làm slide tập trung vào thông điệp, logic và việc kiểm tra bản render. AI hỗ trợ dựng bố cục, còn tôi chịu trách nhiệm về nội dung và chất lượng bản cuối. Tôi sẽ tiếp tục thử cách làm này với báo cáo sprint, đề xuất kỹ thuật và chuẩn bị PR để xem hiệu quả có lặp lại trong công việc hằng ngày hay không.