Sổ tay BuildMidas: bản đồ của nền tảng

Hãy để tôi dẫn bạn qua một tài khoản thực tế, từ đầu đến cuối, thay vì mô tả từng mục trong thanh bên. Giả sử đó là một freelancer, tuần đầu tiên trên nền tảng, đang xây một ứng dụng theo dõi thói quen cho một khách hàng nhỏ. Đây là những gì xảy ra với bản build đó khi nó đi qua bảng điều khiển, theo đúng thứ tự thực tế — và nơi mỗi điểm dừng hoặc giúp ích hoặc lãng phí năm phút.

Lời nhắc

Họ mở AI Builder và gõ đại loại như "làm cho tôi một app theo dõi thói quen." Đó là một câu mở đầu hợp lý nhưng lại là một prompt cuối cùng tồi. Thứ trả về không phải là code — mà là một kế hoạch, viết bằng ngôn ngữ thông thường, và nếu bạn dừng đọc ở mức "trông ổn đấy" rồi bấm phê duyệt, bạn sẽ nhận được thứ gì đó phản ánh đúng nghĩa đen của cụm từ "app theo dõi thói quen" nhưng lại chung chung ở mọi khía cạnh quan trọng. Khách hàng của freelancer này muốn không có tính năng xã hội, chỉ lưu trữ cục bộ, chế độ tối mặc định. Không điều nào trong số đó có trong prompt đầu tiên. Thay vào đó, chúng được đưa vào kế hoạch, dưới dạng ba chỉnh sửa trước khi phê duyệt: xóa tính năng "chia sẻ chuỗi ngày liên tiếp" mà kế hoạch tự nghĩ ra, đổi dòng về lưu trữ, chuyển giao diện mặc định. Ba mươi giây chỉnh sửa. Bản build ra đời từ đó khớp với yêu cầu của khách hàng thay vì chỉ khớp với cụm từ "app theo dõi thói quen."

Bước lập kế hoạch mà mọi người thường bỏ qua

Tôi đã chứng kiến đúng khoảnh khắc này đi sai hướng với nhiều người dùng khác — phê duyệt kế hoạch đầu tiên mà không đọc, đi sâu đến vòng lặp thứ ba, rồi bắt đầu phải giải thích lại các ràng buộc lẽ ra nên được thiết lập ngay từ bước lập kế hoạch. Bước lập kế hoạch tồn tại chính là để bạn không rơi vào tình huống đó. Nó gần như không tốn kém gì, và đó là điểm duy nhất trong vòng lặp mà bạn đang thương lượng với agent bằng ngôn ngữ của mình thay vì gỡ lỗi kết quả của nó bằng code.

Bản build thực sự sẽ nằm ở đâu

Sau khi tạo xong, app theo dõi thói quen sẽ xuất hiện dưới dạng một thẻ trong My Builds — trang thư viện, có thể lọc theo loại, và là trang mà freelancer này sẽ mở nhiều hơn bất kỳ trang nào khác vào tuần thứ ba khi đã có năm hoặc sáu bản build chồng lên nhau. Nó sẽ không xuất hiện trong Showcase; trang đó được tuyển chọn thủ công, không tự động, và việc một bản build của khách hàng nằm ở đó mà không được công khai là điều đúng đắn theo mặc định. Nó cũng sẽ không xuất hiện trong Templates trừ khi freelancer nghĩ đến việc lưu nó thành một mẫu — thực ra rất đáng làm ở đây, vì bộ khung app theo dõi thói quen chính là kiểu thứ mà freelancer sẽ xây lại cho khách hàng tiếp theo với thương hiệu khác. Hầu hết mọi người không khám phá ra "lưu thành mẫu" cho đến bản build thứ sáu, và ước gì đã làm điều đó từ bản build đầu tiên.

Xuất bản, hoặc một thứ gì đó nặng đô hơn

Giờ đến câu hỏi về phân phối. Có ba lựa chọn thực sự, không phải một lựa chọn mang ba cái tên. Published cung cấp một tên miền phụ miễn phí, hoạt động trong vài giây, không cần thiết lập gì — lựa chọn đúng đắn khi khách hàng vẫn đang xem xét và có thể yêu cầu thiết kế lại. Domain Management dành cho khi tên miền riêng của khách hàng đã sẵn sàng để trỏ vào, và bước này còn có công dụng kép: kết nối tên miền ở đây không chỉ là thay đổi URL, mà còn là điều giúp các trang phân tích ở phía dưới thanh bên có thứ để gắn vào. Deploy, trong phần cài đặt, là con đường SFTP dành cho khi khách hàng khăng khăng muốn bản build chạy trên hạ tầng do chính họ kiểm soát — cần thiết lập nhiều hơn, và freelancer không còn chịu trách nhiệm gì về việc duy trì hoạt động nữa, đây là một sự đánh đổi thực sự đáng được nói rõ thay vì phát hiện ra một cách tình cờ.

Với bản build này, hãy chọn Published trước. Việc chuyển từ tên miền phụ sang tên miền riêng sau này chỉ là chuyện nhỏ. Việc hoàn tác một lần triển khai tên miền riêng trên một dự án của khách hàng bị hủy thì tốn công dọn dẹp hơn nhiều so với giá trị nó mang lại — và trên thực tế, freelancer này đã từng bị vấp phải chính điều đó ở một dự án trước, đó chính là lý do cho thói quen "mặc định chọn Published."

