ginobefun

统计数据

162

文章

0

粉丝

0

获赞

611

阅读

16小时前

这两天工作比较忙，《智能体设计模式》中文翻译的进度慢下来了，今天争取把第五章校对完 💪。项目自上周五创建以来，已经收获了 1.1k Star，非常感谢大家的支持！也欢迎更多对这本书感兴趣的朋友加入翻译小组，一起协作。 🔗 项目地址:

#智能体设计模式 #翻译 #开源项目 #感谢 #积极

16小时前

本周 BestBlogs 精选内容已邮件推送，欢迎阅读 ----------------------------- 🚀 模型与研究亮点： ✨ Anthropic 发布了 Claude Haiku 4.5 ，该小模型以其接近顶尖的编码性能、显著的成本效益和更快的处理速度，重新定义了高智能 AI 的可及性与效率。 🎬 谷歌 DeepMind 推出 Veo 3.1 模型，通过增强真实感、提示遵循度和视听质量，并集成生成音频和高级编辑功能，革新了 AI 视频创作工具 Flow 。 📄 百度开源了自研多模态文档解析模型 PaddleOCR-VL ，其 0.9B 参数量在 OCR 四大核心能力上全面刷新 SOTA，打破了“大模型才有好效果”的迷思。 💡 阿里巴巴开源了 Logics-Parsing 模型，基于 Qwen2.5-VL 架构，利用布局为中心的强化学习，有效解决了复杂 PDF 文档的端到端结构化处理难题。 💻 大语言模型结构化输出成为构建可靠 AI 应用的核心，文章深入解析了模式引导生成、约束解码、SFT 及 JSON Mode 等六大关键技术路径。 🤔 深度分析当前大语言模型 LLM 的过度宣传与“p^n 困境”，强调 AI 缺乏真实智能，并提出构建人机协同系统的三大原则以应对其固有局限性。 🛠️ 开发与工具精粹： 🔗 LangChain 与 Manus 深度探讨 AI 智能体上下文工程，提出了上下文卸载、缩减、检索、隔离等策略，并通过 Manus 的“分层行动空间”优化工具调用。 📝 规约驱动开发 (SDD) 作为 AI 辅助编码的新范式被详细解析，其规约优先、规约锚定、规约即源的理念及 Kiro 、Spec-kit 、Tessl 等工具成为关注焦点。 ⚙️ 特斯拉前 AI 总监 Andrej Karpathy 开源了 nanochat 项目，以约 8000 行 Rust 代码和 100 美元的成本，从零开始构建了一个简易版 ChatGPT ，并提供了详细教程。 🧑‍🏫 吴恩达推出 Agentic AI 新课程，将智能体工作流开发沉淀为反思、工具、规划和协作四大设计模式，实战证明能让 GPT-3.5 在特定任务中超越 GPT-4 。 Go 腾讯发布 tRPC-Agent-Go 框架，旨在填补 Go 语言在自主多 Agent 协作框架领域的空白，集成了 LLM、智能规划、工具调用等能力。 🔄 《智能体设计模式》深度解析了 AI 智能体的反思模式，通过“生产者-评审者”架构实现自我评估和迭代改进，显著提升任务输出质量，并提供实战代码示例。 💡 产品与设计洞见： 🔧 Anthropic 推出 Claude 技能功能，用户可将专业知识与指令打包成技能包，定制 Claude 的工作流程，实现可组合、可移植、高效且强大的 AI 任务执行。 🔍 谷歌搜索产品副总裁 Robby Stein 揭示了谷歌 AI 转型的内幕，强调 Gemini 、AI 概览和 AI 模式如何通过更自然的语言和多模态输入，扩展而非取代传统搜索。 🎨 Figma CEO Dylan Field 认为在 AI 时代，设计、工艺和毫不妥协的质量将成为初创企业新的竞争优势，强调产品开发中培养品味的重要性。 🏢 硅谷内部讨论会揭示，AI Agent 部署失败的 95%并非模型智能不足，而是上下文工程、安全性、记忆设计等支撑体系缺失，强调治理与信任及多模型推理。 🚀 Slack 首席产品官 Rob Seaman 提出在 AI 时代，传统路线图已失效，应围绕客户与业务结果规划，并通过精简团队快速原型设计，加速产品开发和创新。 📈 Lovable 增长负责人 Elena Verna 强调 AI 正在瓦解传统分发渠道，产品增长需从漏斗模型转向增长飞轮，构建数据护城河并利用产品作为营销渠道。 📰 资讯与报告前瞻： ⚡ Nathan Labenz 驳斥 AI 发展减速论，强调 AI 在推理能力、上下文扩展及作为“协同科学家”方面的持续进步，并预见多模态 AI 的关键作用。 🖥️ 英伟达发布个人 AI 超级计算机 DGX Spark ，将数据中心级 DGX 架构浓缩至桌面，售价 3999 美元起，旨在实现本地高效 AI 开发和推理，并支持 OpenAI API 服务。 🤝 美图公司吴欣鸿分享在 AI 时代下的组织进化心得，实践“反惯性工作流”，提出“AI 原生组织”模式，倡导“一个人即一支团队”理念，并普及 AI 编码。 💰 《State of AI Report 2025》指出 2025 年是 AI 业务追平炒作的“推理之年”，头部 AI 公司年化收入已达百亿美元，AI 编程、音视频生成等商业领域取得显著成功。 ✍️ 语言学家娜奥米·S·巴伦深刻剖析 AI 时代人类写作的核心价值与挑战，强调写作是思考与情感表达的独特方式，呼吁“增强而非自动化”并划清人机协作界限。 ⚖️ 北京大学论文揭示 AI 在加速知识产出的同时，可能加剧内容和思想同质化，产生“创造性伤痕”效应，警示 AI 带来的“资历偏向”重塑劳动力市场。希望本周的精选文章推荐能帮助您快速了解 AI 领域的最新进展！期待与您下周再见！

