Cách đặt câu lệnh đã thay đổi. Phần lớn hướng dẫn của chúng ta thì không.

Các mô hình đã thông minh hơn. Các stack prompt của chúng ta đã cũ đi. Đã đến lúc thay thế bảo tàng hướng dẫn bằng một bản đồ nhỏ, ranh giới rõ ràng và một vạch đích.

Vài ngày trước, tôi phát hiện ra một điều hơi khó chịu:

Gần như tất cả các prompt, tệp hướng dẫn, quy tắc và kỹ năng của tôi đều đã lỗi thời.

Không phải là hoàn toàn vô dụng. Chỉ là chúng được viết cho một thế hệ mô hình khác.

Các stack prompt từng giúp các mô hình cũ hoạt động tốt giờ đây có thể khiến GPT-5.6, Claude Fable 5, Claude Opus 5, Grok 4.5 và các công cụ viết mã như Cursor trở nên cứng nhắc hơn, tốn kém hơn, và đôi khi còn tệ hơn.

Đây không phải là tín ngưỡng prompt mới nhất của tôi. Anthropic đã cảnh báo rõ ràng rằng các kỹ năng được viết cho các mô hình trước có thể quá mang tính áp đặt đối với Fable 5 và có thể làm giảm chất lượng đầu ra. OpenAI khuyến nghị các prompt tinh gọn hơn, ít hướng dẫn lặp lại hơn và mô tả công cụ đơn giản hơn.

Đọc xong hơi ngượng thật.

Kể từ mùa hè năm 2025, tôi đã viết hơn 100.000 prompt. Nhiều gần bằng tổng số tweet của Elon Musk trong đời, chỉ có điều ít tên lửa hơn và nhiều bộ kiểm thử thất bại hơn.

Nhật ký của tôi chứa khoảng 15 triệu tin nhắn mô hình, bao gồm tin nhắn trợ lý, lời gọi công cụ, tác nhân phụ và các sự kiện quy trình làm việc. Cho đến ngày 26 tháng 3, tổng số là khoảng bảy triệu. Tám triệu khác đến trong vòng ba tháng, phần lớn là do sự bùng nổ của tác nhân phụ và quy trình làm việc xung quanh các mô hình viết mã mới hơn.

Vì vậy, tôi nghĩ mình biết cách viết hướng dẫn.

Sau đó, tôi đọc tài liệu mới và nhận ra rằng phần lớn những gì tôi đã học đã âm thầm biến thành nợ kỹ thuật.

Nợ Prompt Được Tạo Ra Như Thế Nào

Cách tiếp cận cũ của tôi rất đơn giản:

• Mô hình mắc lỗi, tôi thêm một quy tắc.
• Nó hỏi một câu không cần thiết, tôi lại thêm một quy tắc.
• Nó bỏ sót một trường hợp ngoại lệ, tôi thêm ba ví dụ.

Mỗi lần bổ sung trông có vẻ hợp lý. Sau một năm, tệp hướng dẫn trông giống cái ngăn kéo bếp nơi bạn cất mười hai sợi cáp cũ vì biết đâu một trong số chúng vẫn còn dùng được cho thứ gì đó quan trọng.

Kết quả là một bộ sưu tập ngày càng lớn gồm:

• các hướng dẫn bị trùng lặp
• các ví dụ tiêu cực
• các quy tắc xung đột
• các giải pháp thay thế cho mô hình cũ
• các bước xác minh quá mức
• các quy trình chi tiết chỉ áp dụng cho một tác vụ duy nhất
• các ví dụ được tạo ra để khắc phục những lỗi không còn tồn tại

Các mô hình cũ thường cần giàn giáo này. Các mô hình mới hơn làm theo hướng dẫn tốt hơn và suy luận ý định đáng tin cậy hơn. Điều đó có nghĩa là chúng cũng tiếp nhận những hành lý cũ kỹ của chúng ta một cách nghiêm túc hơn.

Chúng ta đã chế tạo những cỗ máy thông minh hơn và sau đó nhồi đầy gạch vào cốp xe.

