循环：意图 → 生成 → 审查 → 打磨

本书中的一切都回归到一个循环。把它内化。

1. **意图。**陈述你想要什么以及关键的约束——输入、输出、边界情况、技术栈、风格。模糊的意图得到模糊的代码。
2. **生成。**让模型写实现。别去手把手管语法；描述行为。
3. **审查。**读返回的内容。它真的做到那件事了吗？它处理了空列表、null、失败的网络调用吗？它是能跑通的最简版本吗？
4. **打磨。**指出哪里不对，给出具体的修正，然后重新生成。重复直到它达到你的标准。

大多数新手会跳过第 3 步。他们生成，它能跑，他们就继续往下走。然后它在生产环境里、在他们从未描述过的那个情况上崩掉了。审查这一步，正是工程发生的地方。

下面是这个循环里一个好的初始提示词长什么样：

Write a TypeScript function `parseDuration(input: string): number`
that converts strings like "1h30m", "45s", "2d" into total seconds.

Requirements:
- Support units: d (days), h (hours), m (minutes), s (seconds).
- Multiple units can combine: "1h30m" = 5400.
- Reject invalid input (empty, unknown units, negative) by throwing
  an Error with a clear message.
- No external libraries. Include 5 unit tests covering the edge cases.

Show the function and tests only.

注意它的结构：一个精确的签名、明确的规则、点名列出的边界情况、陈述清楚的约束，以及对测试的要求。你不是在指望模型猜对——你是在消除那些会导致糟糕猜测的歧义。

打磨这一步和第一条提示词一样是门手艺。模糊的反馈得到模糊的修正。比较下面这两种修正：

差的：  "this is wrong, fix it"

好的： "parseDuration('1h30m') returns 90 instead of 5400 — you're
       summing the numbers but ignoring the unit multipliers. Multiply
       each value by its unit's seconds (d=86400, h=3600, m=60, s=1)
       before summing. Also add a test for the combined case '2d3h'."

好的那条点名了症状、原因和修法。你是在像评审同事的 pull request 那样评审——而你指得越精确，花的回合就越少。每一圈循环都应当收敛。如果你发现自己在原地打转，那是个信号：你的意图说明不足。停止重新生成，改去重写规格。