11 thg 12, 2025·8 phút
Đừng thay đổi pattern prompt — lặp nhỏ an toàn
Học mẫu prompt “không thay đổi” để cập nhật một điểm nhỏ trong khi đóng băng các luồng UI, quy tắc nghiệp vụ và hành vi quan trọng, tránh drift ngoài ý muốn.
Học mẫu prompt “không thay đổi” để cập nhật một điểm nhỏ trong khi đóng băng các luồng UI, quy tắc nghiệp vụ và hành vi quan trọng, tránh drift ngoài ý muốn.
Một thay đổi “nhỏ” hiếm khi thật sự nhỏ. Bạn yêu cầu chỉnh một nhãn nút, và bỗng nhiên bố cục trang dịch chuyển, một form không còn xác thực, hoặc một bước thanh toán hoạt động khác đi. Ứng dụng là hệ thống liên kết. UI, logic, dữ liệu và tích hợp đều dựa vào nhau.
Nguyên nhân thường gặp là ranh giới không rõ ràng. Nếu một yêu cầu viết “làm cho đăng ký đơn giản hơn,” người thực hiện (con người hay AI) phải đoán “đơn giản hơn” là gì. Việc đoán dẫn đến chỉnh sửa thêm: xóa trường, thay đổi bước, chỉnh copy, hoặc viết lại xác thực. Một nguyên nhân khác là phụ thuộc ẩn — một thay đổi UI nhỏ có thể tái sử dụng một component xuất hiện ở năm màn khác.
Một lặp an toàn nghĩa là bạn nhận được đúng cải thiện mong muốn trong khi mọi thứ còn lại giữ nguyên về mặt hiệu năng hành vi. Với đội không chuyên kỹ thuật, điều đó có nghĩa workflow vẫn cho cảm nhận giống cũ với người dùng, kịch bản hỗ trợ vẫn khớp sản phẩm, và báo cáo vẫn có ý nghĩa. Với đội kỹ thuật, nó nghĩa là không có thay đổi bất ngờ về routes, hình dạng dữ liệu, hợp đồng API, hay hành vi các trường hợp góc.
Để làm được điều đó, bạn phải đóng băng những gì không được phép thay đổi. Thực tế, thường bao gồm các luồng quan trọng (các bước chính xác người dùng đi qua), chi tiết UI/UX (bố cục, khoảng cách, hành vi tương tác), quy tắc nghiệp vụ (giá, quyền, xác thực), hành vi dữ liệu (lưu gì và khi nào), và tích hợp (sự kiện analytics, email, thanh toán, API bên ngoài).
Mẫu prompt “không thay đổi” giảm rủi ro bằng cách loại bỏ đoán mò và giữ phạm vi thay đổi. Không phải là bảo đảm tuyệt đối. Vẫn có drift nếu hành vi gốc được định nghĩa kém, nếu thay đổi chạm vào component dùng chung, hoặc nếu bạn không kiểm tra kết quả. Mục tiêu là ít bất ngờ hơn và phê duyệt nhanh hơn.
Mẫu “không thay đổi” là cách đơn giản để yêu cầu một cập nhật cụ thể trong khi rõ ràng khóa mọi thứ còn lại. Bạn nêu duy nhất thay đổi muốn làm, rồi liệt kê ngắn những phần phải giữ nguyên sau cập nhật.
Điều này quan trọng vì các mô hình thường cố gắng hữu ích bằng cách refactor, đổi tên, tổ chức lại file, hoặc “dọn dẹp” logic khi chúng sửa mã. Dù đầu ra vẫn chạy, những thay đổi phụ này có thể đưa lỗi, đổi hành vi, hoặc làm việc review khó hơn.
So sánh hai yêu cầu:
“Make the settings page better.” (Làm trang cài đặt tốt hơn.) Yêu cầu này mời gọi thay đổi thiết kế, copy mới, dịch chuyển bố cục và chỉnh logic.
“Change only the label text from ‘Phone’ to ‘Mobile phone’. Do not change layout, validation, or the save behavior.” (Chỉ thay nhãn từ 'Phone' sang 'Mobile phone'. Không thay bố cục, xác thực, hay hành vi lưu.) Đây hẹp hơn, có thể kiểm tra và an toàn hơn.
Một danh sách đóng băng tốt thường bao phủ ba mảng:
Khi dùng mẫu này trong công cụ build theo chat như Koder.ai, các vòng lặp thường nhanh hơn vì mô hình tập trung vào một chỉnh sửa thay vì thực hiện các “cải tiến” rộng mà bạn không yêu cầu.
Mẫu này hiệu quả nhất khi yêu cầu của bạn đọc như một hợp đồng nhỏ: một mục tiêu rõ ràng, một danh sách đóng băng, và vài kiểm tra để xác nhận kết quả.
Sao chép mẫu này và điền vào ngoặc. Giữ ngắn nhưng cụ thể.
Goal (one sentence):
- Change: [describe the one small change you want]
Context (1-3 sentences):
- Current behavior: [what happens today]
- Desired behavior: [what should happen after]
DO NOT CHANGE (must remain identical):
- Critical flows: [e.g., sign up -\u003e checkout -\u003e receipt stays the same]
- UI/UX that must not move: [e.g., button location, labels, navigation order]
- Business rules: [e.g., pricing, permissions, validation rules]
- Data behavior: [e.g., database schema, stored fields, migration rules]
Constraints (limit drift):
- Scope: [only this screen / only this endpoint / only this component]
- Files/modules (if known): [list a couple, or say “only touch what’s necessary”]
- No refactors: do not rename, reorganize folders, or change formatting beyond the touched lines
Acceptance checks (how I will verify):
1) [a simple before/after check]
2) [a user path that must still work]
3) [a rule that must still hold]
Output requested:
- Provide a brief diff-style summary: what changed, where, and why
- Call out any risk or unclear requirement before implementing
Để ví dụ cụ thể: nếu bạn muốn đổi màu nút checkout, mục tiêu là “Update the primary checkout button color to #1A73E8.” Các mục DO NOT CHANGE nên đóng băng toàn bộ flow checkout, văn bản nút và phép tính giá.
Nếu bạn dùng Koder.ai, định dạng này cũng giúp review nhanh hơn vì bạn có thể so sánh acceptance checks với preview và bản tóm tắt thay đổi trước khi phê duyệt.
Khi bạn yêu cầu thay đổi nhỏ, đừng chỉ nói “đừng phá gì.” Hãy nêu chính xác hành trình người dùng phải giữ nguyên, từ cú nhấp đầu tiên đến kết quả cuối cùng. Bạn không đóng băng toàn bộ app, bạn đóng băng những phần mà regressions gây hại.
Bắt đầu bằng cách liệt kê các luồng quan trọng bằng ngôn ngữ đơn giản: login (kèm reset mật khẩu), onboarding, checkout, settings. Với mỗi luồng, nêu “xong” nghĩa là gì. Ví dụ: “Người dùng có thể đăng nhập bằng email + mật khẩu, vào Dashboard, và vẫn giữ đăng nhập sau khi refresh.”
Rồi khóa các edge case mà người ta hay quên. Hành vi nút back là nguồn drift kinh điển: “Back từ Checkout trả về Cart (không phải Home), và các mục trong cart vẫn còn.” Nêu rõ trạng thái lỗi (“mật khẩu sai hiển thị cùng thông báo”), trạng thái rỗng (“không có project hiển thị copy rỗng như trước”), và trạng thái loading (“spinner xuất hiện trong 200ms, không có nhảy bố cục”).
Nếu hiệu năng và bảo mật quan trọng, đóng băng chúng luôn. Nếu không đề cập, mô hình có thể “cải tiến” bằng cách thêm request, logging mới, hoặc thay đổi kiểm tra auth.
Một cách chặt chẽ để chỉ định mà không viết dài:
Hãy cụ thể về luồng dữ liệu trong một câu mỗi mục. Ví dụ: “Địa chỉ chỉ được lưu sau khi nhấn Save, lưu trong bản ghi user profile, và phải tồn sau logout/login.” Mức độ chi tiết này ngăn autosave vô ý, trường mới, hay thay đổi timing gây lỗi cho người dùng thật.
Drift UI thường xảy ra vì mô hình “giúp” bằng cách dọn style, spacing, hoặc cấu trúc component. Cách sửa giống như với logic nghiệp vụ: nêu rõ những phần phải giữ nguyên và chỉ rõ duy nhất cái được phép thay đổi.
Khóa cấu trúc hiển thị nhìn thấy được. Ghi rõ bố cục (cột/hàng, vị trí header và footer), quy tắc spacing (padding, gaps, alignment), và hành vi component (hover, trạng thái disabled, spinner loading, thông báo lỗi). Nếu một component có cảm giác cụ thể, nói thẳng: “Kích thước nút, bán kính góc và màu phải giữ y nguyên.”
Hành vi responsive cần quy tắc rõ. Nếu bạn không nhắc mobile, công cụ có thể “cải tiến” nó. Nêu breakpoint bạn quan tâm và điều gì phải xảy ra ở mỗi breakpoint: thứ tự xếp chồng, phần ẩn, thanh cố định, và kích thước tap targets.
Cũng đóng băng chữ. Nói rõ với mô hình rằng toàn bộ copy, nhãn, placeholder và helper text phải giữ nguyên, ngoại trừ chuỗi duy nhất bạn chỉnh. Điều này ngăn việc viết lại thầm lặng làm thay đổi ý nghĩa.
Một prompt gọn bạn có thể dán vào yêu cầu thay đổi:
Nếu có thể, yêu cầu ảnh chụp màn hình trước/sau. Nếu không có ảnh, yêu cầu mô tả “UI diff” ngắn (cái gì di chuyển, cái gì thay đổi kích thước, đổi màu) để bạn phê duyệt tự tin.
Quy tắc nghiệp vụ là nơi dễ xảy ra regression khi bạn chỉnh UI. Một cập nhật nhãn có thể vô ý thay đổi phép tính, chuyển trạng thái, hoặc ai thấy được một bản ghi. Xử lý quy tắc và dữ liệu như hợp đồng đóng băng.
Bắt đầu bằng cách nêu vài quy tắc mà drift sẽ gây hại nhất. Viết chúng như test: input, output và ai được phép làm gì.
Thay vì “giữ giá như cũ,” cụ thể:
Thêm một ví dụ số để loại bỏ cách hiểu. Ví dụ: “Order subtotal $120, discount 10% (applies before tax), tax 8.25% on discounted amount. Expected total = (120 - 12) * 1.0825 = $116.91. Rounding to 2 decimals only at the final total.”
Ghi rõ quyền nhìn theo vai trò, không chỉ hành động. Ví dụ: “Support agents có thể xem trạng thái đơn và email khách hàng, nhưng không được xem chi tiết thẻ đầy đủ. Chỉ admins mới có thể hoàn tiền.”
Nếu validations quan trọng, đóng băng chúng rõ ràng. Nói trigger và thông báo hiển thị: “Nếu start date sau end date, chặn lưu và hiển thị: ‘End date must be after start date.’ Không thay đổi wording này.”
Đừng quên tác động bên ngoài app. Nếu bạn gửi email, webhook, hay gọi API bên thứ ba, đóng băng những gì phải giữ: tên sự kiện, trường payload, thời điểm (ngay lập tức hay trì hoãn), và hành vi idempotency (không gửi trùng khi retry).
Đối xử với cập nhật nhỏ như hợp đồng mini. Mẫu hoạt động tốt nhất khi thay đổi hẹp và mọi thứ khác được đóng băng rõ ràng.
Viết thay đổi như một câu có thể kiểm tra. “On the settings page, add a toggle to enable dark mode” là có thể kiểm tra. “Improve the settings UI” thì không.
Viết danh sách đóng băng cho những phần sẽ gây hậu nếu drift: luồng người dùng, phần UI chính, quy tắc nghiệp vụ, hành vi dữ liệu, và bất kỳ API hay bảng DB nào phải giữ nguyên.
Thêm acceptance checks và kế hoạch test nhanh. Đây nơi ngăn “chạy ổn trên máy tôi” bất ngờ. Bao gồm kiểm tra như: toggle mới xuất hiện, các setting hiện tại vẫn lưu được, và không có phần nào khác trên trang dịch chuyển.
Trước khi sửa, yêu cầu assistant lặp lại lại các ràng buộc của bạn. Để nó xác nhận cái gì sẽ thay đổi và gì phải giữ y nguyên. Nếu tóm tắt sai, sửa prompt trước khi cho phép thay đổi.
Yêu cầu cài đặt nhỏ nhất: không refactor, không đổi tên, không thay đổi format ngoài các dòng cần chỉnh. Bạn mua một thay đổi, không phải một cuộc đại tu.
Một checklist review ngắn:
Điều này đặc biệt hiệu quả trong Koder.ai: dán danh sách đóng băng vào Planning Mode, yêu cầu nó echo constraints, rồi tạo patch nhỏ nhất.
Hầu hết sửa “nhỏ” hỏng vì cùng lý do: yêu cầu bảo vệ mục tiêu nhưng không bảo vệ hành vi. Mô hình có thể đạt mục tiêu theo cách mới làm thay đổi màn, logic, hoặc dữ liệu.
Một cái bẫy hay gặp là đóng băng kết quả (“làm onboarding mượt hơn”) thay vì các bước chính xác người dùng đi qua. Một cái khác là viết “giữ mọi thứ giống” và giả định hệ thống biết nghĩa đó.
Những lỗi thường gây drift:
Ví dụ nhỏ: bạn yêu cầu “làm nút nổi bật hơn” và đóng băng màu, nhưng quên đóng băng trạng thái disabled. Bản cập nhật có thể luôn bật nút, thay đổi hành vi theo cách bạn chỉ nhận ra sau này.
Cái giúp là nêu cụ thể những gì không được phép thay đổi. Trước khi chấp nhận cập nhật, làm một pass regression nhanh:
Nếu bất kỳ điều nào khác trước, yêu cầu bị thiếu một chi tiết đóng băng, chứ không phải “code tệ.”
Một lặp an toàn thường là một chỉnh polish UI nhỏ nơi workflow không được phép thay đổi.
Kịch bản: một founder có màn signup đơn giản với form ngắn (Name, Email, Company size) và nút chính submit form rồi chuyển người dùng tới dashboard.
Yêu cầu thay đổi chính xác (một câu): “Rename the primary button from 'Create account' to 'Continue' and change the 'Company size' field from a free-text input to a dropdown.”
Áp mẫu bằng cách đóng băng những gì phải giữ:
Acceptance checks bạn chạy trong vài phút:
Một trợ lý tốt nên nhắc lại các mục đóng băng, xác nhận chỗ mơ hồ (ví dụ: các tùy chọn dropdown cụ thể và giá trị nào được lưu), rồi chỉ thực hiện thay đổi tối thiểu cần thiết. Nó cũng nên nêu rõ những gì cố ý không đụng tới (routing, logic xác thực, shape payload).
Trước khi chấp nhận “thay đổi nhỏ,” làm một pass nhanh tìm drift thầm. Mục tiêu không phải QA đầy đủ. Mà là xác nhận app vẫn hành xử giống nơi bạn nói “không thay đổi,” ngoại trừ duy nhất chỉnh sửa mong muốn.
Chạy các kiểm tra này theo cùng thứ tự mỗi lần. Giữ review bình tĩnh và dễ phát hiện regressions.
Revert nếu bất kỳ mục đóng băng nào thay đổi, dù app “vẫn chạy.” Một nhãn đổi, một trường mới, hoặc quy tắc hơi khác đều là dấu hiệu mô hình làm quá quyền. Re-issue yêu cầu với ràng buộc chặt hơn: lặp lại thay đổi đơn trong một câu, liệt kê các luồng/màn phải đóng băng theo tên, và thêm “no schema changes, no endpoint changes, no behavior changes outside X.” Nếu bạn dùng Koder.ai, chụp snapshot trước khi test giúp rollback chỉ một bước khi có drift.
Nếu bạn xây dựng trong Koder.ai, mẫu “không thay đổi” hiệu quả nhất khi thành thói quen: một thay đổi nhỏ, mọi thứ khác khóa, và có cách rõ ràng để quay lại nếu có drift.
Trước khi yêu cầu thay đổi, vào Planning Mode và để assistant lặp lại phạm vi bằng lời. Yêu cầu nó nhắc lại hai điều: (1) thay đổi chính xác, và (2) danh sách đóng băng rõ ràng (flows, UI details, business rules không được đổi). Một prompt planning hiệu quả: “Restate my request. Then list what must not change. If anything is unclear, ask questions before editing.”
Đối xử mỗi yêu cầu như một checkpoint. Tạo snapshot trước khi áp cập nhật, rồi snapshot sau khi xác minh. Nếu có gì vỡ, rollback nhanh hơn là cố vá thay đổi tồi.
Ví dụ: bạn điều chỉnh nhãn nút trong một màn React. Thay đổi nhỏ nhưng vẫn có thể dịch spacing, trigger rerender, hoặc làm hỏng test tự động. Snapshot cho phép so sánh hành vi và revert nhanh.
Một workflow đơn giản:
Koder.ai có thể tạo web (React), backend (Go + PostgreSQL), và mobile (Flutter). Mẫu vẫn như nhau dù code khác nhau. Đóng băng những phần định nghĩa hành vi, không chỉ file.
Nếu bạn thay endpoint backend, đóng băng shape request/response, quy tắc xác thực và ghi dữ liệu. Nếu thay màn mobile, đóng băng thứ tự điều hướng, mặc định field và thông báo lỗi. Nếu thay logic DB, đóng băng ý nghĩa các row hiện tại và giữ migrations an toàn.
Sao chép template, làm một thay đổi nhỏ hôm nay, và xác minh bằng checklist trước khi chấp nhận. Giữ nguyên text template và đổi nội dung thay đổi cho lần tiếp theo, từng bước một.
Sử dụng mẫu này khi bạn muốn một thay đổi cụ thể và cần mọi thứ khác giữ nguyên. Nó đặc biệt hữu ích cho checkout, xác thực, thanh toán hoặc bất kỳ luồng nào mà sự dịch chuyển nhỏ có thể gây hậu quả thật cho người dùng.
Bởi vì các phần của một app chia sẻ component, dữ liệu và quy tắc. Một sửa UI nhỏ có thể tác động đến component được tái sử dụng, làm lệch bố cục ở nơi khác, thay đổi xác thực hoặc thay đổi payload API mà bạn không nhận ra cho đến sau.
Viết một mục tiêu rõ ràng, sau đó liệt kê những gì phải giữ nguyên sau khi thay đổi. Mấu chốt là đóng băng hành vi (luồng, quy tắc, dữ liệu, tích hợp) và các chi tiết hiển thị, không chỉ nói “đừng phá gì cả.”
Giữ ngắn nhưng cụ thể: các luồng quan trọng, chi tiết UI/UX không được thay đổi, quy tắc nghiệp vụ, hành vi dữ liệu và tích hợp. Nếu bạn không thể nêu rõ những gì phải giữ nguyên, mô hình sẽ phải đoán và đoán dẫn đến drift.
Giới hạn nó vào khu vực nhỏ nhất vẫn bảo vệ bạn. Ví dụ: đóng băng luồng checkout và các component chia sẻ của nó, nhưng đừng đóng băng toàn bộ app nếu bạn chỉ thay đổi một nhãn trên một màn hình.
Nêu các hành trình bước từng bước và xác định thế nào là “hoàn thành”. Thêm các edge case hay quên như hành vi nút back, thông báo lỗi, trạng thái rỗng, và hành vi làm mới để luồng giữ nguyên ở những chỗ người dùng nhận thấy nhất.
Đóng băng rõ cấu trúc hiển thị, khoảng cách, trạng thái component (hover/disabled/loading), và tất cả nội dung văn bản ngoại trừ chuỗi duy nhất bạn đang sửa. Nếu không, mô hình có thể “dọn dẹp” style hoặc viết lại text theo cách làm thay đổi ý nghĩa hoặc bố cục.
Đóng băng hợp đồng: dạng request/response, quy tắc xác thực, quyền, các phép tính, và những gì được lưu và khi nào. Thêm một ví dụ số cho các quy tắc nhạy cảm như giá để không còn cách hiểu khác khi thực hiện.
Yêu cầu các bài kiểm tra chấp nhận mà bạn có thể chạy nhanh, cộng thêm một bản tóm tắt dạng diff ngắn về những gì thay đổi và ở đâu. Sau đó xác minh luồng được đóng băng end-to-end, kích hoạt ít nhất một trạng thái lỗi, và xác nhận dữ liệu/tích hợp không đổi.
Tạo snapshot trước khi thay đổi, chạy planning pass để lặp lại phạm vi và danh sách đóng băng, rồi áp bản vá nhỏ nhất. Sau khi xác minh, chụp snapshot nữa để rollback dễ dàng nếu có drift.