原创 裴伟伟 2026-09-14 18:05 山西

AI 开发越来越多的时候，工程师的判断力越来越重要。

在软件开发中，我们很熟悉这样一种工作方式：产品经理负责想清楚需求，设计师负责画清楚界面，开发人员按照文档实现功能，项目经理盯着时间推动交付。每个人都有自己的职责，也有相应的交付标准。遇到问题，先判断属于哪个环节，再找对应的人处理。这套分工能够支持复杂项目的协作，也逐渐形成了一种习惯：开发人员开始工作之前，应该有人先把“做什么”想清楚。

但 AI 正在改变这个前提，当工程师能够借助 AI 更快地完成原型、验证方案和实现功能时，一部分原本需要通过文档和会议提前确认的问题，已经可以通过实际构建来获得答案。如果仍然把自己的职责限定为接收需求、编写代码、提交测试，工具带来的收益就主要停留在执行环节。至于应该做什么、先做什么、做到什么程度，项目仍然需要在原来的协作链条里等待。

所以，吴恩达认为：具备 AI 工程能力的人，应当更加主动地参与塑造产品。这要求工程师理解用户、作出取舍、协调相关人员，并持续跟进结果。代码写得更快之后，工程师有条件承担更完整的工作，也需要为自己的判断建立更充分的依据。

一、实现能力增强之后，判断力会成为新约束

过去，一个想法是否值得尝试，往往先受到开发成本的限制。做一个原型需要排期，调整一次流程需要协调资源，验证失败还可能意味着前面的投入无法回收。因此，团队会把不少精力放在事前讨论，希望在开始开发之前尽量想清楚。这种做法有其合理性，毕竟试错需要付出成本。

当 AI 降低部分实现工作的成本之后，项目的约束也会随之变化。一个功能可以很快做出来，但团队未必知道它是否值得做；一个页面可以迅速生成，但用户的实际困难可能根本不在界面上。也就是说，开发实现速度提高，并不会自动带来需求理解和产品判断的提高。如果方向没有得到验证，效率提升也可能表现为更快地堆积技术债务。

这有点像装修房子：工具改进之后，施工速度可以提高，但房间如何安排、动线是否合理、哪些墙不能拆，仍然需要有人判断。施工能力越强，越需要在关键位置把这些事情想清楚。软件开发也是如此：工程师能够完成更多工作之后，就需要更加清楚每项工作为什么值得投入，以及它和用户的问题有什么关系。

二、推动开发，需要知道下一步应该验证什么

软件开发通常包含一个反复进行的过程：实现一部分内容，获得反馈，再决定下一步。工程师参与产品构建，首先体现在能够推动这个过程。当前阶段最大的疑问是什么，需要通过什么方式获得答案，投入多少才合适，这些判断决定了项目能否持续向前。

假设团队要做一个内部知识库助手，最开始需要确认的，可能是现有文档能否支持有效检索，以及回答是否能够准确引用资料。此时，一个范围有限的技术原型就有价值。基础能力得到验证之后，再让员工带着真实问题试用，观察它是否减少了查找资料和反复确认的时间。至于完整后台、个性化配置和更多交互功能，应当根据这些反馈确定优先级，这个过程其实就是产品的迭代，先用MVP确认需求是存在的，再用迭代完善产品的能力。

如果基础问题尚未解决，就开始不断补齐周边功能，项目很容易进入一种忙碌却缺乏进展的状态，所以笔者在产品管理中尤其重视对于每一项需求的记录与跟踪，它能够帮团队看到每一个新需求的价值。如果页面越来越完整，代码越来越多，团队对产品的理解却没有明显增加，那么这种忙碌会让团队陷入疲惫但无成就感的怪觉之中。频繁交付应当帮助团队缩短获得反馈的时间，并为下一次投入提供依据，一个小版本能够排除关键疑问，就可能比一个功能齐全的版本更有价值。

因此，工程师们需要根据项目阶段选择行动。有时应该写代码，有时应该找用户交流，有时需要做技术实验，也有时应该暂停一个方向。能够作出这些选择，才能把 AI 提供的执行能力转化为项目进展，否则，原来是等需求，现在只是更快地把需求做完，然后继续等，前置时间会造成诸多资源浪费。

三、需求文档里的空白，本来就需要工程师判断

