宝玉
2个月前
像 Claude Code、Codex 这样的“AI Coding Agent”,能交付高质量代码,这已经不是新鲜事,但这给软件开发带来的真正改变是什么呢? 硅谷顶尖风投 a16z 最近发了一篇文章:《价值万亿的 AI 软件开发新“战局”(The Trillion Dollar AI Software Development Stack)》,文章的重点不是 AI 会不会写代码,也不是它会不会抢走程序员的饭碗。真正的重点是,AI 正在把“软件开发”这件事,从一个“手艺活”彻底重塑为一个全新的、价值万亿美金的“工业体系”。 为什么是“万亿美金”?我们来算一笔账。 全球大概有 3000 万名软件开发者。假设每人每年创造 10 万美金的经济价值(这在美国算保守了),那整个软件开发业的经济贡献就是 3 万亿美金。 去年的时候,像 Copilot 这样的 AI 助手,就已经能给程序员带来大概 20% 的效率提升。 但这只是开胃菜。a16z 估计,一套“顶配”的 AI 开发系统,至少能让开发效率翻倍。这意味着什么?这意味着每年能凭空多创造出 3 万亿美金的价值。这是个什么概念?这相当于法国全年的 GDP。 这就是为什么资本会如此疯狂,为什么这个领域被称为“战国时代”。 那么,这个价值万亿的“新工业体系”到底长什么样?a16z 给出的这张流程图(图1 )就是答案。 这张图的核心,不再是“人去写代码”,而是 AI 全面参与的“计划 -> 编码 -> 审查”新循环。 第一步:AI 帮你“想清楚”(计划与架构) 过去,我们以为 AI 编程是这样的:你对它说“给我写个登录函数”,它给你一段代码,你复制粘贴。 在新的工作流里,AI 从项目最最开始的“产品经理(PM)”和“架构师”阶段就介入了。 你给 AI 一个模糊的需求(比如“我想做个用户反馈系统”),AI 的第一反应不是写代码,而是反过来向你提问: - “用户反馈需要打分吗?” - “需要上传图片吗?” - “数据要存在哪里?” - “需要和哪些系统打通?API 密钥是什么?” 它会帮你把一个模糊的想法,拆解成一份详细的规格说明书(Spec)。这份说明书既是给人类看的,也是后续 AI 自己写代码的指南。 最有意思的是,我们开始为 AI 编写“AI 专属的说明书”(比如 .cursor/rules、Agents .md、Claude .md)。什么意思?就是你告诉 AI:“我们公司的代码规范是这样的”、“这个模块的安全级别最高,不许调用第三方库”、“日志必须这样打印”…… 我们正在创造第一批纯粹为 AI 而不是为人类设计的知识库。你不再是手把手教一个新员工,你是直接把“公司手册”和“最佳实践”灌输给 AI。 第二步:AI 负责“动手干”(编码与审查) 这才是我们传统理解的“写代码”环节,但它也已经面目全非了。它分化成了好几种模式: - 聊天式编辑:这就像你旁边坐了个结对编程的伙伴,你在 IDE(编程软件)里一边打字聊天,它一边帮你实时修改和创建文件。 - 后台智能体(Agent):Codex Claude、Claude Web 现在已经做的比较成熟了。你给它一个完整的任务(比如“修复这个 bug”或“开发这个新功能”),它就自己去后台吭哧吭哧干活了。它会自己写代码、自己运行测试、自己改 bug,几个小时后,它直接给你提交一个“Pull Request”(代码合并请求),说:“老板,活干完了,请审阅。” - AI 应用构建器:你用大白话描述,或者画个草图,它直接“duang”一下给你生成一个功能完整的应用程序。目前这主要用于做原型设计,但离“直接上线”也不远了。 - AI 代码审查员:AI 不仅自己写代码,它还反过来审查人类写的代码。它会像个资深架构师一样,在 GitHub 上评论:“你这里写得有安全漏洞”、“这个逻辑不严谨”、“不符合公司规范,打回重写”。 这里有个特别有意思的改变:Git(版本控制系统)的意义变了。 以前,我们用 Git 关心的是“代码如何被修改”(比如“张三在第 10 行加了个 if”)。但如果整个文件都是 AI 一键生成的,这个“如何”就没意义了。未来我们关心的是“代码为什么被修改”(AI 是根据哪个提示词生成的?)以及“它能跑吗”(AI 的测试结果如何?)。 第三步:AI 成为“后勤保障”(QA 与文档) 代码写完,测试和文档这两件苦差事,AI 也全包了。 - AI QA(质量保证):AI 扮演一个“自主的 QA 工程师”。它会像真人一样去“爬”你的应用,点一点这个、试一试那个,自动生成测试用例、报告 bug,甚至还附上建议的修复代码。a16z 提到一个极端情况:未来,AI 写的代码可能成为一个“黑盒”,人类根本看不懂,但这没关系,只要 AI QA 说它能通过所有测试,那它就是对的。 - AI 写文档:无论是给用户看的产品说明书、给其他程序员看的 API 文档,还是给老板和法务看的合规性报告,AI 都能自动生成,而且保持实时更新。 第四步:给 AI 的“工具箱”(智能体工具) 这可能是最“硬核”的一层,也是很多人没想到的:我们不止在开发“给人类用的 AI 工具”,我们还在开发“给 AI 用的 AI 工具”。 AI Agent 要是想干活,它也需要“工具”: - 代码搜索引擎(Sourcegraph):一个公司动辄上亿行代码,AI 不可能每次都把所有代码读一遍。它需要一个“代码专用搜索引擎”,在 0.1 秒内找到它需要参考的几个关键函数。 - 文档检索引擎:同理,AI 需要“外挂知识库”来查询第三方 API 怎么用。 - 代码沙箱(E2B):这是最关键的。AI 写完代码总得跑跑试试吧?但你敢让它在你的电脑上“瞎跑”吗?万一它产生幻觉,rm -rf / 把你电脑删光了怎么办?“沙箱”就是给 AI 提供的一个安全的、隔离的“模拟器”,让 AI 可以在里面随便折腾、运行、测试,就算玩“炸”了,也不会影响真实环境。 a16z 在文章最后也回答了几个大家最关心的问题: 1. 3000 万程序员要失业了吗? a16z 的回答是:“当然不。” 他们认为“AI 取代程序员”是个“荒谬的叙事”。历史告诉我们,技术进步最终会把蛋糕做大。目前他们看到的真实数据是:那些最懂 AI 的企业,反而在加速招聘程序员。因为他们突然发现,以前要 100 人年才能做的项目,现在 10 个人就能启动了,那为什么不多开几个项目呢? 2. 那程序员的工作会变吗? 会,而且是巨变。 大学里教的那些传统“软件开发”课程,可以说一夜之间就成了“老古董”。 但有两样东西不会过时:算法和架构。因为 AI 经常会“挖坑把自己埋了”,你需要有扎实的基本功,才能把它从坑里“拽出来”。你的角色,从“砌墙的工人”变成了“指挥挖掘机和吊车的工头”。 3. 代码最终会消失吗? 也不会。 有人(比如 AI 大神 Andrej Karpathy)畅想,未来不需要代码了,LLM 直接执行我们的“意图”就行。 a16z 认为这不现实。为什么?因为代码的效率高到变态。 一个现代 GPU 执行一次 16 位整数加法,需要 10 的-14 次方秒。而一个 LLM 哪怕只生成一个 token(单词),也需要 10 的-3 次方秒。 两者之间是 1000 亿倍的效率差距。 所以,代码作为“意图”的最高效、最精确的“编译结果”,在很长很长时间内,都是不可替代的。 AI 对软件开发的革命,不是“工具革命”,而是“工业革命”。它不是在造一把“更好的锤子”,它是在造一整条“自动化生产线”,而且这条生产线还需要“给生产线用的工具”。 这是一个“技术超级周期”(technology supercycle)的开端。在这样的浪潮中,旧的霸主(比如微软、Meta)会很难受,因为船太大、掉头慢。而新的创业公司有绝佳的机会,因为整个游戏规则都变了。 对于我们每个从业者和爱好者来说,最好的消息是:一个充满无限可能的新大陆刚刚被发现,而我们正站在滩头阵地上。 原文地址: 翻译:
RamenPanda
2个月前
wwwgoubuli
2个月前
户晨风我不熟悉,但那个著名的苹果山姆理论我也听过。 不管你是职业开发者,还是热衷用 AI 落地自己想法的产品,在干活出货这件事上,他那个理论可以套用下。 苹果手机当然不是最好的,只选择山姆也会失去很多其他生活中的美好和高性价比选择。 但对有些人来说,不做选择,做一个不出错的选择,比考虑性价比和可能性更重要。 而我的推荐就是 codex / claude,用原版模型。 国产之光 glm ,kimi 等平替很好,但不稳定。 不要浪费时间。 实在觉得用量不够,加个 augument 和 amp 。 你就当我是觉得国外的月亮圆吧。 在 macos 上开发,别去 windows 里装 wsl 折腾。 买台苹果。 选个好的梯子,贵点的人少的,能给你解决 IP 问题避免封号的。 如果你实在不需 terminal,就用个 vscode,别去尝试 zed。 zed 很快,但我都测出一堆 bug 了。别盲目追求那个。 我以前推荐过 trae,但想贯彻不折腾的原则,你可以试试 windsurf 。 trae 的 action 和提示词有点用力过猛。副作用偏大,在这个帖子里我不推荐。 windsurf 稍微好一点。 以上所有的建议,都是模仿户晨风那个出发的,不是什么最佳实践,也不是什么最好的2025年度选择。 但是一定是那种,如果你经济能承担的话,又不想折腾,不想vibe 后改来改去,希望尽量一次性提高命中率,专注于让东西可靠,稳健的落地的最合适搭配。 其中我最推荐的模型是 gpt-5-codex,它不快,跑起来慢。 但它综合看来就是最不折腾,最容易让你晚上可以安心合上电脑,享受会儿生活的那个助手。 再说一次,这些组合不是适合所有场景的,也不是最强的,你们可以在单点上很轻易的反驳我。 重点是是不折腾,粗暴,管用。
nazha
2个月前
#分享 大脑和工具之间的抽象:Skills Anthropic 前几天推出 Skills,今天研究了下,第一眼就让我感觉怎么跟 Cursor Rules 的设计一模一样:标题、描述和被“卸载”到文件系统的详细内容。 接着仔细看了 Anthropic 提供的 Skills 示例,强烈觉得这恐怕又是 Anthropic 公司内部 dogfooding 的结果。 我的理解是:Skills 描述的对人类技能的抽象。 ## MCP 和 Skills 一般,我们把 MCP 定义为 Agent 的 **工具能力**,能够访问外部系统、执行相关流程和获取关键信息。当然,MCP 也可以来做跟 Skills 相关的事情,它可以很狭义,也可以很广义,这主要看在具体实践中的定义。 技能是更高纬度的,通过学习、训练或工作经验获得的能力。之前主要是依赖 LLMs 的内在的通用能力,而 Skills 有点类似于强化学习路径,让 LLM 有一个可参考的模板。 简单理解,MCP 不能跟 Skills 混为一谈:MCP 定位在工具,Skills 定位在技能。 在 Anthropic 发布的这张图也并没有表达 Skills 替换 MCP 的意思,工具应该是更原子化的东西。而工具 = MCP + 命令行 + 自定义脚本 + ... ## Skills 是 Anthropic 让 Claude Code/Claude Web 向迈向通用 Agent 做的努力 Anthropic 在 Claude Code 中也集成了 Skills,显然是看到了 Claude Code 在通用 Agent 方向的潜力,而不仅仅是写代码(拜托,先换个名字,不要叫 Claude Code 了)。 ## 再来看 Skills 的设计 第一个感觉就是对普通人来说真的简单。你要实现一个 MCP 工具,非编程科班出身的还真有点难度,理解 MCP 的各个概念就能让人退而却步。而 Skill 的设计呢,无非就是写文档、讲明白事情就可以。 为了实现在 Skills 执行脚本和代码,Anthropic 就必须提供一个虚拟执行环境,将部分困难转交给容器执行环境(这也许是下一个技术热点)。当然,并不是批评 MCP,MCP在设计的时候,也许并没有这个共识存在。 ## 给我们在设计 Agent 架构时的启发 技能的部分,在之前的架构设计中,有一部分是会演变成子智能体,技能详情变成了子智能体的系统提示,即 Agent as Tool / Agent as Skill 的设计。若在智能体和工具之间又加了一个技能层,给我们在设计 Agent 架构的时候,就要思考得更多了,第一个问题就是是否需要额外引入一个 Agent,如果这个 Agent 的能力能够被 Skill 承载? 对于多智能体的架构,目前我看到的一些产品,比如 Manus、 Claude Code 都是很谨慎的。Skills 给我们在设计 Agent 的时候提供另一条思路:有技能的智能体。 ## 了解 Skill, 我的建议 先从 的每个例子开始,对技能是什么有个初步的概念。再看下 这篇工程文章,深入了解 Skills 的设计。 最后,我表示我很喜欢 Skill。哪怕 Cursor Rules 出来很久,这也是我也没取思考过的工程设计。也许像浩瀚天空的一颗星,指明了一些方向。