同义反复问题——人工智能的自我确认。

2026西湖龙井茶官网DTC发售：茶农直供，政府溯源防伪到农户家 

昨天我发帖谈到，资深开发人员花费 25 分钟审查单个由人工智能生成的拉取请求。有人给我发私信说：“直接用人工智能审查员取代资深开发人员就行了。”这就是陷阱所在。

人工智能编写代码。人工智能编写测试。人工智能审查代码。三个层级，每一层都看似“智能”。问题在于：这三层共享同一个推理源。

如果人工智能误读了规范——代码是错误的，测试却因错误的代码而通过，审查也批准了错误的代码。三个层级全部显示通过。但规范仍然被违反。

这就是同义反复问题——人工智能在自我确认。

2026 年 4 月，Anthropic 发布了一份大多数人没有仔细阅读的事后分析报告。他们承认：其自身代码库中由人工智能生成的回归错误，逃过了人工审查、自动化审查、单元测试、端到端测试、自动化验证以及内部试用。Anthropic 的全套技术栈——仍然未能发现它。

如果 Anthropic 的技术栈都无法捕捉到这类错误——那么对于任何正在交付人工智能辅助代码的团队来说，一个诚实的问题是：你们的技术栈实际上能捕捉到多少问题？

业界已经尝试了几种方法。但没有一种能解决同义反复问题：

• 测试框架（Jest、Pytest 等）——测试由同一个人工智能编写，来源相同
• 代码检查工具 / 静态应用程序安全测试（SonarQube、Semgrep）——不阅读规范，仅对代码进行模式匹配
• 人工智能代码审查（Copilot、CodeRabbit、Qodo）——审查的是代码与代码库的对比，而非代码与原始规范的对比
• 人工资深审查——无法扩展规模，让你回到每个拉取请求耗时 25 分钟的状态（参见昨天的帖子）

这就是我们构建 DQA 的原因——一个面向人工智能生成代码的信任层。它不是第五个审查工具，而是一个结构上不同的层级。

DQA 直接从规范文档中编译规则——过程中无人工智能解释。人工智能提交的每次提交都会经过交叉检查：

• 此功能是否能追溯至原始需求？
• 是否违反了任何结构性约束？
• 是否有用于审计的已签名且带时间戳的证据链？

它位于“人工智能编写代码”和“代码合并至生产环境”之间。作为一个第三方，它在结构上独立——不与代码人工智能、测试人工智能或审查人工智能共享相同的推理源。

如果你正在生产环境中积极交付人工智能辅助代码，并希望交流你的团队在验证模式方面遇到的情况——请给我发私信。

本周我正在与三个开发团队进行交流，每次约 30 分钟。没有推销幻灯片。你分享你的痛点，我分享其他团队的模式。如果合适，我会建议下一步行动。如果不合适，你也能带着关于其他人如何处理此问题的 30 分钟见解离开。

👉 给我发私信或评论“DM”——我会先给你发消息。