回顾与练习

关键要点

• 规格先行，而且很短 — 一段话点明了真正重要的约束，包括那些在运行的应用里永远看不到的工作流约束。
• 密钥从未碰过仓库；每个项目都从环境变量或在仪表盘里设置的加密配置中读取密钥。
• 技术栈是为了少出错而选的 — 托管认证、托管数据库、静态托管、无服务器函数。
• 障碍是靠给 AI 喂确切证据来解决的 — 真实的报错、实际的代码、部署配置 — 并把修复范围收得很窄。
• 上线意味着对现实的真实测试，而不是"它编译通过了": 一笔真实购买、第二个账户、线上站点上的一个深层链接。

动手试试

挑一个你自己的点子，像这四个案例那样写出它的一段式规格: 点明核心动作、每个用户能看到的数据，以及至少一个工作流约束(内容如何发布、谁能做什么)。然后列出你会依赖的托管构件，以减少会出问题的自定义代码。控制在一段话加一个简短的项目符号列表 — 如果超出了，就说明你规格定得过头了。

本章提示词

I want to build: [one-paragraph description of the app].
Before any code, help me tighten this into a buildable spec.
1. Restate the single core action a user performs.
2. List the data each user can see — and what they must NOT see.
3. Name the workflow constraints that won't show up in the UI
   (e.g. "pushing a file should publish it", "only their own data").
4. Recommend a stack that MINIMIZES custom code: managed auth,
   managed database, static or serverless hosting where possible.
5. Flag the one part most likely to go wrong, and how we'll test it
   against reality (a real purchase, a second account, a deep link).
Keep the spec to a paragraph plus bullets. Push back if it's too big.