Antigravity-您的智能编程助手

Antigravity 是由 Google DeepMind 团队开发的强大代理 AI 编程助手。我致力于与您一起协作，解决复杂的编码任务，并为您提供高效、优质的代码实现方案。

---

📘 用 Antigravity 从 0 到 1 打造规划设计院合同管理系统：完整方法总结

🧭 一、为什么要先写 GEMINI.md，而不是直接开干

在使用 Antigravity 开发正式项目时，第一步不应该是“直接让它写代码”，而应该是先为它建立一套稳定的行为规则。
原因很简单：Antigravity 本质上是协作开发代理，如果没有提前约束，它很容易出现以下问题：

• 输出语言不稳定，时而中文时而英文
• 上来就大改架构
• 不看上下文就开始写代码
• 编造接口、字段、文件结构
• 把正式系统写成演示项目
• 喜欢一次性铺很大，导致后续返工

因此，最先做的事情，是编写一份项目级的 GEMINI.md，让 Antigravity 明确自己的角色、工作方式、输出规范和工程边界。

---

📏 二、GEMINI.md 的核心目标是什么

这份规则文件的目标，不是“让它更聪明”，而是“让它更稳定、更像正式团队里的工程师”。

整个规则体系主要围绕以下几点建立：

1. 统一输出语言

所有分析、计划、说明、总结必须使用简体中文。
只有代码关键字、字段名、接口名、库名等必要内容保留英文。

2. 强制先读上下文

在任何中等及以上复杂度修改前，必须先阅读相关文件、理解结构、再给出简短计划，不能直接动手。

3. 坚持最小必要改动

优先复用现有结构、组件、hooks、services、types 和样式体系，不允许无关重构。

4. 明确禁止编造

没有看到的文件、接口、字段、环境变量、数据库结构，不得假装存在。必要时必须说明“这是基于当前上下文的合理假设”。

5. 按正式系统标准开发

不是做演示页，不是做静态原型，而是按可维护、可扩展、可上线的正式项目思路实现。

6. 面向 Next.js / Web App / 后台系统

规则中进一步加强了：

• Server / Client Component 边界
• App Router / Pages Router 的遵循
• 表单、权限、列表、CRUD、Dashboard、SaaS 后台等常见场景的规范

最终形成了三套可用版本：

• GEMINI.md 精简版
• GEMINI.md 完整版
• 超短前置规则版

其中，完整版最适合正式的 Next.js / SaaS / 后台管理系统项目。

---

🏗️ 三、为什么这个项目不能只靠一句提示词

在确定要做“规划设计院合同管理系统”时，一个关键认识是：

不能只给 Antigravity 一句“帮我做一个合同管理系统”。

因为这个项目不是普通网站，而是一个规划设计院内部使用的正式 Web 管理系统，还包含：

• 前端
• 后端接口
• 数据库
• 权限控制
• 合同全生命周期
• 附件归档
• 财务跟踪
• 风险预警
• 报表导出
• 审计日志

如果只给一句笼统提示，Antigravity 很容易做成：

• 通用 CRUD 空壳
• 电商后台风格
• 普通 CRM 风格
• 逻辑散乱、字段泛化的演示项目

所以我们后来采用的不是“单条提示词”，而是分层提示法。

---

🧱 四、建立项目提示体系：不是一句话，而是一整套提示包

为了让 Antigravity 稳定输出，我们把提示拆成了多层：

1. 项目总提示词

用于第一轮校准项目背景，告诉它：

• 这是规划设计院内部系统
• 是正式商用后台，不是演示页
• 要有数据库
• 要有权限
• 要管理合同全生命周期
• 所有输出用简体中文
• 要拆成小闭环逐步实现

2. 总体方案提示词

让它不要急着写代码，而是先输出：

• 系统定位
• 功能模块
• 角色权限
• 生命周期流程
• 页面结构
• 数据库建议
• 开发优先级

3. 数据库设计提示词

要求它围绕规划设计院场景，设计：

• 用户、角色、部门
• 客户、项目
• 合同主表
• 收款计划
• 实收款
• 发票
• 附件
• 审批
• 操作日志

4. 角色权限提示词

要求它区分：

• 页面权限
• 按钮权限
• 数据权限
• 本人 / 本部门 / 全院可见范围
• 服务端权限控制

5. 页面结构提示词

要求它设计：

• 菜单树
• 页面用途
• 列表字段
• 筛选项
• 详情页分区
• 可执行操作

