最近我基于 AI 完成了一个需求的初版然后交给产品验收。产品体验之后给出了一份非常详细的修改意见哪里需要调整、交互应该如何变化、什么场景没有覆盖、哪些表达不符合业务习惯以及最终期望呈现成什么样。我没有重新整理没有把它翻译成技术方案甚至没有认真“加工”一遍而是将产品的修改意见原封不动地交给了 Agent。Agent 很快完成了修改而且结果相当不错。于是我开玩笑说我现在就是一个无情的“产品 → Agent 转换层”。这句话听起来像是在调侃自己没有做什么工作却意外触碰到了 AI 时代一个值得认真讨论的问题当 AI 的执行能力越来越强处在业务、产品与技术之间的人究竟还有什么价值研发会不会逐渐变成需求的传话筒产品是否可以直接把需求交给 AI如果自然语言已经能够驱动系统生成代码那么过去层层翻译的软件生产链路还有没有存在的必要表面看这是一个关于职业分工的问题。更深一层它其实是一个关于理解、上下文与责任的问题。一、软件研发本来就是一条不断翻译的链路传统的软件生产过程本质上是一连串的信息转换业务目标 → 产品需求 → 交互设计 → 技术方案 → 编程语言 → 可运行系统业务人员说“我希望降低用户投诉。”产品经理将它翻译成具体功能用户在哪些场景下容易投诉系统应该增加什么能力哪些流程需要调整如何判断功能是否有效研发再将产品语言翻译成技术语言涉及哪些系统和服务数据从哪里来接口如何设计状态如何流转异常如何处理如何保证性能、安全和可维护性最后程序员把这些技术设计翻译成机器能够执行的代码。所以从某种意义上说软件工程中的大多数角色本来就是“转换层”。业务把现实世界的问题翻译成目标产品把目标翻译成需求架构师把需求翻译成系统边界研发把系统设计翻译成代码。过去这条链路很长是因为每一层都只能理解特定形式的信息。业务不需要理解数据库索引产品不应该依赖某一种编程语言计算机也无法直接理解“提升用户体验”意味着什么。每一层都负责消除一部分歧义再把结果交给下一层。AI 的出现并没有改变软件生产是一种“翻译活动”这个事实。它改变的是自然语言与可执行结果之间的距离突然大幅缩短了。二、AI 压缩的首先是执行距离而不是理解距离过去产品提出一项修改即使描述得非常清晰研发仍然需要完成大量机械执行找到对应代码理解已有实现修改页面或接口补充数据处理逻辑调整测试运行验证修复编译和运行错误。现在具备代码库访问能力的 Agent 可以完成其中相当大的一部分。这会给人一种强烈感受研发似乎只是把产品的文字转交给 AI自己变成了一个多余的中间层。但仔细观察会发现AI 缩短的主要是从清晰意图到具体实现的执行距离而不是从模糊问题到清晰意图的理解距离。产品说这里要增加一个筛选条件。这句话对人和 AI 来说都不够。筛选什么数据范围是什么是否支持多选默认值是什么条件之间是什么关系是否影响导出历史数据如何处理权限不足时如何展示移动端如何交互真正困难的部分从来不是把一个输入框画出来也不是写一条查询条件而是确定这个筛选条件在完整业务中究竟意味着什么。AI 可以很快执行一个明确任务但它无法凭空获得组织内部没有提供给它的事实。它也不能稳定地替人决定那些尚未形成共识的业务规则。因此AI 时代需要区分两类问题第一类任务已经被理解只是尚未执行这类任务目标明确、边界清晰、验收标准具体。AI 通常完成得很快。第二类问题本身还没有被理解不同角色对目标的认知不一致关键规则没有确认例外场景没有定义甚至大家对“完成”的判断都不同。这类问题即使交给再强的模型AI 也只能在缺失的信息之间进行概率补全。它可能写出高质量代码却解决了错误的问题。所以AI 能力越强我们越容易误判一件事输出质量高不等于问题理解正确。一个执行能力很强、上下文却不足的 AI最大的风险往往不是“什么都做不出来”而是非常高效地做出一个看起来合理的错误结果。三、为什么“原封不动转发”这一次有效回到开头的例子。产品给出详细修改意见我原封不动交给 AgentAgent 很快完成了修改。看起来价值全部来自两端产品负责思考Agent 负责执行中间的人只是复制粘贴。但这次协作能够成功实际上依赖了很多没有出现在那段修改意见里的前置条件。首先系统已经有了一个初版。这个初版不是单纯的代码它是一次对需求的具体解释。产品不再面对抽象描述而是在一个可操作的对象上指出差异。“这里不对”之所以有意义是因为双方已经能看到同一个“这里”。其次Agent拥有代码库上下文。它知道产品提到的页面在哪里、相关功能如何实现、现有模块采用什么结构以及修改可能影响哪些文件。再次产品的反馈足够具体。它描述的不是“感觉不好”“再优化一下”而是当前状态与目标状态之间的差异。最后我仍然处于这个反馈闭环中。我知道产品在讨论什么知道当前实现是怎样形成的也有能力判断 Agent 的修改是否偏离了目标。因此真正发生的事情不是产品意见 → 我复制 → AI 写代码而是已有需求共识 可运行初版 产品差异反馈 代码库状态 工程规范 Agent 执行 人工验收那段被“原封不动转发”的文字只是这套上下文系统中最后增加的一块信息。换句话说复制粘贴之所以有效不是因为上下文不重要而是因为大量上下文已经提前存在。这也是很多 AI 使用经验难以复制的原因。有人展示一句提示词AI 就生成了非常好的结果。其他人照抄提示词却得不到同样的效果。差异往往不在那一句话而在提示词之外模型此前看过什么当前工作区里有什么任务已经推进到哪个阶段双方共享了哪些术语示例、约束和历史决策是否存在结果如何被验证和纠正。我们看到的是最后一次输入却忽略了此前已经建立起来的上下文。四、上下文不是“多给一些资料”AI 时代人们越来越频繁地使用“上下文”这个词但上下文很容易被误解为把更多文档、聊天记录和代码都塞给 AI。资料多不等于上下文充分。没有组织的信息只会形成更大的噪声。真正有效的上下文至少应该回答六类问题。1. 目标为什么要做不是“增加一个按钮”而是这个按钮要帮助谁完成什么任务、改善什么指标、解决什么问题。2. 事实当前是什么状态包括现有系统、数据来源、代码实现、业务流程、用户行为和已知问题。3. 约束什么不能被破坏例如兼容性、权限、性能、合规要求、交付时间、技术边界和历史包袱。4. 规则遇到不同情况应该怎么判断正常路径通常不难真正决定系统质量的是边界条件、异常分支和冲突规则。5. 标准怎样才算完成如果没有可验证的验收标准“完成”就只是生成了一些产物。6. 状态任务现在进行到了哪里初次设计、已有初版、局部修改和线上故障处理需要的上下文完全不同。所以上下文工程不是简单地“喂资料”而是把分散在人的经验、组织规则、历史系统和当前任务中的信息整理成一个可供推理和执行的环境。可以将 AI 的有效产出粗略理解为有效结果模型能力×上下文质量×验证能力有效结果模型能力×上下文质量×验证能力这里更接近乘法而不是加法。模型很强但上下文接近于零结果仍然不可控上下文充分但没有验证机制错误可能直接进入生产验证严格但目标本身错误也只能保证“正确地实现错误需求”。五、研发会不会沦为“产品需求传话筒”会但只有一部分研发会。如果一个研发的主要价值长期停留在接收已经非常明确的需求按固定模式增删改查把产品描述手工改写成代码遇到问题再由别人决定最后确认代码能够运行那么这部分工作的确会被 Agent 大幅压缩。这不是因为 AI 突然拥有了完整的软件工程能力而是因为这类工作本来就高度依赖执行理解与决策的比例较低。但把这个结论扩大为“研发不再重要”仍然过于简单。在真实的软件系统中产品意见很少能够覆盖全部工程事实。产品可能说“列表增加一个状态筛选。”研发需要进一步判断这个状态来自哪个系统前后端枚举是否一致历史数据是否存在空值查询是否会导致索引失效是否影响缓存键导出接口是否同步支持不同组织权限下是否应该看到相同选项状态未来是否可能扩展这次修改是局部需求还是暴露了领域模型设计问题这些并不是把产品语言“翻译成 Java 或 TypeScript”而是在补充产品视角之外的系统上下文。因此研发不会因为不再亲自编写每一行代码而失去价值。真正发生的是研发的价值正在从代码的生产者迁移为业务意图与可运行系统之间的建模者、约束者和验证者。代码仍然重要但“写出代码”不再是最终目的。研发需要确保系统在复杂约束中长期正确运行。过去一名研发可能把大量时间花在“怎么写”上未来他会把更多精力放在应该做什么为什么这样做哪些假设尚未验证系统边界如何划分哪些规则应该固化如何让 AI 稳定复现正确结果如何证明结果没有破坏原有系统。这不是研发价值的消失而是价值重心的上移。六、真正的“转换层”不是传话而是编译“产品 → Agent 转换层”有两种完全不同的形态。第一种是机械转发器。收到什么就转发什么对输入不质疑对结果不验证也不对最终效果负责。这类转换层确实没有多少不可替代的价值。第二种更像编译器。编译器并不创造业务意图但它会完成一系列关键工作检查输入是否完整识别语义是否冲突补齐执行所需的信息将目标转换成可执行任务注入工程约束检查结果是否符合契约在失败时提供可定位的反馈。高质量的 AI 协作者不是消息中转站而是意图编译器。产品说“把这个页面优化一下”他不会立即让 AI 开始改颜色和间距而是先明确优化目标究竟是信息密度、操作效率、视觉层级还是移动端适配。业务说“做一个智能分析能力”他不会立刻接入大模型而是先确认输入数据、目标用户、决策场景、错误成本和人工兜底机制。AI 给出一个能够运行的实现他也不会把“能运行”当作“已完成”而是依据需求、架构、安全性和可维护性进行验证。从这个角度看AI 时代真正有价值的转换层至少承担四项职责意图澄清把模糊愿望转化为具体目标但不擅自替业务做决定。上下文编排为 AI 提供完成当前任务所需的事实、规则、边界和历史状态。执行控制把复杂目标拆成适合 Agent 执行和反馈的任务控制修改范围与风险。结果验收判断产物是否满足真实目标而不只是形式上符合指令。这四项能力共同构成了 AI 应用中的关键闭环理解 → 建模 → 执行 → 验证 → 反馈AI 可以深度参与其中每一步但至少在当前阶段人仍然需要对整个闭环负责。七、产品、研发和管理者的角色都会变化AI 带来的变化不会只发生在研发岗位。对产品经理而言需求文档正在变成可执行输入过去需求文档主要用于人与人沟通。未来它还会直接驱动 Agent 生成原型、代码、测试和文档。这意味着产品表达不能只做到“让熟悉业务的人大概明白”而需要更加结构化目标用户是谁当前问题是什么主流程和异常流程是什么哪些行为必须保持不变冲突规则如何处理验收标准如何验证。产品不一定需要学习编程但需要提高可执行表达能力。一份高质量需求不只是描述想法而是在建立一个机器和人都能共同工作的任务模型。对研发而言编码能力仍是基础但不再是完整能力不会写代码的人很难判断 AI 写出的代码是否可靠只会写代码的人也可能难以驾驭 AI 完成复杂工程任务。未来更重要的能力组合是业务理解系统建模架构判断上下文组织Agent 任务分解自动化验证风险识别结果负责。研发需要从“实现需求”进一步走向“经营系统正确性”。对技术管理者而言不能只采购 AI 工具许多组织引入 AI 的方式是给员工购买账号然后统计使用率和生成代码量。这远远不够。如果组织内部的需求长期模糊、文档彼此冲突、领域术语不统一、工程规范没有沉淀、测试体系薄弱那么 AI 只会放大原有问题。管理者真正需要建设的是组织级上下文基础设施可检索的业务知识清晰的领域模型可信的接口契约可执行的工程规范自动化测试和质量门禁决策记录与变更历史权限、安全和审计机制。AI 的上限不只由模型决定也由组织能够提供多少高质量上下文决定。八、上下文工程会成为 AI 时代的基础能力提示词工程曾经受到大量关注但单次提示词的技巧正在快速贬值。模型越来越能理解自然表达也越来越会主动调用工具、搜索代码和拆解任务。真正困难的不再是找到某个“神奇句式”而是建立一套持续、可靠、可复用的上下文供给机制。上下文工程关注的不是“这一句话怎么写”而是AI 应该知道哪些信息信息的权威来源在哪里哪些内容需要按任务动态加载如何避免过期信息污染判断如何让业务规则可被机器读取如何将工程约束嵌入执行过程如何保存任务状态和决策历史如何通过测试验证上下文是否被正确理解。进一步说企业未来的重要数字资产不只是代码和数据还包括业务知识、决策规则、组织约束与执行标准的机器可理解表达。过去这些内容大量存在于人的脑中、聊天记录里、会议纪要里或者散落在已经离职的核心员工经验中。AI 要真正进入企业核心生产流程就必须把这些隐性知识逐渐显性化、结构化并建立更新机制。这件事的意义甚至超过“让 AI 更好用”。因为一旦组织能够清楚地表达自己如何运作人本身的协作效率也会提高。九、AI 越强人越需要对“为什么”负责当执行成本下降错误执行的成本也可能被放大。以前一个模糊需求进入研发阶段可能因为实现困难而被迫反复讨论。这个过程效率不高却客观上形成了一道减速带。现在AI 可以在几分钟内生成完整实现。模糊需求不再因为执行困难而暴露反而可能迅速变成大量代码、配置和上线变更。因此AI 越强我们越需要在执行前问清楚这是正确的问题吗目标是否得到相关方确认隐含假设是什么哪些事实来自可靠来源错误结果的代价是什么谁来验收谁对最终结果负责AI 可以参与分析也可以提供建议但责任不能通过一句“这是 AI 生成的”被转移。在软件工程中真正专业的人并不是那个亲手敲下最多代码的人而是那个能够解释为什么要这样设计它依据了什么事实在什么边界内成立我们如何证明它是正确的以及出现问题时如何处理。AI 让“做出来”变得便宜也因此让“为什么这样做”变得更加珍贵。十、从“无情的转换层”到“有判断的责任层”回头看“无情的产品 → Agent 转换层”这个玩笑一半是真的。未来我们确实会越来越频繁地把业务或产品的自然语言直接交给 Agent。很多过去需要数小时甚至数天的编码工作会被压缩到几分钟。但另一半并不成立。当一次转发能够获得好结果时往往说明需求已经清晰、上下文已经建立、系统能够被理解、反馈足够具体而且有人在为结果把关。真正高质量的工作可能发生在按下发送键之前也可能发生在 AI 返回结果之后。中间那次复制粘贴很轻但支撑它的理解并不轻。所以我更愿意把 AI 时代的核心变化总结为执行能力正在快速普及构造正确执行条件的能力正在成为稀缺资源。未来不只是研发每一个知识工作者都可能成为某种“人与 Agent 之间的转换层”。问题不在于我们是不是转换层而在于我们是哪一种转换层是原样传递信息、无法判断结果的消息管道还是能够理解目标、组织上下文、约束执行并承担责任的意图编译器前者终将被继续压缩。后者可能正是 AI 时代最重要的新型专业能力。当 AI 已经能够高效地回答“怎么做”人的价值将越来越集中在几个更难的问题上做什么为什么做做到什么程度以及我们如何知道它真的做对了。References从汽车转向灯的声音聊聊软件开发中的那些“细枝末节”
