name: policy-lab description: Workflow nghiên cứu chính sách và kinh tế vĩ mô cho Việt Nam và các nước đối sánh, dùng khi cần phân tích mục tiêu chính sách, thiết kế hệ thống, dữ liệu quốc gia, hoặc hàm ý chính sách đến 2030. category: research
Dùng skill này cho các đề tài chính sách công, kinh tế vĩ mô, hệ thống dữ liệu quốc gia, so sánh quốc tế, và các câu hỏi kiểu: - Vì sao Việt Nam nên ưu tiên một mục tiêu chính sách nào đó? - Nên thiết kế hệ thống đo lường / hạ tầng dữ liệu / API quốc gia như thế nào? - Việt Nam đang ở đâu so với các nước đối sánh? - Hàm ý chính sách đến 2030 là gì?
Làm rõ: - Câu hỏi thật sự là gì? - Mục tiêu chính sách là gì? - Tại sao câu hỏi này quan trọng ở thời điểm hiện tại? - Nếu trả lời sai thì hệ quả là gì?
Xác định: - Vấn đề có đáng ưu tiên không? - Đâu là bottleneck hệ thống? - Dữ liệu nào có thể kiểm chứng? - Nhóm nước đối sánh nào phù hợp? - Phân tích theo góc nào: hiệu quả kinh tế, năng suất, quản trị, cạnh tranh, đo lường, thực thi?
Khi cần scan nhanh thông tin chính sách/ngành của nước ngoài (không có search tool):
1. Ưu tiên cổng chính thức — tìm trực tiếp site .gov.my, .go.id, .go.th v.v.
2. Dùng DuckDuckGo HTML (html.duckduckgo.com/html/?q=...) vì Google dễ trigger CAPTCHA.
3. Đọc tài liệu tham khảo references/tourism-benchmarking-phase2-template.md trước khi bắt đầu scan quốc gia — template chứa sẵn 5-section cấu trúc và các dimension cần cover.
4. Lấy snapshot structure — inspect navigation, top-level sections, và link graph của portal chính thức trước khi đi sâu vào nội dung cụ thể.
5. Ghi nhanh pitfalls vào references/<country>-phase2-scan-notes.md để hỗ trợ Phase 3 deep dive sau này.
Ưu tiên nguồn: - Văn bản chính sách, luật, nghị định, chiến lược quốc gia - Báo cáo chính phủ, tổng cục, bộ ngành - WB, IMF, OECD, ADB, UN, WEF, WTTC và nguồn tương đương - Nghiên cứu học thuật, working papers, case studies - Dữ liệu quốc gia và dữ liệu ngành
Kết quả cần trả lời rõ: - Vì sao Việt Nam nên ưu tiên vấn đề này? - Tác động nếu triển khai hoặc không triển khai? - Nên làm theo thứ tự nào? - Bài học nào từ nước đối sánh có thể áp dụng? - Hàm ý cho 2030 là gì?
Dùng 1 file duy nhất cho mỗi đề tài nghiên cứu.
RES_YYYYMMDD_ShortName.md
Ví dụ:
- RES_20260708_PolicyTourismASEAN.md
- RES_20260708_VietnamMacroDataAPI.md
Nếu cần tổ chức theo workspace nội bộ:
- Research_Inno/00_Templates/
- Research_Inno/01_Active/
- Research_Inno/02_Archived/
topic.md chuẩn---
type: research-topic
title: "{{TITLE}}"
alias:
- "{{ALIAS}}"
status: draft
scope: policy-lab
---
# {{TITLE}}
## Phase Log
- [ ] Phase 1: Đối chất câu hỏi
- [ ] Phase 2: Khung khả thi ban đầu
- [ ] Phase 3: Chốt đề tài
- [ ] Phase 4: Nghiên cứu sâu
- [ ] Phase 5: Tổng hợp & lập luận chính sách
## 1) Câu hỏi nghiên cứu
- ...
## 2) Vì sao câu hỏi này quan trọng
- ...
## 3) Phạm vi
- Quốc gia / ngành / giai đoạn / đối sánh
## 4) Khung phân tích
- Policy cycle
- Stakeholder mapping
- Economic logic
- Comparative benchmark
- Implementation feasibility
## 5) Open Insights
> Ghi mọi phát hiện, dấu hiệu, giả thuyết, mâu thuẫn cần kiểm chứng.
- ...
## 6) Dữ liệu & bằng chứng
- Định lượng:
- Định tính:
- Nguồn chính sách:
- Nguồn quốc tế:
## 7) So sánh quốc tế
| Tiêu chí | Việt Nam | Nước A | Nước B | Nhận xét |
|---|---:|---:|---:|---|
| ... | ... | ... | ... | ... |
## 8) Lập luận chính sách
- ...
## 9) Hàm ý đến 2030
- ...
## 10) Fact-check
- [ ] Xác minh số liệu
- [ ] Xác minh hiệu lực văn bản
- [ ] Xác minh nguồn gốc dữ liệu
## 11) References
- ...
topic.md rồi mới chuyển phase tiếp theo.Luôn kết thúc bằng: - Kết luận ngắn gọn - 3–5 luận điểm chính - 3 rủi ro / phản biện lớn nhất - Gợi ý bước tiếp theo
Khi nạp và hệ thống hóa dữ liệu nghiên cứu chính sách/du lịch vĩ mô từ NotebookLM vào Brain chung (company_kb):
1. Thiết lập quyền kiểm soát (Manual Gate): Task ingest phải có tag [CEO-Approved] hoặc dựa trên lệnh direct từ CEO. Worker chỉ được phép List và Search, tuyệt đối không được tự ý Ingest hàng loạt.
2. Chỉ ingest khi được chỉ định rõ ràng: Ingest chỉ bắt đầu khi có Notebook cụ thể được chỉ định.
3. Quy trình Ingest NotebookLM chuẩn:
- Bước 1: List notebooks và sources (không tự ý ingest).
- Bước 2: Tóm tắt sơ lược mỗi source → File master cho notebook đó.
- Bước 3: Group, đặt tên, và tag (properties) cho các source.
- Bước 4: Chỉ sync vào company_kb khi được chỉ định rõ ràng.
4. Phân tách Rõ ràng: Tránh để các file thô (dữ liệu phân mảnh từ NotebookLM trong notebooklm_ingest/) làm ô nhiễm Đồ thị Tri thức (Knowledge Graph) hiển thị trên Dashboard. Các file thô này có thể lên tới hàng trăm file và làm chậm/rối đồ thị.
5. Quy hoạch vào knowledge/: Ingest dữ liệu thô vào các thư mục con có cấu trúc dưới company_kb/knowledge/ (ví dụ: knowledge/tourism/, knowledge/policy/).
6. Tiêu chuẩn tiền tố đặt tên file:
- Văn bản pháp quy: GOV_YYYY_Tên-văn-bản.md
- Báo cáo nghiên cứu vĩ mô: RP_YYYY_Tên-đề-tài.md
- Tin tức & Phân tích: NEW_YYYY_Tên-bài-viết.md
- Sách/Giáo trình: [books]_Tên-sách.md
7. Tạo Báo cáo Synthesis & Map: Đối với mỗi chủ đề lớn, xây dựng file synthesis.md and _index.md đóng vai trò là "cổng thông tin" (portal) đúc kết các điểm mấu chốt, có gắn wikilink [[knowledge/path/to/file|Tên hiển thị]] tới các bài viết chi tiết bên dưới.
8. Cập nhật Đồ thị Tri thức (kb_graph.py):
- Loại bỏ thư mục thô (như notebooklm_ingest/) khỏi hàm build của đồ thị.
- Nhóm các file dưới knowledge/ theo thư mục con cấp 2 của chúng (ví dụ: tourism, policy) để hiển thị màu sắc và cụm riêng biệt trên Dashboard đồ thị.
Tóm tắt: (tiếng Anh) và Tóm tắt (VN): (tiếng Việt) đã được cập nhật thành công và không bị lỗi hiển thị hay rỗng.blocked và gán cho CEO khi hoàn thành khâu deliver cuối cùng của file để làm cổng duyệt thủ công, tuyệt đối không tự ý chuyển task về done hoặc tự tạo thêm task sửa lỗi vụn vặt làm loãng bảng Kanban.stream=True khi gọi dịch thuật qua API local 9router trong Python để loại bỏ lỗi phân tách dữ liệu SSE không hoàn chỉnh. Dùng stream=False để nhận phản hồi JSON đồng bộ sạch và ổn định.(Giữ nguyên nội dung bên dưới)
| Lớp | Công cụ | Vai trò |
|---|---|---|
| Nguồn gốc | RES_YYYYMMDD_Name.md | AI đọc/ghi chi tiết, phase log, open insights, fact-check |
| Bản mirror đọc nhanh | Lark Doc | User đọc và follow up trực tiếp trên Lark |
| Tracker tiến độ | Lark Base / Research Tasks table | Project/task/phase status |
RES_...md, không đặt tên theo giai đoạn (vd "Phase 1 Framing") vì sẽ gây nhầm lẫn về vai trò..md, Base record status, và Doc mirror content.lark-cli auth statuslark-cli base +url-resolve --url "<url>" --as userlark-cli base +table-list --base-token <token>, lark-cli base +field-list --base-token <token> --table-id <id>lark-cli base +record-list --base-token <token> --table-id <id>lark-cli base +record-upsert --as user --base-token <token> --table-id <id> --record-id <id> --json '{...}'Khi thực hiện nghiên cứu đối sánh quốc tế (ví dụ: du lịch, đo lường dữ liệu giữa các quốc gia):
- Sử dụng cấu trúc rà soát sơ bộ (Phase 2 Scan) chuẩn hóa theo 5 trụ cột chính: Đơn vị quản lý, Chỉ chỉ tiêu đo lường chính (KPIs), Phương pháp thu thập dữ liệu, Công nghệ & Nền tảng hỗ trợ, và Dữ liệu tích hợp.
- Xem template mẫu chi tiết tại: references/tourism-benchmarking-phase2-template.md.
- Đảm bảo thiết lập cấu trúc thư mục đồng bộ giữa các nước đối sánh dưới thư mục cha projects/.
Lark CLI dùng split-flow để xin thêm scope:
- Bước 1 (turn hiện tại): lark-cli auth login --scope "<scope>" --no-wait --json → lấy device_code + verification_url → gửi URL cho user → kết thúc turn
- Bước 2 (turn tiếp sau khi user confirm "done"): lark-cli auth login --device-code <code> → kiểm tra kết quả
⚠️ Scopes thường cần xin từng bước riêng lẻ:
- docx:document:create — tạo doc mới
- docx:document:write_only — overwrite/update doc đã có
# Tạo từ file .md local (dùng @file tránh shell escaping)
lark-cli docs +create --as user --doc-format markdown --title "<TopicName>" --content @<relative_path>.md
# Update/overwrite doc đã có (cần scope write_only)
lark-cli docs +update --as user --doc <doc_id> --command overwrite --content @<relative_path>.md
@file chỉ chấp nhận relative path từ cwd; không dùng absolute path.<<'EOF') trong terminal() hay bị lỗi với ký tự & trong nội dung — dùng @file thay thế.& ký tự: terminal báo uses '&' backgrounding khi nội dung markdown có & → dùng write_file trước rồi @file.auth login thêm scope mới (không ghi đè); scope cũ vẫn còn.references/tourism-benchmarking-phase2-template.md có 5-section cấu trúc sẵn. Lưu scan notes vào references/<country>-phase2-scan-notes.md.references/lark-cli-binding.mdÁp dụng khi khởi tạo mới hoặc tái cấu trúc một Lark Base / research OS:
Dùng format:
- P0 - Project Setup & Scoping
- P1 - Problem Definition & Refinement
- P2 - Feasibility Assessment & Risk Analysis
- P3 - Scope Finalization & Topic Selection
- P4 - Evidence Gathering & Synthesis
- P5 - Analysis, Insights & Recommendations
Nguyên tắc: - Tên phase phải phản ánh trạng thái tư duy của workstream, không chỉ là mô tả chung chung. - Phase càng đầu càng phải tách rõ “định nghĩa vấn đề” với “đánh giá tính khả thi”. - Không dùng tên phase chỉ mang tính trình tự mà thiếu chức năng.
Dùng format:
- P2.1 - Evidence Inventory - Desk Research
- P2.2 - VN TSA Diagnostic - Data Analysis
- P2.3 - Benchmark Architecture Mapping - Comparative Research
- P2.4 - Feasibility Scoring - Policy Analysis
- P2.5 - Counter-Hypothesis Testing - Strategic Review
- P2.6 - Decision Memo - Policy Recommendation
Nguyên tắc:
- P#.X cho biết phase và thứ tự task con.
- Cụm giữa là động từ / hành động chính.
- Cụm cuối là vai trò / chuyên môn hoặc workstream.
- Task phải đủ rõ để nhìn là biết cần làm gì, review ở đâu, và output là gì.
Phase khả thi phải đi theo chuỗi logic sau: 1. Map nguồn bằng chứng — inventory nguồn, phân tầng độ tin cậy. 2. Chẩn đoán bottleneck — tách dữ liệu / thể chế / công nghệ / hành vi. 3. Đối chiếu chéo quốc gia — không chỉ hỏi có làm hay không, mà hỏi làm thế nào, ai vận hành, dùng để ra quyết định gì. 4. Đánh giá theo ma trận — legal, data availability, technical feasibility, organizational fit, cost/timeline, political acceptability. 5. Kiểm tra giả thuyết ngược — thử counter-hypothesis để tránh kết luận cảm tính. 6. Kết luận Go / Go-with-conditions / No-go — mỗi kết luận phải đi kèm bằng chứng và điều kiện thực thi.
Khi tạo Base mới cho một research project:
- Tạo phase trước, rồi mới tách task con.
- Mapping task theo phase cần bám định danh P#.X.
- Mỗi task nên có tối thiểu các trường: Task, Phase, Workstream, Status, Output, Evidence / Source, Notes, Priority.
- Nếu project có vòng lặp nghiên cứu, thêm một task cuối phase để “Decision memo / gate review”.
- Cập nhật status phải phản ánh thật: Backlog / Next / Doing / Waiting / Review / Done.
Khi user có tư duy IT BA hoặc quản lý dự án số hóa: - Ưu tiên cấu trúc rõ ràng, có gate, có output, có review point. - Không để research task quá “mềm” hoặc mơ hồ. - Tên phase/task phải đọc lên là biết ngay nó nằm ở đâu trong flow dự án.