AI编程的"鬼打墙"：为什么你的需求越清晰，代码越烂

「生产就绪」「99%可靠」「比默认更好」——这些词每天都在技术文档里出现，但没人能说清楚它们到底意味着什么。

一位Anthropic工程师最近公开了他的解决方案：在AI写第一行代码之前，先设一道「零号闸门」。不是检查代码，是检查人话。

一个正在蔓延的隐蔽故障

技术团队用AI辅助编程时，会产出大量持久性文档：规则文件、架构说明、代码规范。这些文档的生命周期远长于创建它的那次对话。

问题就出在这里。

当提示词里混入「不可证伪」的表述——听起来像标准，实际是情绪——模型会执行某种「看似合理」的输出。它被提交入库。六周后，这个短语成了承重结构：其他规则引用它，其他提示继承它。此时已无人能说清它的含义。

研究者给这种故障起了名字：语义偏移（Semantic Displacement）。模型用自身的概率先验替代了未被约束的目标。输出看起来合理，通过表面审查，然后静默污染所有下游环节。

这位工程师的框架文件里写得很直白：「阻止不可证伪提示词固化为规范的最快方式，就是在入口处拦截。」

正方：模糊是效率的敌人

支持「零号闸门」的核心论点建立在成本曲线上：发现不可证伪表述的位置越靠后，修复成本指数级增长。

在提示词阶段拦截，代价是一次对话重述。在代码评审阶段发现，代价是重构和回归测试。在六个月后、当其他系统已经依赖这个模糊定义时，代价可能是整个架构的隐性债务。

框架设计者本人就在用这套规则约束自己。他的全局配置文件`~/.claude/CLAUDE.md`里嵌入了同样的检查逻辑——对框架创建者和普通用户一视同仁。

具体的拦截机制很机械：

检测到风险时，AI必须逐字引用问题短语，禁止转述。用户必须看到具体的语言失败点，否则会在下一次提示中重复同样的错误。

然后解释认识论层面的失败：「这是一个氛围描述，非可证伪标准。我无法判断何时满足或违反。继续执行将导致语义偏移：我会用自己的先验替代你的实际需求。」

接着提供两到三个可量化替代方案，至少包含一个具名工程闸门和一个具体布尔失败条件。

最后强制暂停。明确拒绝执行模糊版本，等待用户选择替代方案或提出新的操作性定义。

框架还提供了一份参考转换表。不是规定具体数字，而是示范如何将氛围转化为测量：

「生产就绪」可以变成「通过CI流水线且零警告」「能在单核2GB内存下处理100并发」「回滚时间<30秒」。

「99%可靠」可以变成「连续30天无P1/P2事故」「故障恢复时间<5分钟」「错误率<0.1%（以24小时滑动窗口计）」。

「更好」可以变成「延迟P99<200ms」「支持10倍当前流量」「API向后兼容两个大版本」。

关键不在于数字本身，而在于提示词现在命名了一个测试可测量的数值或布尔值。

反方：精确是创造力的牢笼

反对声音同样存在，只是很少被写成文档。

第一种质疑指向探索性工作的本质。早期阶段的需求本就是模糊的，强制量化可能过早锁定错误方向。一位产品经理的「让用户爽」在第一天确实无法测量，但它指向了一个待验证的假设空间。如果AI在第一句话就要求「定义爽的操作性指标」，对话可能死在起点。

第二种质疑关于认知负荷。框架要求用户即时将抽象意图转化为可测量标准，这对非技术背景的提示词作者构成门槛。结果是：要么用户被迫学习一套新的表述规范，要么他们绕过闸门、用更隐晦的方式表达同样的模糊性。

第三种质疑更根本：有些价值确实难以量化。「优雅」「直观」「专业感」——这些词支撑着无数成功产品的差异化。如果AI系统只能执行可测量的目标，它可能系统性地淘汰那些依赖微妙人类判断的设计决策。

框架设计者对此有回应，但回应本身也暴露了张力：「如果用户在挑战后坚持模糊表述，闸门允许继续——但会记录在案。」

这个「抗议日志」机制说明，设计者承认存在「用户确实知道自己在说什么」的情况。但日志的存在也暗示了一种不信任：未来的读者需要被提醒，这个短语曾被标记、未被认可。

更深层的矛盾在于：同一个提示词作者，既是从闸门中获益的人，也是最可能写出模糊提示的人。工具在对抗的是使用者自身的认知习惯。

判断：这不是技术问题，是组织学习问题

「零号闸门」的真正价值不在于拦截机制本身，而在于它强制暴露了一个被忽视的事实：技术团队每天都在生产大量「假装是规范的模糊性」。

这些模糊性之所以长期存在，不是因为没人发现，而是因为纠正它们的成本被延迟支付了。AI编程工具的引入加速了这一过程——现在模糊性可以被即时转化为代码、文档和架构决策，而无需经过人类的中层翻译。

框架的激进之处在于时间点选择。它不在代码层、不在测试层、不在评审层拦截，而是在人类意图进入系统的第一毫秒。这相当于宣称：软件质量的根本瓶颈，从「如何实现」前移至「如何要求」。

但这种前移也有代价。它假设提示词作者具备即时精确化的能力，或至少具备接受挑战的心理准备。对于习惯了「先做个demo看看」的探索型团队，闸门可能成为一种摩擦成本。

更务实的视角是：将「零号闸门」视为一种组织学习工具，而非强制执行规则。抗议日志的设计暗示了这一点——重要的不是阻止每一次模糊，而是建立「模糊性被标记」的元数据层。当团队回顾决策时，他们能看到哪些需求从未被真正定义，哪些「共识」实际上是沉默的猜测。

长期来看，这可能改变技术文档的生产方式。不是先写一堆氛围描述、再逐步细化，而是在诞生的第一秒就接受可证伪性的检验。这种习惯的迁移，比任何具体的AI安全机制都更深远。

框架的公开版本托管在`claude-code-agent-skills-framework`仓库。设计者强调：具体数字不是重点，重点是提示词现在命名了测试可测量的东西。

这句话本身也值得审视。如果数字不是重点，为什么整个机制围绕数字构建？可能的答案是：数字是可达成的妥协。在「完全模糊」和「完全精确」之间，可测量的数值提供了一个中间地带——足够具体以避免语义偏移，又足够灵活以适应领域差异。

最终，「零号闸门」揭示了一个关于AI辅助编程的冷峻事实：我们以为瓶颈是模型的能力，实际瓶颈是我们向模型描述意图的能力。而描述意图的能力，又折射出组织对「什么是完成」的集体迷茫。

工具可以拦截模糊的提示词，但无法替代团队回答那个更古老的问题：我们到底在建造什么，以及怎么知道它建好了。

至少现在，当AI准备把「生产就绪」写进你的架构文档时，它会先停下来问你：具体是多少并发、多少延迟、多少恢复时间——还是你想让我猜？

如果你选择让它猜，它会记下来。六个月后，当这个猜测成为整个系统的承重墙，至少有人能翻出日志说：看，这里本来可以问清楚的。