我曾要求 AI 构建一个品牌网站。初看之下，它生成的成果似乎很有说服力，但在真正关键的地方却漏洞百出。页眉恰好只显示了两个链接；到处都找不到“关于我们”页面；后端确实存在一个管理面板，但前端没有任何按钮或路由可以实际触达它。服务端运行正常，客户端却不行。

大多数遇到这种情况的人都会认为 AI 变懒了，或者达到了 Token 限制。事实并非如此。问题在于结构。AI 编程工具的设计初衷是维护内部一致性。它们会问：“我声明的所有内容是否能自圆其说？”但它们不会问：“这类交付物是否包含了它应该包含的所有内容？”如果你提到品牌网站需要两个页面，模型会尽职尽责地检查这两个页面是否可以互相链接。一旦链接解析成功，它就认为任务完成了。它并没有“品牌网站需要‘关于我们’页面、信任背书或联系方式”这种内在概念。它的脑子里没有标准。

我将这种解决方法称为完整性基准 (Completeness Baseline)。

完整性基准就是一个标准清单，规定了给定的交付物必须包含的内容。你生成产物，然后根据这个外部标准来检查实际输出，而不是盲目信任工具自带的“完成”感。

从三个维度进行检查

并非所有缺失的部分都同样显而易见。一个有效的基准需要检查三个不同的维度。

存在性 (Existence)。 该部分是否真的存在？这听起来很基础，但 AI 会非常乐意构建一个引用了仪表盘页面的导航栏，却从未生成仪表盘页面本身。引用存在，但目标不存在。

可达性 (Reachability)。 真实用户能否真正触达它？隐藏的管理面板就是典型的症状。路由和组件可能都存在于代码库中，但没有任何菜单项、按钮或重定向将其暴露在界面上。如果用户在正常使用过程中无法“偶遇”它，那么它实际上并不存在。

实质性 (Substantiation)。 表面之下是否有真实的数据或结构？一个可以加载但只包含占位符文本且没有图片上传槽位的页面，只是一个穿着戏服的空壳。一个没有图片槽位或可编辑文本字段的“关于我们”页面是不完整的，即使它的 HTML 渲染得非常干净。

这三个维度可以捕捉不同类型的缺陷。存在性检查的是丢失的鞋子；可达性检查的是锁在壁橱里的鞋子；实质性检查的是没有鞋底的鞋子。

按类型划分基准

单一的基准无法涵盖所有项目。你需要对正在构建的内容进行分类，并为该类别定义不可逾越的底线。

品牌网站需要特定的板块和可触达的页面。例如“关于我们”、“联系我们”、隐私政策链接，以及能够展示每一个主要视图的导航栏。

API需要文档、详尽的错误代码和速率限制。一个仅在成功时返回 200 OK、而其他所有情况都返回通用 500 错误的可用端点，并不是一个完成的 API。它是一个隐患。

自动化需要日志和失败告警。如果一个工作流在凌晨 2 点中断，而直到人工检查运行历史之前都没人知道，那么这个自动化就是不完整的。可观测性不是附加功能，它是交付物的一部分。

一旦确定了类别，基准就自然而然地形成了。难点在于代码生成之后如何强制执行它。

经得起考验的设计规则

我围绕这个理念重构了自己的工作流，并总结出三条实用的规则，以防止项目逐渐失控。

能力门控设计 (Capability-gated design)。 在你决定使用某个工具或生成的模块之前，先检测它实际能做什么。如果一个组件库缺乏原生的移动端抽屉菜单支持，不要让 AI 生成一个假设该功能存在的完整导航方案。当某种能力缺失时，系统应当优雅降级，而不是直接崩溃。先了解边界，然后在边界内进行设计。

公共引擎，私有价值 (Public engine, private values)。 使用公共引擎来处理繁重的任务，但在运行时注入你的私有数据、配置和规范。这可以确保你的个人或公司方法论安全，并与生成的脚手架分离。AI 构建框架，你嵌入玻璃。这可以防止模型硬编码那些违反你实际标准、或将敏感模式泄露到公共训练上下文中的假设。

只提议，不要自动推进。 让 AI 建议下一步，但必须由人类做出选择。自动化执行流程，但绝不要自动化判断。当一个模型一口气自动生成数据库迁移、身份验证方案和支付钩子时，你获得的便利是以牺牲监督为代价的。让工具呈现计划，让开发者按下按钮。

为任务选择合适的模型

我在不同的模型上进行了测试，发现其价值有着明显的划分。廉价模型在处理机械性繁重任务方面表现得惊人地好。它们生成样板代码、重复组件和结构存根的速度比你打字还要快。而昂贵模型只有在表现出“克制”时才物有所值。当你需要一个拒绝编造虚假修复方案，而是指出真实缺口时，才需要选择高级选项。一个会为缺失的 API 端点幻觉出一个变通方案的模型是危险的；而一个会停下来并说“此工作流需要一个未定义的 webhook 目标”的模型才值得这个价格。你应该为洞察力买单，而不是为产量买单。

构建系统，不要追求魔法

不要试图通过使用更大的模型或更多的提示词技巧来解决 AI 的缺陷。要用基准（baseline）来解决它们。这种缺陷不是能力问题，而是预期问题。

为了防止出现缺失的代码块，请做以下三件事：

为系统提供一个完整性基准，然后再开始编写任何代码。将其制作成一个与任务并列的物理清单。

将你的规范融入到可复用的组件中。如果你通过模板、lint 规则或预构建的脚手架（scaffolds）来强制执行基准，AI 就会从正确性的起点开始工作，而不是寄希望于它能猜中你的标准。

在自动化流程的同时，保持人类对判断的控制。让机器处理重复性工作，将决策权留给理解上下文的人。

这是改变我工作方式的最后一个习惯。如果你做了七次相同的设计决策，就不要再把它当作一次性的选择。那不是重复，那是定律。为它命名，将其转化为规则，并将其文档化。当你将这种模式代码化时，你就消除了 AI 在第八次偏离它的可能性。

该框架的来源和最初的探索 可以在这里找到。

如果你想与其他面临同样问题的人交流心得，可以加入 GyaanSetu learning community。