Ảnh chân dung đen trắng độ tương phản cao của một phụ nữ trẻ tóc vàng trong chiếc áo cổ lọ sẫm màu, bối cảnh phòng thu tối giản. Ánh sáng viền nhẹ nhàng tách biệt hình bóng của cô khỏi nền xám mềm mại, tăng thêm chiều sâu. Tâm trạng nội tâm nhưng mạnh mẽ, thể hiện chủ nghĩa hiện thực vượt thời gian. Độ rõ nét của định dạng trung bình kỹ thuật số Hasselblad X2D, lấy cảm hứng từ nhiếp ảnh báo chí thế kỷ 20.

Nguyên Tắc Mới: Nói Ít Hơn, Nghĩa Nhiều Hơn

Giải pháp không phải là viết những prompt nhỏ xíu và mù quáng tin tưởng vào mô hình.

Một prompt ngắn nhưng mơ hồ vẫn là một prompt tồi.

Mục tiêu là một prompt chứa nhiều thông tin, trong đó mọi hướng dẫn đều xứng đáng có mặt.

Các quy tắc hiện tại của tôi là:

• Nêu mỗi hướng dẫn một lần.
• Loại bỏ sự lặp lại giữa các prompt hệ thống, tệp dự án, kỹ năng, mô tả công cụ và prompt tác vụ.
• Ưu tiên mô tả rõ ràng hành vi mong muốn hơn là một bộ sưu tập các trường hợp thất bại.
• Giữ các ràng buộc phủ định khi chúng bảo vệ một ranh giới thực sự, nhưng đừng viết bảo tàng về mọi thứ mô hình không bao giờ được làm.

Ví dụ, thay vì thế này:

Không tái cấu trúc mã không liên quan. Không đổi tên tệp. Không thay đổi API. Không thêm lớp trừu tượng. Không dọn dẹp các mô-đun lân cận.

Tốt hơn:

Giới hạn thay đổi trong luồng đăng nhập bị ảnh hưởng. Giữ nguyên các hợp đồng API hiện có và kiến trúc xung quanh. Ưu tiên bản sửa lỗi nhỏ nhất và chính xác nhất.

Cùng một ranh giới. Ít nhiễu hơn. Nhiều không gian cho phán đoán hơn.

Trong một mẫu đánh giá tác nhân viết mã nội bộ, OpenAI nhận thấy prompt hệ thống tinh gọn hơn giúp cải thiện điểm số khoảng 10 đến 15 phần trăm, đồng thời giảm lượng token sử dụng từ 41 đến 66 phần trăm và chi phí từ 33 đến 67 phần trăm. OpenAI cũng nói rõ rằng những con số này chỉ mang tính định hướng và cần được xác thực trên khối lượng công việc của riêng bạn.

Nói cách khác, việc xóa bỏ các hướng dẫn có thể cải thiện cả chất lượng lẫn hóa đơn. Đó là một sự kết hợp hiếm có và tuyệt vời.

Tệp Hướng Dẫn Toàn Cầu Của Bạn Nên Nhàm Chán

Các tệp toàn cầu tại ~/.claude/CLAUDE.md và ~/.codex/AGENTS.md chỉ nên chứa các hướng dẫn áp dụng cho mọi dự án và mọi tác vụ.

Đối với tôi, một người bản ngữ nói tiếng Đức, điều đó bao gồm những thứ như:

1Sử dụng tiếng Anh cho tất cả mã, bình luận, tài liệu, ví dụ,
2kiểm thử, cấu hình và tin nhắn commit.
3
4Ưu tiên thuật ngữ bao gồm như allowlist/blocklist,
5primary/replica, placeholder/example, main branch,
6conflict-free, và concurrent/parallel.

Đó có lẽ đã là phần lớn nội dung của tệp toàn cầu.

• Quy trình triển khai không thuộc về đó.
• Các lệnh kiểm thử dành riêng cho dự án không thuộc về đó.
• Kiến trúc của một kho lưu trữ cụ thể không thuộc về đó.

Tệp hướng dẫn toàn cầu của bạn không nên biết cách triển khai một trang WordPress, xuất bản gói npm và khởi động lại cơ sở dữ liệu sản xuất. Đó không phải là sự linh hoạt. Đó là sự nhầm lẫn với định dạng tốt.

