最近小红书上有个扎心的数字：一个中等需求，过去二三十次提交就能做完，换成AI之后一口气飙到六百多次；测试刚跑完一轮，第二天又冒出八十多个新提交，追不上，只好用AI批量生成用例，开发收到一堆细节单，又只能继续用AI批量地改。人人都在"提效"，整条链却一起失控。小红书微博
楼主把这叫作加速陷阱。小红书
因为ai给到人类的加速链里没有中断点。软件工程本来需要一些减速带，需求裁剪、验收标准、测试取舍、发布门禁、人工否决。这些减速带被冲掉后，速度不会自动变成吞吐，反而会变成噪声和返工。
为什么省了敲键盘的时间，却没换来轻松的交付？
本月知乎的热议问题问的就是它：写代码变快了，交付却没变轻松——省掉的是敲键盘的时间，更耗精力的是review、改错和对齐上下文。痛苦没消失，只是换了形态。一位用Codex的同学说得很精确。小红书
它只是把以前“我该怎么写”的痛苦，变成了现在“它写的到底对不对”的痛苦。
病根一：AI不知道人类会"妥协"
评审时产品随口一句"这个边界先不用管"，没进PRD、没变成用例，复杂度却实实在在降了下来——靠的是人类团队的隐性知识。AI没有这套默契：没有显式约束，就把所有边界都当有效、所有异常都当要覆盖。以前复杂度在进代码前就被人类裁掉了，现在它先被展开，再指望靠review和测试收回来。可人的带宽有限，变更一旦超过某个量级，review 就会从"判断对不对"退化成"看着像不像"。小红书
病根二：真正贵的不是开发，是维护
一个做广告的非程序员，用vibe coding做出过真上架App Store的产品，也真撞过维护的墙：一个礼拜迭代五十多个版本，代码变成层层叠加的黑箱，本来只需改几行的小毛病能牵动几十个文件。他的复盘值得裱起来。知乎
AI 解决的是开发速度的问题，软件工程解决的是复杂性失控的问题。Agent 提高了写代码的速度，也同时提高了制造复杂性的速度。
B站评论区也有同样的共鸣：生成的大量代码能用倒是能用，但根本看不懂。再迭代几次，就成了越改越错的屎山。哔哩哔哩
怎么装减速带？实战派收敛出四个动作
给需求加一栏"这次不做什么"：不碰哪些模块、哪些异常不展开、兼容范围和人工兜底，写清楚让AI读到、执行到；
分阶段放行：先让AI出方案，人确认后再逐段实现，没写明的分支先问人，不许脑补展开；
两个Agent分工，写的人不审自己：一个负责写，另一个站架构视角挑毛病、做验证；
补齐工程卫生：Git、版本号、架构文档、修改记录，每次改动能追溯、每个版本能追回。
原帖评论区最狠的一句：AI提效的上限不是生成速度，是人一次能审多少行。小红书
所以问题从来不是"要不要用AI编程"，而是你有没有给一台不知妥协、又不知疲倦的发动机装上刹车。毕竟——没有中断的加速，不是吞吐，是噪声。
