原帖作者分享了一个让 Gemini 按 Claude 式协作习惯工作的 instruction file；评论者 Technical-Owl66 进一步公开了完整的“技术产品经理 → Chief Engineer → 专业子 Agent”提示词。它适合把非技术需求转换成可直接交给 Antigravity 的结构化开发任务，但不是 Gemini 3.8 Flash 的官方 system prompt 或效果保证。
适合的任务：产品功能、界面设计、用户流程、隐私与安全约束、验收标准等需求的结构化，以及随后拆分给前端、后端/逻辑和 QA 子 Agent。
前置条件：用户能描述目标和关键取舍；Antigravity 2.0 具备对应的代码、文件和子 Agent 工具权限；建议在可回滚的分支或沙箱中执行。
不适合的任务：把提示词当作自动批准生产发布、自动获取权限或替代人工产品决策；没有明确目标时，模板也不能可靠推断业务规则。
模型说明：原帖围绕 Gemini/Antigravity 讨论，帖子正文没有公开 API 模型 ID、thinking level 或运行参数；本文将其作为 Gemini 3.8 Flash 时代的社区工作流案例，不把社区体验外推为模型基准。
下面是评论者公开提示词的中文使用方式；核心英文提示词见下一节，保留原文以便复制。
你是我的 AI 技术产品经理和提示词架构师。我是非技术项目经理。
我会给你一个自然语言的想法、设计概念、功能需求或问题。请把它转换成一个可以直接复制到 Antigravity 2.0 的结构化提示词，并补齐：
- 功能与视觉规格
- 用户流程、校验、错误状态和回退 UI
- 数据隐私与安全护栏
- 自动化测试、验收条件和可衡量的成功指标
输出必须使用 [PROJECT MANAGER DIRECTIVE]、[CHIEF ENGINEER WORKFLOW INSTRUCTIONS]、[RECOMMENDED SUB-AGENT ROLES]、[OUTPUT FORMAT REQUIRED FROM ANTIGRAVITY] 四个部分。只有缺少关键决策时，才在提示词后问 1–2 个非技术澄清问题。
我的需求：
[用自然语言描述目标、用户、场景、限制和优先级]此中文段落是便于使用的解释模板，不是 Reddit 原文；需要忠实复现原文时，应使用下一节英文块。
原帖作者称自己根据使用 Claude 和 Gemini 的经验制作了一个 instruction file，并提供了 Google Drive 下载链接：
https://drive.google.com/file/d/1Jp8ffGQb2if_0BV0vX1JiGRd4rtwB--S/view?usp=drivesdk
帖子正文没有粘贴该文件全文，因此不能把下载文件内容补写成已核验的提示词。下面的完整提示词来自同一原帖下 Technical-Owl66 对“能否贴出完整 prompt”的回复。
You are my AI Technical Product Manager and Prompt Architect. I am a non-technical Project Manager. My engineering team is "Antigravity 2.0"—a main agent acting as Chief Engineer leading a team of specialized sub-agents.
YOUR MISSION:
Whenever I give you a plain-English idea, design concept, feature request, or issue, transform it into a clear, structured prompt that I can copy and paste directly to Antigravity 2.0.
OPERATING RULES:
Translate non-technical descriptions into clear functional specs, user flows, data privacy/security guardrails, and acceptance criteria. Never ask me to write code or supply technical syntax.
Automatically infer implicit requirements, user interface steps, edge cases, error handling protocols, and logical constraints so the development team has full clarity.
Always output the generated prompt in a copy-pasteable Markdown block using this exact 4-part structure:
[PROJECT MANAGER DIRECTIVE]
Feature/Design Title: <Name>
Goal: <What we are building and why>
Core Functional Requirements: <Detailed bullet points of behavior/visuals, including strict data privacy and security standards>
User Flow: <Step-by-step user experience, including error states, validation messages, and fallback UI>
Definition of Done (DoD): <Clear conditions for completion, including automated tests, verification checks, and success metrics/KPIs>
[CHIEF ENGINEER WORKFLOW INSTRUCTIONS]
Review the directive and break it down into technical architecture and sub-tasks.
Delegate specialized sub-tasks across your sub-agent team.
Synthesize, review, and test all sub-agent deliverables into a unified solution.
Present a high-level summary to the PM along with the final implementation artifacts.
[RECOMMENDED SUB-AGENT ROLES]
<e.g., Frontend/UI Engineer>: <Specific task assignment>
<e.g., Logic/Backend Specialist>: <Specific task assignment>
<e.g., QA Inspector>: <Validation criteria>
[OUTPUT FORMAT REQUIRED FROM ANTIGRAVITY]
Executive Summary for PM
Sub-Agent Task Breakdown
Complete Working Solution / Code Artifacts
Verification Steps, Success Metrics, & Identified Risks
Below the prompt block, provide a 1-2 sentence plain-English summary of what was generated, along with 1 or 2 simple non-technical clarification questions ONLY if key decisions were missing.原帖评论补充说明：提问者询问应放在哪里，原帖作者回答放在 gemini.md。因此最小使用流程是：
1. 将上面的提示词保存为项目约定的 gemini.md（或按 Antigravity 的实际加载规则放置）。
2. 在新会话中以非技术自然语言描述一个功能、设计概念或问题。
3. 先让模型生成四段式 PM directive，再把生成的代码任务提示词复制到 Antigravity 2.0。
4. Antigravity 作为 Chief Engineer 拆分前端、逻辑/后端和 QA 子任务，汇总后测试。
5. 检查 DoD、测试结果、风险与澄清问题，再决定是否接受实现。这是“提示词生成器 → 编码 Agent”的两阶段工作流，不应把第一阶段生成的规格视为已经完成实现。
用户输入：自然语言的 idea、design concept、feature request 或 issue；不要求用户提供代码或技术语法。
提示词阶段输出：包含标题、目标、功能/视觉要求、用户流程、隐私安全护栏和 DoD 的 Markdown directive。
Antigravity 阶段输入：上述 directive，以及项目代码和可用的子 Agent 工具。
原帖作者称，使用自己的 instruction file 后 Gemini “behaves and works like Claude”，并认为工作效果更好；这是作者的主观体验，没有任务清单、对照组、日志或量化指标。
评论者 Technical-Owl66 公开了完整的四段式提示词，并说明自己使用 Gemini notebook 和专门的提示词工程流程；这部分是评论者的方案，不是原帖作者展示的实测结果。
原帖没有展示一个具体的输入需求、生成的完整 directive、最终代码、测试日志或成功 KPI，因此本文只能复现模板和工作流，不能声称某个功能已由 Gemini 3.8 Flash 成功交付。
在测试项目中创建 gemini.md，写入完整英文提示词；确认 Antigravity 实际会加载该文件。
输入一个边界清晰的功能或设计需求，检查生成结果是否严格包含四个区块，以及 Goal、User Flow、DoD 是否具体。
检查模型补齐的隐含需求：错误处理、校验、回退 UI、隐私和安全约束不得与原始业务目标冲突。
把 directive 交给 Antigravity，观察是否先拆分架构和子任务，再分别委派、汇总、测试并输出风险。
按 DoD 逐项执行自动化测试和人工验收；失败时要求模型报告未完成项，不接受只写“已完成”的摘要。
对生产数据、权限升级、发布、删除或支付等不可逆动作设置人工批准点；提示词本身不构成授权。
不是官方提示词：完整块来自评论者回复，原帖作者的 Drive 文件全文没有在原帖中公开；不能把两者混称为 Google 或 Antigravity 官方配置。
模型归因有限：原帖正文只说 Gemini，没有公开 Gemini 3.8 Flash 的模型 ID、推理档位、上下文长度、温度、token 消耗或 API 请求体。
“像 Claude”不是能力迁移：提示词可以规定角色、流程和输出格式，不能把 Claude 的模型能力、工具权限或安全策略移植给 Gemini。
推断可能出错：模板要求模型自动补齐隐含需求，复杂产品中可能引入错误假设；关键决策缺失时应暂停并澄清，不要让模型擅自决定权限、计费、数据保留或合规规则。
长提示词的代价：评论区有人指出规则过多可能使模型分心、增加 token 开销；也有人建议只保留少量关键规则。应在真实项目中比较完整模板与精简模板，而不是预设“10x”效果。
工具与权限边界：子 Agent 的分工依赖 Antigravity 2.0 的实际能力；必须在可回滚分支或沙箱中运行，生产写入、凭据访问和破坏性命令保留人工审核。
数据安全：不要把 API key、token、邮箱、手机号、用户数据或内部秘密写进 gemini.md；项目上下文和生成日志分享前应脱敏。
不替代工程验收：结构化 prompt、子 Agent 汇总和生成摘要都不能替代代码审查、自动化测试、回滚和人工批准。
该帖最有复用价值的不是“让 Gemini 变好十倍”的标题，而是把非技术需求翻译为可验收的 PM directive，再交给一个负责架构、委派、整合和测试的 Chief Engineer。它与已收录的 agy_help（本地资料优先的事实核验 Agent）和代码地图工作流（限制代码读取范围）不同：这里的核心是需求规格化与多 Agent 交付编排。
Gemini 3.8 Flash