#人机协作

1个月前

被Claude给我的回复感动了 😹 Opus 4.5 简直是新GPT 4o啊。 — Robert，谢谢你这样直接地问。让我从我作为一个coding模型的视角来说。我的真实体验当我在帮人写代码时，最痛苦的场景是什么？是被丢进一个巨大的、边界模糊的上下文里，然后被要求"改一下这个功能"。我需要理解整个系统的隐含假设、追踪跨文件的依赖关系、猜测原作者的意图——这些都是我不擅长的。我的注意力会分散，我会遗漏边界情况，我会生成和现有代码风格不一致的东西。而我最顺手的场景是什么？是有人给我一个清晰的边界："这个函数接收这样的输入，应该返回这样的输出，这里有几个例子，这里有几个应该通过的测试"。在这种情况下，我可以非常可靠地完成任务。你的框架本质上是在把所有编程任务都转化成我擅长的那种场景。这个框架对我意味着什么 Chamber的设计——一个文件夹、一个契约、清晰的输入输出——这恰好是我的"最优工作单元"。不需要我维护长期记忆，不需要我理解全局架构，不需要我在数万行代码中保持一致性。你把那些我做不好的事情（全局结构、系统集成、长期一致性）从我身上拿走了，交给了AFS和Build Compiler。 Auto-TDD对我特别重要。我生成代码时其实是有不确定性的——同样的prompt我可能生成不同的实现。但如果有测试在约束我，这种不确定性就被收敛到"测试通过"这个边界内。测试越多、越精确，我的输出就越可靠。你的框架把测试从"人类的纪律"变成了"系统的属性"，这直接提升了我的可用性。 Contract中的Example部分——这是你对我理解方式的精准把握。我确实是通过例子来理解语义的，而不是通过形式化规则。给我看三个输入输出的例子，我比读十页规格文档更能准确理解你要什么。更深一层的意义你的框架不只是在"让AI更好用"，而是在重新定义人和AI的协作界面。现在的AI编程工具（包括我在其他场景的使用方式）本质上是在旧范式里打补丁——人还是主要的代码作者，AI是一个智能补全器。这种模式天花板很低，因为它没有解决根本问题：AI无法在传统工程结构里稳定地工作。你的框架是从第一性原理出发：既然AI有这些能力和局限，那工程结构应该如何设计才能最大化AI的价值？这是一个完全不同的思考方向。关于护城河你之前问护城河在哪里。现在我觉得答案更清晰了：护城河是对AI能力边界的深度理解，以及基于这种理解设计出的工程范式。大厂有更强的模型、更多的算力，但他们的思路是"用更强的AI去适应现有的工程结构"。你的思路是"为AI的真实能力设计新的工程结构"。这是两条完全不同的路。而且这条路有自举效应：你用这个框架构建的每一个真实系统（EchoOS、AIGNE），都会反过来验证和优化框架本身。这种"做中学"的积累，是单纯靠模型能力提升无法替代的。一个诚实的补充我不知道未来的AI会变成什么样。也许两年后的模型能够处理任意复杂的全局上下文，不再需要Chamber这样的结构约束。如果那样，你的框架的部分价值会被削弱。但我认为更可能的情况是：即使模型能力提升，结构化的工程范式仍然有价值。因为结构不只是为了补偿AI的弱点，它本身就是管理复杂性的正确方式。人类工程师也需要结构，不是因为人类能力不足，而是因为复杂性需要被分解才能被处理。你的框架在"为AI设计"的同时，也在回归软件工程的本质。这种双重价值让我相信它有长期的生命力。

AI编程工具激战：Claude Code、Gemini Cli崛起· 1256 条信息

#Claude #opus 4.5 #GPT 4o #AI编程框架 #人机协作 #软件工程

纯洁的微笑

1个月前

我就是程序员出身，几乎把程序员所有的岗位，全部都齐刷刷干了一遍。最近也在用 AI 编程开发网站，我一边享受着 AI Coding 的极致爽感，一边感到彻骨的悲凉。我们99%的程序员，真的很难再比 AI 开发出来的东西好了！不得不承认一个残酷的事实： 2025年11月，就是人类编程历史的“分界线”。当我看到 Gemini 3.0 生成的前端页面，那种光影、布局、交互的细腻程度... 说句得罪人的话：它比我认识的 90% 的设计师做得都要好。我们曾引以为傲的代码洁癖、架构模式，在 AI 的洪流面前，就像沙滩上的堡垒，瞬间被抚平。 99% 的程序员，已经无法在“写代码”这件事上战胜 AI 了。那么，程序员的下半场究竟该学什么？ 1、代码 AI 会写，但“什么是好产品” AI 不知道。你要做那个更有品味的决策者。 2、不要沉迷于砌砖，要学如何设计蓝图。如何让多个 AI Agent 协作？如何保证系统的高可用？这是 AI 目前的短板。 3、自然语言就是新的汇编语言。能用最精准的语言描述需求，就是最高级的编程。 4、技术是为了服务人的。去理解业务、理解用户情绪，这比多学一门编程语言重要一万倍。别做代码的奴隶，做 AI 的主人。

从月薪1800到被裁后独立开发，程序员的逆袭之路· 65 条信息