#AI进展 #大模型 #AI工具 #AI应用 #AI伦理

4天前

Github 博客分享了如何使用智能体原语和上下文工程构建可靠的人工智能工作流 🔽

#GitHub #智能体原语 #上下文工程 #人工智能工作流 #技术分享

4天前

这家伙在自己没写任何代码的情况下，使用多种 AI 工具开发了一款移动应用。

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

#AI工具 #移动应用开发 #零代码 #创新 #技术

5天前

淘宝信息流通过 AI 驱动的 WaterFlow 平台，实现产品需求端到端自动化开发，大幅提升迭代效率，部分需求甚至可由产品经理直接开发。

#淘宝信息流 #AI驱动 #WaterFlow平台 #自动化开发 #迭代效率提升

5天前

Anthropic 亲自下场教学，用这份零门槛的交互式指南带你解锁 Claude 的真正潜力，让你的提示工程技能瞬间升级。

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

#Anthropic #Claude #提示工程 #交互式指南 #教程

5天前

人生的幸福感常被描述为一条 U 形曲线，中年是那个无可回避的谷底。这不仅是外部压力累积的结果，其本质更是一场深刻的内部危机：我们曾经赖以生存的思维模式与行为习惯，在不知不觉中变得僵化，失去了年轻时的灵活与开放。我们感到力不从心、沮丧懈怠，正是因为内心世界变得封闭，失去了成长的活力。中年最大的危险，不是打击和意外，而是我们默许自己混日子。曾国藩的人生经历则揭示了另一条道路：所有的低谷，都可以是新的爆发点。他所践行的「突围」，并非是向外冲杀，而是一场向内的自我对话与人生再造。这场突围包含四个关键步骤，层层递进，直至核心。一、打开心态：从「我是对的」到「也许我错了」这不仅是谦虚，而是主动打破过往经验的牢笼。人到中年，最容易被自己的成功经验所困，认为自己手握真理，把所有问题都归咎于他人。曾国藩也曾如此，他用固有的理学标准去衡量世界，结果处处碰壁，加深了对他人的成见和对自我的执着。真正的突围，始于放下「我永远对」的执念，敢于承认自己赖以成功的旧地图，在新的人生阶段可能已经失灵。只有时刻提醒自己「也许我是错的」，保持一颗开放和有弹性的心，我们才能为自己封闭的内心重新打开一扇窗，让新的空气和阳光进来，为真正的反思和成长创造可能。二、看到他人：从「以我为尊」到「和光同尘」这不仅是学会欣赏，而是摧毁自我中心的幻觉。当曾国藩被迫远离官场，以局外人的身份审视过往时，他才发现自己曾经鄙视的同僚并非一无是处，许多矛盾的根源恰恰是自己的骄傲自负。人到中年，必须完成一次视角的转换：从将世界看作是自己表演的舞台，转为将自己看作是复杂社会生态中的一员。当我们不再以自己为唯一的坐标，才能客观地看到他人的长处和自己的局限。主动「挫其锐，解其纷」，磨平自己的棱角，把自己融入集体，才能真正减少外界的阻力，获得更广阔的空间。三、当下不乱：从「思前想后」到「未来不迎，过往不恋」这不仅是专注，而是停止精神内耗的源头。我们的能量，常常在对过去的悔恨和对未来的焦虑中被白白消耗，这正是行动迟缓、效率低下的根源。我们总被想象中的困难吓倒，却忘了唯一能有所作为的，只有当下这一刻。曾国藩在绝境中「当下不杂」的定力，正是将所有能量从时间的虚无两端，强行拉回到「现在」这个实点的功夫。这种能量管理比时间管理更重要。把宏大的目标简化为眼前具体的一步，然后完成它。这是斩断内耗、重获行动主导权的唯一途径。四、积极自救：从「被动承受」到「主动破局」这不仅是乐观，而是一种身份的切换。面对困境，人最容易陷入受害者的无力感中。曾国藩一生败仗无数，但他最强大的能力，就是无论局势多糟，总能第一时间从一个被动的承受者，转变为一个主动的破局者。他思考的永远不是「我为什么这么不幸」，而是「在当前局面下，我还能做什么来反败为胜，哪怕只是减少损失？」这个问题本身，就是拒绝听天由命、重夺主动权的宣言。在任何时候，都不要放弃自救的权利，因为这才是走出困境的第一步。中年，是我们第一次清晰地感受到，我们无法靠过去的惯性跑赢时间。真正的突围，是放弃与时间对抗的幻想，转而寻求一种新的共存方式，和时间和解。我们不再执着于「更高、更快、更强」，而是开始追求一种更有火候的境界，更有质量的人生。

#中年危机 #自我突破 #曾国藩 #积极自救 #心态开放

5天前