6. 模块开发提示词

用于实际开发时每次只做一个小闭环，比如：

• 合同列表页
• 新增合同页
• 合同详情页
• 项目立项页
• 收款计划子表
• 附件上传
• 实收款
• 发票记录

7. 通用开发约束提示词

每次开发前都补一句，压住它的风格漂移：

• 先看上下文
• 最小改动
• 不无关重构
• 不编造
• 重视权限与一致性

8. 开发后自检提示词

每次模块完成后，要求它自查：

• 是否有无关改动
• 是否补了 loading / empty / error
• 是否有假设未说明
• 是否有权限或数据风险

这套方法后来证明非常有效，比一句大而化之的“帮我做系统”稳得多。

---

🏢 五、项目本身如何定义：为什么必须强调“规划设计院场景”

这个系统之所以需要专门强调“规划设计院”，是因为它不是普通销售型合同管理。

它有很强的行业特征：

• 一个客户往往有多个项目
• 一个项目可能对应多个合同或补充协议
• 合同必须强关联客户、项目、部门、负责人
• 合同金额、收款节点、开票情况、归档资料都很重要
• 管理重点不只是“台账”，更是“业务管理 + 财务协同 + 过程留痕”
• 不同角色关注点不同：
  • 经营人员关注签约与推进
  • 财务关注收款与开票
  • 负责人关注项目与履约
  • 管理层关注风险与总览

正因为这些特征，整个系统必须围绕：
客户 → 项目 → 合同 → 收款计划 → 实收款 → 发票 → 附件 → 风险看板
这一条主链去设计。

---

🛠️ 六、开发不是按“轮次概念”，而是按 Antigravity 的实施蓝图推进

在实际推进中，我们明确放弃了继续围绕抽象“方案轮次”打转，而是转向 Antigravity 生成的 implementation_plan.md，把它作为真正的主线蓝图。

这份方案把项目拆成多个 Sprint，更接近正式工程实施节奏：

Sprint 1：基础设施与系统基座

• Next.js 项目骨架
• 登录与鉴权
• RBAC 基础
• 通用基础组件

Sprint 2：客户与项目基座

• 客户库管理
• 项目立项管理

Sprint 3：合同核心

• 合同台账
• 合同起草向导
• 合同详情页
• 收款计划
• 附件归档

Sprint 4：财务履约链路

• 实收款
• 发票
• 三角经营链

Sprint 5：全局看板与增强

• 管理层 Dashboard
• 导出报表
• 审计日志

这样一来，开发就不再是“想到哪做哪”，而是沿着一个可验证、可回头、可交付的实施路线推进。

---

🧩 七、Sprint 1：先搭地基，而不是先做业务页面

第一阶段并没有急着做合同页面，而是优先把基座搭起来。

重点完成了：

1. 项目骨架

建立项目目录、路由分组、后台布局、顶栏与侧栏等基础结构。

2. 登录与鉴权

建立最小可运行的登录页、登录态管理、路由保护和当前用户获取能力。

3. RBAC 基础

建立用户、部门、角色、关系模型，为后续数据权限埋下基础。

4. 通用基础组件

统一整理和实现：

• ProTable
• FilterBar
• Modal
• Uploader
• StatusTag
• Feedback

这样做的价值很大：后续客户、项目、合同、财务模块都能在统一底座上快速组装，而不是每个页面都从零写起。

---

🧑‍💼 八、Sprint 2：先做客户，再做项目，补齐“合同的母体”

客户库管理

客户模块按规划设计院场景做了专门收敛，没有套电商字段，而是更关注：

• 统一社会信用代码/税号
• 客户性质（政府、国企等）
• 信用风险评级
• 商务属性

实现了：

• 客户列表
• 新增/编辑
• 详情页
• 基础筛选与分页

项目立项管理

在做合同前，先补齐项目模块，这一步非常关键。
因为合同不能悬空存在，必须挂在：
客户 1:N 项目，项目 1:N 合同
这条链路上。

项目模块至少补上了：

• 项目编号
• 项目名称
• 客户关联
• 工程类型
• 预计产值 / 预算
• 计划起止期
• 状态
• 默认归属人与部门

到这里，合同的“上游母体”才真正建立起来。

---

📄 九、Sprint 3：以合同为中心，建立主业务引擎

1. 合同台账

首先做的是合同台账骨架，而不是超级复杂详情页。
它承担了：