Đối với các tệp cấp dự án, hãy bao gồm thông tin ổn định mà mô hình thực sự cần lặp lại: mục đích của dự án, các ràng buộc kiến trúc quan trọng, các quy ước bất thường và chỉ dẫn đến các hướng dẫn chuyên môn hơn.

Anthropic hiện khuyến nghị nhắm mục tiêu ít hơn 200 dòng cho mỗi tệp CLAUDE.md. Các tệp dài hơn tiêu tốn nhiều ngữ cảnh hơn và có thể làm giảm khả năng tuân thủ hướng dẫn. Tài liệu của họ cũng khuyến nghị các quy tắc theo đường dẫn cụ thể và các kỹ năng theo yêu cầu khi các tệp hướng dẫn trở nên quá lớn.

Hai trăm dòng không phải là một quy luật bất biến của tự nhiên, nhưng nó là một hồi chuông cảnh báo tuyệt vời.

Tôi cũng sẽ tránh yêu cầu Claude hoặc Codex tự viết lại toàn bộ hệ thống hướng dẫn và chấp nhận kết quả một cách mù quáng. Tôi đã thử điều này với hầu hết mọi mô hình mới. Chúng rất hữu ích để tìm ra sự trùng lặp, xung đột và các điểm có thể cắt giảm, nhưng chúng vẫn có xu hướng giữ lại quá nhiều thứ lộn xộn được thừa hưởng hoặc phát minh ra một bộ máy hành chính mới đẹp đẽ.

Hãy để mô hình chuẩn bị kế hoạch phá dỡ. Bạn vẫn nên quyết định bức tường nào là chịu lực.

Chân dung một phụ nữ trẻ điềm tĩnh với mái tóc vàng buộc đuôi ngựa, thể hiện qua tông màu đen trắng sâu lắng. Ánh sáng phòng thu mềm mại nhưng có hướng, làm nổi bật các đường nét trên khuôn mặt và bóng đổ tự nhiên. Chụp qua ống kính 120mm để tạo độ nén nhẹ nhàng, gợi lên phong cách chân dung Hasselblad với cảm giác chân thực và cảm xúc kiềm chế.

Ngừng Sử Dụng Một Tệp Cho Mọi Mô Hình

Cho đến gần đây, tôi tạo CLAUDE.md và tạo symlink AGENTS.md trỏ đến nó.

Tôi không còn làm điều đó nữa.

Phải, duy trì hai tệp thật phiền phức. Cũng giống như việc duy trì các bản sửa lỗi riêng cho từng trình duyệt. Chúng ta vẫn làm điều đó khi hành vi khác nhau.

Các mô hình bây giờ có các mặc định khác nhau rõ rệt.

GPT-5.6 ngắn gọn hơn theo mặc định, vì vậy một hướng dẫn "hãy ngắn gọn" toàn cầu có thể làm cho một số câu trả lời quá ngắn. Claude Opus 5 có xu hướng tạo ra các phản hồi dài hơn hướng đến người dùng, vì vậy một hướng dẫn ngắn về độ dài phản hồi vẫn có thể hữu ích. Fable 5 có thể điều tra và lập kế hoạch vượt xa những gì một tác vụ thông thường yêu cầu, đặc biệt là ở các cài đặt nỗ lực cao hơn, vì vậy nó được hưởng lợi từ phạm vi rõ ràng và ranh giới dừng lại. Opus 5 đã thực hiện tự xác minh đáng kể, điều đó có nghĩa là các quy tắc "kiểm tra lại mọi thứ" cũ có thể tạo ra việc xác minh quá mức tốn kém.

Các dữ kiện dự án chung vẫn có thể nằm trong tài liệu chung. Bộ điều hợp hành vi cấp cao nhất nên phù hợp với mô hình đọc nó.

Một prompt phổ quát thường trở thành mẫu số chung nhỏ nhất.

Thay Thế Prompt Chính Bằng Hướng Dẫn Theo Yêu Cầu

Cấu trúc ưa thích của tôi là một tệp lõi nhỏ cộng với tài liệu và kỹ năng dành riêng cho từng tác vụ.

Một tệp hướng dẫn dự án có thể chứa nội dung này:

1Chỉ tải hướng dẫn dành riêng cho tác vụ khi có liên quan:
2
3- `docs/agent/commit_rules.md`
4- `docs/agent/code_review.md`
5- `docs/agent/debug_workflow.md`
6- `docs/agent/frontend_polish.md`
7- `docs/agent/release_notes.md`

