即刻App年轻人的同好社区
下载
其实大家都在卷 AI，聊 AI，我也在聊 AI，但是对于我来说，AI 对我来说是生存，不是生活，我不喜欢这种天天追着跑，天天变的东西，而且未来只会越来越趋于同质，没有任何人味，我想要做点回归生活，做点回归人味，回归生活的内容
8 00
我觉得学习AI的最佳路径,不是用各种AI工具，做各种乱七八糟的产品,这种上线即结束的做法,只会让自己停留在表面的AI技法,天花板很低,有价值的是找一个领域,构建一个从需求分析-构建产品-获取反馈-迭代产品的一整个商业闭环,可以从一个小的点切入,公司没这样的环境,那就自己造,在这个过程中,哪怕没获得什么商业的收益,也能驱动你逐步进入大多数人接触不到的AI应用的深水区,打磨一款产品一年好过于一年做几十款产品,但可惜,很多人满足于后者的奇技淫巧!
4 00
都说什么Al native的年轻人,会把玩各种AI工具,我不知道有什么用,就像现在,有谁还会讲互联网,会招一个所谓很懂互联网的人?我相信大家更愿意找一个资深的行业玩家吧?别迷失在用AI造出各种玩具的幻境中,踏踏实实在某个行业深耕,看AI如何持续赋能这个行业,踩出来的各种坑才是你的核心,AI这些所谓的技巧,在一两年大家都会慢慢趋同!
3 10
最近我们在做一个企业尽调智能体。说实话，一开始我没太当回事，就觉得丢给模型跑跑就行了，现在的模型那么强，还有什么做不了的？
但做着做着，我卡住了。一个非常根本的问题摆在面前——我们团队没有一个人真正懂尽调。
不懂意味着什么？意味着模型之外你能做的事情非常有限。数据不知道该怎么处理，知识库不知道要搭什么，甚至都不清楚什么样的输出才算"合格"。因为你不懂这个领域的标准，你连验收的标准都没有。模型吐出来的东西，你觉得好像还行，但到底行不行，你说不准。
公司倒是有做尽调的人，你可以去咨询他们、调研他们。但说实话，咨询跟真正参与到项目里、为结果负责，完全不是一码事。对业务人员来说，你的咨询就是个负担——他手头还有自己的KPI，你的项目做成了跟他没关系，做砸了也跟他没关系。所以他最多敷衍一下，告诉你大概方向，不会坐下来帮你一起想这个功能应该怎么设计、那个指标应该怎么算、什么数据源是靠谱的什么是不靠谱的。
做不到这个程度，你还做什么智能体？模型就是个大脑，你连该喂它什么信息、该怎么喂都不知道，这个大脑再聪明也是空转。
· · ·
后来我停下来想了一下，这不是我们一个团队的问题。
现在很多企业做AI，默认的姿势就是：找一个懂技术的团队，调一个大模型，写一堆提示词，然后以为就完事了。至于业务经验？有就有，没有拉倒，反正模型那么强。
但如果你真的下场做过，你会发现这个想法根本站不住脚。问题有三层。
第一，AI对于非公开的业务经验，几乎一无所知。
模型训练的数据是公开的，互联网上能扒到的它都见过。但一家企业真正值钱的东西，从来不在公开资料里。什么数据该用、什么数据该扔，什么指标能算、什么指标算了是误导，什么场景该走A流程、什么场景该走B流程——这些判断标准散落在员工的脑子里、文档里、聊天记录里、会议纪要里，模型根本接触不到。
这些就是业务上下文。模型连你的业务上下文都不知道，你让它怎么帮你做决策？
你需要的是一群懂业务的人，把这些经验提炼出来，浓缩成有效信息，在有限的上下文窗口里塞给模型。提炼和浓缩这四个字听着简单，实际上比写代码难得多——你不懂业务，你提炼什么？你连什么东西重要、什么东西不重要都分不清。
第二，模型不擅长计算，也不擅长处理复杂逻辑。
这是很容易被忽略的一点。大模型本质上是个语言模型，它玩的是文字接龙，不是真的理解规则。比如你要它算一个企业的资产负债率，它可能会给你一个数字，看上去有模有样，但那个数字是接龙接出来的，不是真正用财务公式算出来的。你说这能用吗？
真正靠谱的做法，是你先用程序把计算逻辑写好，算好了再喂给模型，让它去解读和输出。但问题在于：算什么、怎么算、算完怎么用——这三步里，每一步都需要业务专家的经验。如果没有人告诉你这个行业应该算哪些指标、权重怎么分配、异常值怎么识别，你的程序写出来也是瞎算。
这还只是计算。如果你面对的是一个跑了好几年的老系统，里面的业务规则是多年来一块块补丁叠上去的，那更麻烦。因为这些规则不是一条条写在文档里的，是写在代码里的，而且写得很乱。你丢给AI让它去理解，它理解不了的。最后还是得人来梳理——而梳理这些逻辑的人，必须是懂业务的。
第三，如果只是丢给模型就能做，那你的产品有什么核心竞争力？
这个问题的残酷之处在于：大家都能调API，大家都能写提示词，大家都能搭RAG。如果不需要做任何额外的处理就能做出一个产品，那凭什么你做的东西别人做不出来？你的护城河在哪里？
我现在的判断是：真正有壁垒的AI产品，壁垒一定不在模型本身。模型是大家的，甚至可能过两个月别人的模型就比你的强了。但你在一个垂直领域里积累的非公开数据、业务规则、处理逻辑、工作流设计——这些别人拿不走，模型自己也不会，因为它们不在任何公开资料里。
你做得越通用，越没有竞争力。因为通用意味着谁都能做，意味着用户可以直接用WorkBuddy、用扣子、用任何通用工具，为什么非要用你的？越是企业级的应用，越要往垂直和定制化的方向走。但垂直的前提是什么？是你真的懂这个垂直领域。
· · ·
反过来想一下：如果一个团队真的懂这个垂直领域，做出来的AI会是什么样？
首先，他们知道哪些数据是关键数据、哪些是噪音。不会一股脑把所有数据都灌进去，而是会做筛选和清洗——该聚合的聚合，该剔除的剔除，该补全的补全。这个东西模型不会帮你做，它只会基于你给它的数据去推理。垃圾进垃圾出。
其次，他们知道这个领域的判断逻辑是什么。比如做尽调，你拿到一个企业的工商信息之后，先看什么、后看什么、什么指标异常了要重点深挖、什么指标看着不对但实际上可以解释——这是一套有先后顺序、有权重分配的判断流程。不懂业务的人做出来，可能就是平铺直叙地把所有数据列一遍，跟百度百科似的，用户看了跟没看一样。
第三，他们知道输出给谁看、对方要什么。尽调报告给风控官看的，和给业务部门看的，和给老板看的，格式完全不同。风控要的是数据来源和推理逻辑，业务要的是结论和风险点，老板要的是结论加建议。这些对输出格式和内容的理解，没有业务经验你根本不知道。
所以你看，有业务经验和没有业务经验，做出来的东西根本不是同一个产品。前者是一个有判断逻辑、有筛选机制、有输出标准的专业工具；后者就是一个"什么都给你但什么都不准"的半成品。
· · ·
那到底该怎么做？
我的答案其实很简单，但很难执行：业务团队必须领头，而不是被"咨询"。
回到尽调智能体的例子。最好的做法是什么？是高层推动，让做尽调的业务人员正式进入项目组，为项目结果负责。不是"有空了帮我们看看"，而是"这就是你的工作，做不好是你的问题"。角色变了，态度就变了——从敷衍变成认真，从帮忙变成责任。
而且不只是"参与"这么简单。业务人员要做的是：把你们脑子里那些隐性的经验往外掏。什么数据源是靠谱的、什么判断标准是行业默认的、什么场景容易出错、什么输出格式是客户要的——这些东西，没人比你更清楚。你把它整理出来，AI团队才有办法把它工程化，变成系统能执行的逻辑。
这个过程很痛苦，因为隐性知识变成显性知识本来就是一个很累的事。但你不做，AI就永远只能停在"看起来还行"的水平。
还有一点。做出第一个版本不是目的，能持续可用才是。模型会出错，客户会反馈，政策会变化，数据源会失效——你得有机制去回溯问题、修正错误、持续迭代。而这些，同样需要懂业务的人来判断：这个错误是模型的问题，还是业务规则的问题？这个反馈意味着要调整什么？
没有业务经验的人，连这些判断都做不了。
· · ·
我之前还操盘过一个金融领域的SaaS产品，从零到一搭起来的。回想起来，那个产品最核心的从来不是用了什么技术、接了什么接口，而是我对这个行业足够了解——我知道获客链路怎么走，知道交易结构怎么设计，知道合规边界在哪里，知道客户的真实痛点是什么、哪些是表面问题不能花时间、哪些是根本问题必须死磕。
这些判断力，模型能辅助，但不能替你做决定。因为这些判断依据太私有了——不在任何公开资料里，不在任何教程里，是在行业里摸爬滚打、摔了无数次跤之后慢慢长出来的直觉。
就像医生看病。学了理论之后，你得看过各种病人，见过各种疑难杂症，才知道怎么处理。AI就像刚学完所有教科书的医学生，知识面比你广得多，但你问它"这个病人到底怎么回事"，它只能根据书上写的给你一个"最可能"的答案。而你知道，真实的病人从来不按教科书生病。
你就是那个看过真实病人的医生。你的价值不在知识量，在临床经验。在你知道书本之外的那些"奇怪但就是这个"的判断。
· · ·
所以我现在越来越确定一件事。
AI时代，真正值钱的不是"会用AI"，而是"有业务经验，并且还懂AI"。
会用AI的人满大街都是。写个提示词、搭个工作流、调个API——门槛太低了。一个刚毕业的新人加上AI辅助，也能在短时间内做出看起来像模像样的东西。你在这个层面跟他们卷，卷不过，也没必要卷。
你的优势在哪里？在于你在真实环境里做了那么多年的项目，踩过各种坑，见过各种疑难杂症。你知道AI在什么场景下能打、什么场景下不能打、它的短板该怎么补。你知道什么是AI能替代的、什么是只有人才能做的判断。
这些东西，才是你的竞争力，才是AI替代不了的。
所以别光想着"我要学AI"——你脑子里那些行业经验、那些踩过的坑、那些说不清道不明的直觉，就是你的AI竞争力。
把它喂给AI，让AI做你的手脚。你的大脑，是你自己的经验。
但做着做着，我卡住了。一个非常根本的问题摆在面前——我们团队没有一个人真正懂尽调。
不懂意味着什么？意味着模型之外你能做的事情非常有限。数据不知道该怎么处理，知识库不知道要搭什么，甚至都不清楚什么样的输出才算"合格"。因为你不懂这个领域的标准，你连验收的标准都没有。模型吐出来的东西，你觉得好像还行，但到底行不行，你说不准。
公司倒是有做尽调的人，你可以去咨询他们、调研他们。但说实话，咨询跟真正参与到项目里、为结果负责，完全不是一码事。对业务人员来说，你的咨询就是个负担——他手头还有自己的KPI，你的项目做成了跟他没关系，做砸了也跟他没关系。所以他最多敷衍一下，告诉你大概方向，不会坐下来帮你一起想这个功能应该怎么设计、那个指标应该怎么算、什么数据源是靠谱的什么是不靠谱的。
做不到这个程度，你还做什么智能体？模型就是个大脑，你连该喂它什么信息、该怎么喂都不知道，这个大脑再聪明也是空转。
· · ·
后来我停下来想了一下，这不是我们一个团队的问题。
现在很多企业做AI，默认的姿势就是：找一个懂技术的团队，调一个大模型，写一堆提示词，然后以为就完事了。至于业务经验？有就有，没有拉倒，反正模型那么强。
但如果你真的下场做过，你会发现这个想法根本站不住脚。问题有三层。
第一，AI对于非公开的业务经验，几乎一无所知。
模型训练的数据是公开的，互联网上能扒到的它都见过。但一家企业真正值钱的东西，从来不在公开资料里。什么数据该用、什么数据该扔，什么指标能算、什么指标算了是误导，什么场景该走A流程、什么场景该走B流程——这些判断标准散落在员工的脑子里、文档里、聊天记录里、会议纪要里，模型根本接触不到。
这些就是业务上下文。模型连你的业务上下文都不知道，你让它怎么帮你做决策？
你需要的是一群懂业务的人，把这些经验提炼出来，浓缩成有效信息，在有限的上下文窗口里塞给模型。提炼和浓缩这四个字听着简单，实际上比写代码难得多——你不懂业务，你提炼什么？你连什么东西重要、什么东西不重要都分不清。
第二，模型不擅长计算，也不擅长处理复杂逻辑。
这是很容易被忽略的一点。大模型本质上是个语言模型，它玩的是文字接龙，不是真的理解规则。比如你要它算一个企业的资产负债率，它可能会给你一个数字，看上去有模有样，但那个数字是接龙接出来的，不是真正用财务公式算出来的。你说这能用吗？
真正靠谱的做法，是你先用程序把计算逻辑写好，算好了再喂给模型，让它去解读和输出。但问题在于：算什么、怎么算、算完怎么用——这三步里，每一步都需要业务专家的经验。如果没有人告诉你这个行业应该算哪些指标、权重怎么分配、异常值怎么识别，你的程序写出来也是瞎算。
这还只是计算。如果你面对的是一个跑了好几年的老系统，里面的业务规则是多年来一块块补丁叠上去的，那更麻烦。因为这些规则不是一条条写在文档里的，是写在代码里的，而且写得很乱。你丢给AI让它去理解，它理解不了的。最后还是得人来梳理——而梳理这些逻辑的人，必须是懂业务的。
第三，如果只是丢给模型就能做，那你的产品有什么核心竞争力？
这个问题的残酷之处在于：大家都能调API，大家都能写提示词，大家都能搭RAG。如果不需要做任何额外的处理就能做出一个产品，那凭什么你做的东西别人做不出来？你的护城河在哪里？
我现在的判断是：真正有壁垒的AI产品，壁垒一定不在模型本身。模型是大家的，甚至可能过两个月别人的模型就比你的强了。但你在一个垂直领域里积累的非公开数据、业务规则、处理逻辑、工作流设计——这些别人拿不走，模型自己也不会，因为它们不在任何公开资料里。
你做得越通用，越没有竞争力。因为通用意味着谁都能做，意味着用户可以直接用WorkBuddy、用扣子、用任何通用工具，为什么非要用你的？越是企业级的应用，越要往垂直和定制化的方向走。但垂直的前提是什么？是你真的懂这个垂直领域。
· · ·
反过来想一下：如果一个团队真的懂这个垂直领域，做出来的AI会是什么样？
首先，他们知道哪些数据是关键数据、哪些是噪音。不会一股脑把所有数据都灌进去，而是会做筛选和清洗——该聚合的聚合，该剔除的剔除，该补全的补全。这个东西模型不会帮你做，它只会基于你给它的数据去推理。垃圾进垃圾出。
其次，他们知道这个领域的判断逻辑是什么。比如做尽调，你拿到一个企业的工商信息之后，先看什么、后看什么、什么指标异常了要重点深挖、什么指标看着不对但实际上可以解释——这是一套有先后顺序、有权重分配的判断流程。不懂业务的人做出来，可能就是平铺直叙地把所有数据列一遍，跟百度百科似的，用户看了跟没看一样。
第三，他们知道输出给谁看、对方要什么。尽调报告给风控官看的，和给业务部门看的，和给老板看的，格式完全不同。风控要的是数据来源和推理逻辑，业务要的是结论和风险点，老板要的是结论加建议。这些对输出格式和内容的理解，没有业务经验你根本不知道。
所以你看，有业务经验和没有业务经验，做出来的东西根本不是同一个产品。前者是一个有判断逻辑、有筛选机制、有输出标准的专业工具；后者就是一个"什么都给你但什么都不准"的半成品。
· · ·
那到底该怎么做？
我的答案其实很简单，但很难执行：业务团队必须领头，而不是被"咨询"。
回到尽调智能体的例子。最好的做法是什么？是高层推动，让做尽调的业务人员正式进入项目组，为项目结果负责。不是"有空了帮我们看看"，而是"这就是你的工作，做不好是你的问题"。角色变了，态度就变了——从敷衍变成认真，从帮忙变成责任。
而且不只是"参与"这么简单。业务人员要做的是：把你们脑子里那些隐性的经验往外掏。什么数据源是靠谱的、什么判断标准是行业默认的、什么场景容易出错、什么输出格式是客户要的——这些东西，没人比你更清楚。你把它整理出来，AI团队才有办法把它工程化，变成系统能执行的逻辑。
这个过程很痛苦，因为隐性知识变成显性知识本来就是一个很累的事。但你不做，AI就永远只能停在"看起来还行"的水平。
还有一点。做出第一个版本不是目的，能持续可用才是。模型会出错，客户会反馈，政策会变化，数据源会失效——你得有机制去回溯问题、修正错误、持续迭代。而这些，同样需要懂业务的人来判断：这个错误是模型的问题，还是业务规则的问题？这个反馈意味着要调整什么？
没有业务经验的人，连这些判断都做不了。
· · ·
我之前还操盘过一个金融领域的SaaS产品，从零到一搭起来的。回想起来，那个产品最核心的从来不是用了什么技术、接了什么接口，而是我对这个行业足够了解——我知道获客链路怎么走，知道交易结构怎么设计，知道合规边界在哪里，知道客户的真实痛点是什么、哪些是表面问题不能花时间、哪些是根本问题必须死磕。
这些判断力，模型能辅助，但不能替你做决定。因为这些判断依据太私有了——不在任何公开资料里，不在任何教程里，是在行业里摸爬滚打、摔了无数次跤之后慢慢长出来的直觉。
就像医生看病。学了理论之后，你得看过各种病人，见过各种疑难杂症，才知道怎么处理。AI就像刚学完所有教科书的医学生，知识面比你广得多，但你问它"这个病人到底怎么回事"，它只能根据书上写的给你一个"最可能"的答案。而你知道，真实的病人从来不按教科书生病。
你就是那个看过真实病人的医生。你的价值不在知识量，在临床经验。在你知道书本之外的那些"奇怪但就是这个"的判断。
· · ·
所以我现在越来越确定一件事。
AI时代，真正值钱的不是"会用AI"，而是"有业务经验，并且还懂AI"。
会用AI的人满大街都是。写个提示词、搭个工作流、调个API——门槛太低了。一个刚毕业的新人加上AI辅助，也能在短时间内做出看起来像模像样的东西。你在这个层面跟他们卷，卷不过，也没必要卷。
你的优势在哪里？在于你在真实环境里做了那么多年的项目，踩过各种坑，见过各种疑难杂症。你知道AI在什么场景下能打、什么场景下不能打、它的短板该怎么补。你知道什么是AI能替代的、什么是只有人才能做的判断。
这些东西，才是你的竞争力，才是AI替代不了的。
所以别光想着"我要学AI"——你脑子里那些行业经验、那些踩过的坑、那些说不清道不明的直觉，就是你的AI竞争力。
把它喂给AI，让AI做你的手脚。你的大脑，是你自己的经验。
35 412
前端时间我觉得，要做一个 金融领域的 通用agent 平台，然后可以将各种各样的 skill 都往里面装，由模型去自由调度，现在我的想法有点改观。
其实很多垂直领域的业务并不需要那么灵活，就是一个很垂类的场景，而且需要跟已有的系统打通，并且交互方式不一定都是对话，可能还是要融入一些传统的交互方式，如果用通用的那种 agent，反而稀释了垂直场景的独特性，体验不友好。
所以，越是企业级的应用，越要注重独特性，定制化，跟 C 端消费者不一样，你做的太通用，反而失去了优势，大家都去用 workbuddy 就好了，为什么要用你的。
其实很多垂直领域的业务并不需要那么灵活，就是一个很垂类的场景，而且需要跟已有的系统打通，并且交互方式不一定都是对话，可能还是要融入一些传统的交互方式，如果用通用的那种 agent，反而稀释了垂直场景的独特性，体验不友好。
所以，越是企业级的应用，越要注重独特性，定制化，跟 C 端消费者不一样，你做的太通用，反而失去了优势，大家都去用 workbuddy 就好了，为什么要用你的。
7 00
智能体其实是一个上层应用，对于已经有很多业务系统的公司来说，其实不需要一开始对业务系统进行大改造，这样试错成本太高了，可以在业务系统的更上层再架构一个智能体层，智能体通过对话的交互方式来调度业务系统已经有的能力就可以了。
这个灵感来源于，我们最近要做一个新的智能体，领导的表面意思是做一个新的系统，如果我只是按照表面意思去做，那我就相当于抛开所有已存在的业务系统，从零到一去构建一个新的东西，包括账户体系、结算体系等等都要重新搭建，但是这个智能体明明是需要用到已有业务系统的很多能力的，从零开始搭建系统不划算，所以，其实我要做的并不是要做一个新系统，而是做一个新的上层应用，已有的业务系统只是作为一个底层能力可供调用而已，这样就不会重复造轮子，后续新的智能体也在这个底座上进行构建。
所以，有时候，系统架构思维很重要，不是每个领导都能够很耐心地跟你讲清楚他到底要什么，可能就是一句话的事，他有他自己的理解，但是他不会掰开了揉碎了跟你讲清楚，你需要思考他本质要的是什么，然后用自己觉得更合适的方式来实现，否则，久而久之，产品就会被做成四不像。
这个灵感来源于，我们最近要做一个新的智能体，领导的表面意思是做一个新的系统，如果我只是按照表面意思去做，那我就相当于抛开所有已存在的业务系统，从零到一去构建一个新的东西，包括账户体系、结算体系等等都要重新搭建，但是这个智能体明明是需要用到已有业务系统的很多能力的，从零开始搭建系统不划算，所以，其实我要做的并不是要做一个新系统，而是做一个新的上层应用，已有的业务系统只是作为一个底层能力可供调用而已，这样就不会重复造轮子，后续新的智能体也在这个底座上进行构建。
所以，有时候，系统架构思维很重要，不是每个领导都能够很耐心地跟你讲清楚他到底要什么，可能就是一句话的事，他有他自己的理解，但是他不会掰开了揉碎了跟你讲清楚，你需要思考他本质要的是什么，然后用自己觉得更合适的方式来实现，否则，久而久之，产品就会被做成四不像。
5 20
很多人学习AI的方式存在误区，比如追求快速制作各种产品却缺乏深度。我看到网上很多AI博主热衷于在短时间内开发大量不同方向的产品，比如20分钟做一个应用，一个月做几十个项目，涉及日记、闹钟、聊天工具、自媒体文案工具等各种类型，甚至尝试制作AI短片或技能。我也曾这样尝试过，涉足APP、技能、网站、短片等多个领域，但一段时间后发现自己在AI认知上并没有实质性提升，仍然停留在表面。
作为AI产品经理，我在工作中接触的AI系统相对复杂，但当遇到实际落地难题时，却发现自己无法给出有效解决方案。尽管投入大量时间从零开始开发AI应用，但这些经验却难以应用到职场工作中。问题在于这些项目都只是浅尝辄止，没有深入探索更复杂的层面。和大多数AI博主一样，我往往在项目上线后就转向下一个，没有持续使用、迭代和优化。
如果不深入使用产品，就无法发现问题，也就无从寻找解决方案。这样就无法了解AI产品在长期发展过程中会遇到哪些挑战，以及相应的解决方法。比如：上下文窗口占满如何处理？AI持续出现幻觉怎么办？如何确保AI稳定调度工具？什么情况下该用RAG？何时仅需提示词就能解决？选择skill还是mcp？只有在持续解决问题的过程中反复验证，才能获得这些认知。
如果只是不断开发新产品而不深入使用，做再多项目也没有意义。与其一年做100个不同产品，不如专注打磨一款产品能获得更多认知。因此我决定停止目前所有项目，未来几个月到一年内只专注开发一款产品。不追求商业化结果，而是作为深度用户持续使用，发现问题并解决，从而提升AI落地相关的认知，为未来从事AI行业打下坚实基础。接下来我会持续分享在打磨产品过程中获得的AI认知。
作为AI产品经理，我在工作中接触的AI系统相对复杂，但当遇到实际落地难题时，却发现自己无法给出有效解决方案。尽管投入大量时间从零开始开发AI应用，但这些经验却难以应用到职场工作中。问题在于这些项目都只是浅尝辄止，没有深入探索更复杂的层面。和大多数AI博主一样，我往往在项目上线后就转向下一个，没有持续使用、迭代和优化。
如果不深入使用产品，就无法发现问题，也就无从寻找解决方案。这样就无法了解AI产品在长期发展过程中会遇到哪些挑战，以及相应的解决方法。比如：上下文窗口占满如何处理？AI持续出现幻觉怎么办？如何确保AI稳定调度工具？什么情况下该用RAG？何时仅需提示词就能解决？选择skill还是mcp？只有在持续解决问题的过程中反复验证，才能获得这些认知。
如果只是不断开发新产品而不深入使用，做再多项目也没有意义。与其一年做100个不同产品，不如专注打磨一款产品能获得更多认知。因此我决定停止目前所有项目，未来几个月到一年内只专注开发一款产品。不追求商业化结果，而是作为深度用户持续使用，发现问题并解决，从而提升AI落地相关的认知，为未来从事AI行业打下坚实基础。接下来我会持续分享在打磨产品过程中获得的AI认知。
7 10
最近我们领导去上了一个AI 工具的课，然后 vibe coding 了一个 CRM 系统，他瞬间就被震惊到了，想不到 AI 能干出一个这么复杂的系统，于是乎大周末晚上的在公司群里分享他的劳动成果，可惜群里无一响应，气得他在群里大发雷霆，觉得这么牛逼的事情你们怎么都不激动？
其实我的老板不是个例，很多没有深入使用 AI 的老板，都会被 AI 做出来的这种产品惊艳到，觉得以后再也不需要程序员了，一个人就可以干 100 个人的活，但实际上是，大部分所谓的不懂编程vibe coding 做出来的东西，顶多是一个很简单的玩具，根本无法支撑起一个可以长期迭代的商业化产品，做一版就结束了，后面根本改不动，到了后面基本都得专业的程序员来进行重构。
所以，现在的 vibe coding，顶多是 AI 辅助编程，还是需要专业的程序员来驾驭他，不懂程序的人顶多用来做个 demo 方便验证想法或者演示，无法真正投入生产使用，有了 vibe coding 可以做到提高人效，减少人力投入，但无法真正替代人。
无论AI 再强，我觉得语言是有边界的，你要 Ai 完全实现你脑子里的想法，前提是你要能够用语言完全表达出来，但是你跟人沟通过程中就知道，有些事情真的就只能意会无法言传，那你又如何能够期待 AI 能够完全理解你脑子里的想法呢，所以，完全替代人这个就不现实。
还有一点就是，很多公司的系统是陈年老系统，里面有很多打了又打的补丁，有很多盘根错节的逻辑，丢给 AI 根本看不懂，之前我们数科系统要做对账的功能，评估的工时比较多，领导居然说数科系统的代码都丢给 AI，让 AI 去写，简直是扯淡。
其实我的老板不是个例，很多没有深入使用 AI 的老板，都会被 AI 做出来的这种产品惊艳到，觉得以后再也不需要程序员了，一个人就可以干 100 个人的活，但实际上是，大部分所谓的不懂编程vibe coding 做出来的东西，顶多是一个很简单的玩具，根本无法支撑起一个可以长期迭代的商业化产品，做一版就结束了，后面根本改不动，到了后面基本都得专业的程序员来进行重构。
所以，现在的 vibe coding，顶多是 AI 辅助编程，还是需要专业的程序员来驾驭他，不懂程序的人顶多用来做个 demo 方便验证想法或者演示，无法真正投入生产使用，有了 vibe coding 可以做到提高人效，减少人力投入，但无法真正替代人。
无论AI 再强，我觉得语言是有边界的，你要 Ai 完全实现你脑子里的想法，前提是你要能够用语言完全表达出来，但是你跟人沟通过程中就知道，有些事情真的就只能意会无法言传，那你又如何能够期待 AI 能够完全理解你脑子里的想法呢，所以，完全替代人这个就不现实。
还有一点就是，很多公司的系统是陈年老系统，里面有很多打了又打的补丁，有很多盘根错节的逻辑，丢给 AI 根本看不懂，之前我们数科系统要做对账的功能，评估的工时比较多，领导居然说数科系统的代码都丢给 AI，让 AI 去写，简直是扯淡。
28 112
