从产品 intent 到团队可以 review 的软件

一个简短产品想法通常包含期望结果，但省略了构建它所需的决策。它可能没有识别主要用户、启动工作流的时刻、必须持久化的数据，或证明 job 完成的状态。生成可以很快填补这些空白，但速度不会让推断出来的答案自动正确。

可 review 的 workflow 会保留 stated intent 和 generated interpretation 之间的区别。原始目标保持可见。假设以可检查选择的形式出现。这给团队一个稳定参照：当屏幕看起来 polish 却不再服务 job，或技术捷径悄悄改变产品本应做的事时，可以回到这个参照。

第一个有用版本和最终产品承担不同工作。它应该让产品方向具体到足以评估。真实屏幕暴露层级和语言。连起来的流程暴露缺失 transition 和 dead end。技术选择暴露这个想法在哪些地方依赖 authentication、stored data、external services 或 deployment decisions。

这就是把产品 intent 转成可工作的第一个版本，而不是静态承诺的价值。reviewer 可以回应同一个对象。他们可以指向感觉不对的确切状态，追踪还需要下一步的路径，并把产品问题和 polish 偏好分开。这个 artifact 成为 product、design 和 engineering 之间的共同语言。

有说服力的 happy path 不够。软件在状态明确时才变得可 review：首次使用、空数据、进行中的工作、完成、失败和回访。这些状态显示产品是否有连贯节奏，还是只有强开场屏。它们也暴露每一步需要的信息，以及一个 action 的后果。

技术边界也属于同一场 review。暗示账号的屏幕应该提出 authentication 问题。刷新后仍存在的列表暗示 persistence。触达另一个 service 的生成 action 暗示 permissions 和 error handling。让这些 implications 保持可见，可以防止 interface 承诺底层系统尚未定义的产品。

当所有类型的反馈同时到来，团队会失去清晰度。更有用的 review sequence 从 purpose 开始：这个版本是否服务预期用户和 outcome？然后再经过 workflow、information 和 technical feasibility，最后才把注意力放到 visual finish。这个顺序防止 polish 细节保护薄弱的产品方向。

每一层都应该以明确决策结束。保留方向，修订有边界的一部分，或停止并回到 intent。捕捉这个决策很重要，因为下一次 generated 或 manual pass 应该继承改动原因，而不只是请求的 surface edit。否则，迭代会变成一串局部合理、整体却丢失原始产品目标的改动。

产品 intent 应该随着 artifact 改变仍然可追踪。团队不需要沉重流程，但需要一条可见线索：目标、关键约束、当前 interpretation、未解决问题和已经做出的决策。这个 context 让后续 handoff 更精确，也帮助 AI-assisted workflow 修改正确的东西。

结果不是确定性，而是可控学习。可 review 的第一个版本让人发现 brief 说不出的东西，然后同时更新软件和他们对产品的理解。这就是一个想法如何变成可构建方向，而不假装第一个生成答案就是最终答案。