最近美图创始人吴欣鸿的内部讲话，表面看是分享 AI 时代的组织进化，实则是一次深刻的自我剖析和对大公司病的宣战。最引人注目的观点，是他毫不避讳地指出了“惯性工作流”的弊病——那些看似规范却严重拖累效率的流程，比如“细节拉满但无人细读的需求文档”和“无休止的会议”。这背后反映出一种深刻的焦虑：在灵活的 AI 创业团队面前，传统互联网公司的规模和流程正从优势变为沉重的负担。他们提出的解法，是在 RoboNeo 项目中实践的“反惯性工作流”。其中最关键的突破，是借助 AI 工具，实现“一个人就是一支团队”。例如，海外运营仅靠一人完成，设计师 5 分钟就能上线一个新效果，这彻底颠覆了过去依赖多部门协作、排期的工作模式。这种变革的本质，是从依赖“流程和分工”转向依赖“人和工具”。它挑战了传统组织管理中“分工越细越专业”的共识，预示着未来组织的核心竞争力，将取决于能否将 AI 工具转化为个体战斗力，打造出小而精、高自主性的作战单元。

#美图 #吴欣鸿 #AI #组织进化 #反惯性工作流

6天前

以前，大家总跟我们说，要在一个领域里挖得够深，才能成为专家。可现在情况变了，AI 能把很多专业活儿干得又快又好，这时人的价值反而体现在「通才」上。比如能连接不同领域、有品味、懂战略的能力。所以说，让自己懂得多一些、知识体系更多元化，变得格外重要了。

#AI发展 #通才重要性 #多元化知识 #未来人才需求 #跨领域连接

6天前

最近听了 ElevenLabs 联合创始人兼 CEO Mati Staniszewski 的一次访谈，让我对 AI 时代的创业机会有了全新的思考。Mati 来自波兰，他创业的初衷非常有趣，源于他从小就无法忍受波兰引进的外国电影——所有角色，无论男女，都由同一个声音用平淡无奇的语调配音。他最初的宏大愿景，就是用 AI 彻底改变这个糟糕的配音行业。让我感到意外的是，他们放弃了这个性感的梦想，并因此获得了成功。当他们带着初步的配音产品去接触潜在用户时，得到的反馈出奇地一致。一位用户告诉他：“你的想法很有趣，但实际上，如果你能先帮我解决自己声音的问题……那就好太多了。” 他们很快发现，对于内容创作者来说，最迫切、最高频的痛点，并非颠覆一个行业，而是解决一个极其具体而无聊的需求：人们只是想在录制后，能轻松地修复或重录某一句台词。这个发现成了公司的转折点。他们果断地从宏伟蓝图转向了解决这个微小但真实的痛点，并因此赢得了第一批忠实用户和现金流，为后续发展奠定了基础。这背后是一种深刻的产品哲学：伟大的创新，往往始于解决一个具体而高频的麻烦，而不是一开始就去追逐一个遥远的星辰大海。这种务实的思考，也贯穿在他给普通创业者的建议中。当被问及普通人如何利用 AI 月入一万美元时，他的回答不是去开发什么新算法，而是建议大家：拿着现成的语音代理方案，去本地的牙医诊所，帮助他们实现预约自动化。这个建议之所以深刻，是因为它点破了一个被大多数人忽视的真相：在技术圈被视为常识的工具，对于圈外的广大传统行业来说，依然是遥不可及的未来科技。Mati 强调，这些诊所的老板们根本不知道这已经成为可能，而部署这些方案你甚至不需要成为一个程序员。当前 AI 领域最大的机会，或许并非创造更强的技术，而是将现有技术「翻译」和「部署」到真实世界的商业场景中。填补技术与需求之间的认知鸿沟，就是普通人最实际的黄金机会。

#AI创业 #elevenlabs #Mati Staniszewski #语音技术 #传统行业AI赋能

1周前

