聊了半天需求，Agent 还是只做了一个 MVP

聊了半天需求，Agent 还是只做了一个 MVP

“先做一个 MVP，把注册主流程跑通。”

这句话交给 Agent，它很可能点头。准备开工时，让它把目标换成自己的话再说一遍，答案可能是：做一个能点击的注册页面，使用假数据，不接邮件，也不保存账号。

可你心里的 MVP 是另一回事：真实用户能注册、收到验证码、登录测试环境，只是不做第三方登录和找回密码。

两边都没有理解错“MVP”这个词。它本来就没说清楚停在哪一层。聊了二十分钟需求，如果最后不核一次终点，前面的讨论仍然可能各说各话。

“明白了”没有提供新信息

systematicls 的 Agentic Engineering 长文里举过一个很硬的对比。只说“做一个认证系统”，Agent 得自己研究认证是什么、有哪些选项、该用哪一种；如果任务已经确定 JWT、bcrypt-12、refresh token 轮换和 7 天过期，它才能把时间花在实现上。

现实里当然不可能每次都知道这么细。很多时候，我们正是要借 Agent 帮忙做选择。麻烦出在选择做完之后，研究和实现还混在同一个对话里：前面出现过的三个备选方案都留在上下文中，最后采用哪一个、交付到哪一步，只存在于人的印象里。

于是 Agent 说“明白了”，人也觉得自己说清楚了。这个“明白”没法检查。

让它复述的作用，是逼双方产生一份很短、能核对的共同版本。复述里只需要四件事：交付物、完成深度、明确不做的部分，以及完成后拿什么验。

有用的复述跟润色是两回事。它要暴露深度和边界。

复述不能照抄原话

如果要求只是“重复一遍需求”，Agent 会把对话压缩成一段更顺的文字，原来的歧义还在。

拿注册 MVP 来说，有用的复述应该长这样：

本次交付一条可在测试环境真实使用的邮箱注册流程。验证码通过现有邮件服务发送，账号写入当前用户表，注册后可以登录。不做第三方登录、找回密码和正式环境发布。完成时提供测试结果，并实际走一遍注册和登录。

这段话没有什么高明技巧，但它把“跑通”从一句感受变成了一个位置。假数据还是实际入库，原型还是测试环境可用，做不做邮件，扫一眼就能确认。

如果项目里已经有一批旧账号，还会多出一个很现实的问题：这次只保证新用户能注册，还是旧用户也要迁移到同一套认证逻辑？Agent 若在复述里写“仅处理新注册，不迁移现有账号”，人就能当场确认；等数据库改完才发现双方理解不同，代价已经不在一个数量级。

另一个方向也一样。你只想验证页面，如果 Agent 复述里出现数据库迁移、埋点和管理后台，马上删掉。很多范围膨胀并非做到一半才发生，第一份计划里就已经写着，只是没人让它把计划对准目标再说一次。

确认完再开工

这个动作最好放在研究结束、实现开始之前。太早复述，关键选择还没做；代码写了一半再核，已经晚了。

一句指令就够：“先用自己的话说清这次交付到哪一层、哪些不做、你怎么证明完成。我确认后再改代码。”不需要再生成一份十页 Spec，也不需要给这套做法起新名字。

人要检查的也不是措辞漂不漂亮，只看有没有一处跟自己心里不同。发现分歧后，直接改那一行，再让 Agent 开工。目标如果在执行中变化，也更新这一小段，不必让它翻完整段对话猜最新决定。

复述不需要每轮都做。讨论里出现了“先做”“简单一点”“跑通”“完整支持”这类没有刻度的词，或者任务从研究切换到实现时，再用它核一次最划算。

Agent 很会沿着一个目标往前跑。问题在于，它可能正跑向一个你没确认过的终点。

下次它说“明白了”，先别急着同意。让它把那个“明白”摊开给你看。