前端工程师 · 任务逐条

把设计稿变成能用的界面

这是整个软件工程里暴露度最高的一项任务,原因很机械:输入是视觉的、输出是文本、对不对看一眼就知道,而训练数据就是整个公开的网。「从一张图或一句话生成一个界面」的工具,比「生成一个后端服务」的工具更早达到可用质量。

能渲染出来的界面不等于能发出去的界面。它不说明产物是否可维护、是否符合已有的设计体系,也不说明它在没人画过的那些状态下会怎样 —— 空数据、加载中、出错、加载了一半的列表。

没有人画过的那些状态

生成是从顺利路径出发的,因为设计稿里画的就是顺利路径。而实际代码的大部分恰恰长在其余那些状态里,并且「每一种该怎么表现」是关于这个具体产品的判断,不是一个可以检索出来的模式。

这是一条关于「工作落在哪儿」的判断,不是对它的测量。团队并不会去统计自己前端代码里有多少是边界情况处理,所以没有一个数字可以拿来核这句话;而一个营销页和一个交易界面之间,这个比例差得极远。

让它在真实设备与真实网络上活下来

在这件事上工具测得比人好 —— 预算、审计与性能剖析,正是软件擅长的那种机械检查。它们做不到的是决定接受哪一个取舍,因为那取决于你的用户到底是谁,而那是一个关于生意的事实,不是关于代码的事实。

这里没有任何东西说明这件事要花多少工时、团队到底做不做 —— 大量已经上线的前端工作从来没得到过这份关注,而工具存在不等于有人跑过它。

让所有人都能用 —— 因为这是被要求的

自动检查器只能抓住一小部分真实的可访问性问题,而且判断不了「一个看不见的人能不能走完这个流程」。这项任务同时正在若干市场里从「良好实践」变成「法律义务」—— 那改变的是「谁要为它答复」,不是它有多难。

这里的方向判断建立在「要求的形状」上,而不是建立在一个测出来的结果上;能把它定下来的,是一次点名了具体界面、并说清那里错在哪的执法行动。要求因市场而异,也取决于产品是否面向消费者。

维护别人都在用的那套组件

生成变便宜让这件事更承重,而不是更轻:当任何人几分钟就能产出一个界面,让产品保持一致的就是那层约束,而它必须有人守着。这份工作的内容是「拒绝」与「版本管理」,不是「创作」。

它是一份工作还是一件顺手的事,完全取决于团队规模;而「有多少团队真的为此配人」,没有任何人在数。

为「会回话的东西」做界面

这是生成式功能进入产品之前不存在的工作,而且还没有沉淀出成型的模式 —— 每个团队现在都在各自发明「怎么表示这个答案可能是错的」。它落在前端身上,因为这是一个关于「用户看到什么」的问题,不是关于「模型做了什么」的问题。

新工作出现不等于新增编制:它目前是被塞进已有岗位里的,而这里没有任何东西说明有人是为它而被招进来的。