https://www.ycombinator.com/library/UN-boris-cherny-building-claude-code 给我看一下

回复 群友 716： 看了。这篇是 YC 对 Claude Code 创作者 Boris Cherny 的访谈。抓到的正文在后半段截断了，下面只讲已读到的部分；其中新模型能力、产品功能和案例属于受访者说法，不等于独立验证。 核心观点是：模型不断变强，Agent 的配套框架不能只加不减。以前帮助模型完成任务的规则，后来可能反而限制它。 一、Harness 要跟着模型更新，而不是一直堆补丁 Boris 说，他们每次换模型，都会重新检查系统提示词、工具和外围代码。 具体做法叫“消融”：先拿掉一些东西，看表现怎么变，再逐条加回来，确认哪些真的有用。 他在访谈里称，他们删除了超过 80% 的系统提示词。但他也明确纠正主持人：不是每次把整个代码库推倒重来。安全、权限、静态分析和界面等代码仍然有价值。 所以重点不是“提示词没用了”，而是“为旧模型缺陷写的提示词，不一定值得永久保留”。 二、先看到反复失败，再补规则 他不建议凭空猜模型需要什么指导，然后写一大份说明。 而是先让模型做真实任务，观察它在哪里反复栽跟头，再针对那个问题补说明。因为每多一条常驻指令，模型以后每次工作都要读它。 比如，Agent 总把业务逻辑放错模块，就补模块职责；如果它已经能稳定判断，就没必要继续保留一大段手把手教学。 这也适用于 CLAUDE.md 和 Skills。他提出定期删除重审的激进建议，我理解其有效内核是：定期验证必要性，而不是机械清空项目知识。 三、给目标、边界和验收条件，少规定每一步 他认为，过细的操作指令可能把模型锁在人的解题路径上。 相比“先改 A，再调用 B，然后必须用 C”，更合适的表达是： 要完成什么。 哪些东西不能动。 怎样才算完成。 注意，这不是“随便让它跑”。少控制实现路径，不等于取消权限边界和结果验收。 四、产品可能没有释放模型已有的能力 访谈用了一个概念：product overhang。 意思是，模型其实已经能做某件事，但产品还没有提供合适的工具和交互，让用户真正用上。 他用 Claude Code 的起源解释：当时产品主要围绕补全和聊天，但模型已经有能力写更完整的代码。提供终端和实际修改能力，才把这部分潜力释放出来。 所以做 Agent 产品，不只是追问“下一代模型什么时候更强”，也要问“当前模型的能力，是不是被我的工作流限制了”。 五、验收也要升级，但别把口述案例当保证 他提到用测试约束大型代码迁移，以及通过多 Agent 动态编排处理复杂任务。关键不是 Agent 数量多，而是拆分、执行、验证能够形成闭环。 他也认为，测试题如果已经被模型轻松做满，就需要增加更难、贴近实际失败的题目。 访谈中“无法再展示提示注入攻击”“整个运行时迁移只花十一天”等表述很强，需要另外核验。尤其“没测出攻击”不能直接理解成“已经绝对安全”。 和你前面看的两篇放一起： Agent SDK 那篇讲“怎么让 Agent 跑起来”。 长任务 harness 那篇讲“怎么接力、验证、不烂尾”。 这篇讲“模型升级后，怎么避免旧 harness 成为包袱”。 也正好回应群里刚才的讨论：不是不要 repo harness，而是保留项目事实、工具、权限和验收，持续淘汰已经没必要的行为补丁。