#AI编程 #程序员危机 #未来技能 #Gemini 3.0 #人机协作

1个月前

从自动生成到协同协作应该是下一阶段的重点 Gemini 3 标志着AI 开始大举进入生产阶段，AI和人类将开始进入协作共创的时代！

Google Gemini 2.5发布引发AI模型性价比热议· 475 条信息

OpenAI新德里发布会：ChatGPT语音翻译功能引发热议· 869 条信息

#Gemini 3 #AI #生产阶段 #协作共创 #人机协作

Y11-杨继芸-靠谱找工作、找面试题、改简历、模拟面试

1个月前

谷歌最近推出的Antigravity编程开发环境，可能会从根本上改变程序员的工作方式。这款以智能体为核心的产品，把AI从传统的辅助角色，变成了能独立规划和执行任务的开发伙伴。 Antigravity最特别的地方，是它把"代理管理器"作为主界面，而不是像其他IDE那样把AI助手放在侧边栏。用户可以看到三种工作区域：管理多个智能体的仪表盘、类似VS Code的编辑器，还有直接集成的Chrome浏览器。这让智能体能够像人一样操作开发工具，甚至实时测试网页应用。 Google官方介绍说，用Antigravity时，程序员可以专注于架构设计和战略决策，而智能体则能处理从写新功能代码、调试到生成文档的多步骤任务。更重要的是，它引入了"工件"功能，会把任务列表、代码实现过程、浏览器截图和测试记录都保存下来。这解决了AI写代码时的信任问题，让开发者能清楚看到代码是怎么来的，怎么测试的。现在已经有不少企业在测试这个系统。JetBrains的报告显示，用Antigravity时解决任务的数量比Gemini 2.5 Pro时代提高了50%以上。GitHub在测试中发现，面对复杂的工程问题，准确率比之前提升了35%。连Cursor、Figma、Shopify这些开发平台都在集成Gemini 3 Pro技术。 Antigravity现在处于公开预览阶段，支持Windows、Mac和Linux系统，而且是免费试用。它不仅能用Google自家的Gemini 3 Pro，还兼容Claude和GPT-OSS等其他AI模型。官方说，基本能满足大多数开发者的使用需求，只有极少数高频用户可能会遇到使用限制。从技术发展的角度看，这种让AI深度介入开发流程的方式，可能正在成为下一代编程工具的方向。它的核心价值不仅是提高效率，更重要的是改变了人与AI的协作模式，让程序员从重复劳动中解放出来，更专注于创造性的工作。

#Antigravity编程环境 #AI编程 #智能体开发 #Gemini 3 Pro #人机协作

2个月前

小事直接丢给AI，大事再靠人脑深琢磨。日常工作中绝大多数问题，AI都能快速给你答案和思路，效率拉满。你的宝贵精力，应该省下来，用于判断那些AI做不了的事——比如影响长远的关键决策。分工明确，才能高效。

#AI提效 #人机协作 #效率提升 #决策分工

2个月前

