Week 3 · Build an MVP

01 · Where we are, and today

• • You have An idea and a GitHub repo From last week. Today we turn the idea into something real and grounded. Recap
  • Goal 1 Research your topic with AI Find what's known, judge the evidence, sharpen your question — this decides everything else. Search
  • Goal 2 Limit it to an MVP, and write its spec Let what you found decide the smallest version — then write it down as spec.md. Spec

02 · Show & tell — your HTML

First 30 minutes, 3 minutes each: open the page you made last week (your idea.html) and walk us through it — your idea’s first time in front of other people.

• • 3 min each Open your URL, pitch your idea Which social issue · game / site / tool · how it will collect feedback. Talk
  • ~30 min All 9 done, then we start today’s research A warm-up — and your last gut-check on who your thing is really for, before today’s work. Go

03 · Research your topic with AI

A strong project stands on what's already known. Use AI as a research partner — it's great at mapping a field, naming concepts, and suggesting where to look. Paste this:

打开我这个仓库里的 index.html,先读懂我想做的东西。然后当我的研究伙伴,顺着我的想法把这个议题查清楚 —— 背后有哪些值得了解的概念、研究、数据、真实案例和已有做法,我能切入的空白在哪。你觉得还该往哪些方向查,就主动带我去查。

04 · What counts as good evidence

AI points you to sources — but you decide which ones to trust. Not all evidence is equal. Lean on the top of this list, and always go read the real thing (Google Scholar, official sites), not just AI's summary:

• • Strongest Peer-reviewed studies Research in academic journals — checked by other experts before publishing. Cite
  • Strong Official data & big reports Government statistics, large surveys, reputable NGO or institute reports. Cite
  • Useful Quality journalism Good reporting points you somewhere — then check the source it's citing. Trace
  • Weakest Anecdotes & single posts One person's story is vivid and humanizing — but it's not proof on its own. Color

05 · Go wide — research in parallel

Both your tools can run subagents — several AI agents at once, each on its own angle, in its own fresh context. In Codex, type /agent (use read-only "explorer" agents); in Cursor, type /multitask. Then give them this:

帮我把这个议题查得更广 —— 开几个子代理并行去不同信源读东西(Codex 用 /agent,Cursor 用 /multitask)。分头去哪些信源(学术、新闻、真实案例、数据、已有的类似产品……)你来分工。

每个读完带回要点和来源,最后汇总给我,并标出哪些需要我核实。

我的议题:[填你的议题]

Why it's worth it: four angles at once, each in its own fresh context — a wide map in minutes instead of one slow, narrowing thread.

06 · Structure it & archive it to GitHub

Good research isn't a pile of links — it's structured and saved, so you and your AI can come back to it for weeks. Don't keep one messy note; build a small research archive in your repo:

• • summary.md What's known, in one page The field, the key facts, the gap — skimmable in 60 seconds. Map
  • sources.md Your sources as a synthesis matrix One row per source × theme · key finding · strength · verified — the backbone of your lit review. List
  • data/ The raw stuff worth keeping Statistics, quotes, screenshots, scraped files — the evidence itself. Raw
  • questions.md Open questions Where the project is headed, in writing. Ask

This is how a serious research repo works — the teacher's own gaokao-pro and kaogong-pro keep a docs/ of structured sources, coverage reports, and raw data, so the knowledge compounds instead of evaporating. Paste this to build yours:

把我们查到的东西整理成我仓库里的一个 research/ 文件夹 —— 这也是我论文的草稿:

research/sources.md   一张「文献表(synthesis matrix)」:每行一个来源,列出 来源(作者·年份·标题)| 主题 | 关键发现 / 可引用的话 | 证据强度 | 是否核实。按主题归类。
research/summary.md   一两段:这个议题已知什么、争论在哪、我能切入的空白。
research/data/         值得留存的原始材料(统计、引语、截图)。
research/questions.md  开放问题、以及你最想搞清楚的那个问题。

整理好后帮我 commit 并 push 到 GitHub。

07 · Limit it to an MVP

MVP = Minimum Viable Product — the smallest version of your idea that still makes your point. The job this week isn't to build it; it's to limit it, so the thing you make later never feels huge or scary. This is your product’s MVP — the interactive site / tool you’ll build, not your paper.