《智能体设计模式》中文翻译计划启动接下来的一周，我将通过 AI 初次翻译 → AI 交叉评审 → 人工精读优化的方式来翻译这本书，所有翻译内容将持续更新到开源项目：本书由 Antonio Gulli 撰写、谷歌 Cloud AI 副总裁 Saurabh Tiwary 作序、高盛 CIO Marco Argenti 鼎力推荐，系统性地提炼出 21 个核心智能体设计模式，涵盖从提示链、工具使用到多智能体协作、自我修正等关键技术。更难得的是，本书的所有版税都将捐赠给救助儿童会，这是一份真正属于开发者社区的公益之作。前言部分精华概览今天完成了前言部分的人工校对，完成的翻译内容我已发布到公众号，这里为大家梳理几个关键要点： 1. 来自行业领袖的深度洞见谷歌 Cloud AI 副总裁 Saurabh Tiwary 在序言中指出，我们正在从构建「仅能处理信息的模型」，迈向创造「能够推理、规划和行动的智能系统」。他将智能体开发比作在画布上创作，而设计模式正是这块画布上的基本笔触。高盛 CIO Marco Argenti 则以「权力与责任」为题，分享了他对智能体技术的深刻思考。他坦言自己最初是怀疑的——早期模型「被优化的目标是追求可信度，而非正确性」。但推理模型的出现带来了质的飞跃，他第一次试用智能体编程工具时，「感受到了那种久违的、如魔法般的火花」。更重要的是，Marco 强调了专业精神和企业文化的重要性。在金融这样高风险的领域，智能体的失误代价巨大。他提出的三大原则值得所有开发者铭记： - 为使命而构建：确保每个智能体都始于对客户问题的清晰理解 - 洞见未来，防患未然：预见失败模式，设计具有韧性的系统 - 启迪信任，不负所托：对方法保持透明，对结果负责 2. 什么是智能体系统？书中给出了清晰的定义：智能体系统是一种能够感知环境、根据目标做出决策、并自主执行行动的计算实体。不同于遵循固定脚本的传统软件，智能体系统具备以下核心特征： - 自主性：无需持续人工监督即可行动 - 主动性：能主动发起行动以实现目标 - 反应性：能有效应对环境变化 - 工具使用：与外部 API、数据库或服务交互 - 记忆：在多次交互中保留信息 - 通信：与用户、系统或其他智能体交互 3. 智能体的演进层级书中提出了一个实用的智能体分级框架： - 0 级：核心推理引擎 - 大语言模型本身，仅基于预训练知识响应，无法感知当前事件。 - 1 级：连接外部的问题解决者 - 能够使用外部工具来解决超出预训练知识范围的问题。这是 RAG 技术的典型应用场景。 - 2 级：战略性问题解决者 - 具备战略规划、主动协助和自我提升能力。核心赋能技能是提示工程和上下文工程。它能够战略性地选择、打包和管理最相关信息，确保高效决策。 - 3 级：协作型多智能体系统 - 这是一次重大范式转变：不再追求单一全能的超级智能体，而是转向复杂的、协作式的多智能体系统。就像人类组织一样，由不同专家组成的团队协同工作，通过劳动分工和协调产生强大的协同效应。 4. 智能体的未来：五大假设书中对智能体的未来提出了五个极具前瞻性的假设：假设 1：通用智能体的崛起 - 从狭隘专家演变为能高可靠性管理复杂、模糊、长期目标的通用型选手。替代路径是「乐高式」的小型语言模型组合。假设 2：深度个性化与主动发现目标 - 智能体将成为深度个性化的主动合作伙伴，不仅响应指令，更能预测需求，主动发现和支持用户的潜在目标。假设 3：具身化与物理世界交互 - 通过与机器人技术结合，智能体将挣脱数字束缚，在物理世界中运作，弥合数字智能与物理行动的鸿沟。假设 4：智能体驱动的经济 - 高度自主的智能体将成为经济中的积极参与者，创造新的市场和商业模式，形成超高效率的「智能体经济」。假设 5：目标驱动的、可演化的多智能体系统 - 系统能基于声明性目标自主运作，动态修改多智能体工作团队的拓扑结构，在架构层面和指令层面实现真正的自我演化。

#智能体 #设计模式 #AI翻译 #开源项目 #公益

1周前

以为 Kindle 已是过去式，没想到新款凭借惊艳的全面屏和AI 智能笔记，直接从阅读器进化成了高颜值的学习工具。

#Kindle #全面屏 #AI智能笔记 #阅读器 #学习工具

1周前

我认为这次分享最核心且反共识的观点可以归结为一句话：衡量 AI 进步的真正尺度，不是模型本身有多强大，而是我们度量它的那把“尺子”有多精准。长期以来，社区痴迷于模型参数量、架构创新和基准测试跑分，但 OpenAI 用亲身经历告诉我们，当旧的尺子已经无法反映真实能力时，整个领域的进步方向就会变得模糊。他们发现，“模型得分已经接近 100%，然而……仍然无法完成真实世界工作”，这暴露了旧尺子的失灵。这背后是一种回归本源的深刻思考：我们开发 AI 的最终目的是什么？答案是在真实世界中创造价值。因此，度量工具本身必须与这个最终目的对齐。GDP Eval 的诞生，以及整个 Evals 产品的推出，本质上都是在打造一把全新的、与真实经济价值直接挂钩的“尺子”。这把新尺子不仅能更准确地衡量模型的当前位置，更重要的是，它能像指南针一样，为未来模型的研发指明最有价值的方向。从这个角度看，评估体系的进化，可能比模型本身的进化更为重要，因为它定义了「进步」本身。

#AI评估体系 #GDP Eval #OpenAI #真实世界价值 #模型进步

1周前

正如设计模式曾是软件工程的圣经，这本由谷歌资深工程主管免费分享的《智能体设计模式》，正为火热的 AI Agent 领域带来首套系统性的设计原则与最佳实践。🔽

谷歌Deep Research：AI操作系统雏形？· 95 条信息

#AI Agent #设计模式 #谷歌 #系统性设计原则 #最佳实践

1周前

这两天高强度地折腾服务器，Warp 几乎全程在线。无论是安装 Nginx、调试部署脚本，还是申请 SSL 证书，和 AI 聊几句基本就搞定了。感觉以前需要查半天文档的活儿，现在几分钟就解决了。当然，越是方便，越要注意安全，关键信息千万别在对话里裸奔。

#服务器折腾 #Warp在线 #AI辅助 #效率提升 #注意安全

1周前