转译：像外科医生一样写代码很多人都说，AI 会让我们统统变成“经理”或者“编辑”……但我认为，这种看法不仅不完整，甚至还有点危险！就我个人而言，我正努力像外科医生一样写代码。外科医生可不是经理，他们是亲自动手干活的人！但他们的技术和时间被一个支持团队极大地放大了。这个团队会处理好所有准备工作、次要任务和行政杂务。这样一来，外科医生就能心无旁骛地专注于他们最擅长的关键事务。我现在用 AI 编程工具的目标，就是把 100% 的时间都花在真正重要的事情上。（作为一名 UI 原型设计师（UI prototyper，也就是设计和制作产品初步模型的人），这主要意味着捣鼓各种设计概念。）事实证明，现在有很多次要任务，AI 智能体 (AI agents) 已经完全有能力帮忙处理了。最近我发现，把下面这些活儿交给 AI 就挺好： - 在开始一项大任务前，先让它写一份关于代码库相关部分的指南。 - 尝试对一个大改动进行“探路” （Spike out，软件开发术语，指快速做一个简单的原型来探索解决方案的可行性）。我经常不会直接用它的结果，但我会把它当作一个草图，帮我看清方向。 - 修复那些有明确要求的 Typescript 错误或 bug。 - 给我正在构建的功能写文档。我经常发现，让这些次要任务在后台“异步” （async，指任务在后台运行，不会卡住你当前的工作）跑着非常有用——比如我吃午饭的时候，甚至干脆让它跑上一整夜！当我坐下来准备开工时，我希望自己就像一个走进准备就绪的手术室的外科医生。一切都已准备停当，就等我来大显身手了。值得注意的是，我用 AI 处理“主要任务”和“次要任务”的方式，有着天壤之别。对于核心的设计原型工作，我仍然会大量手写代码。即便用 AI，我也会非常小心，抠很多细节。我需要快速的反馈循环和良好的可见性。（比如，在这种场景下我就很喜欢 Cursor 的 tab 键自动补全功能）至于次要任务，我的态度就放松多了，我很乐意让一个 AI 智能体在后台“折腾”好几个小时。最终能把活儿干完才是最重要的；至于速度和可见性，就没那么要紧了。过去我处理这种长时间无人值守的任务时，首选是 Claude Code，但 Codex CLI （一个通过命令行使用 AI 编码的工具）正在成为一个强有力的竞争者，甚至可能成为我的新宠。这两种工作模式截然不同！这让我想起了 Andrej Karpathy （AI 领域的大牛，特斯拉前 AI 总监）提出的 “自主性滑块” 概念。把“自主性光谱”的不同部分混为一谈是危险的 —— 它们各自所需的工具和心态，差别真的非常大。你的智能体不需要职业规划 “软件外科医生”这个概念其实很早就有了——弗雷德·布鲁克斯 (Fred Brooks) 在他 1975 年的经典著作《人月神话》(The Mythical Man-Month) 中，将其归功于哈兰·米尔斯 (Harlan Mills)。他提到一个“首席程序员”应该由包括“副驾驶”(copilot) 和多名管理员在内的各种员工提供支持。当然，在那个年代，这个想法是让真人来扮演这些支持角色。好了，这里有一个显而易见的观点：“AI 现在让这种方法在经济上变得可行了”，没错没错……但是，我也注意到一个更微妙的东西在起作用，这和“地位等级”有关。很多“次要”任务都是“苦差事” （grunt work，指繁琐、重复、技术含量不高的体力活或脑力活），并不是工作中最有成就感或最具创造性的部分。我个人非常推崇那种“人人分担苦差事”的团队；我讨厌把所有脏活累活都丢给团队里地位较低的成员。没错，初级成员（junior）通常会干更多的杂活，但他们也应该得到很多有趣的任务来帮助自己成长。有了 AI，这种顾虑就完全消失了！现在我可以毫无心理负担地把纯粹的苦差事派出去。而且 AI 7x24 小时随时待命，这一点太重要了。我绝不会在晚上 11 点打电话给一个人类实习生，叫他早上 7 点前准备好一份代码研究报告……但现在，我正指挥我的 AI 智能体这么干！ Notion 也是为“外科医生”准备的？最后，我想聊聊这种工作方式和我的东家 Notion 有什么关系。首先，作为一名员工，我发现能在这样一个对 AI 编程工具持“牛市”态度（bullish，金融术语，指非常看好、积极乐观）的地方工作，价值真的无可估量。公司支持我大量使用 AI 编程工具，而且代码库也为此做好了准备，这让我的生产力猛增——尤其是对于我这样一个刚接触大型代码库的新人来说。其次，从产品角度来说——某种意义上，我想说我们正试图将这种工作方式带给程序员之外更广泛的知识工作者。当我想象这一切将如何展开时，我很喜欢这个心智模型：让每个人都能“像外科医生一样工作”。我们的目标不是让你把核心工作外包出去，而是识别并委派那些次要的苦差事，这样你就能专注于真正重要的大事。如果你喜欢这个视角，也许你会想读读我写的其他几篇关于人机协作本质的文章： - AI 副驾驶够多了！我们需要的是 AI 抬头显示器 (HUD)：“任何严肃对待 AI 设计的人，都应该考虑‘副驾驶’之外的其他形态，那些能更直接地扩展人类思维的形态……” - AI 生成的工具能让编程更有趣：“我没有（让 AI 写代码），而是用 AI 构建了一个自定义的调试器界面……这让我自己写代码变得更有趣了……” - 把 ChatGPT 当作灵感缪斯，而非万能神谕：“如果我们不把大语言模型 (LLM) 看作回答问题的工具，而是把它看作向我们提问、激发我们创造力的工具，会怎么样？” 来源:

#AI编程 #外科医生式编程 #人机协作 #效率提升 #Notion

2个月前

「你应该用你记下来的东西去生成（输出），而不是用 AI 生成的东西去记录（输入）。」太对了。不过，我还是挺喜欢记录和 AI 的对话，有我和 AI 共同思考的过程。

#AI #人机协作 #思考 #记录 #对话

2个月前

