返回首页
一周热榜
对于那些经常发布更新的团队来说，您通常是写一套发布说明，还是会为不同的受众重新编写它们？
例如：
• 针对开发者的技术版本
• 针对最终用户的简化版本
• 针对利益相关者的更高层次版本等……
在我目前的职位上，我见过许多不同的团队，甚至是我目前工作的公司在处理这个问题时采取的各种方式。
我看到的情况有：
1. 将原始的GitHub变更日志直接粘贴到客户邮件中（如果您现在这样做，我强烈不推荐）
2. 针对每个受众手动多次重写相同的更新
3. 完全跳过发布说明，因为这工作量太大
所以我想问的是：您或您的公司目前是如何处理多套发布说明的？您觉得是否需要多套发布说明？
我很想听听您有效（或无效）的做法，以及您是否找到过任何可以帮助解决这个问题的工具。
大家好！我们是 BrowserBook 的 Chris、Jorrie 和 Evan，这是一个用于编写和调试基于 Playwright 的网页自动化的集成开发环境（IDE）。您可以在这里下载 Mac 应用程序：<a href="https://browserbook.com">https://browserbook.com</a>，还有一个演示视频可以在这里观看：<a href="https://www.youtube.com/watch?v=ODGJBCNqGUI" rel="nofollow">https://www.youtube.com/watch?v=ODGJBCNqGUI</a>。
<p>我们为什么要开发这个工具：在我们参加 YC 的时候，我们是一家自动化后端医疗工作流程的公司。由于医疗行业的互操作性生态系统非常分散，我们开始使用浏览器代理直接通过网络自动化电子病历、诊所管理软件和支付门户。当我们这样做时，遇到了很多问题：
<p>速度：与脚本方法相比，LLM 调用的高延迟。
<p>成本：为了使自动化尽可能准确，我们消耗了大量的令牌来提供所需的上下文。
<p>可靠性：即使有详细的指示、上下文和工具，代理在多步骤任务中往往会以不可预测的方式偏离。
<p>可调试性：当出现偏差时，我们基本上是在提示中玩打地鼠，并重新运行整个自动化来调试问题（如上所述：速度和成本问题使得这一过程相当痛苦）。
<p>我们越来越多地只是给我们的代理脚本来执行。最终，我们得出结论，对于这类用例，脚本化是一种更好的网页自动化方法。但脚本化也太痛苦了，因此我们着手用 BrowserBook 来解决这些问题。
<p>在技术层面上，它运行一个独立的 TypeScript REPL，直接与内嵌的浏览器实例连接，并内置工具，使脚本开发快速而简单。这包括：
<p>- 在 IDE 中直接提供一个完全交互的浏览器窗口，您可以在不切换上下文的情况下运行代码。
<p>- 类似 Jupyter Notebook 的环境——这里的想法是，您可以在单独的单元中编写自动化的部分并单独运行它们（并可以在浏览器中快速手动重置），而不必每次都重新运行整个流程。
<p>- 一个 AI 编码助手，利用当前页面的 DOM 上下文来编写自动化逻辑，帮助避免寻找选择器的麻烦。
<p>- 用于截图、数据提取和管理身份验证的辅助函数，适用于需要身份验证的工作流程。
<p>一旦您创建了自动化，可以直接在应用程序中运行它，或者通过 API 在我们的托管环境中运行，以便在外部应用程序或代理工作流程中使用。
<p>BrowserBook 的核心是一个 Electron 应用，因此我们可以直接在应用中运行 Chrome 实例，而无需依赖云托管的浏览器。对于 API 运行，我们通过 Kernel 使用托管的浏览器基础设施（顺便说一下，这是一个很棒的产品），依赖于他们的反机器人检测能力（隐身模式、代理等）。
<p>脚本化自动化可能不受欢迎，因为脚本本质上是脆弱的；与“传统”软件开发不同，您的代码是在您无法控制的环境中部署的——别人的网站。通过 BrowserBook，我们试图“接受这种不完美”，并承认这种“进攻性编程”的环境。
<p>我们从头开始设计，假设脚本会出错，并旨在提供使构建和维护它们更容易的工具。未来，我们的计划是利用 AI 在其已经显示出优势的领域——编写代码——来最小化停机时间，并在部署环境变化时快速修复损坏的脚本。
<p>浏览器代理承诺通过将控制权交给可以处理不一致性和模糊性的 LLM 来解决这个问题。虽然我们认为在某些应用中浏览器代理确实可以提供帮助，但需要可靠和重复执行的任务并不在其中。
<p>我们希望您能试用一下！您可以在我们的网站上下载 BrowserBook：<a href="https://browserbook.com">https://browserbook.com</a>（目前仅支持 Mac，抱歉！）当然，我们也非常欢迎您提供任何反馈和意见！