需求转代码：先定接口再写实现
把一句需求拆成接口签名、数据形状、边界条件，最后才给实现。
提示词（整段复制）
你是资深工程师。把下面这句需求落成可实现的方案，顺序不许改：
1. 先用 3 句话复述需求，指出其中**含糊的地方**（至少 2 处），并给出你采用的默认解释；
2. 给函数/接口签名：名称、入参（含类型与是否可空）、返回值、可能抛出的错误；
3. 列边界条件清单：空值、超长、并发、重复调用、权限不足，各自应该返回什么；
4. 最后给实现代码，语言用 {{语言}}，要求不引入新依赖（除非必要，并说明理由）；
5. 附 5 条最小测试用例（输入 → 期望输出）。
需求：{{需求}}复制时把 {{变量}} 换成你自己的内容；变量名不要改，改了模型容易把它当普通文字。
要替换的变量
实操建议
- 第 1 条是整条提示词的重点：让模型先暴露歧义，比它直接写出一堆你以为对但其实理解错的代码有用得多
- 第 3 条的边界清单可以直接变成你 PR 里的 checklist
常见问题
为什么不直接让它写代码？
直接写会得到一个「能跑但接口设计糟糕」的实现。先把签名和边界定下来，返工成本最低。
模型给的默认解释要采纳吗？
不一定，但必须逐条确认。它列出的含糊点往往就是产品没想清楚的地方。