AI时代的产品需求经历深刻重构。当实现效率提升百倍后，真正的挑战转向如何精准定义问题。
--91likeyou---
定义问题不是把一个想法说得更高级，而是把真实用户、具体场景、当前痛点、产品需求和 MVP 边界讲清楚。
AI 会让实现变快，但越是实现变快，越需要有人把问题定义准。
01 很多项目，从第一句话就走偏了
我见过不少人第一次用 AI 做项目，包括我自己，兴奋点都很像：先抛给 AI 一个项目名，然后等它变出一个系统。比如“帮我做一个客户管理后台”“帮我做一个内容生成工具”“帮我做一个企业知识库问答机器人”。
几分钟之后，页面出来了，按钮也有了，左侧菜单、顶部导航、列表、搜索框都像模像样。那一刻很容易让人觉得，项目已经完成了一大半。
可真正拿去用时，问题才会慢慢冒出来。
- 客户管理后台里有“客户姓名”和“备注”，但销售每天最需要看的其实是下次跟进时间；
- 内容工具能生成一段文案，却没有选题、修改、排期和复盘；
- 知识库机器人能回答几个问题，但没有答案来源，也不知道资料里没有内容时该不该拒答。
页面看起来像软件，工作却没有被真正接住。
这不是 AI 没用，恰恰相反，是 AI 太快了。
过去需求不清楚，项目可能会卡在沟通、报价和排期里；现在需求不清楚，AI 也能先给你生成一个看起来完整的东西。
速度变快之后，问题不会消失，只会更早、更快地暴露出来。
02 想法和需求，中间差一个现场，也差一份 PRD
“做一个学员管理后台”是想法，不是需求。
真正的需求，至少要能说清楚这个后台给谁用、在什么场景下用、现在的工作方式哪里不顺、第一版到底要改善哪一段流程。
如果把这件事放回一家小型培训机构，画面会清楚很多。
- 教务老师每天上午要看哪些学员需要跟进，下午要记录试听、入班、请假、续费等沟通结果；
- 课程顾问关心线索有没有推进，老师关心学员有没有按时到课，负责人关心状态是否准确。
现在这些信息可能散在表格、聊天记录和个人备忘录里。
真正麻烦的不是“没有一个后台”，而是学员状态不一致、交接时容易漏、每天不知道先跟进谁。
这样一拆，项目方向就变了。
第一版不一定要做完整教务系统，也不需要一开始就做复杂权限、排课算法和数据大屏。它可以先围绕一个很小的闭环展开：录入学员，设置状态，记录一次沟通，设置下次跟进时间，第二天打开后能看到待跟进名单。这个版本看起来没有那么宏大，却更接近真实工作。
这时就需要一份轻量 PRD，也就是产品需求文档。它不一定要写成几十页，也不是为了显得专业，而是把现场里的混乱信息翻译成产品能执行的语言。
一份够用的 PRD，至少要回答六件事：目标用户是谁，真实场景是什么，当前问题为什么值得解决，第一版要完成哪条核心流程，系统需要保存哪些关键数据，最后用什么标准判断它可用。
拿学员管理后台来说，PRD 不应该只写“支持新增、编辑、删除学员”，而应该写清楚：教务每天进入后台后，先看到待跟进学员；点进学员详情，可以看到最近一次沟通记录；完成沟通后，更新状态并设置下次跟进时间；第二天系统能把这名学员重新放进待跟进列表。
这样的描述比功能名更有价值，因为它把用户动作、业务状态和产品结果连起来了。
很多人以为需求写得具体，是为了让 AI 更听话。
其实更重要的是让自己别被“系统”这个大词带偏。软件项目最怕的不是小，而是虚。一个小而清楚的项目，能被试用、被反馈、被继续迭代；一个听起来很完整但没有现场、没有 PRD 的项目，只会越改越像模板。
03 FDE 的第一反应，不是开工，而是追问
FDE 做项目时，最有价值的动作往往发生在写代码之前。不是因为代码不重要，而是因为前面的判断会决定后面所有代码有没有方向。
一个模糊想法摆在面前，成熟的做法不是立刻进入实现，而是先追问几个具体问题。
用户到底是谁？这个问题不能停在“企业员工”“所有学生”“所有职场人”。越泛的用户，越难做出第一版。更好的表达是教务运营、课程顾问、一线客服、销售负责人、内容运营、自由职业者。角色越具体，使用动作就越容易浮出来。
场景也要具体。用户是在早上打开工具安排当天工作，还是在接待客户时快速查资料，还是每周一整理内容排期？同样叫“内容工具”，如果用在选题阶段，产品要解决的是灵感和素材；如果用在发布阶段，产品要解决的是排期和状态；如果用在团队协作阶段，产品又会变成审核、版本和责任人。
痛点更不能只写“效率低”。效率低通常只是结果，不是原因。真正要问的是卡在哪里：信息分散、重复录入、判断困难、状态不同步，还是结果无法追踪。原因不同，系统就完全不同。AI 可以帮你生成页面，但不能替你决定到底该解决哪个原因。
04 第一版不是功能越多越好，而是 MVP 越精准越好
很多项目一开始会列出很长的功能清单：新增、编辑、删除、搜索、筛选、导入、导出、统计、提醒、权限、消息通知。清单越长，项目看起来越完整，也越容易失去第一版的重点。
这也是为什么产品里经常讲 MVP，Minimum Viable Product，最小可行产品。MVP 的重点不是“做一个简陋版本”，而是用最小的产品形态，验证最关键的问题是否真的成立。第一版产品不追求完美，也不追求看起来什么都有，而是要足够精准地解决一个真实痛点。
更稳的做法，是先写最小闭环。
所谓闭环，不是“有几个功能”，而是用户能不能完成一次有价值的动作。
- 学员管理后台的 MVP，可以先验证教务能不能从“发现待跟进学员”走到“记录沟通结果并安排下一次跟进”；
- 内容工作台的 MVP，可以先验证用户能不能从“输入主题”走到“生成选题、形成文案、放进发布计划”；
- 企业资料问答的 MVP，可以先验证系统能不能从“导入资料”走到“提出问题、返回答案、显示来源、收集反馈”。
这就是“能运行”和“能用”的差别。
一个页面能打开，只说明它运行了；一个用户能在真实场景里完成任务，才说明它开始有用。
很多 AI Demo 停在前者，看起来很快，实际上没有进入工作流程。
闭环越清楚，取舍就越容易。你会知道哪些功能必须做，因为没有它们流程就断了；也会知道哪些功能可以以后再做，因为它们只是增强体验；更会知道哪些功能本次不要碰，因为它们会把项目拖向另一个方向。
第一版真正需要保护的，不是功能数量，而是问题焦点。
一个好的 MVP，不是把完整产品砍掉一半，而是把最精准的问题先解决到能被验证。
05 让 AI 先当访谈者，再当开发者
如果你手上有一个项目想法，第一句不妨先别说“帮我写代码”。
可以换成：“我想做一个小型软件项目，请你先不要实现，先围绕目标用户、使用场景、当前痛点、第一版范围、关键数据、AI 参与方式和成功标准，帮我把问题问清楚。”
这句话的意义，是把 AI 从“立刻生成”切换到“先做访谈”。
很多时候，我们并不是缺一个更复杂的提示词，而是缺一次像样的需求澄清。
你让 AI 多问几个问题，自己也会被迫把脑子里那个模糊的“系统”拆回真实工作。
等这些问题回答完，再让 AI 整理成一份需求说明。
需求说明不需要写成长篇报告，但最好包含几件事：目标用户是谁，使用场景是什么，当前方式为什么不够好，第一版必须做什么，哪些以后再说，哪些本次明确不做，系统需要保存哪些数据，AI 在里面负责什么，以及怎样算第一版可用。
这份说明最大的价值，是减少猜测。
AI 少猜一点，项目就稳一点；人少被大词带着跑一点，交付就更接近真实一点。
06 验收标准，是把 Demo 拉回现实的绳子
需求说清楚之后，还要写验收标准。
没有验收标准，项目很容易停在“看起来差不多”。尤其是 AI 生成的页面，经常第一眼很完整，但一刷新数据没了，一输入空内容就异常，一换，一到真实用户手里就不知道下一步该点哪里。
以学员管理后台为例，验收标准可以非常朴素：能新增一名学员，能修改学员状态，能记录一次跟进内容，能设置下次跟进时间，刷新后数据不丢失，能筛选出今天需要跟进的人。
它们不华丽，但每一条都对应真实使用。
FDE 看一个项目，不只看页面像不像，也不只看有没有用到 AI，而是看它能不能支撑一次完整任务。输入是什么，处理过程是什么，输出给谁看，用户看完以后下一步做什么，哪里可能出错，出错后有没有补救方式。把这些问题问完，项目才从“演示”往“交付”靠近。
07 真正的门槛变了
AI 时代，写代码的门槛确实在降低。过去很多普通人有业务经验、有问题意识，却很难跨过开发门槛；现在，只要能把问题说清楚，就有机会更早做出第一版工具。
但这不代表项目变得没有门槛。门槛只是换了位置。过去更稀缺的是会写代码的人，现在越来越稀缺的是能定义问题、组织上下文、判断结果、推动试用的人。谁能把一个现场问题讲成清楚的需求，谁就更容易让 AI 变成生产力；谁只是把一个大词丢给 AI，谁得到的就很可能只是另一个模板。
所以，普通人做项目，第一步不是打开开发工具，而是先把项目讲明白。你可以从一个很小的问题开始：目标用户是谁，他现在怎么做，哪里最卡，第一版先改善哪一段流程，怎样证明它真的有用。能回答这些问题，再进入实现，项目会稳得多。
08 今天可以先写这张纸
如果你今天刚好有一个想法，可以先用一张纸把它写下来：
- 这个项目服务哪类具体用户；
- 用户在什么场景下会打开它；现在的解决方式是什么；
- 现在方式最麻烦的地方在哪里；
- 第一版只验证哪一个核心假设；
- 用户输入什么，系统处理什么，最后输出什么；
- 用户看到结果后下一步做什么；哪些功能以后再说；
- 哪些功能本次明确不做；
最后，用哪几条标准判断第一版可用。
写完这张纸，再让 AI 参与项目，你会发现对话质量完全不同。
你不再是在让 AI 猜一个产品，而是在带着 AI 推进一个项目。
题图来自Unsplash，基于 CC0 协议。
🔥 热词：#AI · #都说 · #时代最稀缺的是定义问题 · #什么才叫会定义问题 · #时代的产品需求正在经历深刻重构。当实现效率提升百倍后 · #真正的挑战转向如何精准定义问题 · #从目标用户画像到最小闭环设计 · #PRD