我悟了，我就说总感觉测试这个东西有哪里和我理解不一致

互动交流
1

看见下面这句话：

传统的质量保证范式（包括单元测试、集成测试甚至常规的人工代码审查）根本无法有效检测这类错误。因为这些测试工具设计的初衷是为了检查“可预测的故障”，而不是为了应对AI对人类意图的无声误解 。

1 个赞
2

所以目前有没有什么思路去减少这个AI对应人类意图，比如说我的业务需求可能误解呢

3

核心理念是从传统的“测试代码实现”转向“验证业务意图”

4

  • 意图驱动开发 (Intent-Driven Development, IDD)： 这是一种正在兴起的方法论，主张“实现后置”。它要求在让AI编写代码之前，先通过构建轻量级的“意图文档”来彻底对齐需求。这种文档具有严格的结构，包含WHY（业务动机）、WHAT（具体要求，通常使用Gherkin等行为驱动语言编写）以及HOW（实施的边界和任务计划）。结合领域驱动设计（DDD）作为严格的约束模式，可以有效防止AI在核心业务概念上产生幻觉。

  • 属性驱动测试与策略验证 (Property-Based Testing & Policy Verification)： 传统的测试用来检查已知的错误，而属性驱动测试要求开发者定义系统不可变的“业务定律”或高阶的行为契约。开发者可以采用“预言机策略（Oracle Strategy）”，提示AI同时写出业务功能代码及其需要满足的属性校验，从而在深层逻辑上检查AI是否真正理解了业务约束 。

  • 结构化提示与思维链 (Chain of Thought)： 面对存在歧义的业务需求，直接让AI生成代码往往会导致偏差。通过在提示词中引入思维链等技术，强制要求AI在实施具体操作前，先一步步输出它对业务规则的理解和推理过程。这种方法能在AI动手写代码前，暴露出它对业务意图的理解偏差。

  • 逆向提示词校验 (Reverse Prompting)： 在一些先进的多智能体（Agent）架构中，可以采用逆向校验策略。即在第一个AI根据业务需求生成代码或方案后，让第二个充当“审计员”的AI去阅读这段代码，并反向推导出“这段代码要解决的原始业务需求是什么”。如果审计员推导出的需求与你最初的意图不符，就说明实现过程中发生了无声的误解。

  • 从“环路内”转向“环路上” (On the Loop)： 面对AI极高的生成速度，人类无法再像过去那样逐行审查代码（In the Loop）。开发者的角色必须转变为意图架构师（On the Loop），把核心精力放在设计约束护栏、规范要求以及自动化的验证流水线上，让机器去校验机器 。

总结来说，减少AI误解的关键在于：不要用自然语言中模糊的“口语化需求”直接去驱动AI，而是用高度结构化的意图框架（如DDD和行为契约）去框定AI的边界，并建立反向验证机制。

5

Human Verification

语义债务泡沫：AI生成代码的保障危机——Lucenor

6

ai 生成哈 注意甄别

7

AI连车位中间都识别不出来。大概只有脑机结合才能让它快速 理解

8

完全认同！把模糊需求转成结构化意图文档，再用逆向校验和思维链控过程，本质是把人类的业务认知做成AI的开发护栏，这才是用好AI写代码的关键，再也不用对着AI生成的“歪代码”反复改了。

9

这不是:lobster:我把桌子吃了 :kissing_cat:

10

这个就是某种形式写代码。

1 个赞