一提到「公司政治」，多数工程师的第一反应是远离。但如果有一种方法，既能让你告别内耗，又能让你的技术方案获得高层鼎力支持，你是否愿意了解？这篇博客的作者认为，工程师最大的错误就是试图去玩一场自己不擅长的「权力的游戏」。相反，真正有效的策略是看懂规则，然后选择在正确的时间，将你早已准备好的技术方案，递到最需要它的高管手中。这篇文章揭示的就是这种「等风来」的智慧，一种更适合技术人的生存法则。 --------- 作为一名专家工程师，我是如何影响公司政治的作者：sean goedecke 原文：很多软件工程师对公司政治都抱着一种听天由命的态度。他们觉得掺和进去纯属白费力气，因为： - 技术决策的背后往往是纯粹的私心，一个善意的工程师根本影响不了。 - 那些手握重权的利益相关者，通常既愚蠢又混乱，你根本没法搞懂他们的真实需求，更别提拿出解决方案了。 - 所谓的政治博弈，靠的是工程师压根接触不到的内部消息。你要是贸然参与，只会在里面瞎转悠。 - 管理层和高管们大部分时间都在搞政治，而工程师大部分时间都在搞技术。所以工程师还没下场，就已经输在了起跑线上。总而言之，大家普遍认为，软件工程师根本就不是玩这套游戏的料。没错！工程师要是觉得自己也能像《权力的游戏》里那样运筹帷幄、搞阴谋诡计，那可就大错特错了。你的那点小九九很快就会被识破，然后被别人利用，让你吃亏，让他们获利。玩心计需要经验和权力，这两样东西工程师都没有。事实就是，在大公司里，软件工程师往往是政治博弈中的棋子，而不是棋手。不过，不玩权谋，不代表你不能参与政治。顺势而为，而非凭空创造最简单的方法，就是主动投入，把一个高调的项目做成功。这差不多是你本来就该做好的分内工作。如果公司正在大力投资某个新项目 —— 比如现在最火的 AI 项目 —— 你用自己的技术把它做成，对于主导这个项目的副总裁或高管来说，就是送上了一份政治大礼。作为回报，你也能得到高管们能给的好处：奖金、晋升上的帮助，以及未来参与更多明星项目的机会。一个稍微难点但让你更有主动权的方法，是让你自己的私藏项目搭上高层关注的顺风车。比如，你早就想把某个现有功能抽出来做成一个独立服务。想实现它，你有两种办法。难的办法是消耗你自己的政治资本：到处游说，争取支持，告诉你的经理这对你有多重要，慢慢磨到大家都不反对了，项目才可能被正式批准。简单的办法是，让某个高管用他那多得多的政治资本来推你的项目。你要做的，是等到公司自上而下地推行某个目标，而这个目标正好和你的项目方向一致时（比如，在发生了一次重大线上事故后，公司开始强调可靠性）。这时候，你再跟你的经理提议，说你的项目可能很适合这个大方向。如果你判断对了，你的整个组织都会支持你的项目。而且，这非但不会消耗你的政治资本，反而会增加它。准备好你的“弹药库” 公司的关注点总是一阵一阵的。强调“可靠性”的时候，VP 们都急于“做点什么”。他们想找一些听起来靠谱的可靠性项目来投资，因为他们需要向自己的老板汇报工作，但他们自己又没能力凭空想出来。所以，工程团队提上来的任何建议，他们通常都很乐意买单。反过来，当公司的注意力在别的地方 —— 比如要发布一个重磅新产品 —— 他们最不希望看到的，就是工程师把时间花在客户完全感知不到的、为了内部可靠性而做的重构上。所以，如果你想在科技公司里把某件技术性的事情做成，你就得学会等风来。一个好方法是提前准备好几个不同方向的技术方案。厉害的工程师在日常工作中就会有意识地做这些储备。比如，你可能已经有了一些初步计划： - 把计费代码从缓存 API 调用改成基于 webhook 更新存储数据。 - 用 Vite 替换掉那个老掉牙的手摇构建流程。 - 把一个笨重的、高流量的 Python 服务用 Golang 重写。 - 把那个加载缓慢的、支撑着公开文档的 CMS 前端，换成一个快速的静态网站。当高管们开始关心计费问题时，你就可以把计费重构方案作为可靠性改进提出来。当他们关心开发者体验时，你可以建议替换构建流程。当客户抱怨性能时，你可以指出用 Golang 重写是个好选择。当 CEO 看了眼公开文档，觉得很丢人时，你就可以提议把它重建成静态网站。最关键的是，无论当下的“月度风向”是什么，你手里都要有一个详细、可行的方案随时准备好。你的职责所在不管你做不做这些准备，反正总得有项目被推行。但如果你不这样做，你就没法控制到底是什么项目。依我之见，这恰恰是公司做出最烂技术决策的时刻：当“必须做点什么”的政治需求，撞上了“没啥好点子”的窘境。没有好主意，那烂主意也只能凑合了。但没人想要这种结果。高管们很难受，因为他们得把一个令人失望的技术成果包装成成功案例去汇报；工程师们也很难受，因为他们得把时间和精力浪费在错误的事情上。如果你是一个非常资深的工程师，VP 们私下里会把这笔账算在你头上。而且他们这么做是对的！在正确的时间点，准备好正确的方案，这本身就是你的职责。你可以从两种角度来看待这一切。从悲观的角度看，我这是在建议你把自己变成一个方便的工具，好让那些管理公司的野心家们，在他们无休止的内部权力斗争中利用你。从乐观的角度看，我这是在建议你让高管们去设定公司的总体优先事项 —— 毕竟那是他们的工作 —— 然后你再把自己的技术规划与之对齐。无论你怎么看，只要能在正确的时间点推动正确的计划，你就能实现更多的技术目标。

#公司政治 #工程师 #技术方案 #高管支持 #生存法则

