定义Shape是AI时代程序员的新核心技能

在开发者价值评判标准正在发生转变，而目前大多数讨论都把焦点放在了错误的半边上。

论证大致是这样的：AI Agent 能够把你脑中已有的系统设计以比你手工输入快得多的速度转化为可运行的软件。这意味着你所能交付的产品上限，不再取决于你写代码的速度，而取决于你决定做什么、以及如何将其塑造成形的能力。状态应该放在哪里，组件边界应该如何划分，当你构建的东西需要扩展时，哪些后果会在数月后才显现出来。

这些观点都是正确的，也确实为开发者价值的走向提供了有用的重构思路。真正领先的开发者，是那些主动引领设计而不是完全将其外包的人——他们设定好形状，然后让 Agent 在其内部快速执行。

但这种框架没有说明的是，连接这两个半边的实际机制。拥有判断力是一回事；让 Agent 真正在你设想好的形状内工作，则是完全不同的事情，二者之间的差距不会因为你的判断力出色就自动消失。

存在于你脑中的判断力对 Agent 没有作用

你可能对 React 项目的结构有极好的直觉。关于何时状态应该本地化、何时应该共享，一个组件何时做了太多事情，哪些命名方式能让代码库在六个月后仍然清晰可读，功能边界应该怎样划分才不至于日后变成维护噩梦——你积累了多年的模式识别经验。

但这些判断力不会因为你存在于脑中就自动转移到 Agent 身上。Agent 无法访问你积累的模式识别能力。它只能访问你实际传达出去的内容，以任何你在对话前或对话中生成内容时传达的形式。

如果，你关于组件边界的判断力只作为一种直觉存在于你个人写代码时会用到的地方，那么在你代码库中工作的 Agent 就没有办法继承这种直觉。它会基于训练中的通用模式以及它能从当前上下文中推断出的信息，自己做出关于边界落在哪里的决定——这与你对这个特定项目的具体、来之不易的判断完全不同。

根据上述论证，你应该设定的"形状"，只有存在于 Agent 能读取的地方时，才能真正被设定。否则你就是拥有好的判断力，而 Agent 却在你自己从未实际传达过的形状里工作——只是它自己猜出来的一个形状而已。

"设定形状"具体需要什么

设定形状不是单一行为。抽象地描述听起来像是一件事，但它实际上分解为一组必须明确做出的决定，而不仅仅是作为直觉来持有。

它意味着决定并写下不同类别数据的状态存放位置。不是模糊地知道某些状态应该本地化、某些应该共享，而是明确指定实际的阈值。只被一个组件使用的状态留在该组件内部。被同一功能内两个或更多组件使用的状态移动到一个专用的 hook 中。只有在不同独立功能真正需要相同数据时，才将其提升为全局状态，而且仅在确实必要时才这样做。

它意味着决定并写下在这个项目中组件边界实际上是什么样子。不是对何时感觉太大的一般性感知，而是一条具体的界线，无论是通过代码行数、责任数量，还是关于在同一文件内混合展示层逻辑和业务逻辑的规则来定义。

它意味着决定并写下领域的词汇表。这个项目用于特定概念的具体词汇，以便 Customer 始终是 Customer，而不会有时是 User、有时是 Client，取决于哪个会话恰好生成了那个特定文件。

这些都是经验丰富的开发者已有的判断碎片，通常并没有被有意识地阐述为规则。这些判断力是存在的。在大多数情况下，不存在的是这些判断力的显式书面版本——Agent 能够真正遵循的版本。

为什么这在 Agent 完成大部分输入工作之前比现在更重要

在 Agent 生成代码库的大部分内容之前，开发者的判断力是自动应用的，每次都是如此，因为持有判断力和亲自编写每一行代码的是同一个人。拥有直觉和直觉出现在代码中之间没有差距，因为直觉和代码来自同一个来源、在同一个时刻产生。

一旦 Agent 承担了相当比例的实际生成工作，那种自动应用就断裂了。判断力和生成变成了两个独立的东西，二者之间只通过它们之间传达的任何内容来连接。如果没有传达任何明确的内容，Agent 就基于它自己的通用模式来生成，而你的具体判断力，无论多好，都闲置在你的脑中，Agent 则做出了与你不同的决定。

