一条动态：非工程角色被鼓励自己造工具

消息提到，1Password领导层基于工程团队的结果，正把Codex权限扩展到财务、市场等职能团队，让这些团队构建自己的工具。其CTO称，产品、设计、研究、开发岗位的人都在变成构建者，产品经理开始交付产品，设计师开始交付前端代码，并预测未来12个月更多传统上不写代码的人会熟悉AI工具、有信心交付代码。这是企业内部的判断和预告，不是全行业招聘门槛。

简历里要不要放“自己用AI做出来的东西”

先读岗位描述，区分两类要求。一类写“与技术团队协作、推动落地、需求分析”，重点是流程与判断；另一类写“独立完成原型、可运行Demo、端到端交付”，才需要放可运行产出。同一句“熟悉AI工具”，在前者可能指用AI写文档、做竞品分析，在后者可能指能提交可评审的原型，两者准备方式完全不同。

不要因为一篇企业案例就默认所有产品岗都要求写代码。可以做一个假设场景：两个求职者都做过用户调研，A只写“输出调研报告”，B写“把调研结论做成可点击原型，交给工程师评估可行性”——后者更贴近“构建者”叙事，但前提是B真的做过。简历成果必须实际完成才写，没有就留白，用[实际记录]占位，别编数字。

面试怎么问清团队对动手能力的真实期待

别只问“你们用不用AI工具”，这只会得到笼统回答。可以问：团队里产品/设计是否直接提交代码或原型？评审流程怎么走，非工程角色的产出算不算交付物？需求从想法到可验证版本通常经过谁的手？这些问题能帮你判断岗位是“用AI提效”还是“要求独立产出”。

素材里提到，Codex可把需求拆成功能规格、构建接近最终形态的原型，再交给系统工程师接入后端。这说明“动手”未必等于写工程级代码，也可能是把需求变成可评审原型。面试时围绕“我如何缩短从想法到可验证产出的距离”讲，比强调“我会用某工具”更实在。

决定补能力时，优先补什么

优先补“把需求变成可评审原型”的闭环：拆需求、写清验收标准、做出能给人看的东西、收集反馈再改。不必追求工程级代码。可以练习向目标岗位的人核查：这个能力在你们团队算加分还是必需？

一个实际可做的小建议：挑一个你熟悉的岗位描述，把其中“AI相关”要求逐句标成“提效”或“独立产出”，再对照自己的经历，缺哪块补哪块。