跑起来的Demo,一上手就拉胯——如果你最近几个月在用AI写代码,大概率经历过这个瞬间。
这周,这件事被全网集中摆上了台面。B站一条叫《AI编程下半场》的视频直接挑明:VibeCoding出的产品能跑,不代表它敢交付,权限、异常和验收,才是Demo走向产品必须补上的课。哔哩哔哩知乎上一篇关于Superpowers的文章也在流传,标题写着"27万星的AI编程代理纪律框架",它讲的核心就一件事:别让AI先动手写代码,先强制它想清楚。
风向在变。而且这个变化,和每个用AI写代码的人都有关。
为什么突然都在讲"踩刹车"
先说清楚:不是AI编码退步了。恰恰相反,知乎热帖《AI编程这么厉害,为什么不下班前提交需求给AI,第二天回来Review代码》下面,高赞回答相当乐观——现在的AI,基本能在九成程度上实现"甩手掌柜",几千字需求文档丢过去,真能写得不错的案例到处都是。知乎
但另一面同样真实。有程序员发帖自述"脑子生锈":用了半年AI编程,遇到问题时自己连一个Laravel API都不会写了。36氪也有人照着"0基础用AI月入过万"的标题真去试了一遍,结果项目失败,感慨标题和现实差距大得离谱。知乎
把两边放在一起,你会发现现在问题的真实形状:AI的"平均能力"已经足够强,但一个项目从"能跑"到"能长期用",中间有一段AI自己不会主动补的暗坑。
比如过度工程化。最近B站有条热视频,叫《别让Codex继续加戏:3道刹车控制过度工程化》。哔哩哔哩它讲的场景很典型:你只想让AI改一个按钮,它顺手帮你重构了半个项目。这是现在编码Agent的通病:能力很强,但热情需要管理。
再比如,项目一大,AI就开始"失忆":前面改过的后面忘,修一处坏两处。这不是哪家的个例——社区里已经有人把主流编码Agent的上下文机制逐项拉出来对比:什么时候触发压缩、安全边界怎么留、失败了怎么恢复,全都成了摆在台面上的设计要点。小红书
这些都不是"哪个模型更聪明"的问题,而是方法问题。
社区正在讨论的4种纪律化流派
把最近知乎、B站和科技媒体上密集讨论的方法拢一拢,大致能分成四派:
1. 规格先行派。 SDD,Spec-Driven Development,规格驱动开发。先把需求、边界和验收标准写成文档,再让AI照着规格干活。《AI编程下半场》那条视频点的就是这个方向:Demo之所以不敢交付,是因为从第一天起就没人定义过"什么叫做完"。权限怎么管、异常怎么处理、验收按什么标准,写清楚了,AI的产出才有检验依据。这一派已经不是概念:GitHub官方推出的SDD工具包spec-kit,目前星标已经超过13万,定位就是帮开发者上手规格驱动开发。GitHub社区的OpenSpec也做到了6万+星标。
2. 任务拆分流水线派。 一个完整项目,不要整个丢给一个AI。B站有人分享用Godot引擎做雪地生存游戏的全过程:把开发拆给四个模型,每个只负责一项具体工作,独立对话、实时测试、精准调优。最大的好处是——系统崩了,不用全部重来。哔哩哔哩
3. 框架纪律派。 知乎流传的Superpowers是这一派的代表。它自己不生成代码,而是把头脑风暴、测试驱动开发、子代理审查、代码审查这些工程实践,封装成AI代理可以自动触发的"技能",强制先想清楚再动手。知乎我们查了一下,这个项目2025年10月上线,目前GitHub星标确实已经超过27万,官方定位是给编码Agent的一整套软件开发方法论,支持Claude Code、Codex、Cursor、OpenCode等主流编码Agent。GitHub被这个问题折磨的人,显然不在少数。
4. 刹车与验收派。 给AI设明确的边界:哪些能碰、改到什么程度要停、停下来之后必须人来检查。前面提到的"3道刹车"就是这一路的打法。Agent框架之间的比拼也在往这个方向走:诊断命令、会话日志可观测性、评估闭环,社区对比图里逐项较量的,正是这些"刹车件"。小红书
其实今年6月,这个方向就有过更大的声量:36氪报道过Claude Code之父等人物同时力挺的"新范式",核心观点是"你不该再给编程Agent写提示词了"——该给的是规格、约束和流程,不是措辞。36氪两个多月过去,这个方向正在从口号变成工具。
哪种方法适合谁?别急着全学
这里要泼一盆冷水:方法虽好,但不是人人都需要,更不是每个项目都值得上全套。
只是做玩具、做一次性工具的人,纯VibeCoding完全够用。一个处理图片的脚本、一个自己用的单页小工具,快和爽最重要,写规格文档纯属自我折磨。
想做副业项目、想发布真东西的人,至少把"验收标准+任务拆分"这两课补上。这周B站另一条讨论很多的视频说得挺到位:不会编程的人,现在确实能靠AI做出能上线、能传播的产品原型,但能不能长期做下去,取决于你能不能补上产品决策、运营和工程化这些AI替不掉的部分。哔哩哔哩
想把代码放进真实项目、甚至提交开源的人,纪律已经不是可选项,而是入场券。最近开源圈的风明显在收紧:据公开报道,科技公司纷纷收紧AI生成代码的使用限制,甲骨文已经禁止AI垃圾内容进入OpenJDK,Zig、Rust、LLVM等项目也各自出台了针对AI代码的规则。哔哩哔哩其中Rust的新规被概括成一句话:能帮你看,不能替你写,用多了还会"熔断"。36氪维护者们的说法很直白——大量AI生成的PR,已经让他们精疲力竭。
也就是说,哪怕你自己不在意代码质量,外部世界也开始用纪律标准来给你的产出打分了。
三条可以现在就做的事
第一,下个项目开工前,先写一页"什么叫做完"。验收标准、异常场景,哪怕各写一条,也比没有强。这是成本最低、杠杆最高的一步。
第二,复杂任务主动拆。一次对话只交代一件事,做完立刻测,别让AI一口气写完整个游戏。
第三,盯住两个信号:一是你用的工具有没有原生"刹车/规格"能力,这明显是接下来工具厂商竞争的方向;二是你打算参与的开源项目的代码规范,提PR前先看看对方社区对AI生成代码有没有新规,别一上来就撞在枪口上。
AI编码的上半场,解决的是"能不能做出来"。下半场比的是"做出来能不能用"。这道坎,无论新手还是老手,都绕不过去。
