待翻译：What We Can Learn From Google Engineers’ Indispensible Prompts

AI 服务暂时不可用，以下为来源正文，待恢复后补全翻译。

--> What We Can Learn From Google Engineers’ Indispensible Prompts - KDnuggets --> Join Newsletter Most people's prompt history looks like a junk drawer. A one-off request to explain an error message, a quick "clean this up," a boilerplate generator used once and forgotten. In June 2026, Google Cloud's developer relations team published something different: they asked ten of their own engineers and leaders one specific question: what prompt do you personally refuse to work without, and why? What came back wasn't a list of clever phrasings. It was ten different engineers, independently arriving at the same underlying move: using AI as an adversarial second opinion rather than an agreeable assistant. That distinction is the entire subject of this article. Below are ten techniques pulled from that piece, each one explained, attributed to the engineer who shared it, and then rebuilt as an original example prompt you can actually use — not copied verbatim, but reconstructed to show the same pattern at work. Every example applies to one running project: a small task-tracker REST API, so the techniques build on each other instead of resetting to a new hypothetical every section. # Building the Spec Before Any Code Exists Maja Bilić, a Senior Outbound Product Manager at Google Cloud, doesn't start with code; she starts by making the model argue with her. Her technique assigns the model a specific, skeptical persona (a cynical principal architect and technical PM), explicitly forbids it from writing code, and has it list the key technical, UX, and architectural considerations for the idea before asking targeted questions on each one. Once that back-and-forth is done, the model turns the answers into an actual requirements document and implementation plan, with an instruction not to over-engineer or oversimplify either direction. The reasoning is worth sitting with: a model asked to help "plan a feature" will often just agree with the first framing you give it. A model asked to critique a concept from a skeptical persona has to generate actual objections first, and those objections are usually where the real planning value is. Applied to the task tracker: Act as a skeptical principal architect reviewing a proposed feature, not writing code yet. I want to add recurring tasks to a task-tracker API, tasks that regenerate on a schedule (daily, weekly, custom RRULE). Do not write any code. List the top 5 technical, data-model, and UX considerations this feature raises. For each one, ask me the specific questions you need answered before this could be built responsibly. Once I've answered all of them, draft a short spec and implementation plan. Don't over-engineer this for scale we don't have, and don't oversimplify by ignoring timezone or edge-case handling. # Making Testing Non-Negotiable Andrew Brogdon, a Staff Developer Relations Engineer, uses a prompt that treats testing as something to audit rather than generate. Rather than asking for tests directly, his pattern has the model first examine the codebase to find which parts of the UI or logic aren't properly covered, judge whether the existing code is even written in a testable way (dependencies injected, domains loosely coupled), and only then build and execute an actual testing plan — moving one confident step at a time rather than rushing straight to output. The insight underneath this one is simple but easy to skip: asking directly for tests gets you tests for whatever's easiest to test, not what actually needs coverage. Auditing testability first catches the gap between "tested" and "well-tested." Applied to the task tracker: Partner with me on improving test coverage for this task-tracker API. First, examine the codebase and identify which endpoints and business logic aren't properly tested. Then assess whether the current code is actually written in a testable way, are external calls injected or hardcoded, is the scheduling logic isolated from the HTTP layer. Build a prioritized testing plan based on what you find, tell me what's already covered, then implement the missing tests. Don't skip ahead to writing tests until you're confident in your assessment of what's actually missing. # Running the Two-Prompt Cleanup Pass Aja Hammerly, Director of Builder Relations, runs two separate, narrow prompts before handing code to review — deliberately in a fresh conversation with no development context attached. The first asks the model to run the existing tests, then specifically hunt for missing edge cases and race conditions. The second, run separately, looks for a different category entirely: unused code, leftover debug comments, comments that no longer match the code they describe, and unresolved TODOs — the kind of small, embarrassing residue that piles up while you're focused on the main path through a feature. Running these as two distinct prompts rather than one combined request matters more than it looks like it should. A single broad "review this" prompt tends to blend everything into a generic pass. Separating "what's structurally missing" from "what's sloppy leftover" gets sharper answers on both. Applied to the task tracker: [Fresh conversation, no prior context] Run the test suite for this project and identify any missing tests. Pay specific attention to edge cases (empty recurrence rules, timezone boundaries) and race conditions (two requests updating the same task simultaneously). Write the missing tests. [Same fresh conversation] Look through this commit for unused code, leftover debug comments, comments that no longer match what the code actually does, unresolved TODOs, or anything else that shouldn't ship. List each one with a file and line reference. # Running Domain-Specific Compliance Checks Rich Hyndman, Head of Antigravity Developer Relations, shared a highly specific Android permissions audit: locate every manifest file across build variants, extract the declared permissions, cross-reference them against actual usage in the codebase to find bloat, verify runtime permission flows are implemented correctly, and confirm any hardware-feature declarations line up. Crucially, the prompt ends with an explicit instruction not to make any edits until the plan is approved. The pattern generalizes well past Android. Any compliance or configuration surface — environment variable usage, API scope grants, IAM role assignments — benefits from the same shape: locate every declaration, cross-reference against actual usage, flag the gap, propose fixes, wait for approval before touching anything. Applied to the task tracker (its API authentication scopes, in this case): Run a compliance check on this API's authentication scopes. Locate every place a required OAuth scope is declared (route decorators, middleware config, API gateway rules) and build a master list. Cross- reference that list against where each scope is actually checked in the code, and flag any declared scope that's never enforced, or any enforced check that isn't declared anywhere. Output a markdown report with file paths and suggested diffs. Do not make any edits until I approve the plan. # Grading Your Own Code Like a Harsh Reviewer Shir Meir Lador, Head of AI Developer Relations, names a real problem directly: ask a model for a code review, and it usually defaults to polite — a compliment on naming, a suggestion for a docstring, a green light. Her fix is to assign a specific, demanding persona (a strict principal engineer with zero tolerance for happy-path code), then force an actual letter grade (A through F) on production readiness, explicitly instructing the model not to hand out an A unless the code is genuinely robust across efficiency, resilience, and architecture. The prompt closes by requiring exact fixes, not just commentary. This is worth using specifically because of how well it exposes the gap between "this code looks fine" and "this code is fine." A grading rubric with a real failing condition forces the model to actually look for what would break, rather than defaulting to encouragement. Applied to the task tracker: Act as a strict principal engineer doing a pre-production review. Zero tolerance for fragile, happy-path-only code. Grade my uncommitted changes A through F for production readiness, don't give an A unless it's genuinely robust. Specifically check for: redundant database queries or missing caching, silent failure points and missing error boundaries around the scheduler, and tight coupling between the recurrence logic and the HTTP layer. For every issue, explain exactly how it fails in production, then give me the git diff to fix it and earn that grade. # Making the Model Defend Its Own Plan James O'Reilly, the post's author and a Staff Developer Relations Engineer, uses one of the shortest prompts on the list — and it's arguably the most important: after getting an implementation plan, ask the model to explicitly lay out the trade-offs of its own suggestion across performance, cost, security, and maintainability. The goal isn't more code; it's forcing the model to stress-test its own reasoning rather than letting its first suggestion stand unchallenged. This directly counters a specific failure mode of working with AI on technical decisions: it's easy for a model's confident, well-formatted plan to feel like a settled decision rather than one option among several. Making it list what it's trading away keeps a human in the actual decision seat. Applied to the task tracker: Explain the trade-offs of the recurring-tasks implementation plan you just proposed. Be specific about what we're giving up on performance, cost, security, and long-term maintainability compared to at least one alternative approach, so I can make an informed call instead of just taking your first plan as final. # Turning Outside Research Into a Review Checklist Emma Twersky, Head of Flutter & Dart Developer Relations, points the model outward before it looks inward: research real-world security pitfalls, architectural mistakes, and subtle logic errors specific to AI-generated code in a given tech stack — drawing on developer forums, GitHub issues, and technical blogs — then convert those findings into a targeted manual review checklist for the highest-risk parts of the codebase. The reasoning behind this one carries real weight. A well-known 2022 study on GitHub Copilot — analyzing 1,689 generated programs across 89 security-relevant scenarios, found that roughly 40% contained a real vulnerability — a finding that later, larger studies have continued to reinforce rather than overturn. AI-written code doesn't look wrong. It compiles, it passes a casual glance, and that's exactly what makes an external, evidence-based checklist more useful than a generic "review this for bugs" request. Research current security pitfalls and subtle logic errors commonly found in AI-generated FastAPI code, focusing on developer forums, GitHub issue trackers, and recent technical write-ups. Based on what you find, build a manual review checklist specifically for auditing this project's highest-risk areas: the scheduling/cron logic, webhook signature verification, and how task ownership is checked on update requests. # Iterating in Stages, Not One Mega-Prompt Fred Sauer, Head of Frameworks & Languages Developer Relations, doesn't describe a single prompt so much as a staged workflow. Early on, in a discovery phase, he deliberately stays less specific — arguing that being too prescriptive early creates blind spots the model won't think to question. That's followed by a proof-of-concept pass just to confirm the idea is buildable at all, then refinement toward something he'd be satisfied to have written himself, and only at the end — in a fresh conversation for a genuinely new perspe [truncated for AI cost control]