In addition to reading laid-out documents, the most popular purposes for PDFs are forms and annotation. As far as filling in PDF forms are concerned, I have just one word to say: Fillably, Joel Norvell’s outstanding app available from the App Store, which transforms Preview into the ideal platform for tax and other forms. Rather than struggling with the tangle of tools in a general PDF editor, Fillably provides the perfect suite for creating PDF forms.

Annotating PDFs is more complicated, though.

Encoding annotations

Annotations aren’t an afterthought, but a central part of PDF. All PDF documents consist of a list of hundreds or thousands of objects of different types, including annotations of the Annot type, and those are listed in one of the file’s standard dictionaries, its Annotations Dictionary, Annots.

There are at least 27 sub-types of Annot, including Caret, Highlight and Stamp, which are reflected in the annotation tools provided by apps from Acrobat to Preview. Seemingly complex annotations like popup notes are straightforward to code in PDF, requiring just two linked objects, one for the popup and its text, the other to specify its placement on the page. Others are more involved, as they can extend to include file attachments, sound, movie and other multimedia.

PDF versions

Despite their original simplicity, there are multiple problems that can arise with annotations.

With more recent versions of PDF, the ways in which they can be coded has increased. Mark up a PDF using the latest versions of Adobe Acrobat Reader or its ‘Pro’ CC colleague and they’ll cast it in PDF-1.6 and you’re unlikely to see a single Annot in their source. Most apps built on the Quartz PDF engine should write their files in PDF-1.3 so they can be accessed more widely, and should use regular Annot sub-types throughout. However, Preview likes to use opaque AAPL:AKAnnotationObjects that you won’t encounter anywhere else.

What Quartz does is to ‘flatten’ each PDF into a common 1.3 format for rendering, and that can be saved to disk. At present, that seems to work faithfully, but might give the impression that macOS can’t render more recent versions of PDF, which isn’t true. You can demonstrate that by opening an Acrobat PDF-1.6 document using an app that relies on the Quartz engine, such as PDF Expert, Preview or my Podofyllin, and comparing that with the original in Acrobat.

Podofyllin has a convenient feature for doing just that, in its source window. The uppermost of its three views displays Quartz ‘flattened’ code in PDF-1.3, the middle shows the original, here in PDF-1.6, and the lowermost is a summary of the latter.

Hidden annotations

The biggest dangers with annotations arise because of PDF’s ancient origins and a file format that doesn’t make sufficiently clear distinction between data and metadata. All annotations are metadata added to the underlying document, but in PDF, objects for each are mixed freely within the source. When they’re clearly distinguished with the Annot type, they should be easy to remove as a group, and PDF Expert offers that as a convenient command. That’s ideal when a document has been developed with the aid of reviewers’ annotations, to prepare the finished version for release.

Unfortunately this can cause its own problems, as PDF source is notorious for retaining old content that’s no longer visible in the rendered document, but can be read by anyone with a little knowledge about PDF. Like incomplete redactions, such hidden annotations have caused many embarrassments in the past, and will continue to catch folk out.

Preview’s bugs

Finally, Preview has had more than its fair share of bugs in handling PDF annotations. During my research for this article, Preview 11.0 (1069.7.1) in macOS 15.6 was generally well behaved, but did mangle comments added to a test document by PDF Expert and Adobe Acrobat. Preview has two behaviours that can appear disconcerting: that of its Highlights and Notes tool, and its use of versioning.

All Preview’s tools are single-shot apart from Highlights and Notes, the drawing pencil icon to the left of its popup menu. Click this once to apply highlighting to selected blocks of text, and to remove existing highlighted sections. Unfortunately when this tool is turned on, its own highlighting is so weak that it’s hard to see.

Overwritten files

Preview has a habit of saving PDF documents automatically when closing them, without any warning. If it has just mutilated an annotation, for example, you might assume the original file has just been overwritten and lost. However, Preview saves PDFs using the macOS document versioning system, so you can always recover the previous version.

This might at first seem an impossible task: use Preview to restore that old version and it will repeat its mutilation, defeating the purpose. Yet the original PDF editor won’t have access to previous versions, as it doesn’t use the versioning system. The solution is to use Revisionist, or Versatility, which can save the original as a separate document.

Key points

• Annotations are a central feature of PDF, come in many sub-types, and can be complicated as they can be expressed in different ways.
• The macOS Quartz PDF engine transforms them into PDF-1.3, which makes them simpler and more explicit, so they can be saved ‘flattened’.
• PDF format mixes document data with metadata and annotations.
• Few PDF editors offer to remove all annotations, and there’s a risk of some remaining hidden from view, but still remaining in the PDF source, potentially causing embarrassment when they’re discovered.
• Preview’s earlier bugs in annotations have improved, but it can still mutilate those made by other PDF editors.
• If Preview saves a mutilated PDF, you should be able to recover the previous version of that file using Revisionist or Versatility.

According to scientific tradition, we first observe then experiment. If you proceed to the latter before you understand how a system behaves, then you’re likely to labour under misapprehensions and your trials can become tribulations. Only when a system is thoroughly opaque and mysterious can we risk attempting both together.

That’s the case for Spotlight, which despite its name does everything but shine any light on its mechanisms. It presents itself in several guises, as a combination of web and local search (), as local search using terms limited in their logical operators (Finder’s Find), as full-blown predicate-based local search (mdfind), as in-app file search (Core Spotlight), and the coder’s NSMetadataQuery and predicates. It relies on indexes scattered across hundreds of binary files, and runs multiple processes, while writing next to nothing in the log.

Last week’s code-doodling has been devoted to turning the Spotlight features in Mints into a separate app, SpotTest, so I can extend them to allow testing of different volumes, and search for text that has been derived from images. Those are proving thorny because of Spotlight’s unpredictable behaviour across different Macs running Sequoia.

Every week I search for screenshots to illustrate another article on Mac history. When using my old iMac Pro where most of them are stored, Spotlight will find many images containing search terms from the text shown within them, even from ancient QuickDraw PICT images, demonstrating that text is being recovered using Live Text’s optical character recognition. When I try to repeat this using test images on an Apple silicon Mac, Spotlight seems unable to recognise any such recovered text.

