常见拆问：系統提示怎么写、要不要思维链、長文件怎么塞、多轮如何防漂移。用分节覆蓋，不另开“入门 / 进阶”两个空站。
先写合同再写文采#
- 目標：完成什么决策或工件，成功長什么样。
- 工具：可以调用哪些函数，禁止造訪哪些網域。
- 輸出：欄位名、枚举、语言、引用格式。
- 回收：證據不足時提问或返回 needs_review，不要编造。
推論模型少逼它“写出思考”#
o 系列和 Astra 已經在內部推論。再要求“一步步打印全部思维”會泄漏中间态、拉長輸出，且不一定更准。需要审计時，讓它輸出简短依据欄位，而不是完整私有思维链。effort 用参数调，不用自然语言哀求。
長上下文不是垃圾桶#
Astra 上下文很大，但檢索质量仍决定答案。先檢索再粘贴相關节選，並标明來源。把整库檔案每次都塞进提示，既贵又容易淹没指令。
You are a claims assistant.
Goal: extract a decision object.
Tools: lookup_policy(id), never browse the open web.
Output: JSON matching the provided schema.
If documents conflict, set needs_review=true and list the two policy ids.沒有评测集就不算高級#
准备 30～100 条真實难例，覆蓋拒绝、工具失敗、多语言。每次改提示只改一处，对照分數。把提示当程式碼：PR 裡看 diff，而不是在群裡贴“新魔法句”。
要點#
- 合同先于修辞；結構輸出先于散文约束。
- 推論用参数，不靠“請仔细思考”。
- 提示、模型、effort 同一版本号。