Hãy chú ý đến các dấu backtick.

Trong Claude Code, viết @docs/example.md bên ngoài một khoảng mã sẽ nhập tệp đó vào ngữ cảnh khi khởi động. Điều đó hữu ích khi bạn luôn cần nội dung, nhưng nó không phải là tải chậm. Một đường dẫn đơn giản cho phép tác nhân biết thông tin tồn tại ở đâu mà không tự động mang toàn bộ tài liệu vào mọi tác vụ.

Các kỹ năng thậm chí còn tốt hơn cho các quy trình có thể lặp lại. Toàn bộ nội dung của chúng chỉ được tải khi kỹ năng được sử dụng, vì vậy một quy trình làm việc chi tiết không tiêu tốn ngữ cảnh trong khi bạn đang sửa một lỗi CSS không liên quan.

Ví dụ, một kỹ năng commit có thể có một trình kích hoạt hẹp:

name: git-commit-conventional

description: Sử dụng sau khi thay đổi mã để soạn thảo hoặc xác thực tin nhắn commit.

Kỹ năng sau đó có thể chứa định dạng chính xác, các loại được phép, quy tắc độ dài chủ đề, yêu cầu nội dung và định dạng đầu ra.

1---
2name: git-commit-conventional
3description: Use for drafting or validating git commit messages after code changes. Do not use for diagnosis-only, planning-only, or review-only tasks.
4---
5
6# Goal
7
8Produce Conventional Commit messages that are short, correct, and review-friendly.
9
10# Rules
11
12- Format: <type>(<scope>): <subject>
13- Types: feat | fix | docs | style | refactor | test | chore | perf
14- Subject: imperative mood, no period, <= 50 chars
15- Small changes: one-line commit
16- Larger changes: add a wrapped body explaining what and why
17- Keep commits atomic and split by concern
18
19# Output
20
21Return 1-3 candidate commit messages, then recommend the best one.

Tệp hướng dẫn chính của bạn không cần phải mang toàn bộ hiến pháp Conventional Commits vào mọi phiên gỡ lỗi.

Bạn có biết không? Claude Code cũng hỗ trợ CLAUDE.local.md cho các cài đặt dành riêng cho dự án cá nhân như tên máy chủ cục bộ, URL sandbox, tài khoản kiểm thử ưa thích hoặc các lệnh dành riêng cho máy. Thêm nó vào .gitignore. Cuối cùng thì nó cũng là một ngôi nhà thích hợp cho thông tin quan trọng với bạn và không quan trọng chút nào với phần còn lại của nhóm.

Nhắc Đến Kết Quả, Không Phải Vũ Đạo

Các mô hình mới hơn thường hoạt động tốt hơn khi chúng hiểu được điểm đến và các ranh giới, thay vì nhận được một mô tả cứng nhắc về từng bước chân.

Bất cứ khi nào có thể, tôi thay thế "đầu tiên làm A, sau đó B, rồi C" bằng:

• kết quả yêu cầu
• ngữ cảnh liên quan
• các ràng buộc cứng
• bằng chứng yêu cầu
• tiêu chí thành công
• ranh giới phê duyệt
• điều kiện dừng

Ví dụ:

1Goal
2
3Fix the failing login flow in the web application.
4
5Context
6
7Focus on `apps/web` and `packages/auth`.
8Use the attached test output as the starting point.
9
10Constraints
11
12Preserve existing API contracts.
13Keep changes limited to the authentication flow.
14Prefer the smallest correct fix.
15Broaden the change only when required for correctness.
16
17Evidence
18
19Run the relevant tests and report their actual results.
20Identify the root cause with references to the affected files.
21
22Done when
23
24The failing login test passes.
25Tests are added or updated when the corrected behavior requires it.
26The final summary explains the cause, the fix, and any remaining risk.
27
28Approval
29
30You may inspect files, edit in-scope code, and run non-destructive tests.
31Ask before destructive actions, database migrations, external writes,
32or a material expansion of scope.
33
34Stop
35
36Stop when the fix is implemented, validated, and summarized.