Image analysis on Macs has a stormy history. In a well-intentioned gaffe four years ago, Apple shocked us when it declared it was intending to check our images for CSAM content. Although it eventually dropped that idea, there have been rumours ever since about our Macs secretly looking through our images and reporting back to Apple. It didn’t help that at the same time Apple announced Live Text as one of the new features of macOS Monterey, and brought further image analysis in Visual Look Up.

Although I looked at this in detail, it’s hard to prove a negative, and every so often I’m confronted by someone who remains convinced that Apple is monitoring the images on their Mac. I was thus dragged back to reconsider it in macOS Sonoma. What I didn’t consider at that time was how text derived from Live Text and image analysis found its way into Spotlight’s indexes, which forms part of my quest in SpotTest.

This doesn’t of course apply to images in PDF documents. When I looked at those, I concluded: “If you have PDF documents that have been assembled from scans or other images without undergoing any form of text recognition, then macOS currently can’t index any text that you may still be able to extract using Live Text. If you want to make the text content of a PDF document searchable, then you must ensure that it contains its own text content.” I reiterated that in a later overview.

My old images aren’t PDFs but QuickDraw PICTs, TIFFs, PNGs and JPEGs, many from more than 20 years ago. When the circumstances are right, macOS quietly runs Live Text over them and stores any text it recovers in Spotlight’s indexes. It also analyses each image for recognisable objects, and adds those too. These happen more slowly than regular content indexing by mdworker, some considerable time after the image has been created, and have nothing whatsoever to do with our viewing those images in QuickLook or the Finder, or even using Live Text or Visual Look Up ourselves.

There are deeper problems to come. Among them is discovering the results of image recognition as can be revealed in the command line using a search such as
mdfind "(** == 'cattle*'cdw) && (kMDItemContentTypeTree == 'public.image'cd)"
to discover all images that have been recognised as containing cattle. There’s no equivalent of the first part of that when calling NSMetadataQuery from Swift code, and a predicate of
kMDItemTextContent CONTAINS[cd] \"cattle\"
will only discover text recovered by Live Text, not the names of objects recognised within an image.

What started as a quick doodle is now bogged down in the quirks of Spotlight, which defies the scientific method. Perhaps it’s time for a little sorcery.

To make its graphical interface work, the Mac needed a high-performance graphics system, for which the late Bill Atkinson (1951-2025) and Andy Hertzfeld designed and implemented QuickDraw. When it came to driving printers, though, Steve Jobs licensed the new page description language PostScript from Adobe, where it had just been developed by John Warnock (1940-2023), Charles Geschke (1939-2021) and others. PostScript is a stack-based interpreted language that could take many seconds or even minutes to image a page for printing, so wasn’t practical for doing much else at that time.

In the early 1990s, as desktop publishing became dominant among Mac users and we were all sending one another faxes, several companies recognised the need for a universal document format that could display laid-out text and graphics. Among them was Adobe, where Warnock formulated the aims of what he then referred to as Interchange PostScript or IPS, and so led the development of Portable Document Format. It’s telling that the final sentence of his proposal reads: “In any event corporations should be interested in site-licensing arrangements.”

When the first version of PDF was released in 1993, with its Carousel reader app, it faced competition from other similar ideas, and Adobe found itself competing against products including Farallon’s Replica, and Tumbleweed’s Envoy that gained the support of WordPerfect, then a popular cross-platform word processor. PDF didn’t become dominant until Adobe distributed its reader app free, rather than charging $50 for it as it had initially.

For many years, the only way to create really good PDFs was using Adobe’s Acrobat Distiller app, costing $695 for a single-user licence. That ingested PostScript files, created on the Mac by printing to a file, and transformed them into PDFs that could in turn only be read using Adobe’s software. Although PostScript was by then a prerequisite for all publishing work on Macs, it wasn’t until 1996, when PDF reached version 1.2 in Acrobat 3.0, that it captured the prepress market, which it consolidated in 1998 with the PDF/X-1 standard.

This is Acrobat Distiller 4.0 running on Mac OS 9.1 in early 2001, showing a few of its bewildering array of options for turning PostScript files into PDF.

At the same time, John Warnock’s aspirations for success in enterprise markets were being realised, and PDF steadily became the standard for fixed-format electronic documents, with the support of the US Internal Revenue Service and Adobe’s free cross-platform Acrobat Reader.

When Steve Jobs established NeXT in 1985 he must have become the only person to have licensed PostScript from Adobe twice, as NeXTSTEP adopted Display PostScript as the centrepiece of its graphics, developed collaboratively between NeXT and Adobe. At the time many thought this to be a mistake, as PostScript isn’t as efficient a graphics language as QuickDraw, despite Adobe’s efforts to accelerate it.

When NeXT and Mac merged to form the beginnings of Mac OS X in 1997, Display PostScript was replaced with PDF as the central graphics standard for both display and printing, in what was dubbed Quartz 2D. This was first demonstrated at WWDC in 1999 and lives on today in macOS. At the time, Apple’s in-house PDF engine in Quartz was one of few, alongside Adobe’s.

Prior to Mac OS X, Adobe Acrobat, both in its free viewer form and a paid-for Pro version, had been the de facto standard for reading, printing and working with PDF documents on the Mac. The Preview app had originated in NeXTSTEP in 1989 as its image and PDF viewer, and was brought across to early versions of Mac OS X, where it has remained ever since.

This PDF shows Apple’s original iPod promotional literature from late 2001.

Adobe continued providing its free Acrobat Reader for Mac OS X, here seen in 10.0 Cheetah.

The full paid-for version of Adobe Acrobat provided an extensive suite of editing tools, here in Mac OS X 10.1 Puma in early 2002.

By Mac OS X 10.3 Panther in 2003, Apple was claiming that Preview was “the fastest PDF viewer on the planet”, capable of navigating and searching text within PDF documents “at lightning speed”. This worked with the Mac’s new built-in support for faxing, which rendered received faxes in PDF to make them easier and clearer to access.

This is an early Keynote Quick Reference guide from 2003, viewed in Preview.

