本文作者：meng shao（@shao__meng）。版权归作者所有，未经授权禁止转载。
How Anthropic Builds And How Engineering Will Change Soon | Thariq Shihipar - youtu.be/2Kch3tWMnw8
Claude Code 开发者 Thariq Shihipar @trq212 与 Ryan Peterman @ryanlpeterman 70 分钟深度对谈，围绕「Anthropic 内部如何用 AI 做工程」深入展开，来自一手前沿实践者的深度经验，大量内容是外部很少听到的内部细节。
核心命题：工程师的抽象层级必须上移
Thariq 给新人的第一条建议是一种工作姿态：把 Claude 当作思考伙伴，遇到任何事先问“Claude 能不能做？不能的话为什么？” 更进一步——不要只构建产品，要构建“构建产品的系统”。
他解释了 Anthropic 内外认知落差的根源：Anthropic 把“花一天时间尝试让 Claude 自主完成某件事、哪怕失败”视为工作本身，失败本身就是有价值的反馈；而在普通公司，自动化是有风险的投资，老板不会容忍你调了几天工具却没产出。这是文化差异，不是能力差异。
一个惊人的细节：他谈到大型企业客户里，有人六个月没亲手写过一行代码；Anthropic 内部工程师“基本不再待在 IDE 里”。
“知识工作皆可代码化”——被低估的用法
他认为外部人做得最少的一件事是：用 Claude Code 做知识工作。技术人和非技术人做知识工作的效率差距正在拉大，因为大多数知识工作可还原为“代码化的步骤”——他自己用 Python 脚本而非 Excel 做个人记账，用 ffmpeg 做视频剪辑。
Harness 悖论：模型越强，Harness 越复杂
直觉认为模型变强后 harness 会变得不重要，他观察到恰恰相反：模型能跑数小时后，你需要沙箱、权限分类器（auto mode）、以及让它有效“汇报”数小时工作成果的方式（artifacts 本质上是一种提示工程）。结论：harness 工程是科学与艺术的混合，而且越来越难自己“vibe code”出来。
关于自主性的清醒判断
- “给 Claude 一个 ticket 就别来烦我”的世界离我们多远？ 取决于 ticket 写得多好。如果 ticket 已经是一份完美的软件规格说明，Claude 今天就能做到。难点在于：大多数 ticket 的本质是人们还没想清楚自己要什么。以前靠边写代码边想清楚，现在需要新的方法去弄清未知项。
- 典型失败模式：一句話的需求、零上下文，做完不满意，然后无限迭代。正确做法是先快速搞清楚自己真正想要什么。
- 实习生的变化：不再“写 React 代码”，去解决没人做过的新问题（比如如何评估数百万用户身上的模型行为）——旧经验的相关性在下降，新人的新鲜视角反而更值钱。
提示工程是不是持久技能？——是，但重新定义
这是全场最有信息量的部分之一：
- 提示不仅仅是那段文字，是你在此之前注入上下文的一切（skills、数据、验证装置）。Anthropic 工程师写出看似简单的 prompt，是因为大量工作已经沉淀在 harness 里。
- 他们删掉了 Claude Code 系统提示词的 80%，其中一个反直觉发现：示例（examples）现在大多是负面的——模型足够有想象力、能贴住你的意图，示例反而形成束缚。这在几年前是不可想象的。
- 模型各有怪癖，需要不断“学习-忘却”，但**你积累的元技能是“快速学会用一个新模型”**。他从 GPT-2 时代（让它稳定输出 JSON 都难）一路用过来，深有体会。
- 实用技巧：**给模型“使用算力的许可”**。模型默认按普通用户偏好行事——快速回复、不烧算力。所以要明确说“这是个难题，可以用 subagents/workflows”，或“我要睡了，设好目标自己跑”。他顺带澄清了病毒式传播的“believe in yourself”玄学——Jared 黎曼猜想帖子的本质其实是“允许模型花算力”。
品味（Taste）成为稀缺资源
对于前端这类主观领域，方法给得很具体：给带数据的参考（HTML 文件优于截图、Figma 文件优于位图），用 HTML 做探索性 mockup，再开新会话照着实现。
但深层观点更尖锐：高品味的用户是获得好输出的前提。黎曼猜想那次，Jared 能 prompt，但要靠世界顶级数学家 Lev 才能验证对错——“也许 Claude 真解出了某个物理问题，但你知识不够，根本不知道”。知道“什么时候够好了、什么时候该逼它更进一步”本身就是领域专长（他举了陶哲轩“别给我半成品定理，直接做完整条”的例子）。
写作与信任文化
他的一条拇指法则非常精彩：“如果我愿意给别人看我的 prompt，我就敢发这份产出。” 由此推出一套清晰的规范——
- 收集上下文类写作（如 1:1 前让 Claude 汇总所有 Slack/PR 动态）：完全可以，没人会怪你；
- 数据 readout：可以，但要有人工校验和小的手写痕迹，证明你理解了；
- ** pitching 新想法、内部 essay：必须人写**。Anthropic 内部用 Claude 写 essay 是被看不起的，因为“每个词都应承载你的意图”。写作本身就是思考。
- 他的实践：发大 PR 时附上一个 artifact，包含发给 Claude 的每一条 prompt，包括失败的尝试——既展示工作量，也消除“这一万行你到底读没读”的质疑。
代码维护的重定义
- 命名、代码风格等的重要性在下降；验证能力的重要性在暴涨——他建议测试代码要比以往多两个数量级（约 100 倍），用生产数据现做 fixtures、前端用 storybook；给 Claude Code 仓库提 PR 会收到模型“使用该功能并测试”的录制回放。
- 每个代码库都将面对一个时刻：**“要不要让模型整个重写？”**（他的激进例子：没有理由所有软件不跑在浏览器的 WebAssembly 里）。
- 对技术债：朋友的策略是“留着，下一代 Fable 会一键重构”，他认为不算全错——按 1-2 个月的短周期交付价值，6-12 个月后的项目可以等下一个模型。
几个即将扩散到全行业的转变
- Claude Code 负责代码实现，“Claude Tag”负责软件开发生命周期的其余一切——收集反馈、code review、盯着 CI/CD、处理 incident，把 SDLC 的每一环变成例行 loop；
- 生成式界面（artifacts）：Claude 为当前任务即时生成一个交互式 web 应用作为汇报和协作界面，纯文本进出不再够用；
- loop engineering：不再直接 prompt，要搭建“去 prompt Claude 的系统”，让软件工程在某些场景真正自治运行——前提是验证、skills、数据源都搭好，且像招人一样评估“这份自动化值不值”。
“编码已被解决”到底是什么意思
回应 Boris 的名言，他给出迄今最清晰的诠释：“编码被解决”不是说工作变少了，应该是编码不再是那种“大概率失败、极少数人才能做好”的稀有活动。以前给你的车行找人写软件几乎必然翻车（没人想骗你，是软件本身太难）， bug 可能卡一天也可能卡两周。现在编程可以用来做从没做过的事。
但他明确坚持：技术能力本身依然极其重要——懂缓存、内存分配、后端服务这些概念，就像最好的 CEO 都是技术出身（Zuckerberg、Musk 早已不写代码但懂系统）。引 Karpathy 的话：“学习应该感觉像在费力”——让 Claude 解释一遍然后点头，不是真的学会了。只有成为优秀的软件工程师，你才判断得出自己是否做出了优秀的软件。
Ryan 补充了一个时代情绪的最佳注脚：以前代码一次跑通会震惊“怎么会能用”，现在一次跑不通才震惊“怎么回事”。
给个人的建议：扩大“幸运表面积”
他给职业建议时罕见地不留情面：“统计上，我劝过的人几乎没人照做；而照做的人，要么在做自己热爱的工作，要么在开自己的公司。” 方法朴素：选一个有趣的项目、拼命做、发布、写出来分享。不要指望让 Claude 替你运营 X 账号——人们要的是真实的高质量内容。他自己的路径就是范例：在 Goodfire 做可解释性可视化，一条 500 赞的帖子带来 DM，最终引荐进 Anthropic。
给年轻自己的建议是“两头狼”的平衡：既要更早地相信自己能立刻做出惊人的事、更大胆地分享原创工作；也要更充分地利用前辈的经验，避免重新踩坑——他自己偏向于前者不够、后者也没做足。
