Appearance
核心论点
不要用职业名判断 AI 风险，用任务结构。
AI 改造工作的顺序不按职业声望排队，而是按反馈清晰度入侵——哪里能定义任务、观察过程、验收结果、低成本纠错，哪里就会先被推快。程序员先站到第一排，不是因为写代码低端，而是代码世界有测试、编译、日志和版本记录，环境会主动告诉模型哪里错了。
本文沉淀一套从姚顺宇「任务可评价性」推导的个人/团队 AI 风险自检工具。
一、为什么职业名是无效的风险判据
同样叫程序员，有人每天按 spec 改局部函数、跑测试、提代码；也有人理解业务目标、拆系统边界、对整个系统结果负责。同样叫产品经理，有人按模板写 PRD；也有人判断用户到底卡在哪里、定义指标、承担版本取舍。
这两组人被同一个职业名盖住了。问"程序员会不会被替代"，就像问"车会不会坏"——卡车、赛车、自行车都被塞进一个词，答案当然混。
AI 不认识岗位头衔。它只看任务能不能被定义、执行、验收，失败后能不能继续修。
二、任务可评价性三指标
把可验证性原则从二分法（可验证 vs 不可验证）细化为三维连续光谱：
| 指标 | 含义 | 如何判断 | 极高值举例 | 极低值举例 |
|---|---|---|---|---|
| 验收速度 | 做完以后多久知道对错 | 结果反馈是秒级/天级/月级/年级？ | 代码编译测试（秒级） | 产品方向判断（季度/年级） |
| 纠错成本 | 错了以后能不能快速重来 | 失败后回滚/重做的代价有多大？ | 代码回滚（秒级） | 品牌战略失误（年级修复） |
| 责任位置 | 你是在执行标准，还是在制定标准 | 标准是别人定的还是你定的？ | 按接口 spec 写实现 | 定义什么叫"好产品" |
风险公式：前两个越高 + 第三个越低 = 你的工作越接近「代码世界」的结构 = AI 越容易练 = 风险越近。
三、五问自检
用五个问题审视你的工作（或团队中某个角色的工作），判断 AI 风险暴露程度：
问题 1：你的结果能否自动验收？
代码能跑测试，表格能对账，数据能校验，格式能检查，交付物能被明确打分——这类任务更容易被 AI 练习。
自检标尺：结果好坏是机器能判断的（自动验收）、还是人才能判断的（主观评价）、还是要等很久才知道的（延迟反馈）？
问题 2：任务能否拆成小闭环？
一个大目标如果能被拆成很多小任务，每个任务都有输入、输出和完成标准，就更容易被分配给 AI Worker 并行执行。
自检标尺：你的工作能不能被拆成 10 个独立子任务，每个子任务有明确的"完成"定义？
问题 3：上下文是否结构化？
文档、代码、数据、历史记录、接口、约束都清楚，AI 就更容易接手。如果上下文全在某个人脑子里，模型很难稳定工作——但这不代表安全，只代表组织还没把上下文整理出来。
自检标尺：如果你明天消失，接手的人（或 AI）能不能从现有文档和系统中获取足够上下文完成你的工作？
问题 4：失败能否低成本纠错？
失败以后能重跑、回滚、复盘、再试，AI 就会进步得更快。如果失败一次成本很高、反馈很慢，风险会晚一点暴露——但终会暴露。
自检标尺：你最近一次工作失败，从发现到修复/重来花了多久？成本有多大？
问题 5：你是否拥有标准设定和取舍责任？
这是唯一一个"是"意味着安全的问题。你是定义成功标准的人，还是按别人定义的标准执行的人？
自检标尺：如果结果不好，是你来判断"问题出在哪里、接下来怎么调整"，还是别人来判断？
综合判读
| 问题 1-4 答案 | 问题 5 答案 | 风险判断 |
|---|---|---|
| 大多是"是" | "否" | 高风险区——你的工作正在被改造成 AI 喜欢的形状 |
| 大多是"是" | "是" | 放大区——AI 会放大你的产出，你反而更值钱 |
| 大多是"否" | "否" | 暂缓区——AI 暂时进不来，但可能只是因为组织还没把上下文结构化 |
| 大多是"否" | "是" | 安全区——核心判断权 + 模糊反馈 = 短期内最不可替代 |
四、代码世界为什么是第一排
程序员先被 AI 改写工作方式，不是因为写代码低端——恰恰相反，软件工程复杂到一定程度，才给了 AI 足够多的可学习信号。代码世界像一座提前铺好的练习场：
- 有题目：明确的 issue、需求、bug report
- 有上下文：仓库、文件、提交历史、接口定义
- 有工具：编译器、类型检查、linter、测试框架
- 有错误提示：编译报错、测试失败、日志异常
- 有回滚：版本控制、分支管理
- 有复盘：code review、commit 历史、讨论记录
这个结构出现在哪里，AI 就在哪里有了练习场。运营里有像代码的部分，研究里有像代码的部分，设计里有像代码的部分，产品里也有像代码的部分。
所谓"像代码"，重点不在产出物是不是代码，而在任务结构：输入清楚，输出清楚，验收清楚，失败可以重跑，迭代成本很低。
五、产品经理不是安全，只是反馈更脏
PM 工作里有大量可验收执行层，都会被 AI 改造：
| PM 执行任务 | 为什么会被改造 |
|---|---|
| 按模板写 PRD | 有输入、输出、格式要求 |
| 整理用户访谈 | 模板化摘要 + 标签提取 |
| 生成竞品分析 | 结构化信息搜集 + 对比矩阵 |
| 数据初筛 | SQL/看板/趋势识别 |
| 写埋点方案 | 格式化 + 事件定义 |
| 生成原型说明 | 模板化 + 交互规则 |
PM 难被完整训练的部分是：把模糊目标变成可验证的问题、标准和取舍。
产品反馈信号的三个特征——晚（需要时间显现）、脏（混进太多变量）、主观（用户心理、审美、组织目标都会进入判断）——使得完整产品判断是 AI 最后才能稳定练的。
但外围执行层不受保护。
六、AI 提效的真实产物：工作密度压缩
AI 提效先改变的是尝试成本。尝试成本一降，高竞争环境不会把省出来的时间留给你，而是把更多尝试塞进同一天。
| 维度 | AI 之前 | AI 之后 |
|---|---|---|
| 方案数量 | 一个方案两天 | 一个下午三个方案 |
| Bug 处理 | 费劲修，先忍 | 模型快速定位，更多边角问题被拉进待办 |
| 实验成本 | 每个实验都要人力 | 实验成本低，判断成本上升 |
| 工作重心 | 手写实现 | 定义任务、组织上下文、审查结果、比较方案、承担验收 |
AI 未必先让人失业。它可能先让同一份工作变得更密。
七、价值迁移方向：从执行到反馈责任
被压缩的是纯执行，不是所有人的价值。
人的价值正在往两端迁移：
- 上游：定义任务、组织上下文、设定边界
- 下游：审查结果、设计验收、承担取舍
中间那段纯执行，会被越来越多的 AI Worker 接走。
下一阶段稀缺的不只是会写代码或懂产品的人，而是能管理 AI Worker 的人——能定义目标、分配任务、提供上下文、识别失败、更新标准、最后承担结果。
八、对 PM 工作的映射
| 本文框架 | PM 工作场景 |
|---|---|
| 验收速度 × 纠错成本 | 评估哪些 PM 任务优先引入 AI 协作——优先选反馈快、错了能重来的任务 |
| 责任位置 | PM 应主动把精力从执行层转向判断层——从写 PRD 转向定义成功标准 |
| 五问自检 | 用于审视团队中每个角色的任务结构，识别可验收执行层占比 |
| 工作密度压缩 | 团队 OKR/绩效设计需考虑：AI 工具越好用，工作不是变少而是变密 |
| 管理 AI Worker | PM 的核心竞争力从"写文档"转向"定义验收标准"——给 AI "做得好一点"它只能猜，给它明确的指标/边界/失败判据它才能进入真正的协作 |
九、决策原则金句
不要把职业名当护身符，也不要把某个工具当灾难本身。
AI 改造工作的顺序，更像是在寻找反馈最清楚的地方。
你是在写文档，还是在定义问题？你是在整理别人已经说清楚的东西，还是在把没人说清楚的东西变成判断标准？
程序员只是第一排。问题是：你的工作有没有正在被改造成 AI 喜欢的形状？
无法验收，就是 AI 协作里的 P0 问题。
来源
| # | 标题 | 来源 | 收录日期 |
|---|---|---|---|
| 1 | 别躲在岗位后：从姚顺宇判断看 AI 为什么不按职业排危险榜 | 张小珺/姚顺宇访谈转译（公众号文章） | 2026-05-20 |
原始访谈：张小珺 / Yao Shunyu 访谈《Let Me Go a Little Crazy! Training Models at Anthropic & Gemini》
关联方向
- AI 时代的人——黄仁勋/吴军视角的 AI 时代人性竞争力
- AI 产品经理能力模型——§4.6 从写文档到定义问题
- Agent 范式演进与 AI 未来——§3.1 任务可评价性三指标
- AI 研发效能与 SDLC 工程纪律——§1.2 工作密度压缩效应