1.4 最小可用目标：MVP 功能清单

选型和账号都搞定，CEO 问我多久能上线。我说四周，他嫌慢，但我不松口——小团队最怕一上来搞大的，需求像滚雪球，越议越多。不如先跑通一个能用的闭环，给客户和老板看到真东西，再往里加。

这一节就是我们第一版的功能清单和推进节奏，你照着抄都能跑。定 MVP 的时候我犯了难：老板的预期是市面上那种什么都能答的 AI，客服的预期是能帮他们接走所有活的救星，开发同事的预期是能炼新技术的练手项目。三个预期三个方向，我只能拿数据和清单一样样对齐。这就是这一篇要解决的事。对齐会上我第一句话就是先泼冷水：我们做的不是通用 AI 助手，是客服助手；衡量它行不行的标准只有一条，重复工单有没有下去。所有人听完这句，后面的讨论就顺了——所有的功能候选都被拿去问一遍，它服务于哪类工单？答不上来的一律砍。这一招特别好使，讨论效率直接翻倍。

MVP 功能清单

第一版我只留了四件事，每一件都给了验收标准，做没做到一句话能说清：

没有验收标准的功能不算需求。这四条写完，我和老周一人一条核对过，确认每一项都能被非技术人员验证——验收标准写成测试用例，上线那天谁来点、怎么点、点什么算通过，全都提前定死。

经验之谈：验收标准里千万别写流畅、自然、智能这种形容词。什么叫自然？谁能判？这种词一旦写进清单，上线验收的时候必定扯皮。全部换成可计量的东西：响应时间、是否带来源、订单号输错有没有提示。

举个例子你就明白为什么这条重要：本来我想写回答准确率大于 90%，写完自己心虚——怎么定义准确？谁来抽检？抽多少条？最后改成了灰度期每天抽 20 条对话由客服人工判对错，准确率连续三天达标才算过。具体到可执行，验收才不会变成自由心证。

顺带定了个规矩：验收那天客服组长、开发、我三方在场，逐条点单，过了当场签字。这条后来被证明是最省钱的规定，因为它把上线后互相推诿的可能提前堵死了。

四件事的取舍各有各的道理：官网问答是门面，直接决定老板和客户对这件事的第一印象；知识检索是给客服自己的福利，降低新人成长门槛，老周私下跟我说这是他最期待的一条，因为新人培训最熬人；查订单是技术上最难的一环（要调接口、取参数），放进来是为了验证工具调用这条路走得通；转人工是兜底，没有它，答不上来的客户就卡在对话里出不去，有了它整套系统才是一个闭环而不是半成品。老周最看重这一条，因为客户最反感的不是 AI 答错，是答错了还找不到人。优先级里为什么把查订单降成 P1：因为它依赖订单接口改造，是唯一有外部依赖的功能，万一接口排期耽搁，不能让它拖住其他三件事上线。真到排期有压力的时候，有兴趣跟着抄的团队，我额外建议一句：MVP 清单要打印出来贴在公共区域，别只躺在某个文档系统里。看得见的需求才有压力，也才有成就感——每验收掉一条，当众划掉，团队氛围立刻不一样。我们当时的清单就在会议室白板上，现在想来远比任何甘特图有用。

不做清单

比做什么更难的是不做什么。这是我顶回去的一版需求清单：

除了表里的，还有几个被砍的想法值得说一下。有同事提议加个满意度评价按钮，我想了想没收：MVP 阶段流量小，样本太少，评分反而失真，不如灰度期先看对话记录人工判断。还有人想做客户分组画像，给不同画像推不同答案——这个想法本身好，但前提是问答链路本身足够稳，饭还没熟先别摆盘。拒绝这些需求的时候，我都会说同一句话：先解决重复问题，再谈锦上添花。

我把这条原则贴在工位上：MVP 的标准不是能用多少功能，是能不能让客服明天少接十个重复电话。

