如何把 MVP 需求写成 AI 能执行的开发任务书

从一句任务开始#

示例工具面向需要整理文章的内容编辑。用户粘贴中文长文，得到标题建议、摘要和标签，再复制出去使用。

先把这句话留下来。开发过程中，有人提出“加一个团队空间”，就拿它对照：这个功能是否影响用户完成当前任务？如果不影响，先记到后续需求里。

任务书不需要写得很长，但应当消除会改变实现方式的歧义。比如“上传文章”可能意味着上传 Word、PDF 或粘贴文本。第一版如果只接收纯文本，就直接写“粘贴文本”，省掉文件上传和解析的工作。

写清输入和输出的约定#

可以先给示例项目定下这样一组规则。下面的数字是教学规格，实际项目应根据用户材料和模型限制调整。

1
输入：中文纯文本。
2
长度：去掉两端空白后，100 至 12000 个 Unicode 码点，含标点。
3
第一版不支持文件上传、网页链接和批量处理。
4

5
输出：
6
- title：一个标题建议，字符串。
7
- summary：一段摘要，目标长度为 120 至 200 字。
8
- tags：3 至 5 个不重复的标签，字符串数组。
9

10
内容要求：以原文为依据，不补充原文没有的事实。
11
摘要长度作为质量检查项；字段缺失或类型错误时，不能当作成功结果。

明确计数口径，是为了让前端和服务端采用同一套规则。JavaScript 的字符串 length 统计 UTF-16 码元，与 Unicode 码点数并不总是相同；实现时可以用 Array.from(text.trim()).length 计算这里约定的长度。这个长度也不等于模型的 token 数，接入 API 时还要单独检查上下文限制。

字段名一旦确定，页面、接口和测试就沿用它们。不要让 AI 在前端叫 summary，到了后端又改成 abstract，然后靠猜测补映射。

“以原文为依据”同样需要检查。能返回三个字段，只能说明格式基本成立；摘要有没有漏掉条件、标题有没有夸大，仍要拿真实文章对照。

把用户看不到的状态补上#

设计稿通常展示成功结果，实际使用还会经历等待和失败。任务书可以用一张小表说明这些状态：

这里有一个容易遗漏的细节：用户成功处理文章 A 后，再提交文章 B，旧结果怎么处理？可以把旧结果标为“上一次结果”，或者暂时收起。不能把 A 的摘要继续放在 B 的输入下面，却让人误以为那是新结果。

复制按钮也需要交付标准。点击之后应当复制对应字段，并显示成功提示；剪贴板访问失败时，仍允许用户选中文本手动复制。

技术限制写到会影响开发的地方#

第一版的限制可以很短：

1
采用已确认的项目技术栈，不另换框架。
2
模型请求由服务端发起，浏览器不接触服务密钥。
3
输入原文不做持久化存储。
4
错误日志不记录完整原文和密钥。
5
暂不增加账号、历史记录、支付和团队协作。

不保存原文，不等于数据不会离开自己的服务器。使用外部模型时，原文会发给供应商；任务书应当明确这条数据流，产品页面也要在提交前说明。至于供应商是否保留数据，应按所选服务的实际条款核对。

团队权限、跨区域部署和复杂审计如果还没有对应需求，可以以后再讨论。任务书先规定当前实现的边界。

将任务拆成能单独检查的步骤#

“一次实现整个工具”很难验收。更容易推进的顺序是：

1. 做输入页和长度校验，确认正常输入能提交，无效输入有提示。
2. 用固定的模拟结果连接页面，检查结果展示、复制和错误状态。
3. 单独测试模型 API，用一份真实样例确认它能交付需要的结果。
4. 把模拟处理替换成服务端真实调用，检查返回格式和失败情况。
5. 用验收样例跑完整流程，再处理移动端和文字溢出等问题。

第二步的模拟结果只用于检查界面与数据传递，不能算核心功能已经完成。进入第四步后，还要确认页面确实使用了真实接口，而不是仍在返回写死的数据。

可以给 AI 一次这样的指令：

1
先阅读项目现有入口、运行命令和文章整理工具的 SPEC。
2
本次只实现输入框与长度校验，不接模型 API。
3
前端校验采用 SPEC 的字符计数规则。
4
保留已有页面布局，不增加账号和数据库。
5

6
完成后运行现有检查，并说明：
7
修改了哪些文件；正常与无效输入的实际检查结果；尚未实现的部分。

这条指令规定了本次工作和完成证据。AI 如果发现必须改动其他模块，应先说明原因，让范围变化有据可查。

用样例检查任务书有没有漏洞#

让 AI 开工前，准备几份材料：一篇正常文章、只有空白的输入、一篇超过长度上限的文章，以及一篇包含数字和限定条件的文章。

逐份问自己：页面应该怎么反应？什么结果可以接受？如果答案写不出来，先补任务书。遇到“摘要没报错，但是意思变了”，也要能把问题落到具体原句和输出句上。

SPEC 可以随着测试结果修改。比如真实用户经常粘贴英文文章，就需要重新决定语言范围；同时更新页面提示、接口校验和验收材料，不能只改其中一处。

检查任务书时，我会重新核对问题、方案、技术约束、不能改动的部分和交付标准，看看它们是否已经落实到输入输出、页面状态和验收步骤里。任务书是否够用，最终要看开发时还需要猜多少答案。

下一篇接着准备开发工具和本地环境，让这份任务书有一个能运行、能检查的项目。