Cách sử dụng Các quy trình làm việc động của Claude để nghiên cứu sâu

Trong ba năm qua, tôi đã không thể thiếu việc sử dụng AI để hỗ trợ nghiên cứu ngành, đồng thời còn xây dựng một loạt kỹ năng và hệ thống hỗ trợ để giải quyết việc sàng lọc, tổng hợp, liên kết, xác minh và lưu trữ thông tin.

Cho đến khi trải nghiệm sâu rộng vào luồng làm việc động của Claude Code trong tuần này, tôi mới hiểu được ý nghĩa thực sự của câu nói: "Con người đừng chống lại thời đại lớn".

Hãy suy nghĩ lại: Trong thời đại AI, con người nên thực hiện những nghiên cứu sâu nào, và làm thế nào để xây dựng mối quan hệ hợp tác bổ sung giữa tôi và AI.

Việc thực hiện nghiên cứu kỹ thuật thực sự đầy rẫy bẫy (dù là với con người hay AI), bởi vì ngay từ đầu nghiên cứu, bạn sẽ tiếp nhận một lượng lớn thông tin, các quan điểm ngày càng nhiều và kết luận ngày càng mờ nhạt. Vì vậy, hãy luôn nhớ quay trở lại mục tiêu ban đầu.

Đây cũng là điểm mà AI chưa thực sự xuất sắc, bởi vì từ góc độ chú ý và liên tưởng, nó sẽ dễ bị ràng buộc hơn con người bởi lượng thông tin hiện tại, đồng thời khả năng liên tưởng xuyên ngành thực sự có giá trị lại rất yếu.

Điểm mạnh của AI chính là khả năng thực thi, nó sẽ tìm kiếm, tổng hợp và tổng kết từng lớp theo dạng agent, hoàn toàn tránh được sự hao hụt chi tiết.

Mặc dù nửa năm qua tôi chưa đăng nhiều bài trên nền tảng công chúng, nhưng tôi đã theo dõi và nghiên cứu toàn diện tất cả các战场 chính trong ngành, và nền tảng cho việc tiếp nhận và xuất ra thông tin này là một hệ thống deep-research riêng của tôi.

Trong khi đó, khi thấy Claude Code vừa ra mắt tính năng Dynamic Workflows vào tuần trước, tôi muốn thử thách lẫn nhau xem khả năng mặc định của anh ấy có thể hoàn toàn vượt trội hơn tôi không.

Dynamic Workflows (động học) có ý tưởng cốt lõi là: trước khi thực hiện nhiệm vụ, AI sẽ tự động thiết kế workflow nào nên được sử dụng để hoàn thành nhiệm vụ đó, sau đó mới khởi động thực thi.

Điều này có sự khác biệt bản chất so với “chế độ lập kế hoạch” và “skill” mà chúng ta từng sử dụng. Chế độ lập kế hoạch chia nhỏ nhiệm vụ chi tiết hơn, nhưng không nhất thiết tuân theo luồng công việc hợp lý; chỉ khi bạn sắp xếp các prompt, bạn mới có thể thêm các chỉ số验收 (điều cực kỳ quan trọng đối với Research). Tương tự, bạn chỉ khi có prompt, nó mới có thể dự đoán tốt hơn một số quy tắc harness.

Tuy nhiên, luồng làm việc động sẽ tự động tích hợp các yếu tố như logic chấp nhận, hội tụ kết quả và xác minh đối kháng.

Cách kích hoạt rất đơn giản: chỉ cần sử dụng /deep-research trực tiếp trong cc, sau đó cung cấp một số mẫu nghiên cứu và tài liệu đầu vào. Nếu muốn sử dụng riêng khả năng của luồng làm việc động, hãy dùng từ khóa gợi ý hoặc nói trực tiếp là ultracode. Lưu ý trước khi sử dụng: lượng token tiêu thụ khoảng gấp chục lần bình thường.

Bên dưới luồng làm việc động là sáu mô hình lập lịch cốt lõi do chính thức tổng hợp, đây là lý do tại sao nó mạnh hơn các cuộc hội thoại/agent/skill thông thường.

Thực ra, đằng sau sáu chế độ này chỉ có hai vấn đề cốt lõi: làm thế nào để chia nhỏ nhiệm vụ? Và làm thế nào để tổng hợp kết quả? Việc tách ra thành sáu loại bản chất là sự sắp xếp và tổ hợp của hai yếu tố này.

3.1 Chế độ định tuyến (Classify-And-Act)