1周前

韩国政府这波操作真是惊为天人。他们轰轰烈烈地建了个国家级云盘 G-Drive，强制 75 万公务员使用，然后在一场火灾中发现…… 这系统竟然没备份！数据被一锅端，实现了真正意义上的物理删除。这完美绕开了 IT 入门第一课的所有知识点，把“3-2-1 备份原则”硬是执行成了“0-0-0”。这背后仿佛能看到有人为了省下「异地备份」那笔看似多余的预算，而签下大名的场景。这故事告诉我们，有时候最可怕的不是天灾，而是某个省钱的“英明”决策。

#韩国政府 #G-Drive云盘 #数据丢失 #缺乏备份 #预算决策失误

1周前

OpenAI 开发者日 2025，Sam Altman 主题演讲的四件事： - Apps SDK：在 ChatGPT 内部构建应用。 - Agent Kit：简化智能体的创建。 - Codex：一个能自主编写、重构、审查软件的智能体。 - 新模型 (GPT-5 Pro, Sora 2)：更强的大脑和新的感官（视频、音频）。这是一个典型的产品发布会：提供新工具，展示新能力。但这不是重点。

#OpenAI开发者日2025 #Sam Altman #GPT-5 Pro #Sora 2 #AI

2周前

远山如黛，近水含烟。

#远山 #近水 #烟 #景色描写 #中性

2周前

早上在鸟叫声中醒来

#鸟叫声 #早上 #醒来 #积极 #自然

2周前

AI 智能体的两个核心特征自主循环：从被动应答到主动执行智能体与传统程序在工作模式上有着根本区别。传统计算，包括许多既有的人工智能，遵循一种静态的交易模型。它们像一个自动售货机，接收一个明确的指令，然后提供一个预设的结果。这个过程是一次性的，缺乏状态和上下文，本质上是被动地等待下一个指令。而智能体的工作模式是一个动态的、持续的过程。它通过一个自主循环，将自身从被动的应答者，转变为主动的问题解决者。这个循环的核心在于，它接收的不是一个精确指令，而是一个高层次的意图。为了实现这个意图，它会自主地进行规划，将模糊的目标分解为一系列可执行的步骤。在采取行动后，循环中最关键的环节便会启动：自省。智能体会评估刚刚的行动结果，判断其是否让自己更接近最终目标，并根据评估结果来修正后续的计划。这种「行动-反思-调整」的闭环，使得智能体能够处理无法被预先编写脚本的复杂性和模糊性。它不再需要人类在每一步进行干预，而是被赋予了在一个任务周期内独立工作的能力，这正是其自主性的根本体现。目标驱动：为自主性设定方向与边界如果说自主循环是智能体的引擎，那么目标驱动的架构就是它的导航系统与行为准则。这套架构是人类向一个非确定性系统有效委托任务的契约，它确保了自主性既有明确的方向，又处在可控的范围之内。该架构包含三个核心要素。首先是目标，它为智能体的一切行为提供了清晰的方向和最终成功的评判标准。没有目标，自主循环便会陷入迷茫；有了目标，每一次循环都成为朝向终点的有效迭代。其次是规则边界，这是人类在让渡控制权时，为保障安全和信任而设置的安全阀。我们承认无法、也不必去微观管理智能体的每一步行动，但必须为其划定绝对不能逾越的红线。对于一个拥有自主能力的系统，定义其能力的边界，远比定义其能力本身更加重要。这些边界确保了智能体在广阔的行动空间内，始终运行在一个安全的、可信的子空间里。最后是适应能力，这是系统应对变化并从经验中学习的机制。它确保智能体在面对动态环境和意外情况时，能够调整自身策略，而不是僵化地执行过时计划。这种能力使系统具备了韧性，能够持续地优化路径以达成目标。这三者的结合，从根本上重塑了系统设计的思维范式。架构师的角色不再是设计一套精确的流程，而是去设计一个以目标为激励、以边界为约束、以适应性为核心的激励系统。我们不再构建一部机器，而是创造一个能自主学习和执行的环境。

#AI智能体 #自主循环 #目标驱动 #自省 #规则边界

2周前

