开发者会在两个地方遇到提示词：请 AI 助手修改代码，以及编写随应用一起发布的提示词。两者所需的技能有重叠，但出错的方式不同。本指南同时涵盖这两方面。
第 1 部分：面向 AI 编码助手的提示词
写规格说明，不要写愿望
只给编码助手一句话，它就必须自行推断范围、约束以及“完成”的含义。请把你会写进一个好工单的内容都给它。
fix login issue and make google login work and don't break anything
## Objective
Fix the login failure and make Google login work.
## Constraints
- Do not change the existing email and password flow.
- Keep the public API of AuthService unchanged.
## Edge cases
- Expired or revoked OAuth tokens.
- A Google account whose email already exists as a password account.
## Testing
- Add unit tests for the token exchange and the account-linking path.
## Acceptance criteria
- Existing auth tests pass. New tests cover both edge cases.
## Expected output
A summary of the cause, then the changed files as diffs.
第二个提示词多花一分钟来写，却能省下一轮“我不是这个意思”。PromptFlowEngine 的 VS Code 扩展能根据一行任务和相关文件生成这样的结构。
提供合适的代码，而不是全部代码
上下文窗口很大，但注意力不是无限的。包含改动涉及的文件、必须遵守的接口，以及一个体现项目约定的示例。把生成的文件、锁文件和无关模块排除在外。
说明什么不能改
助手会针对请求去优化。如果向后兼容、公开接口或性能很重要，就要说出来。“不要破坏任何东西”不是模型能检查的约束；“保持 GET /orders 的响应结构不变”才是。
大改动先要计划
只要超出小幅修改，就先要计划，审阅后再要实现。这就是应用于代码的提示词链，能在写出任何代码之前发现错误的思路。
验证返回的内容
阅读差异。运行测试。对较大的改动，写一个评审提示词，把原始任务和修改后的文件交给模型，让它列出改动在哪些地方没有满足验收标准。
第 2 部分：应用内部的提示词
把提示词纳入版本控制
提示词是程序行为的一部分。把它存放在文件里，在拉取请求中评审改动，并为版本打标签。参阅提示词管理与版本控制。
使用带分隔变量的模板
永远不要把用户输入拼接进指令。使用具名变量，并用标签包裹每个变量。
PROMPT = """Classify the support ticket in the tags as billing, bug, or other.
Return only the label.
<ticket>
{ticket}
</ticket>"""
要求结构化输出并加以验证
如果你的代码要解析响应，就要求符合 schema 的 JSON，在服务商支持时使用其结构化输出功能，并在使用结果之前先验证。参阅结构化输出提示词。
为 token 制定预算
要知道你的固定提示词用了多少 token，因为每次调用都要为它付费。用模型真实的分词器来计数，而不是按字符估算。参阅 token 优化。
在 CI 中测试提示词
静态检查能发现无需模型就能发现的回归：被删掉的输出格式、重复的部分、超出预算的 token 数、被提交的 API 密钥。提示词测试门禁会在每个拉取请求上运行这些检查。
- run: promptflow check "prompts/**/*.md" --min-score 70 --max-tokens 1500
把模型输出视为不可信
输出可能出错，也可能被输入中注入的文字所操纵。在没有施加与用户输入同等的验证之前，不要把它传给 shell、SQL 查询或 HTML 页面。参阅提示词安全。
从代码中调用引擎
同样的检查也可以不用密钥通过 HTTP 获得，适合快速的集成测试或内部工具：
curl -s https://promptflowengine.com/api/v1/analyze \
-H 'content-type: application/json' \
-d '{"prompt":"Write something about our product."}'