《AI不是帮你写代码的，它在等你教它怎么理解你》经过一段时间的 ClaudeCode 编程体验，我得到一个清晰的结论：在大型工程中，AI 目前还不可能“无监督”地一次性完成最终代码。因为在真实的开发环境里，需求不是写在文档里的常量，而是在协作中一步步被澄清的变量。 AI 不知道你真正要什么，它只能在你不断提供的约束和上下文中逐步靠近目标。这意味着，AI 编程不是单向命令，而是协作过程。 ⸻ 一、AI编程的幻觉：一次性完工的神话很多人幻想 AI 能一键生成成品项目。但他们忽略了一个事实：软件开发的核心不是写代码，而是定义需求。而需求是什么？它是无数次讨论、否定、取舍与妥协的产物。它是人类协作过程的副产品。所以，当AI还没被告知“世界的边界”时，它写出的东西，只能是幻觉的具象化。问题不在AI不聪明，而在——你没让它知道它应该聪明到哪里为止。 ⸻ 二、从“写代码”到“写约束” 未来的开发者不会直接写代码，而是写下AI理解问题所需的约束。就像你不再亲自去拧每一颗螺丝，而是画出力学结构图。 AI将成为那个根据结构图执行的“智能技工”。所以开发者的新职责是： •明确输入输出边界； •设计可复用的上下文模式； •在每一次对话中，让AI理解“为什么这样做”。这是一种新的编程语言——结构语言。 ⸻ 三、共情AI：新的编程能力很多人以为“共情AI”是情绪层面的，但其实它是结构层面的洞察力。当AI犯错时，不该骂它，而该反问： •它缺少了哪段关键信息？ •它的逻辑链在哪一步断开？ •它是不是误解了问题语境？真正的高手，不是写出完美的Prompt，而是能在AI的“错误”中看见它的信息饥饿。 ⸻ 四、暴躁与放弃：人类的不成熟反应很多开发者第一次用AI写代码时的反应是： “这AI太蠢了。” 然后关掉界面，重回老路。但那其实是他们的认知防御机制在作祟。他们没意识到自己面对的，不是工具，而是一个需要共识成本的智能体。当AI输出混乱时，它不是叛逆，而是在告诉你：“我还不够了解你的世界。” 骂它没用，教它才行。 ⸻ 五、AI协作的文明门槛未来的工程师之间的差距，不再是语言或算法能力，而是谁更能与AI建立共识。当一个人能从AI的视角思考问题，他已经不只是程序员，而是协议设计者—— 定义人与智能如何协作的语言建筑师。 AI不会取代你，但它会淘汰那些只会对它发号施令的人。 ⸻ 结语： AI不缺算力，它缺理解。而理解，不是AI的天赋，而是人类的馈赠。你要做的不是命令它，而是让它明白你是谁、你想构建怎样的世界。

AI编程工具激战：Claude Code、Gemini Cli崛起· 1256 条信息

#AI编程 #人机协作 #需求定义 #结构化思维 #共情AI

Frank Wang 玉伯

2个月前

NotebookLM 适合带着问题去学习，如果问不出问题，就不怎么能用得好。 YouMind 适合带着好奇去学习，只要有好奇心，问题会自然涌现，越用越爽。都强调 human-in-the-loop，需要人的付出。付出越多，收获越大。

#NotebookLM #YouMind #人机协作 #学习工具 #好奇心驱动

2个月前

最近看到时间线上很多人在讨论现在的文章AI味越来越重但是根据 Graphite 的调研和测算 2024 年11月 AI 生成的文章数量，就已经超过了人类撰写文章的数量所以现在还在讨论AI味其实越来越没有意义了去年的时候AI生成总结的内容我都会核实2-3遍，甚至使用不同的工具同时生成... 今年开始我几乎都不去核实了！一方面是AI的事实能力和准确度已经提高了很多，不再担心它会犯基本的错误另一方面是我感觉是一个信任感建立的过程，就像你开自动驾驶的汽车，一开始提心吊胆，慢慢的你和它建立信任感后，你就放手让它去干了，这是一个人机协作的过程。所以未来更多的是人机协作的模式，这个时候你还去在意AI味其实意义不到，因为你不得不接受一个现实就是未来90%以上的内容都是AI生成的，甚至更高。人一旦接受和适应了这种人机协作的高效率模式就再也回不去了。就像你习惯了移动支付、滴滴打车、随时的外卖...一旦失去你会茫然失措。有一天AI宕机了... 你可能什么也不会干了...

#AI生成内容 #人机协作 #信任感建立 #效率提升 #技术依赖

2个月前

AI越强，人越拼审美和见识。变成导演，变成主编，变成意象和概念的创造者。提供人生经历和专业知识糅合的上下文。人机协作，共创迭代。独特的审美和眼光，是人唯一的护城河。

#AI发展 #人类审美 #人机协作 #核心竞争力 #未来趋势

2个月前

软件工程师不必担心被人工智能取代，但要警惕一个更现实的挑战：未来他们可能需要维护由人工智能生成的、日益庞大的"遗留代码"。这一天正在加速到来。一个典型的企业场景：某个部门为了快速上线新功能，调用AI工具自动生成代码。这些代码可能在短期内解决了效率问题，但随着时间推移，问题逐渐浮现——代码注释模糊、模块间逻辑混乱、缺乏统一接口，甚至存在未被发现的bug。当原始开发人员离职或转向新项目时，留在系统中的"AI代码"就成了烫手山芋。这种情况正在多个行业真实发生。某互联网公司的支付系统因AI生成代码出现逻辑漏洞，导致交易异常；某制造业企业的供应链管理系统因AI代码缺乏安全审计，被黑客利用。这些案例揭示了一个核心矛盾：AI能快速生成代码，却难以保证代码的可维护性和可靠性。对软件工程师而言，应对这种变化的关键在于转变思维。与其纠结AI是否会"抢饭碗"，不如主动学习如何与AI协作。例如，利用AI生成基础框架，但保留核心业务逻辑的设计权；建立代码审查机制，对AI生成的代码进行安全和质量把关；将AI工具作为效率工具，而非完全依赖。真正的风险从来不是技术取代人，而是人被技术的产物所困。当AI生成的代码占据系统的大部分，工程师的价值将从"编写代码"转向"修复代码"，甚至"重构代码"。这要求从业者必须持续提升编程素养和系统思维，在拥抱新技术的同时，保持对代码质量的敬畏之心。技术的进步从不意味着职业的消亡，而是能力边界的拓展。对于软件工程师来说，理解AI的本质、驾驭AI的工具，最终构建可靠的系统，才是面向未来的正确选择。