At that time, Preview was also able to convert Encapsulated PostScript (EPS) files and raw PostScript to PDF, so they could be saved in the more accessible format, and printed easily.

This page from the 9/11 Commission Report of 22 July 2004 is being viewed in Preview.

Acrobat Distiller remained an important component in Adobe’s paid-for product, even though Mac OS X was capable of generating its own PDFs. It’s seen here in Mac OS X 10.4 Tiger in 2005.

This is Acrobat Pro in 10.4 Tiger in early 2006, showing its long list of supported export formats.

Since those heady days, Preview has been relatively neglected. Revision of both the Quartz PDF engine and its API brought a spate of bugs that only abated with macOS Sierra. Preview has adopted an uncommon model for PDF annotations that often doesn’t work well with other PDF products, but it has remained very popular for completing electronic forms. Then, in macOS Ventura, Apple removed all support for converting EPS and PostScript to PDF, most probably as a result of security concerns, and their progressive disuse.

Although rumours of the death of Preview continue to prove unfounded, it’s unlikely to feature again as one of the strengths of macOS.

References

John Warnock (1991) The Camelot Project, on the Internet Archive’s Wayback machine.
Laurens Leurs’ The history of PDF.

我们还年轻，可不想看到这个世界处在毫无自由、隐私的边缘。

Anthropic 的内部团队正在利用 Claude Code 彻底改变他们的工作流程。无论是开发者还是非技术人员，都能借助它攻克复杂项目、实现任务自动化，并弥补那些曾经限制生产力的技能鸿沟。

为了深入了解，我们采访了以下团队：

通过这些访谈，我们收集了不同部门使用 Claude Code 的方式、它对工作带来的影响，以及为其他考虑采用该工具的组织提供的宝贵建议。

数据基础设施团队负责为公司内所有团队整理业务数据。他们使用 Claude Code 来自动化常规的数据工程任务、解决复杂的基础设施问题，并为技术和非技术团队成员创建文档化工作流，以便他们能够独立访问和操作数据。

利用截图调试 Kubernetes

当 Kubernetes 集群出现故障，无法调度新的 pod 时，团队使用 Claude Code 来诊断问题。他们将仪表盘的截图喂给 Claude Code，后者引导他们逐个菜单地浏览 Google Cloud 的用户界面，直到找到一个警告，指出 pod 的 IP 地址已耗尽。随后，Claude Code 提供了创建新 IP 池并将其添加到集群的确切命令，整个过程无需网络专家的介入。

为财务团队打造纯文本工作流

工程师向财务团队成员展示了如何编写描述其数据工作流程的纯文本文件，然后将这些文件加载到 Claude Code 中，以实现完全自动化的执行。没有任何编程经验的员工只需描述“查询这个仪表盘，获取信息，运行这些查询，生成 Excel 输出”等步骤，Claude Code 就能执行整个工作流，甚至会主动询问日期等必要输入。

为新员工提供代码库导览

当新的数据科学家加入团队时，他们会被指导使用 Claude Code 来熟悉庞大的代码库。Claude Code 会阅读他们的 Claude.md 文件（文档），识别特定任务所需的相关文件，解释数据管道的依赖关系，并帮助新人理解哪些上游数据源为仪表盘提供数据。这取代了传统的数据目录和发现工具。

会话结束时自动更新文档

在每项任务结束时，团队会要求 Claude Code 总结已完成的工作并提出改进建议。这创建了一个持续改进的循环：Claude Code 根据实际使用情况帮助优化 Claude.md 文档和工作流指令，使后续的迭代更加高效。

跨多个实例并行管理任务

在处理耗时较长的数据任务时，团队会为不同项目在不同的代码仓库中打开多个 Claude Code 实例。每个实例都能保持完整的上下文，因此即使在数小时或数天后切换回来，Claude Code 也能准确地记住他们当时正在做什么以及任务进行到哪里，从而实现了无上下文丢失的真正并行工作流管理。

无需专业知识即可解决基础设施问题

解决了通常需要系统或网络团队成员介入的 Kubernetes 集群问题，利用 Claude Code 诊断问题并提供精确的修复方案。

加速新员工上手

新的数据分析师和团队成员无需大量指导，就能迅速理解复杂的系统并做出有意义的贡献。

增强支持工作流

Claude Code 能够处理比人类手动审查大得多的数据量，并识别异常情况（例如监控 200 个仪表盘），这是人力无法完成的。

实现跨团队自助服务

没有任何编程经验的财务团队现在可以独立执行复杂的数据工作流。

编写详细的 Claude.md 文件

团队表示，你在 Claude.md 文件中将工作流程、工具和期望文档化得越好，Claude Code 的表现就越出色。当你拥有现成的设计模式时，这使得 Claude Code 在设置新数据管道等常规任务上表现卓越。

处理敏感数据时使用 MCP 服务器而非命令行界面

他们建议使用 MCP 服务器而不是 BigQuery 命令行界面，以便更好地控制 Claude Code 的访问权限，尤其是在处理需要日志记录或存在潜在隐私问题的敏感数据时。

分享团队使用心得

团队举办了分享会，成员们互相演示他们使用 Claude Code 的工作流程。这有助于传播最佳实践，并展示了他们自己可能没有发现的各种工具使用方法。

Claude Code 产品开发团队使用自家的产品来为 Claude Code 构建更新，扩展产品的企业级功能和 AI 智能体循环功能。

通过“自动接受模式”快速构建原型

工程师们通过启用“自动接受模式”（Shift+Tab）并设置自主循环，让 Claude 编写代码、运行测试并持续迭代，从而实现快速原型开发。他们将自己不熟悉的抽象问题交给 Claude，让它自主工作，然后在接手进行最后润色前，审查已完成 80% 的解决方案。团队建议从一个干净的 git 状态开始，并定期提交检查点，这样如果 Claude 跑偏了，他们可以轻松回滚任何不正确的更改。

同步编码开发核心功能

对于涉及应用程序业务逻辑的更关键功能，团队会与 Claude Code 同步工作，提供带有具体实现指令的详细提示。他们实时监控过程，确保代码质量、风格指南合规性和正确的架构，同时让 Claude 处理重复的编码工作。