• • One thing Keep the single core thing it must do If it did only this, would it still make your point? That's your MVP. Core
  • Park the rest Everything else goes on a "later" list Not deleted — parked. You get to it only if the core proves itself. Later
  • Go smaller It should feel almost too small If cutting it feels comfortable, you haven't cut enough yet. Small
  • Not this week You're defining it, not building it Today's goal is a clear, tiny target — written down. Building comes next week. Define

08 · Cut it down

Now let your research drive this. Most ideas are too big for eight weeks; the skill is cutting — and what you just found tells you which slice actually matters. Here's the shape of it — say your idea is "an app that fixes online misinformation":

• • The dream A platform that fact-checks every post for everyone Accounts, feeds, a browser extension, real-time AI checks… months of work. Too big
  • The MVP One page: paste a claim → get one AI-assisted check → rate if it helped One user, one flow, and it already collects feedback. Small enough to define today. Just right
  • Later Accounts · feeds · extension · real-time All real, all worthy — and all parked until the core proves itself. Park it

Now do yours — point the AI at your index.html and cut together:

打开我这个仓库里的 index.html(我上周做的想法页),读懂我的想法,然后帮我把它砍成一个 MVP —— 也就是我这个「交互式网站 / 作品」最小能做出来的版本(是产品本身,不是论文)。
1. 它必须做的「那一件」核心交互是什么?
2. 用户打开后,最短的一条使用流程是什么(3–5 步)?
3. 哪些功能先砍掉、进「以后再说」清单?
4. 这个最小版本怎么还能收集到用户反馈?

要狠,逼我砍到几乎太小。这周只定义、不搭建。

09 · Write your MVP spec — spec.md

Before anyone builds anything, you write a spec — a short, plain-language plan of what the MVP is. Write it in Markdown (just text: # makes a heading, - makes a bullet) in a file called spec.md in your repo. A good MVP spec answers five things:

• • What What it does — in one sentence If you can't say it in a line, it's still too big. Core
  • Who Who it's for The one specific user — not "everyone". User
  • Flow The core flow, start to finish The 3–5 steps a user takes. This is the whole MVP. Steps
  • Not in it Your "later" list What you're deliberately leaving out — so scope stays small. Later
  • Feedback How it collects feedback One question, one rating, or one logged choice. Data

Paste this to draft your spec.md:

帮我给我的 MVP 写一份 spec.md —— 一份简短的 Markdown 计划,不是代码。

我限定后的 MVP:[粘贴你上面收敛好的 MVP]

严格用下面这个结构,Markdown 的 # 标题:
# [项目名] — MVP Spec
## 它做什么    (一句话)
## 给谁用       (一个具体用户)
## 核心流程     (用户走的 3–5 步)
## 不在 MVP 里  (「以后再说」清单)
## 怎么收集反馈

保持简短朴素。然后帮我存成 spec.md 并 push 到我的仓库。

10 · Leave with

• • Homework 1 Your AI research, archived in GitHub The research/ folder: summary, sources, data, and your sharpened question. This week
  • Homework 2 spec.md — your MVP spec A short Markdown plan of the smallest version. No building yet — just the spec. This week
  • Homework 3 Sign up: Vercel · Supabase · Cloudflare You will deploy for real next week — register all three this week. (Logging in with GitHub is easiest.) Before W4
  • Book Wednesday office hour ~15 min each. Bring your research and your spec, and anything that blocked you. Wed

Submit your work to the course. In your project folder, paste this into Codex / Cursor and run it — it sends in your repo link automatically:

我要把我的项目提交给课程。请你:
1. 运行 git remote get-url origin,拿到我这个仓库的 GitHub 地址。
2. 用 curl 把我的名字和这个地址 POST 到 https://course.lawted.tech/api/submit ,JSON 格式:{"name":"我的名字","repo":"仓库地址"}。
我的名字是:[在这里填你的名字]
做完把返回结果给我看,确认提交成功。

11 · Before you go — class feedback

Two minutes, every class. Tell us what landed and what didn't — it directly shapes next week's class.