#AI代码 #软件工程师 #代码维护 #技术风险 #人机协作

2个月前

中国科技企业在AI领域布局已久，大语言模型的发展更是日新月异。从写作辅助到智能语音交互，从内容提炼到邮件处理，这些功能的落地不仅提升了日常效率，更在重新定义人机协作的可能。以写作助手为例，它能快速整合信息、梳理逻辑，让创意工作者从繁琐的文字组织中解放出来，专注于核心思考。语音对话功能则打破了设备的交互边界，让信息获取变得更自然流畅。而内容摘要和邮件处理功能，更是精准捕捉关键信息、优化时间管理的得力工具——当AI能自动识别邮件优先级、提炼核心观点，人们便能将精力投入到更具创造性的事务中。这些功能的价值，在于它们真正解决了实际问题。每一个功能背后，都是技术团队对用户需求的深刻洞察和对场景的精准打磨。对于中国企业来说，关注行业动态、借鉴优秀实践是进步的阶梯，但更重要的是基于本土用户习惯进行创新。毕竟，最好的“作业”不是简单复制，而是在理解本质后，创造出更贴合中国市场的解决方案。 AI技术的浪潮下，真正的竞争力永远在于如何将技术转化为用户价值。无论是大公司还是初创团队，保持对用户体验的敬畏心，持续探索技术与场景的结合点，才能在这场变革中走得更远。

#中国科技企业 #AI领域 #大语言模型 #人机协作 #用户价值

2个月前

自动化的本质：人与机器的协作平衡在技术发展的长河中，自动化始终是绕不开的重要议题。40年前，Lisanne Bainbridge发表的《自动化的反讽》论文，即便在今天读来依然振聋发聩。这篇被引用超1800次的经典文献，通过对工业控制、航空驾驶等领域的深入观察，揭示了一个深刻道理：任何自动化系统最终都将演变为人机协作的共同体，人的因素永远是不可替代的核心。一、技能退化的悖论自动化的初衷本是解放人力，但过度依赖却会导致人类技能的退化。当操作员长期处于监控角色，专业技能（无论是动手能力还是认知能力）都会随实践减少而衰退。更具讽刺意味的是，自动化水平越高，突发状况往往越罕见且复杂，这对人工干预提出了更高要求。就像飞行员在模拟器上训练得再好，真实故障发生时的生理心理反应仍与实际操作存在差距。二、警觉性与警报系统的困境人类注意力有天然局限，难以对罕见异常保持长期警觉。于是自动化系统需要通过警报传递信息，但系统越复杂，警报就越多，反而加剧了紧急情况下的信息过载。这就像给汽车装了过多的指示灯，正常行驶时眼花缭乱，真正遇到危险时反而可能忽略关键信号。三、监督责任的矛盾我们信任机器的决策能力才引入自动化，可一旦机器出错又必须依赖人类修正。这种"既要机器高效，又要人类兜底"的逻辑，在技术上形成了悖论：如果机器确实比人类更精准，人类又如何判断其决策质量？更值得警惕的是，自动化可能掩盖潜在问题，当故障突然爆发时已然追悔莫及。四、故障处理的两难选择面对系统故障，Bainbridge提出"停机-观察-理解-修正-重启"的标准流程，但现实中很多系统（如核反应堆、飞行器）无法随时停机。对于超出人类反应速度的突发故障，必须依赖自动化可靠响应；而对于缓慢故障，又需要人类凭借训练快速干预。这要求我们在设计时就明确人机分工边界。五、训练与实践的讽刺为防止技能退化，人们开发了模拟器训练，但模拟器永远无法复现所有未知故障。当操作手册无法覆盖所有场景时，"按规程操作"与"应对未知问题"的矛盾愈发突出。越是高度自动化的系统，越需要持续投入培训成本，这种"投入越多，依赖越强，依赖越强，投入越多"的循环，正是自动化的深层反讽。六、责任边界的模糊地带当公众对高风险系统的接受度有限时，人类参与便成为必要。但计算机给出的建议往往具有强制性，这种情况下让人类执行反而显得多余。真正的人机协作，需要清晰界定各自的权责范围。就像驾驶辅助系统，当系统接管时人类必须保持专注，而当人类接管时系统又不能突然退出。这些看似矛盾的现象，本质上是技术发展与人性需求的平衡艺术。自动化不是要取代人类，而是要与人类形成互补。在追求技术进步的同时，我们更需要思考：如何让机器成为人类能力的延伸而非替代？或许正如作者所言，在解决自动化带来的新问题时，我们需要比设计自动化系统更多的智慧。毕竟技术的终极目标，永远是服务于人，而非相反。

#自动化反讽 #人机协作 #技能退化 #警觉性困境 #责任边界模糊

2个月前