构建 Vim 模式

他们最成功的异步项目之一是为 Claude Code 实现 Vim 快捷键绑定。他们要求 Claude 构建整个功能，最终实现中大约 70% 的代码来自 Claude 的自主工作，只需几次迭代即可完成。

生成测试和修复 bug

在实现功能后，团队使用 Claude Code 编写全面的测试，并处理在代码审查中发现的简单 bug。他们还使用 GitHub Actions 让 Claude 自动处理像格式问题或函数重命名这样的 Pull Request 评论。

代码库探索

在处理不熟悉的代码库（如 monorepo 或 API 端）时，团队使用 Claude Code 来快速理解系统的工作方式。他们不再等待 Slack 上的回复，而是直接向 Claude 提问以获取解释和代码参考，从而大大节省了上下文切换的时间。

更快的功能实现

Claude Code 成功实现了像 Vim 模式这样的复杂功能，其中 70% 的代码由 Claude 自主编写。

提升开发速度

该工具可以快速构建功能原型并迭代创意，而不会陷入实现细节的泥潭。

通过自动化测试提高代码质量

Claude 生成全面的测试并处理常规的 bug 修复，在减少手动工作的同时保持了高标准。

更好的代码库探索

团队成员可以快速熟悉 monorepo 中不熟悉的部分，而无需等待同事的回复。

创建自给自足的循环

设置 Claude 通过自动运行构建、测试和代码检查来验证自己的工作。这使得 Claude 可以更长时间地自主工作并发现自己的错误，尤其是在你要求 Claude 在编写代码之前先生成测试时效果更佳。

培养任务分类的直觉

学会区分哪些任务适合异步处理（外围功能、原型设计），哪些需要同步监督（核心业务逻辑、关键修复）。产品边缘的抽象任务可以用“自动接受模式”处理，而核心功能则需要更密切的监督。

编写清晰、详细的提示

当组件具有相似的名称或功能时，你的请求要极其具体。提示越好、越详细，你就越能信任 Claude 独立工作，而不会对代码库的错误部分进行意外更改。

安全工程团队专注于保障软件开发生命周期、供应链安全和开发环境安全。他们广泛使用 Claude Code 来编写和调试代码。

复杂基础设施调试

在处理事故时，他们将堆栈跟踪和文档喂给 Claude Code，并要求它在代码库中追踪控制流。这大大缩短了生产问题的解决时间，使他们能够在大约 5 分钟内理解问题，而手动扫描代码通常需要 10-15 分钟。

Terraform 代码审查与分析

对于需要安全审批的基础设施变更，团队将 Terraform 计划复制到 Claude Code 中，并提问“这会做什么？我会后悔吗？”。这创建了更紧密的反馈循环，使安全团队能够更快地审查和批准基础设施变更，减少了开发过程中的瓶颈。

文档综合与操作手册

Claude Code 吸收多个文档来源，创建 Markdown 格式的操作手册、故障排除指南和概述。团队将这些精简的文档作为调试实际问题的上下文，创建了比在完整知识库中搜索更高效的工作流程。

测试驱动开发工作流

他们摒弃了以往的“设计文档 → 粗糙代码 → 重构 → 放弃测试”模式，现在他们要求 Claude Code 提供伪代码，引导其进行测试驱动开发，并定期检查以在卡住时进行引导，从而产出更可靠、更易于测试的代码。

上下文切换与项目上手

在为现有项目（如用于安全审批工作流的 Web 应用“dependant”）做贡献时，他们使用 Claude Code 来编写、审查和执行存储在代码库中的 Markdown 格式的规范，从而能够在几天内做出有意义的贡献，而不是花费数周时间。

缩短事故解决时间

通常需要 10-15 分钟手动代码扫描的基础设施调试现在大约需要 5 分钟。

改进安全审查周期

需要安全审批的 Terraform 代码审查速度大大加快，消除了开发人员在等待安全团队批准时的阻塞。

增强跨职能贡献

团队成员可以在几天内为项目做出有意义的贡献，而不是花费数周时间来建立上下文。

更好的文档工作流程

从多个来源综合而成的故障排除指南和操作手册创建了更高效的调试过程。

广泛使用自定义斜杠命令

安全工程团队使用了整个 monorepo 中 50% 的自定义斜杠命令实现。这些自定义命令简化了特定的工作流程，并加快了重复性任务的速度。

让 Claude 先说

他们不再通过提出有针对性的问题来生成代码片段，而是告诉 Claude Code “边做边提交你的工作”，让它在定期检查的情况下自主工作，从而得到更全面的解决方案。

利用它进行文档处理

除了编码，Claude Code 还擅长综合文档和创建结构化输出。团队提供写作样本和格式偏好，以获得可立即在 Slack、Google Docs 和其他工具中使用的文档，避免界面切换带来的疲劳。

推理团队负责管理在 Claude 读取你的提示并生成回复时存储信息的内存系统。团队成员，尤其是那些刚接触机器学习的人，可以广泛使用 Claude Code 来弥补知识差距并加速他们的工作。

代码库理解与新员工上手

在加入一个复杂的代码库时，团队严重依赖 Claude Code 来快速理解其架构。他们不再手动搜索 GitHub 仓库，而是询问 Claude 哪些文件调用了特定的功能，几秒钟内就能得到结果，而不是向同事求助或手动搜索。

包含边界情况的单元测试生成

在编写完核心功能后，他们要求 Claude 为其编写全面的单元测试。Claude 会自动包含被遗漏的边界情况，在几分钟内完成通常需要大量时间和精力的工作，就像一个他们可以审查的编码助手。

机器学习概念解释

没有机器学习背景的团队成员依赖 Claude 来解释模型特定的函数和设置。过去需要一个小时谷歌搜索和阅读文档的工作，现在只需 10-20 分钟，研究时间减少了 80%。

跨语言代码翻译

在用不同编程语言测试功能时，团队向 Claude 解释他们想要测试的内容，Claude 就会用所需的语言（如 Rust）编写逻辑，从而无需为了测试目的而学习新语言。

