一个「AI 找房助手」是怎么造出来的?

拆开一个真产品——好用和难用，差在看不见的地方。

前面几篇讲了 AI 干活的原理。这篇动真格，拆一个真实产品——AI 找房助手，钻进去看那些外行看不见、内行才知道的设计。

先用一句话搭骨架。你把这个 AI 想象成一个房产中介，它就走 5 步：

问清需求：像中介反问你楼层、通勤、学区。

拆任务：心里盘算先查啥、后查啥。

调工具干活：去查房源系统。

自己核一遍。

整合成人话回给你：「帮你挑了 3 套匹配度高的」。

带过这类项目的人有句话：「所有 AI Agent 基本都是这个套路。」骨架就这么简单。

好用和难用的天壤之别，全藏在每一步的细节里。挑三个最要命的给你看。

📌 本文看点

拆到最小：一任务一工具

按场景配答案：模板 + 卡片

「必须」不保证：代码才兜得住

ATOMIC

你以为 AI 随便拆拆就行？不是。拆出来的每个小任务，有条硬规矩：必须简单到「只用一个工具就能完成」。

为什么这么轴？因为一旦一个任务要连着调好几个工具——先查 A 再查 B——就冒出一堆麻烦：谁先谁后？A 失败了怎么办？B 失败了又怎么办？分支一多，工程上根本兜不住。所以强行拆到「一个任务、一个工具」这种最小颗粒。

还有条反直觉的规矩：能合并的查询，必须合并

比如你想看同一个小区的三居、两居、一居。笨办法是查三次；聪明的做法是「一个小区 + 三种户型」一次查完。为什么较这个真？因为调用工具越多 = 越慢 = 用户越不耐烦。C 端产品，慢一秒都是罪。

TEMPLATES

AI 最后那段回复，看着是随口一说，其实背后是按意图分好的好几套模板。

「学区找房」和「投资找房」，能一个模子吗？学区房得讲学区好坏、对口学校、通勤；投资房得讲增值潜力、租售比、政策风险。所以贝壳维护了一整排模板：全城、地铁、通勤、投资……看人下菜。

💡 反常识：它回给你的「小区卡」「楼盘卡」「地图卡」，本质上也是一种「工具」——每张卡都是一段可复用的代码，AI 在合适的场景「调用」合适的卡片。产品经理要做的，是把「什么场景配哪张卡」写进规则里。

HARD-CODE

这条最反直觉，也最值钱：你在指令里写「必须输出下一步建议」「严格按 X 格式」，AI 不保证 100% 照做。

为什么？因为大模型骨子里是在「算概率」，对它来说，「必须」两个字也只是一串普通字符，没有真正的强制力。

指令里的「必须」是主观愿望，代码里的拼接才是客观强制。

想要它 100% 输出怎么办？只能靠工程代码写死——AI 生成完，再由代码在后面硬拼上那段「下一步建议」。分不清这两者，产品就会时灵时不灵。

顺带说个内幕：这些精细的规矩（比如「任务描述禁止用数学符号」），没有一条是一开始就想全的，全是上线后被一个个真实翻车案例，逼着一条条打补丁打出来的。做 AI 产品，有大把时间花在「线上救火」上。

∞

THE END

现在你再回头看那 5 步就明白了：「用了 AI」根本不算壁垒，真正的壁垒，是这些看不见的设计功夫——怎么把任务拆到最优、怎么按场景配答案、怎么用代码兜住不确定。

好用的 AI，不是模型多聪明，是有人把细节一处处抠出来了。

👉 5 步里最难的是第一步「听懂你没说全的话」。下一篇专门钻进去：你只说「便宜点的」，AI 怎么把它变成能执行的条件。

END

如果你觉得今天这篇有收获，欢迎点赞、在看、转发三连，我们下篇见。