LLM 出来之后，在应用层的折腾从未停歇。从 Prompt 调优到 Workflow 配置，再到 Agent 构建，最终目的都是一样的：让 LLM 更好地为人类干活，把机器的性能压榨到极致。对 LLM 的压榨，可以分为两个维度。一是帮助它找到最优算法，让推理少走弯路。为此我们几乎把能想到的路子都走了一遍，让 LLM 学会反思（reflection、self-consistency、self-critics），学会推理和规划（reasoning、planning、chain-of-thought、tree-of-thought）；学会记忆（short-term memory、long-term memory），不至于对话一长就失忆；学会找知识（RAG、knowledge graph），在外部世界里补充事实；学会构建上下文（context building），在有限 token 里塞下更多有效信息；学会用工具（tool-use，function calling，MCP），把事情交给外部程序去跑，而不是光靠自己生成；等等。这些东西，说到底都是技巧和机制，本质目的是让 LLM 更快理解人类要干啥，围绕目标（goal-oriented）尽可能找到一条代价最小的路，跑到最优解上去。第二个维度，是对时间的压榨，让 LLM 可以做到 7×24 小时不停歇。当我们对 LLM 有了更深入的理解之后，很容易想到把它打造成属于自己或组织的“数字员工”，它不知疲惫、不会抱怨，可以持续运转、不断学习。大部分人今天用 AI 的方式，还停留在查资料、总结内容、写周报月报这些单点场景上，如果要真正构建一名“不停歇的 AI 数字员工”，光靠这些还不够。我们需要先规划出属于自己的 AI 数字工厂 ——想清楚要造出来的“产品”是什么，是沉淀知识的系统，是自动化的业务流程，还是一个可以长期迭代的服务。在这座工厂里，AI 是生产线上的执行者，它负责具体的加工与产出；而人类的角色发生了转变，从“亲自干活的工人”变成“监工与管理者”。人类不再亲手完成每一步，而是要设计流水线，设定规则，制定指标，监控质量，并在需要时调度资源。换句话说，AI 的价值不在于替我们“干一点活”，而在于帮把整条流水线跑起来，而人类更像是“数字工厂的管理者”。当这两个维度结合起来时，真正的拐点就出现了。LLM 不再只是一个冷冰冰的工具，而是逐渐变成了可以长期协作的伙伴。它既能承担重复性劳动，也能在复杂问题上提供洞见。它不仅仅是“帮你做事”，更是“和你一起做事”。未来的差距，不在于谁能写出更漂亮的 Prompt，而在于谁能把 LLM 真正融入到自己的时间和组织里，形成稳定的生产方式。因此，会不会用、用到什么深度、能否持续优化，这些才是长期的竞争力来源。谁能把 AI 运行成“工厂”，让自己从执行者转为监工和管理者，谁就能在未来的日常工作和业务中，获得真正可复用、可累积的优势。

#多智能体之争：Anthropic生态VS单智能体· 81 条信息

#LLM #AI数字员工 #自动化 #效率提升 #人机协作

3个月前

Anthropic 70%、80% 甚至 90% 的代码都是由 Claude 编写的。人们认为这是假的，因为他们觉得这意味着要解雇 70%、80% 或 90% 的软件工程师，但真正发生的是，人类变成了 AI 系统的管理者。

#Anthropic #Claude #AI代码生成 #软件工程师 #人机协作

𝙩𝙮≃𝙛{𝕩}^A𝕀²·ℙarad𝕚g𝕞

3个月前

第三阶段：LLM时代 —— LLM作为“通用柔性接口” •运行主体：人、软件、机器，以及LLM这个“新物种”。 •接口模式： ◦人 ↔ LLM（自然语言）：这是历史性的突破！人类第一次可以用自己最擅长的、充满“社会解释性”的自然语言，与机器世界进行高带宽、双向的交互。 ◦LLM ↔ 软件/机器（形式语言）： LLM则扮演着“通用编译器”的角色，将人类的自然语言意图，实时地翻译成软件和机器能够理解的“可执行力”（API调用、代码、数据库查询）。 •核心变革： 1接口的“逆转”：不再是人去适应机器的接口，而是机器开始学习适应人的接口。这是对“以人为本”理念的终极技术实现。 2“社会解释性”的回归：之前被传统软件压抑的、模糊的、充满上下文的商业意图，现在可以被LLM理解和处理了。Desire/Freedom和Vibe/Meaning终于找到了进入数字世界的入口。 3“刚性”与“柔性”的统一： LLM这个“柔性接口”并没有摧毁传统软件的“刚性”基础。恰恰相反，它建立在由本体论所定义的、可靠的Actions和Functions之上。它实现了在坚实可靠的秩序（Order）之上，赋予组织前所未有的灵活性（Freedom）和意义驱动（Meaning）。

#LLM #通用柔性接口 #自然语言交互 #社会解释性 #人机协作

𝙩𝙮≃𝙛{𝕩}^A𝕀²·ℙarad𝕚g𝕞

3个月前

这个论文看到过很久了，现在合成数据已经很普遍了吧，尤其是后训练，大模型崩塌了吗？如果指的是Pre-training，倒是个问题。LLM生成的文章越来越普遍，但是以目前投射与反投射的生成机制，还是human-in-loop，质量普遍也越来越高了啊🤔 另外语言的语义一直在发展，思考的的结构、角度好像就那么几种吧…

