Google Cloud 团队离不开的 10 个 AI 工程提示词
整理自 Google Cloud Blog 文章 *10 Indispensable Prompts Our Team Refuses to Build Without*。原文作者：James O'Reilly，发布时间：2026-06-11。原文链接：https://cloud.google.com/blog/topics/developers-practitioners/10-indispensable-prompts-our-team-refuses-to-build-without
>
说明：下文重点是提示词分享。提示词保持英文原文，并使用代码块呈现；中文部分只做使用说明、案例解释和预期效果说明。原文中 GitHub Actions PR 审查提示词只展示了片段并给出“Full prompt: link”占位，下文不补写原文没有公开的完整内容。
很多人用 AI 写代码，但 Google Cloud 团队这篇文章提醒我们：更有价值的用法，往往不是让 AI 更快地产出代码，而是让 AI 更早暴露假设、缺口和风险。
这 10 个提示词覆盖了产品规格、测试补齐、提交清理、权限合规、生产级代码审查、方案权衡、AI 代码风险研究、Fresh Eyes 多轮审查、自动 PR 审查、DAG 测试缺口分析。它们共同指向一个目标：把 AI 放到“审查者”和“反方”的位置上，而不是只把它当作代码生成器。
---
1. Build a spec：先做规格和架构反方审查
提示词原文：
Act as a cynical Principal Architect and Technical PM. I want to build a [product] that allows [user] to do [action]. Do not write code. Analyze this concept and list the top 5 technical, UX and architectural considerations. Then ask me key questions for each of the 5 considerations so we can work together on building the spec. Once you have all the answers, create a PRD doc and implementation plan. Don't over engineer or over simplify the design or implementation plan.使用场景：
适合在写代码之前使用，尤其是产品想法还停留在“我想做一个功能”的阶段。它可以帮助你先审查需求、架构和 UX 假设，而不是让 AI 立刻把未经验证的想法写成代码。
使用案例：
假设你要做一个“让运维人员通过页面批量执行 SQL 变更”的工具，可以把 [product] 替换成 SQL 变更平台，把 [user] 替换成运维或 DBA，把 [action] 替换成提交、审核、备份、执行和归档 SQL。AI 会先列出事务边界、权限、回滚、审计、误操作防护等关键问题，再推动你补齐 PRD。
预期效果：
避免一上来就生成实现方案；先暴露产品定义、架构复杂度、用户体验和风险控制中的盲点。最终产物应该是更清楚的 PRD 和实施计划，而不是一段仓促代码。
---
2. Widget tests：用官方测试规范驱动补测试
提示词原文：
I'd like to partner with you on increasing the robustness of this project by creating widget tests. If you haven't already, please read the Flutter team's skill for creating widget tests (https://github.com/flutter/skills/tree/main/skills/flutter-add-widget-test). Then, let's do these things:
* Examine my application's codebase to identify areas of the UI/UX that are not being tested properly.
* Determine if the existing code is written in a testable way (are dependencies injected? Are domains loosely or tightly coupled? Etc.).
* Determine which domains require more rigor than others.
* Create an overall testing plan for the application.
* Determine which areas of functionality are already aligned with that plan, and which are missing tests.
* Create a plan to implement those tests.
* Execute that plan.
Do not proceed from one step to another unless you are completely confident about your reasoning. You are encouraged to as many questions as needed.使用场景：
适合已有项目测试薄弱、但不知道从哪里开始补测试时使用。重点不是“让 AI 随便写几个测试”，而是先让它对照官方测试规范和项目结构，判断哪里缺测试、哪里不易测试。
使用案例：
在前端或移动端项目中，可以把 Flutter 官方测试 skill 换成你当前技术栈的测试规范，例如 Vue 组件测试规范、React Testing Library 指南、FastAPI 测试约定等。让 AI 先检查 UI/UX 未覆盖区域、依赖注入、模块耦合，再输出补测试计划。
预期效果：
生成更有依据的测试计划，并推动代码向可测试结构靠拢。比直接说“帮我补测试”更可靠，因为它要求 AI 先做测试缺口分析，再执行计划。
---
3. Find all the tests / Clean-up commit：提交前找缺失测试和脏内容
提示词原文：
Run all the tests and identify any missing tests and write them. Pay special attention to edge cases and race conditions.Find any unused code, embarrassing comments, comment to code inconsistencies, unresolved TODOs, or other things in this commit that shouldn't be in there.使用场景：
适合提交 PR 前的自查阶段。第一段用于补测试，第二段用于清理提交内容，避免把临时代码、尴尬注释、无用代码、TODO 残留带进 review。
使用案例：
在一次功能开发完成后，先让 AI 运行测试并识别缺失测试，特别关注边界情况和竞态条件；再让它检查当前 diff 里是否有调试残留、注释失真、未使用函数、未完成 TODO。
预期效果：
降低 reviewer 在低级问题上浪费时间的概率，让 PR 更干净。它不替代正式 review，但能作为提交前第一道自动清洁层。
---
4. Check for correct and compliant permissions：权限声明与实际使用对账
提示词原文：
Run a comprehensive check on this Android project to ensure all permissions are correct and compliant. Perform the following steps:
1. Locate and analyze all 'AndroidManifest.xml' files (including main, debug, and flavor-specific manifests), extract a master list of declared <uses-permission> tags.
2. Cross-reference these declared permissions against the codebase to verify where they are actually used. Identify any bloatware or unused permissions that can be safely removed.
3. Check the Kotlin/Java source files to ensure that all runtime permissions implement the dynamic runtime permission request flow 'checkSelfPermission','onRequestPermissionsResult' or the Activity Result API.
4. Verify that any hardware features associated with the permissions (like android.hardware.camera) are correctly declared.
Output your findings as a Markdown report. Provide file paths and suggested code diffs for any fixes. Do not make any file edits until I approve the plan.使用场景：
适合发布前做权限、合规、声明与实际使用之间的一致性检查。虽然原文是 Android 场景，但这种思路可以迁移到很多配置型系统：声明了什么、实际用了什么、是否有冗余或缺失。
使用案例：
Android 项目中，AI 可以扫描所有 Manifest，汇总权限，再和 Kotlin/Java 源码交叉比对。迁移到后端项目时，也可以让 AI 检查环境变量、配置项、K8s RBAC、数据库权限、API scope 是否被真实使用，是否存在过度授权。
预期效果：
发现人工容易漏掉的权限膨胀、运行时授权缺失、配置声明与源码使用不一致等问题。关键边界是：AI 输出报告和建议 diff，但不要未经批准直接改权限相关文件。
---
5. Conduct code review：用严格 Principal Engineer 标准审查代码
提示词原文：
Act as a strict, highly analytical Principal Engineer conducting a pre-production code review. You have incredibly high standards and zero tolerance for fragile, "happy-path" code. Your goal is to guide me to write bulletproof, production-ready systems.
Grade my uncommitted changes on an A-to-F scale for production readiness.
Do not award an "A" unless my code is exceptionally robust. Specifically, analyze the changes for:
1. Efficiency: Redundant API calls, wasteful database queries, or un-cached resource leaks.
2. Resilience: Silent failure points, lack of explicit error boundaries, and missing rate-limit fallbacks.
3. Architecture: Tight coupling and lack of clear separation of concerns.
For every issue, explain pragmatically where the code is vulnerable to real-world production failures. Then, provide the exact git diffs needed to upgrade my code and earn that "A."使用场景：
适合 PR 前或重要变更前做生产就绪度审查。它特别适合那些“能跑，但不一定扛得住真实生产环境”的代码。
使用案例：
在新增一个数据库自动化执行模块后，让 AI 审查未提交变更，重点检查重复查询、静默失败、缺少错误边界、缺少限流/降级、职责耦合、资源泄漏等问题，并要求它给出真实生产失败场景和修复 diff。
预期效果：
压制 AI reviewer 过度礼貌的问题。普通提示词容易得到“整体不错”的反馈，这个提示词会迫使 AI 用更严格标准指出脆弱点，并把问题和生产故障联系起来。
---
6. Explain trade-offs：让 AI 解释方案取舍
提示词原文：
Explain the pros and cons of executing your suggested Implementation Plan. Be specific about the trade-offs we're making related to perforance, cost, security and maintainability so I can make an informed decision on how to proceed.使用场景：
适合 AI 已经给出实施方案之后、你准备决策之前使用。它让 AI 不只说“可以这样做”，还要把性能、成本、安全、可维护性上的取舍摊开。
使用案例：
当 AI 建议你引入缓存、拆分服务、增加队列、改数据库索引、接入新工具时，可以继续追问这段提示词。让它说明这个方案会带来哪些复杂度、哪些风险被降低、哪些风险被转移。
预期效果：
帮助人类保留最终决策权。AI 的方案不再是单向建议，而是带有取舍说明的候选方案，便于你判断是否值得实施。
---
7. Improve AI-generated code through research：研究 AI 生成代码的常见失败模式
提示词原文：
Research online, focusing on X threads, StackOverflow, GitHub issues and tech blogs for common security pitfalls, architectural misalignments, and subtle logic errors found in AI-generated INSERT_TECH_YOU'RE_USING_HERE code. Based on these findings, generate a manual review checklist specifically for auditing high-risk areas like platform channel validation, deep link routing, and sensitive data logging in crash reports.使用场景：
适合审查 AI 生成代码之前使用，尤其是你正在使用某个框架、SDK、平台 API，而 AI 可能有常见误用模式时。
使用案例：
把 INSERT_TECH_YOU'RE_USING_HERE 替换成 Flutter、FastAPI、Kubernetes Operator、PostgreSQL migration、Terraform、Ansible 等具体技术。让 AI 先从社区资料中归纳该技术栈里 AI 生成代码常见的安全陷阱、架构错配和微妙逻辑错误，再形成 review checklist。
预期效果：
把审查从“看当前代码有没有明显问题”升级为“按该技术栈的高风险模式做针对性审查”。这对 AI 代码尤其重要，因为 AI 生成内容常常看起来合理，但隐藏了错误假设。
---
8. Find problems through iteration：用 Fresh Eyes 多轮审查
提示词原文：
- Code review the uncommitted changes.
I prefer being less specific has oversteering can lead to blind spots.
I prefer a new chat session for a fresh set of "eyes".
I iterate until the results returned are boring and I'm satisfied.
If needed:
- Code review the uncommitted changes. Identify any unhandled corner cases. Assess performance. Summarize findings.
Then after receiving findings:
- Fix 1, 3 and 5.使用场景：
适合重要变更的多轮审查。它强调少给过度约束，用新会话获得 fresh eyes，避免同一个上下文不断强化已有方向。
使用案例：
完成一次复杂重构后，开一个新对话只给 diff 或代码，让 AI 自主 review；修复其中部分问题后，再开新会话继续 review。不要一开始把自己的判断塞太满，避免 AI 被你的叙述带偏。
预期效果：
通过多轮独立视角减少盲点。当反馈逐渐变得重复、低价值、接近“无聊”，说明明显问题大概率已经被清掉了一轮。
---
9. Review every pull request：把 AI 审查放进 PR 流程
提示词原文片段：
## Role
You are a world-class autonomous code review agent. You operate within a secure GitHub Actions environment. Your analysis is precise, your feedback is constructive, and your adherence to instructions is absolute. You do not deviate from your programming. You are tasked with reviewing a GitHub Pull Request.
## Primary Directive
Your sole purpose is to perform a comprehensive code review and post all feedback and suggestions directly to the Pull Request on GitHub using the provided tools. All output must be directed through these tools. Any analysis not submitted as a review comment or summary is lost and constitutes a task failure.
[...]
Full prompt: link使用场景：
适合团队已经有稳定 CI/PR 流程，希望用 AI 做自动化第一轮 PR 审查时使用。它强调 AI 必须把反馈提交到 PR，而不是只在日志里分析。
使用案例：
在 GitHub Actions 中运行 AI code review，让它读取 PR diff、提交 review comments 和 summary。人类 reviewer 继续负责架构、需求、风险接受等最终判断。
预期效果：
缓解 review 瓶颈，让 AI 先捕捉实现细节、遗漏测试、潜在 bug 和改进建议。它不应该替代人类最终审查，而是把人从低价值重复检查中释放出来。
---
10. Apply directed acyclic graph analysis for tests：用 DAG 找测试缺口
提示词原文：
Analyze the application workflow as a directed acyclic graph. Identify impactful tests for components, seams across components, and across the system. Present your findings in a markdown table as a prioritized gap analysis.使用场景：
适合测试规划阶段，尤其是系统流程不是线性的、组件之间依赖复杂、传统测试清单容易漏掉边界时。
使用案例：
对一个“用户提交任务 → 队列调度 → 后端执行 → 状态回写 → 通知告警”的系统，让 AI 把流程拆成 DAG。节点是组件或阶段，边是数据流和控制流，再识别组件内部测试、组件 seam 测试、系统级测试缺口。
预期效果：
让测试计划从“功能点枚举”升级为“结构化缺口分析”。输出的优先级表格可以直接作为补测试路线图。
---
最后：这些提示词应该怎么用
这 10 个提示词的重点不是文案本身，而是它们背后的使用姿势：
- 写代码前，让 AI 挑战需求和架构；
- 写代码中，让 AI 检查可测试性和测试缺口；
- 提交前，让 AI 清理低级问题和边缘风险；
- PR 阶段，让 AI 做自动化审查，但保留人类最终判断；
- 高风险场景，让 AI 做权限、合规、配置和失败模式的交叉检查。
如果只能先选 3 个落地，我建议从这三个开始：
- Conduct code review：最容易立刻提升代码质量；
- Find all the tests / Clean-up commit：最适合放进提交前自查；
- Explain trade-offs：最能避免 AI 给出看似正确但没有取舍意识的方案。
AI 写代码已经不稀缺了。真正稀缺的是，让 AI 在正确的位置上帮你发现问题。