Đừng thay đổi pattern prompt — lặp nhỏ an toàn

Tại sao thay đổi nhỏ thường làm hỏng phần khác

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à gì

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:

• Flows (hành trình người dùng): các bước người dùng đi qua và màn hình xuất hiện.
• UI và UX: bố cục, khoảng cách, thứ tự trường, vị trí nút và tương tác.
• Quy tắc nghiệp vụ và hành vi dữ liệu: quy tắc xác thực, công thức giá, quyền, ghi vào database và phản hồi API.

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 cơ bản bạn có thể tái sử dụng

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.

Cách đóng băng các luồng quan trọng mà không quá mơ hồ

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:

• Flows cần đóng băng: Login, Signup, Checkout, Settings (không thêm bước, không đổi thứ tự màn hình)
• Edge cases cần đóng băng: kết quả nút back, thông báo lỗi, trạng thái rỗng, hành vi khi refresh
• Hành vi dữ liệu cần đóng băng: cái gì được lưu, khi nào được lưu, và xuất hiện ở đâu sau reload
• Bảo mật cần đóng băng: quyền, kiểm tra auth, giới hạn tốc độ, không thêm endpoint công khai
• Hiệu năng cần đóng băng: không thêm API call trong các luồng này, thời gian phản hồi không tệ hơn hiện tạ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.

Cách đóng băng UI và UX

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:

• Giữ y nguyên: routes/screens, thứ tự điều hướng, và hành vi nút back
• Giữ y nguyên: lưới layout, spacing, fonts, màu sắc, và trạng thái component
• Giữ y nguyên: tất cả văn bản và nhãn trừ: <the one string>
• Luật mobile: giữ hành vi hiện tại tại <breakpoints>, không reflow các phần khác
• Output: mô tả mọi thay đổi UI bạn đã làm, và list file/component bị chạm

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.

Cách đóng băng quy tắc nghiệp vụ và hành vi dữ liệu

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ì.

Ghi chi tiết các quy tắc không được thay đổi

Thay vì “giữ giá như cũ,” cụ thể:

• Pricing: công thức chính xác, quy tắc làm tròn (lên/xuống), tiền tệ, thuế/VAT, và khi nào giảm giá áp dụng
• Permissions: vai trò nào có thể tạo, sửa, xóa, phê duyệt, hoàn tiền, export, hoặc xem trường nhạy cảm
• Statuses: các trạng thái hợp lệ và chuyển đổi cho phép (và gì kích hoạt chúng)
• Calculations: tổng, hoa hồng, credit, giới hạn và mọi caps hoặc mức tối thiểu
• Data writes: bảng/bản ghi nào được tạo hoặc cập nhật, và gì phải bất biến

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).

Các bước: thực hiện một yêu cầu thay đổi an toàn

Đố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.

1. 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.

2. 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.

3. 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.

4. 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.

5. 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:

• Chỉ hành vi yêu cầu thay đổi
• Luồng và màn hình đóng băng vẫn giống
• Quy tắc nghiệp vụ và ghi dữ liệu không đổi
• Tests (hoặc bước tay) pass như mô tả
• Không có commit “cleanup” lọt vào

Đ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.

Sai lầm phổ biến vẫn gây drift

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:

• Trừu tượng: bạn bảo vệ ý định, nhưng không nêu flow theo từng nhấp chuột và kết quả mong đợi.
• Bỏ sót edge cases: trạng thái rỗng, loading, lỗi xác thực, quyền truy cập.
• Gộp thay đổi: hai ba chỉnh trong một yêu cầu khiến phải đánh đổi và regressions khó phát hiện.
• Không định nghĩa “giống”: cùng layout UI, cùng API calls, cùng ghi DB, cùng email/notification, cùng events analytics.
• Phê duyệt bằng cảm nhận: “nhìn ổn” mà không kiểm tra các path chính.

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:

• Chạy luồng chính end-to-end (luồng bạn đóng băng)
• Kích hoạt ít nhất một trạng thái lỗi và một trạng thái rỗng
• Kiểm tra quyền (admin vs user thường)
• Xác nhận tác dụng phụ: bản ghi tạo/cập nhật, thông báo gửi, logs/metrics không đổi

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ệ.”

Ví dụ: tinh chỉnh UI nhỏ mà không đổi workflow

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ữ:

• Flow freeze: submit vẫn tạo account, hiển thị cùng thông báo xác thực, và gửi user tới cùng màn tiếp theo.
• UI freeze: bố cục trang, spacing, màu sắc và vị trí nút giữ nguyên.
• Data freeze: payload backend keys và types không đổi; giá trị company size lưu giữ định dạng như trước.
• Business rules freeze: các trường required vẫn required, và nút vẫn disabled cho tới khi form hợp lệ.
• Analytics freeze: cùng tên event tracking firing khi submit và khi có lỗi xác thực.

Acceptance checks bạn chạy trong vài phút:

• Text nút hiển thị “Continue” ở mọi trạng thái (default, loading, disabled).
• Company size là dropdown với mặc định giống trước.
• Submit vẫn dẫn tới dashboard và account được tạo.
• Người dùng hiện tại chỉnh hồ sơ vẫn thấy company size lưu đúng.
• Không có cảnh báo mới hay test fail ở khu vực signup.

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).

Checklist nhanh trước khi phê duyệt cập nhật

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.

5 kiểm tra nhanh (10 phút)

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.

• Luồng quan trọng vẫn hoàn thành end-to-end: Bắt đầu từ entry point thật người dùng dùng (login, landing page, dashboard) và hoàn thành nhiệm vụ chính.
• UI giống y nguyên trừ thay đổi mong muốn: Mở các màn chính bạn đóng băng. Soát bố cục, nhãn, spacing và điều hướng.
• Quy tắc nghiệp vụ vẫn đúng: Spot-check 2–3 trường hợp hay vỡ, như phép tính giảm giá, quyền, hoặc chuyển trạng thái.
• Dạng dữ liệu không đổi: Xác nhận không có trường mới, đổi tên trường, xóa trường, hoặc migration.
• Tích hợp không bị động: Xác nhận không có thay đổi endpoint và không có thay đổi payload (tên trường, required, status codes).

Khi nào revert và re-issue prompt

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.

Bước tiếp theo: áp dụng trong Koder.ai để lặp an toàn hơn

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.

Bắt đầu với planning pass nhanh

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.”

Bảo vệ mỗi lần lặp bằng snapshot

Đố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:

• Tạo snapshot: “Before - change button label only”
• Chạy planning pass và xác nhận danh sách đóng băng
• Yêu cầu thay đổi duy nhất và yêu cầu tóm tắt dạng diff ngắn về gì thay đổi
• Xác minh theo checklist (UI, flows, rules, data)
• Tạo snapshot: “After - verified”

Tái sử dụng cùng mẫu trên toàn bộ stack

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.