常用提示词结构

1. 角色 + 目标 + 边界

角色不是让模型“假装专家”，而是提供工作视角和判断标准：

你是一名面向新手的产品文档编辑。
目标：把下面的技术说明改写成 800 字以内的中文入门说明。
要求：不透露内部架构，不使用没有解释的缩写，每个步骤都能被新手验证。

2. 少量示例（Few-shot）

当格式比内容更重要时，给一两个“输入 → 输出”示例：

输入：登录失败，用户看到了 401。
输出：{"类别":"账号或权限","下一步":"检查 Key、账号状态和服务商额度"}

现在请按同样格式处理：用户看到 429。

示例要代表真实情况，且不要互相矛盾。

3. 分步任务与阶段验收

复杂工作不要一次要求“分析、修改、测试并部署”。可以拆成：

读取并总结现状；
列出方案和取舍；
只实现已确认的方案；
运行检查并展示结果；
根据反馈继续迭代。

每一步结束都保留可检查的产物，例如问题清单、文件列表、测试输出或截图。

4. 对比和选择

需要方案时，让 AI 用统一维度比较：

请比较静态托管、平台部署和云服务器。
维度固定为：适合谁、费用结构、上线速度、可控程度、维护工作、迁移难度。
最后给出三种预算情况下的推荐，并标出你不确定的地方。

5. 让 AI 先提问

需求缺信息时，与其让 AI 猜，不如规定最多问 5 个关键问题，并说明每个问题会影响什么决定。回答后再让它生成方案。

6. 结构化输出

清楚写明字段、类型、枚举值、是否允许空值和失败格式：

只返回 JSON，不要 Markdown：
{
  "summary": "一句话总结",
  "risks": ["风险 1"],
  "next_step": "下一步动作",
  "confidence": "high | medium | low"
}

如果内容会交给程序处理，仍要在应用侧校验 JSON，不能完全相信模型输出。

7. 让模型引用上下文

要求引用文件名、段落标题、URL 或资料编号，并规定“没有证据时回答资料不足”。这会让错误更容易被发现，但不等于自动保证真实。

一个通用模板

# 任务
请完成：[一句话目标]

# 背景
[项目、用户和当前状态]

# 可用资料
[文件、链接、示例]

# 约束
- 不要：[明确禁止项]
- 必须：[必须保留或遵循的规则]

# 交付
- [需要修改/生成的文件]
- [输出格式]

# 验收
- [可观察的成功条件]
- [需要运行的检查]