想做一个项目，先写清这几个问题

大目标需要一个能开始的位置

“做一个智能体客服”能表达方向，但还不能直接指导今天写哪一段代码。它可能包含知识库、模型调用、人工接管、权限、部署和监控。所有功能一起出现时，很容易分不清当前究竟在验证什么。

可以先问：谁会使用它？他带着什么问题来？第一版结束时，我们能展示哪一种输入和输出？这些答案会决定本轮的范围。

给第一版一个有限的任务

下面是客服项目的设计练习，尚不代表项目已经交付：先准备少量可公开的常见问题，在本地验证提问与答案之间的对应关系；资料里没有答案时，明确返回未找到，不伪造政策或承诺。

此时的验收可以围绕三类输入：资料中已有的问题、资料外的问题、含糊的问题。能否给出预期行为，比界面上有多少按钮更容易判断。

涉及真实客户之前，权限、隐私、错误处理和人工接管需要单独验证。不能因为本地示例能回答，就省略这些工作。

找到当前最需要验证的一个问题

如果资料本身混乱，先做检索也可能只得到更快的混乱。如果答案准确但没有人需要，继续优化响应速度也未必改变结果。

列出几个未知项后，选一个最影响下一步的：资料是否够用、答案能否追溯、使用者是否能理解，或失败时是否有退出路径。本轮围绕它设计最小测试。

知识库整理也能这样做：先验证“能否从主入口找到正确版本”，再考虑自动化。可以参考知识库项目记录。

一页项目卡

项目名称：
帮助谁解决什么具体问题：
第一版可展示的输入与输出：
必须保留的功能：
本轮明确不做什么：
当前最关键的未知项：
最小测试与预期结果：
允许修改的数据或文件范围：
失败后的停止与恢复办法：
完成证据放在哪里：
下一次检查时间：

填写时尽量写可观察的动作。“更智能”不好验收，“资料外问题返回未找到，并保留问题类型”就更清楚。卡片不需要承诺一次把所有问题解决。

做完后，留下结果而非补写成功故事

如果测试没有通过，记录实际输出与预期差异；如果范围缩小，说明为什么；如果还缺材料，把缺口留在下一步。它们都能帮助后来的人理解项目。

想把结果放上网站，可以继续看学习成果卡：把项目卡里的计划，接到真实产物与检查记录上。

来源

依据个人知识库《使命驱动的第一性原理执行系统》及《埃隆之书：目标与成功指南》相关整理改写。本文聚焦项目范围与验证，不复述未经核对的企业故事；客服例子是设计练习。