AI正在如何改变 Anthropic 的工作方式

新闻

作者：微信文章
读完Anthropic的Blog《AI正在如何改变 Anthropic 的工作方式》，给人的感觉是比较系统地、量化地把“AI编程助手真正把工程师的工作变成了什么样”拆开给大家看清楚了。

对工程师日常工作的直观冲击

作为工程师视角，最直观的是：

绝大部分人每天用 AI 来写代码、 debug、看代码、补齐自己不熟的技术栈，而不是只用来写自己栈内负责的新功能。 现在 60% 的工作会用到 Claude，生产力平均 +50%，比一年前翻了 2~3 倍；还有 14% 的“重度用户”觉得自己效率翻倍以上。 但真正“完全丢给 AI 不用自己看”的，只占 0–20%，大部分仍然是“人机协作 + 严格 code review”，而不是“AI自己在干活”。 这和很多宣传的“自动写完一个系统”完全不一样，更像是：工程师从“码农”变成了“AI + 架构师 + 审核员”。

“好处很多，但有代价”的复杂感受

明显的爽点：

可以跨栈干活：后端去写前端、搞可视化、做 data pipeline，“人人 full‑stack”不再是口号。

很多原来“懒得做 / 不值时间做”的小工具、小重构、文档、测试，现在都能顺手做，团队整体“质量与打磨”提升。

迭代速度暴涨：过去要排会、排资源的东西，现在一个下午就能拉出 demo。

明显的代价：

手感在退化：大家担心自己“深度功底”在萎缩，尤其是 debug 大型系统、做底层设计的能力。

监督悖论：越依赖 AI，自己越少练习底层coding技能；但越缺这些技能，就越不具备审核 AI 结果的能力。

工作体验变化：有人怀念“戴耳机自己敲代码的心流”，不喜欢“整天在 prompt / review AI 输出”。

其中有一个说话挺有道理：AI 同时在拉高“你能做多少事”，也在侵蚀“你对 craft 的掌控感和成就感”。

如何“聪明地用 AI”

文章里工程师总结了很清晰的“任务分界线”，这部分对一线开发者非常有指导意义：适合交给 AI 的任务：

自己上下文不熟，但问题本身不复杂（例如：生疏的 Git / Linux 操作、陌生库的小脚本）。 结果容易验证，比如：小函数、脚本、配置、简单 SQL。 子问题边界清晰、对外部系统耦合少的模块。 质量要求不高的“扔完就忘”的调试脚本、实验代码。 自己觉得无聊、重复、抗拒开工的事情（文档、样板、重复重构）。 “写 prompt 比自己写还慢”的活，就自己干；否则就让 Claude 干。

自己要紧紧抓在手里的：

高层设计、架构、跨团队协同的决策。 需要强约束和安全性的模块，尤其是安全、底层基础设施类任务。 真正想深入掌握的核心技能：刻意选择不用 AI，多做几次“笨办法练习”。

这套标准，可以直接变成一线工程师的“AI 使用守则”：“凡是容易验证、边界清楚又很烦的事，交给 AI；凡是牵涉架构、安全、长期能力积累的事，坚持自己多做。”
技能与职业路径的重构

文章对“未来职业形态”的描述我觉得挺有共鸣的：

很多人已经觉得自己从“写代码的人”变成了“管理一群 AI agent 的 tech leader”，日常是同时开着好几个 AI Coding 工具会话，让它们并行尝试不同方案，然后做取舍和整合。 有人估计自己“70% 以上的时间是在审阅 / 修改 AI 写的代码，而不是从零写”。 对未来的普遍感受是： 短期乐观：工作更高效、更有成就感。 中长期迷茫甚至焦虑：会不会某天 AI 把这些也接管掉，自己角色被边缘化？

文章里有几种应对姿态值得工程师参考：

向上抽象：更多投入产品 sense、系统设计、跨角色协作，而不是把身份绑死在“写代码这件事”上。 强化“AI 监督能力”：学习如何拆问题、评估方案、识别 AI“聪明但危险”的解法，这比单纯会写代码更稀缺。 精准选择自己要保留的“手工能力”，定期“关掉 AI 练习一下”，避免完全丧失独立战斗力。

对工程师身份认同的冲击也写得很实在：有人把“20 多年的编程手艺”当成自豪感来源，如今突然发现自己变成 prompt engineer，既兴奋又有哀伤。AI 的确让人能做更多、更快，同时也在重塑技能曲线、职业路径、团队文化。真正重要的是：每个工程师、每个团队要有自觉——设计好“交给 AI 做什么、自己坚持做什么”，以及“如何在效率提升的同时，保住深度能力和人与人之间的连接”。

原文链接：https://www.anthropic.com/rese…ransforming-work-at-anthropic如果对你有启发，欢迎分享给更多朋友，也欢迎留言分享你的看法。