#BestBlogs 【早阅】将 Claude 代码变成自己的超赞 UI 设计师（使用 Playwright MCP ） | 前端早读课文章详细阐述了如何通过集成 Playwright MCP 赋予 Claude Code 视觉能力，从而解决 AI 在前端 UI 设计中的盲点，实现像素级自校正和迭代优化，大幅提升设计效率和质量。摘要：文章深入探讨了 AI 在前端 UI 设计中面临的“盲点”困境，即传统 AI 代理无法“看见”自身代码渲染出的实际界面，导致设计通用且缺乏精度。为解决此问题，文章核心介绍了 Playwright MCP（模型协作协议）如何赋能 Claude Code 直接控制浏览器、截取屏幕截图，从而激活 AI 模型的视觉智能。文章进一步阐述了三个核心概念：作为 AI 工作流基石的“编排层”提供上下文、工具和验证机制；实现设计效率 10 倍提升的“迭代代理循环”允许 AI 自主运行并持续优化设计输出；以及通过屏幕截图“激活模型视觉智能”使其能进行更深层次的设计思考。此外，文章还介绍了文件作为 AI 记忆、子代理实现自动化与条件逻辑、Git Worktrees 并行开发策略以及视觉上下文提示最佳实践，为开发者提供了构建高效 AI 辅助设计工作流的全面指导。主要内容: 1. Playwright MCP 赋予 AI 代理视觉能力，解决了 AI 在 UI 设计中的“盲点”问题。 -- 传统 AI 因无法“看见”渲染界面而生成通用 UI，Playwright MCP 通过浏览器控制和截图，让 AI 能进行像素级自校正，显著提升设计精度和质量。 2. 迭代代理循环结合明确规范，使 AI 代理能长时间自主运行并持续优化设计输出。 -- 通过设定样式指南和 UI 模型作为验证器，AI 代理可进行多轮自我校正，大幅减少人工干预，实现设计流程的 10 倍效率提升。 3. 强大的编排层和文件是构建高效 AI 工作流的关键基石。 -- 编排层为 AI 提供全面的上下文、工具和验证机制；文件作为 AI 记忆，自动化加载设计原则和工作流配置，确保上下文一致性和工作流可移植性。 4. 激活模型视觉智能是提升 AI 设计深度的关键，通过屏幕截图充分利用其多模态能力。 -- Claude Code 等模型通过图像数据训练，Playwright MCP 提供的视觉反馈能激活其视觉智能，使其从实际视觉而非抽象代码层面思考设计，实现更精准的像素级优化和创意改进。文章链接：

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

#AI #UI设计 #Playwright MCP #Claude Code #视觉智能

2周前

假期第一天，和 AI 一起结对重新设计了 BestBlogs 的首页，看着清爽多了

独立开发者手搓新Logo，MarkTodo即将上线新版本· 81 条信息

#假期 #AI #BestBlogs #首页重新设计 #清爽

2周前

假期从陪娃看电影开始

#亲子 #电影 #假期 #娱乐 #积极

2周前

