好提示词更像一份接口契约
模型不是魔法盒。比起堆砌人设，我更喜欢把任务拆成四部分：
- 目标：要完成什么。
- 上下文：已知的材料有哪些。
- 约束：什么不能做，遇到缺失信息如何处理。
- 输出格式：最终应该长什么样。
一段可以直接改的模板
任务：根据下面的代码审查潜在问题。
输入：<代码文本>
约束：
- 仅根据输入作结论
- 不确定时明确标注
- 优先关注正确性和安全性
输出：JSON 数组，每项包含 line / issue / suggestion
这段模板没有「世界第一工程师」之类的神秘咒语，却更容易测试：只要输入不变，你就有明确标准比较不同输出。
最重要的是给出失败路径
如果模型没拿到必要资料，它应该询问、说明缺失或给出有限结论，而不是编造一个看起来完整的答案。
Prompt 只是系统的一部分。工具权限、输入校验、输出验证和日志同样重要。
用测试用例迭代
准备正常输入、空输入、冲突要求、超长输入四组测试。每次改动提示词都重跑一遍，看看到底是更稳定了，还是只是碰巧回答得更漂亮。
最后
你不需要「完美提示词」，你需要一个可观察、可验证、能逐步改善的工作流。