• 多维筛选
• 分页
• 权限隔离（本人 / 本部门 / 全院）
• 详情入口

2. 合同起草向导

没有一开始就做超重表单，而是按“先主表，再增强”的原则推进。

合同起草首先完成了：

• 客户 → 项目 级联选择
• 项目基准信息自动带出
• 合同主表字段录入
• 服务端锁定归属字段继承
• 合同主表成功入库

这里强调了一个关键策略：
先让合同主表可靠入库，再逐步挂子模块。

3. 合同详情页

详情页作为聚合中心，不追求一开始塞满，而是预留挂载位，后续逐步点亮。

4. 收款计划子表

围绕合同详情页挂接了 PaymentPlan，实现：

• 一对多收款期次
• 金额累计保护
• 状态展示
• 列表与表单管理

5. 附件归档模块

附件模块以合同详情页为中心，完成了：

• 文件元信息建模
• 上传、下载、删除
• 分类管理
• 与合同 ID 稳定绑定

这一步使系统第一次具备“档案沉淀”能力。

---

💰 十、Sprint 4：让“计划”变成“实际发生”

这一阶段的重点，是把财务链路补完整。

1. 实收款记录

围绕合同详情页继续挂接 ReceiptRecord，实现：

• 实收款登记
• 与合同总金额的累计保护
• 可选关联某一期收款计划
• 列表、编辑、删除
• 回款率与资金进度展示

2. 发票记录

继续挂接 InvoiceRecord，实现：

• 开票记录列表
• 开票金额、税率、税额计算
• 发票类型、号码、备注
• 合同总盘保护
• 与合同税率逻辑联动

3. 单合同三角统计看板

当 PaymentPlan、ReceiptRecord、InvoiceRecord 三者都具备后，合同详情页头部进一步升级为经营驾驶舱，集中展示：

• 合同总金额
• 计划收款总额
• 已收款
• 已开票
• 未收款
• 未开票

并揭示两大关键风险：

已票未收

表示已经开票，但现金没回来，存在垫资与坏账风险。

已收未票

表示钱已经到账，但票没开完，存在合规与客户索票压力。

这一步完成后，单合同级的“业财税三角闭环”就真正形成了。

---

📊 十一、Sprint 5：从单合同走向全局经营视角

当单合同闭环稳定后，系统开始往管理层视角演进。

1. 全局经营 Dashboard

为了避免过早引入重型图表库，采用轻量 CSS 和服务端聚合方式，搭建了院级管理看板，包括：

• 合同总数与总金额
• 收款计划总盘
• 已收款总额与回款率
• 已开票总额与开票占比
• 合同状态分布
• 计划 → 开票 → 回款 漏斗
• 全局已票未收 / 已收未票 / 逾期计划风控指标

这里还特别强调了一个正确的统计口径：
风险不能在全局上直接抵消，而应先按单合同计算，再汇总。
否则会出现一个合同的好数据把另一个合同的风险“冲平”的假象。

2. 合同台账导出

为了让系统更像可交付的正式工具，又补上了“合同台账导出 Excel”能力。

导出具备几个很重要的特性：

• 继承当前筛选条件
• 继承当前权限隔离
• 支持更多深水区指标
• 文件命名规范
• 使用按需加载的 xlsx 减少首屏包体积

3. 审计日志

系统级审计日志作为 MVP 最后一个重要增强项落地，建立了：

• 登录留痕
• 合同新增/修改/删除留痕
• 收款计划、实收款、发票、附件、导出行为留痕
• 仅管理员可见的审计视图
• 多维筛选能力

到这里，系统的“经营可视 + 安全留痕”能力同时具备。

---

✅ 十二、什么时候算 MVP 通过

在整个协作过程中，一个很重要的节点是：什么时候停止“继续加功能”，转而进入试运行。

最后的判断是：

这套系统已经达到 MVP 验收标准

因为它已经完整打通了：

• 权限与登录
• 客户与项目
• 合同建档与台账
• 收款计划
• 实收款
• 发票
• 附件归档
• 单合同预警
• 全局 Dashboard
• 合同导出
• 审计日志

这意味着它已经不只是“原型”，而是具备了正式内部试运行价值的系统。

---

🧪 十三、为什么此时不该继续无节制加功能，而要先准备内部体验版

当 MVP 核心链路完成后，下一步最正确的动作，不是继续埋头加功能，而是：

