当 AI 开始参与开发之后，软件工程正在重新学习“如何表达”
软件工程的下一阶段，不是更快地实现，而是让理解成为结构。
——为什么端到端自动化最终会走向中间表示（IR）
在过去很长一段时间里，软件开发几乎围绕同一个中心运转：人类编写代码。
工具不断进步。从版本控制到持续集成，从云平台到自动化测试，每一次变化都在提升效率，却很少改变一件事情——开发者既理解问题，也亲自完成实现。理解与实现，始终发生在同一个人身上。
AI 的出现，第一次让这种关系开始松动。
越来越多工程师开始直接把任务交给 Agent：让它阅读仓库、规划步骤、修改实现，甚至完成跨模块的调整。从个体体验来看，这种变化几乎是立刻可感的——实现变快了，很多过去需要投入注意力的细节，被系统接管。
但当这种能力进入真实团队环境后，一种微妙的变化开始出现。
时间不再主要消耗在编写代码上，而开始消耗在另一件事情上：补充背景、解释约束，以及反复确认系统是否真正理解了“正在做什么”。
同一个需求，需要越来越长的上下文；同一次执行，需要不断校正方向；而当结果交付回来时，人往往需要重新建立对过程的理解，才能判断它是否可靠。
代码生成变得容易，但让不同参与者形成同一种理解，却变得更昂贵。
最初，这看起来只是协作方式的调整。但慢慢地，一些团队开始意识到，开发过程真正发生变化的，可能并不是效率，而是重心。
问题不再只是如何实现功能，而开始变成一个更基础的问题：
我们究竟是如何把一个问题表达给系统的？
当这个问题出现时，一件长期被忽略的事实也随之浮现——自动化真正依赖的，从来不是执行能力，而是某种可以被共同理解的中间形态。
软件工程也许一直建立在各种中间形态之上，只是过去，这些表示大多隐含在人与人之间的经验与默契之中。而当执行开始被系统承担，那些原本可以依赖理解弥补的部分，第一次必须被明确表达出来。
于是，一个新的现象开始变得清晰：当某种结构需要被反复理解、反复传递、反复执行时，它最终都会趋向被结构化。
也许，AI 并没有改变软件工程要做什么。
当执行开始交给系统，理解反而变得更困难
当团队开始反复讨论“AI到底理解了什么”时，一个原本很少被单独注意的问题开始浮现。
在软件开发中，我们似乎一直假设，只要需求被说清楚，实现自然会发生。但现实的开发过程从来不是直接从想法走向代码。需求需要被拆解，设计需要被描述，接口需要被约定，数据需要被建模。每一步之间，都依赖某种能够被共同理解的中间形态。
这些形态有时是文档，有时是接口定义，有时是组件结构，更多时候，它们只是团队内部默认成立的一种理解方式。
**它们并不直接运行，却决定了什么能够被实现；
**它们不是结果，却约束着结果如何产生。
软件工程长期运行在这些中间形态之上，只是因为人始终参与其中，我们很少需要单独意识到它们的存在。
直到 AI 开始参与开发。
当系统也需要参与理解时，那些过去依赖经验维持的中间形态，第一次变得不可回避。人类可以在模糊中达成共识，而系统只能依赖明确的结构。
也许，我们真正开始面对的，并不是新的工具，而是一件一直存在却未被清晰命名的东西——一种用于表达问题、传递理解，并支撑协作发生的结构。
在本文中，我更愿意把它称为：表示（Representation）。
软件工程一直依赖某种中间形态，只是我们很少注意它
当“表示”这个问题被单独提出之后，一个更具体的疑问随之出现：为什么这种问题直到 AI 参与开发之后才变得明显？
毕竟，软件研发一直依赖语言进行协作。
需求通过讨论形成，方案通过文字描述，评审通过评论完成。长期以来，自然语言似乎已经足够支撑复杂的软件系统运转。即使描述并不完全精确，团队成员仍然能够逐渐对齐理解，让事情继续推进。
这种能力在人类协作中几乎是理所当然的。
人可以根据经验补全上下文，可以从模糊表达中推断真实意图，也可以在发现偏差后通过交流不断修正理解。许多没有被明确写下的前提，实际上被默认为共享背景的一部分。
自然语言可以沟通，却无法稳定协作
但当参与者从“人”变成“系统”时，这种机制开始失效。
系统不会默认理解背景，也不会主动修正歧义。对于 AI 来说，每一次输入都必须成为一次可独立理解的表达；任何未被明确说明的约束，都可能被解释为不存在。
于是，一种过去被人类能力掩盖的现象开始显现：
自然语言非常擅长沟通，却并不擅长成为稳定的协作结构。它可以启动理解，却无法固定理解。
在人与人之间，这种不稳定性可以被持续交流弥补；而在人与系统之间，它却会不断累积为偏差。
当开发开始依赖系统执行时，我们第一次真正感受到这一点——问题因此不再是“说得够不够多”，而是表达能否脱离解释而独立存在。
问题开始变得清晰：我们真正缺少的，并不是更多描述，而是更稳定的表达。
当理解需要被重复，表达就开始变成结构
当自然语言不再足以稳定支撑协作时，一个看似技术性的变化开始悄悄发生。
团队开始自发地引入更多“约定”。
需求被拆成固定模板，接口被定义为明确的 Schema，任务被整理为可追踪的结构，评审开始依赖统一的检查清单。许多原本通过讨论完成的事情，逐渐被写成格式、字段和流程。
这些变化往往不是出于设计，而是出于疲劳。
当同一种解释需要被重复说明，当同一种理解需要被反复确认，人们会本能地寻找一种方式，让下一次不必重新开始。
于是，表达开始从语言滑向结构。
这种现象并不只发生在 AI 出现之后。软件工程的历史，本身就是一系列类似变化的累积：编程语言取代机器指令，接口协议取代口头约定，数据模型取代自由文本，组件系统取代页面拼接。
每一次演进，看起来像是工具升级，但背后发生的其实是同一件事——那些需要被反复理解与反复执行的内容，逐渐从描述变成结构。
因为只有结构，才能被稳定地复用。
语言可以传递一次理解，但结构可以承载无数次执行。
当参与者只有人类时，这种转变可以缓慢发生；而当系统开始参与协作，这个过程被突然加速了。
AI 并没有创造新的需求，它只是放大了一个长期存在的规律：
当某种表达需要被反复消费时，它最终都会趋向被结构化。
当理解不再依赖参与者本身，而依赖表达是否稳定时，结构便开始取代解释。
也许，这正是当前软件研发正在经历的变化——我们不是在为 AI 设计新的流程，而是在把那些过去依赖人类默契维持的理解，逐渐转化为系统可以稳定使用的表示。
当结构开始取代语言承担协作时，一个新的现象逐渐变得清晰。
团队不再只是讨论需求，而是开始生成某种“可以被执行”的任务描述；设计不再只是解释思路，而是转化为具有明确约束的模型；验证也不再依赖个人经验，而是基于预先定义的标准进行判断。
这些产物既不是代码，也不是自然语言。
它们位于两者之间。
它们描述要做什么，却尚未决定如何实现；它们能够被人理解，也能够被系统消费；它们既用于沟通，也直接参与执行过程。
在不同团队中，这些形态拥有不同名字：任务模型、规格定义、工作流、Schema、配置、Prompt 模板，或某种内部约定的数据结构。
名称各异，但角色相同。
它们正在成为软件研发过程中真正被反复传递与反复使用的对象。
换句话说，软件开发正在逐渐更多地依赖这种位于理解与执行之间的中间形态。
直到这里，一个名字终于可以被说出来。
位于理解与执行之间的那一层，正在成为新的中心
在计算机科学中，这类形态有一个并不新的名字：中间表示（Intermediate Representation，IR）。
传统上，IR 多存在于编译器内部，用于连接不同阶段的转换过程。而今天，类似的结构正在走出系统内部，进入软件研发流程本身，成为人与系统之间共享的表达层。
AI 并没有改变软件如何被实现，而是让“实现之前的表达”第一次成为系统的一部分。
IR 并不是新概念，只是第一次走出系统内部。
最初，这类中间形态往往只是局部实践的一部分。它可能出现在需求拆解阶段，或作为某个团队内部的工作约定，看起来只是为了让一次协作更加顺畅。
但当越来越多环节开始围绕这些结构运转时，一种变化悄悄发生：它们不再只是辅助表达，而开始决定流程如何展开。
研发流程不再只是由阶段连接而成，而逐渐围绕某种可以被持续消费的表示组织起来。
局部的结构，开始演变为流程的中心。
当协作开始围绕表示展开
当中间表示开始成为研发流程中的稳定对象时，一种变化随之发生。
过去的软件协作，主要发生在人之间。需求被讨论，方案被解释，代码被评审，每一步都依赖参与者对上下文的持续理解。工具只是辅助执行，而不是协作的一部分。
但当表示开始同时被人和系统共同使用时，协作的边界开始移动。
同一个任务结构，可以被工程师阅读，也可以被 Agent 执行；同一种约束，可以同时指导代码生成、测试验证与部署流程；一次表达，不再只服务沟通，而直接驱动后续行为。
协作不再仅仅发生在人之间，而开始围绕表示本身展开。
人通过表示定义目标，系统依据表示执行任务，工具围绕表示完成转换与验证。参与者的类型变得不同，但它们共享的是同一种表达对象。
于是，一种新的协作形态自然出现：不是因为 AI 更聪明，而是因为不同参与者终于能够基于同一个表示进行工作。
当表达成为共享对象时，协作便不再依赖持续解释，而转向持续消费。
软件研发开始从“人与人协作”，逐渐转向“围绕表示协作”。
有人已经开始设计“表达本身”
当协作开始围绕表示展开时，一些微妙的变化也出现在工程实践之中。
在许多团队里，开始有人花越来越多时间在一种过去并不显眼的工作上：他们不直接实现功能，而是调整任务如何被描述；不只是编写代码，而是重新组织上下文；不专注某一次执行，而是思考怎样的表达能够被持续复用。
他们修改的不只是实现，而是表达方式本身。
例如，将模糊需求拆解为可执行结构，为 Agent 补充必要约束，设计统一的任务模板，或者调整表示，使不同工具能够基于同一理解协同工作。
这些工作往往难以被传统角色定义覆盖。
它既不像架构设计，也不同于项目管理；既涉及技术判断，又影响协作方式。它的目标不是完成一次任务，而是让后续任务更容易被理解与执行。
在 AI 尚未深度参与研发之前，这类工作通常被分散吸收在经验之中，由团队默契维持。而当系统开始成为协作者，这部分隐性的能力开始变得可见。
软件工程中似乎正在出现一种新的重心：不再只是设计系统如何运行，而是设计问题如何被表达。
如果说 Builder 关注实现，System Designer 关注结构，那么正在浮现的这一角色，更接近于一种新的职责——设计表示本身。
在本文中，我更愿意把这种实践称为：Representation Architect。
这并不是一个需要被正式命名的职位，而是一种正在发生的工作方式变化。当软件研发逐渐围绕表示运转时，谁能够设计、维护与演化这些表示，谁就开始影响系统如何发展。
结语
当执行变得容易，软件工程真正困难的开始转向如何表达可以被共同理解的世界。
也许，从更长的时间尺度看，AI 对软件研发的影响，并不只是执行方式的改变。
当理解与实现不再天然发生在同一个人身上，软件工程不得不寻找一种新的稳定方式，让理解本身可以被共享、被传递、被反复消费。
过去，这种稳定性依赖经验维持；今天，它开始依赖结构存在。那些曾经存在于人类理解之中的中间形态，正在被显性化、被结构化，并逐渐成为研发流程真正的中心。
AI 并没有消灭软件工程中的表示。**
**它只是让表示第一次承担起维系理解与实现之间关系的责任。
也许，我们正在经历的，并不是一次关于效率的升级，而是一场关于“如何让理解成为结构”的重新学习。
而软件工程接下来会走向何处，也许将取决于——我们如何设计那些尚未被完全看见的表示。
相关阅读
本文是对「表示迁移模型（Representation Shift Model）」的一次阶段性展开，用于解释 AI 时代软件工程为何开始围绕中间表示重新组织。
本系列尝试记录一个正在发生的变化：当执行逐渐可以被系统承担，软件工程开始重新学习如何把理解表达为可以被持续使用的结构。相信 AI 正在推动软件工程从以编码为中心，转向以表示为中心的组织方式。