夜雨聆风FDE 从“AI 包工头”说起
我一直觉得 AI FDE 这个概念不太好直接解释，所以更愿意把它戏称为“AI 包工头”：不是单纯写代码，也不是只做咨询，而是深入需求方的现场，理解真实工作流，然后调度 AI 工具把问题解决掉。
最近这个概念开始热起来，我也准备把一些自己的实践案例陆续整理出来。第一篇先从一个很具体的线下实体店场景开始：一家咖啡工作室，和一次关于“冲煮参数记录”的小需求。
需求：记录每一次测试，方便之后复盘
这次的需求来自一位开咖啡店的朋友。当天他提到一个很朴素的问题：每次测试咖啡冲煮参数时，都希望能把参数、口味反馈和结果记录下来，之后定期复盘，最好还能让 AI 帮忙总结规律。
这个需求看起来不复杂，但很典型。它不是“做一个系统”这么宏大的命题，而是把每天已经在发生的工作流程数字化，让记录成本足够低，复盘价值足够高。
现场：边聊需求，边把工具做出来
我骑车到了离家不远的 Temple Coffee。刚到店里，店里正在烘豆，现场感很强：这不是在会议室里凭空想象产品，而是在真实的咖啡工作台旁边，看着对方怎么测试、怎么记录、怎么判断一杯咖啡的结果。
聊清楚需求以后，我们没有先写一大堆需求文档，而是直接围绕店主最常用的动作开始做：拍照、识别、记录、查看、复盘。这个过程更像是把一个实际工作动作翻译成一个网页工具。
这类场景里，最重要的不是第一次就把产品做完整，而是让需求方理解工具如何被修改。只要他能继续提出需求、继续调整字段、继续改界面，这个工具就不再只是一次性交付。
做法：让店主也参与 Vibe Coding
做一个简单网页版并不难，但我更想验证另一件事：与其替对方做完所有功能，不如把方法交给他，让他知道怎么用 AI 工具继续迭代自己的小系统。
所以这次的重点不是“我做了一个工具”，而是让店主也参与到 Vibe Coding 里。他知道自己要什么，也最清楚哪些字段有用、哪些交互多余。AI FDE 的角色，就是把这种业务判断转成可运行的东西。
如果只交付工具，短期能用，但后续每次改动都要等人帮忙，工具和真实工作流之间的偏差也会慢慢变大。
如果一起迭代工具，需求方能直接参与字段、流程和界面的调整，AI 工具会更自然地成为现场工作的一部分。
结果：一个小时做出可用版本
最后大概花了一个小时，我们做出了一个可以识别拍照结果、自动录入冲煮参数的版本。它还不是一个完整产品，但已经足够验证方向：店主可以更轻松地记录实验，也可以在数据积累以后让 AI 帮他总结不同冲煮参数和口味之间的关系。
这次实践给我的最大提醒是：AI FDE 的价值不在于炫技，而在于把 AI 带到真实现场，用最短路径做出一个能改变工作方式的东西。
复盘：这个案例为什么值得记录
线下实体店里有大量这种“小而具体”的需求：记录、归档、识别、总结、提醒、复盘。它们单独看都不大，但一旦被做成合适的工具，就能持续节省精力，并且把经验沉淀为数据。
接下来欢迎做实体店的朋友们跟我约时间，我到店去教你们 vibecoding，解决实际的小问题。
