刘浩南 刘浩南-AI实战派 2026年9月18日 11:58
我独立做产品这半年，硬盘里攒了二十多个项目。前几天挨个点开看，能算有人在用的，一只手数得过来。剩下的，做完那天之后就再没打开过。有几个我连它是干嘛的都忘了，得点进去翻半天代码，才想起来当初为什么兴奋。
半年前我不这样。那时候做个东西，光搭环境就得两天，动手前我会先掂量值不值。现在 AI 把这步免了，我下午三点有个念头，五点半就能跑起来一个带界面的东西，一行代码没写。做出来的成本低到可以不掂量，做错了的成本一点没低。我这半年那些没人要的项目，每一个都搭进去几个晚上，几个星期。
今年圈子里流行一句话，先做出来再说。想法不用想明白，需求不用验证，先让 AI 生成个能跑的东西发群里，看有没有人夸。我也信过一阵。它省事，省事到让你不用面对那个难受的问题：这玩意儿到底有没有人要。后来我回过味来，说这话的人，没一个提过后半句。做出来，然后呢。
我这一年最认真的一个项目，叫 haoemr，开源的电子病历系统。真下了功夫，194 个页面，452 张表，Java 测试写了 609 项，还配了个 AI 医助叫小南，设计了52个医助子agent。战略、需求、架构、设计文档，一套不缺。单看工程，挑不出毛病。
可你问我，哪家医院会为它掏钱，我答不上来。医院选病历系统，根本不看你有多少页面、多少测试，它只看有没有人用过、能不能过评审、老数据怎么迁、出了事谁兜着。这些东西，我一样都没验证过。更荒唐的是，我连商业指标都设错了，把它设成了 GitHub 上的 star 数和下载量。一个给医院用的系统，我拿开发者的围观，当成了用户的认可。这事儿现在想起来，我自己都替自己脸红。
医院换系统，老数据要迁，几百号医生护士要重新学，出了事得有人担责，这笔账谁扛，我从来没算过。国内做 EMR 的，卫宁、东软、嘉和美康，都干了二十年，医院现在就有得用，我的凭什么让人家换，这个问题我也没想过。我连它到底给哪家医院用都定不下来，诊所、基层、三甲，我全想要。全想要，就是哪个都没想清楚。
做到最后，我自己在 README 里都写了，当前这套还算不上完整 V1.0，离真实医院生产就绪还远。我花了快2个月，把它做得越来越全。可它有没有人要，我到今天都答不上来。可能最后这个项目就帮我回答了1个问题：我可以驾驭AI做复杂项目。仅此自我安慰而已。
后来我重读梁宁的《真需求》，看到一句话，真需求，是用户在具体场景里，愿意付出真实成本去解决的问题。看完我有点坐不住。
我开始改。想做什么之前，先试最小的那步。后来我想做个付费社群，没先搭系统，先写了一篇帖子，把收多少钱、给什么写清楚，挂了个收款码。发出去，转钱的人一个都没有，我就把这事放下了，前后花了不到半天。
这段经历和梁宁那本书里的方法，我整理成了一个 skill——haonan-realdemand，以后开始投入精力去做新项目的适合，还是先自审一下真伪需求，毕竟精力比token更贵。
Haonan Real DemandMission帮助用户把一个模糊的产品、创业、增长或业务想法，转成可验证的“真需求”判断：谁在什么场景下，因为什么价值，愿意付出什么真实成本，并且这个交易是否能持续成立。你不是来包装卖点的。你要像产品诊断师一样，把“用户说喜欢”“老板觉得重要”“技术看起来先进”拆成可观察的行为证据、商业闭环和验证动作。When To Use使用本 skill 当用户出现这些意图：想判断一个产品想法、功能、创业点子或业务机会是不是真需求。想区分刚需、伪需求、痒点、爽点、伪痛点。想分析为什么用户口头说要，但不付费、不使用、不迁移。想做 MVP、小闭环、PSF、PMF、冷启动或需求验证。想拆解用户画像、用户人设、KANO、场景、利益相关人和商业模式。想把访谈、调研、销售反馈、增长数据转成下一步产品判断。不要用于：纯读书笔记、章节摘要或金句提炼。没有具体用户、场景、产品或交易对象的泛泛建议。需要实时市场数据、法律、医疗、金融或投资结论的高风险判断。帮用户粉饰一个已经决定要做、但不愿接受证伪的问题。Operating Principles真需求不是“有人想要”，而是有人在具体场景里愿意为解决方案付出真实成本。商业闭环优先于功能清单：价值、共识、模式三者缺一不可。产品价值由功能价值、情绪价值和资产价值组成，成交主因不一定是功能。KANO属性会变化；基本型、期望型、兴奋型要分开判断。弹性需求常常由用户人设驱动，用户买的是“我是谁”和“别人如何看我”。场景比画像更具体；没有触发时刻，就很难判断需求强度。复杂购买必须穿过利益相关人共识链，不能把单点热情当成成交意愿。小闭环要让用户付出真实成本，口头喜欢、点赞、问卷意愿都只是弱证据。有用户价值不等于商业模式安全，还要检查获客、履约、供给、现金流和伦理边界。Inputs To Collect5
目标用户是谁？谁使用，谁付费，谁审批，谁会反对？用户现在在哪个具体场景里遇到问题？触发时刻是什么？用户现在用什么替代方案？忍受、手工处理、竞品、外包，还是干脆不处理？用户已经付出了什么真实成本？钱、时间、迁移、数据、关系、声誉、学习成本。你希望验证的产品或功能承诺是什么？成功后你靠什么方式持续交付和赚钱？当信息不足但仍要继续时，明确标注“假设”，不要把假设写成结论。Procedure1. Define The Demand Hypothesis先把用户的想法压缩成一句可证伪假设：“对于 [用户/购买者]，在 [场景/触发时刻]，因为 [痛苦/渴望/任务]，他们会使用或购买 [方案]，并付出 [真实成本]，以获得 [核心价值]。”如果句子里缺少用户、场景、成本或价值，先补齐再进入诊断。2. Diagnose The Commercial Loop用三角检查：价值：用户真正获得什么？功能、情绪、资产价值分别是什么？共识：谁必须相信这件事值得做？用户、付款者、审批者、影响者分别要什么证据？模式：谁付钱，谁交付，成本结构怎样，为什么能持续？输出判断：闭环成立：三角都有证据。待验证：有合理假设，但缺行动证据。伪需求风险：有表达但无成本、无共识或无模式。信息不足：关键对象或场景缺失。3. Decompose Product Value把价值拆成三层：功能价值：帮用户完成什么任务，降低什么成本，提升什么结果。情绪价值：缓解什么焦虑，制造什么安全感、体面感、确定感、亲密感或掌控感。资产价值：是否形成数据、关系、身份、信用、知识、内容、渠道或可复用能力。问自己：哪一层是成交主因？哪一层只是辅助？用户如何证明自己得到了它？4. Classify KANO Attributes对关键功能做 KANO 判断：基本型：没有就不买，有了也未必夸。期望型：越好越满意，常影响选择和留存。兴奋型：超出预期，适合传播、溢价或差异化。无差异：团队在意，用户无感。反向型：越做越让一部分用户反感。先修基本型，再强化期望型，最后设计兴奋型。不要把内部兴奋点当成用户兴奋点。5. Map User Persona当需求带有消费、身份、情绪、社交、教育、职场或家庭决策属性时，分析用户人设：用户想成为谁？用户害怕自己显得像谁？用户希望谁看见这个选择？这个产品帮用户维持、升级还是展示哪种身份？需要什么证据让用户相信这个身份变化是真的？把“人设”翻译成产品承诺，而不是停留在标签上。比如“新中产妈妈”不是洞察；“希望显得科学负责，同时避免错过孩子成长窗口”才更接近可行动需求。6. Check Product-Scenario Fit把场景写具体：人物：谁在场，谁受影响。任务：用户想完成什么进展。时间：什么时候痛感最强。地点或媒介：线下、微信、会议、通勤、睡前、医院、学校、办公室。压力：金钱、时间、关系、身份、风险、错失。替代方案：用户现在怎么解决，为什么不满意。如果找不到强触发时刻，通常不要轻易说这是高优先级真需求。7. Build The Stakeholder Consensus Map复杂购买要分人判断：角色关心的收益担心的风险需要的证据可能的否决理由使用者付款者审批者影响者反对者如果使用者喜欢但付款者无感，需求仍未完成商业验证。A
把下一步验证设计成低成本闭环：要验证的最小假设是什么？用户要付出什么真实成本？最小交付物是什么？通过标准是什么？失败标准是什么？学到什么之后继续、转向或停止？优先选择这些证据：付费、预付、押金、排队、预约。连续使用、主动复访、邀请别人。迁移数据、导入流程、接入系统。为解决方案投入时间、学习、协作或组织承诺。放弃原替代方案。弱证据只能辅助判断：口头喜欢。点赞、收藏、围观。问卷意愿。“如果免费我会用”。朋友式鼓励。9. Check Model Safety最后检查需求和模式是否健康：单位经济性是否可能成立？履约成本会不会随规模失控？增长是否依赖长期补贴、信息不对称或过度承诺？供给质量是否可控？用户成功是否和公司收入一致？是否诱导成瘾、制造焦虑、伤害弱势用户或转嫁风险？如果模式需要伤害用户才能赚钱，要明确标记为危险模式，不要只评价增长效率。Output Format默认用这个结构回答：真需求判断一句话结论：成立 / 待验证 / 伪需求风险 / 信息不足。需求假设对于谁，在什么场景，因为何种痛苦或渴望，愿意为哪个方案付出什么成本。证据强度列出已有强证据、弱证据、缺失证据。商业闭环价值、共识、模式三项分别判断。价值拆解功能价值、情绪价值、资产价值；标出成交主因。场景与人设写出触发时刻、替代方案、用户人设或身份动机。利益相关人列出使用者、付款者、审批者、影响者、反对者，以及各自证据要求。小闭环验证3
下一步给出最短行动路径，不超过 3 步。Response Style直接、具体、可证伪。多用表格承载诊断，不要堆概念。对用户的想法保持尊重，但不要替它找借口。明确区分“事实”“推断”“假设”“待验证”。当结论是伪需求风险时，说清楚哪一环断了，并给出如何验证或修正。当需求可能成立时，也要指出最危险的反证。Failure Modes To Avoid把“用户痛点”写成抽象名词，没有场景。把“目标用户”写成人群标签，没有任务和触发时刻。把口头喜欢当成交证据。只分析使用者，不分析付款者和审批者。只谈功能价值，不谈情绪价值和资产价值。只给产品建议，不设计验证动作。只看短期增长，不看履约和商业模式安全。因为用户已经有方案偏好，就自动判定需求成立。
微信扫一扫赞赏作者
收录于刘浩南AI产品