这是形状设定论证指向但没有完全阐明的部分。在 Agent 驱动的工作流中仅有良好的系统设计判断力是不够的。判断力必须经受住从你脑中转移到 Agent 能实际使用的形式的转变，每个会话都要如此，而不仅仅是那些你恰好记得在提示词中提到的会话。

真正领先的开发者在做具体的事情

仔细观察那些真正从 Agent 中获得更多的开发者实际上在做什么——超越"设定形状、让 Agent 在其内部工作"的一般性描述——一种特定的模式就会浮现出来。他们并不依赖于在每个提示词中记住重新传达自己的判断力。他们正在将那些判断力转化为一套独立于任何单独会话而存在的既定约束，这样设定形状这件事就一次性、全面地完成了，而不是每次写新提示词时都零散地重新尝试。

这与提示词工程不同，尽管两者经常被混为一谈。一条精心设计的提示词传达当前任务的意图。一套全面的规则系统传达每个任务的形状，无论那个具体提示词恰好如何措辞。真正领先的开发者不是在写越来越巧妙的提示词。他们在做更困难、更不起眼的工作：将他们的判断力一次性地阐述为一个明确的、既定的系统，然后让每个后续的提示词都在那个已经定义好的形状内运作。

以下是大致上当你真正坐下来做这件事而不是打算最终去做时的样子：

将判断力转化为 Agent 可遵循的形状定义规则：

1. 状态作用域由使用场景决定，而非便利性。默认为单一组件本地。一个专用 hook 当同一功能内两个或更多组件需要它时。只有当至少两个独立功能真正需要相同数据时才全局化。

2. 当一个单一文件开始同时处理以下多项内容时，即跨越了组件边界：渲染、数据获取或业务逻辑。发生这种情况时，在继续之前就拆分，不要将拆分推迟到之后的清理阶段。

3. 本项目的领域词汇表是固定且已文档化的。即使某个不同词汇单独看起来合理，也不允许出现偏差。

4. 为本项目做出的架构决策从其制定之日起即适用于后续开发，即使在现有代码库中某些尚未触及的地方仍存在旧模式。

一旦写下来，这些都不复杂。它的价值在于，这些判断力先以 judgment 的形式存在，然后才以规则的形式存在——正是写下来这个动作，真正让 Agent 能够在形状内运作，而不是在猜测一个形状。

良好判断力从不外部化的风险

有一种特定的失败模式值得直接命名，因为它很容易恰好在你的判断力确实很好的情况下掉进去。如果你的架构直觉很强，Agent 在没有明确规则的情况下生成的代码，在快速浏览时往往看起来是合理的——因为你在心理上填补了 Agent 留下的空白，自动修正一些小事情，却没有完全意识到你正在进行修正工作。

这就产生了一种虚假的感觉，觉得形状正在被成功地设定，而实际发生的事情是你的判断力在不断地、隐蔽地修复着一个从未以明确形式收到形状的 Agent。系统看起来运行良好，是因为你的判断力在其缺失的位置补偿了 Agent 的过程，而不是因为 Agent 真正内化了任何东西。

通常的信号是即使在同一个项目上与同一个 Agent 工作了数月之后，修正疲劳感仍然没有完全消失。如果你的判断力真的被转移了，对于某一类决定所需的修正会随着 Agent 输出越来越匹配形状而随时间减少。如果无论你们合作了多久，修正次数都大致保持不变——那说明判断力从未真正被外部化。它只是被你一次又一次地默默地应用着。

提示词不重要。规则才重要。

关于软件应该如何塑形的判断力，确实是现在最重要的技能——这个论点就其本身而言是正确的。但是，只存在于你脑中的判断力不会塑造 Agent 生成的任何东西。它只能塑造你亲自写的代码——而随着 Agent 承担越来越多的实际生成工作，这部分在总产出中占比越来越小。

设定形状不是通过拥有好的直觉就能一次性完成的事情。它需要将这些直觉转化为一套明确的、既定的系统，独立于任何单一提示词而存在，并且在 Agent 生成任何东西之前就让它访问这个系统。

你的判断力是资产。规则是让这份资产真正到达代码的途径。

想找出你的架构判断力在哪里从未被写下来供 AI 遵循吗？

我制作了一份免费的 24 点检查清单，帮助你精确识别这些地方——那些你的直觉很强但 AI 从未以它能实际使用的形式接收到的结构性决策。

→ 获取 React AI 整洁代码检查清单——免费

→ Avery Code React AI 工程系统

---