源自 Hacker News 上的这篇文章 🔽 文润转译： --------- 软件工程中的“品味”究竟意味着什么？技术品味（Technical taste）和技术能力（Technical skill）是两码事。你可能技术很强但品味不足，也可能技术平平却品味独到。如同生活中的品味，技术品味有时会超前于你的实际能力：就像你即便不会下厨，也能分辨佳肴与糟粕；同样地，即便你还不具备构建某种软件的能力，也可能已经知道自己喜欢什么样的软件。技术能力可以通过学习和重复练习来提升，但好品味的养成过程则更为难以捉摸。以下是一些衡量软件品味的指标： - 什么样的代码在你看来是“好看”的？什么样的又是“难看”的？ - 哪些设计决策让你深感满意，而哪些只是“差强人意”？ - 哪些软件问题会让你寝食难安，甚至下班后还在琢磨？而哪些问题你又能一笑置之？我认为，品味是一种能够根据当前项目，选择并采纳最契合的工程价值观的能力。为什么品味不同于能力看到上面的指标，你可能会问：这难道不就是技术能力的一部分吗？比如说，代码看起来“好看”，不正是因为它本身就是“好代码”吗？我不这么认为。举个例子。我个人觉得，使用 map 和 filter 的代码要比传统的 for 循环更简洁。我们很容易会认为，这代表了我在工程观点上是绝对正确的。比如，map 和 filter 通常涉及纯函数 (pure functions)，更易于理解和推理，还能避免一类常见的下标错误（off-by-one iterator bugs）。这让我觉得，这并非品味之争，而是我正确、其他工程师错误的问题。但现实当然要复杂得多。像 Golang 这样的语言，出于其设计原则，完全没有内置 map 和 filter。从性能角度看，for 循环的逻辑更容易分析，也更容易扩展到其他迭代策略（比如一次处理两个元素）。我个人对后者的关注度，不如对前者的关注度高——这就是为什么我不常用 for 循环——但如果因此就说偏爱 for 循环的工程师技术能力不行，那就太傲慢了。很多时候，他们拥有的技术能力恰恰是我所不具备的。他们只是在乎的东西不一样。换言之，我们的分歧源于价值观的差异。关于这一点，我曾在《我不知道如何构建软件，你也不知道》一文中探讨过。即使那些重大的技术争论确实存在标准答案，也没有哪个在职的软件工程师敢说自己样样精通，因为一个人的职业生涯所能积累的经验终究有限。我们都在一定程度上依赖于个人经验，依赖于自己那套特定的工程价值观。工程品味的本质是什么软件工程中的几乎每一个决策都是一种权衡 (tradeoff)。你很少会遇到一个选项完全优于另一个选项的情况。更多时候，每个选项都有其利弊。我们常常需要在不同的工程价值观之间做出艰难的取舍：例如，当性能优化到一定程度后，你可能就很难在不牺牲代码可读性的前提下继续提升性能了。在我看来，能否真正理解这一点，是衡量软件工程师成熟度的最大标志。不成熟的工程师在做决策时往往很固执，他们认为做 X 或者 Y 总是更好的。而成熟的工程师则乐于权衡一个决策的利弊，因为他们知道每种选择都有其优缺点。关键不在于判断技术 X 是否优于 Y，而在于在当前这个特定场景下，X 的好处是否大于 Y。换句话说，不成熟的工程师对自己的品味过于执着。他们知道自己喜欢什么，却误将这种喜好当作了放之四海而皆准的工程原则。那么，一个工程师的品味究竟是由什么构成的呢？我认为，你的工程品味，由你认为最重要的那套工程价值观所构成。例如： - 可靠性 (Resiliency) 如果某个基础设施组件（如服务、网络连接）发生故障，系统是否仍能正常运行？能否在无人干预的情况下恢复？ - 速度 (Speed) 软件的运行速度与理论极限相比如何？在关键路径 (hot path) 上是否存在不必要的计算？ - 可读性 (Readability) 代码是否一目了然，便于新工程师上手？函数是否相对简短且命名得当？系统文档是否完善？ - 正确性 (Correctness) 系统是否可能出现无效状态？系统是否通过测试、类型系统和断言进行了严格的约束？测试是否使用了模糊测试 (fuzzing) 等技术？在极端情况下，程序是否通过 Alloy 等形式化方法被证明是正确的？ - 灵活性 (Flexibility) 系统能否毫不费力地扩展？进行一次变更有多容易？如果我需要修改某个功能，需要同时改动多少个不同的地方？ - 可移植性 (Portability) 系统是否被绑定在特定的运行环境上（比如 Windows 或 AWS）？如果需要将系统部署到别处，能否在不投入大量工程工作量的情况下完成？ - 可扩展性 (Scalability) 如果流量增长 10 倍，系统会崩溃吗？100 倍呢？系统是需要过度配置资源，还是可以自动扩展？哪些瓶颈需要工程师介入解决？ - 开发速度 (Development speed) 如果我需要扩展系统，需要多长时间？是大多数工程师都能着手处理，还是需要领域专家的介入？当然，工程价值观还有很多，比如：优雅性、技术的现代性、开源技术的使用、系统运行的经济成本等等。所有这些都很重要，但没有哪个工程师会对所有这些方面给予同等的关注。你的品味，正取决于你将哪些价值观置于最高优先级。例如，如果你看重速度和正确性胜过开发速度，你可能会更喜欢 Rust 而不是 Python。如果你看重可扩展性胜过可移植性，你可能会主张深度利用你所在平台（如 AWS）的特性和工具。如果你看重韧性胜过速度，你可能会希望将流量分散到不同区域。我们还可以将这些价值观进行更细致的拆分。两个都非常关心可读性的工程师，可能会因为一个推崇短函数，另一个推崇短调用栈而产生分歧。两个都关心正确性的工程师，也可能因为一个看重详尽的测试套件，另一个信奉形式化方法而意见不合。但原理是相通的——有太多工程价值观值得我们去追求，而它们之间又常常相互冲突，这就迫使每位工程师必须有所取舍。如何识别“坏品味” 虽然我前面说所有的价值观都很重要，但这并不意味着不存在“坏品味”。在软件工程的语境下，坏品味意味着你所偏爱的价值观与你正在做的项目格格不入。我们大多数人都和这样的工程师共事过。他们加入你的项目后，就开始鼓吹某些东西——形式化方法、用 Golang 重写、Ruby 元编程、跨区域部署等等——因为这些东西在他们过去的项目中效果很好。无论这是否适合你当前的项目，他们都会极力推崇，因为这是他们喜欢的方式。不知不觉中，你发现自己为了让一个内部指标看板达到 99.999% 的可靠性，牺牲了代码的可理解性，导致没有一个初级工程师能看懂。换句话说，大多数坏品味都源于僵化和缺乏变通。我总是对那些以“这是最佳实践”来为自己决策辩护的工程师持保留态度。没有任何工程决策在所有情境下都是“最佳实践”！你必须针对你面临的具体问题，做出正确的决策。这带来一个有趣的结果：品味差的工程师就像一块坏了的罗盘。如果你恰好站在对的位置，坏罗盘依然能指向北方。只有当你开始移动，它才会把你引向歧途。同样，许多品味差的工程师在特定的领域内可能非常高效，因为在那个领域里，他们的个人偏好正好与项目需求相符。但当他们被调到不同的项目或岗位，或者当项目本身的性质发生变化时，问题就立刻暴露出来了。要知道，工作内容很少会一成不变，尤其是在 2021年后这些充满挑战的时代里。如何识别“好品味” 相比技术能力，好品味要难以捉摸得多。因为与技术能力不同，好品味是针对你面临的特定技术问题，选择正确工程价值观组合的能力。因此，判断一个人是否有好品味要困难得多：你无法通过玩具问题 (toy problems) 或技术问答来检验它。你需要一个真实的复杂问题，以及它所附带的各种错综复杂的现实世界背景。如何判断自己是否有好品味？如果你深度参与设计的项目都取得了成功，那么你可能就拥有好品味。如果你只是执行任务（比如完成一个个工单），那么可以这样判断：那些你认同其设计决策的项目取得了成功，而那些你不认同的项目则步履维艰。重要的是，你需要经历不同类型的项目。如果只有一个项目，或者反复做同一种项目，那可能只是说明你恰好适合那个领域。即使你经历过许多不同类型的项目，也不能保证你在不熟悉的领域里同样拥有好品味。那么，如何培养好品味呢？这很难说，但我建议多接触不同类型的项目，密切关注哪些项目（或项目的哪些部分）进展顺利，哪些部分举步维艰。你应该专注于保持灵活性：尽量不要对“什么是写软件的正确方式”形成固执的、普适性的看法。我自己的好品味是慢慢积累起来的。当然，我也不认为你不能快速获得它。我相信编程领域也存在一些天赋异禀、品味超乎其经验的奇才，就像其他领域一样。

#软件工程 #技术品味 #工程价值观 #权衡 #成熟度