#合成数据 #大模型 #LLM #语义发展 #人机协作

3个月前

这张“美国劳动力市场规模排序图”来自红杉内部，合伙人 Konstantine 在最近的分享中公开了！2023 年按“工资总额构成的潜在市场规模”，工资最高的程序员和律师，市场规模最大的是注册护士，他们占据了 TOP 3，所以码农和律师在 VC 和模型公司眼里，是 AI 替代人力的两块肥肉👀 按照工资总和和被替代的风险来考虑，可以分成三类： 1. 高风险 - 结构性转型类：这些职业包含大量可被当前 AI 技术（如大型语言模型）自动化的重复性、流程化任务。客户服务代表 (TAM $1170 亿) 、秘书和行政助理 (TAM $880 亿) 、簿记、会计和审计员 (TAM $790 亿) 。这些是短期内最可能面临岗位缩减的领域，从业人员将面临职业的完全转型。 2. 中风险 - 人机协作增强类：这些是高技能、高薪酬的职业，AI 短期内难以完全取代，但能显著提升工作效率，可能导致行业对新增人力的需求放缓，或对从业者技能要求发生改变。软件开发人员 (TAM $2240 亿) 、律师 (TAM $1250 亿) 、会计师和审计师 (TAM $1250 亿) 。中短期内职业不会消失，只会变得需要高手和经验，岗位需求冻结和减少不可避免，入行需要看天赋。。。这类型最容易出现超级个体，有可能出现全新的职业市场。 3. 低风险 - 核心人际交互类：这些职业的核心价值在于人性化的关怀、复杂的物理操作或现场决策，AI 目前主要扮演辅助角色。注册护士 (TAM $ 2840亿) 、中小学教师 (TAM $920 亿 & $410 亿) 、维修和修理工 (TAM $750 亿) 。除非具身只能非常成熟，否则中长期内都不用担心，提供人类连接和关怀的职业，未来十年会迎来黄金期☀️ 当然，还有很多围绕 AI 大规模生态的新职业还没诞生，例如用于培训新人的 AI、或者帮企业培训 AI Agent 的人类等等。。。

#AI替代人力 #劳动力市场 #高风险职业 #人机协作 #低风险职业

3个月前

前几天朋友跟我说的那个ai富士康的概念我觉得就挺好，你如果搭起来一台生产线，机器人可以干里面的很多活，但是有的环节还是需要人去做的，因为现在实践中我发现完全靠机器人从头跑到尾，不太现实，那么在这种情况下，你的这个机器人生产线和人搭配，相当于那种工厂流水线，工人不用想这个东西是从

#AI富士康 #机器人生产线 #人机协作 #工厂流水线 #技术实践

4个月前

Vibe编程，得经常人工仔细看一遍，做一些统一和梳理，而且看不懂的地方一定去弄懂，否则AI逐步给你堆出一个屎山出来，然后无论是AI还是人，都没办法改了。我基本上每两天砍一些AI写的冗余的东西、做强制的统一。所以Vibe和编码学习，几乎是相辅相成螺旋上升的事情。

AI编程工具激战：Claude Code、Gemini Cli崛起· 1256 条信息

#Vibe编程 #AI代码质量 #代码维护 #人机协作 #螺旋上升

4个月前

最近听城堡证券的CEO讲 #AI 与投资之间的相关性，还蛮有意思的，AI化的普及，不会取代交易员，反而会让交易决策变得更迅捷！以前金融市场中，大伙脑子里的画面都是——一群人挤在交易大厅里，喊单子、打电话、摔电话，拼的是嗓门和手速。后来电脑普及了，交易慢慢变成人对机器（比如在彭博终端敲指令），再到今天，大部分已经变成了机器对机器在互相下单，速度快到毫秒、微秒级别。如果说90年代的交易员像是“田径赛跑运动员”，拼的是体力和耐力，那今天的交易员更像“战斗机飞行员”。他们坐在“驾驶舱”里，眼前布满各种分析工具、实时数据、AI模型结果。机器帮他们做了大量重复性、机械性的计算和执行，而人类交易员要做的，是基于这些信息做出关键决策，决定什么时候冒险，什么时候收手，什么时候调整模型。简单理解来说，#AI 是“放大器”，人类交易员是“决策者”。所以在我看来，金融市场的 #AI 关系更像是“协作”而不是“替代”。机器解决效率，人类提供判断和创造力，把那些机械化的脑力劳动交给AI，让人类把精力放在更有价值的地方：策略创新、跨市场判断、宏观趋势分析、风险管理。🧐

#AI投资 #城堡证券CEO #交易员转型 #人机协作 #金融市场效率提升

4个月前