不做清单还有个隐性收益：它让团队学会了对需求说再做一遍评估。后来再有人提新想法，我的第一句话不是行不行，而是先放不做清单里排个队。大多数想法排了两周就没人提了，真正重要的自己会浮上来。砍需求这件事一开始我也怕得罪人，后来发现同事们通情达理——怕的不是被拒绝，是没有一个透明的规则。把不做清单贴出来，规则就摆在了明面上。

四周时间线

我按周给自己定了里程碑，每周有可交付的东西，跑不起来就当周复盘：

最后说说这个 10% 灰度怎么定的。我原本想上来就全量，被老周拦住了：万一答得离谱，十分之一的访客看笑话。先放一成流量，观察两天对话记录再放量，稳妥第一。这也是全书唯一一个我一开始没想通、被业务同事教会的地方。

第 1 周导入文档这一步，我用建站时搭好的文件结构做底子，官网和帮助中心怎么从零搭，可以看轻量建站实战。

表里第 1 周就写跑通最简单问答链路，是有意为之：先用最快的方式证明整条链路能通，哪怕回答质量还很差。链路通了，后面三周全是精装修；链路不通，越早死越好。这套先跑通再打磨的打法贯穿了整个项目，后面每一篇里你都会看到它的影子。

还有一点要说：表里没有列 owner，实际项目管理里我给每行都指定了负责人——知识库相关是老周，接口和编排是我，官网挂件是前端。表格不写名字，责任就飘在空中。

我自己的推进节奏是工作日写代码测流程，周五下午拉老周过一轮验收。开发效率上我靠 AI 编程工具省了不少力气，具体怎么用在Claude Code 指南里详细聊过，体验上是真的快，尤其是写联调脚本和测试用例这种零碎活。中间有几次我走神想顺手加个新功能，被墙上那张不做清单拦住了——这才知道清单比自制力靠谱，人是动摇的，墙是不动摇的。开发进度有一阵也确实靠这个守住，想加花活的念头每个程序员都有，我也没有例外。所谓 MVP，先是最小，然后才是可行。如果你们团队也在纠结第一版做多大、砍哪些功能，希望这张清单和时间线能给你一个够用的参考，直接照着改一版，明天就能开工。

时间线排得松是故意的。每周留出半天容错，因为联调这东西出意外的概率比写代码本身高得多。第 3 周接订单接口的时候确实延后了一天，因为订单接口那边的字段定义要跟后端同事拉齐，如果没有那半天缓冲，整个排期就要往后串。排期这事我还有个体会：里程碑一定写下可交付物，不能写完成某模块开发这种内部语言。不然到了周五，开发觉得做完了，老板觉得啥也没看到，解释半天。里程碑用结果语言还有一个好处：排期延误的时候，一眼就能看出延的是哪件事，而不是笼统地慢了。

交付物先于一切

排好时间线之后，我把每周的可交付物写成一张大纸贴在会议室墙上，全公司都能看见。上面没有技术名词，只有结果：第一周能看的演示、第二周能对话的雏形、第三周能查订单能转人工、第四周官网灰度上线。CEO 路过看了一眼说这个好，我对技术的细节不感兴趣，但对什么时候能看到什么很在意。这一点我深有同感，做技术的人习惯用过程汇报，听的人只关心结果。

对小团队来说，让非技术同事尽早看到进展，是争取后续资源最有效的办法。第三周演示的时候，CEO 亲自体验了一把查订单，那一刻他比我更确定这事儿能成。所以哪怕时间再紧，每周的演示也别省——它是团队士气和后续资源的发动机。

同时也要克制：演示只演已验收通过的功能，没调通的坚决不演，免得翻车。有一次我抱着侥幸演了半成品，当着老板的面答非所问，尴尬得想找个地缝。从那以后演示清单我先跟老周过一遍，确认演的都是稳定路径。

写到这里，需求和选型这一篇就齐活了：痛点有数据，方案有对比，账号预算有清单，MVP 有范围和时间线。下一章我们进入知识库——先把喂给 AI 的知识准备好。知识这件事，我后来才深刻体会到一句话：AI 的上限不是模型，是喂进去的那些原料。

延伸阅读

• 官网聊天窗要挂在哪，先看轻量建站实战。
• 大模型问答的提示词思路，看DeepSeek 工具链。