从谷歌工程师不可或缺的提示词中我们能学到什么
内容提要
Google Cloud工程师分享了十种AI提示词技巧，核心是将AI用作对抗性审查者而非顺从助手。包括：让模型以怀疑视角构建规格、审计测试覆盖、分两次清理代码、检查合规性、用评分标准严格审查代码、让模型辩护自身方案、基于外部研究制定检查清单、分阶段迭代、自动化审查脚本，以及用图结构分析工作流。这些方法旨在降低人类假设风险，提升代码质量。
延伸解读
对抗性提示词的核心：降低人类假设风险
文章中的十种技巧看似各异，但共同点在于将AI从顺从的助手转变为对抗性的审查者。无论是让模型扮演怀疑的首席架构师，还是要求它为自己的方案辩护，目的都是迫使模型生成具体的反对意见，从而暴露人类在规划、测试和代码审查中容易忽略的盲点。这种思路提醒我们，提示词的价值不在于节省打字时间，而在于系统性地降低因人类假设而引入的风险。
从“测试”到“审计”：测试覆盖率的真正提升
Andrew Brogdon的方法强调先审计可测试性，再制定测试计划，而非直接要求生成测试。这避免了模型只生成最容易测试的用例，而忽略了真正需要覆盖的边界情况。类似地，Aja Hammerly将清理代码分为两个独立提示，分别处理缺失的测试和遗留的杂物，以获得更精准的结果。这些做法表明，有效的AI辅助测试需要先诊断，再行动。
自动化审查：将对抗性审查嵌入CI流程
Remigiusz Samborski的团队将审查代理直接集成到GitHub Actions中，确保每个拉取请求都自动获得结构化审查。文章提供了一个独立的Python脚本，它获取git diff并发送给模型进行评分。这种自动化不仅消除了“忘记审查”的可能性，还使得审查标准一致且可重复。对于追求代码质量的团队，这是一个值得借鉴的实践。
图结构思维：发现组件间的“接缝”风险
Karl Weinmeister的方法独树一帜：将应用工作流建模为有向无环图，并重点分析组件之间的“接缝”——即边界处，因为没有任何单一组件负责验证跨边界的数据。这种方法比传统的测试清单更能发现集成问题。它提醒我们，在复杂系统中，风险往往隐藏于组件交互之处，而非单个组件内部。
Q&A
谷歌云工程师分享的十种AI提示词技巧的核心思想是什么？
核心思想是将AI用作对抗性审查者而非顺从助手，通过让模型以怀疑视角审查代码、测试、合规性等，降低人类假设风险，提升代码质量。
如何利用AI在编写代码前构建需求规格？
让模型扮演怀疑的首席架构师，禁止写代码，先列出技术、UX和架构考虑，然后提问，最后生成需求文档和实现计划。
如何让AI进行有效的代码审查而不是礼貌性反馈？
给模型设定严格的首席工程师角色，要求给出A到F的等级评分，并明确不轻易给A，同时要求提供具体的修复diff。
为什么建议分两次进行代码清理？
分两次分别关注缺失的测试和边缘情况，以及未使用的代码、过时注释等残留问题，能获得更精准的审查结果。
如何利用AI进行合规性检查？
让模型定位所有声明（如权限、作用域），与实际使用交叉引用，标记差距，提出修复建议，并在批准前不进行修改。
如何让AI基于外部研究生成审查清单？
让模型先研究特定技术栈中AI生成代码的常见安全漏洞和逻辑错误，然后基于这些发现构建针对性的手动审查清单。
如何自动化代码审查流程？
通过编写脚本（如Python）获取git diff，并调用AI模型进行对抗性审查，集成到CI/CD中，每次PR自动执行。
如何用图结构分析工作流以发现测试盲点？
让模型将应用工作流建模为有向无环图，识别组件间的“接缝”（seams），并针对这些边界生成高影响测试。