命令记忆与 Kubernetes 管理

他们不再需要记住复杂的 Kubernetes 命令，而是向 Claude 询问正确的语法，比如“如何获取所有 pod 或部署状态”，然后就能收到他们基础设施工作所需的确切命令。

加速机器学习概念学习

有了 Claude Code，他们的研究时间减少了 80%，历史上需要一个小时谷歌搜索的工作现在只需 10-20 分钟。

更快的代码库导航

该工具可以帮助团队成员在几秒钟内找到相关文件并理解系统架构，而不是依赖同事在几天内分享知识。

全面的测试覆盖

Claude 自动生成包含边界情况的单元测试，在保持代码质量的同时减轻了精神负担。

消除语言障碍

团队可以在不熟悉 Rust 等语言的情况下实现功能，而无需学习它。

首先测试知识库功能

尝试问各种问题，看看 Claude 能否比谷歌搜索更快地回答。如果它更快、更准确，那么它就是你工作流程中一个宝贵的时间节省工具。

从代码生成开始

给 Claude 具体的指令，让它编写逻辑，然后验证其正确性。这有助于在将其用于更复杂的任务之前，建立对该工具能力的信任。

用它来编写测试

让 Claude 编写单元测试可以极大地减轻日常开发工作的压力。利用这个功能来保持代码质量，而无需花费时间手动思考所有测试用例。

数据科学和机器学习工程团队需要复杂的 可视化工具来理解模型性能，但构建这些工具通常需要不熟悉的语言和框架的专业知识。Claude Code 使这些团队能够构建生产质量的分析仪表盘，而无需成为全栈开发人员。

构建 JavaScript/TypeScript 仪表盘应用

尽管对“JavaScript 和 TypeScript 知之甚少”，团队仍使用 Claude Code 构建了完整的 React 应用，用于可视化强化学习（RL）模型的性能和训练数据。他们让 Claude 控制从头开始编写完整的应用程序，比如一个 5000 行的 TypeScript 应用，而无需自己理解代码。这一点至关重要，因为可视化应用相对上下文较少，不需要理解整个 monorepo，从而可以快速构建原型工具，以便在训练和评估期间了解模型性能。

处理重复的重构任务

当遇到合并冲突或半复杂的文件重构时——这些任务对于编辑器宏来说太复杂，但又不足以投入大量开发精力——他们就像玩“老虎机”一样使用 Claude Code：提交当前状态，让 Claude 自主工作 30 分钟，然后要么接受解决方案，要么在不成功时重新开始。

创建持久性分析工具而非一次性笔记本

团队现在不再构建用完即弃的 Jupyter 笔记本，而是让 Claude 构建可重复使用的 React 仪表盘，这些仪表盘可以在未来的模型评估中重复使用。这很重要，因为理解 Claude 的性能是“团队最重要的事情之一”——他们需要了解模型在训练和评估期间的表现，而这“实际上并非易事，简单的工具无法从观察一个数字上升中获得太多信号”。

零依赖任务委托

对于完全不熟悉的代码库或语言中的任务，他们将整个实现委托给 Claude Code，利用其从 monorepo 中收集上下文并执行任务的能力，而无需他们参与实际的编码过程。这使得他们在自己专业领域之外也能保持生产力，而不是花时间学习新技术。

节省了 2-4 倍的时间

过去虽然可以手动完成但很繁琐的常规重构任务现在完成得更快了。

用不熟悉的语言构建了复杂的应用

尽管 JavaScript/TypeScript 经验极少，却创建了 5000 行的 TypeScript 应用。

从一次性工具转向持久性工具

不再使用一次性的 Jupyter 笔记本，而是构建可复用的 React 仪表盘进行模型分析。

直接获得模型改进的洞见

第一手使用 Claude Code 的经验为未来模型迭代中更好的内存系统和用户体验改进提供了信息。

实现了可视化驱动的决策

通过先进的数据可视化工具，更好地理解了 Claude 在训练和评估期间的性能。

把它当作一台老虎机

在让 Claude 工作之前保存你的状态，让它运行 30 分钟，然后要么接受结果，要么重新开始，而不是试图费力去修正。重新开始的成功率通常比试图修复 Claude 的错误要高。

必要时为了简化而打断它

在监督过程中，不要犹豫，停下来问 Claude “你为什么这么做？试试更简单的方法。” 模型默认倾向于更复杂的解决方案，但对于简化方法的请求反应良好。

产品工程团队致力于开发如 PDF 支持、引用和网页搜索等功能，这些功能将额外的知识引入 Claude 的上下文窗口。在大型、复杂的代码库中工作意味着不断遇到不熟悉的代码部分，花费大量时间来理解特定任务需要检查哪些文件，并在进行更改前建立上下文。Claude Code 通过充当向导，帮助他们理解系统架构、识别相关文件并解释复杂的交互，从而改善了这种体验。

第一步工作流规划

团队将 Claude Code 作为任何任务的“第一站”，要求它确定在进行 bug 修复、功能开发或分析时需要检查哪些文件。这取代了传统上在开始工作前手动浏览代码库和收集上下文的耗时过程。

跨代码库独立调试

团队现在有信心处理不熟悉代码库部分的 bug，而无需向他人求助。他们可以问 Claude “你觉得你能修复这个 bug 吗？我看到的行为是这样的”，并经常能立即取得进展，这在以前由于所需的时间投入是不可行的。

通过内部测试进行模型迭代测试

Claude Code 自动使用最新的研究模型快照，使其成为他们体验模型变化的主要方式。这为团队在开发周期中提供了关于模型行为变化的直接反馈，这是他们在之前的发布中从未体验过的。

消除上下文切换的开销

他们不再需要复制粘贴代码片段并将文件拖入 Claude.ai，同时还要详细解释问题，现在可以直接在 Claude Code 中提问，无需额外的上下文收集，从而显著减少了心智负担。

增强了处理不熟悉领域的信心

团队成员可以独立调试 bug 并调查不熟悉代码库中的事故。

在上下文收集中节省了大量时间

