OpenClaw创始人一语戳破“造轮子狂欢”：难的从来不是写出来，而是多年不断修
PSPDFKit 和 OpenClaw（ClawdBot）创始人 Peter Steinberger在回应开发者讨论时写道：“creating a thing isn’t hard. maintaining is.”，把矛头对准了一大堆“周末黑客项目式”的造轮子文化——写个Demo、发个Repo不难，真正难的是几年如一日把它维护到别人敢依赖。
这句话在他身上有现实注脚：PSPDFKit从业余项目变成被苹果内部采用、跑在十亿级设备上的PDF基础库，他自己维护了十几年；OpenClaw在短时间内冲上AI圈焦点，现在也因为他被OpenAI挖走而面临“谁来长期维护”的问题——这些经历让他对“起盘容易、长期维护难”的现实格外敏感。
来源：公开信息
ABAB AI Insight
1）一句话结论：这条信息真正想提醒什么？
技术世界真正稀缺的不是新项目，而是那些十年如一日把项目修到可靠、可依赖的人和组织。
底层机制是：发布版本和写一篇酷炫博客能立刻获得关注，而修边角、补文档、兼容旧环境、平滑迁移这些“维护工作”，却几乎没有短期名声回报，导致绝大多数开源和内部系统在“发布高潮”后，迅速滑入“勉强有人看管”的状态。
从商业角度看，长期维护意味着要承担技术债、兼容压力和支持成本，这些都不如“做新东西”好看，但对用户来说，能不能在五年后还安全运行，比你当年写了多优雅的架构重要得多。
2）历史同构案例
案例A：（Linux内核、PostgreSQL这类“慢工出细活”的基础软件，约1990s–至今）。Linux和PostgreSQL早期都不性感，与同时代很多“炫技式新系统”相比，发布节奏看似保守，但几十年持续维护、审慎引入特性、严控回归，最终让它们在服务器与数据库领域成为事实标准，跑在数以百万计关键业务上。
赢家是愿意投入长期维护、把“无事故运行岁月”当成护城河的社区与公司；输家是那些早期架构很酷、论文刷屏，却几年后无人维护、被迫迁移的项目。
Peter的话背后，是对这种“长线维护才是真王道”的认同：OpenClaw这种一周爆火的Agent项目固然耀眼，但能否在多年内保持安全、可扩展和兼容，才决定它是不是基础设施，而不仅是一次热点。
案例B：（企业内部核心系统从“项目上线”到“遗留系统”的生命周期，约2000s–2020s）。无数企业在某一年砸大钱上线新的CRM、风控或结算系统，项目团队拿到奖金和简历亮点后转岗，只留下一个不断被打补丁的“遗留系统”；十年后，没有人真正理解系统全貌，任何改动都像拆炸弹。
赢家是那些在立项时就规划“谁来维护、怎么演进、何时重构”的组织；输家则是把“上线”当终点、对维护毫无设计的公司，最终为技术债付出巨额成本。
Peter用一句短话提醒开发者和创始人：你今天做的每一个“酷项目”，如果没有维护计划，十年后要么变成没人敢动的黑盒，要么被迫重写，这两种结局都不配被叫“工程成功”。
3）认知模型：给读者一个可迁移的判断框架
一句话模型：评价一个技术成果时，把“能不能被维护10年”放在“有多酷”前面。
以后看到新框架、新开源项目或者内部系统升级，不妨先问三件事：1）谁对这个东西的长期健康负责？2）维护所需的知识有多集中在少数人头上？3）有没有清晰的版本策略、迁移路径和文档。
如果这三点都回答不上来，就把它当成“实验品”而不是“基础设施”，不要在关键业务上过早重仓，更别指望它无痛跑十年。
4）行动清单
投资人：
在技术尽调时，不只看GitHub Star和发布频率，刻意要求团队展示“过去3年的维护记录”：包括长期支持版本、兼容性策略和关键Bug响应时间，把“维护能力”写进投资备忘录，而不是一句“团队技术强”带过。
评估开源依赖时，建立一个“单点维护风险”清单：标出那些只有一两位核心维护者、且长期高压工作的关键依赖，并提前和团队讨论“如果项目停更，我们有什么Plan B”，避免未来被动迁移。
创业者：
给每一个核心系统或对外产品指定“维护Owner”和明确预算，把“长期维护”当成本项写进商业模型，而不是把成本都压在“上线之前”，这样才能在融资和定价时真实反映软件的全生命周期。
在内部文化上奖励“修东西的人”：不只庆祝新功能发布，也在全员场合表扬修顽固Bug、整理文档、清理技术债的工程师，用晋升和奖金向团队传递一个信号——维护本身就是高杠杆贡献，而不是没前途的苦力活。