过去很多非技术人做产品，最大的挫败感不是没有想法，而是想法永远卡在“找谁开发”“什么时候排期”“预算够不够”这些问题上。现在，非技术人做 AI 产品，拼的不是代码，是场景判断。一个业务人员、设计师、顾问，明明最懂用户、最懂场景、最懂流程，却往往离真正的产品构建最远。这也是为什么我看完 Zara Zhang 关于 vibe coding 的分享后，最大的感受不是“非技术人也能写代码了”。
Zara 在分享里讲到 Tab Out 这个产品案例，我印象很深。它解决的问题很简单：浏览器标签页太多，用户永远不会主动整理。一开始，她也尝试过更复杂的 AI 分类功能。听起来很高级，也很符合大家对 AI 产品的想象：自动分类、智能整理、帮你管理标签页。但后来她发现，这个功能自己根本不用。最后真正有效的方向反而很简单：不要强迫用户整理标签页，而是让“关闭标签页”这件事变得很爽、很有反馈感，甚至有点上瘾。这就是一个非常典型的服务设计视角。很多产品失败，不是因为功能不够高级，而是因为它假设用户会变得更自律、更理性、更愿意配合流程。但真实用户不是这样的。真实用户会忘，会懒，会绕路，会中断，会在压力下回到最熟悉的习惯。所以 AI 产品落地的第一步，不是问：“我们能不能加一个智能功能？”而是问：用户真正卡住的地方在哪里？他现在已经自然发生的行为入口在哪里？我们能不能把改变嵌入那个入口？这也是我现在做 AI 落地培训时最想强调的一点：不要一上来就做大而全的 AI 系统。先找到一个真实卡点，做一个小而准的行为改造。比如客服每天重复回答同样的问题，不要一上来就做“全能 AI 客服系统”，可以先做一个高频问题辅助回复工具。比如销售每天要判断客户意向，不要一上来就做“AI 销售总监”，可以先做一个客户线索分级助手。比如员工总是记不住 SOP，不要一上来就做“企业超级知识库”，可以先做一个流程问答机器人。AI 落地最怕的，不是做得太小。而是问题还没看清楚，就开始做一个看起来很大的系统。
二、AI 产品需要观点，而不是功能堆叠
Zara 还有一句话我很认同：有观点的产品，才有机会被记住。现在太多 AI 产品都在说自己是 all-in-one agent。能帮你处理工作，能帮你管理生活，能帮你写文案，能帮你做表格，能帮你查资料，能帮你自动执行任务。问题是，如果一个产品什么都能做，用户为什么不直接用 ChatGPT、Claude 或 Codex？真正能被记住的产品，背后一定有一个清晰观点。Frontend Slides 的观点是：不要再用传统 PPT，HTML 才是新的表达媒介。Tab Out 的观点是：浏览器不应该只鼓励你打开更多标签页，也应该让关闭变得有快感。Codebase to Course 的观点是：过去是先学习再构建，现在可以先构建再学习。这些产品不是简单地把 AI 加进去，而是在重新定义一个场景。这对企业 AI 转型也一样。很多企业一谈 AI 落地，第一反应就是：“我们要做 AI 客服。”“我们要做 AI 销售。”“我们要做知识库助手。”“我们要做自动写周报工具。”但这些只是功能名，不是产品观点。真正的问题应该是：我们的服务体验里，哪一个环节最消耗人？哪一种重复判断最容易出错？哪一类客户问题最影响转化？哪一个内部流程最需要被重新设计？哪一件事员工每天都在做，但其实并不需要人从头做一遍？AI 落地不是把 AI 塞进旧流程，而是借 AI 重新设计流程。这句话很重要。因为如果旧流程本身就是混乱的，AI 只会把混乱放大。如果企业原本没有清晰 SOP，没有统一判断标准，没有结构化知识，没有反馈机制，那么直接接入 AI，并不会自动带来效率提升。它最多只是让一个混乱的流程，看起来更智能。所以我越来越觉得，非技术人做 AI 产品，最重要的能力不是写代码，而是提出一个清晰的产品观点：这个产品到底反对什么？它想改变什么旧习惯？它希望用户用一种什么新方式完成任务？它要删除什么，而不是增加什么？这些问题，比“能不能接一个模型”更重要。
三、非技术人的价值不是写代码，而是提供判断
这场分享最打动我的地方，是 Zara 一直在强调 taste、opinion 和 workflow。AI 很擅长生成。你让它写代码，它可以很快写出第一版。你让它做页面，它可以很快生成一个界面。你让它搭一个工具，它也可以很快给你一个能跑起来的版本。但问题是，第一版通常都很粗糙。真正让产品变好的，不是 AI 自动完成了一切，而是人在不断反馈：这个不对。这里太复杂。这个按钮不应该放这里。这个流程用户不会这样走。这个功能应该删掉。这个视觉不像我要的感觉。这个结果看起来能用，但实际场景里没人会用。这些判断，才是非技术人的价值。很多企业做 AI 的误区，是以为买一个工具、接入一个模型、培训员工使用几个提示词，就能自动提效。但 AI 落地真正缺的，往往不是工具，而是判断标准。什么叫好？什么叫符合品牌？什么叫客户愿意用？什么叫员工真的会在流程里使用？什么功能应该保留？什么功能应该删除？什么场景适合 AI？什么场景必须保留人工判断？这些判断，来自行业经验、服务现场、客户观察和业务理解。所以我并不认为非技术人会因为 AI coding 而失去价值。恰恰相反，AI coding 让非技术人的经验第一次有机会被快速产品化。过去你的经验可能只能写成方案、SOP、培训材料、咨询报告。现在，这些经验可以进一步变成：一个 AI 工作流。一个内部自动化工具。一个客户服务辅助系统。一个销售决策助手。一个员工培训问答机器人。一个企业自己的 AI skill。也就是说，非技术人的核心价值，不再只是“提出建议”。而是把自己的经验，变成可复用、可执行、可迭代的系统。
四、服务设计可以变成 AI 产品构建方法
过去我做服务设计，最常用的方法是用户旅程、触点分析、服务蓝图、SOP 和培训机制。以前这些方法更多用于优化线下服务、组织流程和客户体验。但现在我越来越意识到，它们完全可以和 AI coding 结合起来，成为一种新的 AI 产品构建方法。比如：用户旅程里的卡点，可以转成一个 AI 原型。服务 SOP，可以转成一个可交互的 AI 工作流。培训材料，可以转成员工随时可用的问答助手。客户咨询中的高频问题，可以转成销售或客服的辅助决策系统。项目里的最佳实践，可以沉淀成企业自己的 AI skill。这其实是我接下来最想持续探索的方向：用服务流程思维，帮助企业把模糊的“AI 落地想法”，变成可以试、可以用、可以迭代的产品原型。在我看来，AI 产品落地的第一步，不是技术选型。不是先纠结用哪个模型。不是先讨论要不要上私有化部署。也不是一上来就做一个大而全的平台。第一步应该是：找到用户真正卡住的地方。然后把这个卡点拆成一个足够小、足够具体、足够容易验证的原型。只有真实使用发生了，反馈才会发生。只有反馈发生了，迭代才有方向。
五、我接下来要验证的三件事
看完这场分享后，我给自己定了三个方向。第一，从过往项目里提炼一批高频 AI 落地场景。比如获客、转化、客服、培训、SOP 执行、跨部门协作、客户复购、员工知识查询等。这些场景不一定都适合做大系统，但都可以先变成一个小而准的 AI 原型。第二，每周做一个自己的 AI 小工具。不追求一开始就商业化，也不追求功能完整，而是训练自己从问题识别、原型构建、真实反馈到持续迭代的完整能力。这件事对我来说很重要。因为未来真正懂 AI 落地的人，不应该只停留在“讲 AI 很重要”，而应该亲手做出一些东西。第三，建立一套 AI 落地诊断方法。我希望未来可以帮助企业先判断几个问题：这个场景到底适不适合 AI？用户入口在哪里？原来的流程哪里最浪费人？成功指标是什么？这个原型验证什么假设？失败了怎么调整？哪些经验可以沉淀成企业自己的 AI skill？这套方法，本质上不是教企业追热点，而是帮助企业把 AI 从一个抽象概念，变成真实业务里的效率杠杆。
结尾
看完 Zara Zhang 的分享，我更确信一件事：未来懂 AI 产品的人，不一定是最会写代码的人。而是那些最懂场景、最懂用户、最懂流程，并且愿意亲手把判断做成原型的人。AI coding 不是让非技术人假装自己是工程师。而是让非技术人第一次有机会，把自己对业务、用户和服务现场的理解，直接变成一个可以被使用、被验证、被迭代的东西。这才是我认为最值得兴奋的变化。因为当构建的门槛被 AI 降低之后，真正拉开差距的，就不再只是技术能力。而是你对问题的理解深度。你对用户行为的观察能力。你对流程的重构能力。以及你有没有勇气，亲手把自己的判断做出来。关注公众号领取codex教学、codex插件
基本文件流程错误SQL调试
请求信息 : 2026-06-20 18:42:06 HTTP/1.1 GET : https://www.yeyulingfeng.com/a/770117.html
夜雨聆风