Claude Code 消除了复制粘贴代码片段和将文件拖入 Claude.ai 的开销，减轻了心智上的上下文切换负担。

加速轮岗员工上手速度

轮岗到新团队的工程师可以快速熟悉不熟悉的代码库并做出有意义的贡献，而无需与同事进行大量咨询。

提升开发者幸福感

团队报告称，随着日常工作流程中的摩擦减少，他们感到更快乐、更高效。

将其视为迭代伙伴，而非一次性解决方案

不要指望 Claude 能立即解决问题，而是把它当作一个与你一起迭代的合作者。这种方法比试图在第一次尝试中就获得完美的解决方案效果更好。

用它来建立在不熟悉领域的信心

不要犹豫去处理你专业领域之外的 bug 或调查事故。Claude Code 使得在通常需要大量上下文建立的领域独立工作成为可能。

从最少的信息开始

从你需要的最低限度的信息开始，让 Claude 引导你完成整个过程，而不是一开始就提供大量的解释。

增长营销团队专注于在付费搜索、付费社交、移动应用商店、电子邮件营销和 SEO 等领域建立效果营销渠道。作为一个只有一人的非技术团队，他们使用 Claude Code 来自动化重复性的营销任务，并创建通常需要大量工程资源的 AI 智能体工作流。

自动化 Google Ads 广告创意生成

团队构建了一个 AI 智能体工作流，该工作流可以处理包含数百个现有广告及其效果指标的 CSV 文件，识别表现不佳的广告进行迭代，并生成符合严格字符限制（标题 30 个字符，描述 90 个字符）的新变体。通过使用两个专门的子智能体（一个用于标题，一个用于描述），该系统可以在几分钟内生成数百个新广告，而无需在多个广告系列中手动创建。这使他们能够大规模地进行测试和迭代，这是以前需要花费大量时间才能实现的。

用于批量创意制作的 Figma 插件

他们没有手动复制和编辑用于付费社交广告的静态图片，而是开发了一个 Figma 插件，该插件可以识别框架并通过替换标题和描述来以编程方式生成多达 100 个广告变体，将需要数小时复制粘贴的工作缩短为每批半秒。这使得创意产出提高了 10 倍，让团队能够在关键社交渠道上测试数量庞大的创意变体。

用于广告活动分析的 Meta Ads MCP 服务器

他们创建了一个与 Meta Ads API 集成的 MCP 服务器，以便直接在 Claude Desktop 应用内查询广告活动表现、支出数据和广告效果，从而无需在不同平台之间切换进行性能分析，节省了宝贵的时间，因为每一分效率的提升都意味着更好的投资回报率。

利用内存系统进行高级提示工程

他们实现了一个基本的内存系统，该系统记录了广告迭代中的假设和实验，使得系统在生成新变体时能够将之前的测试结果纳入上下文，创建了一个自我改进的测试框架。这使得系统性的实验成为可能，而这些实验是无法手动追踪的。

在重复性任务上节省了大量时间

Claude Code 将广告文案创作时间从 2 小时缩短到 15 分钟，让团队能够专注于更具战略性的工作。

创意产出增加 10 倍

通过自动广告生成和与 Figma 集成以获取最新的视觉设计元素，团队现在可以在各个渠道上测试数量庞大的广告变体。

像一个更大的团队一样运作

团队能够处理传统上需要专门工程资源的大型开发任务。

战略重点转移

团队可以将更多时间用于整体战略和构建 AI 智能体自动化，而不是手动执行。

识别支持 API 的重复性任务

寻找涉及使用带有 API 的工具（如广告平台、设计工具、分析平台）进行重复操作的工作流程。这些是自动化的主要候选对象，也是 Claude Code 提供最大价值的地方。

将复杂工作流分解为专门的子智能体

不要试图在一个提示或工作流中处理所有事情，而是为特定任务创建单独的智能体（比如一个标题智能体和一个描述智能体）。这使得调试更容易，并在处理复杂需求时提高输出质量。

在编码前进行充分的头脑风暴和提示规划

在前期花大量时间使用 Claude.ai 来构思整个工作流，然后让 Claude.ai 为 Claude Code 创建一个全面的提示和代码结构以供参考。此外，要逐步进行，而不是要求一次性解决问题，以避免 Claude 因任务过于复杂而不堪重负。

产品设计团队支持 Claude Code、Claude.ai 和 Anthropic API，专注于构建 AI 产品。即使是非开发人员也可以使用 Claude Code 来弥合设计与工程之间的传统鸿沟，使他们能够直接实现自己的设计愿景，而无需与工程师进行大量的反复迭代。

前端润色和状态管理变更

团队不再为视觉调整（字体、颜色、间距）创建大量的设计文档并与工程师进行多轮反馈，而是直接使用 Claude Code 实现这些变更。工程师们注意到，设计师们正在进行“通常不会看到设计师做的大型状态管理变更”，这使他们能够实现他们所设想的精确质量。

GitHub Actions 自动化工单处理

通过使用 Claude Code 的 GitHub 集成，他们只需提交描述所需更改的问题/工单，Claude 就会自动提出代码解决方案，而无需打开 Claude Code，从而为他们积压的润色任务创建了一个无缝的 bug 修复和功能优化工作流。

快速交互式原型制作

通过将模型图粘贴到 Claude Code 中，他们可以生成功能齐全的原型，工程师可以立即理解并在此基础上进行迭代，这取代了传统的静态 Figma 设计，后者需要大量的解释和转换才能成为可用代码。

发现边界情况和理解系统架构

团队使用 Claude Code 来规划错误状态、逻辑流程和不同的系统状态，使他们能够在设计阶段就识别出边界情况，而不是在开发后期才发现，从而从根本上提高了他们初始设计的质量。

复杂的文案更改和法律合规

对于像在整个代码库中移除“研究预览”信息这样的任务，他们使用 Claude Code 查找所有实例，审查周围的文案，与法务部门实时协调更改，并实施更新。这个过程只用了两次 30 分钟的电话会议，而不是一周的反复协调。

核心工作流程的变革

Claude Code 成为主要的设计工具，80% 的时间里 Figma 和 Claude Code 都是打开的。