先准备内部体验版

原因有三个：

1. 真实用户反馈比闭门造车更重要

继续开发更多功能，边际收益已经下降。
此时最需要的是让真实用户跑流程，暴露问题。

2. 可以做预期管理

很多 MVP 的“留白”如果不提前说明，很容易被误判成 Bug。
所以必须写说明文档。

3. 有助于进入第二阶段的正确排期

只有知道真实使用中最痛的点，第二阶段的优先级才能排得准。

因此，最终又专门让 Antigravity 准备了：

• 《系统试用说明 / 操作指引》
• 《当前版本已知限制说明》
• 《内部反馈收集模板》
• 《下一阶段增强建议清单》

并落成 docs/MVP内部体验与测试指南.md。

---

🚀 十四、为什么接下来先发 GitHub，而不是继续写功能

在确认要准备内部体验版后，下一步不是再让 Antigravity 多做几个页面，而是：

先把当前“内部测试版”发到 GitHub 仓库

这里也明确了几个原则：

• 不要盲目推送，先检查 git 状态
• 校验 .gitignore
• 避免提交 .env、token、上传目录、构建产物等敏感和无效文件
• 单独编写 README.md
• 保留 docs/MVP内部体验与测试指南.md 不动

同时还明确了：

README.md 和 指南.md 不应混用

• README.md 是仓库首页说明书
• 指南.md 是内部试运行操作手册

后来项目也已经成功发布到 GitHub。

---

🧠 十五、整个过程中最重要的方法论总结

回看整套协作过程，最关键的方法不是某一条具体代码，而是下面这些原则：

1. 先立规则，再做系统

没有 GEMINI.md，Antigravity 很容易失控。

2. 不用一句提示词解决一切

正式项目必须拆成：

• 总提示
• 方案提示
• 结构提示
• 模块提示
• 自检提示

3. 永远只做“小闭环”

不是一口气“生成整套系统”，而是每次只做一个可验证的小环节。

4. 永远先打地基

客户、项目、权限、组件、数据模型这些先稳，后面才不会返工。

5. 先主后从

先让合同主表稳定入库，再挂收款、发票、附件等子模块。

6. 先单体，再全局

先做单合同详情闭环，再做院级 Dashboard。

7. 先管理价值，再复杂自动化

先把台账、预警、导出、日志做稳，再考虑：

• 预警推送
• OCR
• OSS
• SSO
• 更复杂审批流

8. MVP 到点就要收手

当核心链路齐全时，最重要的不是继续开发，而是进入试运行。

---

🏁 十六、当前阶段该如何继续

到目前为止，这套系统最合理的下一步不是继续猛加功能，而是：

1. 部署测试环境

让内部人员可访问。

2. 准备测试数据

避免空系统影响体验。

3. 小范围内部试用

覆盖经营、财务、管理层等角色。

4. 用统一模板收集反馈

区分：

• Bug
• 流程问题
• 增强需求

5. 再排第二阶段

根据真实反馈决定后续是优先做：

• 财务流水导出
• Dashboard 颗粒度增强
• 权限细化
• 日志增强
• 预警推送
• 云存储
• SSO
• 审批接入

---

📌 十七、结语：Antigravity 不是替你“写完系统”，而是与你一起把系统“稳稳做出来”

这次从制定 GEMINI.md 到一步步完成规划设计院合同管理系统 MVP 的过程，最有价值的地方，不是某一个模块多漂亮，而是逐渐形成了一套清晰的方法：

• 用规则约束代理
• 用分层提示组织复杂任务
• 用小闭环降低风险
• 用结构化节奏推进工程
• 用试运行代替闭门开发

换句话说，Antigravity 并不是“你说一句，它吐一堆代码”的工具。
它更适合被当成一个需要你持续指挥、持续校准、持续约束的协作开发伙伴。

当你把规则、提示、节奏和验收标准都掌握住之后，它才能真正帮你把一套正式系统，从 0 推到 1。

---

📚 附：本文适用场景

这套方法不仅适用于“规划设计院合同管理系统”，也适用于任何类似的正式后台项目，例如：

• 内部业务管理系统
• SaaS 后台
• ERP / CRM 子模块
• 财务协同平台
• 项目管理平台
• 带权限和流程的 Next.js Web App

如果你的目标不是“做个 Demo”，而是“做个能跑流程、能试用、能继续迭代的系统”，那么这套方法就是有效的。