Author: aitrendtrackers@rengongzhineng.io

2025年8月28日，多家媒体报道，微软正在公开测试其首个完全自主训练的大语言模型——MAI-1-preview。这一举措不仅意味着微软试图减少对OpenAI的依赖，也可能加剧两家公司之间的竞争。 微软AI部门首席执行官Mustafa Suleyman表示，MAI-1-preview是公司从头到尾独立训练完成的首个基础模型。目前，该模型已在LMArena网站上对外开放测试，用户可以在平台上进行评估。微软还发布了开发者申请表，允许有兴趣的团队申请提前体验。公司计划未来几周将该模型逐步应用到Copilot的部分文本场景中，以便通过用户反馈不断优化。 长期以来，微软的Bing搜索引擎、Windows 11操作系统以及其他核心产品，主要依赖OpenAI的模型来驱动AI功能。微软本身也是OpenAI的最大投资方之一，已累计投入逾130亿美元，同时为OpenAI提供云计算基础设施支持。然而，在微软2024年的年度报告中，OpenAI已被列入竞争对手名单，与亚马逊、苹果、谷歌和Meta并列。与此同时，OpenAI也在逐渐拓展合作伙伴，近期开始依赖CoreWeave、Google和Oracle等公司提供的算力，以应对ChatGPT每周覆盖7亿用户的庞大需求。 在LMArena的排名中，MAI-1-preview在文本任务上位列第13，落后于Anthropic、DeepSeek、Google、Mistral、OpenAI和xAI的模型。不过微软强调，该模型训练依托了约15,000块Nvidia H100 GPU，并已配备运行中的Nvidia GB200芯片集群。Suleyman在社交平台X上表示，公司对未来有着宏大的规划，包括模型的进一步提升、算力的扩展以及通过微软产品触达数十亿用户的愿景。 在推出MAI-1-preview之前，微软曾发布过一系列小型开源语言模型Phi。但此次的新模型，被视为微软真正意义上的首个完全自主基础模型。值得注意的是，Suleyman本人曾是Google收购的AI研究公司DeepMind的联合创始人，后来创立了Inflection AI，并在2024年率领大部分团队成员加盟微软。这一背景，使得微软AI团队在近几个月迅速扩张，其中包括约二十名来自DeepMind的专家。 这一动作显示，微软一方面仍与OpenAI保持深度战略合作关系，另一方面也在加快自研模型的步伐，力图在未来的AI竞争中掌握更大主动权。

