Dùng mẫu đặc tả một trang để biến ý tưởng mơ hồ thành các prompt rõ ràng cho Planning Mode, bao gồm người dùng, việc cần hoàn thành, thực thể dữ liệu và các tình huống biên.
Ý tưởng mơ hồ thì hợp để mơ mộng. Để xây dựng thì không đủ rõ ràng.
Khi bạn yêu cầu một AI builder “một ứng dụng để theo dõi thói quen” mà không nói rõ hơn, AI phải đoán ý bạn. Những suy đoán đó thay đổi theo từng prompt, nên ứng dụng cũng thay đổi. Kết quả là màn hình không khớp nhau, dữ liệu bị đổi tên giữa chừng, và các tính năng hiện rồi biến mất rồi xuất hiện lại dưới dạng khác.
Sự không nhất quán thường xuất hiện ở vài chỗ:
“Planning Mode” là một khoảng dừng đơn giản trước khi xây dựng. Bạn viết ra các quyết định mà lẽ ra AI phải tự nghĩ ra. Mục tiêu là tính nhất quán: một tập lựa chọn để UI, backend và cơ sở dữ liệu cùng tuân theo.
Mục tiêu không phải hoàn hảo. Là một bản xây được mà bạn có thể lặp lại mà không phải vá hàng loạt giả định. Nếu sau này đổi ý, bạn cập nhật một đặc tả nhỏ và xây lại theo cùng logic.
Đó là lý do mẫu đặc tả một trang quan trọng. Nó không phải PRD dài, cũng không phải tuần lễ sơ đồ. Là một trang trả lời bốn thứ: ai là người dùng, họ muốn đạt được gì, dữ liệu nào tồn tại (bằng ngôn ngữ bình dân), và những tình huống biên hoặc không-mục-tiêu nào giữ cho phiên bản đầu không bị nổ tung.
Ví dụ: “Một ứng dụng đặt lịch” trở nên rõ rệt hơn khi bạn quyết định nó dành cho chủ salon đơn lẻ hay một marketplace, và khách hàng có thể dời lịch, huỷ hay vắng mặt hay không.
Mẫu đặc tả một trang là một ghi chú ngắn biến ý tưởng mơ hồ thành hướng dẫn rõ ràng. Bạn không “thiết kế toàn bộ sản phẩm.” Bạn cho AI builder đủ cấu trúc để chọn cùng một cách mỗi lần.
Trang gồm bốn khối. Nếu không vừa một trang, có lẽ bạn có quá nhiều tính năng cho lần xây đầu.
Một trang buộc bạn chọn giới hạn có ích. Nó ép bạn chọn người dùng chính, định nghĩa luồng nhỏ nhất thành công, và tránh hứa hẹn mơ hồ như “hỗ trợ tất cả.” Những giới hạn đó chính là thứ giữ cho ứng dụng do AI xây không thay đổi ý giữa các màn hình.
Chi tiết “đủ tốt” trông giống các câu đơn giản, có thể kiểm thử. Nếu ai đó đọc và hỏi “Làm sao biết điều này hoạt động?” thì bạn đang ở mức đúng.
Mục tiêu nhanh để nhắm tới:
Giữ ngôn ngữ đơn giản. Viết câu bạn có thể dán thẳng vào prompt, như “A manager can approve or reject a request, and the requester gets a status update.”
Đặt hẹn giờ 20 phút và nhắm đến “đủ rõ để xây,” không phải “hoàn hảo.” Mục tiêu là loại bỏ suy đoán để AI builder chọn cùng một cách mỗi lần.
Bắt đầu bằng một câu đơn trả lời: dành cho ai và họ nhận được kết quả gì?
Ví dụ: “Một ứng dụng di động cho chủ chó để theo dõi các lần đi dạo và lịch khám thú y ở cùng một nơi.”
Nếu không thể nói trong một câu, có lẽ ý tưởng là hai ứng dụng.
Tiếp theo, đặt tên 1–3 loại người dùng như người thực, không phải vai trò trừu tượng. “Owner,” “Vet,” và “Family member” rõ hơn “User A.” Với mỗi loại, thêm một dòng ngắn về điều họ quan tâm nhất.
Rồi viết 3–7 jobs-to-be-done theo định dạng: “When [tình huống], I want to [hành động], so I can [kết quả].” Giữ sao cho có thể kiểm thử. “When I finish a walk, I want to log distance and notes, so I can spot patterns” rõ hơn “track health.”
Bây giờ định nghĩa các entities và trường chính mà không nói chuyện cơ sở dữ liệu. Nghĩ “những thứ ứng dụng nhớ.” Với app chó ví dụ: Dog (name, age), Walk (date, duration, notes), Visit (date, clinic, cost). Nếu một trường không dùng trên màn hình hay job, bỏ nó.
Kết thúc bằng hai khối ngắn: edge cases và non-goals. Edge cases gây phiền nhưng phổ biến (“không có internet,” “hai con chó cùng tên”). Non-goals là những thứ bạn không làm bây giờ (“không thanh toán,” “không feed xã hội”).
Cuối cùng, chuyển mỗi khối thành prompt mà builder có thể theo. Giữ cấu trúc nhất quán (mục tiêu, người dùng, jobs, entities, edge cases) giúp hệ thống sinh màn hình, dữ liệu và luồng khớp nhau.
Nếu đặc tả của bạn viết “cho tất cả mọi người,” AI builder sẽ phải đoán bắt đầu từ đâu. Trong mẫu một trang, định nghĩa người dùng theo mục đích (họ đến để làm gì), không phải theo nhân khẩu học. Mục đích dẫn đến lựa chọn rõ ràng về màn hình, dữ liệu và quyền truy cập.
Đặt tên 2–4 loại người dùng, mỗi loại một mục tiêu chính. Ví dụ tốt: “Customer đặt hàng,” “Team member thực hiện đơn,” “Manager xem hiệu suất.” Ví dụ mơ hồ: “18–35,” “busy professionals,” hoặc “admins” (trừ khi bạn nói họ quản gì).
Dùng cùng cấu trúc câu mỗi lần: “When..., I want to..., so I can...”. Điều này giữ app tập trung vào kết quả và cho AI builder yêu cầu ổn định, có thể kiểm thử.
Dưới đây là ví dụ JTBD thực tế với “xong” được định nghĩa rõ:
Tiêu chí thành công quan trọng vì nó loại bỏ sự mơ hồ “trông ổn.” Nó nói cho builder biết UI phải cho phép gì và backend phải lưu gì.
Không cần viết kế hoạch bảo mật đầy đủ. Chỉ nêu ai làm được gì, bằng ngôn ngữ đơn giản.
Ví dụ: “Members can create and edit their own items. Managers can edit any item and change status. Owners can manage users and billing.”
Nếu bạn dùng bước lập kế hoạch trong công cụ như Koder.ai, các loại người dùng này, dòng JTBD và phân quyền trở thành đầu vào đáng tin cậy. Chúng cũng ngăn AI tạo vai trò thừa hoặc trộn trách nhiệm giữa các màn hình.
Entities là những “điều” ứng dụng theo dõi. Nếu bạn đặt tên rõ, AI builder có thể tạo màn hình, biểu mẫu và cơ sở dữ liệu khớp nhau. Điều này ngăn trường không khớp và tính năng thừa.
Bắt đầu bằng cách liệt kê các danh từ cốt lõi. Nếu app là “quản lý dự án,” danh từ có thể là Project, Task, Comment. Nếu là “đặt lịch cắt tóc,” có thể là Booking, Service, Customer, Staff.
Vì mỗi entity, viết trường bằng lời thông thường, không phải thuật ngữ cơ sở dữ liệu. Tưởng tượng người sẽ gõ gì vào form.
Nếu không thể giải thích một trường trong một câu, có lẽ quá chi tiết cho phiên bản đầu.
Mô tả kết nối các entity bằng câu đơn giản:
“One user can have many projects.” “Each task belongs to one project.” “A comment belongs to a task and has one author.”
Điều này cung cấp đủ cấu trúc để builder sinh danh sách, trang chi tiết và bộ lọc nhất quán.
Thêm vài quy tắc dữ liệu để tránh hành vi lộn xộn:
Cuối cùng, cắt scope bằng cách nêu rõ sẽ không lưu gì ở lần đầu. Ví dụ: “No file attachments in v1,” hoặc “Don’t track staff schedules yet, only bookings.” Những loại loại trừ này quan trọng vì chúng ngăn app lớn lên theo hướng sai.
Mẫu một trang hoạt động tốt nhất khi phiên bản đầu có tập màn hình nhỏ, ổn định. Nếu bạn cố thiết kế mọi màn hình có thể cần trong tương lai, AI builder sẽ tiếp tục đoán, và UI sẽ trôi dạt giữa các lần xây.
Bắt đầu bằng cách đặt tên các màn hình tối thiểu để hoàn thành công việc chính. Với hầu hết MVP, 3–6 màn hình là đủ:
Rồi viết happy path như một câu chuyện ngắn từ đầu đến cuối.
Ví dụ: “User signs in, lands on the list, searches, opens an item, edits one field, saves, and returns to the list.”
Với mỗi màn hình, ghi các hành động chính bằng lời thường. Tránh màn hình “làm mọi thứ.” Chọn 2–4 hành động quan trọng nhất, như tạo, sửa, tìm kiếm, xuất, hoặc lưu trữ.
Cũng quyết định điều gì phải nhanh và điều gì có thể chấp nhận được. “Nhanh” thường là danh sách mở nhanh, tìm kiếm phản hồi tức thì, và lưu có cảm giác tức thì. “Chấp nhận được” có thể là xuất dữ liệu mất vài giây, phân tích cơ bản, hoặc phần cài đặt sơ khai.
Cuối cùng, ghi quyền và truy cập một dòng cho mỗi vai trò:
Điều này giữ màn hình dễ đoán, ngăn bất ngờ về phân quyền, và giảm viết lại sau này.
Hầu hết viết lại xảy ra vì một lý do: app chạy tốt trên happy path, rồi vỡ khi đời thực xuất hiện.
Một mẫu một trang tốt dành chỗ cho edge cases và non-goals; phần nhỏ đó tiết kiệm hàng giờ.
Bắt đầu với mỗi job-to-be-done và hỏi: điều gì có thể hỏng? Giữ bằng lời thường, không kỹ thuật. Bạn đang loại bỏ mơ hồ để builder quyết định cùng một cách mỗi lần.
Các trường hợp biên phổ biến nên ghi:
Rồi quyết định phản ứng. Cụ thể: “Chặn hành động và hiển thị thông báo rõ ràng,” “Cho lưu nháp,” hoặc “Thử lại một lần, rồi hiện nút thử lại.” Những quy tắc này dịch thẳng vào các prompt nhất quán.
Thêm mong đợi về quyền riêng tư và an toàn trong 1–2 dòng. Ví dụ: “Thu thập dữ liệu tối thiểu cần thiết,” “Người dùng có thể xóa tài khoản và toàn bộ dữ liệu cá nhân,” và “Ẩn mục riêng tư mặc định.” Nếu app có nội dung do người dùng tạo, ghi xử lý báo cáo và spam, dù đơn giản cho v1.
Cuối cùng, viết non-goals để ngăn scope creep. Chọn những tính năng lớn cám dỗ bạn sẽ không làm.
Ví dụ non-goals rõ ràng:
Ví dụ nhanh: nếu job là “Create an event,” định nghĩa chuyện xảy ra khi ngày ở quá khứ, tiêu đề trống, hoặc sự kiện cùng tên tạo hai lần. Rõ ràng như vậy ngăn lần xây tiếp theo.
Cách nhanh nhất để có kết quả nhất quán là biến mỗi khối của mẫu thành một prompt ngắn, trực tiếp. Nghĩ như đưa builder một bộ thẻ để theo thứ tự, thay vì một yêu cầu lớn mơ hồ.
Chuyển mỗi khối (Users, Jobs, Entities, Screens, Edge cases, Non-goals) thành một hướng dẫn với danh từ và động từ rõ ràng. Tránh nhận định như “làm gọn” trừ khi bạn cũng nói “làm gọn” nghĩa là gì.
Dùng chu kỳ hai bước: xây rồi kiểm tra so với spec.
Thêm định nghĩa hoàn thành ngắn để builder biết khi nào dừng. Giữ nó đo lường được:
Chỉ thêm ràng buộc khi thực sự cần: thiết bị yêu cầu (mobile-first), xác thực bắt buộc (admin-only actions), hoặc stack bắt buộc (React frontend, Go backend, PostgreSQL) nếu nền tảng của bạn mong vậy.
Khi muốn chỉnh sửa, tham chiếu đến khối spec, không phải mã.
Ví dụ: “Update the Entities block: add ‘Subscription’ with fields X and Y. Then regenerate only the affected APIs and screens, and re-run the validation step.”
Cách này giữ kế hoạch ổn định trong khi cho phép lặp an toàn.
Giả sử bạn muốn một bộ theo dõi nhắc lịch đơn giản cho salon nhỏ. Mục tiêu không phải hệ thống đặt lịch đầy đủ. Là nơi nhẹ để lưu cuộc hẹn và gửi nhắc nhở.
Đây là mẫu một trang khi đã điền.
APP: Appointment Reminder Tracker
GOAL: Track appointments and send reminders. No payments, no online booking.
USERS
1) Owner/Staff: creates and manages appointments, wants fewer no-shows.
2) Client: receives reminders, wants an easy way to confirm.
JOBS TO BE DONE (JTBD)
1) As staff, I add an appointment in under 30 seconds.
2) As staff, I see today's schedule in time order.
3) As staff, I mark a client as confirmed or no-show.
4) As staff, I resend a reminder when asked.
5) As a client, I confirm from a message without creating an account.
ENTITIES (DATA)
- Client: id, name, phone, email (optional), notes
- Appointment: id, client_id, service, start_time, duration_min, status (scheduled/confirmed/canceled/no_show)
- Reminder: id, appointment_id, channel (sms/email), send_at, sent_at, result (ok/failed)
- StaffUser: id, name, role (owner/staff)
Relationships: Client 1-to-many Appointment. Appointment 1-to-many Reminder.
EDGE CASES (WHAT BREAKS NAIVE BUILDS)
1) Duplicate client (same phone, different name)
2) Overlapping appointments for the same staff
3) Time zone changes (travel, daylight saving)
4) Client has no email, SMS only
5) Reminder send fails, needs retry and visible status
6) Appointment edited after reminder scheduled
7) Client cancels after confirmation
8) Same-day appointment created 10 minutes before start
9) Phone number format varies (+1, spaces, dashes)
10) Deleting a client with future appointments
Bây giờ chuyển nó thành một gói prompt bạn có thể dán vào Planning Mode để xây app. Giữ nghiêm để builder chọn cùng một cách mỗi lần.
PLANNING MODE PROMPT BUNDLE
1) Build an MVP web app with these entities and relationships exactly as written.
2) Required screens: Login (StaffUser), Today Schedule, Client List, Client Detail, Appointment Create/Edit.
3) Required flows: create client, create appointment for a client, confirm/cancel/no-show, schedule reminders, resend reminder.
4) Constraints: no payments, no public booking page, no client accounts.
5) Edge-case handling: implement validation and UI feedback for all 10 edge cases listed.
6) Output: database schema, API endpoints, and UI behavior notes per screen.
Kết quả lộn xộn thường bắt đầu từ một spec mơ hồ và danh sách mong muốn tính năng. AI builder làm đúng những gì bạn yêu cầu, nhưng không đọc được suy nghĩ. Những khoảng trống nhỏ biến thành khác biệt lớn qua các màn hình và luồng.
Những cái bẫy phá vỡ tính nhất quán thường xuyên nhất, và mẫu một trang khắc phục:
Nếu bạn dùng Planning Mode trong Koder.ai, những cơ bản này càng quan trọng vì kế hoạch trở thành nguồn cho các prompt lặp lại. Jobs rõ ràng, mô hình dữ liệu nhỏ, phân quyền cụ thể và tiêu chí kiểm thử giữ cho mỗi màn hình mới khớp với phần còn lại.
Trước khi xây, rà soát nhanh mẫu một trang của bạn. Mục tiêu là lấp các lỗ buộc AI không phải đoán. Những đoán đó thành viết lại.
Kiểm tra độ hoàn chỉnh nhanh:
Nếu muốn một ý tưởng chấm điểm đơn giản, cho từng phần điểm 0–2:
Mục tiêu ít nhất 7/10 trước khi sinh bất cứ thứ gì. Nếu Entities hoặc Edge cases dưới 2, sửa chúng trước. Chúng gây nhiều sự thay đổi nhất.
Sau lần xây đầu, so sánh app với mỗi job-to-be-done và đánh dấu sai lệch. Lưu một snapshot trước mỗi thay đổi. Nếu một lần lặp làm mọi thứ tệ hơn, rollback và thử sửa nhỏ hơn.
Nếu bạn dùng Koder.ai (koder.ai), Planning Mode là nơi thực tế để giữ mẫu một trang như “nguồn chân lý” và chỉ regenerate phần thay đổi thay vì viết lại mọi thứ bằng tay.
Giữ mẫu cập nhật khi tiến triển. Khi bạn chấp nhận thay đổi trong app, cập nhật spec cùng ngày. Khi bạn từ chối thay đổi, ghi lý do, để prompt lần sau vẫn nhất quán.
Planning Mode là giai đoạn tạm dừng ngắn để bạn ghi lại các quyết định chính trước khi sinh ra màn hình và mã. Mục tiêu là tính nhất quán: cùng một tập người dùng, luồng và tên dữ liệu giữa UI, backend và cơ sở dữ liệu, để bạn không phải xây lại vì các giả định mới xuất hiện trong mỗi lần tạo lại.
Bắt đầu với một câu mục tiêu ngắn, sau đó điền bốn khối sau:
Nếu không vừa một trang, hãy cắt bớt tính năng cho phiên bản v1.
Giữ cho thực tế và dựa trên mục đích. Ghi vài loại người dùng và họ cố gắng đạt được điều gì. Ví dụ: “Owner/Staff tạo cuộc hẹn” rõ ràng hơn “Admin”. Nếu bạn không thể giải thích vai trò trong một dòng, có lẽ nó mơ hồ quá mức.
Dùng mẫu câu chặt chẽ để mỗi job có thể kiểm thử được:
Rồi thêm định nghĩa hoàn thành (phải lưu/cập nhật/hiển thị gì). Điều này ngăn builder tự động tạo bước phụ hoặc màn hình ngẫu nhiên.
Liệt kê những “điều ứng dụng ghi nhớ” bằng ngôn ngữ thông thường, rồi cho mỗi cái 3–7 trường bạn thực sự dùng trên màn hình.
Ví dụ: Appointment: start time, duration, status, service, client. Nếu một trường không được một job hay màn hình sử dụng, để nó ra khỏi v1.
Viết mối quan hệ bằng các câu đơn giản:
Thêm vài quy tắc cơ bản (trường bắt buộc, trường phải duy nhất, giá trị mặc định). Thường vậy là đủ để giữ cho danh sách, biểu mẫu và bộ lọc nhất quán.
Một khởi điểm tốt là 3–6 màn hình hoàn thành công việc chính end-to-end:
Viết một “happy path” (bắt đầu → hành động → lưu → xác nhận) để luồng không bị lệch.
Ghi 5–10 tình huống biên khả năng xảy ra nhiều nhất:
Với mỗi trường hợp, nêu rõ phản hồi mong đợi (chặn + thông báo, cho lưu nháp, thử lại, v.v.).
Chuyển mỗi khối thành một chỉ dẫn ngắn mà builder có thể thực hiện và kiểm tra.
Chuỗi đơn giản:
Đừng dựa vào một prompt khổng lồ dễ bị hiểu sai.
Cập nhật spec trước, rồi chỉ sinh lại phần bị ảnh hưởng.
Ví dụ: “Thêm entity Subscription với trường X/Y; cập nhật các API và màn hình liên quan; chạy lại bước kiểm tra.” Giữ spec làm nguồn chân lý để tránh các chỉnh sửa rải rác, không nhất quán.