Trước tiên, một agent sẽ xác định loại nhiệm vụ, sau đó phân phối nhiệm vụ cho agent chuyên biệt phù hợp nhất để thực hiện. Logic cốt lõi là logic chọn tuyến đường, chứ không phải song song hoặc lặp lại. Một nhiệm vụ chỉ đi theo một con đường duy nhất, các con đường khác hoàn toàn không được thực thi.

Ví dụ, tôi có thể bắt đầu với ba vai trò subagent được định sẵn: một agent phân tích nghiêm ngặt xác minh dữ liệu, một agent xuất bản giỏi về viết lách, và một agent chuyên tìm lỗ hổng. Lớp định tuyến sẽ xác định nhiệm vụ con hiện tại phù hợp để giao cho ai, thay vì giao toàn bộ cho một agent.

Giá trị của mô hình này nằm ở sự chính xác và tiết kiệm: các lời nhắc cho từng agent có thể hoàn toàn độc lập, không bị các mục tiêu khác can thiệp, tạo ra sự khám phá sâu sắc theo chiều dọc. Chi phí token thấp nhất và tốc độ phản hồi nhanh nhất. Biên giới trách nhiệm rất rõ ràng.

Nhược điểm cũng rất rõ ràng, khả năng xử lý các nhiệm vụ có ranh giới mơ hồ (ví dụ: "vừa là vấn đề kỹ thuật vừa là vấn đề tài khoản") yếu.

3.2 Split & Merge

Đây cũng là mô hình tôi sử dụng nhiều nhất, logic cốt lõi là song song + hợp nhất. Chia nhiệm vụ thành N nhiệm vụ con độc lập chạy đồng thời, sau đó hợp nhất tất cả khi hoàn thành.

Ưu điểm nằm ở tốc độ và sự cô lập. Tổng thời gian tiêu tốn khoảng bằng nhiệm vụ con chậm nhất, chứ không phải tổng của tất cả các nhiệm vụ con. Mỗi nhiệm vụ con có context riêng biệt, không ảnh hưởng lẫn nhau và không bị nhiễu từ một nhiệm vụ con nào làm ô nhiễm các nhiệm vụ còn lại.

Điểm yếu là chi phí token là N lần tuần tự, bản thân lớp tổng hợp (Synthesize) cũng có độ khó — việc kết hợp đầu ra với cấu trúc không đồng nhất theo N hướng là một thách thức thiết kế. Việc chia nhỏ nhiệm vụ không tốt có thể dẫn đến bỏ sót hoặc phủ trùng lặp.

3.3 Xác minh đối kháng (Adversarial Verification)

Logic cốt lõi là kiểm tra: đối với cùng một kết luận, nhiều agent sẽ thách thức từ góc độ "phản bác", và chỉ khi có hơn một nửa số phiếu mới được thông qua.

Ưu điểm là do Verifier không biết suy nghĩ của Worker, chỉ xem kết quả, nên về mặt cấu trúc đã loại bỏ sự thiên lệch tự đánh giá khi để mô hình kiểm tra mã do chính nó viết.

Mô hình này đã giải quyết một vấn đề khiến tôi bận tâm lâu nay: chúng ta thường nói chuyện với AI theo cách nói chuyện thông thường, nhưng AI có xu hướng trả lời theo kỳ vọng của bạn, dễ dẫn đến "thiên kiến xác nhận". Việc kiểm chứng đối kháng buộc AI phải tìm kiếm các ví dụ phản chứng, dựa trên dữ liệu và thí nghiệm để xác minh, thay vì迎合 ý tưởng của bạn.

Tuy nhiên, để xác minh điều này, nếu anh ta đưa ra phán đoán sai, sẽ dẫn dắt Worker đi theo hướng phù hợp với Verifier. Do đó, ưu tiên nên dựa trên các sự kiện có thể lặp lại, chứ không phải dựa vào quan điểm.

Nói đùa một chút, nếu bạn để AI tìm lỗi, nó có thể tìm ra vô số vấn đề, vì vậy bạn cần giới hạn phạm vi mà nó tìm kiếm lỗi.

3.4 Tạo và lọc (Generate & Filter)

Logic cốt lõi là phân tán rồi hội tụ. Trước tiên, chủ động tạo ra một lượng lớn ứng cử viên, sau đó loại bỏ bằng rubric để giữ lại những điểm tinh hoa, chỉ xuất ra các kết quả có độ tin cậy cao.

