01
INTAKE
接收用户已经知道的工作描述，不要求先写出完整 Prompt。
Loading...
V3 / activation unverified用户提供截图
事先想想 / AI-ready Work Intent
事先想想
面对不完整的工作描述，先确认真正改变结果的信息，再把用户意图整理成可直接交给 AI 的任务说明和检查点。
产品核心循环是 INTAKE → CLARIFY → CONFIRM → GENERATE → GUIDANCE → DONE；服务器拥有状态、权限、幂等和失败边界，模型只提交结构化提案。
V3 / PRODUCT FLOW
01先把现在要完成的工作说出来。
Frozen cohort
14 raw intents
Displayed questions
31 → 6
Observed rounds
18 → 5
Already-good direct confirm
5 / 5
Product Loop
先理解，再生成。
事先想想把 Prompt 之前的工作变成一个可确认的产品流程：用户不用先知道完整答案，但系统不能替用户编造关键事实。
02
CLARIFY
只追问会改变任务结果的关键信息，最多两轮，不自行补写关键事实。
03
CONFIRM
把系统理解的目标、交付物和边界展示出来，让用户在生成前修正。
04
GENERATE / GUIDANCE
输出任务说明与 2–4 项检查点，并保留可追踪事件和失败状态。
Review 01 → Review 02
少问一点，但不跳过确认。
同一组 14 条冻结原始意图重新运行后，记录澄清轮次、展示问题数量和分组结果。这里展示的是受控审查，不是泛化到所有用户的结论。
Vague / 4 cases
clarification rounds1.75 → 1
displayed questions3.25 → 1.25
3 / 4 success
Moderate / 5 cases
clarification rounds1.2 → 0.2
displayed questions2 → 0.2
5 / 5 success
Already-good / 5 cases
clarification rounds1 → 0
displayed questions1.6 → 0
5 / 5 direct CONFIRM
Question-level provisional audit：6 个已展示问题中，6 个有理由、0 个 questionable；pairwise downstream 的 strict-valid 样本只有 n = 2，整体仍为 INCONCLUSIVE。
Product Evidence
四个界面，四个状态。
以下截图来自用户提供的小程序材料，用于展示事先想想 V3 的任务录入、澄清、确认与输出路径。
截图版本的应用标题仍显示“知序”；网站项目名称已按最新产品命名更新为“事先想想”。
Trust Boundary
系统负责状态真相。
LLM 可以提出结构化建议，但状态转换、权限、幂等和失败归属由后端规则控制。
01
Review 02 的 strict-valid 下游 pairwise 只有 n = 2，整体结论为 INCONCLUSIVE。
02
小程序代码上传成功不等于已经公开激活；当前材料没有 physical-device smoke 证据。
03
截图用于证明当前产品流程与视觉状态，不证明开放用户规模、留存或泛化价值。
04
失败恢复、取消 / 返回控制、交付反馈和真实设备验证仍是后续边界。
V3 / Evidence-led Product
从一句话，到一份可执行任务。
当前可确认的公开入口是服务域名；小程序公开激活与真实设备验证仍未形成证据。