How to Solve the Right Problem in the Age of Agentic AI

在智能体 AI 时代，如何解决正确的问题

Before AI, implementation capacity was scarce. A bad requirement might waste a few engineers’ time. With AI, that capacity expands dramatically. A bad requirement can now produce hundreds of wrong changes very cheaply. The bottleneck therefore moves upstream: towards problem definition, context, constraints, decisions and validation. 在 AI 出现之前，实施能力是稀缺的。一个糟糕的需求可能只会浪费几名工程师的时间。而有了 AI，这种能力得到了极大的扩展。现在，一个糟糕的需求可以以极低的成本产生数百个错误的变更。因此，瓶颈向上游转移：即问题定义、背景、约束、决策和验证。

If the direction is wrong, all that extra speed just gets you to the wrong place ten times faster. It’s a fact that you’re going to have to address uncertainty surrounding a project at one point. Why not do it when change is still cheap? It’s much cheaper to change a blueprint than it is to rebuild whole parts of a building. 如果方向错了，所有的额外速度只会让你以十倍的速度到达错误的地方。事实上，你迟早都要面对项目中的不确定性。为什么不在变更成本还很低的时候去做呢？修改蓝图远比重建建筑的各个部分要便宜得多。

This article’s goal is to provide you with the tools to reduce uncertainty as much as needed before implementation. This article introduces a practical framework that does exactly that in 6 steps. Each step produces one short document that makes the decisions explicit, durable and usable by both humans and agents. It’s a shared record of what’s understood, decided and agreed. 本文的目标是为你提供工具，以便在实施前尽可能地减少不确定性。本文介绍了一个通过 6 个步骤实现这一目标的实用框架。每一步都会生成一份简短的文档，使决策变得明确、持久，并可供人类和智能体使用。这是对已理解、已决定和已达成共识内容的共享记录。

With the framework you build: The right thing: a solution that actually solves a real problem. The right way: without wasting money, time, or resources. As efficiently as possible: with enough clarity during development to prevent backtracking, waiting or guesswork. 通过这个框架，你可以构建： 正确的事物：一个真正解决实际问题的方案。 正确的方式：不浪费金钱、时间和资源。 尽可能高效：在开发过程中保持足够的清晰度，以防止返工、等待或盲目猜测。

The outcome is alignment. Both humans and AI agents work from the same playbook: a clear, shared understanding of the problem and intended solution. This prevents guesswork, rework and surprises. 其结果是达成一致。人类和 AI 智能体都遵循同一套“剧本”：对问题和预期解决方案有清晰、共同的理解。这可以防止猜测、返工和意外。

···

Why this matters

为什么这很重要

The hardest problems in software development are rarely purely technical. They’re about communication and alignment: key components in turning a vague problem into the right solution. Even the best engineers can’t salvage a project if stakeholders can’t agree on what they’re building, why or for whom. Misalignment slows teams down and burns out good engineers because they lack the structure and direction needed to do their job. 软件开发中最困难的问题很少是纯技术性的。它们关乎沟通和一致性：这是将模糊问题转化为正确解决方案的关键要素。如果利益相关者无法就“正在构建什么”、“为什么构建”或“为谁构建”达成一致，即使是最优秀的工程师也无法挽救一个项目。不一致会拖慢团队进度，并让优秀的工程师感到精疲力竭，因为他们缺乏完成工作所需的结构和方向。

Involving agents makes these risks even bigger. A single engineer heading in the wrong direction for a day can do limited damage. That same engineer deploying an entire fleet of agents can do a lot more damage, faster: one wrong assumption doesn’t stay in one file anymore, it gets copied into every agent-generated change that touches the same pattern before a human ever reviews it. 引入智能体会使这些风险变得更大。一名工程师走错方向一天，造成的损害是有限的。而同一名工程师部署一整队智能体，则能更快地造成更大的损害：一个错误的假设不再局限于一个文件，它会被复制到每一个触及相同模式的智能体生成的变更中，甚至在人类审查之前就已经发生了。

Yet many teams treat requirements as a one-and-done event and then sprint into development, assuming the rest will sort itself out. You wouldn’t build a house without blueprints. Why would you build a software project without proper preparation? 然而，许多团队将需求视为“一劳永逸”的事情，然后匆忙投入开发，认为剩下的问题会自行解决。你不会在没有蓝图的情况下盖房子。为什么要在没有充分准备的情况下构建软件项目呢？