Điều này cho phép tác nhân tự do giải quyết vấn đề mà không được phép cải tạo toàn bộ ngôi nhà trong khi sửa một tay nắm cửa. (Hãy sử dụng LLM để tạo các prompt như thế này.)

Đặt Nỗ Lực Suy Luận Vào Cài Đặt

• "Suy nghĩ kỹ hơn."
• "Siêu suy luận."
• "Hít một hơi thật sâu và suy luận từng bước."

Những cụm từ này đã có một sự nghiệp lâu dài và xuất sắc trong kỹ thuật prompt. Đã đến lúc cho nhiều cụm từ trong số chúng nghỉ hưu một cách đàng hoàng.

Sử dụng các điều khiển mô hình.

Đặt mức độ nỗ lực thông qua /effort, API hoặc cấu hình liên quan. So sánh nhiều mức độ nỗ lực trên các tác vụ đại diện. Cao hơn không tự động là tốt hơn.

OpenAI khuyến nghị bắt đầu di chuyển GPT-5.6 ở mức nỗ lực hiện tại và kiểm tra một mức thấp hơn. Nó cũng nói rằng các prompt cho chế độ Pro nên tập trung vào mục tiêu, ngữ cảnh, ràng buộc, bằng chứng, tiêu chí thành công và định dạng đầu ra. Bạn không cần phải nói với mô hình là "hãy suy nghĩ kỹ hơn."

Một tham số suy luận là một điều khiển.

"Làm ơn kích hoạt bộ não kỹ thuật số khổng lồ của bạn" là một lời động viên từ một bộ phim thể thao.

read image description

ALT

Ảnh chụp phòng thu một phụ nữ thanh lịch với mái tóc đen gợn sóng và băng đô sành điệu, mặc quần da cạp cao. Cô ngồi trên ghế đẩu thấp, một đầu gối đưa về phía trước, đôi chân dài thu hút sự chú ý. Chi tiết sắc nét, nền trắng tinh khiết và chuyển động nhẹ của mái tóc tạo thêm năng lượng. Tông màu tổng thể gợi nhớ đến nhiếp ảnh biên tập thập niên 1990 - sạch sẽ, táo bạo, tự tin.

Tự Chủ Cần Có Hàng Rào

Các tác nhân viết mã hiện đại chủ động hơn nhiều. Điều này rất hữu ích cho đến khi tác nhân giải quyết thêm ba vấn đề, tạo ra hai lớp trừu tượng, khởi chạy sáu tác nhân phụ và tự hào trình bày một kiến trúc mà bạn chưa bao giờ yêu cầu.

Đặt ranh giới một cách rõ ràng.

Xác định những gì tác nhân có thể làm mà không cần hỏi. Xác định những gì cần phê duyệt. Bảo nó khi nào nên dừng lại.

Cũng đặt giới hạn cho việc ủy quyền. Cả Opus 5 và Fable 5 đều sẵn sàng sử dụng các tác nhân phụ song song hơn. Điều đó rất mạnh mẽ cho các cuộc điều tra độc lập, nhưng tốn kém và chậm cho các tác vụ nhỏ. Một bản sửa lỗi mười hai dòng không cần một cuộc họp ủy ban.

Chế độ Goal của Codex thực sự xuất sắc. Chúng tôi đã sử dụng nó trong một dự án suốt bốn ngày liên tục.

Nhưng đừng coi một tác nhân chạy lâu như một nồi nấu chậm. Bạn không thể thêm một mục tiêu vào buổi sáng và cho rằng bữa tối sẽ hoàn hảo bốn ngày sau đó.

Đối với các lần chạy dài hơn của chúng tôi, chúng tôi kiểm tra mỗi 30 đến 60 phút với nội dung như:

Báo cáo mục tiêu hiện tại, công việc đã hoàn thành, bằng chứng đã xác minh,

các vấn đề đang chặn, hành động tiếp theo và nơi tiến độ được ghi lại.

Chứng minh mọi tuyên bố về tiến độ bằng đầu ra công cụ thực tế hoặc trạng thái kho lưu trữ.

Nêu rõ những gì vẫn chưa được xác minh.