执行速度提高 2-3 倍

以前需要与工程师进行大量反复沟通的视觉和状态管理变更，现在可以直接实现。

周期时间从数周缩短到数小时

像 Google Analytics 发布信息这样需要一周协调的复杂项目，现在只需两次 30 分钟的电话会议就能完成。

两种截然不同的用户体验

开发者获得了“增强型工作流”（执行更快），而非技术用户则获得了“天哪，我竟然也成了开发者”的工作流。

改善了设计与工程的协作

Claude Code 促进了更好的沟通和更快的问题解决，因为设计师理解了系统的限制和可能性，而无需与工程师紧密合作。

从工程师那里获得适当的设置帮助

让工程团队的同事帮助进行初始的代码库设置和权限配置——对于非开发人员来说，技术上的上手过程具有挑战性，但一旦配置完成，它将彻底改变日常工作流程。

使用自定义内存文件来引导 Claude 的行为

创建具体的指令，告诉 Claude 你是一个几乎没有编码经验的设计师，需要详细的解释和更小、更增量的更改。这极大地提高了 Claude 回应的质量，使其不再那么令人生畏。

利用粘贴图片进行原型制作

使用 Command+V 将截图直接粘贴到 Claude Code 中。它在读取设计并生成功能性代码方面表现出色，使其在将静态模型图转化为工程师可以立即理解和构建的交互式原型方面非常有价值。

强化学习（RL）工程团队专注于 RL 中的高效采样和跨集群的权重迁移。他们主要使用 Claude Code 来编写中小型功能、进行调试和理解复杂的代码库，并采用一种包含频繁检查点和回滚的迭代方法。

有监督的自主功能开发

团队让 Claude Code 在提供监督的情况下编写大部分中小型功能的代码，例如为权重迁移组件实现认证机制。他们以交互方式工作，允许 Claude 主导，但在其偏离轨道时进行引导。

测试生成和代码审查

在自己实现更改后，团队会要求 Claude Code 添加测试或审查他们的代码。这种自动化的测试工作流程在常规但重要的质量保证任务上节省了大量时间。

调试和错误调查

他们使用 Claude Code 来调试错误，结果好坏参半。有时它能立即识别问题并添加相关测试，而其他时候则难以理解问题，但总的来说，在有效时仍能提供价值。

代码库理解和调用栈分析

他们工作流程中最大的变化之一是使用 Claude Code 来快速获取相关组件和调用栈的摘要，取代了手动阅读代码或生成大量调试输出。

Kubernetes 操作指导

他们经常向 Claude Code 询问 Kubernetes 操作，这些操作否则需要大量谷歌搜索或询问基础设施工程的同事，从而能立即获得配置和部署问题的答案。

实验性方法的实现

他们现在使用一种“尝试并回滚”的方法，频繁提交检查点，以便他们可以测试 Claude 的自主实现尝试，并在需要时进行回滚，从而实现了更具实验性的开发。

文档编写加速

Claude Code 自动添加有用的注释，节省了大量的文档编写时间，尽管他们也指出，它有时会在奇怪的地方添加注释或使用有问题的代码组织方式。

有限制的提速

虽然 Claude Code 可以在他们“相对较少的时间”投入下实现中小型 PR，但他们承认，它在第一次尝试中成功的几率大约只有三分之一，需要额外的指导或手动干预。

为特定模式自定义你的 Claude.md 文件

在你的 Claude.md 文件中添加指令，以防止 Claude 重复犯工具调用错误，例如告诉它“运行 pytest 而不是 run，不要不必要地 cd – 只需使用正确的路径”。这显著提高了一致性。

使用检查点密集的工作流

随着 Claude 进行更改，定期提交你的工作，这样当实验不成功时，你可以轻松回滚。这使得在没有风险的情况下可以采用更具实验性的开发方法。

先尝试一次性解决，然后协作

给 Claude 一个快速的提示，让它先尝试完整的实现。如果成功了（大约三分之一的时间），你就节省了大量时间。如果没有，再切换到更具协作性、引导性的方法。

法务团队通过实验和了解 Anthropic 产品的好奇心，发现了 Claude Code 的潜力。此外，一位团队成员有一个个人用例，即为家人创建无障碍工具和为工作创建原型，这展示了该技术对非开发人员的强大能力。

为家人定制的无障碍解决方案

团队成员为因医疗诊断而有语言障碍的家人构建了沟通助手。在短短一小时内，一个人使用原生的语音转文本功能创建了一个预测性文本应用，该应用可以建议回复并使用语音库将其读出，解决了言语治疗师推荐的现有无障碍工具的不足之处。

法务部门工作流自动化

团队创建了“电话树”系统的原型，帮助团队成员联系到 Anthropic 合适的律师，展示了法务部门如何在没有传统开发资源的情况下为常见任务构建自定义工具。

团队协调工具

经理们构建了 G Suite 应用程序，可以自动化每周的团队更新，并跟踪各产品的法律审查状态，让律师只需通过简单的按钮点击就能快速标记需要审查的项目，而无需管理电子表格。

用于解决方案验证的快速原型制作

他们使用 Claude Code 快速构建功能性原型，然后展示给领域专家（例如向加州大学旧金山分校的专家展示无障碍工具），以验证想法并在投入更多时间之前识别现有解决方案。

在 Claude.ai 中规划，在 Claude Code 中构建

他们使用两步流程：首先在 Claude.ai 中进行头脑风暴和规划，然后转到 Claude Code 进行实现，要求它放慢速度，逐步工作，而不是一次性输出所有内容。

视觉优先的方法

他们经常使用截图向 Claude Code 展示他们想要的界面样子，然后根据视觉反馈进行迭代，而不是用文本描述功能。

原型驱动的创新

他们强调克服分享“傻瓜式”或“玩具级”原型的恐惧，因为这些演示能激励他人看到他们未曾考虑过的可能性。

MCP 集成担忧

产品律师使用 Claude Code 立即识别深度 MCP 集成的安全隐患，并指出随着 AI 工具访问更多敏感系统，保守的安全策略将成为障碍。

合规工具的优先级

