As promised last week, I have now produced a new version of Textovert that can extract text from PDF files and convert that to any of the nine formats supported by the app. Testing here suggests this could be generally useful, as the quality of output files appears good, and worth the small effort in conversion.
This new version offers the same conversions as the first, using textutil, but handles PDF files with a .pdf extension (case-insensitive) differently. When converting them to plain text, it loads the PDF and uses Quartz 2D’s PDF engine to extract the text for saving as a text file. When the output format is set to Rich Text (RTF), it uses the same engine to extract styled text and saves that as an RTF file. Note that doesn’t include layout information, but is generally a fairly faithful representation of the styles used in the original.
For the seven other output formats, Textovert first extracts styled text into a temporary RTF file, then hands that over to textutil to convert it to the selected output format.
Each PDF conversion is handled in a separate thread running at a high QoS in the background, to avoid blocking the main thread. As large conversions can take many seconds or even minutes to complete, Textovert’s window tracks how many are running at the moment. That’s most useful when converting batches of PDFs, when it’s easy to forget the last one or two that are still in progress.
Because each conversion gets its own thread, multiple simultaneous conversions will occupy as many CPU cores as are available, as shown in this CPU History for my seven heavyweight test PDFs. At the left of each chart the CPU % rises rapidly as all seven conversion threads are active. As those complete, the bursts of CPU activity diminish until they are from the single thread converting the largest of the PDFs.
To give you an idea of the quality of output, this is a tiny excerpt of the last of those in its original PDF:
And this is the webarchive output from Textovert viewed in Safari:
Converting PDFs does require significantly more memory than those performed by textutil alone. For most documents of more modest size, 100-500 MB is usual, but my monster test PDFs usually rise toward 5 GB during their conversion. I have checked this version for memory leaks, and although it can hold onto some memory longer than I would have expected, that doesn’t continue to rise, and no leak is apparent.
Because PDF conversions are more intricate, I have added extensive error-reporting. For example, if you try to convert a PDF containing scanned images without any recognised text, that won’t have any recoverable text available, as will be reported in the main window. Once conversion is complete, Textovert tries to delete the intermediate RTF file from temporary storage, and if that fails, you’ll be warned.
Textovert version 1.1 for macOS 14.6 and later is now available from here: textovert11
from Downloads above, and from its Product Page.
Yesterday’s explainer covered a range of text formats, but stopped short of one of the most popular formats for text documents, Adobe’s Portable Document Format, PDF. Its origins are as old as the Mac, and it hasn’t changed much since the start of this century, so PDF is very different from the more recent file formats, and from its antecedent PostScript.
PostScript
PostScript files, with the extension .ps, start with a prologue containing metadata such as %!PS-Adobe-3.0
%%Title: c:\output\online.dvi
%%Creator: DVIPSONE 0.8 1991 Nov 30 16:22:12 SN 102
%%CreationDate: 1992 Mar 26 10:04:36
They then largely consist of dictionaries of PostScript programs, instructions that are to be used to construct the page being described, such as %%Page: 3 4
dvidict begin bp % [3]
38811402 d U
-34996224 d u
-1582039 d U
29614244 r
f2(3)s O o
34996224 d u
-34340864 d u
8708260 r(of)s
185088 W(abstractions,)s
191757 X(such)S(as)S(\\mixed)S(blessing")S(and)S(\\retaliation,")T(in)S
(semantic)S(nets)S(that)s o
and so on. These place each item of text and graphics on that page. PDF is completely different in that it consists of a tree of objects, sometimes many hundreds or thousands of them.
PDF
To be recognised as a PDF file, the first line must start with the ‘magic’ characters and give the version used: %PDF-1.3
followed by a short line of non-ASCII bytes. It may appear surprising that macOS still writes a version that was defined in 1999, when the current version is 1.7 (before ISO standardisation) or 2.0 (standardised), and the Quartz 2D PDF engine may also report version 1.4. At least these ensure wide compatibility.
Then follows the main data, as a series of objects arranged in a flattened tree structure, starting like 3 0 obj
<< /Filter /FlateDecode /Length 158 >>
[…stream length 158…]
with a binary stream of data, which is here compressed using the Flate method (an improvement on LZW), terminated by endobj
which defines object number 3.
Some objects consist of code or definitions, such as 1 0 obj
<< /Type /Page /Parent 2 0 R /Resources 4 0 R /Contents 3 0 R /MediaBox [0 0 595 842]
>>
endobj
which is a Page dictionary.
Somewhere towards the end of the file, you’re likely to find an object containing metadata, such as details of the PDF engine that built the file: 11 0 obj
<< /Title (Untitled) /Producer (macOS Version 26.1 \(Build 25B78\) Quartz PDFContext)
/Creator (DelightEd) /CreationDate (D:20251126211410Z00'00') /ModDate (D:20251126211410Z00'00')
>>
endobj
Right at the end of the PDF file comes the cross reference, which starts like xref
0 12
0000000000 65535 f
0000000252 00000 n
and ends with a trailer trailer
<< /Size 12 /Root 8 0 R /Info 11 0 R /ID [
] >>
startxref
8785
%%EOF
and that EOF marker ends the PDF file.
Problems
Objects, as elements on the page, can be laid out almost randomly, something that often makes converting laid-out columns of text so infuriating. PDF can just drop in blocks of text and images in whatever order they come, which often doesn’t coincide with the original flow in the text. As a PDF file proceeds one page at a time, multiple columns laid out over several pages can be particularly disastrous to extract as text, or to reconstitute in any other way.
PDF files are extremely verbose, and their contents are now largely unreadable due to the extensive use of binary streams of data, and all their supporting information. A document containing a single character may thus result in a PDF file of 160 lines, making even expansive XML files look concise in comparison. The example file used in yesterday’s article takes 9 KB in storage, for a total of only 11 PDF objects.
When a PDF file is changed by annotation, the contents of each annotation are added to the file as further objects. To save apps from having to rewrite the whole PDF file every time a change is made, changes can be appended to the end of the main file contents. Those can then be incorporated into the body by rewriting the file in ‘flattened’ form.
It’s also important to remember how old the roots of PDF are. The first volume of the Unicode standard 1.0 wasn’t published until 1991, and its introduction into Mac OS was long delayed after that. Consequently, PDF remains based on 8-bit extended ASCII text, with the main characters in a PDF file still being original 7-bit ASCII. Handling characters is generally accomplished by specifying individual characters in a specific font. This is why font substitution in PDF documents so commonly results in incorrect characters being displayed, with characters outside the extended ASCII set being most vulnerable. In worst cases, this mojibake can render entire documents incomprehensible.
When I was developing my PDF reader Podofyllin, one of my goals was for it to be able to export from PDF to Rich Text Format. I never managed to get that to work, but in the light of your comments about supporting PDF as one of the convertible formats in Textovert, I revisited Podofyllin yesterday with the aim of adding that feature. And to my amazement it seems to work.
Before implementing any PDF conversions in Textovert, I’d be very grateful if you could test and comment on a beta of Podofyllin, which does now export PDF to RTF. If that code does a good enough job, then in the coming couple of weeks I will add PDF as one of the supported formats in Textovert, although that won’t rely so much on textutil as on my own code, and Quartz 2D support in macOS.
Podofyllin version 1.5 beta, build 38, adds a new command to its File menu to Export Rich Text. It also has printing disabled, as that has stopped working in recent versions of macOS, and needs repairs. I have disabled its update checking mechanism, so you won’t be pestered to ‘upgrade’ to version 1.4 when using this beta. Otherwise it retains all the features of version 1.4, and still has that Help book.
From my initial testing here the only significant oddity with the RTFs it writes may be small font sizes. There may be the occasional inappropriate use of a font, such as a line set in Courier in the midst of a paragraph in Helvetica, but those should be straightforward to correct. For small font sizes, I have simply selected all and used the Bigger font command to enlarge them all.
Podofyllin 1.5 beta, build 38, is now available from here: podofyllin15b
but not from anywhere else, for the time being. It requires macOS 11.5 or later.
Making the big presumption that PDF to RTF conversion proves worthwhile, this would make it possible to include PDF as one of the supported formats in Textovert. The snag is that would require the whole of any PDF document to be read into memory, before it could be converted to another format, in contrast to other formats where I suspect that textutil streams the input file during conversion. I don’t think there is any way to do that with PDF, because of its complex data structure.
So, if you think that this beta’s conversion of PDF to plain text and RTF is good enough to be useful, please let me know whether you want it built into Textovert, together with PDF to the other supported formats, or left in Podofyllin.
I wish you all a happy Thanksgiving, and thank you for your friendship, contributions and engagement.
Earlier this week, when I considered how best to save websites using Safari, I pointed out that the PDFs it saves aren’t intended to be in archival format, using one of the PDF/A standards. As some of you pointed out, Preview has an option to export PDFs in “PDF/A” format. This article examines whether those are suitable for archiving.
PDF/A
PDF is a generic document type and includes a multiplicity of different standards. Standard PDF generated by the Quartz 2D engine should comply with PDF version 1.4, from 2001, although the first open ISO standard of 2008 was based on version 1.7, and the current ISO standard is version 2.0. There are also five specialised subsets of PDF, among them PDF/A intended for archival purposes, each with their own families of ISO standards.
PDF/A was originally based on PDF version 1.4, but more recently has adopted 1.7. Its standards impose additional restrictions on core features, such as requiring all fonts to be embedded, and forbidding the use of encryption and LZW compression. Its standards are based on three levels of conformance: basic (B), accessible (A), and full Unicode text (U). The two standards and levels in most common use are PDF/A-2A (accessible) and PDF/A-2B (basic). A more detailed account is given in Wikipedia’s article.
Although Preview claims to export PDF documents in PDF/A format, I’ve been unable to discover which standard or level those are intended to comply with. However, each of the test documents is reported by Adobe Acrobat CC (Pro) as claiming compliance with PDF/A-2B in ISO 19005-2.
Conformance
Three test PDF documents were used, two saved from Safari 26.1 (macOS 26.1) as detailed previously, and the Help book for LogUI, written by Nisus Writer Pro. All three were opened in Preview 11.0 (1113.2.5) and Exported As PDF/A, with just the Create PDF/A option ticked in the File Save dialog.
All three exported PDFs were then opened in Adobe Acrobat ‘Pro’ version 2025.001.20841. That reported that each claimed “compliance with the PDF/A standard”, so opened them read-only to ensure they couldn’t be modified. When each was verified against PDF/A-2B, that failed.
Details of the compliance failures were then obtained using Acrobat’s Preflight feature. In each there were multiple errors, such as those shown below.
To assess what changes were required to make the LogUI help book compliant with the standard, Acrobat then performed the conversion. Corrections it made are shown below.
Although those were quick and simple, without them the file exported from Preview wasn’t considered by Acrobat to comply with the standard.
When do you need to use PDF/A?
Although I’m confident that PDF documents created using the engine in Quartz 2D in macOS Tahoe will remain fully accessible for at least the next 20 years or more, looking 50 or 100 years ahead the use of a major open standard intended and widely used for archives becomes more important. Whether the imperfect PDF/A exported by Preview would make any difference to that is unclear.
If you intend any PDF documents created on Macs to be true archives that should stand the test of long times, then you should convert them into PDF/A-2B or another appropriate standard before committing them to archival storage. Otherwise, it’s moot whether Preview’s conversion is a good investment of your time.
Summary
According to Adobe Acrobat, the ‘PDF/A’ format exported by Preview doesn’t comply with its claimed standard of PDF/A-2B. Thus the answer to the question posed by the title is no, not quite.
If a PDF is intended to be accessible for decades into the future, it should be converted to a recognised PDF/A standard such as PDF/A-2B using Adobe Acrobat or an equivalent.
Other PDFs may as well be left in their original format, which should ensure their accessibility for at least the next 20 years or more.
Websites come and go, and although the Internet Archive’s Wayback Machine provides a unique service by preserving so many, saving your own copies of pages remains important to many of us. This article looks at how you can do that using Safari 26, the current release for supported versions of macOS. If you want to explore the pages saved in the Wayback Machine, then its Safari extension is available free in the App Store.
Safari now offers the following five options for saving a page:
File/Save As…/Page Source to save it as an HTML source file (169 KB).
File/Save As…/Web Archive to save it as a Webarchive file (2.7 MB).
File/Save As…/PNG to save it as a PNG image (43.5 MB).
File/Export As PDF… to save it as a PDF file, in display format (31.6 MB).
File/Print…/Save as PDF to save it as a PDF file, in print format (28.1 MB).
Sizes given are those for a test page with plenty of images from here.
Page source
This is the smallest and least complete version of the five, as it contains just the HTML source of the page, omitting all linked and similar generated content. For relatively plain pages containing text exclusively, this can be useful. The saved file can be opened in Safari or another browser, and so long as none of the linked content is missing or changed, you should see the original content reconstituted, but in a flattened layout without columns or styling. This is unlikely to be suitable as a lasting record, although it’s by far the most compact at 169 KB for the test page.
Web Archive
This saves to a single opaque webarchive file containing the entire contents of the page, including embedded images and other content, but not linked downloadable files. Although this format is peculiar to Safari, it has had limited support by some other apps, but I can’t find any other current software that can give access to its contents.
A webarchive file is a (binary) property list written as a serialisation of the web page content in Safari, in a series of WebResource objects. For example, a JPEG image would consist of:
WebResourceData in Base-64 containing the image data;
WebResourceMIMEType of image/jpeg;
WebResourceResponse in Base-64 data;
WebResourceURL containing the URL to the file.
Although in theory it should be possible to recover some of its contents separately, in practice that isn’t available at present. In the past access has been supported by the macOS API, but all those calls to work with Webarchive files are now marked as being deprecated by Apple. Current API support is limited to writing but not reading them from WKWebView from macOS 11 onwards, and there’s no sign of that being extended.
Webarchive format has changed over time, and compatibility with different versions of Safari is unpredictable. When testing in virtual machines, Safari 18.6 proved incapable of opening any webarchive test file, including its own, while Safari 26.0 and 26.1 loaded webarchives written by Safari 18.6, 26.0 and 26.1. There has also been a long history of problems reported with webarchive files. Recent versions of macOS can display QuickLook thumbnails and previews of webarchives, although thumbnails aren’t particularly faithful to their contents.
Although webarchives should contain embedded images shown in the original page, those appear to be saved at the resolution they’re displayed in. This helps limit the size of files; in the case of the test page used here, that required 2.7 MB, around 10% of the size of a PDF, making them the most efficient option apart from plain HTML.
When they work, Safari Web Archives can provide excellent snapshots of web pages, but longer-term compatibility concerns make them unsuitable for archival use.
PNG
Saving the page to a PNG graphics file is a relatively new option in Safari. For the example page, that generates a 2,622 x 32,364 pixel image of 43.5 MB size, making it the largest of all.
The PNG image is a faithful replica of the page as viewed, although it can be affected by lazy loading (see below). Disappointingly, its text contents don’t appear to be accessible to Live Text, limiting its usefulness.
PDF
Safari provides two routes for turning a webpage into a PDF document: directly using the Export As PDF… menu command, and indirectly via the Print… command then saving as PDF from the Print dialog. The results are different.
Exporting as PDF creates a document in which the entire web page is on a single PDF page, although it can spill over to one or two additional pages. The advantage of this is that the PDF is one continuous page without any breaks, and is a faithful representation of what you see in your browser, complete with its original layout and frames. The disadvantage is that this won’t print at all well, imposing page breaks in the most awkward of places. Very long pages can also prove ungainly, and difficult to manipulate in PDF utilities. The example page was 31.6 MB in size.
Printing to PDF breaks up the web page into printable pages, and splits up frames. What you end up with isn’t what you see online, but could at a push be reassembled into something close to the original. That isn’t too bad when the placement of frames isn’t important to their reading, but if two adjacent columns need to appear next to one another, this layout is likely to disappoint. It is the best, though, for printing, with headers and footers and page numbering as well. The example page was slightly smaller than the single-page version, at 28.1 MB.
While PDF is one of the preferred formats for archiving laid-out documents, it’s worth bearing in mind that standard macOS PDF isn’t compliant with any of the PDF/A standards for archival documents. You’d need a high-end PDF editor such as Adobe’s Acrobat (Pro) CC to prepare and save to any of those.
Despite being ancient and inefficient, PDF normally does a good job of preserving the original format and layout. Text content is preserved, if laid out erratically, making it ideal for content search. Thus, either of the PDF options is best-suited for archiving web pages from Safari.
Lazy loading
Recent versions of Safari appear to load pages lazily, only inserting some images and other included content when scrolled. If you save that page to PNG or PDF without scrolling to the end of the page, the resulting file may skip those images that haven’t yet been loaded. Check the file when it has been saved to ensure that all enclosures have been captured successfully.
Conclusions
Save As…/Page Source is of limited use, mainly for text-only pages without embedded content.
Save As…/Web Archive can be excellent for day-to-day use, being complete and faithful, but isn’t an open standard and can prove fragile. It’s therefore not recommended for critical or archival use.
Save As…/PNG is of limited use, as its images are largest and their content least accessible.
Export As PDF… is excellent for day-to-day use, complete and faithful, but for serious archival use needs to be converted to comply with an archival standard in the PDF/A series.
Print…/Save as PDF is an alternative more suitable if you want to print the document out.
Before saving to PDF or PNG ensure you scroll through the whole page, then afterwards check the saved document contains everything it should.
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 个仪表盘），这是人力无法完成的。
他们建议使用 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 自主编写。
尽管对“JavaScript 和 TypeScript 知之甚少”，团队仍使用 Claude Code 构建了完整的 React 应用，用于可视化强化学习（RL）模型的性能和训练数据。他们让 Claude 控制从头开始编写完整的应用程序，比如一个 5000 行的 TypeScript 应用，而无需自己理解代码。这一点至关重要，因为可视化应用相对上下文较少，不需要理解整个 monorepo，从而可以快速构建原型工具，以便在训练和评估期间了解模型性能。
处理重复的重构任务
当遇到合并冲突或半复杂的文件重构时——这些任务对于编辑器宏来说太复杂，但又不足以投入大量开发精力——他们就像玩“老虎机”一样使用 Claude Code：提交当前状态，让 Claude 自主工作 30 分钟，然后要么接受解决方案，要么在不成功时重新开始。
创建持久性分析工具而非一次性笔记本
团队现在不再构建用完即弃的 Jupyter 笔记本，而是让 Claude 构建可重复使用的 React 仪表盘，这些仪表盘可以在未来的模型评估中重复使用。这很重要，因为理解 Claude 的性能是“团队最重要的事情之一”——他们需要了解模型在训练和评估期间的表现，而这“实际上并非易事，简单的工具无法从观察一个数字上升中获得太多信号”。
零依赖任务委托
对于完全不熟悉的代码库或语言中的任务，他们将整个实现委托给 Claude Code，利用其从 monorepo 中收集上下文并执行任务的能力，而无需他们参与实际的编码过程。这使得他们在自己专业领域之外也能保持生产力，而不是花时间学习新技术。
在让 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 能立即解决问题，而是把它当作一个与你一起迭代的合作者。这种方法比试图在第一次尝试中就获得完美的解决方案效果更好。
最近有很多朋友在讨论：「Deep Research 的用量是怎么算的？」 又因为目前 Plus 每个月只能用 10 次，大家都非常担心浪费。其实一句话就能总结——只要开始出现 「Starting Research」 的进度条，就算使用了一次。在进度条出现之前，怎么问都不算。下面就为大家分享一些 Deep Research 的使用流程、注意事项和提示词模板，帮助大家更好地运用这一强大的研究功能。
报告生成 研究进度条走完后，ChatGPT 会给你发送完整的报告，这标志着一次 Deep Research 流程的完成。
进度条出现后，你可以随时离开 进度条开始后，无论你是关闭窗口、刷新网页、切换到其他会话还是新开会话，都不会影响已经开始的 Deep Research 流程，它会在后台继续执行并最终生成报告。
Deep Research 可以后续追问 当报告生成结束后，如果你要继续追加信息重新生成报告，有两种选择：1). 直接提问，会使用你开始会话时选择的模型继续对话，报告内容可以作为上下文；比如说你从 GPT-4o 开始的，那么你在报告生成后，如果继续提问，实际上是 GPT-4o 基于你报告和提问内容回复，但是可能会受限于上下文长度无法完整理解报告内容；2). 重新生成新报告：Deep Research 是一次性生成的，但是你可以继续在当前会话选中「Deep research」按钮，这样可以把当前会话内容作为输入，或者把内容复制出去新开会话选中「Deep research」按钮重新开始一次新的生成。内容复制出去处理一下再生成会更好的对输入进行控制，但是麻烦一些。
你无法追加新的信息让它继续深度研究。如果你在当前会话里继续追问，后续的回答将由其他模型（如 GPT-4o）接管。 如果你对报告不满意，需要重新修改提示词再新开一次会话进行 Deep Research。
灵活切换模型 你可以先选任何模型（如 o1 pro/o1 等），再让它进行 Deep Research。若后续还打算继续追问报告内容，建议在 Deep Research 开始前就选一个更强的模型（比如 o1 pro / o1）来进行分析。
Login
