宝玉
13小时前
问:想问个问题,如果ToB的卡点是懂业务的和懂技术的不是一波人,在构建Agent的方式上,老板们就会倾向于通过低代码落地,但langchain新文章的逻辑又很扎实:低代码产品的空间在被模型能力和纯代码挤压,看起来这类产品似乎是过渡态。那整体未来的方向可能是什么呢?在企业里做低代码一定是沉没成本吗 答: 我的回答仅为抛砖引玉,供参考和一起讨论。 无论是低代码还是纯代码,最大的价值是快速验证可行性,前期把落地的路径跑通才是最重要的,某种程度上来说低代码可以弥补业务人员不懂技术的不足,但是局限性也很大,稍微偏离一点 happy path 就无法编排。 最理想的状态还是业务人员懂技术或者技术人员懂业务,但这很难,现在有 AI 了后,前期的落地业务人员是可以通过 AI 的辅助快速实现,搭建一个可行性的原型还是可以的,等到跑通了,再让专业技术人员去优化也很快。 个人观点和LangChain的类似,企业内不推荐在低代码上花功夫,还是业务人员借助 AI 或者和技术人员合作,搭建原型灵活性更大,更有可能做出真正适合企业的应用,而不是局限于低代码平台有限的能力。 另外现在 AI Agent,可行性更高的还是 WorkFlow,在原有验证过的 WorkFlow上用AI提效,或者借助AI衍生出新的更高效的WorkFlow,Agentic 方案还需要模型能力的进化,以及慢慢摸索出一些有效的交互方式会更靠谱,需要一点时间。
Y11
13小时前
最近五年,科技圈总有一些声音在说:“这一次,真的不一样了!”从元宇宙到Web3,从AI大模型到自动驾驶,每一次新技术冒头,似乎都被贴上“颠覆一切”的标签。 但如果我们静下心来看看,这些所谓的“改变一切”,其实都在沿着一条清晰的路径生长——那就是“解决问题”和“创造价值”这两个核心点。 就像当年互联网刚兴起时,人们争论它会如何颠覆一切,最后却发现,它更像是一个工具,让信息传递更高效,让连接更直接。 现在的新技术也一样,它们不是凭空出现的“新物种”,而是在前人探索的基础上,解决了更具体的痛点。 比如AI,它不是突然就“改变一切”,而是通过算法优化、算力提升和数据积累,让以前难以实现的功能变得可行,比如更聪明的客服、更精准的推荐,甚至是辅助科研发现。 这些变化,其实是在悄悄改变我们的生活和工作方式,让一些事情变得更简单,让一些梦想有了实现的可能。 真正的“改变一切”,往往不是一开始就喊出来的口号,而是在实践中慢慢渗透到我们生活的每个角落。 它可能不会让世界瞬间天翻地覆,但会像涓涓细流,逐渐汇聚成推动进步的力量。 而对于我们来说,与其追逐那些虚无缥缈的“颠覆”概念,不如关注这些技术能带来什么实际的好处,能不能让我们的生活更美好,能不能帮助更多人解决问题。 毕竟,无论是马云当年说的“让天下没有难做的生意”,还是张一鸣追求的“激发创造,丰富生活”,最终的落脚点,都是对“人”和“价值”的关注。 所以,下次再听到“这改变一切”时,不妨多问一句:“它具体改变了什么?又给我们带来了什么?”或许我们会发现,真正的进步,往往藏在这些细微的变化里,而不是喧嚣的口号中。
Y11
15小时前
软件工程师不必担心被人工智能取代,但要警惕一个更现实的挑战:未来他们可能需要维护由人工智能生成的、日益庞大的"遗留代码"。这一天正在加速到来。 一个典型的企业场景:某个部门为了快速上线新功能,调用AI工具自动生成代码。 这些代码可能在短期内解决了效率问题,但随着时间推移,问题逐渐浮现——代码注释模糊、模块间逻辑混乱、缺乏统一接口,甚至存在未被发现的bug。 当原始开发人员离职或转向新项目时,留在系统中的"AI代码"就成了烫手山芋。 这种情况正在多个行业真实发生。 某互联网公司的支付系统因AI生成代码出现逻辑漏洞,导致交易异常;某制造业企业的供应链管理系统因AI代码缺乏安全审计,被黑客利用。 这些案例揭示了一个核心矛盾:AI能快速生成代码,却难以保证代码的可维护性和可靠性。 对软件工程师而言,应对这种变化的关键在于转变思维。 与其纠结AI是否会"抢饭碗",不如主动学习如何与AI协作。 例如,利用AI生成基础框架,但保留核心业务逻辑的设计权;建立代码审查机制,对AI生成的代码进行安全和质量把关;将AI工具作为效率工具,而非完全依赖。 真正的风险从来不是技术取代人,而是人被技术的产物所困。 当AI生成的代码占据系统的大部分,工程师的价值将从"编写代码"转向"修复代码",甚至"重构代码"。 这要求从业者必须持续提升编程素养和系统思维,在拥抱新技术的同时,保持对代码质量的敬畏之心。 技术的进步从不意味着职业的消亡,而是能力边界的拓展。对于软件工程师来说,理解AI的本质、驾驭AI的工具,最终构建可靠的系统,才是面向未来的正确选择。
Y11
15小时前
近年来,不少企业在技术应用上存在一个常见倾向:他们更倾向于构建“人工的自己”来替代现有岗位,用自动化工具重复过去的工作流程,而非重新梳理优化旧有业务模式,以真正发挥技术的价值。 这种做法,就像古代为了替代战马而制造机械马——看似解决了“马”的问题,却没有从根本上改变运输的逻辑和效率。 比如有些公司引入智能客服系统后,只是简单将人工话术“搬”到机器上,结果客服效率没提升,反而因机器无法灵活应对复杂问题,导致用户投诉增多。 这正是陷入了“机械马误区”:没有思考如何通过技术重构服务流程,只是用新工具复制旧路径。 真正的技术变革,应该像互联网重构商业模式那样——不是让新工具去做旧事情,而是重新设计“怎么做”。 就像当年电商取代传统零售,不是简单把实体店“搬到线上”,而是利用网络特性创造了“人货场”的新连接方式。 同样,当我们谈论自动化时,更该问的是:“这个工作流程中,哪些环节可以被技术简化?哪些决策需要人类的经验和创造力?” 无论是马云在阿里推动的“大中台小前台”战略,还是张一鸣在字节跳动强调的“极致效率”,本质上都是在做“流程重构”。他们不执着于用技术替代人,而是通过数据中台整合资源,让每个业务单元更专注于创新和用户价值。这种思路,才是让技术真正成为“解放者”而非“替代者”的关键。 说到底,工具永远是手段,人的价值才是核心。与其费力打造“机械马”,不如先看看脚下的路是否需要重新规划——毕竟,真正的进步从来不是复制过去,而是创造未来。
Andy Stewart
18小时前
昨天开完会在车上培训公司同事 研发出身怎么获取项目管理和产品管理的能力? 方法很简单,遇到用户需求,不要只考虑表面反馈,要针对这个需求问底层原因,然后对底层原因再问下去,一直问3-5层,直到到底为止,最底下的原因就是真实需求。 得到真实需求后,一般尽量靠修改交互,简化流程来实现对用户的需求,而不是靠写代码武力解决。 为了达到培训目的,我给同事讲了我过去一个真实例子 2018年我从deepin linux离开,中间在家躺了半年,一个朋友要做智能售货柜,我带了3个人从硬件设计,操作系统开发,小程序商城开发,后台打标平台,工厂生产程序,硬件自动运维平台,半年内全部搞定。把硬件成本从6000多降到1800(柜子成本1500)。 他们原来开发商城时自己开发了IM、交易系统和打标系统,那个系统真的烂,bug百出,遇到我时,我根本没有写更多代码去解决这些bug。 我在白板后面思考了一上午,IM真实的需求是什么?根本不是聊天,发图片,语音这些。如果一个研发产品团队上下不动脑筋就会自然而然的开发这些功能。对于售货柜来说,IM本质是交易出现问题老板要和客户扯皮,不扯皮的话,你和柜子后面老板聊天吗?我做了什么?知道扯皮需求后,我只改了一处代码,在订单页面,老板可以看到顾客电话,顾客可以看到老板电话,但凡一方觉得有问题,给对方打电话,自己加微信解决。微信的功能不比你自己开发那个IM好多了?就这样化繁为简,顾客老板都满意,而且一个静态的电话号码是不会出bug的 还有就是交易系统,交易系统难的是你后面要对接微信支付宝和银行,每个系统退款机制不一样,你写交易程序一来会出很多bug,二来这些退款有延迟的时候,客户就要来骂你,最麻烦的时,进款和退款会导致商家对账非常麻烦,商家会觉得系统难用。那我又做了啥?我设计了交易系统只进钱不出钱,要补差价和退款,老板和客户微信联系,微信可以发红包。这样一来,不退款系统就没那么多bug,而且老板对账很简单,这个月所有进账总额减去微信红包就好了,因为发红包的时候是老板自己沟通的,他印象深刻,他就不会对着原来莫名其妙的退款账目找售货柜厂商了 最后一个就是打标平台,客户买了东西,要远程人工识别。原来团队每天思考怎么搞一堆售后去扛峰值,这样导致饭点时后台打标人很多,顾客工作时,打标人大量闲置,成本巨大浪费。我问为啥这样设计?回答说,这样可以保证实时结算。又是不动脑筋的研发。我说,实时结算重要吗?对方跟我说了一堆啥用户体验鬼话。我回答他说,人性不是这样的,人性最期望你免费。我说,用户不是有微信信用分担保嘛,你怕啥?他拿了货,你先不要给他扣款,你就显示订单结算中,不要去扣他款,所有用户看到这里,他都会想,这个柜子有意思,买了东西不扣款,最好他一直结算中。这样你原来30个人打标成本最后换成一个人就好了,你晚2个小时给他扣款,用户根本就不着急。运维人员成本降低了多少?95% 我讲完这个故事,给研发同事说,看到没?这就叫做深入思考,一个顶尖的将军,讲的不是武艺高强,写多少牛逼的代码去解决伪需求,而是深入思考,不战而屈人之兵才是最好的策略