Đường vòng qua kho ứng dụng

Vị khách hàng cụ thể này còn muốn có một danh sách trên kho ứng dụng, vì vậy bản build sẽ đi qua Shipped thay vì dừng lại ở Published — một trang tồn tại vì việc xét duyệt của các kho ứng dụng mang tính bất đồng bộ theo cách mà triển khai web không hề có. Nộp lên một kho thì nó nằm chờ hai ngày; nộp lên kho khác thì được duyệt trong hai mươi phút. Shipped là nơi bạn theo dõi tất cả điều đó mà không cần mở năm tab trình duyệt cho năm bảng điều khiển kho khác nhau, mỗi cái có đăng nhập riêng và từ vựng trạng thái riêng.

Trang trống mà chẳng ai cảnh báo trước

Một tuần sau khi tên miền được kết nối, freelancer mở Search Performance để kiểm tra. Trống trơn. Thậm chí trông hơi buồn — không biểu đồ, không con số, chỉ có lời nhắc kết nối tài khoản. Đó không phải lỗi, mà là sự trung thực: chưa có dữ liệu nào cả, vì Search Performance, Google Analytics, và Store Analytics đều dựa vào kết nối tài khoản Google trong phần cài đặt, và không cái nào tự động lấy dữ liệu về sau. Việc đồng bộ chỉ chạy kể từ thời điểm bạn kết nối, chỉ tính từ đó trở đi. Kết nối tên miền ngay ngày đầu thì đến tuần thứ hai bạn đã có một tuần lịch sử dữ liệu; kết nối vào ngày thứ mười vì quên mất, thì bạn bắt đầu từ con số không vào chính ngày thứ mười đó. Freelancer đã kết nối tên miền nhưng chưa kết nối tài khoản Google — hai bước riêng biệt trông như thể chỉ là một.

Phần thực sự tốn kém ở đây không phải là biểu đồ bị thiếu. Mà là các agent tối ưu hóa đọc từ chính nguồn dữ liệu này, và một agent được yêu cầu cải thiện thứ hạng của một trang mà không có lịch sử Search Performance nào phía sau sẽ phải làm việc dựa trên các phương pháp hay nhất chung chung thay vì dựa trên số liệu thực tế của trang web này. Việc bỏ qua kết nối không chỉ để lại một trang bảng điều khiển trống — nó còn giới hạn những gì các agent có thể làm được.

Bản brief xuất hiện mà không cần yêu cầu

Hai tuần sau, một thẻ xuất hiện trong Discovery: một bản brief cơ hội chỉ ra lỗ hổng nội dung trên site của khách hàng, kèm theo nút Build-this. Thực sự hữu ích khi nó chạm đúng vào thứ bạn vốn sẽ hành động. Nhưng Discovery thiên về số lượng hơn độ chính xác theo thiết kế — nhiều brief hơn số người sẽ hành động — nên tư thế đúng là một hộp thư gợi ý, không phải hàng đợi cần dọn sạch. Freelancer lướt qua nó vài ngày một lần và bỏ qua hầu hết, đó chính là cách dùng dự kiến, không phải thất bại trong việc theo kịp.

Những cài đặt lẽ ra nên làm từ ngày đầu

Đến lúc này, freelancer đã chạm vào bốn trang cài đặt mà không hề chủ động mở menu cài đặt — mỗi trang được phát hiện vì thứ gì khác bị trống.

Google Accounts là thứ đáng thiết lập trước. Đây là một điểm kết nối duy nhất đứng sau ba giao diện dashboard riêng biệt, và việc phát hiện ra điều đó theo cách khó khăn — ba trang trống khác nhau, ba khoảnh khắc "ồ, tôi cần kết nối gì đó" — chính là loại trở ngại mà một lượt thiết lập 5 phút vào ngày đầu có thể tránh được.

Hai thứ vốn đã luôn ở đó

Nút Ask-AI nổi luôn hiện diện trên mọi trang này suốt thời gian qua, và nó không phải là một bot FAQ thu hẹp — nó có thể kết nối một tài khoản, khởi động một build, hoặc giải thích vì sao một trang đang trống, thay mặt bạn. Khách hàng của freelancer, không nói tiếng Anh, cần toàn bộ giao diện bằng ngôn ngữ khác cho một buổi review call; biểu tượng địa cầu trên thanh nav chuyển đổi cả hai mươi ngôn ngữ, ngay giữa phiên làm việc, mà không làm mất build đang tiến hành. Cả hai điều này không cần phải được phát hiện qua thử-sai như mọi thứ khác trong bài hướng dẫn này. Chúng chỉ đơn giản là ở đó.

Đó là bản tóm tắt trung thực về hai tuần đầu của toàn bộ tài khoản này — không phải "đọc tài liệu rồi build", mà ngược lại. My Builds chỉ là một khái niệm trừu tượng cho đến khi có một thẻ trong đó. Search Performance là trạng thái trống cho đến khi một domain cung cấp dữ liệu cho nó. Đọc sơ đồ mặt bằng trước lần build đầu tiên là nền tảng tốt, nhưng sơ đồ mặt bằng chỉ có ý nghĩa khi có một habit tracker thật sự nằm đâu đó trong đó.