详细内容或原文请订阅后点击阅览
为什么人工智能编码代理仍然需要明确的规范
以下文章最初发表在 Markus Eisele 的时事通讯“主线程”上，经作者许可在此重新发布。现在开发者社区中流行着一种心理模型，它是这样的：代理足够聪明，能够解决问题，所以大量的前期规范是官僚开销，你不需要 [...]
来源:O'Reilly Media _AI & MLThe following article originally appeared on Markus Eisele’s newsletter,The Main Thread, and is being republished here with the author’s permission.
There’s a mental model spreading through the developer community right now that goes something like this: Agents are smart enough to figure things out, so heavy upfront specification is bureaucratic overhead you don’t need anymore. Just describe the goal loosely, let the agent explore, and correct as you go.快速地。灵活的。现代的。
It’s wrong. Not because agents aren’t capable—they often are—but because the accounting is off.你并没有消除成本。 You’re deferring it, fragmenting it, and making it harder to see.
让我们运行实际的账本。
两个极点，两个隐性成本
一个极端是：最小规格。 You describe intent loosely, agents interpret freely, and work begins immediately.人力的前期成本几乎为零。 What you don’t immediately see is what accumulates downstream: correction loops, each carrying token cost plus human reengagement time. Review cycles where a human acts as the oracle for every output—deciding whether what the agent produced is what was actually meant. Rework when it wasn’t.
At the other extreme: full formal specification. TDD, BDD, Gherkin scenarios, acceptance criteria locked down before a single line of code runs.人类前期的努力是真实且可见的。 But the downstream verification cost looks fundamentally different, because the tests are the oracle. Pass or fail. The human doesn’t need to personally evaluate every output—the spec does it automatically, repeatedly, without fatigue.
What you’re actually trading off is when you pay and in what currency. Minimal spec front-loads token cost and back-loads human judgment. Heavy spec front-loads human effort and back-loads almost nothing—automated verification doesn’t scale with runs.
老问题始终是规范
The real challenge in software engineering has always been specification.