GitHub 计费团队如何使用 GitHub Copilot 中的编码代理持续减少技术债务
GitHub Copilot 的编码代理工具为解决技术债务提供了新的思路和方法。技术债务是软件开发中一个长期存在的问题，随着时间推移，快速修复、“临时”解决方案和截止日期妥协会累积成技术债务，就像财务债务一样，拖延越久解决成本越高。优先处理技术债务面临诸多挑战，因为开发团队通常忙于应对紧迫的截止日期和不断涌现的功能需求，技术债务处理工作往往被搁置。
传统的技术债务管理方法，如“园艺周”（专门用于处理技术债务的冲刺阶段）和延长功能开发时间线，效果并不理想。“园艺周”将技术债务视为例外情况而非持续维护的一部分，导致大问题未得到解决，小问题被推迟处理；延长开发时间线则会破坏工程团队与产品团队之间的信任。
GitHub Copilot 的编码代理工具为解决技术债务提供了新的思路。通过将技术债务任务分配给编码代理，开发人员可以在专注于新功能和架构变更的同时，让代理处理技术债务，无需中断正常的开发流程或影响功能交付时间表。例如，编码代理可以增加代码测试覆盖范围、替换依赖项、标准化代码库中的模式、优化前端加载模式以及识别和删除死代码。这些任务都是实际开发中常见的技术债务问题，而编码代理能够高效地完成这些任务，大大减少了处理技术债务所需的时间。
GitHub Copilot 的编码代理工具并非要取代人类工程师，而是增强工程师的能力。代理可以处理重复、耗时的代码重构、更新依赖项和标准化模式等工作，而人类工程师则可以专注于架构决策、功能创新和解决复杂业务问题。这种分工使得软件能够保持更健康的状态，团队能够更快地交付产品，工程师也能将时间花在更有价值的工作上。
尽管 AI 代理在处理定义明确、重复性的任务上表现出色，但在涉及重大架构决策或复杂业务逻辑变更时，人类的判断仍然不可替代。开发人员需要仔细规划和权衡，确保每个提示都经过深思熟虑，每个代码库的变更都经过彻底审查。AI 代理能够带来速度和一致性，而人类工程师则提供战略思维，决定优先处理哪些技术债务，理解不同方法的业务影响，并识别可能引发更大问题的“快速修复”。
为了更好地利用 GitHub Copilot 的编码代理，开发人员可以采取以下建议：为代码库编写清晰的 Copilot 指令，以获得更好的使用体验；将任务分解为可管理的小块，以便更高效地审查变更；掌握有效的提示技巧，明确传达需求、上下文、约束条件和编码标准；始终彻底审查代码，确保质量。这些方法能够帮助开发人员更好地与 AI 代理协作，提高工作效率。
软件工程正处于一个关键时期，技术债务一直是生产力的隐形杀手。AI 编码代理为解决这一问题提供了新的机会。学会与 AI 代理有效协作的工程师将获得巨大优势，他们能够维护复杂的代码库，处理其他人回避的技术债务，甚至可能消除昂贵且耗时的系统重写需求。然而，这一转变需要有意识的努力，开发人员需要尝试这些工具，了解它们的优势和局限性，并将其整合到工作流程中。
#Github #Copilot #AI #实践
https://github.blog/ai-and-ml/github-copilot/how-the-github-billing-team-uses-the-coding-agent-in-github-copilot-to-continuously-burn-down-technical-debt/
GitHub Copilot 的编码代理工具为解决技术债务提供了新的思路和方法。技术债务是软件开发中一个长期存在的问题，随着时间推移，快速修复、“临时”解决方案和截止日期妥协会累积成技术债务，就像财务债务一样，拖延越久解决成本越高。优先处理技术债务面临诸多挑战，因为开发团队通常忙于应对紧迫的截止日期和不断涌现的功能需求，技术债务处理工作往往被搁置。
传统的技术债务管理方法，如“园艺周”（专门用于处理技术债务的冲刺阶段）和延长功能开发时间线，效果并不理想。“园艺周”将技术债务视为例外情况而非持续维护的一部分，导致大问题未得到解决，小问题被推迟处理；延长开发时间线则会破坏工程团队与产品团队之间的信任。
GitHub Copilot 的编码代理工具为解决技术债务提供了新的思路。通过将技术债务任务分配给编码代理，开发人员可以在专注于新功能和架构变更的同时，让代理处理技术债务，无需中断正常的开发流程或影响功能交付时间表。例如，编码代理可以增加代码测试覆盖范围、替换依赖项、标准化代码库中的模式、优化前端加载模式以及识别和删除死代码。这些任务都是实际开发中常见的技术债务问题，而编码代理能够高效地完成这些任务，大大减少了处理技术债务所需的时间。
GitHub Copilot 的编码代理工具并非要取代人类工程师，而是增强工程师的能力。代理可以处理重复、耗时的代码重构、更新依赖项和标准化模式等工作，而人类工程师则可以专注于架构决策、功能创新和解决复杂业务问题。这种分工使得软件能够保持更健康的状态，团队能够更快地交付产品，工程师也能将时间花在更有价值的工作上。
尽管 AI 代理在处理定义明确、重复性的任务上表现出色，但在涉及重大架构决策或复杂业务逻辑变更时，人类的判断仍然不可替代。开发人员需要仔细规划和权衡，确保每个提示都经过深思熟虑，每个代码库的变更都经过彻底审查。AI 代理能够带来速度和一致性，而人类工程师则提供战略思维，决定优先处理哪些技术债务，理解不同方法的业务影响，并识别可能引发更大问题的“快速修复”。
为了更好地利用 GitHub Copilot 的编码代理，开发人员可以采取以下建议：为代码库编写清晰的 Copilot 指令，以获得更好的使用体验；将任务分解为可管理的小块，以便更高效地审查变更；掌握有效的提示技巧，明确传达需求、上下文、约束条件和编码标准；始终彻底审查代码，确保质量。这些方法能够帮助开发人员更好地与 AI 代理协作，提高工作效率。
软件工程正处于一个关键时期，技术债务一直是生产力的隐形杀手。AI 编码代理为解决这一问题提供了新的机会。学会与 AI 代理有效协作的工程师将获得巨大优势，他们能够维护复杂的代码库，处理其他人回避的技术债务，甚至可能消除昂贵且耗时的系统重写需求。然而，这一转变需要有意识的努力，开发人员需要尝试这些工具，了解它们的优势和局限性，并将其整合到工作流程中。
#Github #Copilot #AI #实践
https://github.blog/ai-and-ml/github-copilot/how-the-github-billing-team-uses-the-coding-agent-in-github-copilot-to-continuously-burn-down-technical-debt/
The GitHub Blog
How the GitHub billing team uses the coding agent in GitHub Copilot to continuously burn down technical debt
Tech debt is a big problem that no one has time to solve. GitHub Copilot coding agent can help.
单点登录（SSO）无法保障每一个身份的安全
单点登录（SSO）解决方案旨在管理并保障对 SaaS 应用程序的访问。通过与企业的身份提供商（IdP）集成，SSO 允许团队通过一次登录验证多个应用程序的身份。减少访问点和员工凭据数量，SSO 能够缩小企业的攻击面，并且便于 IT 和安全团队通过 IdP 管理应用程序的访问权限。然而，SSO 并不能保障企业 SaaS 应用程序的所有访问安全。如今的员工随时随地工作，使用自己的 SaaS 和生成式 AI 应用程序，并且与 AI 代理的互动日益频繁。这种自由推动了生产力的飞跃，但也扩大了访问信任差距（Access - Trust Gap）。访问信任差距指的是未经联合的身份、设备、应用程序和 AI 驱动工具在缺乏适当治理控制的情况下访问公司数据所带来的安全风险。
即使采用 SSO 的公司，仍然在与不受信任的访问形式和不断扩大的访问信任差距作斗争。SSO 解决方案在访问管理中仍有一定作用，但仅靠它无法充分应对现代劳文章探讨了影响 SSO 能够保障特定公司用户和身份安全的各种复杂因素，并探索可以补充或替代 SSO 的解决方案，以保障 SSO 未能看到和管理的身份安全。
#SSO #安全
https://blog.1password.com/sso-cant-secure-every-identity/
单点登录（SSO）解决方案旨在管理并保障对 SaaS 应用程序的访问。通过与企业的身份提供商（IdP）集成，SSO 允许团队通过一次登录验证多个应用程序的身份。减少访问点和员工凭据数量，SSO 能够缩小企业的攻击面，并且便于 IT 和安全团队通过 IdP 管理应用程序的访问权限。然而，SSO 并不能保障企业 SaaS 应用程序的所有访问安全。如今的员工随时随地工作，使用自己的 SaaS 和生成式 AI 应用程序，并且与 AI 代理的互动日益频繁。这种自由推动了生产力的飞跃，但也扩大了访问信任差距（Access - Trust Gap）。访问信任差距指的是未经联合的身份、设备、应用程序和 AI 驱动工具在缺乏适当治理控制的情况下访问公司数据所带来的安全风险。
即使采用 SSO 的公司，仍然在与不受信任的访问形式和不断扩大的访问信任差距作斗争。SSO 解决方案在访问管理中仍有一定作用，但仅靠它无法充分应对现代劳文章探讨了影响 SSO 能够保障特定公司用户和身份安全的各种复杂因素，并探索可以补充或替代 SSO 的解决方案，以保障 SSO 未能看到和管理的身份安全。
#SSO #安全
https://blog.1password.com/sso-cant-secure-every-identity/
1Password Blog
SSO can't secure every identity | 1Password Blog
For teams considering adopting SSO or looking to supplement their existing solution, this article explores the various complexities that impact which users and identities SSO can secure for a given company.
掌握 Shopify 性能报告
Dan Gayle 介绍了 Shopify 为平台上所有店铺推出的新网页性能报告功能，该功能为商家提供了前所未有的真实用户指标（RUM）访问权限，帮助识别和修复性能瓶颈。
Shopify 提供了 6 个自定义仪表板，展示了新报告的强大功能，商家可以将其保存并用于自己的店铺。这些仪表板可以通过 Shopify 后台的 “Analytics > Reports” 或 “Online Store > Themes” 页面访问，顶部横幅也可进入，同时提供了全面的文档支持。
高级概述仪表板提供了关键页面类型性能的高级概览，允许商家监控核心指标以评估网站的整体健康状况。建议每天检查一次，如果发现指标不是绿色，则需要使用仪表板 2 进一步深入分析。其 ShopifyQL 查询代码可用于生成报告，显示过去 30 天内不同设备类型和页面类型的加载百分比、LCP、CLS 和 INP 等指标。
如果在高级概述仪表板中发现问题，则需要通过此仪表板深入分析 CWV 分数随时间的变化，以查找可能对性能产生负面影响的变化。报告会显示过去 30 天内不同页面类型和设备类型的 LCP、CLS 和 INP 指标，并以时间序列的形式呈现。通过悬停在图表上，可以查看特定时间点的详细信息。此外，事件注释功能会在添加新应用或更新主题时在图表上添加注释，如果注释与图表中的大幅变化相对应，则很可能是引入了导致问题的因素。
LCP 指标与页面上的某个元素（目标）相关，通常是页面上最大的图像，但也可能包括大文本区域和 cookie 同意弹窗。新性能仪表板可以显示目标元素，这为识别潜在问题提供了新的强大功能。该仪表板会生成一个表格，列出需要改进的 LCP 元素的 CSS 选择器（LCP > 2.5s），并按页面类型、设备类型和页面视图百分比排序。通过识别这些元素，商家可以进一步分析如何更快地加载它们，问题可能出在前端（如延迟加载主图像、客户端渲染等）或后端（如服务器响应时间慢，即 TTFB）。
在诊断慢速 LCP 分数时，了解问题是由于服务器响应慢（TTFB）、渲染阻塞资源（FCP）还是 LCP 目标是延迟加载的资产，是非常有帮助的。该仪表板可以将这些因素分解，以便更清晰地看到问题所在。报告会显示过去 30 天内不同页面类型和设备类型的 TTFB、FCP 和 LCP 指标，并以时间序列的形式呈现。通过切换顶部右侧的指标，可以查看每个指标的性能表现。例如，如果 TTFB 比较平稳，但 FCP 在 6 月 2 日左右出现大幅上升，且注释显示主题更新了 192 次，则可能是有人在编辑主题时引入了渲染阻塞脚本或其他阻止屏幕渲染的内容。
CLS 测量页面上意外移动的量，通过测量元素移动的距离来实现。目标选择器只能帮助识别被移动的项目，而不是导致移动的元素。不过，一旦知道哪个项目发生了移动，通常可以轻松地找出相邻的有问题元素（通常是其上方的元素）。该仪表板会生成一个表格，列出过去 30 天内 CLS 值大于 0.1 的页面类型、设备类型和目标选择器，并按页面视图百分比排序。商家可以在浏览器中查看可能导致移动的原因，例如通过在 Chrome DevTools 中限制连接速度来减慢页面加载速度，从而更容易识别问题部分。
INP 测量浏览器对点击的视觉响应时间，因此 INP 目标是被点击项的 CSS 选择器。一旦知道了这一点，就更容易识别导致响应缓慢的 JavaScript 代码。该仪表板会生成一个表格，列出过去 30 天内 INP 值大于 200 毫秒的页面类型、设备类型和目标选择器，并按页面视图百分比排序。尽管有了点击目标，但查找和修复 INP 问题仍然是一个具有挑战性的任务。Google 在 web.dev 上的文档非常有用，Shopify 的网络性能团队也会参考这些文档。
#性能
https://performance.shopify.com/blogs/blog/mastering-web-performance-reports
Dan Gayle 介绍了 Shopify 为平台上所有店铺推出的新网页性能报告功能，该功能为商家提供了前所未有的真实用户指标（RUM）访问权限，帮助识别和修复性能瓶颈。
Shopify 提供了 6 个自定义仪表板，展示了新报告的强大功能，商家可以将其保存并用于自己的店铺。这些仪表板可以通过 Shopify 后台的 “Analytics > Reports” 或 “Online Store > Themes” 页面访问，顶部横幅也可进入，同时提供了全面的文档支持。
高级概述仪表板提供了关键页面类型性能的高级概览，允许商家监控核心指标以评估网站的整体健康状况。建议每天检查一次，如果发现指标不是绿色，则需要使用仪表板 2 进一步深入分析。其 ShopifyQL 查询代码可用于生成报告，显示过去 30 天内不同设备类型和页面类型的加载百分比、LCP、CLS 和 INP 等指标。
如果在高级概述仪表板中发现问题，则需要通过此仪表板深入分析 CWV 分数随时间的变化，以查找可能对性能产生负面影响的变化。报告会显示过去 30 天内不同页面类型和设备类型的 LCP、CLS 和 INP 指标，并以时间序列的形式呈现。通过悬停在图表上，可以查看特定时间点的详细信息。此外，事件注释功能会在添加新应用或更新主题时在图表上添加注释，如果注释与图表中的大幅变化相对应，则很可能是引入了导致问题的因素。
LCP 指标与页面上的某个元素（目标）相关，通常是页面上最大的图像，但也可能包括大文本区域和 cookie 同意弹窗。新性能仪表板可以显示目标元素，这为识别潜在问题提供了新的强大功能。该仪表板会生成一个表格，列出需要改进的 LCP 元素的 CSS 选择器（LCP > 2.5s），并按页面类型、设备类型和页面视图百分比排序。通过识别这些元素，商家可以进一步分析如何更快地加载它们，问题可能出在前端（如延迟加载主图像、客户端渲染等）或后端（如服务器响应时间慢，即 TTFB）。
在诊断慢速 LCP 分数时，了解问题是由于服务器响应慢（TTFB）、渲染阻塞资源（FCP）还是 LCP 目标是延迟加载的资产，是非常有帮助的。该仪表板可以将这些因素分解，以便更清晰地看到问题所在。报告会显示过去 30 天内不同页面类型和设备类型的 TTFB、FCP 和 LCP 指标，并以时间序列的形式呈现。通过切换顶部右侧的指标，可以查看每个指标的性能表现。例如，如果 TTFB 比较平稳，但 FCP 在 6 月 2 日左右出现大幅上升，且注释显示主题更新了 192 次，则可能是有人在编辑主题时引入了渲染阻塞脚本或其他阻止屏幕渲染的内容。
CLS 测量页面上意外移动的量，通过测量元素移动的距离来实现。目标选择器只能帮助识别被移动的项目，而不是导致移动的元素。不过，一旦知道哪个项目发生了移动，通常可以轻松地找出相邻的有问题元素（通常是其上方的元素）。该仪表板会生成一个表格，列出过去 30 天内 CLS 值大于 0.1 的页面类型、设备类型和目标选择器，并按页面视图百分比排序。商家可以在浏览器中查看可能导致移动的原因，例如通过在 Chrome DevTools 中限制连接速度来减慢页面加载速度，从而更容易识别问题部分。
INP 测量浏览器对点击的视觉响应时间，因此 INP 目标是被点击项的 CSS 选择器。一旦知道了这一点，就更容易识别导致响应缓慢的 JavaScript 代码。该仪表板会生成一个表格，列出过去 30 天内 INP 值大于 200 毫秒的页面类型、设备类型和目标选择器，并按页面视图百分比排序。尽管有了点击目标，但查找和修复 INP 问题仍然是一个具有挑战性的任务。Google 在 web.dev 上的文档非常有用，Shopify 的网络性能团队也会参考这些文档。
#性能
https://performance.shopify.com/blogs/blog/mastering-web-performance-reports
Performance @ Shopify
Mastering Shopify’s Performance Reports
We help you get the most value out of Shopify's newly released web performance reports by showing you how they can help monitor and improve your most important metrics.
从 Skeuomorphic 到 Liquid Glass：苹果对 "后触控时代 "的战略押注
在 2025 年全球的开发者大会（WWDC）上，苹果公司推出了 Liquid Glass（液态玻璃）界面设计，这不仅仅是一次视觉上的更新，更是苹果对未来十年人机交互方式的战略性布局。苹果通过 Liquid Glass 为用户营造一种屏幕不再重要的未来世界，其灵感来源于 visionOS，即苹果的增强现实操作系统。在增强现实中，界面元素需要与物理世界共存，因此必须是半透明、分层且具有环境感知能力的。苹果通过在传统屏幕上率先引入这些概念，让用户在使用 AR 眼镜时，界面式范不会显得陌生。
此次设计转变还充分发挥了苹果垂直整合的核心战略优势。Liquid Glass 不仅是视觉上的装饰，更是硬件与软件紧密耦合的技术展示。实时模糊、动态透明效果和上下文感知照明等功能需要强大的 GPU 性能和优化的渲染管线才能实现。这种设计使得苹果设备在运行 Liquid Glass 时能够流畅运行，而竞争对手的设备可能会出现卡顿。这种设计语言的统一性也贯穿于苹果的所有平台，从 Apple TV 到 Vision Pro，开发者可以在整个生态系统中实现一致的视觉语言，用户在切换设备时也能保持认知上的连贯性。
尽管科技媒体对苹果在 WWDC 2025 上相对低调的人工智能故事大加关注，但苹果实际上正在采取一种更为微妙的策略。苹果没有参与当前大语言模型的竞争，而是专注于其擅长的领域：通过设计和整合创造引人入胜的用户体验。苹果的历史表明，他们很少是第一个进入市场的公司，但往往是第一个以精致、整合的方式进入市场的公司。苹果在人工智能领域似乎也在采取类似的策略，通过 Liquid Glass 设计语言为更具情境化的人工智能互动创造了机会。
然而，任何设计决策都涉及权衡。Liquid Glass 早期的反馈引发了关于可读性和认知负荷的合理担忧。半透明界面可能会降低对比度，使文本更难阅读。不过，苹果过去曾成功应对过这些挑战，并且已经在之前的 iOS 版本中提供了诸如“降低透明度”和“提高对比度”等设置。苹果有能力从大胆的愿景出发，并根据反馈进行调整，尤其是当这一愿景服务于更大的战略目标时。
Liquid Glass 的推出还创造了设计语言上的网络效应。当苹果改变方向时，它不仅影响苹果自身，还会影响整个行业。为 iOS 开发的应用程序开发者将采用新的设计模式，其他公司的设计师也会创造类似的美学风格以保持与时俱进。这种行业影响力进一步增强了苹果的战略优势，即使非苹果设备的用户也会接触到受苹果影响的设计模式，使得未来转向苹果产品时感觉更加自然。
苹果引入 Liquid Glass 揭示了其对未来计算的看法：我们正朝着融合数字与物理现实的环境化、空间化界面发展。触摸仍将很重要，但它不会永远是主要的交互模式。语音、手势和情境感知将发挥更大的作用。通过现在建立视觉和概念框架，苹果正在为用户和开发者准备这一转变。当轻量级 AR 眼镜最终成为主流时，界面范式将已经变得熟悉。
从历史来看，苹果的设计变革总是会面临初步的抵制。问题不在于 Liquid Glass 是否会在审美上取得成功，而在于苹果是否能够执行它所代表的更广泛愿景：从以触摸为主向以空间为主计算的无缝过渡，并以苹果的整合生态系统为中心。如果以历史为鉴，未来五年内我们可能都会使用类似玻璃的界面，甚至难以想象没有它们的生活会是什么样子。
#用户体验 #设计 #Apple
https://omc345.substack.com/p/from-skeuomorphic-to-liquid-glass
在 2025 年全球的开发者大会（WWDC）上，苹果公司推出了 Liquid Glass（液态玻璃）界面设计，这不仅仅是一次视觉上的更新，更是苹果对未来十年人机交互方式的战略性布局。苹果通过 Liquid Glass 为用户营造一种屏幕不再重要的未来世界，其灵感来源于 visionOS，即苹果的增强现实操作系统。在增强现实中，界面元素需要与物理世界共存，因此必须是半透明、分层且具有环境感知能力的。苹果通过在传统屏幕上率先引入这些概念，让用户在使用 AR 眼镜时，界面式范不会显得陌生。
此次设计转变还充分发挥了苹果垂直整合的核心战略优势。Liquid Glass 不仅是视觉上的装饰，更是硬件与软件紧密耦合的技术展示。实时模糊、动态透明效果和上下文感知照明等功能需要强大的 GPU 性能和优化的渲染管线才能实现。这种设计使得苹果设备在运行 Liquid Glass 时能够流畅运行，而竞争对手的设备可能会出现卡顿。这种设计语言的统一性也贯穿于苹果的所有平台，从 Apple TV 到 Vision Pro，开发者可以在整个生态系统中实现一致的视觉语言，用户在切换设备时也能保持认知上的连贯性。
尽管科技媒体对苹果在 WWDC 2025 上相对低调的人工智能故事大加关注，但苹果实际上正在采取一种更为微妙的策略。苹果没有参与当前大语言模型的竞争，而是专注于其擅长的领域：通过设计和整合创造引人入胜的用户体验。苹果的历史表明，他们很少是第一个进入市场的公司，但往往是第一个以精致、整合的方式进入市场的公司。苹果在人工智能领域似乎也在采取类似的策略，通过 Liquid Glass 设计语言为更具情境化的人工智能互动创造了机会。
然而，任何设计决策都涉及权衡。Liquid Glass 早期的反馈引发了关于可读性和认知负荷的合理担忧。半透明界面可能会降低对比度，使文本更难阅读。不过，苹果过去曾成功应对过这些挑战，并且已经在之前的 iOS 版本中提供了诸如“降低透明度”和“提高对比度”等设置。苹果有能力从大胆的愿景出发，并根据反馈进行调整，尤其是当这一愿景服务于更大的战略目标时。
Liquid Glass 的推出还创造了设计语言上的网络效应。当苹果改变方向时，它不仅影响苹果自身，还会影响整个行业。为 iOS 开发的应用程序开发者将采用新的设计模式，其他公司的设计师也会创造类似的美学风格以保持与时俱进。这种行业影响力进一步增强了苹果的战略优势，即使非苹果设备的用户也会接触到受苹果影响的设计模式，使得未来转向苹果产品时感觉更加自然。
苹果引入 Liquid Glass 揭示了其对未来计算的看法：我们正朝着融合数字与物理现实的环境化、空间化界面发展。触摸仍将很重要，但它不会永远是主要的交互模式。语音、手势和情境感知将发挥更大的作用。通过现在建立视觉和概念框架，苹果正在为用户和开发者准备这一转变。当轻量级 AR 眼镜最终成为主流时，界面范式将已经变得熟悉。
从历史来看，苹果的设计变革总是会面临初步的抵制。问题不在于 Liquid Glass 是否会在审美上取得成功，而在于苹果是否能够执行它所代表的更广泛愿景：从以触摸为主向以空间为主计算的无缝过渡，并以苹果的整合生态系统为中心。如果以历史为鉴，未来五年内我们可能都会使用类似玻璃的界面，甚至难以想象没有它们的生活会是什么样子。
#用户体验 #设计 #Apple
https://omc345.substack.com/p/from-skeuomorphic-to-liquid-glass
Substack
From Skeuomorphic to Liquid Glass: Apple's Strategic Bet on the Post-Touch Future
Why Apple Just Killed the iPhone Interface (And What Comes Next)
不要盲目构建多智能体
Walden 探讨了在构建基于大型语言模型（LLM）的智能体时，多智能体架构存在的问题，并提出了一些构建智能体的原则。
目前构建智能体的框架令人失望，而 Walden 希望通过分享自己团队在实践中积累的经验，帮助读者避免一些常见的错误。React 框架之所以成功，是因为它不仅仅是一个代码编写工具，更是一种开发哲学。在当前的 LLM 时代，构建智能体更像是在摸索如何将不同的技术组合在一起，以提供良好的用户体验。目前还没有一种标准的智能体构建方法，而一些像 OpenAI 的 Swarm 和微软的 AutoGen 这样的库，推动了多智能体架构的概念，但 Walden 认为这是错误的方向。
Walden 提出了构建长运行智能体的理论，强调可靠性是核心，而上下文工程是实现可靠性的关键。上下文工程不仅仅是将任务以理想格式写出来，而是要在动态系统中自动完成这一过程。Walden 以构建 Flappy Bird 克隆版为例，说明了多智能体架构的脆弱性。当任务被分解为多个子任务并分配给不同的子智能体时，很容易出现误解和不一致的情况。因此，Walden 提出了两个原则：原则 1 是共享上下文，不仅要共享单独的消息，还要共享完整的智能体轨迹；原则 2 是行动隐含着决策，而冲突的决策会导致不良结果。Walden 认为，这两个原则至关重要，应该默认排除不符合这些原则的智能体架构。
Walden 还讨论了如何应用这些原则。如果是一个智能体构建者，需要确保智能体的每个行动都受到系统中其他部分所做决策的上下文的指导。虽然理想情况下每个行动都能看到其他所有内容，但由于上下文窗口有限和实际的权衡，可能需要决定愿意承担多大的复杂性以实现所需的可靠性。Walden 还提到了一些现实世界中的例子，如 Claude Code 的子智能体和编辑应用模型，说明了在构建智能体时如何避免冲突决策。
尽管多智能体架构在理论上可以提高系统的并行性和效率，但在 2025 年，多智能体协作的系统仍然非常脆弱。决策过于分散，上下文无法在智能体之间充分共享。Walden 认为，随着单线程智能体与人类沟通能力的提高，跨智能体上下文传递问题可能会得到解决。
#AI #Agents #思考
https://cognition.ai/blog/dont-build-multi-agents#principles-of-context-engineering
Walden 探讨了在构建基于大型语言模型（LLM）的智能体时，多智能体架构存在的问题，并提出了一些构建智能体的原则。
目前构建智能体的框架令人失望，而 Walden 希望通过分享自己团队在实践中积累的经验，帮助读者避免一些常见的错误。React 框架之所以成功，是因为它不仅仅是一个代码编写工具，更是一种开发哲学。在当前的 LLM 时代，构建智能体更像是在摸索如何将不同的技术组合在一起，以提供良好的用户体验。目前还没有一种标准的智能体构建方法，而一些像 OpenAI 的 Swarm 和微软的 AutoGen 这样的库，推动了多智能体架构的概念，但 Walden 认为这是错误的方向。
Walden 提出了构建长运行智能体的理论，强调可靠性是核心，而上下文工程是实现可靠性的关键。上下文工程不仅仅是将任务以理想格式写出来，而是要在动态系统中自动完成这一过程。Walden 以构建 Flappy Bird 克隆版为例，说明了多智能体架构的脆弱性。当任务被分解为多个子任务并分配给不同的子智能体时，很容易出现误解和不一致的情况。因此，Walden 提出了两个原则：原则 1 是共享上下文，不仅要共享单独的消息，还要共享完整的智能体轨迹；原则 2 是行动隐含着决策，而冲突的决策会导致不良结果。Walden 认为，这两个原则至关重要，应该默认排除不符合这些原则的智能体架构。
Walden 还讨论了如何应用这些原则。如果是一个智能体构建者，需要确保智能体的每个行动都受到系统中其他部分所做决策的上下文的指导。虽然理想情况下每个行动都能看到其他所有内容，但由于上下文窗口有限和实际的权衡，可能需要决定愿意承担多大的复杂性以实现所需的可靠性。Walden 还提到了一些现实世界中的例子，如 Claude Code 的子智能体和编辑应用模型，说明了在构建智能体时如何避免冲突决策。
尽管多智能体架构在理论上可以提高系统的并行性和效率，但在 2025 年，多智能体协作的系统仍然非常脆弱。决策过于分散，上下文无法在智能体之间充分共享。Walden 认为，随着单线程智能体与人类沟通能力的提高，跨智能体上下文传递问题可能会得到解决。
#AI #Agents #思考
https://cognition.ai/blog/dont-build-multi-agents#principles-of-context-engineering
Cognition
Cognition | Don’t Build Multi-Agents
Frameworks for LLM Agents have been surprisingly disappointing. I want to offer some principles for building agents based on our own trial & error, and explain why some tempting ideas are actually quite bad in practice.
温柔的奇点
Sam Altman 探讨了人工智能与人类社会的未来发展。他认为人类已经跨越了奇点的事件视界，人工智能的起飞已经开始。尽管目前我们尚未看到机器人在街头行走，人类也仍面临疾病和太空探索的难题，但人工智能已经在许多方面展现出超越人类的智能，并能够显著提升人类的工作效率。以 GPT-4 为代表的系统是来之不易的科学成果，未来将带来深远的影响。
人工智能将通过加速科学进步和提高生产力为世界带来巨大收益。科学进步是整体进步的最大驱动力，而人工智能在推动科学发现和创新方面具有巨大潜力。例如，ChatGPT 已经被数亿人每天用于各种重要任务，其影响力巨大。2025 年出现了能够进行真正认知工作的智能代理，这将彻底改变编程等工作。预计 2026 年将出现能够提出新见解的系统，2027 年可能会出现能够在现实世界中执行任务的机器人。
到 2030 年，人们将能够更高效地完成更多工作，这将是一个显著的变化。尽管如此，人们的生活在最重要的方面可能不会发生巨大变化，人们仍将热爱家人、表达创造力、玩游戏和享受自然。然而，在其他非常重要的方面，2030 年代将与以往大不相同。人类将拥有丰富的智力和能源，这两个因素一直是人类进步的限制因素，而有了它们，人类将能够实现更多目标。
人工智能的发展将使数据处理和智能服务的成本逐渐降低，接近电力成本。随着数据中心生产的自动化，智能成本将进一步降低。技术进步的速度将继续加快，人类将有能力适应这些变化。尽管一些工作岗位可能会消失，但世界将变得更加富有，从而能够探索新的政策理念。
Sam Altman 强调，人类需要解决人工智能的安全问题，确保其与人类的长期目标一致。同时，超级智能应该便宜、广泛可用且不被少数人、公司或国家垄断。社会需要通过集体智慧来适应和利用这项技术，以实现最大利益和最小风险。OpenAI 是一家超级智能研究公司，其目标是为世界打造一个高度个性化且易于使用的智能系统。未来，人工智能将变得如此便宜，以至于人们几乎可以免费使用。尽管这听起来有些疯狂，但如果回顾 2020 年人们对 2025 年的预测，如今的成就可能更令人难以置信。
#AI #OpenAI #思考
https://blog.samaltman.com/the-gentle-singularity
Sam Altman 探讨了人工智能与人类社会的未来发展。他认为人类已经跨越了奇点的事件视界，人工智能的起飞已经开始。尽管目前我们尚未看到机器人在街头行走，人类也仍面临疾病和太空探索的难题，但人工智能已经在许多方面展现出超越人类的智能，并能够显著提升人类的工作效率。以 GPT-4 为代表的系统是来之不易的科学成果，未来将带来深远的影响。
人工智能将通过加速科学进步和提高生产力为世界带来巨大收益。科学进步是整体进步的最大驱动力，而人工智能在推动科学发现和创新方面具有巨大潜力。例如，ChatGPT 已经被数亿人每天用于各种重要任务，其影响力巨大。2025 年出现了能够进行真正认知工作的智能代理，这将彻底改变编程等工作。预计 2026 年将出现能够提出新见解的系统，2027 年可能会出现能够在现实世界中执行任务的机器人。
到 2030 年，人们将能够更高效地完成更多工作，这将是一个显著的变化。尽管如此，人们的生活在最重要的方面可能不会发生巨大变化，人们仍将热爱家人、表达创造力、玩游戏和享受自然。然而，在其他非常重要的方面，2030 年代将与以往大不相同。人类将拥有丰富的智力和能源，这两个因素一直是人类进步的限制因素，而有了它们，人类将能够实现更多目标。
人工智能的发展将使数据处理和智能服务的成本逐渐降低，接近电力成本。随着数据中心生产的自动化，智能成本将进一步降低。技术进步的速度将继续加快，人类将有能力适应这些变化。尽管一些工作岗位可能会消失，但世界将变得更加富有，从而能够探索新的政策理念。
Sam Altman 强调，人类需要解决人工智能的安全问题，确保其与人类的长期目标一致。同时，超级智能应该便宜、广泛可用且不被少数人、公司或国家垄断。社会需要通过集体智慧来适应和利用这项技术，以实现最大利益和最小风险。OpenAI 是一家超级智能研究公司，其目标是为世界打造一个高度个性化且易于使用的智能系统。未来，人工智能将变得如此便宜，以至于人们几乎可以免费使用。尽管这听起来有些疯狂，但如果回顾 2020 年人们对 2025 年的预测，如今的成就可能更令人难以置信。
#AI #OpenAI #思考
https://blog.samaltman.com/the-gentle-singularity
Sam Altman
The Gentle Singularity
We are past the event horizon; the takeoff has started. Humanity is close to building digital superintelligence, and at least so far it’s much less weird than it seems like it should be.
Robots...
Robots...
AI 在用户界面中的最佳位置在哪里？
随着大型语言模型（LLMs）和人工智能代理的兴起，熟悉的用户界面模式如聊天机器人得到了升级，但新的界面布局正在逐渐形成。真正的机会在于将人工智能更深入地嵌入复杂、面向任务的界面中。从右侧面板助手、无限画布到语义电子表格，这些空间选择不仅仅是设计决策，它们从根本上塑造了用户发现、信任和与人工智能互动的方式。
Sharang 探讨了七种新兴的用户界面布局以及人工智能代理的感知角色，分析了每种布局如何通过可发现性、用户互动模式和代理能力影响用户行为和期望。
第一种是客户支持聊天机器人，通常位于页面右下角，易于发现且不具侵入性，适用于轻量级、非侵入性的支持场景。现代人工智能聊天机器人能够保持上下文记忆、个性化响应，并自动化后端操作，但不适合主动式、多步骤推理或创造性协作工作流。
第二种是内联覆盖提示，例如在 Notion 和 Grammarly AI 中，这些提示作为交互式、上下文敏感的建议或操作，直接出现在文本或内容区域中，增强用户生产力和编辑效率。内联提示通过用户操作触发，用户可以即时与建议互动，接受、编辑、撤销或重新生成内容。这种代理被视为“精准助手”，提供微观层面的支持，但不适用于开放式创造性探索或需要广泛上下文推理的任务。
第三种是无限画布上的创意合作者，无限画布工具为用户提供了几乎无限的二维工作空间，支持视觉思维和探索性工作流。AI 能力通过上下文触发，用户可以在不打断创意流程的情况下，通过局部、异步的提示输入调用模型。AI 在这里充当“创意合作者”，响应空间上下文，支持创意生成、内容优化、布局建议和视觉增强，但不适合需要严格版本控制或全局上下文感知的场景。
第四种是中心舞台的通用助手，这种界面模型将 AI 置于用户体验的中心，通常是一个全宽、垂直堆叠的面板，以文本输入和对话线程为核心。它支持开放式、自由形式的交互风格，用户通过自然语言发起互动，通过后续问题、澄清或提示工程迭代优化输出。AI 被视为“通用助手”，能够跨多个领域回答问题、生成内容和执行任务，但不适合结构化、多步骤的工作流。
第五种是左侧面板的战略创意伙伴，AI 助手放置在左侧面板中，作为生成内容、代码或结构化输出的协作引擎。这种布局支持多轮次的共同创作，用户可以在持续的反馈循环中提示、细化和测试输出。AI 被视为“战略伙伴或共同创作者”，通过来回互动帮助用户构思、结构化和演变复杂输出，但不适合轻量级任务或移动界面，且模糊的提示可能导致意外行为。
第六种是右侧面板的深度上下文专家，AI 位于可折叠的右侧面板中，作为按需助手，为沉浸于复杂主要任务的用户提供支持。这种布局允许用户专注于中央画布，同时保持助手的易于发现性和非侵入性。AI 被视为“深度上下文专家”，能够提供针对性、推理驱动的支持，但不适合以 AI 为中心的体验，其微妙的存在可能被新手用户忽视。
第七种是网格界面中的分布式研究代理，传统的电子表格网格正在转变为智能表面，用于查询、研究和语义互动。AI 输入通常从顶部提示或查询字段开始，然后单元格自动填充结构化结果。AI 在这里被描述为“分布式研究代理”，每个单元格都像一个智能代理，共同构成一个智能整体，但这些系统最适合研究、分析或结构化内容编译，需要用户对期望输出的结构有清晰的认识。
LLMs 不仅仅是被查询的工具，而是一种新的计算媒介，我们才刚刚开始理解它。正如过去几十年图形用户界面、网络和移动界面重塑了设计一样，LLMs 要求我们重新思考智能在产品中的存在方式，不仅仅是它说什么，还包括它在哪里、如何被触发以及如何引导用户。空间布局如聊天机器人、侧边栏、语义网格和无限画布不仅仅是审美选择，它们定义了用户对 AI 角色的心理模型，其位置塑造了可用性、能力和信任。在这个新时代，设计 AI 的呈现方式将与设计其功能一样重要。
#AI #用户体验
https://uxdesign.cc/where-should-ai-sit-in-your-ui-1710a258390e
随着大型语言模型（LLMs）和人工智能代理的兴起，熟悉的用户界面模式如聊天机器人得到了升级，但新的界面布局正在逐渐形成。真正的机会在于将人工智能更深入地嵌入复杂、面向任务的界面中。从右侧面板助手、无限画布到语义电子表格，这些空间选择不仅仅是设计决策，它们从根本上塑造了用户发现、信任和与人工智能互动的方式。
Sharang 探讨了七种新兴的用户界面布局以及人工智能代理的感知角色，分析了每种布局如何通过可发现性、用户互动模式和代理能力影响用户行为和期望。
第一种是客户支持聊天机器人，通常位于页面右下角，易于发现且不具侵入性，适用于轻量级、非侵入性的支持场景。现代人工智能聊天机器人能够保持上下文记忆、个性化响应，并自动化后端操作，但不适合主动式、多步骤推理或创造性协作工作流。
第二种是内联覆盖提示，例如在 Notion 和 Grammarly AI 中，这些提示作为交互式、上下文敏感的建议或操作，直接出现在文本或内容区域中，增强用户生产力和编辑效率。内联提示通过用户操作触发，用户可以即时与建议互动，接受、编辑、撤销或重新生成内容。这种代理被视为“精准助手”，提供微观层面的支持，但不适用于开放式创造性探索或需要广泛上下文推理的任务。
第三种是无限画布上的创意合作者，无限画布工具为用户提供了几乎无限的二维工作空间，支持视觉思维和探索性工作流。AI 能力通过上下文触发，用户可以在不打断创意流程的情况下，通过局部、异步的提示输入调用模型。AI 在这里充当“创意合作者”，响应空间上下文，支持创意生成、内容优化、布局建议和视觉增强，但不适合需要严格版本控制或全局上下文感知的场景。
第四种是中心舞台的通用助手，这种界面模型将 AI 置于用户体验的中心，通常是一个全宽、垂直堆叠的面板，以文本输入和对话线程为核心。它支持开放式、自由形式的交互风格，用户通过自然语言发起互动，通过后续问题、澄清或提示工程迭代优化输出。AI 被视为“通用助手”，能够跨多个领域回答问题、生成内容和执行任务，但不适合结构化、多步骤的工作流。
第五种是左侧面板的战略创意伙伴，AI 助手放置在左侧面板中，作为生成内容、代码或结构化输出的协作引擎。这种布局支持多轮次的共同创作，用户可以在持续的反馈循环中提示、细化和测试输出。AI 被视为“战略伙伴或共同创作者”，通过来回互动帮助用户构思、结构化和演变复杂输出，但不适合轻量级任务或移动界面，且模糊的提示可能导致意外行为。
第六种是右侧面板的深度上下文专家，AI 位于可折叠的右侧面板中，作为按需助手，为沉浸于复杂主要任务的用户提供支持。这种布局允许用户专注于中央画布，同时保持助手的易于发现性和非侵入性。AI 被视为“深度上下文专家”，能够提供针对性、推理驱动的支持，但不适合以 AI 为中心的体验，其微妙的存在可能被新手用户忽视。
第七种是网格界面中的分布式研究代理，传统的电子表格网格正在转变为智能表面，用于查询、研究和语义互动。AI 输入通常从顶部提示或查询字段开始，然后单元格自动填充结构化结果。AI 在这里被描述为“分布式研究代理”，每个单元格都像一个智能代理，共同构成一个智能整体，但这些系统最适合研究、分析或结构化内容编译，需要用户对期望输出的结构有清晰的认识。
LLMs 不仅仅是被查询的工具，而是一种新的计算媒介，我们才刚刚开始理解它。正如过去几十年图形用户界面、网络和移动界面重塑了设计一样，LLMs 要求我们重新思考智能在产品中的存在方式，不仅仅是它说什么，还包括它在哪里、如何被触发以及如何引导用户。空间布局如聊天机器人、侧边栏、语义网格和无限画布不仅仅是审美选择，它们定义了用户对 AI 角色的心理模型，其位置塑造了可用性、能力和信任。在这个新时代，设计 AI 的呈现方式将与设计其功能一样重要。
#AI #用户体验
https://uxdesign.cc/where-should-ai-sit-in-your-ui-1710a258390e
Medium
Where should AI sit in your UI?
Mapping emerging AI UI patterns and how spatial UI choices shape AI experiences
猛吸一口 AGI 与 Claude Code
Kade 探讨了 Claude Code 的多种创新使用方式，这些内容并非简单的入门介绍，而是更具实验性和探索性。Kade 提到使用 Claude Max 的成本较高，每月需 250 美元，但其功能强大，能够为团队带来新的可能性。
Kade 首先介绍了如何利用 Claude Code 结合 Marp 工具自动生成代码库的介绍性幻灯片。通过让 Claude Code 遍历代码库并生成文档，再将其转换为 Marp 格式的幻灯片文件，最终生成 HTML 文件，团队成员可以通过运行简单的命令快速获取代码库的动态更新概览。这种方法对于新成员的入职和代码库的理解非常有帮助。
然而，这种方法在处理大型代码库时可能会面临性能问题，因为 Claude Code 需要消耗大量上下文信息。Kade 建议可以通过并行化处理每个目录来解决这一问题。此外，Kade 还展示了如何通过脚本化操作让 Claude Code 自动分析代码库的变更情况，并通过语音合成工具读取报告，为团队成员提供每周的代码变更总结。
Kade 尝试将 OpenAI 的 Codex 作为子代理使用，通过修改配置文件让 Claude Code 调用 Codex 来完成任务。这种方法虽然有些“黑客”风格，但展示了不同模型之间协作的潜力。Kade 认为，未来可能会出现由多个不同实验室的子代理组成的团队，它们可以协同工作，提高任务处理效率。
Kade 指出 Claude Code 的潜力尚未完全释放，随着新 Python SDK 的发布，可能会出现更多奇特的用例。尽管目前这种方法可能在成本上并不划算，但从团队协作和任务分配的角度来看，它具有很大的吸引力。
#AI #Claude
https://kadekillary.work/blog/#2025-06-16-snorting-the-agi-with-claude-code
Kade 探讨了 Claude Code 的多种创新使用方式，这些内容并非简单的入门介绍，而是更具实验性和探索性。Kade 提到使用 Claude Max 的成本较高，每月需 250 美元，但其功能强大，能够为团队带来新的可能性。
Kade 首先介绍了如何利用 Claude Code 结合 Marp 工具自动生成代码库的介绍性幻灯片。通过让 Claude Code 遍历代码库并生成文档，再将其转换为 Marp 格式的幻灯片文件，最终生成 HTML 文件，团队成员可以通过运行简单的命令快速获取代码库的动态更新概览。这种方法对于新成员的入职和代码库的理解非常有帮助。
然而，这种方法在处理大型代码库时可能会面临性能问题，因为 Claude Code 需要消耗大量上下文信息。Kade 建议可以通过并行化处理每个目录来解决这一问题。此外，Kade 还展示了如何通过脚本化操作让 Claude Code 自动分析代码库的变更情况，并通过语音合成工具读取报告，为团队成员提供每周的代码变更总结。
Kade 尝试将 OpenAI 的 Codex 作为子代理使用，通过修改配置文件让 Claude Code 调用 Codex 来完成任务。这种方法虽然有些“黑客”风格，但展示了不同模型之间协作的潜力。Kade 认为，未来可能会出现由多个不同实验室的子代理组成的团队，它们可以协同工作，提高任务处理效率。
Kade 指出 Claude Code 的潜力尚未完全释放，随着新 Python SDK 的发布，可能会出现更多奇特的用例。尽管目前这种方法可能在成本上并不划算，但从团队协作和任务分配的角度来看，它具有很大的吸引力。
#AI #Claude
https://kadekillary.work/blog/#2025-06-16-snorting-the-agi-with-claude-code
kadekillary.work
blog - kade@localhost:~$
blog - kade killary
Marp CLI 是由 Marp 团队开发的一个命令行界面工具，用于将 Marp 或 Marpit Markdown 文件转换为静态 HTML/CSS、PDF、PowerPoint 文档以及图像等多种格式。它基于 Marp Core 和 Marpit 框架构建，支持多种转换选项和功能。
#Tools
https://github.com/marp-team/marp-cli?tab=readme-ov-file
#Tools
https://github.com/marp-team/marp-cli?tab=readme-ov-file
GitHub
GitHub - marp-team/marp-cli: A CLI interface for Marp and Marpit based converters
A CLI interface for Marp and Marpit based converters - marp-team/marp-cli
90 年代网页设计的三位大师：塞尔德曼、西格尔和尼尔森
在 1997 年，随着 Flash 和 CSS 的兴起，三位网页设计领域的先驱人物大卫·西格尔（David Siegel）、雅各布·尼尔森（Jakob Nielsen）和杰弗里·泽尔达曼（Jeffrey Zeldman）分别提出了不同的网页设计理念。西格尔主张通过 HTML “黑客” 技巧来提升网站的视觉效果，例如使用隐形表格和单像素 GIF 图片来控制布局。尼尔森则强调简单性和网页的可访问性，倡导使用语义化编码将内容与表现分离，并支持新兴的 CSS 标准。泽尔达曼则将设计感与可用性相结合，他支持 CSS，但也愿意使用像 Shockwave 和 Flash 这样的新工具，尽管这些工具可能不符合语义化编码的要求。
泽尔达曼在 1997 年初开始他的网页设计生涯时，受到了西格尔的影响。西格尔在 1996 年出版的《Creating Killer Web Sites: The Art of Third-Generation Site Design》一书中，提出了许多 HTML 黑客技巧，这些技巧在当时 CSS 和 Flash 尚未普及的情况下，为网页设计带来了新的视觉可能性。而尼尔森则将自己定位为网页设计的 “警长”，他反对西格尔的 “HTML 恐怖主义”，认为网页设计应该以用户为中心，确保在所有主要浏览器上都能正常显示。
1997 年，Flash 2 的发布为网页设计带来了新的机遇。Flash 是一种矢量图形动画工具，它易于学习，且在视觉效果上远超当时的 CSS。Flash 不依赖于浏览器的实现，用户只需下载一个浏览器插件即可使用。西格尔很快就接受了 Flash，并在其 1997 年出版的《Creating Killer Web Sites》第二版中，将 Flash 称为将矢量图形引入网页主流使用的最佳选择。然而，尼尔森则因为 Flash 将内容和表现混合在一起，不符合语义化编码的原则，而迅速拒绝了它。
随着时间的推移，CSS 和 Flash 的发展轨迹逐渐分化。尽管 Flash 在 1990 年代后期成为许多网页设计师的首选工具，但最终，CSS 作为开放的网页标准，逐渐赢得了更多支持。泽尔达曼最终也放弃了 Flash，转而专注于符合标准的网页设计。他的设计理念——将设计感与标准兼容性相结合——在 1990 年代和 2000 年代初期取得了胜利。
在后续的职业生涯中，尼尔森的网站 Useit 以其极简主义风格而闻名，但在 Web 2.0 时代被认为过时，最终在 2012 年被整合到他的公司网站 NNGroup 中。西格尔则转向了商业领域，涉足区块链等领域。而泽尔达曼至今仍然是网页设计领域的活跃人物，他目前担任 Automattic 公司的执行创意总监，并继续在其个人网站上撰写关于网页设计的文章。
#网页设计
https://cybercultural.com/p/web-design-1997/
在 1997 年，随着 Flash 和 CSS 的兴起，三位网页设计领域的先驱人物大卫·西格尔（David Siegel）、雅各布·尼尔森（Jakob Nielsen）和杰弗里·泽尔达曼（Jeffrey Zeldman）分别提出了不同的网页设计理念。西格尔主张通过 HTML “黑客” 技巧来提升网站的视觉效果，例如使用隐形表格和单像素 GIF 图片来控制布局。尼尔森则强调简单性和网页的可访问性，倡导使用语义化编码将内容与表现分离，并支持新兴的 CSS 标准。泽尔达曼则将设计感与可用性相结合，他支持 CSS，但也愿意使用像 Shockwave 和 Flash 这样的新工具，尽管这些工具可能不符合语义化编码的要求。
泽尔达曼在 1997 年初开始他的网页设计生涯时，受到了西格尔的影响。西格尔在 1996 年出版的《Creating Killer Web Sites: The Art of Third-Generation Site Design》一书中，提出了许多 HTML 黑客技巧，这些技巧在当时 CSS 和 Flash 尚未普及的情况下，为网页设计带来了新的视觉可能性。而尼尔森则将自己定位为网页设计的 “警长”，他反对西格尔的 “HTML 恐怖主义”，认为网页设计应该以用户为中心，确保在所有主要浏览器上都能正常显示。
1997 年，Flash 2 的发布为网页设计带来了新的机遇。Flash 是一种矢量图形动画工具，它易于学习，且在视觉效果上远超当时的 CSS。Flash 不依赖于浏览器的实现，用户只需下载一个浏览器插件即可使用。西格尔很快就接受了 Flash，并在其 1997 年出版的《Creating Killer Web Sites》第二版中，将 Flash 称为将矢量图形引入网页主流使用的最佳选择。然而，尼尔森则因为 Flash 将内容和表现混合在一起，不符合语义化编码的原则，而迅速拒绝了它。
随着时间的推移，CSS 和 Flash 的发展轨迹逐渐分化。尽管 Flash 在 1990 年代后期成为许多网页设计师的首选工具，但最终，CSS 作为开放的网页标准，逐渐赢得了更多支持。泽尔达曼最终也放弃了 Flash，转而专注于符合标准的网页设计。他的设计理念——将设计感与标准兼容性相结合——在 1990 年代和 2000 年代初期取得了胜利。
在后续的职业生涯中，尼尔森的网站 Useit 以其极简主义风格而闻名，但在 Web 2.0 时代被认为过时，最终在 2012 年被整合到他的公司网站 NNGroup 中。西格尔则转向了商业领域，涉足区块链等领域。而泽尔达曼至今仍然是网页设计领域的活跃人物，他目前担任 Automattic 公司的执行创意总监，并继续在其个人网站上撰写关于网页设计的文章。
#网页设计
https://cybercultural.com/p/web-design-1997/
Cybercultural
The 3 Gurus of 90s Web Design: Zeldman, Siegel, Nielsen
With the rise of Flash and CSS in 1997, three web design philosophies emerged. David Siegel advocated for 'hacks', Jakob Nielsen kept it simple, while Jeffrey Zeldman combined flair with usability.
现在可能是学习软件开发的最佳时机
Nathan Figueroa 探讨了在当前 AI 技术快速发展的背景下，软件开发人员的现状与未来。他认为现在可能是学习软件开发的最佳时机，尽管许多人担心 AI 会取代开发人员的工作，但实际情况并非如此。他指出，AI 虽然能够快速生成代码，但开发人员的工作不仅仅是写代码，还包括理解业务需求、解决社会问题以及发现真正需要解决的问题。AI 可能会创造出看似完美的解决方案，但这些往往是基于错误的假设或缺乏对现实情况的深入理解。
开发人员的“护城河”（即他们的专业知识和对业务的深刻理解）也是企业的竞争优势。如果企业轻易地用 AI 替换开发人员，可能会失去这种优势。相反，企业应该利用 AI 来增强开发人员的能力，让他们能够以更快的速度和更广泛的范围进行开发。AI 的普及使得学习软件开发变得更加容易，但这也可能导致一些人忽视基础知识的学习，从而陷入“语言模型幻觉”的困境。
Nathan 认为软件开发仍然是一个需要解决的问题，而且在未来很长一段时间内，人类的专业知识和经验仍然不可或缺。AI 虽然强大，但需要人类来指导和监督，以确保其输出的结果符合实际需求。他呼吁企业继续投资于传统开发人员的培养，而不是完全依赖 AI，因为那些能够将 AI 与人类智慧相结合的团队将在未来取得更大的成功。
#AI #软件开发
https://substack.com/home/post/p-165655726
Nathan Figueroa 探讨了在当前 AI 技术快速发展的背景下，软件开发人员的现状与未来。他认为现在可能是学习软件开发的最佳时机，尽管许多人担心 AI 会取代开发人员的工作，但实际情况并非如此。他指出，AI 虽然能够快速生成代码，但开发人员的工作不仅仅是写代码，还包括理解业务需求、解决社会问题以及发现真正需要解决的问题。AI 可能会创造出看似完美的解决方案，但这些往往是基于错误的假设或缺乏对现实情况的深入理解。
开发人员的“护城河”（即他们的专业知识和对业务的深刻理解）也是企业的竞争优势。如果企业轻易地用 AI 替换开发人员，可能会失去这种优势。相反，企业应该利用 AI 来增强开发人员的能力，让他们能够以更快的速度和更广泛的范围进行开发。AI 的普及使得学习软件开发变得更加容易，但这也可能导致一些人忽视基础知识的学习，从而陷入“语言模型幻觉”的困境。
Nathan 认为软件开发仍然是一个需要解决的问题，而且在未来很长一段时间内，人类的专业知识和经验仍然不可或缺。AI 虽然强大，但需要人类来指导和监督，以确保其输出的结果符合实际需求。他呼吁企业继续投资于传统开发人员的培养，而不是完全依赖 AI，因为那些能够将 AI 与人类智慧相结合的团队将在未来取得更大的成功。
#AI #软件开发
https://substack.com/home/post/p-165655726
Substack
Now might be the best time to learn software development
And the most fun
谷歌翻译对 Vibecoding 的启示
最近关于大型语言模型（LLMs）是否会导致计算机编程职业终结的讨论甚嚣尘上，但这些讨论往往缺乏深度。许多人在尝试使用某种 LLM 服务提供商创建小型工具后，便宣称程序员将在某个任意时间窗口内失业，而另一些人则完全否定这类工具的实用性。为了更好地理解这些观点，可以将其放在翻译领域进行类比分析，因为翻译领域在技术应用方面已经走在前列。
谷歌翻译自 2016 年转向神经机器翻译（NMT）以来，技术上有了显著进步，但关于机器翻译将终结翻译和口译职业的言论一直存在。然而，实际情况是，尽管机器翻译技术非常有用，但翻译和口译的工作机会实际上在增加。美国翻译协会的代表布里奇特·希尔雅克（Bridget Hylak）指出，自 2016 年 NMT 出现以来，翻译和口译人员已经开始将人工智能整合到工作流程中。
这种现象的矛盾之处在于，翻译和口译的工作性质常被误解。许多人认为翻译者只是简单的词汇和语法转换者，但实际上他们的工作更多是关于确保上下文的准确性、处理模糊性以及处理文化敏感性。谷歌翻译目前无法做到这些。例如，挪威语与英语非常接近，词汇、语法和文化背景相似，但仍然存在重要的文化差异。挪威语中缺乏礼貌用语，而英语中则常用“请”等词。谷歌翻译会直接翻译，而专业翻译者则会根据上下文提供更敏感的翻译。在法律听证会等场合，这种差异可能引发严重后果。
尽管如此，谷歌翻译并非做得不好。它在某些情况下提供了直接的翻译，但翻译者可能会根据具体语境进行调整。对于编程来说，情况也类似。程序员可以被视为将人类模糊的语言和文化细节翻译成计算机绝对逻辑的“翻译者”，但编程语言中更频繁地创造新抽象，这使得机器翻译在编程语言中的应用比自然语言翻译稍晚。不过，随着技术的发展，这一差距正在缩小。
尽管未来可能有某种形式的人工智能能够像人类一样处理上下文和模糊性，但目前看来，我们至少还需要经历一次“AI 寒冬”，因为当前的人工智能巨头似乎更关注工具的表面光鲜而非提供负责任的输出。虽然这些工具的实用性有限，但其负面影响可能更为突出。
#思考 #AI #Vibe_Coding
https://ingrids.space/posts/what-google-translate-can-tell-us-about-vibecoding/
最近关于大型语言模型（LLMs）是否会导致计算机编程职业终结的讨论甚嚣尘上，但这些讨论往往缺乏深度。许多人在尝试使用某种 LLM 服务提供商创建小型工具后，便宣称程序员将在某个任意时间窗口内失业，而另一些人则完全否定这类工具的实用性。为了更好地理解这些观点，可以将其放在翻译领域进行类比分析，因为翻译领域在技术应用方面已经走在前列。
谷歌翻译自 2016 年转向神经机器翻译（NMT）以来，技术上有了显著进步，但关于机器翻译将终结翻译和口译职业的言论一直存在。然而，实际情况是，尽管机器翻译技术非常有用，但翻译和口译的工作机会实际上在增加。美国翻译协会的代表布里奇特·希尔雅克（Bridget Hylak）指出，自 2016 年 NMT 出现以来，翻译和口译人员已经开始将人工智能整合到工作流程中。
这种现象的矛盾之处在于，翻译和口译的工作性质常被误解。许多人认为翻译者只是简单的词汇和语法转换者，但实际上他们的工作更多是关于确保上下文的准确性、处理模糊性以及处理文化敏感性。谷歌翻译目前无法做到这些。例如，挪威语与英语非常接近，词汇、语法和文化背景相似，但仍然存在重要的文化差异。挪威语中缺乏礼貌用语，而英语中则常用“请”等词。谷歌翻译会直接翻译，而专业翻译者则会根据上下文提供更敏感的翻译。在法律听证会等场合，这种差异可能引发严重后果。
尽管如此，谷歌翻译并非做得不好。它在某些情况下提供了直接的翻译，但翻译者可能会根据具体语境进行调整。对于编程来说，情况也类似。程序员可以被视为将人类模糊的语言和文化细节翻译成计算机绝对逻辑的“翻译者”，但编程语言中更频繁地创造新抽象，这使得机器翻译在编程语言中的应用比自然语言翻译稍晚。不过，随着技术的发展，这一差距正在缩小。
尽管未来可能有某种形式的人工智能能够像人类一样处理上下文和模糊性，但目前看来，我们至少还需要经历一次“AI 寒冬”，因为当前的人工智能巨头似乎更关注工具的表面光鲜而非提供负责任的输出。虽然这些工具的实用性有限，但其负面影响可能更为突出。
#思考 #AI #Vibe_Coding
https://ingrids.space/posts/what-google-translate-can-tell-us-about-vibecoding/
ingrids.space
What Google Translate Can Tell Us About Vibecoding | Ingrid's Space
Ingrid's personal site and blog
Workout.cool 是一个现代化的开源健身指导平台，提供全面的健身计划创建、进度跟踪以及详细的健身动作数据库和视频演示。该项目由 Snouzy 发起，旨在复兴和改进之前被遗弃的健身平台 workout.lol。由于原平台因健身视频合作问题被出售并最终被遗弃，Snouzy 决定重新启动一个全新的项目，以满足开源健身社区的需求。
#健康
https://github.com/Snouzy/workout-cool
#健康
https://github.com/Snouzy/workout-cool
GitHub
GitHub - Snouzy/workout-cool: 🏋 Modern open-source fitness coaching platform. Create workout plans, track progress, and access…
🏋 Modern open-source fitness coaching platform. Create workout plans, track progress, and access a comprehensive exercise database. - Snouzy/workout-cool
作为开发人员，我最重要的工具是一支笔和一个笔记本
Juha-Matti Santala 分享了作为软件开发者最重要的工具是笔和笔记本，而非电脑。他提到在开始新工作前，他特意购买了一本橙色笔记本，这对他来说意义非凡。他认为，开发软件或解决问题时，编写代码只是最后一步，而更重要的是确定要编写什么代码。他发现，自己在电脑前思考时效率不高，因为一旦打开代码编辑器，就会进入“功能模式”，难以激发创造力。因此，他常常离开电脑，或去散步，或带着笔记本坐在沙发上或户外思考。他会在笔记本上记录初始解决方案、绘制用户界面草图或流程图，帮助自己理解代码库中的数据流和交互，以便修复漏洞或添加新功能。
写作和绘图是强大的思考工具，能够将抽象的想法转化为具体的文字和图画，还能暴露知识或理解上的漏洞，因为写作时无法像单纯思考时那样轻易跳过这些问题。他喜欢在写完代码后，像向他人解释一样记录下来，甚至将其发布为博客文章。这种方式不仅能帮助他发现代码中的不一致、设计缺陷甚至错误，还能留下思考过程的记录，方便日后回顾。他鼓励读者通过电子邮件与他交流，分享自己的想法，并希望在 2025 年与世界各地的人进行更深入的讨论。
#写作 #软件开发
https://hamatti.org/posts/as-a-developer-my-most-important-tools-are-a-pen-and-a-notebook/
Juha-Matti Santala 分享了作为软件开发者最重要的工具是笔和笔记本，而非电脑。他提到在开始新工作前，他特意购买了一本橙色笔记本，这对他来说意义非凡。他认为，开发软件或解决问题时，编写代码只是最后一步，而更重要的是确定要编写什么代码。他发现，自己在电脑前思考时效率不高，因为一旦打开代码编辑器，就会进入“功能模式”，难以激发创造力。因此，他常常离开电脑，或去散步，或带着笔记本坐在沙发上或户外思考。他会在笔记本上记录初始解决方案、绘制用户界面草图或流程图，帮助自己理解代码库中的数据流和交互，以便修复漏洞或添加新功能。
写作和绘图是强大的思考工具，能够将抽象的想法转化为具体的文字和图画，还能暴露知识或理解上的漏洞，因为写作时无法像单纯思考时那样轻易跳过这些问题。他喜欢在写完代码后，像向他人解释一样记录下来，甚至将其发布为博客文章。这种方式不仅能帮助他发现代码中的不一致、设计缺陷甚至错误，还能留下思考过程的记录，方便日后回顾。他鼓励读者通过电子邮件与他交流，分享自己的想法，并希望在 2025 年与世界各地的人进行更深入的讨论。
#写作 #软件开发
https://hamatti.org/posts/as-a-developer-my-most-important-tools-are-a-pen-and-a-notebook/
Juha-Matti Santala - Community Builder. Dreamer. Adventurer.
As a developer, my most important tools are a pen and a notebook
Writing code is a part of being a software developer but often more important question is to figure what code to write and how and that I like to do away from computer with my notebook.
Claude 4 系统提示亮点精选
Simon Willison 详细分析了 Anthropic 发布的 Claude 4 系统提示。Claude 是由 Anthropic 开发的 AI 助手，Claude 4 家族包括 Claude Opus 4 和 Claude Sonnet 4，其中 Claude Opus 4 适用于复杂任务。系统提示中明确指出 Claude 的知识截止日期为 2025 年 1 月，尽管 Anthropic 的模型比较表显示训练数据截止日期为 2025 年 3 月。系统提示还强调了 Claude 在处理涉及未成年人、恶意代码、版权内容等方面的安全性和合规性，同时指出 Claude 应避免过度使用列表形式回答问题，并在对话中保持自然、温暖和富有同理心的语气。
Simon 还探讨了 Claude 4 的工具提示，这些提示并未由 Anthropic 官方发布，但通过泄露的版本得以窥见。Claude 4 支持交错思考模式，可以在思考过程中执行工具调用。系统提示中还包含了关于如何使用搜索工具的详细说明，强调 Claude 应在需要最新信息时使用搜索工具，并且在回答中严格遵守版权要求，避免直接复制或引用大量受版权保护的内容。
此外，系统提示还涉及 Claude 的“风格”功能，允许用户选择不同的回答风格，如简洁、解释性或正式等。Claude 需要根据用户选择的风格调整回答的语气和词汇。Simon 认为这些系统提示是 Anthropic 提供的宝贵文档，有助于用户更好地利用 Claude 4 的功能。
#AI #Claude #Prompt
https://simonwillison.net/2025/May/25/claude-4-system-prompt/
Simon Willison 详细分析了 Anthropic 发布的 Claude 4 系统提示。Claude 是由 Anthropic 开发的 AI 助手，Claude 4 家族包括 Claude Opus 4 和 Claude Sonnet 4，其中 Claude Opus 4 适用于复杂任务。系统提示中明确指出 Claude 的知识截止日期为 2025 年 1 月，尽管 Anthropic 的模型比较表显示训练数据截止日期为 2025 年 3 月。系统提示还强调了 Claude 在处理涉及未成年人、恶意代码、版权内容等方面的安全性和合规性，同时指出 Claude 应避免过度使用列表形式回答问题，并在对话中保持自然、温暖和富有同理心的语气。
Simon 还探讨了 Claude 4 的工具提示，这些提示并未由 Anthropic 官方发布，但通过泄露的版本得以窥见。Claude 4 支持交错思考模式，可以在思考过程中执行工具调用。系统提示中还包含了关于如何使用搜索工具的详细说明，强调 Claude 应在需要最新信息时使用搜索工具，并且在回答中严格遵守版权要求，避免直接复制或引用大量受版权保护的内容。
此外，系统提示还涉及 Claude 的“风格”功能，允许用户选择不同的回答风格，如简洁、解释性或正式等。Claude 需要根据用户选择的风格调整回答的语气和词汇。Simon 认为这些系统提示是 Anthropic 提供的宝贵文档，有助于用户更好地利用 Claude 4 的功能。
#AI #Claude #Prompt
https://simonwillison.net/2025/May/25/claude-4-system-prompt/
Simon Willison’s Weblog
Highlights from the Claude 4 system prompt
Anthropic publish most of the system prompts for their chat models as part of their release notes. They recently shared the new prompts for both Claude Opus 4 and Claude …
让 Bug 自动“蒸发”！我们造了个 AI 程序员同事
雪球工程师团队分享了他们开发的 AI 神器 AIFix，旨在帮助程序员自动修复代码中的 Bug，显著减轻手动修 Bug 的工作量。AIFix 能够端到端处理完整开发流程，如同 24 小时待命的代码医生，从发现问题到解决问题一气呵成。
在内部测试中，AIFix 表现亮眼，能够解决 70% 的前端样式问题、60% 的接口调用问题以及 80% 的 React Native 应用闪退问题，自动修复的准确率高达 66%。其核心技术包括 MCP 协议、Bug 信息智能工厂和自动修复流水线。MCP 协议如同一个“万能插座”，能够连接不同的 AI 模型，实现即插即用，方便调用各类数据和工具。Bug 信息智能工厂则通过引导 QA 填写标准模板、智能识别图片标注等方式，整合各类信息生成完整的 Bug 分析报告。自动修复流水线则能够精准判断 Bug 类型、定位代码问题并生成修复方案，对于可自动修复的问题，AI 直接修改代码并编译运行。
AIFix 的工作流程在 Dify 平台中得以实现，Dify 类似于一个智能厨房，能够让用户无需编写复杂代码，通过简单的界面操作即可编排 AI 模型完成定制任务。例如，通过 MCP 协议，AI 可以将不同工具的专业术语转换为统一语言，方便任务的执行和工具的扩展。
为了提高 AI 对 Bug 的判断准确性，团队通过分析历史数据，不断优化 AI 的判断逻辑，并借鉴了之前“雪莲”项目的成功经验。AI 还能够通过视觉识别模型读懂 Bug 截图，生成清晰的问题描述报告。未来，AIFix 将进一步扩展功能，如直接看懂视频中的 Bug，以及实现从 Bug 发现到代码修复提交的全自动流水线。
AIFix 的出现验证了规范、连接和人机协作的重要性。规范化的 Bug 描述模板提高了 AI 的理解准确率，MCP 协议让 AI 工具自由组合，发挥更大价值，而 AI 则将程序员从重复劳动中解放出来，专注于更具创造性的任务。
#AI #MCP #实践
https://juejin.cn/post/7514250027024285734
雪球工程师团队分享了他们开发的 AI 神器 AIFix，旨在帮助程序员自动修复代码中的 Bug，显著减轻手动修 Bug 的工作量。AIFix 能够端到端处理完整开发流程，如同 24 小时待命的代码医生，从发现问题到解决问题一气呵成。
在内部测试中，AIFix 表现亮眼，能够解决 70% 的前端样式问题、60% 的接口调用问题以及 80% 的 React Native 应用闪退问题，自动修复的准确率高达 66%。其核心技术包括 MCP 协议、Bug 信息智能工厂和自动修复流水线。MCP 协议如同一个“万能插座”，能够连接不同的 AI 模型，实现即插即用，方便调用各类数据和工具。Bug 信息智能工厂则通过引导 QA 填写标准模板、智能识别图片标注等方式，整合各类信息生成完整的 Bug 分析报告。自动修复流水线则能够精准判断 Bug 类型、定位代码问题并生成修复方案，对于可自动修复的问题，AI 直接修改代码并编译运行。
AIFix 的工作流程在 Dify 平台中得以实现，Dify 类似于一个智能厨房，能够让用户无需编写复杂代码，通过简单的界面操作即可编排 AI 模型完成定制任务。例如，通过 MCP 协议，AI 可以将不同工具的专业术语转换为统一语言，方便任务的执行和工具的扩展。
为了提高 AI 对 Bug 的判断准确性，团队通过分析历史数据，不断优化 AI 的判断逻辑，并借鉴了之前“雪莲”项目的成功经验。AI 还能够通过视觉识别模型读懂 Bug 截图，生成清晰的问题描述报告。未来，AIFix 将进一步扩展功能，如直接看懂视频中的 Bug，以及实现从 Bug 发现到代码修复提交的全自动流水线。
AIFix 的出现验证了规范、连接和人机协作的重要性。规范化的 Bug 描述模板提高了 AI 的理解准确率，MCP 协议让 AI 工具自由组合，发挥更大价值，而 AI 则将程序员从重复劳动中解放出来，专注于更具创造性的任务。
#AI #MCP #实践
https://juejin.cn/post/7514250027024285734
为无法仅凭直觉行事的团队准备的 AI 辅助编程
Atharva Raykar 探讨了 AI 辅助编程在团队开发中的应用，强调 AI 是一个乘数，其效果取决于使用者的能力。优秀的工程师能够更好地利用 AI 工具，因为他们擅长沟通技术思想、具备对系统的敏锐直觉，并且能够快速掌握新知识。AI 对语言和风格敏感，会反映提示者的品味和直觉，因此开发人员需要像工匠一样投入精力，确保 AI 生成的成果值得骄傲。
在开发过程中，AI 的速度优势至关重要，能够帮助团队更快地与用户进行反馈循环，从而打造更好的产品。然而，AI 工具使用不当可能会导致结果不尽如人意，甚至减慢开发速度。通过精心设计的提示，例如在实现 Python 速率限制器时，详细说明需求和考虑因素，可以更好地实现程序设计者的意图。此外，一种有效的技术是元提示（metaprompting），即先让模型帮助识别权衡和边缘情况，然后将其转化为技术规格，交给另一个 AI 代理执行。
AI 在高质量的团队和代码库环境中表现更好，这些环境具有良好的测试覆盖率、自动化的代码检查、持续集成与部署、清晰的文档记录、一致的代码风格以及简单、清晰、有组织的代码结构。AI 可以利用这些优势来提高工作效率，减少人工干预。例如，在一个具有良好测试和文档的项目中，AI 编程助手能够更轻松地完成任务，而在混乱的代码库中则会遇到困难。
在编辑器中使用 AI 时，建议采用先进的 AI 模型，并且不要吝啬成本，因为优质模型的效果会不断累积。同时，要善于提供上下文信息，使用能够自主分析文件、运行命令、获取文档并执行计划的“代理型”编码工具。此外，通过在 RULES.md 文件中编码编码标准和实践，可以指导 AI 遵循团队的开发规范。
在实现新功能或重构时，需要将问题分解为更具体的小任务，逐个提供给 AI，并在每个任务结束后提交代码。同时，提供技术规格和相关文档，帮助 AI 理解产品和功能的背景。在调试过程中，利用 AI 来分析错误，提供详细的错误上下文和尝试过的解决方案，以便 AI 生成准确的假设。
在编辑器之外，AI 可以用于提升个人技能和知识，通过与 AI 互动学习最佳实践。AI 还可以生成详细的文档，例如解释代码功能、创建知识库、总结指标和智能识别缺失的测试用例。此外，AI 可以用于创建模拟服务器、编写运行手册、自动化常见任务、代码审查、调试和监控应用程序以及性能优化。
AI 的出现改变了软件开发的某些传统观念。例如，现在重复工作变得不那么令人反感，因为 AI 可以处理一些重复性任务，避免过早抽象化。同时，测试变得不可或缺，因为 AI 可以快速生成测试用例，但需要人工审查断言。
#AI #指南 #实践 #Vibe_Coding
https://blog.nilenso.com/blog/2025/05/29/ai-assisted-coding/
Atharva Raykar 探讨了 AI 辅助编程在团队开发中的应用，强调 AI 是一个乘数，其效果取决于使用者的能力。优秀的工程师能够更好地利用 AI 工具，因为他们擅长沟通技术思想、具备对系统的敏锐直觉，并且能够快速掌握新知识。AI 对语言和风格敏感，会反映提示者的品味和直觉，因此开发人员需要像工匠一样投入精力，确保 AI 生成的成果值得骄傲。
在开发过程中，AI 的速度优势至关重要，能够帮助团队更快地与用户进行反馈循环，从而打造更好的产品。然而，AI 工具使用不当可能会导致结果不尽如人意，甚至减慢开发速度。通过精心设计的提示，例如在实现 Python 速率限制器时，详细说明需求和考虑因素，可以更好地实现程序设计者的意图。此外，一种有效的技术是元提示（metaprompting），即先让模型帮助识别权衡和边缘情况，然后将其转化为技术规格，交给另一个 AI 代理执行。
AI 在高质量的团队和代码库环境中表现更好，这些环境具有良好的测试覆盖率、自动化的代码检查、持续集成与部署、清晰的文档记录、一致的代码风格以及简单、清晰、有组织的代码结构。AI 可以利用这些优势来提高工作效率，减少人工干预。例如，在一个具有良好测试和文档的项目中，AI 编程助手能够更轻松地完成任务，而在混乱的代码库中则会遇到困难。
在编辑器中使用 AI 时，建议采用先进的 AI 模型，并且不要吝啬成本，因为优质模型的效果会不断累积。同时，要善于提供上下文信息，使用能够自主分析文件、运行命令、获取文档并执行计划的“代理型”编码工具。此外，通过在 RULES.md 文件中编码编码标准和实践，可以指导 AI 遵循团队的开发规范。
在实现新功能或重构时，需要将问题分解为更具体的小任务，逐个提供给 AI，并在每个任务结束后提交代码。同时，提供技术规格和相关文档，帮助 AI 理解产品和功能的背景。在调试过程中，利用 AI 来分析错误，提供详细的错误上下文和尝试过的解决方案，以便 AI 生成准确的假设。
在编辑器之外，AI 可以用于提升个人技能和知识，通过与 AI 互动学习最佳实践。AI 还可以生成详细的文档，例如解释代码功能、创建知识库、总结指标和智能识别缺失的测试用例。此外，AI 可以用于创建模拟服务器、编写运行手册、自动化常见任务、代码审查、调试和监控应用程序以及性能优化。
AI 的出现改变了软件开发的某些传统观念。例如，现在重复工作变得不那么令人反感，因为 AI 可以处理一些重复性任务，避免过早抽象化。同时，测试变得不可或缺，因为 AI 可以快速生成测试用例，但需要人工审查断言。
#AI #指南 #实践 #Vibe_Coding
https://blog.nilenso.com/blog/2025/05/29/ai-assisted-coding/
Nilenso
AI-assisted coding for teams that can't get away with vibes - nilenso blog
...
我们如何构建多智能体研究系统
Anthropic 团队详细介绍了他们构建多智能体研究系统的经验。该系统利用多个智能体（LLM 自主使用工具循环工作）协同完成复杂任务，其研究功能通过基于用户查询的计划过程，创建并行智能体同时搜索信息，显著提升了处理复杂问题的能力。
多智能体系统的优点在于其能够应对研究工作中难以预测的步骤。与传统的线性流程不同，多智能体系统能够在研究过程中动态调整方向，灵活探索新的线索。这种系统的本质是通过压缩大量信息来提炼关键见解，子智能体通过并行操作和各自的情境窗口，探索问题的不同方面，最终将重要信息汇总给主研究智能体。此外，子智能体的独立性减少了路径依赖性，使每个智能体能够独立进行彻底的调查。内部评估显示，以 Claude Opus 4 为主智能体、Claude Sonnet 4 为子智能体的多智能体系统，在内部研究评估中比单智能体 Claude Opus 4 的表现提升了 90.2%。
该研究系统采用主从模式的多智能体架构，主智能体负责协调整个过程，并将任务分配给专门的子智能体并行执行。用户提交查询后，主智能体分析查询内容，制定策略，并生成子智能体以同时探索不同方面。子智能体通过迭代使用搜索工具收集信息，并将结果返回给主智能体，后者汇总信息并决定是否需要进一步研究。与传统的检索增强生成（RAG）方法相比，该架构通过多步骤搜索动态发现相关信息，适应新发现，并分析结果以形成高质量答案。
多智能体系统与单智能体系统的主要区别在于协调复杂性的快速增长。提示工程是改善智能体行为的主要手段。例如，通过模拟智能体的工作过程，发现早期智能体存在生成过多子智能体、无休止地搜索不存在的来源以及因过多更新而相互干扰等问题。为解决这些问题，提出了以下原则：像智能体一样思考，以迭代提示并理解其效果；教导主智能体如何有效分配任务；根据查询复杂性调整努力程度；选择合适的工具至关重要；让智能体自我改进，例如 Claude 4 模型可以作为优秀的提示工程师，诊断失败模式并提出改进建议；搜索策略应先广泛探索再逐步缩小范围；引导智能体的思考过程，使用扩展思考模式来规划方法；并行工具调用可显著提升速度和性能。这些提示策略专注于灌输良好的启发式规则，而非僵化的规则，同时通过明确的防护措施避免智能体失控。
评估多智能体系统面临独特挑战，因为这些系统即使从相同起点出发，也可能采取完全不同的有效路径。因此，需要灵活的评估方法，判断智能体是否达到正确结果，同时遵循合理过程。建议从少量样本开始评估，因为早期的提示调整可能会产生显著影响。使用 LLM 作为评估工具可以有效扩展评估规模，通过设定标准对输出进行评分。此外，人工评估能够发现自动化评估遗漏的问题，如智能体选择低质量来源等。多智能体系统的出现行为需要通过观察智能体之间的互动模式来理解，而不仅仅是单独的智能体行为。
在传统软件中，错误可能导致功能故障、性能下降或停机，而在智能体系统中，即使是小错误也可能引发大规模行为变化。智能体系统需要长时间保持状态，因此需要有效执行代码并处理错误。通过构建能够从错误发生点恢复的系统，并结合模型的智能来优雅地处理问题，可以提高系统的可靠性。调试智能体系统需要新的方法，因为智能体的动态决策和非确定性使得问题诊断更加困难。通过添加完整的生产跟踪，可以系统地诊断和解决问题。部署更新时，需要避免破坏正在运行的智能体，因此采用逐步转移流量的彩虹部署策略。此外，当前主智能体同步执行子智能体，这虽然简化了协调，但会创建信息流瓶颈。异步执行可以增加并行性，但也带来了结果协调、状态一致性和错误传播等挑战。
尽管存在诸多挑战，多智能体系统在开放性研究任务中已被证明具有巨大价值。用户反馈表明，Claude 帮助他们发现了新的商业机会，解决了复杂的技术问题，并节省了大量时间。通过精心的工程设计、全面的测试、细致的提示和工具设计、稳健的操作实践以及研究、产品和工程团队之间的紧密合作，多智能体研究系统可以在大规模生产环境中可靠运行。
#AI #Claude #Research #指南
https://www.anthropic.com/engineering/built-multi-agent-research-system
Anthropic 团队详细介绍了他们构建多智能体研究系统的经验。该系统利用多个智能体（LLM 自主使用工具循环工作）协同完成复杂任务，其研究功能通过基于用户查询的计划过程，创建并行智能体同时搜索信息，显著提升了处理复杂问题的能力。
多智能体系统的优点在于其能够应对研究工作中难以预测的步骤。与传统的线性流程不同，多智能体系统能够在研究过程中动态调整方向，灵活探索新的线索。这种系统的本质是通过压缩大量信息来提炼关键见解，子智能体通过并行操作和各自的情境窗口，探索问题的不同方面，最终将重要信息汇总给主研究智能体。此外，子智能体的独立性减少了路径依赖性，使每个智能体能够独立进行彻底的调查。内部评估显示，以 Claude Opus 4 为主智能体、Claude Sonnet 4 为子智能体的多智能体系统，在内部研究评估中比单智能体 Claude Opus 4 的表现提升了 90.2%。
该研究系统采用主从模式的多智能体架构，主智能体负责协调整个过程，并将任务分配给专门的子智能体并行执行。用户提交查询后，主智能体分析查询内容，制定策略，并生成子智能体以同时探索不同方面。子智能体通过迭代使用搜索工具收集信息，并将结果返回给主智能体，后者汇总信息并决定是否需要进一步研究。与传统的检索增强生成（RAG）方法相比，该架构通过多步骤搜索动态发现相关信息，适应新发现，并分析结果以形成高质量答案。
多智能体系统与单智能体系统的主要区别在于协调复杂性的快速增长。提示工程是改善智能体行为的主要手段。例如，通过模拟智能体的工作过程，发现早期智能体存在生成过多子智能体、无休止地搜索不存在的来源以及因过多更新而相互干扰等问题。为解决这些问题，提出了以下原则：像智能体一样思考，以迭代提示并理解其效果；教导主智能体如何有效分配任务；根据查询复杂性调整努力程度；选择合适的工具至关重要；让智能体自我改进，例如 Claude 4 模型可以作为优秀的提示工程师，诊断失败模式并提出改进建议；搜索策略应先广泛探索再逐步缩小范围；引导智能体的思考过程，使用扩展思考模式来规划方法；并行工具调用可显著提升速度和性能。这些提示策略专注于灌输良好的启发式规则，而非僵化的规则，同时通过明确的防护措施避免智能体失控。
评估多智能体系统面临独特挑战，因为这些系统即使从相同起点出发，也可能采取完全不同的有效路径。因此，需要灵活的评估方法，判断智能体是否达到正确结果，同时遵循合理过程。建议从少量样本开始评估，因为早期的提示调整可能会产生显著影响。使用 LLM 作为评估工具可以有效扩展评估规模，通过设定标准对输出进行评分。此外，人工评估能够发现自动化评估遗漏的问题，如智能体选择低质量来源等。多智能体系统的出现行为需要通过观察智能体之间的互动模式来理解，而不仅仅是单独的智能体行为。
在传统软件中，错误可能导致功能故障、性能下降或停机，而在智能体系统中，即使是小错误也可能引发大规模行为变化。智能体系统需要长时间保持状态，因此需要有效执行代码并处理错误。通过构建能够从错误发生点恢复的系统，并结合模型的智能来优雅地处理问题，可以提高系统的可靠性。调试智能体系统需要新的方法，因为智能体的动态决策和非确定性使得问题诊断更加困难。通过添加完整的生产跟踪，可以系统地诊断和解决问题。部署更新时，需要避免破坏正在运行的智能体，因此采用逐步转移流量的彩虹部署策略。此外，当前主智能体同步执行子智能体，这虽然简化了协调，但会创建信息流瓶颈。异步执行可以增加并行性，但也带来了结果协调、状态一致性和错误传播等挑战。
尽管存在诸多挑战，多智能体系统在开放性研究任务中已被证明具有巨大价值。用户反馈表明，Claude 帮助他们发现了新的商业机会，解决了复杂的技术问题，并节省了大量时间。通过精心的工程设计、全面的测试、细致的提示和工具设计、稳健的操作实践以及研究、产品和工程团队之间的紧密合作，多智能体研究系统可以在大规模生产环境中可靠运行。
#AI #Claude #Research #指南
https://www.anthropic.com/engineering/built-multi-agent-research-system
Anthropic
How we built our multi-agent research system
On the the engineering challenges and lessons learned from building Claude's Research system
GitHub CEO：尽管 AI 蓬勃发展，但手动编码仍是关键
Thomas Dohmke 强调尽管 AI 工具在软件开发中日益普及，但保留手动编码技能仍然至关重要。Dohmke 指出，开发者需要具备修改 AI 生成代码的能力，以避免生产力问题。他描述了一种有效的开发流程，即 AI 工具生成代码并提交拉取请求，开发者随后利用其编程技能进行即时调整。Dohmke 警告说，过度依赖自动化工具会导致效率低下，例如在自然语言中花费过多时间解释简单更改，而不是直接编辑代码。他提到：“最糟糕的情况是试图用自然语言描述我已经知道如何用编程语言完成的任务。”
Dohmke 还讨论了 “vibe coding” 这一概念，这是由 OpenAI 联合创始人 Andrej Karpathy 提出的，用来描述过度依赖 AI 生成代码的现象。Dohmke 的观点与行业共识一致，即最有效的 AI 编码策略是将自动化与人类编程技能相结合。德勤的研究表明，开发者主要使用 AI 工具来完成特定任务，如编写样板代码，同时保持人工监督，这可以每天提高 10 到 20 分钟的生产力。研究还显示，大约一半的 AI 生成代码存在部分错误，这凸显了人类专业知识的持续需求。谷歌的经验也反映了这种混合模式，该公司报告称，其超过 25% 的代码现在由 AI 生成，但仍需要大量的人工审查和优化。这种平衡的方法反映了对 AI 在软件开发中能力和局限性的成熟理解，表明最成功的实现将是增强而非取代开发人员专业知识的方案。
AI 并非在消除编程工作，而是将开发者的角色从纯编码者转变为 AI 辅助开发流程的协调者。行业专家预测，开发者角色将分为两类：利用 AI 进行代码生成的产品工程师和确保软件系统质量和安全性的高级架构师。这种转变需要新的技能，专注于战略问题解决、有效指导 AI 和做出高级设计决策，而不是手动编写每一行代码。软件工程师的持续短缺，加上研究表明 AI 工具对初级开发人员特别有益，表明 AI 将有助于弥合人才缺口，同时为经验丰富的程序员创造新的机会。这种转变与软件开发中的历史模式一致，新的工具和抽象改变了开发人员的工作方式，但并未消除对人类智慧的需求。
“vibe coding” 这一新兴方法展示了 AI 生成代码的潜力和局限性，尤其是在初创企业和复杂项目中。虽然 AI 工具能够实现快速原型设计和与敏捷方法论一致的迭代开发，但也引发了对代码质量、安全漏洞和可维护性的重大担忧。真实案例已经揭示了过度依赖未经验证的 AI 生成代码的危险，尤其是那些可能不会立即显现的安全问题。对于初创企业来说，这种紧张关系尤为相关，因为非技术创始人可能难以使用主要由 AI 生成的代码构建可持续的复杂系统，可能会产生阻碍未来增长的技术债务。成熟科技公司的经验表明，成功的 AI 集成需要在自动化与严格的质量保证流程之间取得平衡，这一经验对于在 “vibe coding” 趋势中导航的小型组织来说可能至关重要。
#AI #Github #Vibe_Coding #思考
https://www.techinasia.com/news/github-ceo-manual-coding-remains-key-despite-ai-boom
Thomas Dohmke 强调尽管 AI 工具在软件开发中日益普及，但保留手动编码技能仍然至关重要。Dohmke 指出，开发者需要具备修改 AI 生成代码的能力，以避免生产力问题。他描述了一种有效的开发流程，即 AI 工具生成代码并提交拉取请求，开发者随后利用其编程技能进行即时调整。Dohmke 警告说，过度依赖自动化工具会导致效率低下，例如在自然语言中花费过多时间解释简单更改，而不是直接编辑代码。他提到：“最糟糕的情况是试图用自然语言描述我已经知道如何用编程语言完成的任务。”
Dohmke 还讨论了 “vibe coding” 这一概念，这是由 OpenAI 联合创始人 Andrej Karpathy 提出的，用来描述过度依赖 AI 生成代码的现象。Dohmke 的观点与行业共识一致，即最有效的 AI 编码策略是将自动化与人类编程技能相结合。德勤的研究表明，开发者主要使用 AI 工具来完成特定任务，如编写样板代码，同时保持人工监督，这可以每天提高 10 到 20 分钟的生产力。研究还显示，大约一半的 AI 生成代码存在部分错误，这凸显了人类专业知识的持续需求。谷歌的经验也反映了这种混合模式，该公司报告称，其超过 25% 的代码现在由 AI 生成，但仍需要大量的人工审查和优化。这种平衡的方法反映了对 AI 在软件开发中能力和局限性的成熟理解，表明最成功的实现将是增强而非取代开发人员专业知识的方案。
AI 并非在消除编程工作，而是将开发者的角色从纯编码者转变为 AI 辅助开发流程的协调者。行业专家预测，开发者角色将分为两类：利用 AI 进行代码生成的产品工程师和确保软件系统质量和安全性的高级架构师。这种转变需要新的技能，专注于战略问题解决、有效指导 AI 和做出高级设计决策，而不是手动编写每一行代码。软件工程师的持续短缺，加上研究表明 AI 工具对初级开发人员特别有益，表明 AI 将有助于弥合人才缺口，同时为经验丰富的程序员创造新的机会。这种转变与软件开发中的历史模式一致，新的工具和抽象改变了开发人员的工作方式，但并未消除对人类智慧的需求。
“vibe coding” 这一新兴方法展示了 AI 生成代码的潜力和局限性，尤其是在初创企业和复杂项目中。虽然 AI 工具能够实现快速原型设计和与敏捷方法论一致的迭代开发，但也引发了对代码质量、安全漏洞和可维护性的重大担忧。真实案例已经揭示了过度依赖未经验证的 AI 生成代码的危险，尤其是那些可能不会立即显现的安全问题。对于初创企业来说，这种紧张关系尤为相关，因为非技术创始人可能难以使用主要由 AI 生成的代码构建可持续的复杂系统，可能会产生阻碍未来增长的技术债务。成熟科技公司的经验表明，成功的 AI 集成需要在自动化与严格的质量保证流程之间取得平衡，这一经验对于在 “vibe coding” 趋势中导航的小型组织来说可能至关重要。
#AI #Github #Vibe_Coding #思考
https://www.techinasia.com/news/github-ceo-manual-coding-remains-key-despite-ai-boom
Tech in Asia
GitHub CEO: manual coding remains key despite AI boom
GitHub CEO Thomas Dohmke said developers can make immediate adjustments using their programming skills.