Martin Fowler在2025年8月28日发表文章，分享了他对大语言模型（LLM）与软件开发现状的一些思考。在准备休假和处理部分工作事务前，他总结了近期的观察与感受。 他提到，目前已有一些关于AI对软件开发影响的早期调查，试图回答它是否真的加快了开发进度，或是否改善或破坏了代码质量。然而，Fowler认为这些调查存在显著缺陷，因为它们往往没有考虑开发者实际使用LLM的工作流程。从他的观察来看，大多数使用场景仍然停留在“高级自动补全”，常见于Co-pilot工具。但那些真正从LLM中获得最大价值的开发者，往往会采用更直接的方式，让LLM读取和编辑源代码文件，从而完成具体任务。他担忧，如果忽视这些使用差异，调查数据会误导行业方向。 关于“编程的未来”这一常见提问，例如：现在是否还值得进入软件开发行业？LLM会不会取代初级工程师？高级工程师是否该提前退出？Fowler直言，没人能给出确切答案，任何声称“知道未来走向”的人都不可信。当前仍处于探索阶段，如何高效利用LLM尚无定论，尤其是在模型仍有可能获得显著提升的情况下。他建议，开发者应主动尝试这些工具，阅读他人经验，并关注其中的工作流程细节，甚至分享自己的实践。 关于AI是否是泡沫，他给出了肯定回答：“当然是泡沫。”他指出，从运河、铁路到互联网，每一次重大技术进步都伴随着经济泡沫。可以预见，AI热潮也会破裂，大量投资最终归零。未知的是泡沫破裂的时间，可能在下个月，也可能还需几年。但就像互联网泡沫一样，许多公司会消亡，但也会有企业幸存并壮大，就像亚马逊在pets.com和Webvan倒下后依然屹立。 他还提到自己已从公共演讲中退休，但仍期待在即将举行的GOTO Copenhagen大会上与老朋友相聚。他自上世纪90年代（当时该会议称为JAOO）起就参与其中，至今仍对会议的高质量议程保持赞赏。 Fowler引用前同事Rebecca Parsons的观点，认为“幻觉”不是LLM的缺陷，而是其核心特征。LLM的本质就是生成幻觉，只是有时这些幻觉对用户有用。因此，在使用LLM时，可以尝试多次提问，甚至让模型比较不同回答的差异，这些差异本身也可能有价值。尤其在涉及数值时，应至少询问三次，以评估其变动范围。同时，他提醒，不应让LLM直接计算确定性答案，而更适合让它生成计算所需的代码，再由开发者执行和验证。 他指出，传统的软件工程基于确定性机器，而其他工程学科早已习惯处理世界的不可预测性。例如，结构工程会为无法测量的因素留出容差，流程工程会考虑到人的疏忽或失误。随着LLM引入软件开发，或许意味着软件工程正迈入“非确定性”的新阶段。 在类比上，他提到人们常将LLM比作初级同事，但不同的是，LLM可能会轻易回答“所有测试通过”，而实际运行时却失败。若这是初级工程师的行为，HR可能早已介入。 安全性则是另一个严峻问题。他引用Simon Willison的观点，警示“AI代理的致命三合一风险”：访问私人数据、接触不可信内容，以及对外部世界的通信（数据外泄）。例如，若让LLM读取网页，攻击者可能通过隐形文字（如1pt白字）植入恶意指令，诱导LLM泄露敏感信息。更严重的情况是，当AI代理在浏览器中运行时，可能被欺骗去访问银行账户并转账。Willison因此认为，“基于代理的浏览器扩展从根本上存在致命缺陷，不可能安全实现。” 整体来看，Martin Fowler的思考强调了三个核心：一是现有调查和认知的局限性，行业对LLM实际作用的理解仍不充分；二是AI泡沫不可避免，但幸存者或许会成为未来的巨头；三是LLM的本质与风险，既带来新可能，也引入非确定性与安全隐患。 在他看来，行业需要更多实践、反思与警惕，才能真正理解并驾驭LLM在软件开发中的角色。

自去年10月公开测试以来，已有数千名开发者使用Realtime API并推动其优化。与传统的语音处理管道（将语音转文字，再由语言模型生成文字，最后再转为语音输出）不同，Realtime API能够直接通过单一模型处理和生成音频，从而减少延迟、保留语音细节并实现更自然的互动。 多家企业已开始尝试该技术。例如，Zillow的AI负责人Josh Weisberg表示，新模型在处理复杂请求方面表现更佳，如根据生活方式需求筛选房源或结合融资工具指导购房预算，这让找房体验更接近自然对话。 gpt-realtime模型的主要改进包括： Realtime API的新功能： 在安全与隐私方面，Realtime API内置多层防护机制，实时检测潜在违规对话并可终止，开发者也能利用Agents SDK增加额外的安全约束。此外，服务禁止输出被用于垃圾信息、欺骗或其他有害用途，并要求开发者明确告知用户何时与AI交互。该API已全面支持欧盟数据本地化，并遵循企业级隐私承诺。 价格方面，OpenAI宣布gpt-realtime的价格比之前的gpt-4o-realtime-preview降低20%：音频输入为每百万tokens 32美元（缓存输入为0.40美元），输出为每百万tokens 64美元。开发者还可通过智能上下文控制和多轮截断来降低长会话的成本。 目前，开发者可在官方文档中查看Realtime API的使用说明，在Playground中测试新模型，并参考提示指南来快速上手。

