GitHub Copilot、Cursor、Claude Code 这类工具，已经不满足于补全几行代码。新一代编程智能体可以读取代码库、修改多个文件、调用终端、运行测试。
程序员担心岗位和技能贬值，经理不知道该不该调整招聘与考核，公司所有者也说不准投入最终会变成利润，还是变成一笔更贵的软件账单。
一篇题为《Anger, Anxiety and Agency》的博客抓住了其中一个容易被忽略的问题：行业里的愤怒正在增加，但很多怒气落在了无权决定方向的人身上。
同事推荐了一款 AI 工具，不代表他决定了裁员计划。直属经理要求团队试用，也未必掌握公司的长期安排。愤怒可以发出警报，却很容易把责任对象制造错。
所有人都心里没底，但手里的筹码不同
AI 带来的情绪不止一种。
焦虑承认“我不知道接下来会怎样”。好奇愿意继续观察。兴奋看见了新的可能。愤怒则更进一步：它通常需要找到一个应该负责的人。
这个区别很重要。前几种情绪可以暂时和不确定性共处，愤怒却会催促人立刻归因。办公室里最容易接住这团火的，往往是坐得最近的人，而不是权力最大的人。
| 角色 | 正在失去的确定性 | 能采取的行动 | 现实限制 |
|---|---|---|---|
| 程序员 | 技能价值、岗位数量、代码评价标准 | 试用工具、记录收益与返工、保护代码和数据 | 很难决定采购、裁员与收益分配 |
| 技术经理 | 招聘计划、交付节奏、团队能力边界 | 设定试用范围、统一工具链、调整评审流程 | 既要交付，也未必知道高层下一步怎么走 |
| 公司所有者 | 投资回报、竞争位置、组织规模 | 决定预算、产品路线和人员安排 | 拥有行动权，不等于拥有预见能力 |
原文作者的位置也很矛盾。他既是技术实践者，也是公司所有者，却无法确定编程职业会走向哪里，更不能保证 AI 投入一定产生商业回报。
这种坦白很重要。老板可以买工具、改流程、停项目，但采购权不是水晶球。把管理层所有犹疑都解释成恶意操控，既不准确，也会遮住真正该追问的账。
AI 收益也未必进入公司利润表。一个开发者借助智能体，更快做完个人副项目，这同样是生产率收益。公司可能一分钱都拿不到。
反过来，员工节省下来的时间，也可能被换算成更多任务、更紧工期，甚至成为削减岗位的理由。工具带来的效率相同，收益归属却可以完全不同。
怒气找错对象，利益账就被藏起来了
“天下熙熙，皆为利来。”AI 争议最终仍要回到利益和权力，只谈情绪管理远远不够。
几笔账必须摆上桌面：
- **生产率归谁.** 节省的时间会变成员工的自主空间、公司的利润，还是更高的工作量？
- **成本由谁收走.** 模型订阅费、API 费用和云计算支出，会提高 AI 实验室与平台方的议价能力；企业是否真正获利，目前并不确定。
- **数据由谁控制.** 私有代码能否上传、提示词是否留存、模型输出出了问题谁负责，都会落到合同与团队制度里。
- **就业代价由谁承担.** 岗位是否减少还看不清，但初级任务、招聘门槛和绩效预期已经成为技术团队必须重新讨论的问题。
- **社会与气候成本如何结算.** 算力需要能源、基础设施和资本。使用者看到的是几秒钟的回答，账单却可能散落在电力、环境和公共资源中。
欧洲公司还多一层焦虑。许多常用模型、云服务和开发工具掌握在美国平台手中。若核心工作流长期依赖外部 API，数据驻留、价格变化、服务中断和政策管辖就会变成经营约束。
这不代表欧洲团队应该拒绝 AI。闭门不用，只会失去判断能力。但“能调用模型”和“掌握技术主动权”相距很远，合同到期、接口涨价或合规要求变化时，这段距离才会显出来。
十九世纪的卢德运动经常被简化成“工人砸机器”。实际冲突还涉及工资、劳动条件和机器由谁控制。今天与当时并不完全一样，但重复出现的结构很熟悉：技术提高了产出，分配规则却由少数人制定。
所以，抵抗并不天然落后。拒绝把私有代码交给未经审查的平台，反对用粗糙的 AI 指标考核员工，要求公司解释节省成本后的人员安排，都有正当性。
问题出在目标失焦。把怒气砸向试用工具的同事，只会让真正决定预算、数据规则和裁员方案的人轻松退到背景里。
好奇是一种侦察，不是服从
我赞成原文对“好奇和试验”的强调，但要补上一句：试验的目的不是证明 AI 必须进入所有工作，而是获取谈判和决策所需的信息。
不了解工具的人，很难判断它到底替代了什么，也很难指出它增加了哪些审核、安全和维护成本。空泛抵制会失去说服力，无条件拥抱则会替平台免费完成组织改造。
如果你正在一线写代码，接下来最现实的动作不是预测五年后的职业，而是记录眼前的变化：
| 身份 | 现在可以做什么 | 需要盯住什么 |
|---|---|---|
| 程序员 | 记录工具节省的时间、错误率、返工量；上传代码前确认公司政策；保留系统设计、调试和代码审查能力 | 节省的时间是否变成更多任务；绩效标准是否突然提高；私有数据去了哪里 |
| 技术经理或创业者 | 用小范围项目试验；明确允许使用的工具和数据；同时统计速度、质量、安全与维护成本 | 效率收益如何分配；工具费用是否持续上升；团队是否因依赖模型而丢失关键能力 |
程序员还要留意一个很具体的变化：公司可能先减少初级、重复性任务，却没有同步建立新的成长路径。新人若接触不到调试、重构和故障处理，只负责验收模型输出，短期看效率更高，长期可能削弱整个团队的技术梯队。
管理者也有现实难处。完全禁止工具，团队可能私下使用；全面开放，又会带来数据、安全和责任问题。靠谱的做法不是要求员工“积极拥抱”，而是把哪些代码能上传、哪些输出必须人工复核、出了问题谁负责写清楚。
保持好奇，是为了看见收益落在哪里，成本被推给了谁。看清之后，可以采用，可以限制，也可以抵抗。
没有调查，愤怒只能在办公室里寻找最近的靶子；有了证据，矛头才可能指向真正制定规则的人。