确定 MVP：功能取舍与继续投入的标准

把ClearCopy的第一版缩到一个可以完整试用的任务：输入英文App介绍与功能事实，得到可复制改写、修改解释，失败时能看懂原因并重试。本文会做出一份已填范围说明、一张页面草图和三组具体输入输出；开发时可以直接逐项实现。

MVP是“最小可行产品”。“最小”指删除这次任务不需要的工作，“可行”指留下的部分足以让人真正使用。页面只有一个生成按钮却没有结果，或者结果错误后只能刷新重来，都没把这个任务做完。

先把本轮想知道的事情写成一句话

ClearCopy本轮的问题是：开发者能否用真实功能说明约束英文改写，得到自己愿意采用的App介绍？我们先试用，不把团队协作、规模获客和自动续费一起塞进来。

GOV.UK alpha阶段说明建议围绕最不确定的部分做足以测试想法的原型，而不必模拟整条庞大服务。这里借用“先试最难确定的一处”的做法；政府服务阶段的时长与流程不是个人网站必须照抄的工期。

这次最不确定的是改写是否可采用，尤其会不会添加不存在的同步能力。于是“功能事实输入”和“逐项解释”保留；团队邀请虽好看，却回答不了这个问题，先移走。

把功能逐项放入或移出第一版

下面是已经做过取舍的范围表，可以直接用于开发任务讨论。

功能	本轮安排	具体做到哪里
英文原稿输入	做	有标签，允许粘贴；空白时不提交
功能事实输入	做	固定示例可载入，也能填写自己的事实
结果与解释	做	分区展示，只复制正文
等待和失败	做	等待时避免重复提交；失败显示可理解原因
调用长度限制	做	提交前展示，超限时指出怎么缩短
登录与历史	试用版先不做	不把原稿长期保存到服务器
购买10次成功检查	下一阶段做	先把试用任务跑完，正式售卖前再接订单额度
团队、词库、多语言	暂缓	有对应真实任务后另行设计

这也解释了第一章的匿名工具页与后面的支付章节如何衔接：匿名短试用先观察任务；预付销售需要自己的订单与额度设计，不能因为试用页不用登录，就默认正式付费也无需识别购买者。

把页面画到别人不用问你也看得懂

拿一张纸，按顺序填入以下内容。不需要复杂设计工具，先把状态与文字摆清楚。

ClearCopy
Check your App Store description

English draft
[This app can let you make trips and check your things...]

What your app already does
[Create trips; check off items; reuse lists; work offline]

Not provided in this example
Account / cloud sync / AI trip planning

[Check description]

Revised description
Create a packing list for each trip...
[Copy description]

Why it changed
check your things → check off items：明确勾选动作

旁边再画两张小状态。等待状态把按钮文字改为“Checking…”，并保留输入；失败状态写“检查暂时未完成，你的原稿仍在，可以重试”。这些文字只是界面设计示范，连接真实接口后再根据实际错误分类处理，不能一律把权限或额度错误解释为暂时故障。

首轮试用的长度先设为500个Unicode码点，这是本书为了限制短段落任务选定的产品规则，不是App Store描述的官方上限。界面写“最多500个字符”，并告诉用户这是试用处理范围；后续实现与测试用同一种计数方法，别让界面说字符、后台却只数单词。

用三组材料说明“做完”长什么样

正常输入就是前面的离线行李清单原稿。编辑示范的完整结果为：

Create a packing list for each trip, check off items as you pack, and reuse your lists for future journeys. Works offline.

应能复制这段正文，且复制内容不包含按钮文字和修改说明。解释中指出保留的四项事实。这是本书给开发者的预期示范，模型实际用词可以不同，但不能把功能含义改掉。

第二组输入只放空格。此时按钮不应发起模型请求，而是在原稿旁提示“请填写英文原稿”。填写内容后提示消失；用户不用把所有功能事实重填一遍。

第三组输入是501个a。它超过本轮500码点限制，页面应当显示“当前501个字符，试用上限500”，并保留内容以便删减。这个例子没有英语写作价值，专门用来检查长度处理。把三组材料写进开发任务，AI或开发者才能知道要实现的是哪种具体行为。

后面还要单独核对服务故障：接口不可用时不清空原稿、重复点击不产生多次并发；这些放入开发章节实际运行。不要在还未接接口时把纸面设计表述为已经测试成功。

提前写下什么情况会改方向

继续投入需要一个与你的任务有关的判断。本轮先约少量目标使用者，观察他们是否能完成输入、核对与复制，以及结果是否可采用；人数由可接触对象与时间安排决定，不把某个小样本比例当作全市场结论。

为了避免试完后临时改标准，先写下三种处理方式：

实际观察	下一次具体处理
原稿任务真实，结果大致可用，但找不到解释	调整结果区位置，再试同一流程
输出常增加未提供功能，用户必须重写	先改约束与核对，不开始收费
通用工具已足够，使用者说不出另一次需要	停下开发，重新选择更明确任务

GDS公开测试案例中的假设便签把观察、改动与预期连起来；配图可以帮助你读这种结构。案例也提醒按钮效果依赖具体上下文，所以我们不从它借一个百分比当作ClearCopy目标。

最后，在GitHub Issues或自己的任务工具里创建第一项任务：“完成匿名短段落检查页”。把范围表、三组材料和预期结果贴进去，暂缓功能放到另一个列表。你已经得到一份开发者能执行的第一版，而不是一份任何功能都舍不得划掉的愿望清单。