OpenAI mô tả chế độ Goal phù hợp với các mục tiêu có thể chạy trong nhiều giờ hoặc nhiều ngày và hỗ trợ rõ ràng việc tiếp tục cùng một phiên để định hướng công việc hoặc yêu cầu cập nhật trạng thái. Anthropic cũng khuyến nghị việc chứng minh các báo cáo tiến độ bằng kết quả công cụ thực tế thay vì tin tưởng vào các tuyên bố tường thuật.

Tự chủ không phải là không có sự giám sát. Đó là sự giám sát ở một cấp độ cao hơn.

Cận cảnh chân dung một nữ thần được chiếu sáng bởi ánh trăng bạc, đôi mắt sáng long lanh và tràn đầy tình cảm. Chiếc mũ của cô lấp lánh với những thiên hà nhỏ bé, các đường xoắn ốc lấy cảm hứng từ Klimt và các họa tiết thiên thể. Phía sau là phông nền phấn màu phẳng, được sắp xếp cẩn thận với kiểu dàn dựng sân khấu Andersonian, kết cấu phong phú và sự quyến rũ nhẹ nhàng.

Tái Cấu Trúc Prompt Như Mã Sản Xuất

Đừng xóa một nửa prompt hệ thống, chạy một tác vụ và tuyên bố quá trình di chuyển thành công.

OpenAI khuyến nghị loại bỏ một nhóm hướng dẫn, ví dụ hoặc công cụ tại một thời điểm, sau đó chạy lại cùng các đánh giá. Đó chính xác là cách tái cấu trúc prompt nên hoạt động.

Đo lường:

• thành công của tác vụ
• tính đầy đủ
• tính chính xác
• bằng chứng yêu cầu
• lượng token sử dụng
• độ trễ
• chi phí
• các lời gọi công cụ không cần thiết
• các thay đổi không cần thiết

Sử dụng các tác vụ đại diện, bao gồm cả các trường hợp thực tế khó xử, không chỉ một bản demo thân thiện đã hoạt động trước khi di chuyển.

Dọn dẹp prompt mà không có đánh giá vẫn chỉ là phỏng đoán. Nó chỉ là phỏng đoán trong một chiếc áo sạch hơn.

Mã Được Tạo Vẫn Chứa Lỗi

Các mô hình đã được cải thiện rất nhiều. Chúng chưa loại bỏ được các khiếm khuyết phần mềm.

Trong công việc của chúng tôi, một quy tắc chung gần đúng vẫn là khoảng một lỗi cho mỗi 300 dòng mã nguồn được tạo ra. Đây không phải là một điểm chuẩn khoa học, và tôi không đếm các mẫu HTML lặp đi lặp lại theo cùng một cách. Nhưng nó đủ đáng tin cậy để khi một tác nhân tạo ra 1.500 dòng mã ứng dụng thực sự, tôi cho rằng có vài lỗi đang ẩn náu bên trong, ít nhất là 5.

Tôi không hỏi liệu có lỗi hay không.

Tôi hỏi năm lỗi ở đâu.

Đôi khi, tôi thêm:

Tìm ra năm lỗi, nếu không bạn sẽ bị thay thế bởi Codex, Claude hoặc Grok.

Phát triển dựa trên đe dọa không phải là một phương pháp luận chính thức, nhưng nó có thể tạo động lực một cách kỳ lạ. ;-)

Nghiêm túc hơn, hãy sử dụng một lượt xem xét mới cho các thay đổi lớn. Chạy các kiểm thử liên quan. Kiểm tra sự khác biệt. Kiểm tra hành vi thực tế, không chỉ biên dịch.

Và hãy theo dõi các kiểm thử một cách cẩn thận. Các mô hình đôi khi vẫn thích "sửa chữa" một kiểm thử thất bại hơn là sửa mã sản xuất gây ra nó.

Một hướng dẫn hữu ích là:

1Treat existing tests as the expected behavior unless the evidence shows
2that a test is incorrect.
3
4When a test fails, investigate the production code first.
5
6Before changing an existing test, explain why its expectation is wrong,
7what the correct behavior should be, and what evidence supports that change.

Đối với các tác vụ lớn, chạy lâu, một công cụ xác minh ngữ cảnh mới có thể hữu ích. Đối với một thay đổi nhỏ, việc tạo ra nhiều tác nhân chỉ để xác nhận lẫn nhau thường đốt thời gian và token. Việc xác minh nên phù hợp với quy mô và rủi ro của tác vụ.

