Mọi người thường đến gặp tôi và hỏi, "Codex có thể làm việc này không?"
Sau đó, họ dành hai hoặc ba phút tiếp theo để giải thích chính xác "việc này" là gì: vấn đề họ muốn giải quyết, ứng dụng nên làm gì và kết quả tốt sẽ như thế nào. Đôi khi họ chia sẻ những gì họ đã thử, cái gì hiệu quả và cái gì không.
Và tôi nghĩ: bạn thực sự nên nói tất cả những điều này với Codex.
Toàn bộ lời giải thích đó đã là prompt rồi.
Kỹ thuật prompt engineering đã chết. Và cũng chưa chết.
Nếu prompt engineering có nghĩa là học một ngôn ngữ bí mật trước khi nhờ giúp đỡ, thì tôi nghĩ nó gần như đã chết. Đặc biệt là với các mô hình suy luận, thường không có một từ khóa thần kỳ nào mở khóa được câu trả lời đúng. Tôi không nghĩ bạn nên nhìn chằm chằm vào màn hình trống hàng giờ để cố gắng tạo ra một prompt hoàn hảo.
Nhưng nó cũng chưa chết, bởi vì sự rõ ràng vẫn còn quan trọng. Sự mơ hồ khiến công việc trở nên khó khăn hơn cho Codex, cũng giống như với bất kỳ ai khác. Nếu tôi xáo trộn các đoạn văn trong bài viết này hoặc chuyển sang một ngôn ngữ bạn không hiểu, thì sẽ khó theo dõi hơn. Ngay cả thì của động từ cũng quan trọng: "Tôi đã thử cái này" không giống với "Tôi muốn bạn thử cái này."
Bạn thực sự muốn gì? Ngữ cảnh nào quan trọng? Codex nên biết những ràng buộc nào? Một kết quả tốt sẽ trông như thế nào?
Hãy nói chuyện với Codex như cách bạn nói chuyện với một người mà bạn đang làm việc cùng.
Tôi thích bắt đầu với kết quả đầu ra: mục tiêu của tôi là gì? Đó cũng là sự thay đổi lớn hơn với các agent. Thay vì viết kịch bản từng bước và yêu cầu từng kết quả trung gian, tôi có thể giải thích những gì tôi muốn đạt được, đặt ra các ranh giới và để Codex giúp tìm ra con đường.
Hãy nói ra phiên bản lộn xộn
Hầu hết các ý tưởng không đến dưới dạng những đặc tả gọn gàng. Chúng thường nghe giống như:
"Được rồi, tôi có tất cả những tệp này. Định dạng hơi khác nhau một chút. Tôi cần một báo cáo trước thứ Sáu. Tôi nghĩ hầu hết dữ liệu đều có, nhưng cái file export này hơi kỳ lạ..."
Không sao cả. Cứ nói ra đi.
Khi bạn nói lan man, bạn thường cung cấp cho Codex nhiều tín hiệu hơn. Bạn đề cập đến chi tiết mà lẽ ra bạn đã loại bỏ khỏi prompt trau chuốt. Bạn đổi ý giữa chừng. Bạn nói, "Thực ra, không, tôi không muốn điều đó."
Việc đổi ý cho thấy bạn không muốn gì. Một sự lạc đề có thể tiết lộ một ràng buộc ẩn. Suy nghĩ thành tiếng giúp cả bạn và Codex hiểu được nhiệm vụ.
Với tính năng đọc chính tả bằng giọng nói, bạn nhấn micro, nói ra bản tóm tắt, kiểm tra bản ghi lại và gửi nó.
Nếu có trong thiết lập của bạn, Chế độ Voice còn tiến xa hơn. Bạn có thể theo dõi, ngắt lời, thay đổi hướng đi hoặc bắt đầu một luồng suy nghĩ mới. Bạn cũng có thể sử dụng nó để phối hợp công việc: bắt đầu một tác vụ khác, kiểm tra một tác vụ hiện có, hỏi xem có gì bị chặn hay định hướng công việc đang chạy.
Thành thật mà nói: nói chuyện với máy tính vẫn còn hơi kỳ lạ. Ở văn phòng, tôi cầm một chiếc micro DJI trong tay. Tai nghe có micro cũng hiệu quả.
Nhưng nó tốt hơn là để một ý tưởng hay mắc kẹt trong đầu bạn chỉ vì bạn chưa tìm ra cách hoàn hảo để viết nó ra.
Hãy hỏi những câu hỏi ngớ ngẩn
Có một phiên bản meme quen thuộc về điều này:
"Codex, làm cho tôi một công ty B2B SaaS trị giá một tỷ đô la. Đừng sai sót. Làm ngay một lần."
Bạn sẽ không thể tạo ra một công ty tỷ đô chỉ trong một lần. Nhưng cuộc trò chuyện có thể tiết lộ điều gì đó thực tế: một vấn đề bạn hiểu, một người đang gặp vấn đề đó và một bước đầu tiên đáng để thực hiện. Đó là cách giải quyết vấn đề cổ điển tốt đẹp: chia một vấn đề phức tạp thành các bước nhỏ hơn, có thể đạt được.
Giá trị nằm ở chính cuộc trò chuyện. Nó có thể đưa bạn từ một câu hỏi ngớ ngẩn đến một thứ bạn thực sự có thể triển khai ngay hôm nay.
Một vài cách thực tế để bắt đầu
Nếu ý tưởng vẫn còn mơ hồ, hãy yêu cầu Codex phỏng vấn bạn:
"Tôi vẫn đang tìm hiểu vấn đề này. Hãy hỏi tôi từng câu một. Hãy chất vấn bất cứ điều gì mơ hồ, sau đó giúp tôi biến nó thành một thứ cụ thể."
Hoặc hãy thật trực tiếp:
- Điểm mù của tôi là gì?
- Điều gì sẽ khiến việc này thất bại?
- Tôi đang suy nghĩ quá nhiều về điều gì?
- Phiên bản nhỏ nhất hữu ích là gì?
- Bạn cần biết điều gì trước khi có thể bắt đầu?
Chế độ Plan của Codex rất hữu ích khi bạn muốn có cấu trúc hơn. Nó có thể đặt các câu hỏi làm rõ, đưa ra các lựa chọn và giải quyết một cách tiếp cận trước khi thực hiện.
Nhưng tôi không nghĩ mọi ý tưởng đều cần bắt đầu từ đó. Đôi khi một cuộc trò chuyện cởi mở sẽ trôi chảy hơn. Chúng ta không chia mọi cuộc trò chuyện với đồng nghiệp thành lập kế hoạch và thực thi. Hãy nói chuyện trước. Để hình dạng của vấn đề xuất hiện. Chuyển sang một kế hoạch khi công việc cần một kế hoạch.
Hãy hỏi Codex về Codex
Có một ý nghĩa thứ hai của "nói chuyện với Codex": hãy hỏi nó những câu hỏi về chính nó.
Hãy hỏi nó có thể thấy gì. Hỏi chế độ nào phù hợp. Hỏi những công cụ nào có sẵn. Hỏi nó dự định xác minh công việc của mình như thế nào.
Nếu kỹ năng OpenAI Docs có sẵn, hãy yêu cầu Codex kiểm tra tài liệu. Bạn cũng có thể xem xét kho lưu trữ Codex công khai, hoặc sao chép nó và yêu cầu Codex giải thích cách nó hoạt động.
Nếu Codex làm sai, hãy hỏi tại sao
"Bạn đã làm điều này, nhưng tôi thực sự muốn điều kia. Chúng ta đã sai ở đâu?"
Có thể yêu cầu của bạn đã mơ hồ. Có thể một tệp AGENTS.md hoặc kỹ năng nào đó đã kéo công việc theo một hướng khác. Có thể một plugin, quyền hoặc công cụ không có sẵn. Có thể Codex đã đưa ra một giả định sai.
Hãy hỏi nó đã hiểu gì, nó đã làm theo hướng dẫn nào, cái gì đã thất bại và bạn có thể làm rõ điều gì hơn. Codex thường có thể sử dụng ngữ cảnh vẫn còn có sẵn để giúp kiểm tra lại sự cộng tác.
Nếu có thể, bạn có thể mở một cuộc trò chuyện phụ với /side trong khi Codex đang chạy, mà không làm gián đoạn cuộc trò chuyện chính. Hãy hỏi xem việc gì đã xong, việc gì còn lại, việc gì bị chặn và bạn có thể giúp gì. Về cơ bản, bạn là người quản lý của nó trong cuộc họp standup.
Nếu bạn muốn một điều gì đó được giải thích bằng tiếng Việt đơn giản, hãy chọn văn bản trong bản ghi lại và chọn "Hỏi trong cuộc trò chuyện phụ."
Đưa ý tưởng ra khỏi đầu bạn
Trong một chuyến đi đường, tôi bắt đầu nói chuyện với Codex về một bài thuyết trình. Điều đó đã trở thành cấu trúc cho bài nói chuyện và bài viết này. Tôi đã nói ra ý tưởng sơ bộ, đổi ý vài lần và tiếp tục.
Thường thì rào cản lớn nhất không phải là mô hình. Mà là chúng ta. Chúng ta nghĩ ý tưởng chưa sẵn sàng. Chúng ta không biết prompt phù hợp. Chúng ta lo lắng rằng mình đã giải thích chưa đúng cách.
Giao diện sẽ ngày càng tốt hơn. Và nếu bạn có ý tưởng về việc nói chuyện với Codex nên như thế nào, tôi thực sự rất muốn nghe chúng.
Chỉ cần hỏi Codex.
