Boris Cherny 最近三个月发帖与主要观点整理

1. 工作单位正在从 Prompt 变成 Loop

单次提示不再是 Agent 工作的主要单位。更成熟的结构是 Loop Engineering：

1. Agent 获取目标和上下文。
2. Agent 执行任务。
3. 测试、构建、Lint、浏览器或模拟器验证结果。
4. Agent 根据验证结果修正错误。
5. 达到停止条件后提交结果。

人的工作由逐条下指令，转向设计目标、循环、验证器和停止条件。

Boris 给出的长期运行建议包括：

• 使用 Auto Mode，避免 Agent 不断等待权限确认。
• 使用 Dynamic Workflows，让 Claude 编排数百或数千个 Agent。
• 使用 /goal 或 /loop，让任务持续到真正完成。
• 在云端运行，使工作不依赖本地电脑持续开启。
• 为 Agent 提供端到端自验证环境。

2. Self-verification 是自主性的基础

Boris 多次强调，自验证是提升 Agent 结果质量和运行时长的关键。

不同任务需要不同验证方式：

• 后端：启动完整服务、执行测试、检查日志和接口结果。
• 前端：使用真实浏览器访问页面，检查交互和视觉结果。
• 移动端：使用 iOS 或 Android 模拟器及相关 MCP。
• 代码迁移：编译、类型检查、回归测试和性能比较。
• 基础设施：部署检查、健康检查、监控指标和回滚条件。

因此，Agent 的有效能力不只取决于模型智力，还取决于它是否拥有可靠的反馈信号。

3. 领域知识应该成为基础设施

Boris 认为，优秀工程师过去就会通过测试、Lint、类型系统、CI 和开发工具，把经验转成自动化。Agent 时代进一步扩大了可以编码的知识范围：

• 代码注释
• CLAUDE.md
• REVIEW.md
• Skills
• 项目文档
• 记忆文件
• 自动代码审查规则
• 测试和 CI

如果一位新工程师或设计师提交 PR 后，才因为不知道团队使用的框架或架构规范而被拒绝，这说明团队的隐性知识没有被充分编码。

他的目标是：Agent 在没有提示者额外解释的情况下，也能获得足够的领域知识，在代码库里正确工作。

4. AI 基础设施也会产生配置债务

Skills、MCP、Hooks 和 CLAUDE.md 不会天然保持简洁。随着时间推移，它们可能出现：

• 无人使用的 Skills 和插件
• 重复或冲突的规则
• 过大的根目录 CLAUDE.md
• 每次任务都会触发的慢 Hooks
• 过度授权或反复请求授权的命令
• 不必要的上下文和 token 消耗

/checkup 所代表的不是一个普通清理命令，而是一种更重要的工程原则：Agent Harness 也需要持续维护、可观测和重构。

5. Coding 越来越容易，但 Engineering 尚未解决

Boris 明确指出，编码只是工程的一部分。工程工作还包括：

• 调试复杂问题
• 运行和维护服务
• 扩展基础设施
• 决定优化目标
• 规划硬件与容量
• 理解用户
• 进行产品规划
• 权衡成本、可靠性和安全性

因此，“Coding is solved”只能理解为：在部分常见技术栈和明确任务上，模型已经可以完成绝大多数代码生成。它不能被解释为软件工程、产品开发或组织协作已经被解决。

1. Prototyper：原型探索者

大量生成新方向，允许多数想法最终不发布。其价值来自探索范围和试错速度，而不是每个原型都进入生产环境。

2. Builder：构建者

把可行原型迅速变成生产级产品或基础设施，处理真实用户、可靠性、性能和长期维护问题。

3. Sweeper：清理者

简化代码和 UI、删除无效功能、降低系统复杂度、优化性能。AI 降低了增加功能的成本，因此删除、收敛和简化反而会成为更稀缺的能力。

4. Grower：增长者

围绕真实使用数据和用户反馈，持续改善产品市场匹配、留存和使用深度。

5. Maintainer：维护者

让成熟系统保持安全、可靠、高效和可扩展，并控制随规模增长出现的风险和成本。

不同产品阶段的组合

值得注意的是，Sweeper 在三个阶段都不可缺少。AI 大幅降低“增加功能”的成本，却不会自动降低系统熵。

各阶段的升级条件

从阶段 0 到阶段 1：

• 高管和采购方达成一致
• 建立安全使用框架
• 解决部署、身份认证和数据治理问题

从阶段 1 到阶段 2：

