勃勃OC
1个月前
Susan STEM
1个月前
我在这方面的看法和迈克很接近,正好今天也想谈谈。如今,无论在职还是不在职,开发者都必须全方位调整自己的业务与工作范式,因为这个问题迟早要面对,而且很多范式已经进入倒计时阶段。今天看了木头姐的讲座,她也在强调这一点。我甚至认为一大批计算机专业毕业生,可能正好赶上范式转变期,再加上学费贷款等现实压力,没法停下来进行再调整,结果将来可能再也无法从事本专业。 我自己也处在调整期,没有人能准确告诉你未来的范式究竟会如何,所以我也不再劝别人去学计算机了。问题在于,一切发展得太快了。 我既不是冒险家,也不是保守派。从小接受的教育是,要站在信息浪头,但同时找一个安全的地方藏身。我认为,现在开发者面临的最大风险,就是投入大量时间开发的成果,可能会被模型的内化浪潮瞬间淹没。因此,除了手上那个“工程”(暂时不透露),我不会再启动任何新的开发项目,而是将主要精力转向“符号”。 我目前的重心是“符号积累”。 我其实这段时间一直在讲这个事情,包括as code, 协议,其实都是未来范式中“符号”的一部分。 我的目标是不跟风、不试错、零浪费。 作为一个中英文符号高手(咳咳😅),在AI前途和盈利模式不确定的阶段推演出多条可深耕的路径,我有两层: 范式不依赖层(无论技术走向如何都成立) 范式对接层(某些方向一旦成熟,可以立刻切入) 在法律与合规、金融与风控、医疗与健康、制造与供应链、教育与培训、能源与基础设施等领域——这些我过去多次提到过的方向——都普遍存在“范式不依赖层”。简单来说,就是那些目前已经以自然语言存在、但仍需要大量工作才能转化为人机共通语言的领域。例如,将法律条款进行逻辑结构化处理,转化为清晰的 If–Then 条件链,就是一种典型的范式不依赖层工作。否则就算真正Rule as Code那一天到来了,也是符号缺失的。
宝玉
1个月前
转译:为什么大语言模型无法真正构建软件 作者:Conrad Irwin 我花了大量时间做的一件事就是面试软件工程师。这显然是项艰巨的任务,我不敢说自己有什么绝招;但这段经历确实让我有时间去反思,一个高效的软件工程师究竟在做什么。 软件工程的核心循环 当你观察一个真正的行家时,你会发现他们总在循环执行以下几个步骤: * 构建一个关于需求的心理模型。 * 编写(希望如此?!)能够实现需求的代码。 * 构建一个关于代码实际行为的心理模型。 * 找出两者之间的差异,然后更新代码(或需求)。 完成这些步骤的方式有很多种,但高效工程师的过人之处,就在于他们能够构建并维持清晰的心理模型。 大语言模型表现如何? 平心而论,大语言模型在编写代码方面相当出色。当你指出问题所在时,它们在更新代码方面也做得不错。它们还能做所有真人工程师会做的事:阅读代码、编写并运行测试、添加日志,以及(大概)使用调试器。 但它们无法做到的是,维持清晰的心理模型。 大语言模型会陷入无尽的困惑:它们会假设自己写的代码真的能用;当测试失败时,它们只能猜测是该修复代码还是修复测试;当感到挫败时,它们干脆把所有东西删掉重来。 这与我所期望的工程师特质恰恰相反。 软件工程师会边工作边测试。当测试失败时,他们可以对照自己的心理模型,来决定是修复代码还是修复测试,或者在做决定前先收集更多信息。当他们感到挫败时,可以通过与人交流来寻求帮助。尽管他们有时也会删掉一切重来,但那是在对问题有了更清晰理解之后才会做出的选择。 但很快就行了,对吧? 随着模型能力越来越强,这种情况会改变吗?也许吧??但我认为这需要模型在构建和优化方式上发生根本性的变化。软件工程需要的模型,不仅仅是能生成代码那么简单。 当一个人遇到问题时,他们能够暂时搁置全部的上下文,专注于解决眼前的问题,然后再恢复之前的思绪,回到手头的大问题上。他们也能够在宏观大局和微观细节之间自如切换,暂时忽略细节以关注整体,又能在必要时深入研究局部。我们不会仅仅因为往自己的“上下文窗口”里塞进更多词语,就变得更高效,那只会让我们发疯。 即便我们能处理海量的上下文,我们也知道当前这些生成式模型存在几个严重的问题,这些问题直接影响了它们维持清晰心理模型的能力: * 上下文遗漏:模型不擅长发现被忽略的上下文信息。 * 新近度偏见:它们在处理上下文窗口时,会受到严重的新近度偏见影响。 * 幻觉:它们常常会“幻想”出一些本不该存在的细节。 这些问题或许并非无法克服,研究人员也正在努力为模型增加记忆,让它们能像我们一样施展类似的思维技巧。但不幸的是,就目前而言,它们(在超出一定复杂度后)实际上无法理解到底发生了什么。 它们无法构建软件,因为它们无法同时维持两个相似的“心理模型”,找出其中的差异,并决定是该更新代码还是更新需求。 那么,现在该怎么办? 显然,大语言模型对软件工程师来说很有用。它们能快速生成代码,并且在整合需求和文档方面表现出色。对于某些任务来说,这已经足够了:需求足够清晰,问题足够简单,它们可以一蹴而就。 话虽如此,对于任何有点复杂度的任务,它们都无法足够精确地维持足够的上下文,来通过迭代最终产出一个可行的解决方案。你,作为软件工程师,依然需要负责确保需求清晰,并保证代码真正实现了其宣称的功能。 在 Zed,我们相信未来人类和 AI 智能体可以协同构建软件。但是,我们坚信(至少在目前)你才是掌控方向盘的驾驶员,而大语言模型只是你触手可及的又一个工具而已。
sitin
1个月前
这几个月的AI出海实践,让我总结出几个关键点: 1. 从小切口开始 不要想着做平台,先做一个解决具体问题的小工具。比如专门帮设计师生成特定风格的图片,专门帮程序员生成测试用例等。 有很多人一开始就想做"中国版的ChatGPT",结果陷入无穷无尽的功能开发中。相反,那些专注于解决一个具体问题的产品,往往更容易获得用户认可。 小切口的好处显而易见:开发周期短、用户需求明确、容易做到极致、更容易获得第一批种子用户。 2. 重视用户反馈 海外用户很愿意给反馈,要善于倾听并快速迭代。就有一些产品因为固执己见而错失机会。 这一点和国内用户差别很大。海外用户,特别是欧美用户,他们习惯于主动表达意见,会告诉你哪里好用,哪里不好用,甚至会建议你应该加什么功能。 这种反馈是金矿,要建立快速响应机制,用户提出合理建议,争取在一周内就能看到改进。 3. 营销同等重要 好产品也要会吆喝。Reddit、Twitter、Product Hunt这些平台的运营策略,和技术开发同等重要。 很多程序员朋友觉得只要产品做得好,用户自然会来。这在AI出海领域是行不通的。 海外用户获取信息的渠道和习惯与国内不同。Reddit上的相关社区、Twitter的话题讨论、Product Hunt的产品发布,这些都需要精心运营。 酒香也怕巷子深,如果没有营销,再好的产品也无人问津。 4. 现金流优先 不要追求完美产品再收费,先让产品产生现金流,再持续优化。 这一点对程序员来说特别重要,因为我们天生有完美主义倾向,总想着功能再完善一点再上线。 但在AI出海领域,MVP(最小可行产品)思维更重要。先让产品产生哪怕1美元的收入,证明商业模式可行,然后再持续迭代。 有了现金流,你就有了持续优化的动力和资源,也有了与用户对话的基础。