Merge CEO亲述：高管不懂AI，就是组织的天花板

高管是AI能力的上限

Merge CEO Shensi Ding 在最近的一次访谈中抛出了一个尖锐的观点：如果你是高管，你就是整个组织AI流畅度的天花板。她负责的是公司非研发侧的业务，但自己依然大量写代码。这种“非技术高管也动手”的姿态，本身就构成了对团队最直接的示范。

这一判断背后是一个常被忽视的管理逻辑——AI工具的普及从来不是从下往上推动的。当下属观察到领导者本人不使用、不理解、不评估这些工具时，组织的采用意愿会迅速衰减。Ding 的亲身实践给出了另一种路径：管理者先成为深度用户，再谈组织推广。

从零到一：用Astra建出一个功能

Ding 坦言自己此前从未使用过 Codex，直到 Astra 发布后才第一次上手，并被其能力“震惊”。她随即用 Astra 完成了一次真实的产品开发：需要重新设计某个功能，但她一时想不出最佳方案，于是直接向 Astra 提出请求——能不能参考产品其他部分的实现，理解现有设计系统长什么样，然后给出一个最佳尝试。

这个请求的关键在于，它不是让 AI 写一段孤立的代码，而是让 AI 先建立对设计系统的整体理解，再产出符合规范的方案。这恰恰是多数AI编程工具容易断裂的环节：单点生成能力强，跨模块的上下文一致性弱。

设计系统（Design System）是一套可复用的组件库、样式规范与交互模式的集合，用于保证产品在多个模块之间视觉与行为的一致性。对AI编程工具而言，理解设计系统意味着它不能只根据局部提示生成代码，而要能检索并遵循既有的令牌（token）、组件命名和布局约定。这也是评估AI编程工具“上下文能力”的关键指标：能否在生成前主动建立对代码库整体结构的认知，而非孤立地产出片段。

Astra做对了什么：持续执行与常识补全

Ding 对比了 Astra 与其他AI系统的差异，给出两个具体观察。

其一，任务执行的持续性。 她提到，其他AI系统有时会“忘掉”之前的要求，只执行最后一条指令。而 Astra 会持续跟进每一项任务，逐条执行到位。多任务指令下的上下文保持能力，是区分工具可靠性的分水岭——它决定了用户是否需要在每次对话中重复交代背景。

其二，常识性补全。 Astra 不仅完成明确说出的部分，还会用常识填补那些没有显式说明的空白。对于非工程背景的使用者来说，这一点尤其重要，因为他们的提示词往往不够精确，需要工具主动推断意图。

上下文保持（context retention）指AI系统在多轮对话或多任务指令中，持续记住先前约束与要求的能力。受限于模型的上下文窗口以及指令优先级的处理方式，部分系统会出现“遗忘”早期指令、只响应最新一条指令的现象。持续执行多项任务要求模型具备任务分解、状态跟踪与逐条核对的机制，这直接决定了用户是否需要反复重述背景，也是衡量工具能否用于真实生产工作的重要维度。

非工程团队的生产力释放

Ding 特别强调，这套工具对团队中非工程背景成员的帮助最为显著。过去，他们有个想法、想搭一个对自己工作流有用的东西，必须等待工程同事排期协助；现在，他们可以自己想到、自己构建、立即投入使用。

这种变化的意义不止于效率。它改变了组织内部“谁能造工具”的权力结构——工具的生产者从少数工程师扩展到所有能清晰描述需求的人。Ding 用一句话概括：现在他们什么都能构建。

提示词精度（prompt precision）指用户输入指令时对目标、约束与边界的明确程度。工程背景用户通常能写出结构化、边界清晰的提示，而非工程用户往往依赖模糊的自然语言描述。具备常识补全能力的AI系统会主动推断未明说的意图、填补缺失的约束，从而降低使用门槛。这种能力把“能否造工具”的门槛从编程技能转移到需求描述的清晰度上，也正是非工程成员得以自主构建的关键前提。

给管理者的启示

Ding 的分享指向一个务实的结论：AI 转型的起点不是采购预算，也不是培训计划，而是管理者自己是否真正在用。她的做法提供了一个可复制的样本——选一个真实存在、非演示性质的工作任务，用AI从头做一遍，体会它在多任务保持、上下文理解和常识补全上的真实边界。

当高管本人能说出工具“哪里会忘事、哪里能补位”，组织内的推广才具备可信度。天花板的高度，取决于站在上面的人有没有亲手碰过这些工具。