要求工程师具备产品意识，容易被理解为让开发人员再兼职一个产品经理。实际上，即使岗位分工非常清楚，工程师也一直在参与产品决策，因为需求文档无法穷尽所有场景，开发过程中遇到的默认值、异常处理、交互顺序和信息展示，都包含对用户行为的假设。

例如，知识库助手找不到可靠答案时，应该继续生成一段解释，还是明确告知资料不足？资料已经过期，是否仍然展示？用户等待较长时间之后，需要看到什么反馈？这些看起来属于实现细节的选择，会直接影响用户能否理解系统状态，以及是否愿意信任结果。即便没有经过和产品经理的讨论，也不代表这些决定就不重要，它们只是以默认实现的形式进入了产品。所以以笔者的经验来看，无论多么详实和周全的产品经理，都无法覆盖50%以上的产品细节，而剩余的部分就是靠工程师的产品理解来补充的。

产品判断需要建立在对用户工作的理解上。用户提出“搜索不够智能”，原因可能是文档名称混乱、制度长期没有更新，也可能是找到资料之后仍然需要向负责人确认。如果没有了解后续流程，就很容易把一个业务问题收缩为一个模型能力问题，最后交付了更流畅的问答体验，却没有减少用户实际付出的时间。

工程师不需要一开始就掌握完整的产品方法论，但至少应该愿意观察用户如何完成任务，并追问需求背后的原因。同时，也要理解基本的成本约束：功能带来的收益是否值得持续支付调用、维护和人工核查成本。能够把使用价值和运行成本放在一起考虑，技术方案才更接近一个可以长期使用的产品。

四、工作范围扩大，沟通就成为工程能力的一部分

当工程师开始参与更广泛的决策，单纯说明“技术上可以实现”已经不够。业务人员需要了解实现条件，管理者需要判断投入是否合理，运营人员需要知道上线后如何处理例外情况。同一个方案，只有被这些相关人员正确理解，才有可能得到有效执行。

业务负责人提出“让 AI 自动处理工单”，工程师需要进一步说明哪些类型适合自动处理，哪些只能提供建议，什么时候需要人工介入，以及处理错误之后如何恢复。这里需要把技术能力与业务后果联系起来。“模型可能出错”提供的信息有限，而指出某类错误可能导致工单流转到错误部门，因此需要在初期保留确认步骤，才能帮助团队作出具体选择。

这种沟通也包含对组织预期的校准。演示成功可以证明某些能力可行，但持续运行还涉及数据、稳定性、成本和异常处理。工程师需要把已经验证的部分、仍然存在的不确定性以及下一步验证方式讲清楚。技术理解越深入，越应该有能力把这些边界表达得具体，而不能只用专业术语代替解释。

五、主动承担结果，也需要相应的权限和空间

吴恩达非常强调工程师的主动性，也就是：在方向尚未完全明确时，能够发现问题、提出可验证的方案，并持续推动事情获得结果。比如发现同事反复手工整理同一类报表，工程师可以先了解数据来源和使用目的，尝试一个有限范围的方案，再说明预期收益、所需资源和当前限制。这样，团队就有了进一步讨论和决策的基础，而这本身也是需求洞察的能力。

主动性还体现在交付之后。系统是否被使用，原来的困难是否减少，新增成本是否可以接受，出现问题后由谁推动修正，都需要继续跟进。任务完成可以通过交付清单确认，价值是否产生则必须回到实际使用中观察。愿意追踪这些结果，才有可能逐步提高下一次决策的质量。

不过，企业也不能借此把所有岗位职责压到一个人身上。希望工程师对结果负责，就需要让他们接触用户、理解业务背景、参与优先级讨论，并获得必要的资源和决策空间。如果目标不能讨论，需求不能调整，资源不能协调，却要求个人承担全部结果，这种安排只会增加责任压力，很难形成有效的主动性。跨岗位参与工作的前提，是专业协作和授权能够跟上。

对于工程师而言，这种变化可以从当前工作开始应对：理解一个需求的真实用途，主动验证一个关键假设，解释清楚一次技术取舍，跟进一次上线后的效果。同时，继续积累技术深度，保持对工具和工作方式的学习。能够判断实现质量、识别系统限制、设计有效验证，参与更广泛决策才有可靠的基础。

AI 提供了更强的构建能力，也让工程师有机会更直接地影响产品方向。面对下一项需求，除了估算需要多少时间，还应该能够说明：为什么值得做，准备验证什么，以及如何判断这次投入产生了价值。工程师的主见，就应当建立在这些具体问题的答案上。

跳转微信打开