当前职场中AI工具的强制使用正逐渐成为一个令人担忧的趋势。虽然这篇文章不是该平台通常发布的内容类型，但作者认为，这一话题对行业发展极其重要，尤其是对于开发者而言。 文章指出，越来越多的开发人员被要求或被鼓励在工作中使用AI工具。这种趋势并非源自技术进步的自然融合，而往往是由公司高层推动，甚至带有强制色彩。为了深入了解这一现象，作者在社交媒体上发起了调查，并与多位开发者和设计师进行了匿名访谈。 一位来自科学行业的开发者分享说，其主管要求他们将代码粘贴到ChatGPT中进行结构与性能优化建议。这种做法虽初衷为提高效率，但实际上却外包了代码审查的职责。一些初级开发者因此陷入调试困境，因为AI生成的代码经常无法运行，而主管仅仅依赖ChatGPT反馈，而不做深入审查。 在某些公司中，甚至面试问题都交由AI生成，且多人共用一个ChatGPT账户，导致公司内部出现大量非正式、难以追溯的沟通记录。一些员工开始有意识地使用“会自动消失”的聊天记录功能以保护自己，这种行为显然反映了对现状的深层不安。 另一位在创意代理机构任职的团队负责人透露，该公司试图转型为“AI优先”的企业，全面推动AI在品牌塑造、文案写作、设计及开发等领域的使用。公司高层甚至暗示，不接受这一转变的员工将“不再适合留在这里”。这种文化在团队内部引发了明显的不安全感和压力，尤其是当管理层以“使用AI的开发者会取代你”为“激励”口号时，更显得如同威胁。 在另一家小型数字代理机构中，一位设计师则表示，虽然AI工具并未直接用于最终的设计输出，但在早期创意构思、研究和文案撰写阶段已被广泛采用。该设计师曾试图表达对这种趋势的担忧，却因此被贴上“难相处”的标签。尽管后来在某些工具的使用上做出妥协，但仍坚持在客户项目中保持透明，确保披露使用AI工具的情况。 在一家全球零售巨头的技术部门中，AI工具的引入被视为组织发展战略的一部分。尽管目前尚未出现因拒绝使用AI而失业的情况，但该公司正在迅速试点多种AI工具，以应对即将到来的工作方式转型。一位软件工程师指出，AI确实在某些方面提高了工作效率，但同时也增加了新的压力，例如在短时间内掌握新工具，以及在AI辅助下出现更多“边缘性bug”。 有开发者提到，前公司CTO因偏爱Claude Code工具而强制团队使用它进行编码、测试、调试及系统设计验证。然而，该工具常常提供模糊或无效的反馈，令团队疲于奔命。更严重的是，一些主管将AI工具输出视为“设计验证”的依据，完全忽视了AI工具无法真正分析复杂技术问题的局限性。 文章强调，AI工具的本质是“语言模型”，擅长模式识别和语言生成，却不具备创造性和批判性思维。举例而言，Google的AI摘要功能曾引用Reddit上的玩笑评论，建议人们在披萨酱中添加胶水，这种错误说明AI无法辨别信息的真实意图与语境。 面对这一局面，作者提出了一些现实建议：在AI工具带来问题、延误或失败时，应及时记录每一个相关决策、责任人及自身的专业意见，尤其是当这些决策并非出自个人意愿时。这些记录在潜在的纪律处分或劳动仲裁中，将是个人重要的自保手段。 根据麻省理工学院（MIT）的一项研究，目前高达95%的生成式AI试点项目以失败告终，另有研究显示，即便开发人员认为AI提升了效率，实际工作速度反而变慢。这些数据表明，当前AI热潮很可能只是一个泡沫或炒作周期，而真正为此付出代价的，将是普通从业者。 因此，文章呼吁技术从业人员采取积极的防御策略，如加入工会，以集体力量保障自身权益。在这一泡沫破灭之前，尽可能维护自己的职业安全。 最后，作者坦言，尽管对话过程十分有价值，但撰写本文却充满挣扎。其核心观点并非出自对AI工具的偏见，而是基于长期实际使用后的理性判断：AI工具在多数情况下并未带来真正的助力，反而加剧了混乱。尽管个别场景中确有价值，但若将其强加于团队成员，则很可能适得其反。 AI工具的合理使用应基于自愿与实际效果，而非盲目追风。强迫使用AI，只会导致技术文化的倒退与员工士气的崩溃。在这一背景下，最重要的建议是：提前做好准备，保护自己。

