个人网站已上线，欢迎大家讨论交流！！！
2025年，Andrej Karpathy 提出了"Vibe Coding"这个概念。
开发者不再逐行编写代码，而是通过自然语言告诉AI自己想要什么，再由 Claude Code、Codex、Gemini CLI 等工具完成实现。
它让软件开发变得前所未有地快。
过去需要一个团队开发几个月的产品，现在一个人配合几个 AI Agent，可能几周就能完成。
但当大家都在讨论"AI一天能写多少代码"时，一门完全相反的生意出现了：
专门删除AI生成的代码。
一家名为 Slopfix 的创业团队公开表示：
我们每周收费1万美元，只做一件事：删除AI写出来的代码。
他们甚至完成过一个听起来非常夸张的项目：
在保证功能基本不变的情况下，把一个10万行的代码库删到3.5万行。
消息传到 Hacker News 和 Reddit 后，开发者社区立刻吵了起来。
有人认为，这是AI编程时代必然出现的新需求。
也有人直接嘲讽：
真正会 Vibe Coding 的人，谁还会花钱请你们收拾残局？
但比这家公司能不能赚钱更值得讨论的是：
当写代码越来越便宜，维护代码会不会变得越来越贵？
AI写得越快，代码库越容易失控
很多使用 AI Coding Agent 开发产品的人，可能经历过类似的过程。
项目刚开始时，AI几乎无所不能。
你说"帮我增加一个登录页面"，几分钟后页面就能运行；你说"接入支付功能"，它马上开始创建接口、数据库表和前端组件。
新功能不断出现，代码量也快速增长。
然而，当项目从几千行变成几万行、十几万行以后，情况开始发生变化。
以前增加一个功能只需要十几分钟，后来可能要反复调试几天；以前修改一个组件只影响当前页面，后来改动一处，却让另外两个模块出现异常。
原因并不复杂。
AI很擅长解决眼前的问题，却不一定真正理解整个系统。
当上下文不足、工程规范不清晰时，AI通常会选择最容易完成当前任务的方式：
- 找不到已有工具函数，就重新写一个；
- 不确定某个模块能不能复用，就复制一份再修改；
- 遇到历史代码不敢调整，就在外面增加一层兼容逻辑；
- 测试无法通过，就增加更多判断和特殊分支。
每一次修改单独看都很合理，但累积起来，代码库就会越来越臃肿。
这就像一个房间，每次找不到东西就重新买一份。短期非常高效，时间长了，却连走路的空间都没有了。
Vibe Coding真正危险的地方，不是AI会写错代码，而是AI可以用极低的成本不断增加代码。
他们卖的不是删代码，而是恢复开发速度
Slopfix 提供的服务看起来非常简单：帮助客户减少代码量。
但删除代码只是表面，真正的目标是恢复项目的可维护性。
在正式修改代码之前，他们会先和客户梳理整个应用：
- 有哪些页面；
- 有哪些API接口；
- 有哪些核心业务流程；
- 哪些功能必须保留；
- 哪些行为属于历史兼容；
- 哪些模块已经没有人使用。
这份功能清单既是验收标准，也是重构过程中的安全网。
接下来，他们才会开始处理代码：
把十几套日期格式化逻辑合并成一个工具；把重复出现的业务代码抽取成公共模块；把团队自己维护的简陋框架替换为成熟的开源方案；删除废弃页面、无效接口和永远不会进入的逻辑分支。
对于已经无法继续维护的模块，则保留核心需求后重新实现。
所以，客户花1万美元购买的并不是"少了多少行代码"，而是：
以后增加新功能时，不需要继续在十万行混乱代码里寻找落脚点。
代码行数减少，只是工程复杂度下降后最容易被看见的结果。
"按删除量收费"是一种聪明但危险的模式
Slopfix 的收费方式很有话题性。
三位资深工程师连续工作一周，标准价格为1万美元。但客户最终支付多少，与团队完成了多少删减目标有关。
假设双方约定减少50%的代码，最终只减少了20%，那么目标完成率为40%，客户只需要支付4000美元。
这种模式将团队利益与客户目标绑定在了一起，比传统的按工时收费更有吸引力。
但它也存在一个明显的问题：
代码行数并不等于软件质量。
有些重复代码确实应该删除，有些看起来相似的逻辑却可能代表不同的业务规则。一个3万行但高度耦合的项目，不一定比一个结构清晰的8万行项目更容易维护。
如果把"删除多少行"当成唯一指标，就可能诱导工程师为了数字而优化。
因此，真正合理的验收标准不能只有代码行数，还应该包括：
- 核心功能是否保持一致；
- 自动化测试覆盖率是否提高；
- 构建和部署是否稳定；
- 新功能的开发时间是否缩短；
- 模块之间的依赖是否更清晰；
- 安全审计和故障排查是否更容易。
少写代码是一种手段，降低系统复杂度才是目的。
会Vibe Coding，为什么还需要人类工程师？
面对质疑，Slopfix 给出的回答很现实：
他们的客户通常不是刚刚学习编程的个人开发者，而是利用AI快速完成产品验证的创业团队。
这些团队已经有真实用户，甚至已经开始收费。
在产品验证阶段，他们最关心的是速度。只要功能能够运行，代码是否优雅并不重要。
但当项目准备进入下一个阶段，问题就来了：
新工程师不敢修改代码；一次小改动可能引发线上故障；安全审计无法通过；投资人进行技术尽调时，代码库经不起检查。
这时，再对 Claude Code 说一句"帮我重构整个项目"，往往已经解决不了问题。
因为重构并不是简单地修改代码。
它需要回答一系列AI很难独立决定的问题：
哪些重复是技术债，哪些重复是业务隔离？哪些功能已经废弃，哪些功能只是暂时没有入口？哪些地方应该抽象，哪些地方应该保持独立？
这些问题没有标准答案，也不能只从代码中获得答案。
它们需要工程师理解业务、用户、历史背景和未来规划，并且对最终结果负责。
AI可以生成方案，却不能替团队承担决策后果。
未来工程师最稀缺的能力，可能是"知道什么不该写"
过去，我们常用代码产出来衡量一名工程师的工作。
写了多少功能，提交了多少代码，解决了多少需求。
AI正在快速改变这套评价方式。
当生成一千行代码只需要几分钟时，代码本身不再稀缺。真正稀缺的是判断：
- 这个需求是否真的需要开发；
- 现有能力能否解决问题；
- 应该新增模块，还是修改已有设计；
- 哪些代码值得保留；
- 哪些抽象正在制造额外复杂度；
- 系统应该在什么位置建立边界。
未来优秀工程师的价值，不一定体现在他能写多少代码，而可能体现在：
他能阻止多少不必要的代码进入系统。
初级工程师看到需求，思考的是"怎么实现"。
成熟工程师看到需求，首先思考的是"是否应该实现"。
架构师看到十个相似功能，考虑的不是如何更快地生成十份代码，而是能不能通过一个稳定模型解决十个问题。
AI没有消灭技术债，只是加快了技术债的生产速度
Slopfix 的商业模式最终能不能成立，现在还很难下结论。
一周1万美元对于个人开发者太贵，但对于已经拥有用户、准备融资或接受安全审计的创业公司来说，可能只是一次普通的工程投入。
不过，这家公司揭示的趋势值得每个开发者关注：
AI降低了软件的生产成本，却没有自动降低软件的维护成本。
AI可以让一个项目更快地从0走到1，也可以让一个缺乏规范的代码库更快地从1走向失控。
因此，真正成熟的 Vibe Coding 不是一直让AI生成代码，而是建立一套约束AI的工程体系：
明确的架构边界、可靠的自动化测试、统一的代码规范、持续集成检查，以及定期删除无效代码的习惯。
不会使用AI的工程师，可能会被会使用AI的工程师淘汰。
但只会让AI不断生成代码的工程师，也可能被那些懂得审查、约束和删除代码的工程师取代。
当"写代码"变得越来越廉价，"对代码负责"就会变得越来越昂贵。
而这，或许才是 Slopfix 真正押注的生意。