Thay vì để một agent đưa ra câu trả lời “cũng được”, tốt hơn hết là cho nó tạo ra mười câu trả lời, sau đó dùng lớp xác minh để lọc. Vì vậy, lợi thế nằm ở tính đa dạng. Nhiều bộ tạo có thể sử dụng các chiến lược khác nhau, các lời nhắc khác nhau để tạo ra những giải pháp mà con người khó có thể tưởng tượng, bước lọc giúp chất lượng đầu ra cuối cùng được tập trung cao độ.

Nhược điểm là chất lượng rubric của Filter trực tiếp quyết định hiệu quả cuối cùng; nếu thiết kế rubric sai, toàn bộ quy trình sẽ bị hủy bỏ.

Các tình huống phù hợp là khi không biết trước câu trả lời đúng, cần lựa chọn tối ưu từ nhiều khả năng, và có yêu cầu rõ ràng về tính đa dạng.

Chỉ giống bề ngoài với Fanout-And-Synthesize: cả hai đều là "đa luồng song song → một đầu ra", dễ gây nhầm lẫn nhất.

Sự khác biệt chính nằm ở mục đích: Mỗi nhánh của Fanout xử lý một phần khác nhau của nhiệm vụ, kết quả là bổ sung cho nhau, và khi hợp nhất, tất cả các nhánh đều đóng góp; trong khi mỗi nhánh của Generate-And-Filter xử lý cùng một nhiệm vụ, kết quả là cạnh tranh với nhau, và khi hợp nhất, phần lớn sẽ bị loại bỏ.前者是"拼图"，后者是"选美"。

3.5 Chế độ giải đấu (Tournament)

Logic cốt lõi là cạnh tranh và loại bỏ. N agent độc lập thực hiện cùng một nhiệm vụ, loại bỏ từng vòng thông qua so sánh từng cặp, cuối cùng chọn ra giải pháp tối ưu.

Tôi từng tự làm điều này trước đây — chạy hai hoặc ba phiên bản cùng một thay đổi mã, sau đó để AI so sánh phiên bản nào tốt hơn. Bây giờ có thể trực tiếp tích hợp vào quy trình làm việc.

Ưu điểm nằm ở độ ổn định trong đánh giá. So sánh từng cặp ("A và B cái nào tốt hơn?") ổn định hơn nhiều so với đánh giá tuyệt đối ("cho điểm A"), vì loại bỏ được vấn đề lệch chuẩn đánh giá. Kết quả sau nhiều vòng cạnh tranh, người chiến thắng cuối cùng có độ tin cậy cao.

Cũng giống với Generate-And-Filter: cả hai đều chọn ra lựa chọn tối ưu từ nhiều ứng cử viên. Sự khác biệt chính nằm ở cơ chế lựa chọn: Tournament sử dụng pairwise judge để so sánh từng cặp, tức là "để các ứng cử viên cạnh tranh với nhau". Khi tiêu chí đánh giá khó đo lường và việc phán xét bản chất là tương đối, phương pháp này sẽ đáng tin cậy hơn.

3.6 Chế độ vòng lặp (Loop)

Logic cốt lõi là lặp lại thích ứng, liên tục thử nghiệm, khi gặp trở ngại thì thu thập thông tin lỗi, bổ sung ngữ cảnh và thử lại cho đến khi đáp ứng điều kiện chấp nhận.

Về bản chất, đây là việc đối抗 tính ngẫu nhiên của AI: thử nhiều lần, cuối cùng sẽ gặp được kết quả tốt hơn. Nhưng cách tiếp cận chín chắn hơn là kết hợp xác minh đối kháng, để mỗi vòng lặp đều thực thi với nhiều thông tin hơn, thay vì chỉ dựa vào ngẫu nhiên.

Ưu điểm nằm ở khả năng xử lý các nhiệm vụ có khối lượng công việc chưa xác định. Năm chế độ khác đều giả định rằng ranh giới nhiệm vụ là xác định, trong khi Loop Until Done là chế độ duy nhất có thể xử lý trường hợp "không biết phải thực hiện bao nhiêu vòng".

Điểm yếu là rủi ro mất kiểm soát tiềm ẩn—thiết kế điều kiện dừng không tốt có thể dẫn đến vòng lặp vô hạn. Mỗi vòng agent là một ngữ cảnh hoàn toàn mới, không thể tích lũy trạng thái qua các vòng (trừ khi được ghi rõ vào tệp).

Trước khi quy trình làm việc động được ra mắt, tôi đã thiết kế riêng một bộ deep-research của mình. Logic của bộ kỹ năng đó khoảng như thế này:

1. Chỉ cung cấp một thông tin đơn giản (ví dụ: một dự án vừa ra mắt tính năng mới)
2. Để AI tìm kiếm tất cả tài liệu liên quan: tài liệu chính thức, mã nguồn, dư luận thị trường
3. Nén thông tin thành tóm tắt có ý nghĩa
4. Nhiều vai trò agent thực hiện phân tích đối kháng, tạo báo cáo
5. Tự động loại bỏ trùng lặp do tỷ lệ lặp lại nội dung của nhiều agent rất cao

Đã sử dụng một thời gian, tôi thấy nó khá dễ dùng. Nhưng nó có một khuyết điểm cơ bản: thiếu sự hội tụ hướng đến mục tiêu.

Và rất nhiều khi, ngay cả khi có bước thứ năm để loại bỏ trùng lặp, anh ta thường xóa đi những thông tin có giá trị; nếu không loại bỏ trùng lặp, lại rất dễ khiến skill gửi cho bạn một bài viết dài hàng vạn chữ, thông tin đầy đủ nhưng không trực tiếp nói với bạn "việc này liên quan gì đến bạn, bạn nên làm gì".

Tuy nhiên, nghiên cứu là để phục vụ cho “quyết định”, đó là lý do tại sao nhiều kỹ năng chỉ dừng lại ở mức nghiên cứu, đạt 80 điểm nhưng thiếu 20 điểm quan trọng nhất.

Do đó, sau khi AI hoàn thành sơ bộ nghiên cứu, nó vẫn cần tiếp tục mười lần suy nghĩ và đối thoại để đạt được kết luận toàn diện và hài lòng.

Official dynamic workflow did what else

Qua các thí nghiệm với vài nhiệm vụ nghiên cứu phức tạp trong tuần này, tôi nhận thấy, luồng làm việc deep research được tích hợp sẵn trong Claude Code (lưu ý không chỉ là skill, mà là các mô-đun được biên dịch nhúng vào cc), so với các skill do tôi tự xây dựng, đã bổ sung thêm một vài giai đoạn then chốt:

• Lớp phân tích câu hỏi: Nó không bắt đầu tìm kiếm ngay mà trước tiên sẽ đặt câu hỏi, chia vấn đề của tôi thành nhiều câu hỏi con: Bạn thực sự muốn làm rõ điều gì? Sự việc này liên quan gì đến bạn? Những khía cạnh nào đáng để đào sâu? Trước đây tôi đã bỏ qua bước này.
• Đánh giá độ tin cậy: Đánh giá tính có thể phủ định của từng thông tin, tương tự như điểm uy tín trong SEO truyền thống—nguồn có đáng tin không? Số lần trích dẫn là bao nhiêu? Đây là bước mà tôi trước đây chưa từng nghĩ đến việc thêm vào.
• Xóa chéo thay vì gộp trung bình: Trước đây, tôi chọn trung bình tất cả các kết luận, nên tài liệu rất dài. Luồng làm việc động sẽ thực hiện bỏ phiếu đa tác nhân cho từng kết luận và xóa những kết luận không đủ phiếu, chứ không đơn giản là gộp lại.
• Đầu ra hướng đến mục tiêu: Báo cáo cuối cùng không phải là sự tích lũy thông tin, mà là đưa ra phán đoán và giải pháp đề xuất xung quanh mục tiêu ban đầu của bạn. Chìa khóa để đạt được điều này nằm ở việc tận dụng các khả năng được thiết lập sẵn của nhiều agent con. Trước đây, lý do khiến kỹ năng của tôi dễ thiếu hướng đến mục tiêu cuối cùng là do sự suy giảm trọng số lệnh sau khi xử lý lượng thông tin khổng lồ.

These mechanisms solve what problems?

Đây là những vấn đề điển hình khi AI thực hiện các nhiệm vụ dài:

Sự trôi dạt mục tiêu: Lúc bắt đầu nhiệm vụ, trạng thái tốt, nhưng đến giữa chừng thì không còn biết mình đang làm gì, đến cuối mới lại tìm lại được nhịp độ—giống như con người bị phân tâm trong lớp học. Nhiệm vụ càng dài, hiện tượng này càng rõ rệt.

Dừng quá sớm: Đang chạy thì gặp khó khăn, AI cho rằng mình "đã hoàn thành" nên dừng lại, nhưng thực tế tiêu chuẩn nghiệm thu chưa đạt.

Ô nhiễm ngữ cảnh: Khi một agent đơn lẻ thực hiện nhiệm vụ phức tạp, các prompt tiền nhiệm lớn sẽ làm giảm không gian thực thi sau này. Cách tốt hơn là giới hạn các prompt tiền nhiệm dưới vài k, và sử dụng nhiều agent để chia sẻ ngữ cảnh.