在当今这个数据驱动的世界中，数据库构成了现代应用程序的基础，无论是移动应用，还是企业级系统，数据库始终发挥着至关重要的作用。了解不同类型数据库的特性与应用场景，对于从事个人项目开发还是架构企业级解决方案的技术人员而言，都是极其重要的。 什么是数据库？ 数据库是一种结构化的数据集合，通过电子方式进行存储，并由数据库管理系统（DBMS）进行管理。数据库能够高效地存储、检索与管理结构化和非结构化数据，为应用程序的正常运行提供坚实的基础。 数据库的选择对于系统性能、可扩展性、一致性及数据完整性有着深远影响。现代应用程序依赖数据库来组织数据，并确保用户能够快速、可靠地访问所需信息。 现代数据库的主要类型 1. 关系型数据库（RDBMS） 关系型数据库通过表格形式组织数据，表格由行与列组成，并通过主键与外键建立数据之间的关系。这类数据库遵循ACID原则（原子性、一致性、隔离性、持久性），并使用SQL进行数据查询。 2025年最新发展： 最佳应用场景：金融系统、电子商务、企业应用、商业分析。主流平台：MySQL、PostgreSQL、Oracle Database、Microsoft SQL Server、IBM Db2、MariaDB。 2. NoSQL数据库 NoSQL数据库打破了传统的表格结构，支持灵活的数据格式，适合处理半结构化与非结构化数据。 关键类型： 2025年亮点： 适用场景：实时分析、推荐系统、物联网、社交平台、流数据处理。 3. 云数据库 云数据库部署在云平台上，提供弹性扩展、高可用性、自动化管理服务，并适配DevOps及无服务器环境。多以DBaaS（数据库即服务）形式交付。 主流平台：Amazon RDS、Google Cloud SQL、Azure SQL Database、MongoDB Atlas、Amazon Aurora。 为何选择云数据库？ 4. 内存数据库与分布式SQL数据库 内存数据库（如SAP HANA、SingleStore、Redis）将数据存储于RAM中，实现极快访问速度，适合实时分析与高频交易。 分布式SQL数据库（如CockroachDB、Google Spanner）结合关系型数据库的一致性与NoSQL的横向扩展能力，支持跨地域部署及全球复制。 5. 时序数据库 此类数据库专为处理时间序列数据而设计，如传感器数据或金融市场波动数据，强调高速写入、压缩与时序查询能力。 代表平台：InfluxDB、TimescaleDB。 6. 面向对象数据库与多模型数据库 面向对象数据库（如ObjectDB）直接映射到面向对象的代码结构，适用于多媒体或自定义业务逻辑场景。 多模型数据库（如ArangoDB、SingleStore）集成文档、键值、列式与图数据库功能，为复杂场景提供极大灵活性。 7. 专用与新兴数据库类型 2025年主流数据库亮点功能一览 数据库平台 近期关键特性 最佳用途 MySQL JSON架构验证、向量搜索、SHA-3加密、OpenID Connect…

