AI时代的第一性原理，不是解答，是提问

答案vs问题

最近在做关于职场的思考，高级工程师这个头衔之下，每个公司或许都有这样那样的定义标准，比方说写不写代码，写多少代码，负责的问题是不是模糊，克服的挑战和复杂度如何。这些标准都很有道理，而且都可以很好的指导具体的操作和实践。最近在思考，这些东西的背后又是什么呢？一个Senior 和非Senior之间的区别到底在哪里？初级工程师或者II级工程师的重点是完成给定的任务。任务完成的过程中所体现出的独立性程度可以用来区分初级和非初级工程师的水平。而这些工作的最终，都是需要解答一系列既定的问题；或者说，对于这一系列的工作的最终落实的形式都是确定的：给出一段代码、实现一个功能。 这本质上其实还是在为一个个具体的问题给出答案。这些问题如果提的好，足够明确，足够清晰，对于这些问题的答案空间也自然划定地比较清晰，甚至答案（具体要做的事，怎么做，效果如何）有时候就已经呼之欲出，我们需要的仅仅是1周去写代码实现——这也就是通常所说的“straightforward”。

那么，具体做什么事？怎么做？为什么要做？做完了如何评估？为什么这个评估标准就能评估这件事？是否还有其他评估标准？做完这件事，下一步是什么？还要做什么事?

如果你的工作已经碰到了这一系列的问题中一个或者多个，那么你已经开始觉醒高级工程师的skill set了：发起有价值的提问。因为大多商业指标的提升（利润、收入、用户活跃度提升等等）往往都是以最高等级的问题被分发给了高级别的管理者，这些问题结合具体的产品运行模式和商业模式，被一层层breakdown成为更加贴近系统、代码运行逻辑的问题（比方说，把某一个算法从heuristic变成模型based，以达到更高的推荐准确率），到这一步的时候，一个分水岭出现了：继续往下breakdown的时候，即将被提出的问题必须要同时考虑商业指标和具体代码或者系统运行的细节和逻辑，因为最终的解决方案空间(solution space) 一定是要落实到代码层面的。 我们需要一座桥去衔接这两端，一端是抽象的、模糊的、笼统而单一的目标，一端是具象的、清晰的、粒度很细但极有可能很庞杂的解决方案空间。

高级的工程师（们）的任务，就是搭建出这座桥。

造桥就是制定标准

看到这里，相信你也已经意识到了，高级工程师或者再往上的工程师梯队的首要任务，就是制定标准。因为问题总是一个叠加一个，产品的迭代和后续的开发，都是按照一层一层累计的标准去执行的。旧的标准（问题）如果提的好，在高质量落地的前提条件下，未来的新的问题就有了坚实的地基去承载。

这和什么很像？和我们与AI Agent的交互非常相似。

Agent的执行，其实就是在给我们提供的问题寻找答案。而这些问题我发现很多时候都是让agent去猜测一个标准，或者给出的标准很模糊。Agent如何用得好，就是看你制定标准的能力是不是足够强。当你想要做一件事的时候，如何在你自己的脑子里（或者借助其他工具）把这个问题从高层面的抽象单一任务，一点点具体化、清晰化，给出一套非常全面的标准，交付给Agent去开启对于解决方案空间的探索，最终给出验证过的、可幸赖的执行结果（答案），我想才是现在与Agent协作的一个完整的最终形态。

第一个prompt：Ask me, instead of answer me

既然我们最开始需要解决的是提出好的问题，那么为什么不让Agent也参与到这个过程中来呢？最佳的实践可能就是从我们引导Agent去问我们自己问题开始的：与其我们自己去思考可以提出什么样的问题来一点点解析和制定标准，不如和agent一起来做。当我们内心有一个模糊的想法的时候，可以先让AI来发起一场问答风暴，让它来问我们（同时自己也去思考）具体做什么事？怎么做？为什么要做？做完了如何评估？为什么这个评估标准就能评估这件事？是否还有其他评估标准？做完这件事，下一步是什么？还要做什么事?还有什么别的问题可以考虑？有哪些已知的未知的东西？有哪些未知的未知？如此等等。

接着，我们可以让AI去整理整合这一些列的问题，构建出一套multi-milestones的项目计划书，包含每一个阶段的目标、具体任务内容、验收标准，与后续阶段的关联等等。

AI时代的第一性原理，不是答案，是问题。

答案是水泥，而问题才是砖块。好的问题才能引导出更好的问题和更好的答案，一点点叠加，最后建起大厦。