Research Dossier — Vibe-Coding a Case File, Then Teaching It to Hold Its Own Workflow
说明与用途
使用 Next.js 构建的双面板应用程序,具有基于 Sanity 的审批工作流,主要通过提示和迭代调试完成。
问题
Build a Next.js app with a custom two‑pane interface and a real Sanity‑backed approval workflow, while avoiding common pitfalls such as node name collisions, model availability issues, and auth errors.
结果
The app now supports a full approval workflow stored in Sanity, with status transitions visible in both the web UI and Sanity Studio. The build process highlighted common pitfalls and required iterative debugging.
工作流
- 1. Define three core document types (
topic,source,claim) and a newcaseReporttype with fieldsquestion,draftText,finalText,status,createdAt,approvedAt. - 2. Create a write‑scoped Sanity client separate from the read‑only client used for research queries.
- 3. Implement an API route that writes a new
caseReportwithstatus: "draft"when the agent finishes drafting. - 4. Implement a second API route that patches the same document to
status: "approved", setsfinalText, and recordsapprovedAtwhen a human approves. - 5. Update the UI to display the draft log, the report pane, and an approve button that triggers the approval API.
- 6. Deploy to Vercel, ensuring
next.config.jsdoes not force static export and that peer dependencies are resolved with--legacy-peer-deps. - 7. Test the workflow by asking a question, reviewing the draft, approving, and verifying the status change in both the app and Sanity Studio.
证据
The system now models its own approval workflow as real Sanity content, not just UI state.
Three document types: topic, source, claim (the Path One side), plus caseReport for this path — question, draftText, finalText, status, createdAt, approvedAt.
The workflow itself is two writes against one document: the research/writing/review pipeline creates it with status: "draft", and a human approving (or editing, then approving) in the UI patches the same document to status: "approved" with the final text and a timestamp.
- 记录日期: 2026-10-03T18:40:56.028Z