苹果公司即将启动一项为期三年的计划，旨在彻底重塑其标志性的iPhone产品线，这将成为近年来最重要的产品变革之一。据悉，苹果将在即将举行的秋季发布会上揭开这一系列变革的序幕，包括首次推出全新型号“iPhone Air”，以及后续将在2026年和2027年推出的可折叠iPhone和曲面玻璃iPhone。 当前iPhone外观与五年前的产品相比变化不大，尽管边角略有调整、颜色有所变化，摄像头模块也更为突出，但整体设计风格几乎保持一致。这种设计保守的策略导致消费者对新一代iPhone的购买动机逐渐从“外观吸引”转向“功能刚需”，如电池老化、屏幕破裂或对更高质量的拍照和视频功能的需求。 苹果决定改变这一局面。从2025年起，公司将连续三年推出重大设计更新的iPhone产品。首款产品“iPhone Air”将在今年9月亮相，它将取代现有的iPhone 16 Plus型号。iPhone Air延续了苹果2008年推出MacBook Air时的轻薄理念，采用更纤薄、更轻巧的设计，并因其差异化外观和命名策略而更具市场传播力。 不过，这款新产品也将做出一些权衡：电池续航能力有限，仅配备一个后置摄像头，且取消了实体SIM卡槽。更重要的是，iPhone Air将首次采用苹果自主研发的调制解调器芯片，代替此前采用的高通芯片。 除了iPhone Air，苹果还将同步推出iPhone 17、17 Pro和17 Pro Max系列。整体外观与iPhone 16相似，但Pro系列将在背部设计和摄像系统上进行小幅调整，并新增橙色配色方案（Air版本则为浅蓝色）。尽管更新幅度有限，但Pro系列依然是苹果的销售主力，预计今年销量不会受到太大影响。 更具变革意义的是2026年预计发布的可折叠iPhone。该设备代号为V68，其设计类似三星的书本式折叠手机，展开后可用作小型平板电脑。V68将配备四枚摄像头（前置、内屏和两枚后置），同样取消SIM卡槽，并采用Touch ID而非Face ID，略显复古。但预计该设备将受到苹果忠实用户的热烈追捧。苹果供应商已在准备该产品的生产计划，预计明年初量产，以配合秋季发布。 苹果还在对其可折叠iPhone的屏幕技术进行调整，原计划采用“on-cell”触控方案，但因可能导致屏幕折痕明显，目前公司正转向“in-cell”技术，这将更接近现有iPhone的触控体验，有助于减轻折痕并提升触控精准度。 而在2027年，苹果将推出一款纪念iPhone诞生20周年的“iPhone 20”，它将首次采用全曲面玻璃设计，彻底摆脱自2020年以来延续至今的直角边框造型。这款手机将与即将推出的基于Liquid Glass技术的iOS新系统完美结合，成为软件与硬件融合的又一里程碑。 尽管2025年不会带来彻底的革命性变化，但其意义在于为未来两年的重大转型奠定基础。 除iPhone外，苹果今年秋季还将推出多款产品更新，包括Apple Watch系列、搭载M5芯片的iPad Pro、全新AirPods Pro（支持心率监测功能）、更新版HomePod mini和Apple TV机顶盒等。此外，明年还计划推出入门级iPhone 17e、新款低端iPad和iPad Air、搭载M5芯片的MacBook Pro和Air，以及新一代外接显示器等。 更令人关注的是，苹果还计划进入一个全新的产品类别——配备屏幕的HomePod智能音箱。这款产品将运行一个名为“Charismatic”的家庭中枢操作系统，旨在与亚马逊和谷歌在智能家居领域展开竞争。 展望未来，苹果的研发方向包括不配备显示屏的智能眼镜、桌面机器人、更轻更便宜的头显设备、带摄像头的AirPods、可折叠iPad-Mac二合一设备，以及家庭安防系统等。 虽然产品线日益多元化，但iPhone仍是苹果所有业务的核心，而这项升级计划表明，它仍将长期处于苹果战略布局的中心位置。 在服务业务方面，苹果正通过新增订阅项目和涨价策略以维持营收增长。该部门目前年收入约达1000亿美元，成为iPhone之外利润最丰厚的业务领域。 面对App Store监管加强、应用内支付政策调整，以及与谷歌高达200亿美元的搜索合作协议可能被法庭叫停的风险，苹果已采取一系列应对措施。 例如，公司于7月推出AppleCare One订阅服务，每月收费20美元，涵盖三台设备的维修保障。同时，Apple TV+的月费也从9.99美元上调至12.99美元，尽管内容有所扩展，但相比竞争对手仍存在差距。未来还将推出AI驱动的Apple Health+健康订阅服务，提供营养规划与医疗建议。 在人工智能方面，苹果目前正处于是否继续独立研发AI模型还是采用外部技术的决策阶段。据悉，公司正与谷歌、Anthropic及OpenAI展开合作谈判。特别是与Anthropic的合作已延伸至内部开发工具和部分消费级功能，例如为开发者版Xcode引入Claude AI。 近期，苹果还与谷歌商讨在私有云架构上部署Gemini模型，以协助提升Siri语音助手的响应能力。尽管尚未做出最终决定，但管理层正认真考虑采用第三方方案。 在AI人才方面，苹果近期流失严重，仅过去两个月内已有6位核心成员跳槽至Meta，包括基础设施团队的重要高管Frank Chu和AI模型负责人Ruoming Pang。此现象部分反映出苹果在AI战略上的困境，以及Meta开出的高额薪资所产生的强大吸引力。 此外，关于为何AirPods Max迟迟未更新的问题，业内分析认为该产品销量介于“尚可与不够”之间，既不足以被淘汰，又不值得投入大量资源进行彻底升级。目前，该产品仅因欧盟法规新增了USB-C版本。苹果的音频团队更倾向于优先更新销量更大的入耳式AirPods系列及其配套音箱、麦克风产品。 至于苹果即将推出的智能眼镜，业内人士普遍看好其市场前景。凭借在音频与摄像技术方面的深厚积累，以及对iPhone的深度整合能力，苹果有望在功能上全面超越Meta的同类产品。而最终成败或将取决于产品定价策略。 最后，关于Vision…