Xu hướng đầu ra: AI có xu hướng trả lời theo kỳ vọng của bạn, các câu hỏi mang tính khẩu ngữ dễ kích hoạt vấn đề này.

Còn luồng làm việc động giải quyết bốn vấn đề này theo cách có cấu trúc: tự động thêm chỉ số chấp nhận để ngăn dừng sớm; song song cô lập ngữ cảnh; đối kháng xác minh để giảm thiên lệch đầu ra; phân tách vấn đề thành từng cấp độ ràng buộc, khiến AI hiểu mục tiêu trước khi hành động.

Cuối cùng, với tư cách là một nhà nghiên cứu lâu năm, tôi vô cùng ấn tượng với cơ chế mới CC này, với sáu chế độ tích hợp — lựa chọn định tuyến, chia tách và hợp nhất, xác thực đối kháng, lọc sinh ra, thi đấu cạnh tranh, và vòng lặp Loop — bao quát hầu hết nhu cầu lập lịch cho các nhiệm vụ nghiên cứu phức tạp.

Tôi không còn cần thiết kế thủ công việc lập lịch agent, cũng không cần tự thực hiện loại bỏ trùng lặp và xác minh chéo, vì những việc này đã được tích hợp vào chính luồng công việc.

Và anh ấy đặc biệt phù hợp để suy nghĩ trong các tình huống thiếu thông tin và khám phá các câu hỏi mở, vì việc lập lịch đa agent tự nhiên cùng việc chia nhỏ mục tiêu nhiệm vụ đã giúp anh ấy nâng cao thêm tính tổng quát. Thực tế, ngay từ 3 năm trước, AI đã làm rất tốt trong việc giải quyết các vấn đề nhỏ và cực kỳ rõ ràng dưới các ràng buộc层层. Tuy nhiên, sự thay đổi chất lượng thực sự của AI nằm ở tính tổng quát — chính điểm này đã giúp nó vượt lên các đối thủ, từ việc chỉ đơn thuần viết mã đến thực sự trở thành một Agent, từ việc cố định giải quyết một vấn đề sang thích nghi với bất kỳ vấn đề nào.

Vì vậy, Dynamic Workflows không phải là "cuộc hội thoại đơn lẻ thông minh hơn", mà là cấu trúc hóa chính quy trình nghiên cứu.

Trước đây tôi cần thực hiện mười lần cuộc khảo sát độc lập, bây giờ đã được rút gọn còn 3-4 lần. Mặc dù lượng Token tiêu thụ tương ứng đã tăng lên gấp chục lần.

Vậy tại sao vẫn cần 3-4 lần nữa? Tôi cho rằng nguyên nhân cốt lõi nằm ở sự khác biệt của các yêu cầu này.

Đầu tiên là mức độ khắt khe của cơ chế xác minh; tôi chủ yếu nghiên cứu các công nghệ mới trên blockchain, nhiều thứ tài liệu chính thức đều đã lỗi thời, có những mã nguồn mở đáng để tham khảo hơn, cùng các dữ liệu như giao dịch trên chuỗi, nhưng hiện tại AI vẫn mặc định lấy tài liệu chính thức làm chuẩn, chứ không phải dựa trên xác minh thực tế.

Thứ hai là suy nghĩ sâu sắc hoàn toàn vượt ranh giới, điểm này dù có thể giải quyết một phần thông qua các workflow được thiết lập sẵn (định nghĩa trước các subAgent ở nhiều chiều khác nhau) để suy nghĩ về cùng một vấn đề, nhưng AI vẫn mạnh hơn ở các mô hình suy nghĩ phổ biến, còn với những vấn đề cực kỳ mới mẻ, cực kỳ sâu sắc và thiếu cơ sở dữ liệu thì lại hơi hạn chế.

Thứ ba là thiết kế và xác minh giải pháp, ý nghĩa của giải pháp không nằm ở việc đưa ra mà ở việc xác minh và hỗ trợ, nó dựa trên việc đánh giá các cơ chế hiện có, đầu tư và chi phí. Nếu điều chỉnh AI một cách hiệu quả, tất nhiên có thể làm tốt hơn, nhưng điều này lại đi ngược lại tính phổ quát.

Cuối cùng là sự cô đọng thông tin tối đa, điều này đòi hỏi bạn phải hiểu rõ mức độ am hiểu của đối tượng tiếp nhận thông tin: một số người không có nền tảng gì, cần bạn diễn đạt bằng hình ảnh nhân hóa; trong khi một số khán giả khác lại cần bạn chỉ cần một câu để chinh phục họ~.