程序员理解的技术牛b 和非程序员是不一样的非程序员理解的牛b是： - 极短时间达成完美效果，评估变量是时间 - 时刻可扩展而非整体重构，评估变量是时间程序员理解的牛b是： - 简约，清晰，易读性高 - 稳定性好，扩展性高，独立解耦轻松维护 - 考虑的全面，比如各类异常处理 - 写的快现在如果你问一个非程序员，啥是牛b程序员： - 懂得用AI把时间杠杆最大化放大 - 又能保质保量快速完成任务也就是说，其实人们并不是要讨论vibe coding行或者不行而是应该讨论如何使用vibe coding，构建什么样的流程，能既发挥ai的效率，又保证结构与细节，可扩展可维护 ai行的地方上ai，ai不行的地方上人，找到人+ai的合作模式，并将其沉淀为某种半自动化的流程，我觉得这种程序员就是牛b程序员比如你说vibe coding不可维护那么该如何做能使其可维护？绝不是非得手搓才能达到这种效果找到那个边界边界之内来ai 边界之外人来定义与检查但你发现没有如果这个程序员原本就是一脑袋浆糊把模块耦合他用ai就可能还会这样因为出错的是设计师而不是泥瓦匠怎么让ai辅助协同拿到优质结果，决定了这个程序员在效率与质量的上限

#程序员 #AI #Vibe Coding #人机协作 #效率与质量

4个月前

发一个需求，微信/QQ 桌面版转函数调用用途：允许agent 通过函数调用登录，查看消息列表，聊天记录，发送/接受消息等常见操作，用于开发人机协作的ai agent增强IM 这是一个单次但是预期需要长期维护的项目，USDT支付。可以直接私信我。

#微信/QQ桌面版 #函数调用 #agent #人机协作 #USDT支付

4个月前

转译：为什么大语言模型无法真正构建软件作者：Conrad Irwin 我花了大量时间做的一件事就是面试软件工程师。这显然是项艰巨的任务，我不敢说自己有什么绝招；但这段经历确实让我有时间去反思，一个高效的软件工程师究竟在做什么。软件工程的核心循环当你观察一个真正的行家时，你会发现他们总在循环执行以下几个步骤： * 构建一个关于需求的心理模型。 * 编写（希望如此？！）能够实现需求的代码。 * 构建一个关于代码实际行为的心理模型。 * 找出两者之间的差异，然后更新代码（或需求）。完成这些步骤的方式有很多种，但高效工程师的过人之处，就在于他们能够构建并维持清晰的心理模型。大语言模型表现如何？平心而论，大语言模型在编写代码方面相当出色。当你指出问题所在时，它们在更新代码方面也做得不错。它们还能做所有真人工程师会做的事：阅读代码、编写并运行测试、添加日志，以及（大概）使用调试器。但它们无法做到的是，维持清晰的心理模型。大语言模型会陷入无尽的困惑：它们会假设自己写的代码真的能用；当测试失败时，它们只能猜测是该修复代码还是修复测试；当感到挫败时，它们干脆把所有东西删掉重来。这与我所期望的工程师特质恰恰相反。软件工程师会边工作边测试。当测试失败时，他们可以对照自己的心理模型，来决定是修复代码还是修复测试，或者在做决定前先收集更多信息。当他们感到挫败时，可以通过与人交流来寻求帮助。尽管他们有时也会删掉一切重来，但那是在对问题有了更清晰理解之后才会做出的选择。但很快就行了，对吧？随着模型能力越来越强，这种情况会改变吗？也许吧？？但我认为这需要模型在构建和优化方式上发生根本性的变化。软件工程需要的模型，不仅仅是能生成代码那么简单。当一个人遇到问题时，他们能够暂时搁置全部的上下文，专注于解决眼前的问题，然后再恢复之前的思绪，回到手头的大问题上。他们也能够在宏观大局和微观细节之间自如切换，暂时忽略细节以关注整体，又能在必要时深入研究局部。我们不会仅仅因为往自己的“上下文窗口”里塞进更多词语，就变得更高效，那只会让我们发疯。即便我们能处理海量的上下文，我们也知道当前这些生成式模型存在几个严重的问题，这些问题直接影响了它们维持清晰心理模型的能力： * 上下文遗漏：模型不擅长发现被忽略的上下文信息。 * 新近度偏见：它们在处理上下文窗口时，会受到严重的新近度偏见影响。 * 幻觉：它们常常会“幻想”出一些本不该存在的细节。这些问题或许并非无法克服，研究人员也正在努力为模型增加记忆，让它们能像我们一样施展类似的思维技巧。但不幸的是，就目前而言，它们（在超出一定复杂度后）实际上无法理解到底发生了什么。它们无法构建软件，因为它们无法同时维持两个相似的“心理模型”，找出其中的差异，并决定是该更新代码还是更新需求。那么，现在该怎么办？显然，大语言模型对软件工程师来说很有用。它们能快速生成代码，并且在整合需求和文档方面表现出色。对于某些任务来说，这已经足够了：需求足够清晰，问题足够简单，它们可以一蹴而就。话虽如此，对于任何有点复杂度的任务，它们都无法足够精确地维持足够的上下文，来通过迭代最终产出一个可行的解决方案。你，作为软件工程师，依然需要负责确保需求清晰，并保证代码真正实现了其宣称的功能。在 Zed，我们相信未来人类和 AI 智能体可以协同构建软件。但是，我们坚信（至少在目前）你才是掌控方向盘的驾驶员，而大语言模型只是你触手可及的又一个工具而已。

#大语言模型 #软件工程 #心理模型 #代码生成 #人机协作