在2025年，大型语言模型（LLMs，参数≥30B，通常通过API访问）与小型语言模型（SLMs，约1–15B，通常为开源或专有模型）之间，并不存在“一统天下”的解决方案。银行、保险公司以及资产管理机构在选择语言模型时，需综合考量监管风险、数据敏感性、延迟与成本要求以及使用场景的复杂性。 在结构化信息提取、客户服务、代码辅助及内部知识任务中（特别是结合RAG技术和强防护机制时），推荐优先采用SLM。若面对复杂的信息综合、多步骤推理，或SLM无法满足性能标准而成本和延迟可接受时，再考虑升级使用LLM。 无论模型大小如何，金融机构都必须将LLM和SLM纳入模型风险管理（MRM）框架，遵循NIST AI风险管理框架（AI RMF），并确保如信用评分等高风险应用与欧盟AI法案的合规义务相对应。 1. 监管与风险态势 金融服务业受到成熟的模型治理标准约束。在美国，联邦储备委员会、货币监理署（OCC）及联邦存款保险公司（FDIC）联合发布的SR 11-7适用于所有用于商业决策的模型，包括LLM和SLM。这意味着无论模型大小，都必须进行验证、监控和文档记录。NIST发布的AI RMF 1.0已成为AI风险控制的黄金标准，并广泛应用于传统与生成式AI的管理。 在欧盟，AI法案已正式生效，并设定了分阶段的合规时间表：2025年8月起针对通用模型，2026年8月起针对高风险系统（例如附录III所列的信用评分）。高风险模型需符合上市前一致性评估、风险管理、日志记录与人工监督等要求。计划进军欧盟市场的金融机构需相应调整整改时间表。 核心行业数据规定同样适用： **重点：**高风险应用（如信贷、承保）必须实施严格控制，无论模型参数数量如何。所有模型都应进行可追溯的验证、隐私保障及合规管理。 2. 能力、成本、延迟与部署足迹权衡 SLMs（3–15B）在经过微调与RAG增强后，已能在金融领域工作负载中提供高准确率。例如Phi-3、FinBERT、COiN等模型在信息提取、分类与流程增强方面表现出色，同时延迟控制在50毫秒以下，且适合自托管，满足数据本地化部署需求，甚至可在边缘设备上运行。 LLMs则擅长跨文档信息整合、异构数据推理及长上下文处理（>100K tokens）。像BloombergGPT（50B）这类领域专用LLM，在金融基准测试和多步骤推理任务中远超通用模型。 从计算经济学看，Transformer模型的自注意力机制在序列长度增加时呈二次增长，虽然FlashAttention和SlimAttention等优化技术可降低计算成本，但无法打破理论下限。长上下文的LLM推理成本可能远高于短上下文的SLM。 **重点：**短文本、结构化、对延迟敏感的任务（如呼叫中心、理赔处理、KYC信息提取、知识搜索）适合SLM。如果任务需要处理10万以上的tokens或进行复杂信息整合，应预算使用LLM，并通过缓存和选择性“升级”策略控制成本。 3. 安全性与合规性权衡 两类模型都面临常见风险：提示注入、输出处理不安全、数据泄露及供应链风险。 在解释性方面，所有高风险应用必须具备透明特征、挑战模型、完整决策日志和人工监督。LLM的推理路径记录不能代替SR 11-7或欧盟AI法案所要求的正式验证。 4. 部署模式 金融机构已成功采用三种部署策略： 无论采用哪种模式，均须配套实施内容过滤、PII信息去识别、最小权限连接器、输出验证、红队测试与持续监控，参考NIST AI RMF与OWASP标准。 5. 决策矩阵（快速参考） 评估标准 推荐使用SLM 推荐使用LLM 监管风险 内部支持类、非决策类应用 高风险场景（如信用评分），需完整验证 数据敏感性 本地部署、虚拟私有云、符合PCI/GLBA 外部API，需DLP、加密与数据处理协议支持 成本与延迟 毫秒级响应、高请求频率、成本敏感型应用 可接受秒级延迟、批处理、低请求频率 任务复杂性 信息提取、内容路由、RAG草稿生成辅助 信息整合、模糊输入、长篇文本处理 工程部署 自托管、支持CUDA集成 托管API、管理供应商风险、快速上线 6. 典型应用场景 7….

