AI时代，工程师不能停在把功能做出来

最近在更新海外站点时，我对“审美”和“判断力”这两个很抽象的词，开始有了一点实感。

这次更新需要把国内站点的内容翻译到海外。业务逻辑的开发几天前就完成了，但等我有时间完整走查时，还是发现了不少基础的措辞和表达问题。

有些文案带着明显的翻译腔，有些出现语法错误，还有些按钮虽然每个单词都没错，放在那个页面里就是别扭。

我一开始有点气愤。因为在我看来，这些问题并不需要多么高深的专业能力，但凡细致一点，自己从头到尾点一遍，应该都能看出来。

所以我下意识地认为：没做好，就是态度问题。

但研发负责人告诉我，我看到的版本，已经是研发同学自己调整过很多轮的结果了。他们并不是完全没有检查，而是真的觉得这样已经差不多了。

这时我才意识到，有些问题在我眼里非常明显，但在另一些人眼里，可能根本就不存在。

不是他没有看，而是他看不见。

以前听人讲，优秀的产品经理要能够随时切换到小白视角，看到普通用户觉得困惑和不舒服的地方。

这种话听起来很像天赋。

好像有些人生来就敏感，能够一眼看出哪里不对；有些人天生粗线条，再怎么说也没用。

但这次经历让我越来越倾向于认为，所谓审美和产品感觉，更像是长期积累出来的一套判断系统。

你看过大量好的产品，也用过大量难用的产品；你知道一句自然的英文是什么感觉，知道一个专业网站通常如何组织信息，也知道用户看到某个按钮时会产生什么预期。

这些经验并不会每次都以明确的方法论出现在脑子里。

更多时候，它表现为一种模糊但迅速的感觉：这个地方不对，这句话不是人话，这个流程虽然能走通，但就是显得很糙。

这就是所谓的“品味”。

只是品味并不是凭空产生的。它来自大量接触、比较、反馈和修改。

很多工程师缺少的，未必是责任心，也不是智力，而是过去的工作长期只要求他判断一件事：功能有没有正确运行。

至于用户看不看得懂、整体是不是协调、交付物像不像一个成熟产品，通常会由产品、设计或者业务负责人来兜底。

时间久了，岗位边界也就变成了注意力边界。

不属于自己职责范围的东西，大脑会自动忽略。

过去，功能实现本身很贵。

一个需求从想法变成可以运行的产品，需要写代码、调接口、处理异常、测试上线。研发把功能稳定地做出来，就已经完成了最核心的价值交付。

但AI正在迅速压缩这部分成本。

代码可以生成，页面可以快速搭建，文案可以直接翻译，测试用例也可以批量补齐。很多过去需要几天完成的执行工作，现在几个小时就能做出一个初稿。

问题是，初稿变多了，不等于高质量的交付变多了，甚至可能恰恰相反。

因为AI越擅长快速生成“差不多能用”的东西，团队就越需要有人判断：它是不是真的能用，是不是足够准确，是不是符合用户习惯，是不是达到了可以交付的水准。

以前最贵的是生产。以后更贵的，很可能是判断。

这也是为什么，很多团队里的每个人都说自己用了AI，效率提升了很多，但整个团队的交付效率并没有明显变高。

研发写代码快了，产品写需求快了，运营写文案快了，每个人手上的任务都更快地进入“完成”状态。

但这些结果最终汇总到一起，还是需要少数几个人逐项检查：
-这个功能是否真的解决了问题？
-这个交互是否会让用户困惑？
-这个英文表达是不是自然？
-这个页面能不能代表公司的专业水平？

只要负责最终效果判断的还是同一个人，整个系统的瓶颈就没有消失。

上游生成得越快，下游验收反而越堵。

大家都在高速生产半成品，最后排着队等一个人返工。这不叫真正的提效。

真正的效率，不是每个岗位都更快地把任务扔给下一个人，而是整个链路能够用更少的返工，交付更好的结果。

所以在我看来，AI时代的工程师，不能再把自己的职责简单理解为“按照需求把功能实现出来”。

这不是说，研发以后要包办产品、设计、翻译和运营。专业分工仍然有价值。不同岗位的核心能力，也不会因为AI出现就完全消失。

真正发生变化的是，所有岗位都需要多向结果走一步。

以前可以说，我的代码没有bug，至于文案奇不奇怪、流程顺不顺、用户能不能理解，那是其他人的问题。

以后这种交付方式会越来越站不住脚。因为当实现功能已经变得越来越容易，公司凭什么继续为“把需求变成代码”支付高溢价？

真正有价值的人，必须能够回答更多问题：
-这个需求为什么要做？
-用户最终要完成什么任务？
-目前的方案虽然能跑，但体验是否足够好？
-有没有明显会影响结果的问题？
-我交出去的，到底是一段代码，还是一个可以被用户使用的产品体验？

AI时代，岗位的边界会逐渐从“我负责完成什么动作”，转向“我能够闭环交付什么结果”。

一个工程师未必需要拥有顶级设计师的审美，也未必需要独立决定产品方向。

但至少不能做完一个自己都没有完整体验过的功能，然后把所有明显的问题留给别人发现。

“功能实现了”只代表工作开始收尾，不代表已经完成交付。

当然，把这些问题归结为一句“大家要提高质量意识”，基本没有用。

判断力不是开一次会就能长出来的，审美也不是提一个要求就能自动拥有。

如果团队过去只训练如何实现功能，现在却突然要求所有人对最终体验负责，那管理方式也必须跟着变化。

第一步可能是让大家看见差距。

为什么这句话不自然，为什么这个页面显得廉价，为什么一个功能明明能用，却会让用户不敢信任。

这些判断不能只停留在负责人的脑子里，而要通过一次次走查、对比和反馈，慢慢变成团队共同理解的标准。

第二步，是把质量判断前移。

不能等到功能全部开发完成，再由产品负责人进行一次总验收。到了那个阶段，很多问题已经变成返工，修改成本和沟通成本都很高。

更合理的方式，是让研发在实现过程中，就知道最终会按照什么标准判断，而不是只对照需求文档检查有没有遗漏功能点。

再往后，团队还可以把稳定的方法、案例和判断标准逐渐沉淀下来，变成检查清单，甚至变成可以自动巡检的Agent。

比如自动识别翻译腔、不一致的术语、异常的交互文案和常见体验问题。

但工具只能帮助放大标准，不能替代标准本身。

如果团队根本说不清楚什么叫好，Agent也只会更快地检查出一些表面问题。

这也是我们接下来需要探索的事情：怎么把少数人脑子里的口味，逐渐变成一个团队可以学习、复用和强化的能力。

AI让做出一个东西越来越容易。但也正因为如此，“做出来”本身越来越不值得炫耀。

以后真正拉开团队差距的，不是谁能更快地堆出更多功能，而是谁能让更多人独立判断质量，并稳定地交付一个不糙、可信、像样的作品。

功能完成，不再是交付的终点。

它只是结果验收的起点。