Yes, this takes investment up front. But “we don’t have time for that” often turns out to be a very expensive sentence once you count the cost of compliance violations, reputational damage, competitive advantage and rework at scale. 是的，这需要前期投入。但一旦你计算了合规违规、声誉受损、竞争优势丧失以及大规模返工的成本，“我们没时间做那个”往往会变成一句代价极其昂贵的托词。

···

The cost of being wrong

犯错的代价

Spend effort where it’s needed. Not every decision deserves the same amount of analysis. This is one of the principles behind the framework: The more expensive a decision is to reverse, the more uncertainty you should eliminate before making it. 将精力花在需要的地方。并非每个决策都需要同等程度的分析。这是该框架背后的原则之一：一个决策撤销的成本越高，你在做出决策前就越应该消除不确定性。

Choosing the label on a button is highly reversible. Decide quickly, adjust it later if needed. Choosing a data contract, system boundary, or integration architecture may not be, and getting it wrong is expensive to undo. That’s where the scrutiny belongs. 选择按钮上的标签是高度可逆的。快速决定，如果需要以后再调整。而选择数据契约、系统边界或集成架构可能并非如此，一旦出错，撤销的成本很高。这才是需要仔细审查的地方。

This doesn’t mean predicting everything up front. It means spending your preparation effort where a wrong decision would actually cost you, and deliberately leaving the rest flexible. 这并不意味着要预先预测一切。这意味着将准备工作投入到那些一旦决策错误就会让你付出代价的地方，并刻意让其余部分保持灵活性。

···

When to use this framework

何时使用此框架

Not every software change needs six documents. A bug fix, a small internal script or a disposable prototype usually doesn’t justify this level of preparation. Applying the full framework to every change would create bureaucracy rather than clarity. 并非每个软件变更都需要六份文档。修复 Bug、编写小型内部脚本或一次性原型通常不需要这种程度的准备。将完整的框架应用于每一个变更只会制造官僚主义，而不是清晰度。

The framework becomes valuable when the cost of getting the direction wrong is significant. Use it when several of these are true: 当方向错误的代价很大时，该框架就变得有价值了。当以下几点中的几项成立时，请使用它：

• Multiple stakeholders or teams need to coordinate.（多个利益相关者或团队需要协调。）
• The problem or desired outcome is ambiguous.（问题或预期结果模糊不清。）
• The solution depends on existing systems, data or organizational constraints.（解决方案依赖于现有系统、数据或组织约束。）
• Important architectural or data decisions will be expensive to reverse.（重要的架构或数据决策难以撤销。）
• Several people or AI agents will work in parallel.（多个人或 AI 智能体将并行工作。）
• A mistake could create significant financial, operational, compliance or reputational damage.（错误可能造成重大的财务、运营、合规或声誉损害。）
• The project is large enough that rework would materially affect its outcome.（项目规模足够大，以至于返工会实质性影响其结果。）

You also don’t have to use every step with the same level of detail. For a relatively small project, the framework may be a few pages of decisions. For a large, complex project, each step may require substantial discovery and discussion. 你也不必在每一步都使用相同程度的细节。对于相对较小的项目，该框架可能只是几页的决策记录。对于大型、复杂的项目，每一步可能都需要大量的探索和讨论。

The point is not to complete six documents, but rather to reduce the uncertainty that matters before you start implementing. Use the framework when coordination and the cost of being wrong justify it. 重点不是完成六份文档，而是在开始实施之前减少关键的不确定性。当协调成本和犯错代价值得时，请使用该框架。

And the framework is not a substitute for experimentation. When an assumption is uncertain, a prototype, spike or other experiment may be the fastest way to reduce that uncertainty. The result should then feed back into the relevant step rather than silently changing the direction of the project. 此外，该框架不能替代实验。当一个假设不确定时，原型、技术验证（spike）或其他实验可能是减少这种不确定性的最快方法。结果应反馈到相关步骤中，而不是悄悄地改变项目的方向。

···

The framework

框架

The Project Preparation Framework systematically reduces uncertainty by working through one decision domain at a time. Each step builds on the last, bringing the most consequential questions forward while the cost of change is still low. Interpretations, assumptions, decisions and reasoning are documented in a shared file that the relevant stakeholders can review. “项目准备框架”通过一次处理一个决策领域，系统地减少不确定性。每一步都建立在前一步的基础上，在变更成本仍然很低的时候，将最重要的问题提出来。解释、假设、决策和推理都被记录在一个共享文件中，相关利益相关者可以进行审查。

The framework is sequential, but it is not a waterfall. Later discovery can… 该框架是顺序执行的，但它不是瀑布式模型。后期的发现可以……