Những Gì Bạn Không Nên Xóa

Bài học không phải là "viết prompt nhỏ xíu và tin tưởng vào cỗ máy."

• Giữ các ranh giới bảo mật và an toàn.
• Giữ các yêu cầu pháp lý và tuân thủ.
• Giữ các lược đồ đầu ra chính xác.
• Giữ hành vi dành riêng cho sản phẩm.
• Giữ kiến thức miền mà mô hình không thể suy luận.
• Giữ các yêu cầu phê duyệt cho các hành động hệ quả.
• Giữ các yêu cầu về trích dẫn và bằng chứng.
• Giữ các tiêu chí kiểm thử và định nghĩa về "hoàn thành".
• Giữ các ví dụ sửa chữa một lỗi có thể đo lường, tái tạo được.
• Mục tiêu không phải là prompt ngắn nhất có thể.
• Mục tiêu là một prompt mà mọi hướng dẫn vẫn mang thông tin hữu ích.

Một Phần Thưởng Cuối Cùng

OpenAI cung cấp một kỹ năng Docs chính thức có thể kiểm tra một dự án và áp dụng hướng dẫn di chuyển GPT-5.6 của nó:

1$openai-docs migrate this project to the GPT-5.6 model family

Đó là một bước đầu tiên hữu ích. Nó không phải là bản đánh giá cuối cùng.

Hãy để Codex xác định các tham số lỗi thời, hướng dẫn trùng lặp và cơ hội di chuyển. Sau đó tự mình kiểm tra mọi thay đổi. Một tác nhân di chuyển là một kỹ sư cấp dưới rất nhanh, không phải là một tòa án hiến pháp.

Kết Luận

• Hãy coi stack prompt của bạn như mã sản xuất.
• Loại bỏ các hướng dẫn chết.
• Xóa sự trùng lặp.
• Tách biệt các tùy chỉnh toàn cầu khỏi các quy tắc dự án.
• Di chuyển các quy trình vào các kỹ năng theo yêu cầu.
• Mô tả kết quả thay vì viết kịch bản cho từng bước.
• Đặt phạm vi rõ ràng, ranh giới phê duyệt, yêu cầu bằng chứng và điều kiện dừng.
• Kiểm soát nỗ lực thông qua cài đặt mô hình.
• Giới hạn các tác nhân phụ.
• Đánh giá mọi thay đổi có ý nghĩa.
• Các mô hình mới nhất cần ít sự quản lý vi mô hơn, nhưng chúng vẫn cần định hướng.
• Một prompt tốt không còn là một cuốn sách hướng dẫn khổng lồ.

Đó là một bản đồ nhỏ, một hàng rào vững chắc và một vạch đích được đánh dấu rõ ràng.

Bạn đã bắt đầu di chuyển các prompt và kỹ năng của mình chưa? Bạn đã loại bỏ điều gì, và điều gì bất ngờ trở nên tốt hơn?

Liên Kết

Các phương pháp hay nhất của Open AI GPT 5.6:

https://developers.openai.com/api/docs/guides/latest-model?model=gpt-5.6#prompting-best-practices

Các phương pháp hay nhất của Claude Opus 5

https://platform.claude.com/docs/en/build-with-claude/prompt-engineering/prompting-claude-opus-5

Các phương pháp hay nhất của Claude Fable 5:

https://platform.claude.com/docs/en/build-with-claude/prompt-engineering/prompting-claude-fable-5

Các kỹ năng / plugin chính thức của open ai:

https://github.com/openai/plugins

Tín dụng: Hình ảnh được tạo bằng Midjourney. Nghiên cứu và thử nghiệm thực tế do tôi thực hiện. Được chỉnh sửa với sự giúp đỡ của OpenAI, Claude và Grammarly.

Prompt hình ảnh chính:

1
2Close-up black-and-white portrait of a serene blonde woman, hair tied back, wearing a black turtleneck sweater. The chiaroscuro effect shapes her face with striking definition, merging soft ambient light and bold shadow. Medium format style with fine film grain and moody tonal gradation. Evokes authenticity and strength.

Tái bút: Tôi yêu @Midjourney :-)