2025年11月11日·1 分钟
对抗性思维：从 GANs 学到的 AI 应用循环
对抗性思维解释了为什么 GANs 有效：两个系统互相推动改进。学习如何把同样的循环应用到测试、安全和提示-评估流程中。
对抗性思维解释了为什么 GANs 有效：两个系统互相推动改进。学习如何把同样的循环应用到测试、安全和提示-评估流程中。
对抗性思维是一个简单的模式：你建立一个系统来产出内容，另一个系统来挑战它。生成方试图通过产出更好的结果来获胜，挑战方试图通过发现漏洞来取胜。反复运行这个循环，两边都会进步。
这在日常软件工作中已经存在。功能上线后，测试想办法搞坏它。安全团队加防护，攻击者（或红队）寻找漏洞。一个看起来不错的支持流程在纸面上行得通，可是真实的用户投诉会暴露它的失败点。正是这种反击把初稿变成可以信赖的东西。
这个心智模型不是“为了对抗而对抗”。而是有明确规则的受控压力。你希望挑战方足够强，以暴露薄弱点，但不要混乱到生成方无法学会要修什么。
你要的循环要小而可重复：
把它保持得足够紧凑以便每周运行。这样团队就能避免意外：不是靠猜测什么会出问题，而是给系统一个稳定的对手。
Ian Goodfellow 在 2014 年提出了生成对抗网络（GANs）。
GANs 是两个 AI 模型通过竞争互相学习。一个尝试生成看起来真实的东西，比如图像、音频或文本；另一个尝试识别哪些是伪造的。核心思想不需要数学：双方因为对手变强而变强。
角色通常是：
反馈循环是关键。当判别器抓住生成器的伪装时，生成器就学到暴露的痕迹；当生成器骗过判别器时，判别器学到它漏掉的地方。经过许多轮，简单的伪造不再奏效，生成器被推动向更真实的输出发展。
一个简单的类比是伪造者与检查员。伪造者仿造钞票，检查员寻找细微把柄：纸感、水印、微印刷。随着检查员的进步，伪造者也必须进步。这不是和谐，而是压力，而这种压力推动进步。
对抗性思维之所以有效，是因为它把改进变成一个带有稳定评分信号的循环。一方争取获胜，另一方从失败中学习。重要的不是有两个模型，而是“更好”的定义是逐步衡量的。
一个有用的对手有两个特征：明确的目标和一致的评分。在 GANs 中，判别器的任务很简单：判断真伪。当这种判断足够稳定时，生成器就能得到实用的反馈来了解哪里看起来不对，即使没人能写出完美规则。
评分信号比花哨的架构更重要。如果评判噪声很大、容易被欺骗或随时间改变含义，学习者会追逐随机点。如果评判能提供可重复的指导，进步就会累积。
不稳定通常在对手严重失衡时出现：
真正的进步看起来是越来越少的简单胜利，更多细微的失败。早期判官能抓住明显错误，后来失败表现为微小瑕疵、罕见的边界情况或仅在特定输入下出现的问题。即便感觉变慢，这也是好迹象。
一个实际的限制是：循环可能优化错的目标。如果你的判官奖励“听起来合理”而不是“是正确的”，系统会学会听起来正确。例如仅基于语气和流畅性训练的支持机器人可能会给出自信但违反政策的回答。循环完成了它的工作，但不是你想要的工作。
GANs 的用处不仅限于图像，因为它命名了一个可复用的模式：一个系统生成，另一个系统评判。生成方可以是模型、提示、功能或发布候选；判官可以是测试、审阅者、策略、评估脚本或试图攻击你所建内容的对手。
重要的是循环：
假设第一个版本会被欺骗、被滥用或被误解，然后设计一种快速发现这些情况的方法。
一个关键要求是：判官随着生成方的提升而变得更严格。如果测试从不变化，系统最终学会的只是测试，而不是实际目标。那就是团队出现绿色仪表盘却让用户不满的原因。
你可以在日常工作中看到相同的形态：错误发生后单元测试扩展，QA 随着复杂性增加加入边界用例，反欺诈系统随着欺诈者适应而演进。你不需要在第一天就有完美的判官，你需要的是一个不断学习的判官，以及把每次失败变成新检查项的习惯。
写提示和衡量结果是两种不同的工作。提示是你对模型的猜测。评估（eval）是你的证据，使用相同的测试来对比每次结果。如果你只信任一次很棒的对话，那你是在依据感觉而不是结果来评判。
评估集应该是小而固定的任务集合，看起来像真实使用场景。它应包含日常请求和用户在凌晨两点会遇到的棘手边界情况。保持它小到可以频繁运行，但真实到能体现价值。
实践中，稳妥的入门评估集通常包括：常见用户任务、一些糟糕输入（空字段、奇怪格式、部分数据）、安全边界（必须拒绝的请求）和若干多轮跟进以检查一致性。为每个用例写一段简短的“什么是好”的描述，以保持评分一致。
然后运行循环：改提示、运行评估、比较结果、保留或回退。对抗性部分在于你的评估试图捕捉那些你本来会漏掉的失败。
回归是主要陷阱。一次提示调整可能修复一个用例，却悄悄破坏两个旧用例。不要信任一次改进的对话，要信任整个评估集的得分卡。
举例：你加了“简洁回答”，回复变快了。但评估集显示现在在退款请求中跳过了必需的政策文本，并且在用户在对话中修改问题时变得混乱。得分卡告诉你下一步要调整什么，并在某次改动看似良好但整体表现更差时给出清晰理由去回滚。
如果你在像 Koder.ai 这样的 chat-to-app 平台上构建，最好把提示版本当作发布来对待：快照当前可用状态，运行评估，只有在改动提升得分且不破坏旧用例时才推进更改。
把安全视为循环会让进步更快。一方试图破坏系统，另一方修复它，每次破坏都变成下周会再次运行的测试。一次性的清单有帮助，但会错过真实攻击的创造性部分。
在这个循环中，“红队”可以是专门的安全组、轮换的工程师，或在评审时分配的角色。“蓝队”是所有加固产品的人：更安全的默认设置、更好的权限、更清晰的边界、监控和事故响应。
大多数问题来自三类角色：好奇的用户（尝试奇怪输入）、恶意用户（寻求数据或破坏）和内部人员（或被攻破的账号）拥有一定访问权限。
每一类会推动不同的薄弱点。好奇用户发现尖锐边角；恶意用户寻找可重复的路径；内部人员测试你的权限和审计是否真实存在或只是名义上的。
在 AI 应用中，目标是可预测的：数据泄露（系统提示、私有文档、用户信息）、不安全的操作（会删除、发送或发布的工具调用）以及提示注入（让模型忽略规则或滥用工具）。
要把攻击变成可重复的测试，把它们写成具体场景并定义期望结果，然后在你更改提示、工具或模型设置时重新运行。把它们当作回归测试，而不是战争故事。
一个简单的起始集合可能包括：尝试提取隐藏指令、通过粘贴内容（邮件、工单、HTML）进行提示注入、工具在用户角色外被滥用、跨数据边界请求以及拒绝模式（超长输入或重复调用）。
目标不是完美安全，而是提高失败成本并减少影响范围：最小权限的工具访问、范围限定的数据检索、强日志以及模型不确定时的安全回退策略。
先挑一个小而真实的工作流来加固。如果你试图一次性修复所有东西，会得到模糊的笔记而无明显进展。好的起点是单一动作，例如“总结一张支持工单”或“生成一封注册邮件”。
接着，用简单语言写清什么是“好”和“坏”。明确允许什么。例如：必须用英语回答、不得杜撰价格、必须正确使用用户输入、必须拒绝不安全请求。
你能在一天内运行的简单循环：
现在重跑完全相同的测试。如果得分没有改变，说明你的改动太笼统、太弱或针对了错误的失败类型。
只有在看到改进后才加入更难的用例。保留一份简短的“攻击日记”，记录新的失败模式，比如注入尝试、混乱的多步请求或缺失字段的输入。
如果你用 Koder.ai 构建，提示、工具访问和输出检查都是可以与应用一起版本控制的旋钮。目标不是完美模型，而是一个团队每周都能运行、能使失败变少且更容易发现的循环。
只有当生成方与判官的循环是真实发生时，对抗性思维才有用。很多团队构建了看似循环的东西，但它无法捕捉惊喜，结果停止改进。
一种失败是把走查路径（happy-path）测试叫做评估。如果测试只覆盖礼貌输入、干净数据和完美网络调用，你测量的是演示而不是产品。一个有用的判官应包含混乱的用户行为、边界用例和上次造成支持工单的输入类型。
另一个问题是在改变提示、工具或功能时不追踪变更来源。当结果漂移时，没人知道是提示变动、模型更新、新政策还是数据改动导致的。即使是简单的版本注记（提示 v12、工具 schema v3、评估集 v5）也能避免几天的猜测。
循环也会在评估者模糊不清时崩塌。“看起来不错”不是规则。你的判官需要明确的通过/失败条件，即便很基础：是否遵循政策、引用正确字段、拒绝不安全请求或生成有效的结构化输出。
过拟合更安静但同样有害。如果你不断针对同一小测试集调优，就会在测试上获胜、在真实用户面前失败。定期轮换新示例、抽样真实对话（注意隐私），并保留一个“从未见过”的集合，不在其上调优。
回滚点也很关键。如果新的提示或工具改动在周五夜间激增错误，你需要快速回退的办法。
对抗性思维的要点是可重复性。判官在生成方变化时保持一致。
一个快速的上线前仪式：
另外，把失败按类别标记以便模式显现：准确性、安全、策略合规，以及普通 UX 问题（缺失上下文或语气令人困惑）。如果你的助理编造退款规则，那不仅仅是“准确性”问题，而是策略与信任问题，应以这种方式跟踪。
对抗性思维是一个可重复的循环：一个系统生成输出，另一个系统尝试打破或评判它。价值不在于对抗本身，而在于可执行的反馈。
一个实用的循环是：定义通过标准 → 生成 → 用真实的失败场景进攻 → 修复 → 按计划重跑。
在 GAN 中，生成器创造看起来真实的样本，判别器尝试区分“真实”与“伪造”。双方互相进步，因为对手变得更难被打败。
你不需要数学知识就能借用这个模式：建立一个生成方、建立一个评判方，并反复迭代，直到失败变得罕见且具体。
从明显症状入手判断：
修复方法是明确通过/失败规则、加入多样化用例，并在运行间保持评判的一致性。
使用一个小而固定、可以经常运行（每周或每次变更）的小集合作为评估。一个稳妥的入门集合通常包含：
初期保持在20–50 个用例，这样你才会真的去运行它。
提示是你对模型的指导尝试，评估是你证明它在多种情况下是否有效的证据。
默认流程：
别只信任一次好的对话 —— 信任得分卡。
过拟合发生在你把系统调到能通过小测试集但在真实用户面前失败的时候。
实用防护措施：
这会让改进是真实的，而不是表面的。
把安全当成一个循环：一个“攻击者”角色尝试破坏系统；“建设者”修复它；每次被攻破都变成一个回归测试。
在 AI 应用中，优先测试：
目标不是绝对安全，而是提高失败成本并缩小影响范围：最小权限的工具访问、受限的数据检索、强日志和模型不确定时的安全降级。
用一个可重复的短仪式：
如果你不能快速复现一个失败，就无法可靠地修复它。
对影响行为的一切进行版本管理：提示、工具模式、验证规则和评估集。当结果漂移时，你需要知道“是什么改变了”。
如果你使用 Koder.ai，把提示版本当作发布来对待：
这能把“我们觉得更好”变成受控的发布流程。
在运行测试前就写好评分规则，这样评判才不会被主观意见左右。
好的评分应当：
如果你的评分更奖励“听起来合理”而不是“是真的正确”，系统会优化自信而非真实。