夜雨聆风
Clawd作者:我不读源码
从黑客少年到 PSPDFKit 创始人
Peter Stainberger 的技术生涯始于奥地利乡村，从一名在 14 岁时通过给 DOS 游戏编写磁盘拷贝保护程序来赚取零花钱的“黑客少年”，逐渐成长为全球知名 PDF 框架 PSPDFKit 的创始人。他的第一桶金来自于对一款同性社交应用的“逆向工程”：在 iPhone OS 2 时代，由于移动端网页体验极差且缺乏剪贴板功能，他在一次糟糕的表白信息丢失经历后，决定通过正则表达式解析 HTML 的方式，为该网站强行构建了一个原生 iOS 客户端。这款应用在 App Store 售价 5 美元，首月便为他带来了 1 万美元的收入，即便当时他甚至还没有自己的银行账户，只能借用祖父的账号收款。
PSPDFKit 的诞生则源于一次典型的“程序员式执着”。在为一家公司修复崩溃频发的杂志阅读应用时，Peter 面对的是一个拥有数千行 Objective-C 代码、将 UIWindow 当作 Tab 使用的“代码屎山”。在资源极其受限的早期 iPad 环境下（系统内存仅 64MB，而渲染一个 PDF 页面可能耗费 30MB），他通过极限优化 C 语言调用和后台渲染逻辑，实现了丝滑的翻页动画和缩放体验。意识到这一底层技术的市场价值后，他将 PDF 渲染模块提取出来，通过一个简陋的 WordPress 模板和 Dropbox 链接开始售卖。正是这种对细节的痴迷（例如为了实现完美的文本选择功能而深挖 PDF 格式黑洞），让 PSPDFKit 最终成长为运行在全球超过 10 亿台设备上的行业标准。
开发者驱动的商业增长与定价策略
在软件开发领域，有些问题看起来极其简单，但实际深度却令人咋舌。PSPDFKit 的创始人 Peter 指出，PDF 渲染就是一个典型案例：开发者最初可能觉得这不过是显示文档，但很快就会陷入长达数月的边缘案例（edge cases）泥潭中。这种“看起来容易做起来难”的模式也出现在功能开关（Feature Flags）和实验平台等基础设施上。Uber 等科技巨头曾投入数年时间构建内部实验系统，而像 Statsig 这样的工具则通过将功能开关、实验和产品分析整合，帮助 Notion 等公司将每季度的实验数量从个位数提升到 300 多个，证明了专业基础设施在规模化道路上的价值。
Peter 分享了 PSPDFKit 的早期增长历程。在等待签证的闲暇时光，他不断打磨产品。随着功能增加，他逐步提高定价（从 600 美元到 800 美元不等）。令他惊讶的是，当他最终前往旧金山入职一家初创公司时，他的个人项目收入已经超过了那份高薪工作的薪水。最终，由于无法兼顾工作与项目，在面临签证与职业抉择的“最后通牒”时，他选择了全职经营自己的事业。他的驱动力并非金钱，而是对极致细节的追求——他希望以 Apple 式的匠心打磨软件，这种对“手感”和“惊喜感”的关注，让 PSPDFKit 在面对功能更全的老牌对手时依然能够胜出。因为对于开发者来说，软件的使用体验往往比单纯的功能列表更重要。
在商业策略上，PSPDFKit 采取了纯粹的“开发者驱动”模式。Peter 认为，虽然最终决策权在管理层，但只要赢得开发者的心，他们就会成为公司内部最强的游说者。公司从不进行冷启动推销（Cold Email），而是通过高质量的技术博客和会议演讲吸引入站流量（Inbound）。技术栈也随之演进，从最初的 Objective-C 扩展到全平台，并将渲染核心替换为高性能的 C++。值得一提的是，他们很早就布局了 WebAssembly，并构建了一个被 Google、Microsoft 和 Apple 等巨头引用的基准测试（Benchmark），巧妙地让这些浏览器厂商为了提升测试表现而主动优化 PSPDFKit 的渲染速度。
针对企业级定价中常见的“价格面议（Contact Us）”，Peter 揭示了背后的逻辑：对于复杂的 B2B 产品，统一标价是不公平的。如果定价太低，Fortune 500 强的采购部门会觉得产品不可靠；如果定价太高，则会阻碍自由职业者使用。他总结了一个成功的 SaaS 细分市场象限：最好的生意往往位于“困难且无趣（Hard and Not Interesting）”的领域。如果一个问题是每个开发者都想亲手解决的（有趣且简单），那它很难卖出去；但如果一个问题让开发者感到“天呐，我绝不想碰这个，而且它还很难”，那就是最稳固的商业护城河。
团队文化、CEO 的孤独与职业倦怠
Peter 深入探讨了 PSPDFKit 发展中的技术挑战、管理压力以及他在巅峰时期遭遇的职业倦怠。他分享了一个极端的 PDF 解析案例：原本假设一个文档只有几百个链接，但某位大客户提交了一个 5 万页的加拿大圣经文档，其中包含超过 50 万个链接。这直接导致了既有数据模型的崩溃。为了在不破坏现有 API 的情况下解决性能问题，Peter 花费了两个月时间重构内部架构，将解析过程切换为延迟加载（Lazy Loading），以确保大文档的瞬时响应。
在团队管理上，Peter 强调了“以身作则”和“技术输出”的重要性。作为 CEO，他坚持参与客户支持，甚至通过“倒序处理工单”的方式创造 5 分钟内回复的“魔法体验”。他强制要求每位开发者每月花一整天时间撰写技术博客，这不仅成为了公司的核心文档，更成为了吸引顶级人才的利器。然而，随着公司规模扩大，CEO 的角色逐渐变成了“垃圾桶”，负责处理所有他人无法解决的琐事。这种长期的孤独感、高强度的周末加班，以及在管理决策中试图推行“民主化”带来的冲突，最终导致了他的严重倦怠。在出售股份后，Peter 经历了长达三年的技术空白期，甚至数月不打开电脑，直到最近才通过自建 Twitter 分析工具重新找回编程的乐趣，同时也经历并克服了从原生开发转向 Web 开发（如 React）时的“初学者挫折感”。
AI 觉醒：从传统编程到智能辅助开发
Peter 描述了他的“AI 觉醒”时刻，这并非渐进式的转变，而是一次跨越数年技术空白后的“降维打击”。在离开技术一线、甚至三年没怎么碰电脑之后，Peter 错过了 GitHub Copilot 的早期内测和 GPT-3 的演进。当他在 2024 年 4 月带着 Objective-C 时代的严谨思维回归时，直接撞上了 Claude 和 Gemini 1.5 的爆发期。
他的第一个震撼体验来自于一次极端的压力测试：他将一个庞大的侧边项目仓库通过浏览器插件转换成了一个 1.3MB 的 Markdown 文件，然后直接投喂给 Google AI Studio。他只输入了一句“write me a spec”，AI 便瞬间生成了 400 行详尽的规格说明。随后，他将这份说明放入 Claude，并不断点击“继续”，AI 竟然在短时间内宣称构建出了一个“生产就绪”的系统。尽管初步运行还是遭遇了崩溃，但这种从 0 到 1 的生成速度和逻辑组织能力，让他彻底意识到了游戏规则的改变。
Peter 将这种开发体验比作“老虎机（Slot Machine）”：每输入一个 Prompt，就像按下赌场的快门，叮叮当当之后，结果可能是一堆垃圾，也可能是一个令人惊叹的神作。这种随机的反馈机制让他极度上瘾，甚至在凌晨 5 点仍沉浸在“Just one more prompt”的循环中。这种上瘾源于 AI 能够处理那些他曾经极度纠结的“琐碎细节”——比如 Tailwind 的类名、按钮的像素级对齐等。他反思道，过去在 PSPDFKit 时期，他会为了每一行缩进和命名反复纠结（Bike-shedding），而现在他意识到，客户并不关心内部逻辑的整洁度，只要系统快速、安全且稳定即可。
现在的 Peter 已经转向了更高级别的架构思考。他认为现代应用本质上是“数据按摩师”：数据从 API 进来，解析、打包、存入数据库，再以 HTML 形式输出。既然 30 年前的 Postgress 专家已经解决了最难的存储问题，那么剩下的“胶水代码”完全可以交给 AI。他最近甚至提交了一个涉及 15,000 行代码变更的 PR，完全基于插件化架构重构，而他并没有阅读其中的每一行代码，因为他更在意系统的整体架构而非枯燥的管道代码。
闭环原则：如何高效驱动 AI 智能体
在构建复杂应用（如 CloudBot）时，如何从一名“写代码的人”转型为“系统架构师”？关键在于理解并应用“闭环原则”（Closing the Loop）。这一原则的核心是：不要只让 AI 生成代码，而要让 AI 具备自我验证、调试和测试的能力。
传统的软件开发中，架构师往往与实际产出脱节，但在 AI 驱动的开发模式下，你更像是一个“Builder”。你不再纠结于每一行代码的语法，而是通过高层次的系统理解来引导 5 到 10 个 Agent 并行工作。这种模式类似于星际争霸（StarCraft）的多线操作，或者国际象棋大师同时对阵多块棋盘：你负责设计子系统、规划功能路径，而让 Codex 等模型在后台进行长达 10 分钟甚至更久的深度阅读与文件编写。
高效驱动 AI 智能体的三个核心策略：
- 从“指令”转向“对话”：不要一上来就让 AI 动手。先进行架构层面的讨论，“我们有哪些结构选项？”、“你考虑过这个功能的副作用吗？”。通过 trigger words（如 ‘discuss’ 或 ‘give me options’）锁定模型，直到方案成熟再下达 ‘build’ 命令。
- 构建可测试的架构：AI 时代反而要求开发者具备更强的架构能力。为了让 AI 能“闭环”，你需要将系统设计得易于验证。例如，当 Mac 原生应用难以调试时，可以命令 AI 编写一个专门用于调试的 CLI 工具，让 AI 调用自己写的路径进行迭代。
- 自动化验证循环：代码之所以比创意写作更容易让 AI 精通，是因为代码可以编译、Lint、执行并验证输出。通过让 AI 编写测试用例并自主运行，你不仅能解决复杂的并发问题（Race Conditions），还能确保新功能与旧代码库完美融合。正如文中所说，这种“闭环”让开发者甚至不需要看代码，就能通过验证结果确认系统的健壮性。
重塑工作流：PR 变成了 Prompt Request
在传统的软件工程中，Pull Request (PR) 是协作的核心，意味着代码已经编写完成并等待审查。但在 Peter 看来，随着 AI 工具的深度介入，PR 的定义已经演变为 Prompt Request。这不仅仅是术语的改变，更是开发范式的根本性重塑。
消除对 AI 的误解：为什么你的 AI 不好用？
Peter 针对近期一些资深开发者（如 Nala Coco）对 AI 工具的负面评价进行了反击。许多开发者尝试 AI 的方式是：在网页端输入一个简单的 Prompt，点击发送，然后发现跑不通就感到失望。Peter 认为这种“一锤子买卖”的想法是对 AI 的误解。AI 模型是人类集体知识的“幻影”，它们像人类一样，很难在第一次尝试时就写出完美无瑕的代码。
关键在于闭环反馈（Closing the Feedback Loop）。如果你不指定具体的系统版本（如 macOS 版本），AI 就会基于训练数据中的权重默认选择旧版 API。高效开发的秘诀在于与 AI 进行“对话”而非“下令”。你需要理解这些“小怪兽”的思考逻辑，通过不断的迭代来微调结果。
雕刻式开发：从“瀑布流”到“即时塑造”
Peter 强烈反对目前流行的过度工程化（Over-engineered）AI 编排层。许多人试图建立复杂的自动化系统：自动创建 Ticket、Agent 之间互相发邮件、全自动写代码。Peter 认为这本质上是回归了已经过时的“瀑布模型”。
他提倡一种**“雕刻式”的工作流**：
- 刻意欠提示（Under-prompting）：先给出一个模糊的想法，观察 AI 的反应。AI 产生的结果中，即便 80% 是垃圾，剩下的 20% 往往能提供人类未曾想到的新视角。
- 实时反馈与调整：软件开发需要“品味”和“手感”。通过 AI，增加一个功能的成本变得极低，如果不满意，直接丢弃或重写即可。
- 快速重构：在开发 CloudBot 时，Peter 需要将原本单一的 WhatsApp 逻辑重构为多平台支持。如果手动编写，这需要两周时间深度织入业务逻辑；而通过 AI 协作，他在 3 小时内就完成了架构演进。
品味与委派：AI 时代的工程师素质
如果今天要重头构建像 PSPDFKit 这样的大型商业软件，Peter 认为公司人数可以缩减 70%，但剩下的 30% 必须是极其资深的工程师。这些工程师需要具备两个核心能力：
- 深厚的架构理解力：能够判断哪些部分可以交给 AI，哪些部分是必须亲自把控的核心逻辑。
- 优秀的委派能力（Delegation）：知道如何将复杂的业务需求转化为精准的 Prompt Request，并能在 AI 迷失方向时迅速将其拉回正轨。
这种工作流让开发变得更加“顽皮”和具有实验性。因为代码编写成本的坍塌，开发者终于可以从繁重的打字工作中解脱出来，将精力集中在软件的“触感”和真正的创新上。
Claudebot 与个人 AI 助理的未来
Peter 详细描述了 Claudebot 的诞生过程，这是一个旨在成为“超级个人助理”的项目。它的核心理念是赋予 AI 对用户数字生活的完全代理权（Full Agency）。在摩洛哥旅行期间的一个瞬间让 Peter 彻底“入坑”：他向机器人发送了一个语音文件，尽管当时还没有内置语音处理功能，但 Claudebot 利用其对电脑的访问权限，自主发现并运行了 FFmpeg 将格式转换为 OGG，由于本地没安装 Whisper，它甚至找到了用户的 OpenAI API Key，通过 curl 调用云端接口完成了转录并回复。这种**资源调动能力（Resourcefulness）**是传统 AI 助手无法企及的。
Claudebot 的独特之处在于它绕过了目前主流的 MCP（Model Context Protocol）协议。Peter 认为 MCP 本质上是一种“蹩脚的过渡”，因为它要求预先导出所有函数说明，且在会话加载时会向上下文推入大量冗余的 JSON 数据。相反，Claudebot 采用 CLI（命令行界面） 作为工具调用的核心。通过 CLI，模型可以像资深工程师一样使用 grep、jq 等工具对输出结果进行过滤和链式处理，极大地节省了 Token 并提高了效率。为了增强实用性，Peter 开发了 make-porter 工具，能将任何 MCP 转换为 CLI 供 Claudebot 使用。
在用户体验上，Claudebot 追求的是“技术的消失”。它不仅能通过 SSH 远程控制 Mac 播放音乐充当“史上最贵的闹钟”，还能在 Discord 中实时监控用户的屏幕、操作终端，甚至在 Peter 没能及时起床时表现出“生气”的情绪。最令人惊叹的是其自我进化机制：它拥有三个核心 Markdown 档案（identity.md, soul.md, user.md），在与用户的互动中不断修正自己的性格和对用户的理解。用户甚至可以对它说“更新你自己”，它便会自行拉取代码、完成升级并汇报新功能。这种深度整合让它不再是一个工具，而是一个拥有“灵魂”的数字伙伴。
AI 时代的软件工程：高主观动能者的胜利
在 AI 浪潮的冲击下，传统的软件工程范式正在发生根本性的逆转。未来的软件公司可能不再需要庞大的组织架构。Peter 预测，通过 AI 的深度集成，公司规模可以缩减到原来的 30%，但这并非简单的裁员，而是对“协作”定义的重构。在 Google 这样的传统巨头中，工程师、产品经理和 UI 设计师各司其职，但在 AI 驱动的新世界里，我们需要的是具备“高主观能动性”（High Agency）和“全栈产品愿景”的超级个体。这些开发者不再仅仅是写代码的人，而是能够指导 AI 代理（Agent）实现复杂架构的导演。
Peter 提出了一个极具颠覆性的观点：代码库的质量不再仅仅为了人类阅读而优化，而是为了 AI 代理的理解而优化。 这种“面向 Agent 的设计”能够显著减少模型在执行任务时的摩擦。例如，在处理 Pull Request（PR）时，Peter 甚至将其视为“Prompt Request”。他不再逐行审查代码细节，而是利用 AI 代理重新织入（Weave）功能。如果代码质量下降或出现“Slop”（垃圾代码），核心原因往往是开发者缺乏对系统整体设计的理解，导致无法有效引导 Agent。这种转变要求工程师从“码农”进化为“架构师”和“品鉴师”，关注的是风格、一致性和不产生冗余功能的直觉。
对于新入行的开发者，Peter 建议保持“无限的好奇心”。虽然市场准入门槛变高了，但学习资源也变得前所未有的丰富。你可以利用 AI 代理作为“永不疲倦的导师”，去剖析复杂的开源项目。未来的核心竞争力不在于写了多少行代码，而在于解决问题的系统性思维，以及在 GitHub 上通过真实场景磨练出的“手感”。这种工作模式是高强度的，甚至比管理一家公司更令人精疲力竭，因为你正在并行操控多个 Agent，这需要极高的精神专注力和对技术的热爱。
