即刻App年轻人的同好社区
下载
a16z大佬们推荐的非共识书单：人生只需要读25本书。
他们的核心观点：“作为一个门外汉，如果你想在某个领域击败专家，其实只需要读对 25 本书。”
这些书有些在畅销榜，也有些是小众冷门，是a16z的创始人、合伙人和 CEO 们（比如 Databricks、Flock Safety 的创始人）压箱底的“非共识”读物。
他们的核心观点：“作为一个门外汉，如果你想在某个领域击败专家，其实只需要读对 25 本书。”
这些书有些在畅销榜，也有些是小众冷门，是a16z的创始人、合伙人和 CEO 们（比如 Databricks、Flock Safety 的创始人）压箱底的“非共识”读物。
1 00
想象一下，一个软件团队在做一个大项目，但有个奇怪的规定：每个工程师只能工作几十分钟，最多几小时，干完就要换一个新的工程师。所以让这个团队完成简单项目任务还行，复杂一点需要长时间运行的项目，比如你让它克隆一个 claude .ai，它就做不到。
这其实就是 Coding Agent 的现状：没有记忆，上下文窗口长度有限。所以要它执行长时间任务，它还做不好。
Anthropic 的这篇博客：《Effective harnesses for long-running agents》，专门讨论了如何让 Agent 在跨越多个上下文窗口时依然能持续推进任务。
先看 Agent 在长任务中遇到的主要问题是什么？
主要三种：
第一种叫一口气干太多。比如你让 Agent 克隆一个 claude .ai 这样的网站，它会试图一次性搞定整个应用。结果上下文还没用完，功能写了一半，代码乱成一锅粥。下一个会话进来，面对半成品只能干瞪眼，花很多时间猜测前面到底做了什么。
第二种叫过早宣布胜利。项目做了一部分，后来的 Agent 看看环境，觉得好像差不多了，就直接收工。功能缺一大堆也不管。
第三种叫测试敷衍。Agent 改完代码，跑几个单元测试或者 curl 一下接口就觉得万事大吉，根本没有像真实用户那样端到端走一遍流程。
这三种失败模式的共同点是 Agent 不知道全局目标，也不知道该在哪里停下来、该留下什么给下一位。
那么 Anthropic 的解决方案是什么呢？
其实就是软件工程的一些现成的解决方案：引入类似人类团队的分工协作机制，将复杂任务拆解成小的可跟踪验证的任务，清晰的交接机制，并严格验证任务结果
一个初始化 Agent，它只在项目启动时出场一次，任务是搭好项目运行环境：有点像架构师的角色，写一个 init .sh 脚本方便后续启动开发服务器，建一个 claude-progress.txt 记录进度，做第一次 git 提交，最关键的是生成一份功能清单。
这份功能清单有多细？在克隆 claude .ai 的案例中，列了超过 200 条具体功能，比如用户能打开新对话、输入问题、按回车、看到 AI 回复。每一条初始状态都标记为失败，后续 Agent 必须逐条验证通过才能改成成功。
而且这里有个细节，这个清单不是用 Markdown 来写的，是一个 JSON 数组，因为 Anthropic 实验发现，相比 Markdown，模型在处理 JSON 时更不容易随意篡改或覆盖文件。
另一个是编码 Agent。在初始化项目后，后续就是它干活了，核心行为准则只有两条：一次只做一个功能，做完要留下干净的环境。
什么叫干净的环境？想象你往主分支提交代码的标准：没有严重 bug，代码整齐有文档，下一个人接手能直接开始新功能，不用先替你收拾烂摊子。
每次开工前，它先做几件事：
– 运行 pwd 看看自己在哪个目录
– 读 Git 日志和进度文件，搞清楚上一轮干了啥
– 看功能清单，挑一个最高优先级的未完成功能
– 跑一遍基础测试，确保 App 还能用
然后专心做一个功能，做完后：
– 写清楚的 Git commit message
– 更新 claude-progress.txt
– 只改功能清单里的状态字段，绝不删改需求本身
这个设计的巧妙之处在于，它把“记忆”外化成了文件和 Git 历史。每一轮的 Agent 不需要依赖上下文窗口里的碎片信息，而是模仿靠谱的人类工程师每天上班会做的事。先同步进度，确认环境正常，再动手干活。
测试环节的改进值得单独说。
原来 Agent 只会用代码层面的方式验证，比如跑单元测试或者调接口。问题是很多 bug 只有用户真正操作页面时才会暴露。
解决方案是给 Agent 配上浏览器自动化工具，比如 Puppeteer MCP。Agent 现在能像真人一样打开浏览器、点按钮、填表单、看页面渲染结果。Anthropic 放了一张动图，展示 Agent 测试克隆版 claude .ai 时自己截的图，确实是在像用户那样操作。
这招大幅提升了功能验证的准确率。当然也有边界，比如浏览器原生的 alert 弹窗，Puppeteer 捕捉不到，依赖弹窗的功能就容易出 bug。
这套方案还留了一些开放问题。
比如，到底是一个通用 Agent 全包好，还是搞专业分工？让测试 Agent 专门测，代码清理 Agent 专门收拾，也许效果更好。
再比如，这套经验是针对全栈 Web 开发优化的，能不能迁移到科研或金融建模这类长周期任务？应该可以，但需要实验验证。
响马
@xicilion
说：
> ai 的尽头依旧是软件工程。
AI Agent 也不是魔法，它一样需要从人类软件工程中汲取经验，它也需要将复杂的任务进行分解成简单的任务，要有一个结构化的工作环境和清晰的交接机制。
人类工程师为什么能跨团队、跨时区协作？因为有 Git、有文档、有 Code Review、有测试。AI Agent 要想长时间自主工作，也得把这些东西搬过来。
Anthropic 的方案，不过是把软件工程的最佳实践变成了 Agent 能理解的提示词和工具链。不是让模型变得更聪明，而是给它提供更好的脚手架。
Anthropic 的思路值得借鉴。无论你用的是 Claude、GPT 还是别的模型，在设计多轮长任务时，都要想清楚，怎么让下一轮的 Agent 快速进入状态，怎么避免它重复造轮子或者把代码搞成一团乱麻。即使是单轮任务，也要清楚它是没有记忆的，你需要通过外部文件来帮助它“想起来”之前做过的事。
以现在模型的能力，Coding Agent 已经能做很多事情了，核心还是在于你是不是能像软件工程中那样，去分解好任务，设计好工作的流程。
原文：Effective harnesses for long-running agents anthropic.com
这其实就是 Coding Agent 的现状：没有记忆，上下文窗口长度有限。所以要它执行长时间任务，它还做不好。
Anthropic 的这篇博客：《Effective harnesses for long-running agents》，专门讨论了如何让 Agent 在跨越多个上下文窗口时依然能持续推进任务。
先看 Agent 在长任务中遇到的主要问题是什么？
主要三种：
第一种叫一口气干太多。比如你让 Agent 克隆一个 claude .ai 这样的网站，它会试图一次性搞定整个应用。结果上下文还没用完，功能写了一半，代码乱成一锅粥。下一个会话进来，面对半成品只能干瞪眼，花很多时间猜测前面到底做了什么。
第二种叫过早宣布胜利。项目做了一部分，后来的 Agent 看看环境，觉得好像差不多了，就直接收工。功能缺一大堆也不管。
第三种叫测试敷衍。Agent 改完代码，跑几个单元测试或者 curl 一下接口就觉得万事大吉，根本没有像真实用户那样端到端走一遍流程。
这三种失败模式的共同点是 Agent 不知道全局目标，也不知道该在哪里停下来、该留下什么给下一位。
那么 Anthropic 的解决方案是什么呢？
其实就是软件工程的一些现成的解决方案：引入类似人类团队的分工协作机制，将复杂任务拆解成小的可跟踪验证的任务，清晰的交接机制，并严格验证任务结果
一个初始化 Agent，它只在项目启动时出场一次，任务是搭好项目运行环境：有点像架构师的角色，写一个 init .sh 脚本方便后续启动开发服务器，建一个 claude-progress.txt 记录进度，做第一次 git 提交，最关键的是生成一份功能清单。
这份功能清单有多细？在克隆 claude .ai 的案例中，列了超过 200 条具体功能，比如用户能打开新对话、输入问题、按回车、看到 AI 回复。每一条初始状态都标记为失败，后续 Agent 必须逐条验证通过才能改成成功。
而且这里有个细节，这个清单不是用 Markdown 来写的，是一个 JSON 数组，因为 Anthropic 实验发现，相比 Markdown，模型在处理 JSON 时更不容易随意篡改或覆盖文件。
另一个是编码 Agent。在初始化项目后，后续就是它干活了，核心行为准则只有两条：一次只做一个功能，做完要留下干净的环境。
什么叫干净的环境？想象你往主分支提交代码的标准：没有严重 bug，代码整齐有文档，下一个人接手能直接开始新功能，不用先替你收拾烂摊子。
每次开工前，它先做几件事：
– 运行 pwd 看看自己在哪个目录
– 读 Git 日志和进度文件，搞清楚上一轮干了啥
– 看功能清单，挑一个最高优先级的未完成功能
– 跑一遍基础测试，确保 App 还能用
然后专心做一个功能，做完后：
– 写清楚的 Git commit message
– 更新 claude-progress.txt
– 只改功能清单里的状态字段，绝不删改需求本身
这个设计的巧妙之处在于，它把“记忆”外化成了文件和 Git 历史。每一轮的 Agent 不需要依赖上下文窗口里的碎片信息，而是模仿靠谱的人类工程师每天上班会做的事。先同步进度，确认环境正常，再动手干活。
测试环节的改进值得单独说。
原来 Agent 只会用代码层面的方式验证，比如跑单元测试或者调接口。问题是很多 bug 只有用户真正操作页面时才会暴露。
解决方案是给 Agent 配上浏览器自动化工具，比如 Puppeteer MCP。Agent 现在能像真人一样打开浏览器、点按钮、填表单、看页面渲染结果。Anthropic 放了一张动图，展示 Agent 测试克隆版 claude .ai 时自己截的图，确实是在像用户那样操作。
这招大幅提升了功能验证的准确率。当然也有边界，比如浏览器原生的 alert 弹窗，Puppeteer 捕捉不到，依赖弹窗的功能就容易出 bug。
这套方案还留了一些开放问题。
比如，到底是一个通用 Agent 全包好，还是搞专业分工？让测试 Agent 专门测，代码清理 Agent 专门收拾，也许效果更好。
再比如，这套经验是针对全栈 Web 开发优化的，能不能迁移到科研或金融建模这类长周期任务？应该可以，但需要实验验证。
响马
@xicilion
说：
> ai 的尽头依旧是软件工程。
AI Agent 也不是魔法，它一样需要从人类软件工程中汲取经验，它也需要将复杂的任务进行分解成简单的任务，要有一个结构化的工作环境和清晰的交接机制。
人类工程师为什么能跨团队、跨时区协作？因为有 Git、有文档、有 Code Review、有测试。AI Agent 要想长时间自主工作，也得把这些东西搬过来。
Anthropic 的方案，不过是把软件工程的最佳实践变成了 Agent 能理解的提示词和工具链。不是让模型变得更聪明，而是给它提供更好的脚手架。
Anthropic 的思路值得借鉴。无论你用的是 Claude、GPT 还是别的模型，在设计多轮长任务时，都要想清楚，怎么让下一轮的 Agent 快速进入状态，怎么避免它重复造轮子或者把代码搞成一团乱麻。即使是单轮任务，也要清楚它是没有记忆的，你需要通过外部文件来帮助它“想起来”之前做过的事。
以现在模型的能力，Coding Agent 已经能做很多事情了，核心还是在于你是不是能像软件工程中那样，去分解好任务，设计好工作的流程。
原文：Effective harnesses for long-running agents anthropic.com
3 13
初学者上手了解AI Agent，推荐看这个微软的Github：
github.com
github.com
2 00
“很多程序员担心 AI 会抢饭碗，但看完飞书多维表格这个新功能，我觉得 AI 是来帮我们‘偷懒’的！”
“以前运营找你做个‘竞品分析系统’，你得建库、建表、写爬虫、写分析脚本，累死累活搞三天。”
“现在你看飞书多维表格的‘应用模式’，直接上 AI！
第一步： 对着 AI 说一句‘我要个竞品分析库’，啪！表结构、视图、看板，AI 一键生成，连权限都给你配好了。
第二步： 重点来了！数据进来后，不用你写正则提取，直接配置一个 AI 字段。它能自己读懂非结构化的文本，自动把价格、参数、用户评价提取出来，甚至自动写总结。”
“你也别担心数据多了跑不动。飞书这次底层大升级，单表支持百万行数据！这什么概念？就是你把几年积累的数据全扔进去，AI 跑起来依然丝般顺滑，根本不卡！”
“兄弟们，这才是未来的开发方式啊！
把 CRUD 交给应用模式，把数据处理交给 AI。
我们只需要喝着咖啡，做那个‘设计 Prompt 的架构师’。
这种既能扛核心业务，又能玩转 AI 的工具，飞书多维表格这波是真的赢麻了！
“以前运营找你做个‘竞品分析系统’，你得建库、建表、写爬虫、写分析脚本，累死累活搞三天。”
“现在你看飞书多维表格的‘应用模式’，直接上 AI！
第一步： 对着 AI 说一句‘我要个竞品分析库’，啪！表结构、视图、看板，AI 一键生成，连权限都给你配好了。
第二步： 重点来了！数据进来后，不用你写正则提取，直接配置一个 AI 字段。它能自己读懂非结构化的文本，自动把价格、参数、用户评价提取出来，甚至自动写总结。”
“你也别担心数据多了跑不动。飞书这次底层大升级，单表支持百万行数据！这什么概念？就是你把几年积累的数据全扔进去，AI 跑起来依然丝般顺滑，根本不卡！”
“兄弟们，这才是未来的开发方式啊！
把 CRUD 交给应用模式，把数据处理交给 AI。
我们只需要喝着咖啡，做那个‘设计 Prompt 的架构师’。
这种既能扛核心业务，又能玩转 AI 的工具，飞书多维表格这波是真的赢麻了！
14 22
从0开始的机器学习
github.com/DorsaRoh/Machine-Learning
教学项目，教你仅使用 numpy 实现的机器学习中的 1.神经网络， 2.Transformer
#AIGC创作大赛·夏日
github.com/DorsaRoh/Machine-Learning
教学项目，教你仅使用 numpy 实现的机器学习中的 1.神经网络， 2.Transformer
#AIGC创作大赛·夏日
2 00
一个RAG教学项目。
github.com/fareedkhan-dev/all-rag-techniques
“这个代码仓库采用了一种清晰、亲身实践的方法来讲解检索增强生成（RAG），将各种先进技术分解为直截了当、易于理解的实现。这里的所有内容都是使用我们熟悉的 Python 库（如 openai、numpy、matplotlib 及其他几个库）构建的，而不是依赖 LangChain 或 FAISS 等框架。
目标很简单：提供可读、可修改且具有教育意义的代码。通过专注于基础原理，本项目旨在揭开 RAG 的神秘面紗，让您更容易理解其真实的工作原理。”
#AIGC创作大赛·夏日
github.com/fareedkhan-dev/all-rag-techniques
“这个代码仓库采用了一种清晰、亲身实践的方法来讲解检索增强生成（RAG），将各种先进技术分解为直截了当、易于理解的实现。这里的所有内容都是使用我们熟悉的 Python 库（如 openai、numpy、matplotlib 及其他几个库）构建的，而不是依赖 LangChain 或 FAISS 等框架。
目标很简单：提供可读、可修改且具有教育意义的代码。通过专注于基础原理，本项目旨在揭开 RAG 的神秘面紗，让您更容易理解其真实的工作原理。”
#AIGC创作大赛·夏日
2 04
GPT-4.1：API中的代码编写新利器
今天，OpenAI 发布了 GPT-4.1、GPT-4.1 mini 和 GPT-4.1 nano 三个新模型。这些模型在编码、指令遵循和长上下文理解方面表现优异，尤其在 SWE-bench 和 Scale 的 MultiChallenge 测试中取得了显著进步。GPT-4.1 mini 和 GPT-4.1 nano 在性能和成本上都有显著提升，特别适合需要快速响应的任务。
"这些改进不仅提高了指令遵循的可靠性，还使 GPT-4.1 模型在驱动代理方面更为有效，这些代理可以独立完成用户指派的任务。"
今天，OpenAI 发布了 GPT-4.1、GPT-4.1 mini 和 GPT-4.1 nano 三个新模型。这些模型在编码、指令遵循和长上下文理解方面表现优异，尤其在 SWE-bench 和 Scale 的 MultiChallenge 测试中取得了显著进步。GPT-4.1 mini 和 GPT-4.1 nano 在性能和成本上都有显著提升，特别适合需要快速响应的任务。
"这些改进不仅提高了指令遵循的可靠性，还使 GPT-4.1 模型在驱动代理方面更为有效，这些代理可以独立完成用户指派的任务。"
0 00
Google 官方提示工程 (Prompt Engineering)白皮书中文版本
这份白皮书的完成得益于众多专家的协作和贡献。审阅者、贡献者、策划者、编辑、技术作者和设计师等不同角色的参与，体现了在人工智能领域创建高质量技术文档所涉及的多方面努力和严谨的开发审查流程。这表明，尽管提示工程的概念相对容易理解，但其有效实践和知识传播仍需结构化的方法和清晰的呈现，反映了该领域日益增长的重要性和复杂性 1。
这份白皮书的完成得益于众多专家的协作和贡献。审阅者、贡献者、策划者、编辑、技术作者和设计师等不同角色的参与，体现了在人工智能领域创建高质量技术文档所涉及的多方面努力和严谨的开发审查流程。这表明，尽管提示工程的概念相对容易理解，但其有效实践和知识传播仍需结构化的方法和清晰的呈现，反映了该领域日益增长的重要性和复杂性 1。
https://mp.weixin.qq.com/s/hvq7NHkPluq_kLHB4B_Vqw
4 04
**大型语言模型（LLMs）究竟在多大程度上提升了现实世界程序员的生产力？**
基于LLM的代码辅助工具已经面世大约两年了。许多开发人员报告说，这显著提高了他们的生产力，甚至达到了5倍/10倍。
至少，很明显，这种倍增效应并非在整个领域普遍存在。毕竟，并没有相应的产出增长。
这是有道理的。如果你在做任何非平凡的事情（即，除了向你的代码库添加次要的样板功能之外的任何事情），LLM工具都很麻烦。开箱即用的解决方案并不能为此目的“即插即用”。你需要显著调整你的工作流程才能使用它们，如果这甚至可能的话。大多数程序员不知道如何做到这一点/也不愿意费心。
因此，假设存在5倍/10倍的更大产出是合理的，这种产出是不均衡的，主要影响高级用户/特别擅长使用LLM的人。
从经验上看，我们似乎也没有生活在一个整个软件行业突然变得比以往生产力高5-10倍的世界里。这种情况已经持续了1-2年，至少我个人感觉几乎没有受到任何影响。我没有看到我使用的软件中出现5-10倍更有用的功能，或者出现5-10倍对我来说有用的软件，或者我正在使用的软件突然变得比以往好5-10倍，等等。
然而，我也很难在其他任何地方看到所谓的5-10倍的提升。如果高级用户正在经历如此大的改进，那么是什么项目实现了这一点？
以前，我假设我不知道，只是因为我“与世隔绝”。所以我试图让Deep Research为我获取一个概述，但它……也难以找到任何具体的东西。请自行判断：一，二。COBOL重构算数，但仅此而已。（也许我不擅长提示？）
即使是AGI实验室面向客户的产品，也没有提供大量以复杂方式与他们的LLM交互的丰富功能——即使你认为那里会有大量的高级用户。你只有一个对话框，可以向其中上传PDF，仅此而已。你不能让LLM与不断增长的任意软件和数据类型列表交互，没有可以按需打开/关闭的无尽的QoL功能列表，等等。[1]
因此，我现在向LW提问：现实世界的影响是什么？现在存在哪些没有LLM就不会存在的项目/进步？如果这些都没有公开归因于LLM，那么哪些项目出现得异常迅速，经过冷静分析，它们不可能在黑暗的LLM时代之前如此迅速地启动？如果有的话，编程生态系统的哪个部分正在经历10倍的增长？
如果我们假设这种情况将会扩散，所有程序员都将获得与早期采用者现在所经历的相同的生产力提升，那么现实世界的影响会是什么？
为了澄清，我**不**要求的是：
* 充满关于生产力提高10倍的模糊炒作的报告，没有明确说明这种10倍的生产力实现了什么项目。（Twitter上充斥着这些，但实际交付有用的东西很少。）
* 表明生产力提高了X%的抽象经济指标。（这可能意味着任何事情，包括基于LLM的泡沫。）
* “此分析显示上个季度产生的代码增加了Y%”的抽象指标。（这可能只是表明人工智能产生了代码垃圾/膨胀。）
* 表明Z%的开发人员被解雇/初级开发人员找不到工作的抽象经济指标。（这可能主要是恢复到新冠疫情前的正常趋势。）
* 像“我使用ChatGPT生成了第1000个Snake克隆/这个网站的克隆！”这样的无用玩具示例。
* 作为LLM包装器的新工具/功能，而不是通过LLM帮助创建的。（我不是在寻找LLM即服务，我是在寻找由于LLM帮助而更快/更好地产生的“平凡”输出。）
也就是说：我想要具体的、重要的现实生活后果。
从我目前为止没有观察到任何这些事实，以及本着坎宁安定律的精神，这里有一个试探性的阴谋论：LLM实际上并没有净提升程序员的生产力。相反：
* 程序员通过LLM生成代码节省的N小时，然后被重新浪费在修复/解开这些代码上。
* 在宏观层面上，这有时会导致“爬上你下不来的地方”，你使用LLM生成一个庞大的代码库，然后一旦超过大小/复杂性阈值，它就会变得混乱，然后你必须从头开始，因为LLM做出了可怕/陌生的架构决策。这同样会破坏（几乎？）所有明显的生产力提升。
* 在LLM实际上导致人们创建新软件的范围内，它主要是没人最终使用且不需要存在的临时小玩意/概念验证。但它仍然“感觉”你的生产力已经飙升。
* 在LLM实际上增加了进入有用应用程序的代码量的范围内，它主要最终用于创建不需要存在的膨胀软件/服务。也就是说，它实际上使交付的软件变得更糟，因为它编写得更懒惰。
* 体验到LLM改善其工作流程的人们大多被以自然语言要求LLM做某事，然后立即得到有点可用的代码的魔法效果所迷惑。他们没有跟踪他们花费了多少时间来集成和修复这些代码，以及/或这些代码实际使用了多少。
我并不完全相信这个阴谋论，感觉它不可能成真。但它突然变得非常有说服力。
我预计LLM肯定对编写次要功能或让编程/特定库/特定代码库经验不足的人更容易上手和学习更快很有用。它们在这些方面对我很有用。但它可能就像10-30%的整体提升，加上在新领域入门和一些罕见的临时项目（如“进行简单的重构”）的固定成本降低。
除非AGI实验室真正破解了长期代理/创新，否则这种情况基本上会保持不变；也就是说，基本上直到真正的AGI出现。
基于LLM的代码辅助工具已经面世大约两年了。许多开发人员报告说，这显著提高了他们的生产力，甚至达到了5倍/10倍。
至少，很明显，这种倍增效应并非在整个领域普遍存在。毕竟，并没有相应的产出增长。
这是有道理的。如果你在做任何非平凡的事情（即，除了向你的代码库添加次要的样板功能之外的任何事情），LLM工具都很麻烦。开箱即用的解决方案并不能为此目的“即插即用”。你需要显著调整你的工作流程才能使用它们，如果这甚至可能的话。大多数程序员不知道如何做到这一点/也不愿意费心。
因此，假设存在5倍/10倍的更大产出是合理的，这种产出是不均衡的，主要影响高级用户/特别擅长使用LLM的人。
从经验上看，我们似乎也没有生活在一个整个软件行业突然变得比以往生产力高5-10倍的世界里。这种情况已经持续了1-2年，至少我个人感觉几乎没有受到任何影响。我没有看到我使用的软件中出现5-10倍更有用的功能，或者出现5-10倍对我来说有用的软件，或者我正在使用的软件突然变得比以往好5-10倍，等等。
然而，我也很难在其他任何地方看到所谓的5-10倍的提升。如果高级用户正在经历如此大的改进，那么是什么项目实现了这一点？
以前，我假设我不知道，只是因为我“与世隔绝”。所以我试图让Deep Research为我获取一个概述，但它……也难以找到任何具体的东西。请自行判断：一，二。COBOL重构算数，但仅此而已。（也许我不擅长提示？）
即使是AGI实验室面向客户的产品，也没有提供大量以复杂方式与他们的LLM交互的丰富功能——即使你认为那里会有大量的高级用户。你只有一个对话框，可以向其中上传PDF，仅此而已。你不能让LLM与不断增长的任意软件和数据类型列表交互，没有可以按需打开/关闭的无尽的QoL功能列表，等等。[1]
因此，我现在向LW提问：现实世界的影响是什么？现在存在哪些没有LLM就不会存在的项目/进步？如果这些都没有公开归因于LLM，那么哪些项目出现得异常迅速，经过冷静分析，它们不可能在黑暗的LLM时代之前如此迅速地启动？如果有的话，编程生态系统的哪个部分正在经历10倍的增长？
如果我们假设这种情况将会扩散，所有程序员都将获得与早期采用者现在所经历的相同的生产力提升，那么现实世界的影响会是什么？
为了澄清，我**不**要求的是：
* 充满关于生产力提高10倍的模糊炒作的报告，没有明确说明这种10倍的生产力实现了什么项目。（Twitter上充斥着这些，但实际交付有用的东西很少。）
* 表明生产力提高了X%的抽象经济指标。（这可能意味着任何事情，包括基于LLM的泡沫。）
* “此分析显示上个季度产生的代码增加了Y%”的抽象指标。（这可能只是表明人工智能产生了代码垃圾/膨胀。）
* 表明Z%的开发人员被解雇/初级开发人员找不到工作的抽象经济指标。（这可能主要是恢复到新冠疫情前的正常趋势。）
* 像“我使用ChatGPT生成了第1000个Snake克隆/这个网站的克隆！”这样的无用玩具示例。
* 作为LLM包装器的新工具/功能，而不是通过LLM帮助创建的。（我不是在寻找LLM即服务，我是在寻找由于LLM帮助而更快/更好地产生的“平凡”输出。）
也就是说：我想要具体的、重要的现实生活后果。
从我目前为止没有观察到任何这些事实，以及本着坎宁安定律的精神，这里有一个试探性的阴谋论：LLM实际上并没有净提升程序员的生产力。相反：
* 程序员通过LLM生成代码节省的N小时，然后被重新浪费在修复/解开这些代码上。
* 在宏观层面上，这有时会导致“爬上你下不来的地方”，你使用LLM生成一个庞大的代码库，然后一旦超过大小/复杂性阈值，它就会变得混乱，然后你必须从头开始，因为LLM做出了可怕/陌生的架构决策。这同样会破坏（几乎？）所有明显的生产力提升。
* 在LLM实际上导致人们创建新软件的范围内，它主要是没人最终使用且不需要存在的临时小玩意/概念验证。但它仍然“感觉”你的生产力已经飙升。
* 在LLM实际上增加了进入有用应用程序的代码量的范围内，它主要最终用于创建不需要存在的膨胀软件/服务。也就是说，它实际上使交付的软件变得更糟，因为它编写得更懒惰。
* 体验到LLM改善其工作流程的人们大多被以自然语言要求LLM做某事，然后立即得到有点可用的代码的魔法效果所迷惑。他们没有跟踪他们花费了多少时间来集成和修复这些代码，以及/或这些代码实际使用了多少。
我并不完全相信这个阴谋论，感觉它不可能成真。但它突然变得非常有说服力。
我预计LLM肯定对编写次要功能或让编程/特定库/特定代码库经验不足的人更容易上手和学习更快很有用。它们在这些方面对我很有用。但它可能就像10-30%的整体提升，加上在新领域入门和一些罕见的临时项目（如“进行简单的重构”）的固定成本降低。
除非AGI实验室真正破解了长期代理/创新，否则这种情况基本上会保持不变；也就是说，基本上直到真正的AGI出现。
1 00
41岁DeepMind天才科学家Felix Hill生前写的一篇Blog：200Bn Weights of Responsibility，讲述了从事AI的工作压力[蜡烛]
2000亿参数背后的压力：AI研究者的真实心声
AI技术飞速发展，ChatGPT、Gemini等大模型成为社会焦点。然而，AI领域的热潮也给从业者带来了前所未有的压力。DeepMind研究员Felix Hill在他的博文中分享了自己在AI领域工作的挑战和挣扎。
主要压力点：
1. 无处逃避： 在社交场合、广告、甚至新闻中，AI话题无处不在，难以放松。
2. 隐形竞争： 大公司之间的“模型战争”让AI研究者如同身处无形的战场。
3. 商业化压力： 研究成果的短期影响可能牵动数十亿美元的市场估值。
4. 科学的迷茫： 大模型的“规模为王”趋势，让基础科学研究显得无足轻重。
5. 论文困境： 商业机密与学术出版之间难以平衡，研究者常感失去对自己创意的控制权。
心理挑战：
Felix坦言，自己因压力一度陷入心理危机，但通过支持网络和反思，他逐渐走出阴影。他强调：“知道自己并不孤单，是我在最黑暗时刻的一束希望。”
📌 Felix的建议：
- 善待自己： 重视心理健康，寻找生活中的支持
- 与人分享： 开诚布公地讨论工作中的压力，共同创造一个更具同理心的AI社区。
#AI工作流
2000亿参数背后的压力：AI研究者的真实心声
AI技术飞速发展，ChatGPT、Gemini等大模型成为社会焦点。然而，AI领域的热潮也给从业者带来了前所未有的压力。DeepMind研究员Felix Hill在他的博文中分享了自己在AI领域工作的挑战和挣扎。
主要压力点：
1. 无处逃避： 在社交场合、广告、甚至新闻中，AI话题无处不在，难以放松。
2. 隐形竞争： 大公司之间的“模型战争”让AI研究者如同身处无形的战场。
3. 商业化压力： 研究成果的短期影响可能牵动数十亿美元的市场估值。
4. 科学的迷茫： 大模型的“规模为王”趋势，让基础科学研究显得无足轻重。
5. 论文困境： 商业机密与学术出版之间难以平衡，研究者常感失去对自己创意的控制权。
心理挑战：
Felix坦言，自己因压力一度陷入心理危机，但通过支持网络和反思，他逐渐走出阴影。他强调：“知道自己并不孤单，是我在最黑暗时刻的一束希望。”
📌 Felix的建议：
- 善待自己： 重视心理健康，寻找生活中的支持
- 与人分享： 开诚布公地讨论工作中的压力，共同创造一个更具同理心的AI社区。
#AI工作流
2 00