Phase 1 / Ep 01: 起心动念（人类视角的 One-Pager）

⏱ 预计阅读 4 分钟 更新于 2026/4/13

很多人使用大模型进行开发时，往往喜欢打开对话框就开始滔滔不绝：“帮我写一个时间管理软件，左侧要有菜单，右侧要有日历，日历里面能点出来弹窗表单，最好还要支持 Google 登录……”

错！大错特错。 这种口语化的发糖式投喂，是导致代码失控、业务前后矛盾的万恶之源。

在 Antigravity 及具备 using-superpowers 机制的系统开发中，人类的角色是产品架构顶层决策者。你要做的，是提供一份具备战略基线与约束条件（Constraint） 的一页纸，剩下的推导（从边界条件到完整 PRD）是 AI 大架构师的工作。

1. 什么是 One-Pager Intent？

One-Pager 并不追求大而全的页面排版细节，它只回答四个核心问题：

  1. 我们要解决什么痛点？(Why)
  2. 它的护城河/核心差异是什么？(Core Value)
  3. 技术边界在哪里？(Tech Constraints)
  4. MVP（最小可行性版本）绝不能包括什么？(Not-To-Do)

2. 【实战范例】时间管理系统的 One-Pager

针对我们本次实战课程的目标项目，这才是你需要喂给系统的最原始“起心动念”模板：

# 核心意图 (Project Intent): T-Block 同步日历

## 1. 核心目标 (Why & What)
我要开发一款名为 T-Block 的时间块日程管理 Web App。它不是一个单纯的 Todo List，而是强调“将待办事项塞进化身块中、并拖入日历排期”的理念。它必须能和 Google Calendar 实现双向同步。

## 2. 技术护城河边界 (Tech Constraints)
- **技术栈要求**：强制使用 Astro(SSR) 或 Next.js。严禁引入重型的老旧框架。
- **存储要求**：使用 Prisma + 关系型数据库 (PostgreSQL 偏好)。涉及外部同步必须引入事务和软删除机制。
- **端到端测试覆盖**：项目不可承受“手改导致同步错乱”，Google 接口必须在开发初期即实现 Mock 测试层。

## 3. 设计语言基调 (Design Tone)
- **拒绝平庸**。使用极简风，必须考虑暗黑模式。不用写大量 CSS，强制使用 Tailwind CSS 与 Radix UI (或同级高级组件库)。界面参考 Linear 的清霜干练风格。

## 4. MVP 第一版【绝对不做】的伪需求 (Not-To-Do)
- 不做多账号多团队组（第一版纯单机个人版）。
- 不做移动端 App Native 版本。
- 绝不接入微信/苹果等其他第三方，第一版死瞌 Google OAuth 单点登录。

3. 把种子种进土壤

准备好了这页 Markdown，是不是现在就要让 AI 直接“帮我写代码”？

千万忍住！

如果直接开始写代码，你会立刻因为大模型缺乏文件历史记忆而陷入无尽的“文件找不到”、“覆盖前一版逻辑”的地狱中。这就好像你把顶级图纸随手扔在了一个路边建筑队的垃圾桶里。

在把这份图纸喂进系统之前，我们必须先为系统打造好工作流管线（Pipelines）和长线记忆脑（Files）。

下节预告： Ep 02，我们将不写一行代码这页系统，而是先创建 .agents、配置 GEMINI.md，把一个冷冰冰的代码仓库，变成一个拥有行为准则和纠错能力的“智能办公园区”。