他们主张随着 AI 能力的扩展，应迅速构建合规工具，认识到创新与风险管理之间的平衡。

首先在 Claude.ai 中进行详尽规划

在转到 Claude Code 之前，使用 Claude 的对话界面来充实你的整个想法。然后要求 Claude 将所有内容总结成一个分步的实现提示。

增量式和可视化工作

要求 Claude Code 放慢速度，一次实现一个步骤，这样你就可以复制粘贴而不会不知所措。大量使用截图来展示你想要的界面样子。

尽管不完美也要分享原型

克服隐藏“玩具”项目或未完成工作的冲动。分享原型有助于他人看到可能性，并在通常不互动的部门之间激发创新。

A quick check of just one of my working volumes revealed that it contains over 20,000 PDFs, the earliest dating from 1994, just a year after its introduction. Six years ago, I had become fed up with trying to use other PDF readers and set out to write my own, that soon became Podofyllin. It has some unique features, of which the most important to me is that it can’t and won’t change a PDF. Podofyllin is the latest app I have rebuilt, tweaked and given a new icon to, primarily for compatibility with macOS 26 Tahoe.

What I hadn’t realised was that, at some time during Sequoia, one of Podofyllin’s key features had quietly stopped working, apparently as a result of a silent change in macOS. This update fixes that, and restores (almost) full functionality, with just one feature still absent.

Perhaps its most important feature after preserving original PDFs unchanged, is its support for opening multiple views of the same document. Shown above are three different windows, each showing the same document, and at the lower left Writing Tools is just about to produce a summary from one of them.

The main window has thumbnails on the left, a conventional rendered page view in the middle, and the whole text content to the right. You can also open an unlimited number of accessory windows, each displaying different pages from the same document.

Another unique feature (the recently troublesome one) is a window to display the contents of the PDF file in raw format, so you can inspect its structure, metadata, and more.

This source code window shows two versions of the code, one as written in the file, the other ‘flattened’ as used in Quartz 2D to render it, together with a summary. Quite a few PDFs contain hidden content, usually left over from an earlier edit. Some save contents in versions, and for those Podofyllin can recreate and save those as separate PDF documents.

The one feature that used to work in the past that I still can’t revive is exporting page contents in Rich Text format, something I suspect isn’t working in macOS.

I have also taken the opportunity to overhaul the Help file thoroughly, to make it more accessible and navigable.

Podofyllin 1.4 is now available from here: podofyllin14
from its Product Page, and via its auto-update mechanism.

Like other recent updates, this new version requires Big Sur or later. If you’re still running Catalina or earlier, please check Podofyllin’s Help document, as that explains how you can disable its auto-update mechanism.

I’m delighted to welcome the prodigal Podofyllin back at last.

我们还年轻，可不想看到这个世界处在毫无自由、隐私的边缘。

Stirling PDF 是一站式的 PDF 编辑工具，让用户能对 PDF 文件进行各种编辑操作，包括分割、合并、转换、重新组合、新增影像、旋转、压缩等等，特色是免费、开源〔GitHub〕，过程中文件只会存在用户的设备上，若在处理时有暂存于服务器的内容在下载后会即时从服务器删除，不会记录保存或追踪任何资料，相较于在线工具来说是更安全、隐私的解决方案。

1 Locally hosted web application that allows you to perform various operations on PDF files – Stirling-Tools/Stirling-PDF

Stirling PDF 提供多元的 PDF 编辑功能，涵盖文件组织、格式转换、安全性、检视与编辑等工具，满足各类文件处理需求，用户无需额外下载、安装软件，只要通过浏览器即可进行操作，Stirling PDF 有中文在内等多国语言界面〔在我写这篇文章时中文字串翻译率已达 93%〕，进入网站、找到对应的功能后就能直接进行编辑。

这项服务目前可以做到的功能包括：

1. 文件组织

2. 格式转换

3. 签名与安全性

4. 检视与编辑

5. 进阶功能

顺带一提，Stirling PDF 还有提供 Windows 版本，可以在没有连上网络的情况下使用，如果有兴趣的朋友可以在 GitHub 找到下载链接，原则上两者功能差不多，无论在线版或 Windows 应用程序都不用付费、也无广告干扰。

Stirling PDF

进入 Stirling PDF 网站后先从右上角语言选择「中文」。

接着从上方「工具」就能看到完整功能，依照类型分为：组织、转换为 PDF、从 PDF 转换、签名与安全性、检视与编辑和进阶工具，也可以直接从首页输入功能名称列出相关工具。

有一个 PDF 万用工具是整合旋转、裁切、分割、移除、新增图片等功能，进入后先点击左下角新增要编辑的 PDF 文件。

加入后 PDF 页面预览就会显示于下方，每一页都可单独旋转、删除或调整页数，将光标移动到页面中间时还会出现其他编辑选项，例如裁切或是加入图片，其实操作上很直觉，稍微摸索一下就会。

编辑完成别忘记点击右上角「下载」保存新的 PDF 文件。

另一个压缩 PDF 也是很常在在线工具看到的功能，选择文件、设置压缩比或是自动模式〔自动调整质量以使 PDF 达到指定大小〕，就能快速压缩 PDF 以获得更小的文件容量。

点击压缩后就会开始处理，完成后自动跳出下载提示，我以大约 9 MB 的 PDF 文件、手动模式 3 级测试后获取一个约 2.5 MB 的新文件，压缩成效相当好，而且图片并没有失真或模糊等情形。

另一个也很常用到的功能是「分割 PDF」，可以将 PDF 指定页面删除、或只是留下需要的页面，使用方法也很简单就不多加赘述，Stirling PDF 会有预先设置的示例提示，用户照着格式稍作修改后就能完成相关编辑任务。

如果要说 Stirling PDF 有没有比较特殊、少见的功能，有一个「自动涂黑」工具很有用，用户只要输入要涂黑的文字，选择 PDF 后就会自动将识别到的文字涂黑，确保隐私和安全性，同时也省去手动编辑文件的时间，操作上更有效率哦！

下图就是使用自动涂黑工具识别、涂黑的 PDF 文件示例，指定文字就会被涂黑处理。