Dropbox 正在将人工智能（AI）从单一工具转变为全流程协作伙伴——不仅帮助工程师自动化重复性任务，还显著降低摩擦、释放专注力，加速内部创新。Dropbox 首席技术官 Ali Dasdan 和工程生产力高级总监 Uma Namasivayam 在本次专访中分享了他们如何通过明确的战略部署与文化建设，在 2025 年实现了 90% 工程师团队的 AI 使用率，领先业内平均水平。 AI 是 Dropbox 工程团队核心生产力工具 Ali Dasdan（CTO）表示：AI 在 Dropbox 不再只是实验工具，而是提升工程效率的核心引擎。它不仅帮助减少会议时间、加快编码节奏，还覆盖了测试生成、调试、代码审查与事故响应等多个开发流程关键环节。 从最初的编码助手起步，Dropbox 正不断扩展 AI 能力至整个软件生命周期，这也是 AI 工具覆盖率能迅速提升至 90% 的关键所在。 从冷淡到广泛使用：AI 落地的转折点 Uma Namasivayam 指出：尽管早在 2023 年末就引入 GitHub Copilot，最初的使用率却始终处于低位，2024 年也只是小部分工程师在使用。 转折点发生在 2025 年初： 通过这些组合拳，AI 工具逐渐成为工程团队的“默认选择”。 衡量成效：数据驱动 + 文化驱动并行 Uma 分享落地经验： 自研 vs 外部：谁该做，谁该买？…

