夜雨聆风现在关于 AI 的内容太多了，但真正能帮人把事情做成的内容，反而不多。
每天都有新的模型、新的框架、新的工具、新的概念。
Agent、RAG、MCP、Workflow、多模态、知识工程、Claude Code、Dify、LangGraph、OpenRouter……
这些词看起来都很热闹。
但当你真的要把它们用到一个产品里、一个项目里、一个业务场景里，就会发现：热闹归热闹，落地是另一回事。
很多内容只告诉你“这个东西很强”，却不告诉你：
它适合什么场景？不适合什么场景？怎么接入？怎么设计产品流程？怎么跟业务解释？怎么跟研发沟通？怎么验证它到底有没有价值？踩坑之后怎么调整？
这也是我想做《AI 产品实践手记》的原因。
我不想只写 AI 新闻
AI 新闻当然重要。
哪个模型发布了，哪个产品更新了，哪家公司又融资了，这些都能帮助我们理解行业趋势。
但我越来越觉得，如果只是追新闻，很容易陷入一种“信息焦虑”。
今天觉得这个模型厉害，明天觉得那个框架先进，后天又发现新的开源项目更火。
看得越多，反而越不知道自己应该做什么。
所以我更想写的是另一类内容：
不是“AI 又发生了什么”，而是“AI 到底怎么用来做产品”。
比如：
一个 RAG 知识库产品到底应该怎么设计？ 企业知识工程平台和普通知识库有什么区别？ Dify 适合做什么，不适合做什么？ AI Agent 为什么不能只理解成工作流？ 文档解析、财务报表识别、知识图谱、本体工程这些东西，放到真实业务里到底怎么落地？ 一个 AI 产品从想法到 Demo，再到方案汇报，中间会遇到哪些问题？
这些问题不一定新潮，但很真实。
而真实的问题，才最值得记录。
我想记录“做产品的过程”
我做这个公众号，不是想把自己包装成什么专家。更准确地说，我想把它当成一个产品实践笔记。
我会记录自己在做 AI 产品、研究 AI 工具、设计 AI 方案时遇到的问题、判断和取舍。
有些内容可能是完整的方法论。有些内容可能只是一个具体功能的设计。有些内容可能是一次踩坑复盘。有些内容可能是我对某个工具或技术路线的判断。
比如我最近就在反复思考几个问题：
企业为什么需要知识工程平台，而不是简单搭一个知识库？AI 工作流和 AI Agent 到底有什么差别？知识图谱、工业本体、RAG 之间应该怎么结合？一个产品经理在 AI 项目里，应该懂到什么程度才够用？AI 生成 PPT、AI 文档解析、AI 数据分析这些需求，产品上应该怎么拆？
这些问题不会只靠看几篇文章就解决。
很多时候，需要真的去搭 Demo、写提示词、看接口、设计流程、跟业务沟通、跟研发确认，然后再不断推翻自己。
这个过程很琐碎，但也最有价值。
因为产品不是靠概念做出来的，是靠一个个具体问题磨出来的。
AI 产品经理不能只会“讲概念”
现在很多人都在讲 AI 产品经理。
但我觉得，AI 产品经理最危险的一种状态，就是只会讲概念。
一张架构图，几个热词，几个大模型能力，就以为产品定义完成了。
但真正做起来，你会马上遇到非常具体的问题：
数据从哪里来？文档质量不稳定怎么办？解析失败怎么办？模型回答错了谁负责？用户为什么要用？业务流程怎么接？权限怎么管？效果怎么评估？成本怎么控制？跟现有系统怎么集成？
这些问题如果想不清楚，产品方案就很容易变成空中楼阁。
所以我更关注的是：
一个 AI 能力如何变成产品功能。一个产品功能如何进入业务流程。一个业务流程如何产生真实价值。一个真实价值如何被验证和持续优化。
这才是 AI 产品实践里最核心的东西。
我希望这个号有一点“现场感”
我不想把文章写得太像论文，也不想写成营销稿。
我希望它更像一个产品经理的工作手记。
有思考，有判断，有踩坑，也有不成熟的阶段性结论。
比如我可能会写：
今天研究了一个 AI 工具，发现它的宣传和实际能力差距很大。今天做了一个 RAG Demo，发现最大问题不是模型，而是文档质量。今天设计一个 Agent 平台，发现传统工作流的思路已经不太够用了。今天跟业务聊需求，发现他们要的不是“AI”，而是“把原来很麻烦的事变简单”。今天写方案，发现如果不先讲清楚 why 和 how，直接讲功能清单，方案就站不住。
这些东西不一定宏大，但它们是真实发生在产品工作里的。
我相信，真正有用的经验，往往就藏在这些细节里。
我想写给谁看？
这个号首先写给我自己。
因为写作本身就是一种整理。
很多想法如果只停留在脑子里，看起来好像想明白了。但一旦写下来，就会发现逻辑漏洞、概念混乱、表达不清。
写作可以逼着我把问题想清楚。
其次，我也希望它能写给同样在做 AI 产品、AI 项目、AI 应用落地的人。
尤其是产品经理、解决方案人员、项目负责人、技术负责人，以及正在尝试把 AI 用到业务里的团队。
如果你也经常遇到这些问题：
老板说要做 AI，但不知道从哪开始；业务说想用 AI，但需求很模糊；研发说可以实现，但产品不知道怎么定义；工具看起来很多，但不知道怎么选；Demo 能跑，真落地却很难；方案写了一堆功能，但价值讲不清楚。
那这个号里的内容，可能会对你有一点帮助。
我会尽量坚持几个原则
第一，不写纯概念堆砌。
概念可以讲，但必须回到场景、流程、功能和落地方式。
第二，不神化 AI。
AI 很强，但不是万能的。很多问题不是接一个大模型 API 就能解决的。
第三，不只讲成功经验。
很多失败、误判、返工，其实比成功更值得记录。 ** 第四，尽量说人话。**
技术可以复杂，但表达不应该故意复杂。如果一个产品方案只能靠一堆术语撑起来，那它大概率还没想清楚。
第五，尽量给出可复用的东西。
比如产品设计思路、功能拆解方式、方案模板、提示词、工具选型判断、Demo 搭建经验。
我希望文章不是看完就完了，而是能被拿去参考、修改、复用。
说到底，我想做的是一份“实践记录”
AI 发展太快了。
快到很多判断可能过几个月就会变。快到很多工具今天好用，明天就可能被替代。快到很多方法论还没完全沉淀，就已经被新的技术路线冲击。
但也正因为这样，实践记录才有价值。
因为它记录的不只是结论，还有过程。
它会告诉我们：
在某个阶段，我们为什么这样判断；面对某个问题，我们尝试过哪些方案；哪些东西后来被证明是想当然的。
这些记录积累下来，可能就会变成一套属于自己的 AI 产品方法论。
这就是我想做《AI 产品实践手记》的原因。
想在 AI 真正进入产品和业务的过程中，留下尽量真实、具体、可复用的实践痕迹。
如果说 AI 是一场正在发生的巨大变化，那我希望自己不是只站在旁边看热闹的人。
我希望自己在现场。
一边做，一边想，一边记录。
