2025-08-04 08:00:02
原文： https://about.gitlab.com/blog/simple-trick-for-smaller-screenshots/
作者： James Ramsay
译者： Gemini 2.5 Pro
如何用 pngquant 和 zopfli 自动压缩截图
更新于 2020-02-03： 增加了 macOS Automator 的设置说明。
我每天都会截图，在 issue、博客文章、邮件和 Slack 中与人分享。我希望这些截图清晰、高分辨率，而且很重要的一点是，文件尽可能小。文件小意味着上传和下载都很快。当我在写博客或文档时，这一点尤其重要。
下面是对 PNG 压缩的简要介绍，以及将整个过程完全自动化的说明。
当你在 Mac 上截图时，图片会以 PNG-32 格式保存，它支持 1600 万种不同颜色和透明度。这意味着截图会完美捕捉屏幕上的每一个像素，但每个像素都有红、绿、蓝和 alpha (透明度) 四个 8 位通道，这使得文件非常大。如果你感兴趣，可以用 pngcheck 亲自验证一下。
在实践中，我截图的对象通常是按钮和表单，而不是照片。照片可能需要 1600 万种颜色，但截图并不需要。所以我们可以利用 PNG-8 格式，它只用一个更紧凑的 256 色调色板。
第一步是减少截图的调色板。这是一种有损压缩，称为颜色量化，它会减少图像中不同颜色的数量。pngquant 这个命令行工具正是为此而生。如果你用过广受欢迎的 ImageAlpha，那你其实已经用过 pngquant 的库了。
# Install pngquant using Homebrew
brew install pngquant
# Quantize 32-bit RGBA PNG to 8-bit (or smaller) RGBA-palette
# pngquant [number of colors] [options] input.png
# --skip-if-larger only save converted file if they're smaller than original
# --strip remove optional metadata
# --ext=.png set output filename to be same as input filename
# --force overwrite existing output files
pngquant 256 --skip-if-larger --strip --ext=.png --force example.png
下面的截图展示了不同程度的调色板缩减效果。
| PNG-32 (134KB) | 256 colors (42KB) | 128 colors (39KB) | 64 colors (38KB) |
|---|---|---|---|
| Source PNG-32 | 256 colors | 128 colors | 64 colors |
| 32 colors (37KB) | 16 colors (29KB) | 8 colors (22KB) | 4 colors (16KB) |
| — | — | — | — |
| 32 colors | 16 colors | 8 colors | 4 colors |
我发现，对于大多数截图，你可以放心地把调色板减少到 64 色，而图像质量的差异几乎看不出来。如果你经常截取渐变或更复杂的图像，你可能需要坚持使用 256 色，以避免出现明显的失真。
PNG 图像文件格式内部使用 DEFLATE 压缩来增加一层无损压缩，但大多数 PNG 库并没有实现极致的无损压缩。这就为我们提供了进一步减小文件大小的机会。
2013 年，Google 发布了 zopfli，声称与 zlib 相比，能将压缩率再提升 3-8%。这个提升的代价是：需要多等 1-2 秒。（查看压缩后的图像时，没有任何解压性能损失）。
# Install zopfli using Homebrew, which includes zopflipng
brew install zopfli
# Optimize PNG compression
# zopflipng [options] input.png output.png
# -y do not ask about overwriting files
zopflipng -y example.png example.png
相比于颜色量化带来的巨大节省，改进无损压缩提供的缩减要小得多。但在一个有很多图片的页面上，这些边际收益累加起来，也是值得的。
图表：文件大小节省情况
The trick is to make this happen automatically every time I capture a screenshot using Hazel or Automator. This allows you to run commands based on file events, like every time a new screenshot is added to a directory.
诀窍在于，每次我截图时，都通过 Hazel 或 Automator 让这一切自动发生。这些工具可以让你基于文件事件运行命令，比如每当有新截图添加到某个目录时。
另一个额外技巧是，创建一个专门的截图目录，这样它们就不会把你的桌面搞得一团糟。这也很简单：
# Create a Screenshots directory in the current users Home directory
mkdir -p "$HOME/Screenshots"
# Configure macOS to capture screenshots to this location
# If you want to revert this change, and save screenshots to your desktop,
# instead use "$HOME/Desktop"
defaults write com.apple.screencapture location "$HOME/Screenshots"
使用 Hazel，添加你新建的截图文件夹，并创建一条新规则，在文件被添加时对其进行压缩。结合上面的命令，并使用 $1 语法来访问 Hazel 传递的文件名参数，最终的脚本是：
pngquant 64 --skip-if-larger --strip --ext=.png --force "$1"
zopflipng -y "$1" "$1"
或者，使用 Automator，创建一个新的文件夹操作，从截图文件夹接收通知。添加一个运行 Shell 脚本块，并确保将输入作为参数传递。结合上面的命令，这次使用 $@ 语法来处理多个参数，并为 pngquant 和 zopflipng 使用绝对路径，最终的脚本是：
for f in "$@"
do
/usr/local/bin/pngquant 64 --skip-if-larger --strip --ext=.png --force "$f"
/usr/local/bin/zopflipng -y "$f" "$f"
done
这是我的配置截图。
| Hazel | Automator |
|---|---|
| Hazel 截图压缩规则 | Automator 截图压缩操作 |
我的最后一个技巧是，把截图文件夹添加到 Dock 中，方便访问。只需把截图文件夹从 Finder 拖到 Dock 上即可。
PNG 格式非常适合截图，但默认输出的文件对于在互联网上分享来说太大了。与其手动使用 ImageAlpha 和 ImageOptim 来压缩截图，不如用 Hazel 将这个过程自动化，从而稳定地获得 80% 的文件大小缩减。
如果你知道其他压缩技巧，或者适用于 Windows 或 Linux 的替代方案，欢迎在评论区告诉我！
2025-08-04 08:00:01
原文： https://justin.searls.co/posts/full-breadth-developers/
作者： Justin Searls
译者： Gemini 2.5 Pro
软件行业正处在一个其短暂历史上前所未有的拐点。生成式 AI (Generative AI) 是所有人都在谈论的话题。它让整个产品类别变得过时，并颠覆了就业市场。在这种量级的任何经济变革中，都注定有赢家和输家。到目前为止，全广度开发者 (full-breadth developers)——那些同时具备技术和产品能力的人——显然会成为赢家。
为什么我如此肯定？因为在过去几个月里，我认识的那些懂一点产品或商业的工程师，正以令人目眩的速度清理积压的任务。这可能没有对应任何引人注目的创新或公告，但每个人都同意，生成式编码工具最近跨过了一个重要的能力门槛。这正是我写下这篇文章的原因。仅仅两天，我就完成了 Posse Party 项目上两个月的工作量。
我能做到这一点，靠的是为应用提供精准的愿景，维持严格的技术标准，然后让 Claude Code 完成剩下的工作。如果你能将批判性思维、良好的品味和扎实的技术能力集于一身，这些工具就有潜力释放出惊人的生产力。但我看不出这如何能扩展到多人协作。如果你把我分成两个人——产品 Justin 和程序员 Justin——让他们处理同样积压的工作，那将花费数周而不是数天。沟通成本实在太高了。
然而，当我退后一步环顾四周，我看到的大多数公司和员工，在尘埃落定时，目前看来都将沦为输家。
近几十年来，企业不仅没能培养出全广度开发者，反而训练了一代人，让他们相信产品和工程角色应该被严格分开。对于许多人来说，提出一个人可以同时主导产品设计和技术执行的想法听起来很荒谬。即使那些意识到跨学科开发者是成功新关键的公司，他们过时的职位描述和薪资范围也无法招聘和留住这样的人才。
此刻有一种紧迫感。==就在几个月前，最优秀的开发者还只是在拉小提琴。而今天，他们指挥整个交响乐团。==
我的整个职业生涯都对这个问题很着迷，所以如果我在讲述下面这个故事时流露出任何幸灾乐祸的情绪，还请见谅。
2007 年大学毕业前，我通过了 Google 的电话面试。这为我赢得了一次费用全包的旅行，去传说中的 Googleplex 进行现场面试。接下来，我的自尊心彻底崩塌，因为我一败涂地，面试完全没通过。在那次旅行的许多尴尬回忆中，有一次是和一位重量级工程师的小组会谈，他被介绍为 BigTable 的发明者。（可能是 Jeff Dean？不确定。）在某个时候他说，“Google 的一大优点是，工程是一条职业道路，而产品是另一条完全独立的职业道路。”
我刚在一所文理学院花高价学了计算机科学，并且斗胆想运用那些非技术技能，所以他的这番话让我很不爽。而且，我天生就管不住自己的嘴，于是举手问道：“但如果我想扮演一个混合职业呢？如果我认为每个人都接触技术和产品至关重要呢？”
那家伙直视着我的眼睛，告诉我我不适合 Google。
招聘人员带着我们去餐厅吃午饭，打破了长久的尴尬沉默。她建议我尝尝冰淇淋三明治。不知为何，我没什么胃口了。
从那以后的几年里，世界各地越来越多的公司采用了硅谷标志性的双阶梯职业体系。技术人员坐这边，出点子的人坐那边。
回到赢家和输家的话题。
一些人抛弃了他们所知的一切，转而采用 “AI first” 的工作流程。另一些人则谴责生成式 AI 是像加密货币一样昙花一现的无用功。这导致我总是小心翼翼地提起这个话题——就好像在问别人的政治立场一样。过去几个月我一直在琢磨，为什么很难猜到一个程序员对 AI 的看法，因为人们的反应似乎与角色和技能水平无关。到底是什么因素，能预测一个人会成为过分热情的 AI 拥护者，还是一个激进的 AI 怀疑论者？
然后我想起了在 Google 的那一天。我意识到，我认识的那些拥抱 AI 的开发者，往往更有创造力、更注重结果，并且有不错的产品品味。而 AI 的反对者们，则更可能为了写代码而写代码，期望别人递给他们清晰明确的需求，或者希望工作能符合朝九晚五的常规节奏。前一类人感觉被这些工具解放了，而后一类人则常常感到受到了它们的威胁。
当我盘点眼下谁在蓬勃发展，谁在苦苦挣扎时，我发现一个人是否愿意同时扮演两种角色，是成功的最佳预测指标。
| 角色 | 工程师 | 产品 | 全广度 |
|---|---|---|---|
| 初级 | ❌ | ❌ | ✅ |
| 高级 | ❌ | ❌ | ✅ |
在我与人们谈论 AI 时，一些模式不断重复出现：
与此同时，无论技能水平或经验年限如何，混合职业的实践者似乎都玩得很开心。这是因为全广度开发者与众不同的地方，更多在于思维模式而非能力。他们以结果为导向：他们可能喜欢编码，但他们更喜欢把事情搞定。他们有条不紊：当遇到问题时，他们会通过实验和迭代来找到解决方案。他们中最优秀的是有远见的人：他们不等待别人告诉他们要做什么，他们能发现别人看不到的机会，并构想出别人没有想象过的软件。
许多人担心，市场对初级开发者的排斥预示着一个未来：今天的资深工程师会老去，却没有新人来接替他们。我没那么担心，因为经验较少的全广度开发者在这种环境下表现得非常好。不仅因为他们兴奋地拥抱了最新的 AI 工具，也因为他们展现出了纪律性，能够放慢脚步、去理解并批判性地评估这些工具生成的代码。事实是，计算机科学专业、学徒计划和编程学校——如今都已消亡或正在消亡——在培养合格的软件工程师方面从来都不是很有效。每月不到20美元的 Claude Pro，可能不仅是最好的学习资源，甚至是有史以来最好的编程学习方式。
也许你读到这里，我的信息并没有引起你的共鸣。也许它触发了你对 AI 的恐惧或担忧。也许我让你产生了戒心，觉得我此刻在胡说八道。无论如何，不管你的组织尚未为这个新时代做好准备，还是你还不认为自己是全广度开发者，这一节都是为你而写的。
虽然我在这里的目标是创造一个傻傻的短语来帮助我们更好地沟通正在发生的变革，但其实我们一直都有一个词来形容全广度开发者：顾问 (consultant)。
这并不是因为顾问是天才之类的。而是因为，正如我在 Google 面试时学到的，如果一个全广度开发者想做出最好的工作，他们需要存在于组织之外，以合同方式工作。所以毫不奇怪，我最喜欢的一些全广度顾问，正是 AI 最雄心勃勃的采纳者。不是因为 AI 是潮流，而是因为我们的性情天生就适合从这些新工具中获得最大价值。我们正在亲眼见证它们改善世界构建软件方式的潜力。
2011年，当 Todd Kaufman 和我创立我们的咨询公司 Test Double 时，我们告诉所有愿意听的人，我们的差异化优势——我们的核心理念——就是我们是能够写软件的商业顾问。技术只是达到目的的手段，而那个目的（至少如果你期望获得报酬的话）是创造商业价值。即使我们开始赢得那些似乎有无限资金的风险投资支持的公司的合同时，我们也从不动工，直到我们明白我们的工作将如何为客户创造收入或节省开支。每当数字对不上时，我们都会坚持己见，直到聘请 Test Double 的投资回报率 (ROI) 清晰可见。
所以，如果你是一家公司的领导者，并且对这个软件开发的新时代措手不及，我最好的建议是雇佣一家由全广度开发者组成的咨询公司，让他们与你的工程师并肩工作。利用这些经验来鼓励你最优秀的人开始像他们一样思考。观察他们的工作方式，并准备好彻底改革你的职位描述、面试流程和职业路径。如果你想让你的企业在这个正迅速变得更具竞争性的环境中蓬勃发展，最好的办法可能是在人员组织上按下重启键，从头再来。变得更小，保持更扁平，只有在尘埃落定、可重复的模式出现之后，才增加结构。
很多开发者对这一切带来的变化感到恐惧和绝望。是的，高管们正在利用 AI 作为借口裁员并增加利润。是的，基础模型的训练方式不道德，而且可能也违法。是的，那些鸡血哥们到处都在发表胡扯的言论。是的，几乎所有参与方都有理由对 AI 进行夸大其词的宣传。
所有这些都可以是真的，但仍然不重要。你所熟知的那个工作已经不存在了。
如果你想继续领薪水，你可能被告知要“向价值链上游移动”。如果这听起来模棱两可、不清晰，我说的更直白一点：搞清楚你的雇主是如何赚钱的，然后把你的屁股直接放在公司银行账户和客户信用卡信息之间。解释你的工作如何为雇主赚钱所需的句子越长，你就越处于价值链的下游，也就越应该担心。没什么好粉饰的：你很可能将不得不把自己远远地推出舒适区。
认真地学习和使用这些新工具。你会像我一样，一开始会感到退缩。你会发现，如果你还没发现的话，所有这些花哨的 AI 工具在取代你这方面其实做得很差。它们会不断地搞砸。你的新工作，就从想办法驾驭它们的能力开始。你会逐渐学会如何从中提取出近似于你自己会做出来的东西。一旦你越过了那个坎，工作就变成了如何扩大规模。三周前我还是 Cursor 的怀疑者。今天，我用 Claude Code 工作得筋疲力尽，因为我写新需求的速度，已经跟不上它在多个工作区里并行工作的速度了。
至于如何让你对雇主更有价值，我不是让你一夜之间就要求换个新工作。但是，如果你把你的职位描述当作一个盾牌，用来保护自己不做不想做的工作……请停止。把它当作你对自己期望的新的最低标准。主动去承担你和你的 AI 超级计算机能处理的尽可能多的工作，以此给他人带来惊喜。并且要朝着公司赚钱的方向去做。坐下来，试着计算你个人努力的投资回报率，并且不要慢下来，直到那个数字远远超过你给雇主带来的总成本。
开始在工作中践行这些价值观。如果你粗鲁地用“哦是吗？这能怎么帮我们赚钱？”来顶回每一个功能请求，没人会欣赏你。但你的经理会欣赏你问他如何能产生更大的影响。而且，如果你能记录并庆祝你一路上取得的 ROI 胜利，他们可能也不会生气。倾听公司领导层认为企业面临的最紧迫的挑战，不要害怕自愿成为解决方案的一部分。
所有这些，在十年前就是很好的职业建议。这不是什么高深的科学，只是对很多人来说非常不舒服。
我的一部分已经在哀悼上一个时代的终结。我曾花费数年写博客、演讲和构建工具的一些主题，现在已经不再重要了。而另一些我唠叨了多年的东西——极度结构化的代码组织和极其一致的设计模式——突然之间变得比以往任何时候都更有价值。我仍在整理哪些东西值得保留，哪些应该束之高阁。
作为一个人，我真的很讨厌变化。我希望事情能安定下来，静止一会儿。可惜啊。
如果这篇文章引发了你强烈的情感，请给我发邮件，我会回复。如果你觉得我对这些事情的看法有用，你可能会喜欢我的播客，Breaking Change。💜
2025-08-04 08:00:00
原文： https://blog.puzzmo.com/posts/2025/07/30/six-weeks-of-claude-code/
作者： Orta Therox
译者： Gemini 2.5 Pro
想想看，这才过去短短几周，真是不可思议。
Claude Code 极大地改变了我与大规模编写和维护代码之间的关系。我写的代码质量一如既往，但我感觉自己获得了一种全新的、难以言喻的表达自由。
Claude Code 让我不再需要亲手写下每一行代码。我仍然对我发布到 Puzzmo 的所有东西负全责，但这种能瞬间创造出整个场景，而不是一行行、一个词一个词敲代码的能力，实在太强大了。
我相信，有了 Claude Code，我们正处于编程的“摄影术发明”时期。当一个想法就能直接生成，你再用自己的代码审查和编辑技巧将其塑造成你想要的样子时，亲手绘画就再也没有那么大的吸引力了。
如果这种想法让你感到不安，那欢迎来到 2020 年代中期，这里的一切都不再稳定，变化是唯一的不变。抱歉。文化上的变化几乎都是坏的，这锅我不背，而且我认为 LLM 已经在造成社会损害，未来还会更糟——但这个精灵已经从瓶子里跑出来了，它将从根本上改变我们对编程的看法。
这篇文章建立在我使用 Claude 一周后所写的《与 Claude 结对编程》一文的基础上。如果你觉得我是个 AI 吹，你可以在那篇文章的开头部分读到我对 LLM 更细致的看法。
话虽如此，这确实是变革性的。我想从过去 6 周 Puzzmo 工程领域的动态中，给你提供一些视角，让你看看我所看到的景象。
我曾和许多人一起做过项目，其中一些单调乏味的任务需要花费数周全职时间：“把这个 JS 代码库转换成 TypeScript”、“升级到 Swift X”、“切换到 monorepo”，这些都是需要无数次 rebase 的精细迁移工作。
自从能用上 Claude Code，以下是我独自完成的事情清单：
这些项目没有一个是我今年作为 Puzzmo “业务开发”负责人日常需要做的“本职工作”。这些实际上都是我在做别的事情时自己完成的副业项目。
为了让大家更清楚地理解，我再说一遍，因为这对我自己来说都感到震惊：在过去 6 周里，我在完成 Claude Code 出现之前的既定路线图工作的同时，独自完成了所有这些事情。大部分是在后台完成的（对于一些大项目，会有一天专门进行润色）。我也并没有因此从每天工作约 10 小时变成 16 小时。
这对我来说是积压了多年的*“技术债”/“技术创新”*任务！一个半月多一点就搞定了。
只要你清楚自己在做什么，处理那些通常被归为“技术债”的繁杂任务的能力已经变得如此强大，以至于它们不再需要被当作债务来对待，你完全可以在处理其他工作时顺手就把它们做了。
*“在日程表上挤出点时间”*这件事，现在变得极其廉价，以至于你可以在开会前就启动一项任务并取得实质性进展，然后在会后决定这个方向是否正确。这简直颠覆认知。
我一直在努力养成一个习惯：在彻底否定一个想法之前，先动手试一试。例如，从 Puzzmo 第一天开始，我就一直在等待确定前端的测试策略，因为我希望能够雇佣一个人来全权负责“puzzmo.com”，而其中的一部分工作就是想办法避免我们遇到的那么多回归问题。
为前端制定测试策略不是一件轻松活，我见过很多糟糕的测试套件，它们过度测试，变得脆弱，工程师们都不愿碰。网络、react、上下文范围、dom、工具的脆弱性，这些因素混在一起，让你只能在自己用过且有信心维护的方案中，寻找那个最不坏的。
我曾想，我是不是该等别人来做这件事。但后来，我没有直接“添加一个测试套件”，而是选择让 Claude Code 在两周内为我提交的每一个前端 pull request 编写测试。
然后，在看过这些测试后，我把它们删掉了。这个过程每次只多花我 5 分钟，但却让我得以一窥其他项目处理这个问题的不同方式。几周下来，我已经准备好系统性地审视这个问题了。
为每个 pull request 写测试然后再删掉，这个想法要是放在以前，会耗费大量时间，我绝不可能同意这么做。
或者，最近在 slack 上的一个例子，我只是在后台随性地花了半天时间，试图为我们 CMS 工具中的 CRUD 资源创建一个抽象层：
成功了吗？没有。值得探索一番吗？当然。
Anthropic 提供了如何使用 worktrees 的信息——但我想提倡一种更简单的方法。两个克隆仓库，不同的 VS Code profiles。
这意味着你可以在每个克隆仓库中独立工作，并通过使用不同的主题来直观地识别工作区的差异：
我最好的理由很简单：每个克隆仓库代表一个你可以同时处理的 pull request。如果你需要编写 pull request 并与他人协作，这一点仍然非常重要。我设置了让我们的开发服务器能关闭任何占用你所需端口的进程，这样在 Claude Code 忙着处理事情时，你就可以轻松地在两个克隆仓库之间切换，而无需等待构建完成。
自 Puzzmo 创立以来，我们创造一款游戏的流程是这样的：
这个过程在编写任何生产代码之前（如果会写的话）就要花费数周。以我们目前的产出速度，我们大约每季度发布一款达到我们期望打磨水平的游戏。
在后 Claude Code 时代，这个模型可以大大简化，这也是我们正在探索的领域。我创建了一个新的 Puzzmo monorepo（现在有三个了：“app”、“games”和这个新的“prototypes”），它模仿了游戏仓库的基础设施，但对交付的代码类型有着截然不同的期望。有了这个仓库，游戏设计师可以在几个小时内将一个想法变成在 puzzmo.com 上供管理员使用的东西，你写好代码，然后进入我们的管理后台 CMS 点击几个按钮就完成了。
从“这对团队来说不错”到“我们应该公开发布”，需要我和 Saman 的一些亲手操作，但这与我们目前的生产流程相比，工作量完全不在一个量级。
我们用这种方法发布了《Missing Link》，似乎很受欢迎。但这……其实给我们带来了一点小麻烦。我乐于让游戏设计师的代码在 Puzzmo 上作为限时实验运行，但我不能接受它就此成为 Puzzmo 的正式游戏，与其它游戏并列。
正是这种让游戏设计师能够制作原型的灵活性，使其不适合编写长期的生产代码。这给我们留下了几个选择：
所有这些都有利有弊，正确的做法并不明朗。这个问题之所以新颖，是因为在 Claude Code 出现之前，将原型代码与 Puzzmo 的系统集成起来费力不讨好——而现在，这事儿变得轻而易举，团队里的任何人都能完成。我们现在真的可以兑现我们发布时提出的“实验性”游戏理念了，但这也意味着我们必须更审慎地考虑风险：发布太多人们希望我们保留的游戏。
我一直在尝试一件事：在我们每周对所有 GitHub issues 进行分类讨论时，让 Claude Code 的 GitHub action 在我们工程师团队讨论的同时，就先尝试生成一个 pull request：
或者像这个，我在 issue 里自己提供了足够的上下文：
由于我负责将这个 Pull Request 推向生产环境，这算是完成了最初的几步。对于一些小任务，既然仓库已经配置得很好，我发现它一次就能搞定。
我觉得有必要在这里提一下，从我个人意识到 Claude Code 是一个多么强大的工具那一刻起，我们就把它提供给了团队里的每一个人。
我观察到，在我们的团队里，那些使用 Claude Code 并发现其最大价值的人，往往是那些兼具产品、技术能力，并且有自主性，感觉自己可以放手去尝试的人。
其中一位说，Claude Code 让他摆脱了编程时常常面临的“第一步焦虑”。
Justin Searls 写了一篇有趣的文章，他提出了一个“全广度开发者”的概念，其中他认为：
几个月前，最优秀的开发者是拉小提琴的。如今，他们指挥整个交响乐团。
我认为这是对的。在 Puzzmo 团队内部，那些技能是自我驱动的、能独立负责自己领域、并感觉自己有自由去探索和突破界限的人，正在做着非常酷的工作。它打破了所有明确的岗位界限，让我们能以比以往更大、更快的规模就各种想法进行协作，这成了一种乐趣。
所以，我敢加倍肯定地说，Justin 的文章中所说的一切，都与 Puzzmo 工程团队内部正在发生的事情相呼应，他的文章非常值得深思。
我们使用 monorepos。我很幸运一年前花时间把所有项目都迁移到了两个主要环境中。这最初是为了反映工程团队的工作流程。我的目标是能够在一个 pull request 中完成从数据库 schema 变更到前端组件的修改。
Monorepo 非常适合与 LLM 协同工作，因为它可以读取代表我们 schema 的文件，可以读取定义公共 GraphQL API 的 sdl 文件，读取每个页面的请求，从而搞清楚你想要做什么。在一个地方拥有如此多的上下文，意味着作为 Claude Code 的用户，我不需要告诉它那些东西，一句模糊的指令，比如*“在数据库的用户模型中添加一个 xyz 字段，并让它显示在这个屏幕上”*，Claude Code 就能做到。
我的技术选型是十年前做出的。我2018 年的一个会议演讲视频仍然是我向人们介绍 Puzzmo 代码库和这些技术选择背后心态的方式。React、Relay、GraphQL、TypeScript 和（现在的 StyleX）都是乏味但极其明确的技术。所有这些系统都有编译步骤，这意味着一切都必须在本地可用且正确才能运行，这使得学习曲线有点陡峭，但一旦你做对了——你就知道你做对了。对于我们的管理工具，技术选型甚至更乏味/成熟，我还在用 Bootstrap！
对于一个 LLM 来说，这些技术已经深深地融入了它的训练集，Claude Code 知道要做诸如“运行 Relay 编译器”之类的事情（当我第一次看到 Claude Code 这样做时，我就知道这将是一段疯狂的旅程），这给了它增量验证其更改是否有效的方法。
这不是什么开创性的工作。我们日常做的大部分工作，都是相当普通的、脚踏实地的 CRUD 风格应用。
这些代码库不大，也不旧。没有东西比 2021 年更老了，虽然我一直保持更新，但我尽量保持长期的支持/向后兼容性。
我们的业务本身就是这些模型的测试套件/基准。例如，在 6 月 28 日，也就是发布这篇文章的两天前，GLM-4.5 发布了。它提供了一种在本地运行一个性能约为 Claude Code 80% 的模型的方法。他们是如何衡量这 80% 的呢？这是他们基准测试所用数据集的表格：
Puzzmo 的日常工作在他们的测试基础设施中占了大约 (39/52)%！
我本以为在过去 6 周里，Pull Requests、Commits 和合并的代码行数这些指标会有急剧变化。但我觉得这个想法站不住脚：
这是一张 3 个月的图表，其中包含一个月后 Claude Code 时代的数据。我只是让它写个脚本，通过查看我硬盘上的仓库来生成一个 CSV。
话虽如此，我认为内部任何人都会感觉到 Puzzmo 内部的变化速度确实加快了（至少在我贡献的领域），但那些数字实际上并没有真正改变。
最近有一篇论文（来自前 Claude Code 时代）说，使用 AI 的开发者会高估其影响，也许我也是如此。
但感觉上完全不是这样。你看到文章开头那个列表了吗？我感觉自己一直在打破自己通常的时间预估，以至于很难衡量一项任务到底需要多长时间。
刚开始可能会让人陶醉，但过了一段时间，使用 Claude Code 就变成了一件平淡无奇的日常工具使用。你不需要花时间去担心 Sonnet 还是 Opus，也不需要去追逐每一个 Claude Code 的竞争对手，比如 Gemini CLI、Qwen Code 或其他什么酷炫的模型。我除了用我每月 100 美元的账户里的 Claude Code，别的什么都没用，而且我用得很好。我听说过在 Claude Code 卡住时去问问 Gemini 不错，但我发现，如果 Claude Code 卡住了，那通常是我没有把工作框架描述好，重新审视一下问题是值得的。
我从没配置过 MCP server，我觉得语音聊天超级尴尬所以也没用过，我也不关注推特上那些简介里带着“.ai”的“蓝 V 大佬”。那些人可以做他们的事，但我很高兴不参与其中。
未来某个时候，考虑看看生态系统中的其他工具可能会变得有意义，但对我来说，前 Claude Code 时代和后 Claude Code 时代的差异是如此巨大，以至于它与其他工具之间的任何增量改进（在某些方面更好，在另一些方面更差）都不值得为那么一点点微小的胜利而折腾。
在本地运行模型很诱人，但像 Claude Code 这样的网络版本总会领先一步，只要我不需要考虑使用限制（是的，我知道这事），我们就处于一个很好的位置。
就像手机一样，你可能会被一种想法占据：因为 Claude Code 可以随时运行，所以你就应该让它随时运行。这实际上无异于在你的终端里（或者手机里？！）“末日刷屏”（doom-scrolling）。
值得记住的是，任何工具都可以随时使用，但驱动它的是你，而你做出明智决策的精力/能力是有限的。
claude yolo 模式运行#
我一直在尝试列出我能接受的所有操作：
.claude/settings.json
{
"permissions": {
"allow": [
"Bash(grep:*)",
"Bash(yarn run *)",
"Bash(yarn lint:*)",
"Bash(yarn workspace:*)",
"Bash(find:*)",
"Bash(mkdir:*)",
"Bash(rg:*)",
"Bash(ls:*)",
"mcp__ide__getDiagnostics",
"Bash(awk:*)",
"Bash(yarn build)",
"Bash(yarn why:*)",
"Bash(yarn info:*)",
"Edit(*)"
],
"deny": ["Bash(npx prisma migrate dev:*)", "Bash(git checkout:*)", "Bash(git add:*)"],
"defaultMode": "acceptEdits"
}
}
但这还不够，我还是经常感觉被问一些我不需要确认的事情。所以我用 claude --dangerously-skip-permissions（即 claude yolo）来运行。发生在我身上的最糟糕的事情，就是一次糟糕的 Prisma 迁移把我的开发数据库给清空了，还有一次是 Claude Code 决定自己创建一个 commit，然后又发了一个 Pull Request。
我对于后两者的理论是：如果一段内容需要人来读，那它就应该由人来写。我能接受这样的格式：
[人写的描述，或一句话总结]
---
[代码生成的 PR 模板]
但我不会在生产环境中乱来。
我和一些职业生涯早期的同事聊过，他们仍然想亲手做很多基础工作。我给他们的建议是，可以考虑先自己写，然后将自己的成果与向 Claude Code 请求相同任务得到的结果进行比较。
“平行构建”是一种鱼与熊掌兼得的方法。你仍然在学习和成长，但你的成果可以通过观察 Claude Code 训练数据中的“集体智慧”是如何做的来加以磨练。Claude Code 可能对生态系统有更深的理解，可能会读取当前代码库中更多的源代码，并且知道一些你尚未学习的抽象概念。
在我看来，把它当作一个可以学习的竞争对手，是比两种极端更健康的选择：一种是放弃，觉得反正自己什么都不用知道了；另一种是把头埋进沙子里，假装这种变化不会影响到你。
在我的整个编程生涯中，像所有人一样，我的副业项目和一次性项目的能力很大程度上受限于我仍然想拥有个人生活这个事实。我选择投身于大型开源项目，以让我对自己投入到这门手艺上的时间感到满意。
具体来说，这意味着我花时间在 CocoaPods、Danger、Jest、GraphQL 这样的项目上，而不是去做一些有趣的项目来探索一项技术，或者修复一个小问题。
现在不同了。我可以先动手试试，然后再决定我是否喜欢结果。我感觉，用 Claude Code 探索一小时，大概相当于我以前一个周末的探索量。
比如这篇博文。当我在构思它时，我想，“如果能把与 Claude Code 的对话内联显示出来就好了”，然后我又想，“为它恢复 Adium 主题不是很有趣吗”。于是，我就动手了。
我构思了一个我想要的大致想法。提前把它描述得很清楚，然后带狗出去散步了一小时，回来时就得到了一个 CLI 的合理近似版本，而这个东西如果我亲手做，可能要花几个小时。
代码量不大，但研究工作很多：如何重新创建 Adium 主题的 HTML，如何理解 claude code 的消息格式，如何处理本地预览所需的资源。
当它基本能用，可以正确地混合这些想法后，我对其进行了一轮润色。
我润色和部署过的 npm 模块足够多（174个？！），所以，这完全在我能力范围内，不用太费脑子。相反，我把这个项目当作一个有趣的副业，一边看《Apex 英雄》一边做。
如果你读了聊天记录，你会发现我确实花了一些时间来搞清楚如何过滤一些东西，如何以特定方式显示消息，但这是一种系统性的“保姆式”工作，是我真正不关心的代码。
像这样的功能对我来说是一个整个周末的项目，轻松需要 10-12 个小时才能做好并感觉可以发布。但现在，大部分工作在我不在的时候就完成了，然后润色工作是零星进行的。也许整个过程只花了我大约 2 个小时的思考时间？这太疯狂了。
如果你想看剩下的对话，了解我是如何完成这篇博文的，它们在这里：
如果你安装 Adium，然后运行 npx claude-code-to-adium，你现在就可以使用它。它会引导你完成一个向导，最终生成一个包含 html/css/图片的独立子文件夹。
我将尝试从我开始使用以来，在 19 个独立仓库/项目中进行的 147 次对话中挑选一些。我将力求涵盖不同目标，并在旁边给出我的看法。
这次对话中，我大致知道我想要什么，但我不确定 postgres 索引及其对批量删除的影响。
所以我首先问了一个一般性问题，让它使用我的 prisma 定义文件来确定数据库中当前的设置。
我们迭代改进脚本，并使其可以在本地测试。
在本地尝试后，我给了它一个“还行”的评价，然后要求一种更明确的技术。
设置好之后，我检查了所有代码，在本地进行审查，修复了风格问题，让它按照我会写的方式工作。
你可能会注意到它做了一些猜测（“我们 10-20% 的游戏记录是匿名用户的”），然后基于这个猜测做出大胆的承诺：
索引大小减少了 80-85%！
对此我表示怀疑。然而，代码是可靠的，它比我自己写的日志要多得多（这对于一个日常任务很有用），而且我感觉我理解了索引的作用。我后来添加了一些胶水注释，比如*“这个脚本与迁移 y 中的索引一起工作，所以任何更新……”*
我知道这将是一个噩梦般的 PR，你可以在这里看到。
我首先在仓库中添加了一些测试数据，并通过一个我之前留下想法的 issue 提供上下文。为了开始，我将任务描述为“这是长期目标，为了开始，我们先做 Y”。这里的 Y 是栏杆的 ASCII 快照。
我们首先构建了一种可视化工作的方法，Claude Code 做得非常接近。最后，我接手了它的工作并自己完成了集成。
一旦我有了可视化解决方案的方法，我们就可以开始处理工作的主要部分了。
我使用基于 ASCII 快照的测试，来对导入的 jpz 文件格式中栏杆的显式版本进行硬编码测试，然后创建了一个依赖于我们即将创建的算法的测试。这意味着我，以及 Claude，都有一个非常明确的方法来判断算法的工作情况。
现有的 jpz 导入算法太天真了，导入的线索是错误的，这意味着我们花了很长时间试图让两个快照匹配。Claude 一直在作弊，直接硬编码答案！直到我重新评估了所有的线索（通过为这些线索的导入创建一个单独的测试），对算法进行重新审视，才开始有所进展。
一个为游戏 Circuits 可视化设计谜题的快速、完全随性的原型。
我给了一张截图，并试图描述游戏如何运作，以及我设想的 REPL 可以如何工作。我们迭代了几次，我基本上没有写任何代码。
然后将这个原型交给其他人进行实验，并征求他们关于如何为游戏制作一个可用的开发工具的意见。
我想为填字游戏的可打印 PDF 构建一个设计。我已经有了一个可以生成它们的有效工作流，需要专门处理布局问题。
我本以为这是一个相对容易处理的问题，但结果发现，根本没有一套 CSS 原语可以同时支持列布局和围绕图像的文本重排。
Claude 在尝试我正在使用的不同 CSS 属性和系统方面表现不错，我尝试了不同的方式来描述或展示问题，但始终没能让它正常工作。
我认为在这些对话中，我脑子里的核心抽象是错误的，要么是我的建议太具体，要么是通过半吊子的答案进行实验。
最后，我想我将不得不重写它，用 JavaScript 来做布局。
也许一个有趣的结尾是，我如何看待这个工具的能力。Claude Code 知道很多东西，你可以轻松地通过链接、截图和额外的代码向它发送参考材料以提供上下文。我发现它处于“后初级”阶段的某个位置，那里有丰富的经验和充沛的精力，但它在记住你要求的事情方面做得并不好（即使通过 CLAUDE.md），而且它的所有权范围显然是微不足道的。
在 Artsy，早期我们为工程师设立了一个 5 级技术阶梯：
工程师 1 - 能交付一个明确定义的产品功能。
工程师 2 - 能独立负责一个产品功能，并能处理好与其他人的沟通。
达到第二部分要求以某种形式实际存在，并具有某种所有权意识。这是一个值得思考的有趣问题，因为我猜它可能在某种意义上拥有所有权，即代码库中那些完全随性生成且人类不怎么阅读的部分完全由这些工具“拥有”。
然而，从务实的角度来看，当它与一位经验丰富的工程师结对，后者不断审查、修改和理解其输出时——你真的可以把 Claude 当作一个结对编程的伙伴，它有无限的时间和耐心，有点过于谄媚，并且能在我前所未见的速度下，在合理的约束下交付合理的代码。
而这，就像是一种全新的创造方式。
2025-08-01 08:00:05
原文： https://every.to/working-overtime/ai-turned-me-into-a-content-agency-of-one-561948be-5370-4306-a433-b352a572705e
作者： Katie Parrott
译者： Gemini 2.5 Pro
我是如何做到的——以及它如何改变了游戏规则。
As AI races ahead, we try to step back from the fray every once in a while. Each quarter, we gather for a "think week” to reflect on our work from the previous quarter and come up with new ideas that we can build to keep delivering an incredible experience for our readers. In the meantime, we’re re-republishing five pieces by Katie Parrot with insights on how AI is changing our professional lives. Yesterday we re-upped her piece on how using vibe coding tools inspired her to want to learn to write her own software. Today we’re running her in-depth look at how she uses AI to amplify her skills as a content creator.—Kate Lee
随着 AI 的飞速发展，我们偶尔会尝试从喧嚣中抽身。每个季度，我们都会举办一次“思考周”，反思上一季度的工作，并构思新的想法，以便继续为读者提供卓越的体验。在此期间，我们将重新发布五篇由 Katie Parrot 撰写的文章，其中包含了关于 AI 如何改变我们职业生活的深刻见解。昨天我们重发了她关于使用 Vibe 编程工具如何激发她学习编写自己软件的文章。今天，我们将分享她深入探讨如何利用 AI 来放大自己作为内容创作者技能的文章。——Kate Lee
作为一名内容策略师和写作者，我很少停下来计算自己到底产出了多少东西——直到我真的去算了，那些数字让我开始怀疑自己是否活在现实中。
几周前，我坐在电脑前，为我的一个自由职业客户规划下个月要做的所有事情，突然间，我意识到我需要负责的内容数量简直多到离谱：
过去，当我在一家营销代理公司任职时，每周产出两篇文章就已经算满负荷工作了。而我刚刚列出的工作量，足够让一个小型内容营销工作室里的三四个写手忙活两到三个月。
然而，这些都是我一个人完成的。大约只用了两周。在 AI 的帮助下。
没错：我正在使用那些让许多人——尤其是创意专业人士——担心会抢走我们工作的工具，去实实在在地抢走别人的工作。
我不禁思考：我对此感到心安理得吗？
理论上听说 AI 会扼杀工作是一回事。亲眼目睹它的发生——并且在“凶器”上看到自己的指纹——则是另一回事。但我不仅仅是在与负罪感作斗争。我还在努力理解以这种方式工作意味着什么——AI 赋予了我力量，让我能做得更多、更快，并且达到几年前无法想象的规模。因为眼前的任务不仅仅是跟上节奏，更是要决定我想参加一场什么样的比赛。而这，正是事情变得有趣的地方。
我开始使用 AI，并不是为了取代谁。和我们中的许多人一样，我最初只是出于好奇开始尝试这些工具。它们真的能让我的工作更轻松吗？能帮我工作得更快或更好吗？
我从一些小事做起，让 ChatGPT 建议博客文章的标题、总结研究报告或生成粗略的大纲。起初，它仅仅是一个工具。不过是这个推崇效率的行业里又一个生产力技巧罢了。
在我使用 AI 的两年多时间里，我必须承认：AI 不仅仅是帮我更快地生产内容——它从根本上改变了我能做的事情的规模。我过去常常碰到的那些限制——时间、精力、能力——的门槛被大大降低了。那些琐碎乏味的工作，比如重新格式化草稿、插入相关链接、或为了清晰而调整措辞，都变得更容易管理了，我的精神负担减轻了，在不同任务间切换的认知成本也降低了。我可以用更少的时间和精力，交付更多的内容。
但速度并不是我 AI 赋能工作流的唯一好处。我还能交付更高质量的工作，因为我不再因那些繁杂的体力活而心力交瘁。我可以专注于策略，专注于理解客户的需求，专注于打造独特的角度和观点——所有这些，在过去的生活里，我可能因为赶着截止日期和被交付物淹没而不得不偷工减料。说 AI 让你能专注于真正重要的人类元素，这听起来可能有点老套……但 AI 确实让我能专注于那些真正重要的人类元素。
我开始将 AI 在我工作中的角色分为六个部分，这与我工作流程的六个环节相对应：
（如果你好奇，我使用的具体工具栈是：
我们来看看这一切是如何协同工作的。
如果说我学到了什么，那就是：如果你想直接开箱即用 AI，你的体验会很糟糕。这些工具很强大，但它们并没有预装那些能让内容变得“好”的上下文。如果你想让 AI 产出的作品符合你的目标——无论是高质量的思想领导力内容、与品牌一致的营销文案，还是其他东西——你必须先给它喂入正确的输入。
这意味着要预先花时间在那些重要的特定元素上训练 AI。对我来说，这些资源包括：
比如说，我在为一个客户开发一个思想领导力活动。如果没有 AI，这可能需要数周的研究、多次的草稿修改和无休止的调整。有了 AI，整个过程既更快也更有条理——但前提是我已经花时间正确地设置了它。
我首先将品牌的定位、受众画像和过往内容喂给 ChatGPT。然后，我问一些有针对性的问题，比如：
AI 会发现我可能没有注意到的空白——帮助我像一个策略家一样思考，而不仅仅是一个写作者。
基于策略性的洞见，我使用 Claude 来生成大纲。AI 确保了结构逻辑清晰，与品牌信息一致，并涵盖所有关键点。
我将粗略的想法口述给 AI 驱动的文字处理器 Lex，它会将这些想法扩展成结构化的段落。这消除了面对白纸的恐惧，并加快了写作进程。
AI 会在我提交工作成果前帮我进行审查。例如，我会这样提问：
AI 会标记出我可能忽略的薄弱环节、不一致之处和潜在机会。
一旦文章完成，我使用 Spiral 将其转换成一篇 LinkedIn 帖子、一封电子邮件和一条 Twitter 推文——所有这些都使用品牌既定的语调。
项目完成后，我让 ChatGPT 将所有东西打包成一个可复用的框架，包括交付物、工作流程，甚至定价和打包选项。这样，我就可以将相同的流程应用于未来的客户，而无需从头开始，从而将一次性的工作转变为一个可规模化的系统。
通过这些步骤，我可以在一天内完成一篇思想领导力文章，而不是三天。我可以在几次专注的工作时段里，批量生产出整整一个月的内容。
AI 不仅仅是在加速我的工作流程——它正在重新定义作为一个单枪匹马的运营者的可能性。这很令人兴奋：它促使我更大胆地去思考我能创造什么，以及我能对我合作的组织产生怎样的影响。
但它也引出了一个我无法回避的问题：当每个自由职业者、代理公司和营销团队都开始这样工作时——当一个人能完成五个人的工作时——会发生什么？如果 AI 让我如此高效，它是否也让其他人变得多余？
还有另一种看待这个问题的方式。如果 AI 让一个人能做五个人的工作，这不仅仅意味着更大的压力——也意味着更多的机会。通过降低内容生产的成本，AI 为新项目、新业务和新型创意工作打开了大门。一个单枪匹马的创业者现在可以建立一个成熟的媒体品牌。一个营销团队可以达到曾经只有财富 500 强公司才能达到的创作水平。而且从历史上看，技术进步所创造的工作岗位通常比它们取代的要多。
然而，历史并不能保证未来，我们如何将 AI 融入工作，不仅仅是关于可能性——更是关于我们的选择。
理论上，AI 可能成为那个最终能让我们实现不同工作方式的工具。它本可以让我减少工作量，用更少的时间实现财务目标，并腾出时间来关注真正重要的事情——人际关系、休息，以及我书架上越堆越高的没玩过的桌游。
在某些方面，它确实做到了。曾经需要几天才能完成的任务，现在只需要几个小时。一个曾经可能需要一个团队来执行的完整内容日历，现在我一个人就能大规模地制作出来。曾经让人不堪重负的工作，现在变得流程化、结构化、高效化。
那么，如果 AI 让我如此高效，为什么我还在工作这么长时间？
经济学家约翰·梅纳德·凯恩斯在 1930 年代预测，技术进步将带来每周 15 小时的工作制。从那以后，每一次效率的重大飞跃都会引发人们的猜测——是时候了吗？我们终于要实现了吗？每一次，答案都是一样的：还没有。
因为，对我们大多数人来说，工作并不是那样运作的。
效率并不一定会减少我们的工作量——它会扩大工作量。我们能产出的越多，我们对自己和他人的期望就越高。当产出变得更多时，对于“足够”的标准也会被推得更远。
我不再是每周写两篇文章，而是可以写八篇。
我不再是每月发几条 LinkedIn 帖子，而是可以创建 24 条。
我没有用 AI 来减轻我的工作量，而是用它来承担更多。
作为一名自雇者，理论上我有退后一步的自由——将效率提升转化为更多的休息时间，而不是更多的产出。但当我审视整个工作环境时，我知道单靠效率并不能保证稳定。市场会调整。曾经看起来令人印象深刻的工作，最终会变成基线水平。这才是促使我不断前进的真正原因。不是因为我在追逐无尽的增长，而是因为知识工作的根基正在发生变化。
我们创造的这些工具非常强大。它们让高质量的产出变得大众化，使得个体运营者、小企业和大型公司都能比以往任何时候都更容易地进行大规模创作。在许多方面，这都是一个净利好——门槛降低了，机会增多了，执行宏大想法的能力也变得前所未有地触手可及。
它们也把我们推入了一个过渡时期。AI 赋予了我们不可思议的能力，但它也创造了一种新的跑步机。问题不仅仅在于 AI 是否会为我们节省时间，而在于我们是否真的会允许自己把那些时间拿回来。
我愿意相信，我们可以用这些工具来设计更好的工作方式，而不仅仅是更快的方式。不是让 AI 来设定节奏，而是我们可以停止追逐无尽的生产力增长，并为我们自己定义生产力的真正含义。
目前，我正在进行实验：测试我使用 AI 的边界，弄清楚在哪些地方速度是有用的，又在哪些地方它只是为了工作而创造更多的工作。我知道这些工具不会消失——所以真正的挑战不在于是否使用它们，而在于如何有意识地去使用。
因为知识工作的未来，不仅仅在于谁能产出最多。而在于谁能为自己的生产力设定规则。