• 同时运行多个 Agent
• 建立可信的测试、构建、Lint 和端到端验证循环
• 使用 Auto Mode 减少阻塞
• 自动化代码审查和安全审查

从阶段 2 到阶段 3：

• 让 Agent 读取代码、Wiki、讨论记录和组织知识
• 使用独立工作区避免多个 Agent 冲突
• 把任务拆成 Loops 和 Routines
• 允许 Claude 启动和管理其他 Claude

从阶段 3 到阶段 4：

• 针对迁移、模糊测试、功能开发和反馈处理建立领域工作流
• 通过 SDK 程序化地创建和调度 Agent
• 建立自动成本控制和模型选择机制
• 按任务类型配置不同护栏

这套模型最重要的判断是：不要直接追求 Agent 数量。没有可靠验证闭环就扩张 Agent 数量，只会放大返工、成本和审查压力。

1. 一个人获得 10 倍提升，不等于组织完成了 AI 转型

组织经常出现少数高水平用户大幅提升产出，但其他成员和流程没有变化的情况。此时，个人已经进入并行 Agent 阶段，组织却仍停留在受限或单 Agent 辅助阶段。

真正的 组织转型 需要同步改变：

• 权限和安全模型
• 代码审查方式
• 任务分配机制
• 组织知识的记录方式
• 成本和质量指标
• 团队激励和职位设计

2. 应该重构工作流，而不是只加速旧流程

Boris 对 Salesforce 案例的总结是：获得最大收益的团队，不是单纯让原来的每一步快一点，而是重新思考：

• 哪些步骤可以直接删除？
• 哪些交接可以消失？
• 哪些任务可以由 Agent 端到端拥有？
• 哪些质量标准可以嵌入工作流？

这比“给每位员工发一个 AI 助手”更接近真正的 AI 原生转型。

3. Agent 时代需要分布式执行和集中式护栏

Boris 倾向于让团队围绕任务自组织，减少中央协调者成为瓶颈。但这并不意味着取消治理。更合理的结构是：

• 目标、预算、安全边界和质量标准由组织统一定义。
• 任务拆解、执行方式和 Agent 编排由团队分布式完成。
• 高风险操作、生产部署和权限扩展保留明确审查。

值得认可的部分

1. 把问题从 Prompt 提升到了系统层。 生产力来自上下文、验证、自动化、工具和组织流程，而不仅是提示词技巧。
2. 强调验证而不是盲目信任。 这是长期运行 Agent 能够进入生产环境的关键。
3. 看到了新的瓶颈。 当代码生成速度提高后，代码审查、决策和组织知识会成为限制因素。
4. 没有把 Coding 和 Engineering 混为一谈。 这比简单宣称“程序员会消失”更加准确。
5. 将团队角色与产品生命周期联系起来。 五种原型比传统职位名称更能解释 AI 原生团队如何分工。

需要保留判断的部分

1. Boris 是 Claude Code 的负责人，其内容同时承担产品推广功能。
2. “10 倍产出”和“数百个 Agent”主要来自前沿团队、高预算和强模型环境，不能直接外推到普通企业。
3. Salesforce 的 231 天变 13 天很有价值，但仍是特定迁移案例，不代表所有研发工作都能提升同样倍数。
4. Agent 可以大量生成代码，但人工审查能力和组织决策速度未必同步增长。
5. 更多 Skills、规则和自动化也会制造新的配置债务和错误传播路径。
6. 自动模式和主动 Agent 扩大了权限面，需要额外考虑数据泄露、Prompt Injection、误操作和成本失控。

我的综合判断

Agent 并没有消灭复杂性，而是改变了复杂性的位置：

以前复杂性主要在写代码；以后复杂性更多在定义目标、准备上下文、设计验证、审查结果、控制成本和协调组织。

“Coding is solved”不能理解成“Software Engineering is solved”。更准确的说法是：

在部分常见技术栈和边界明确的任务中，代码生成正在逐渐成为低成本能力，而工程判断、产品选择和组织执行成为新的稀缺资源。

建议跟踪的指标

• 从任务提出到交付的周期
• Agent 首次交付通过率
• 无人工干预完成的任务比例
• 每个 PR 或交付物的人工审查时间
• 自动测试和安全检查覆盖率
• 线上缺陷和事故数量
• 每个有效交付物的 token 成本
• 因上下文缺失被退回的任务比例
• 被转化为规则、Skill 或测试的重复问题数量