提示词怎么写

正确做法是：先一次性给“整体约束 + 目标 +边界”，再用小步迭代不断细化与审核。
只用其中一种，都会翻车。

下面从「为什么」「怎么写」「推荐提示词结构」三层说明。

---

一、为什么不能只用“一次性”或“只迭代”

1️⃣ 只一次性提出所有需求的问题

优点是模型能看到全局，但现实中会遇到三类问题：

• 你自己一开始也想不清全部细节
• 模型容易幻觉式补全你没想过的东西
• 输出往往很长、很泛、不可落地

结果通常是：

看起来很完整，但一行代码都不敢用。

---

2️⃣ 只靠不断迭代的问题

如果一开始什么背景都不给：

• 架构会反复推翻
• 技术选型前后矛盾
• UI / API / 数据结构来回改

模型在「局部最优」里打转，你在不断擦屁股。

---

二、正确的整体方法论（你可以记住这 4 个字）

“先定框架，再磨细节”

对应到提示词，就是 两阶段提示工程。

---

三、阶段一：一次性给“不可变约束”（非常关键）

这一阶段不是让模型直接写代码，而是让它：

• 对齐目标
• 冻结大方向
• 不乱猜

阶段一你必须一次性说清楚的内容

至少包括这 7 类（不需要特别详细，但要明确）：

1. 网站目标
   • 这是展示型 / 工具型 / SaaS / 社区 / 内部系统？
2. 目标用户
   • 普通用户 / 程序员 / 企业 / 管理后台？
3. 技术栈约束
   • 前端（React / Vue / Next.js）
   • 后端（Node / Java / Python）
   • 是否允许引入第三方服务
4. 部署与环境
   • 云服务器 / 本地 / Docker / 无服务器
5. 非目标（非常重要）
   • 明确“不做什么”
6. 质量要求
   • 是否追求高性能 / 快速上线 / 可维护性
7. 你的角色
   • 你是新手 / 有经验 / 需要讲解还是直接给代码

---

✅ 阶段一示例提示词（推荐你直接用）

我要开发一个网站，请先不要写具体代码。

网站目标：一个面向程序员的工具型网站
核心功能：在线生成并管理提示词
目标用户：有一定编程基础的开发者
技术栈约束：
- 前端：React + TypeScript
- 后端：Node.js
- 数据库：PostgreSQL
部署环境：Docker + 云服务器

非目标：
- 不做复杂的权限系统
- 不考虑移动端 App
- 不做支付功能

质量要求：
- 结构清晰、易维护
- 优先可扩展性而不是极致性能

我的背景：
- 有 10 年开发经验
- 希望你像架构师一样思考

请你先输出：
1. 整体系统架构
2. 核心模块划分
3. 数据模型草案
4. 接下来推荐的开发迭代顺序

👉 这一轮的目标只有一个：把“地基”定死。

---

四、阶段二：小步迭代 + 审核（真正写代码）

从这一阶段开始，禁止一次性要全部代码。

正确节奏是：

一个模块 → 设计 → 审核 → 再写

推荐的单轮提示词结构

基于上一步的整体架构，
现在只聚焦【用户管理模块】。

请按以下顺序输出：
1. 该模块的职责与边界
2. API 设计（只列接口，不写实现）
3. 数据表设计
4. 潜在风险与可扩展点

等我确认后，再写代码。

确认后再来：

现在只实现【用户管理模块】的后端部分：
- 使用 Node.js + TypeScript
- 只实现注册和登录
- 不做权限系统
- 代码要可直接运行

请逐文件输出，并说明目录结构。

---

五、一个判断标准：什么时候该“一次性”，什么时候该“迭代”

你可以用这一句自检：

“这个决定以后改起来代价大不大？”

• 代价大 → 一次性说清楚
  • 架构
  • 技术栈
  • 数据模型
• 代价小 → 允许反复迭代
  • 页面布局
  • 字段命名
  • UI 交互

---

六、给你的程序员专属结论

提示词 ≠ 需求文档
提示词 = 对 AI 的“最小充分约束”

• 一次性的是「规则」
• 迭代的是「实现」
• 不要让 AI 替你做架构决策
• 让 AI 在你画好的轨道上狂奔