随着通用人工智能（AGI）、超人工智能（ASI）和通用人形机器人似乎越来越接近现实，是时候认真探讨这场技术革命对经济的冲击了。我们是否将被迫过上无所事事且缺乏意义的“闲暇生活”？是否只有极少数仍有工作的“人类工人”被贬为 API 接口之下的螺丝钉？又或是，我们将迎来“全自动奢侈同性恋太空共产主义”的美好世界？ 这篇文章是对五年前“后稀缺社会与后资本主义”相关讨论的续篇，旨在探讨 AI 对经济结构的再塑过程。 凯恩斯的预言快成真了吗？ 凯恩斯在 1930 年曾预测，到 2030 年，自动化将使人类的工作时间减少到每周 15 小时。如今看来，这个预言部分成真： 然而凯恩斯也有预言精准之处：资本积累确实极大地推动了 GDP 和生活水平的跃升，甚至可能还低估了人类发明新需求与新消费形式的能力。 AI 是“工具”的放大器，不是直接的接班人 大型语言模型（如 GPT）等被视为“类 AGI”工具，作为人类认知的延伸，显著提升工作效率。但作者指出： 这种少数精英的极高产出能力将放大他们对“有限资源”的竞争，可能进一步加剧稀缺品的价格通胀。 商品类型的四象限模型 文章引入一个核心模型，将商品划分为四种类型： 需求可饱和 需求不可饱和 具竞争性（rivalrous） 房屋、基础食品、带资质教育、监管下托育 土地、医疗、学历教育 非竞争性（non-rivalrous） 显示器、高质量电子产品、汽车、现代食品 软件、航空、推理算力、机器人军队 随着科技进步，我们将越来越多商品从“稀缺”转换为“充裕”，但问题也随之产生——少数超级高效者在竞争“永远稀缺”的领域（如房产、医疗资源）时，可能把其他人“挤出去”。 通胀悖论：我们越富有，有些东西反而更贵 尽管总体财富提升，一些稀缺资源（如住房、医疗、土地）仍持续涨价，其原因包括： 我们可以通过官僚式配额控制、累进税收等方式来“均衡分配”，但这通常会带来普遍贫困而非真正的公平。 案例分析：技术如何打破旧的“稀缺陷阱” ✅ 食品的去稀缺化 历史上，粮食是竞争性 + 可饱和的资源，容易引发饥荒。随着人工化肥与机械农业发展，今天的食品已充足到你我在 Costco 随意购买都不影响彼此。这是科技彻底转变社会结构的经典范例。 ✅ 医疗的技术突围 ✅ 土地与住房的扩容可能性 政策挑战：如何不制造“被抛弃者” 若 AI 超用户阶层财富暴增，社会若无配套措施，有可能制造出**“被技术抛弃者”阶层**。这将导致： 技术跃迁期的正确姿势 为避免“科技进步，民众贫困”的悖论，文章建议：…

在整个软件开发行业，越来越多的开发者开始使用 AI 编码助手来加快工作节奏，工具如 Junie、GitHub Copilot、ChatGPT 和 Claude 等正在被广泛采用。然而与此同时，我们也看到了许多令人咋舌的“灾难现场”：从潜伏的 bug 溜过代码审查、到因为错误架构决策导致的大规模返工，再到 AI 生成代码引发的安全漏洞成为头条新闻。这些问题很多时候源于初级开发者盲目复制粘贴 AI 的建议，却并不理解代码的含义。 但我们该把责任归咎于谁？是工具本身，用户水平，还是开发流程设计存在更深层的问题？为了寻找答案，作者在多种真实场景下测试了 AI 编码助手，最终得出一个核心结论：AI 就像一个初级开发者，它需要一个经验丰富的技术负责人来带领。 起步阶段：AI 就像靠谱的搜索引擎 作者最初使用 AI 编码助手来解答编程问题，结果令人惊喜。AI 能提供清晰解释与可运行的示例代码，逐渐成为问题排查的首选工具。尤其像 GitHub Copilot 等工具，在自动补全上表现出色，能根据代码上下文完成大量样板逻辑，甚至能识别项目中的编码风格与结构模式。 作者指出，AI 不再是一个新奇的玩具，而成为真正省时省力的开发工具。 初遇 Junie：一场令人抓狂的失败体验 尽管其他开发者高度推荐 Junie，作者一开始对这个“新宠”极为失望。Junie 消耗额度飞快、生成的代码无法通过构建、不断浪费时间，甚至连基础功能都无法完成。作者几乎想直接放弃。 但与此同时，许多可信赖的高级开发者却表示他们使用 Junie 效果非常好。他们不仅能生成清晰、可运行的代码，甚至还能借助 AI 解决复杂问题和调试难题。 问题不在工具，而在用法。 关键认知转折：AI 是初级开发者，不是资深工程师 作者意识到：自己之前像对待一位经验丰富的高级开发者那样对待 AI，期望它理解项目背景、编码风格、业务逻辑甚至架构偏好，却忽略了它实际上缺乏经验与判断力。 举例来说，作者第一次任务是让 AI 重构一批 PHP 的 DTO 类，使用 readonly 和构造函数属性推广（constructor promotion）等新特性。结果 Junie…