Claude用户每周浪费2.5小时截图

开发者用Claude生成一张LinkedIn配图，平均要经历6个步骤、15分钟、3个软件切换。按每周15次计算，这是2.5小时的纯机械劳动——而AI明明已经帮你写好了完美的HTML。

这个痛点催生了Pixdom：一个能把任意HTML一键转成平台就绪图片/动图的CLI工具。作者用AI完成了全部开发，并公开了完整技术决策链。

从"截图地狱"到一行命令

Claude生成的HTML往往带着精致的CSS动画和渐变，但开发者拿到后只能手动截图、裁剪、转格式。作者统计过自己的典型工作流：打开Chrome→启动录屏→等待动画循环→停止录制→导入Canva→修剪循环→导出GIF。6步，15分钟，每次如此。

Pixdom的核心设计是消除这个断层。pixdom convert --html "

Hello" --profile linkedin-post --output launch.jpg——单条命令完成渲染、裁剪、格式转换全流程。

动图处理更复杂。传统工具要求用户手动指定时长、帧率、分辨率，而Pixdom的--auto模式会解析CSS动画本身：计算关键帧的最小公倍数确定循环周期，检测缓动函数推断帧率，最终输出零冗余的GIF或MP4。

AI工程师的技术选型账本

作者选择Claude Code作为"主工程师"，但强调工具链的每个决策都经过刻意设计。渲染层用Playwright控制无头浏览器，避免Puppeteer的内存泄漏问题；图像处理弃用ImageMagick的臃肿依赖，改用Sharp的Node.js原生绑定；动画捕获不用FFmpeg的屏幕录制方案，而是逐帧截图合成，保证像素级精确。

最棘手的决策是MCP服务器架构。作者最初想做成纯本地CLI，但发现Claude Desktop用户更习惯通过MCP协议调用工具。最终采用双模式设计：CLI保留完整功能，MCP服务器暴露精简接口，两者共享核心渲染引擎。

这个选择带来意外的维护成本。MCP协议当时仍在快速迭代，作者每周要跟进协议变更，同时保持CLI的向后兼容。「用AI写代码最大的幻觉是以为不用做架构决策了，」作者在复盘里写道，「实际上你花更多时间在决策上，只是不写实现细节而已。」

那些被AI埋掉的坑

开发日志里记录了多次AI导致的方向性错误。Claude Code曾建议用Canvas API直接渲染HTML，省去浏览器开销——作者花了4小时实现后才发现，Canvas不支持复杂的CSS动画和字体回退，被迫回滚。

另一次，AI为MCP服务器生成了完美的TypeScript接口，却忽略了stdio传输的64KB缓冲区限制。直到测试大体积HTML时才发现数据截断，紧急改用流式分块传输。

作者统计过：AI生成的代码首次运行成功率约60%，但架构层面的建议需要人工验证的比例超过80%。「它像一位语速极快、自信满满的初级工程师，你得学会在哪些问题上打断它。」

产品化的最后1%

Pixdom的--profile系统预设了主流平台的规格参数：LinkedIn文章的1200×627、Twitter卡片的800×418、Instagram方图的1080×1080。作者发现这个设计来自自己的真实使用场景——每次手动查文档找尺寸是另一种隐性摩擦。

但profile系统的实现曾让AI陷入困境。Claude Code试图用JSON Schema做配置验证，代码正确但用户体验糟糕：报错信息指向Schema路径而非人类可读的平台名称。作者最终手工重写了错误提示层，这是全项目少数完全手写而非AI生成的模块。

工具现已开源。作者在GitHub Issues里回复用户提问时，会标注哪些回答来自AI生成、哪些经过人工编辑——这个习惯本身成了产品透明度的注脚。

当AI能完成从需求分析到部署上线的全流程，开发者的核心技能是否正在从"写代码"转向"审代码"？你最近一次完全信任AI的架构建议，结果如何？