StreamSparkAI

核心概览

这期对话最重要的结论是：在 Boris Cherny 当前的工作流和代码类型里，“写代码”这件事已经大体被 AI 代理接管，人类角色正从“逐行实现”转向“定义目标、校验结果、推动方向”。他自述从 2025 年 11 月起不再手写代码，每天并行跑多个 agent，持续高频提交；与此同时，人类审阅与安全检查并没有消失，反而被放在更关键的位置。

整场讨论不只是“效率提升”，而是完整回答了四个问题：
1) 这一年到底发生了什么；
2) 为什么会发生（模型能力 + 产品方法）；
3) 会影响哪些岗位与组织；
4) 个人和团队现在该怎么做。

Boris 的总体态度可以概括为：对技术前景非常乐观，但对过渡期冲击保持清醒。他认为普及会很快，阵痛也会真实存在；而 Anthropic 的路径是“编码 → 工具使用 → 计算机使用”，并在真实世界部署中持续校正安全边界。

一、发生了什么：一年内从“终端小实验”到开发范式变化

1) Claude Code 的起点很小，但增长曲线非常陡

Boris 回顾，Claude Code 最初只是自己在终端里做的快速原型（早期是 CLI 形态），并非一开始就被当成“平台级产品”。他把内部 demo 发出来时，最初反馈很冷，甚至只有很少互动。
真正的转折来自两件事：
- 模型能力持续跃升（尤其是更强模型发布后）；
- 产品形态逐步从终端扩展到桌面、网页、移动端、Slack 等，更贴近不同用户习惯。

他强调，早期对外发布后也不是立刻爆发，而是经历了数月认知爬坡，用户才慢慢明白这类 agent 工具的真正用法。

2) 个人工作方式已经重构

Boris 给出了一组非常具体的个人实践信号：
- 2025 年早期，AI 只写他一部分代码；
- 到 2025 年 11 月后，他进入“100% 由 Claude Code 产出代码”的状态；
- 每天仍保持很高交付节奏，并且会并行运行多个 agent；
- 他会看代码，不是完全放手，尤其在生产场景要做人类把关。

这也说明他的“coding is largely solved”有明确边界：不是说全行业已经彻底自动化，而是说在他当前高频工程任务里，编码已不再是主要瓶颈。

3) 工程岗位内容已经变化，但工程责任没有消失

他所在团队里，Claude 会先参与 100% PR 的自动审阅，但后面仍有人工审阅链路。
这意味着“AI 写得更多”并不等于“人类退出流程”，而是人类从“手工输入者”转向“系统监督者、质量负责人、方向制定者”。

二、为什么会发生：模型能力跃迁 + 产品方法论命中

1) Anthropic 的长期路线：编码 → 工具使用 → 计算机使用

Boris 反复强调，这不是临时战术，而是长期路线：
- 先把模型在编码上做强；
- 再让模型能稳定调用工具；
- 再进入更广泛的计算机操作场景。

这条路线既是能力路线，也是安全研究路线：能力越强，越需要在真实使用中验证对齐效果。

2) Claude Code 的产品原则：最小约束、快速迭代、用户反馈闭环

他总结了几个关键方法：

• 最小流程包裹（而不是复杂编排）
  不把模型锁进严格“步骤 1/2/3”的固定流程，而是给目标和工具，让模型自主规划执行。
• 小团队推进，逼出自动化
  资源不过度堆人，迫使团队把重复工作交给 agent。
• 能今天发就今天发
  快速上线，不等“完美版”，让真实用户反馈决定下一步。
• 反馈闭环速度极快
  早期他会在用户反馈出现后几分钟内修复问题，这种“被听见”的体验反过来增强用户反馈意愿。

3) “潜在需求”是最关键产品信号

他把 latent demand（潜在需求）分成两层：

• 传统层：看用户如何“绕路”用产品
  当用户用非设计方式反复完成某类任务，说明需求真实存在，值得产品化。
• AI 时代的新层：看模型“想怎么做”
  不只是观察用户，也观察模型在能力边界内的自然行为，然后顺势设计产品，而不是强行让模型按旧软件逻辑工作。

4) 关键案例复盘（问题 → AI 介入 → 结果 → 抽象）

• 内存泄漏排查
  传统做法是工程师手动抓 heap snapshot、跑调试工具慢慢找。团队里更“agent-first”的工程师直接让 Claude 全流程处理：抓快照、临时写分析工具、定位问题、提交修复，速度更快。
  抽象：心智要跟上模型代际变化，别用旧时代流程限制新能力。

• CoWork 10 天成型
  团队观察到大量非工程用户在终端“硬用”Claude Code做办公任务，于是把同一 agent 能力搬到更友好的入口，10 天做出可用版本，并配上安全边界（如隔离执行环境）后以研究预览发布。
  抽象：需求不是“拍脑袋定义”，而是从真实使用行为里长出来。

• 日常事务自动化
  包括处理停车罚单、邮件处理、跨表格同步、Slack 提醒未填周报等。
  抽象：agent 价值不只在“写代码”，而在“把琐碎可计算流程自动跑完”。

• 非技术用户的“异常用法”
  用户曾用 Claude Code 去做种植决策、基因数据分析、损坏硬盘照片恢复、医学影像相关分析等非典型场景。
  抽象：当用户愿意忍受高摩擦入口（比如终端）也要完成任务时，说明产品应当前移到更低门槛形态。

5) 先放量实验，再做成本优化

Boris 给管理者的建议很明确：
- 初期别急着“省 token”，先让工程师大规模探索，验证价值；
- 当某个模式跑通并规模化后，再切模型层级、做成本优化。
他的判断是：很多早期实验的 token 成本，相比人力成本并不高，过早优化常常会扼杀有效创新。

三、会影响什么：岗位边界、组织分工与社会讨论

1) 岗位会先“重叠”，再“重命名”

Boris 观察到，工程、产品、设计之间已经出现明显重叠。对话语境中他提到的“到今年年底”（即 2025 年底）预测是：
- 一些组织里“软件工程师”头衔会被弱化；
- 可能出现更统一的“builder”角色；
- 或者“人人都是产品经理，同时人人都能编码”的形态。

这不是说专业能力消失，而是分工边界会被重画。

2) 下一个被深度影响的，不止工程

他认为最先被波及的是工程相邻岗位：产品、设计、数据等，随后会扩展到几乎所有“在电脑上完成的工作”。
关键分界不再是“会不会聊天”，而是“能不能调用工具、能不能真实执行任务”。

3) 关于“要不要学编程”

他的回答有时间分层：
- 现在：仍建议理解底层，这能提高对 agent 的驾驭能力；
- 1-2 年后：底层门槛的重要性可能明显下降。

他用印刷机类比：技术会把原本稀缺能力普及给更大人群，但中间一定伴随职业结构调整和身份焦虑。

4) 就业与体验：乐观与不确定并存

他个人与不少用户反馈是“工作更有趣了”，因为琐碎劳动减少。
但他也明确承认：过渡期会有痛感，且社会层面的就业、教育、政策配套必须跟上，不能只交给公司单方决定。

四、怎么应对：团队与个人的行动框架

A. 团队侧（管理与产品）

1. 用小团队做高密度实验，避免流程过重。
2. 初期给足 token 预算，先找出真价值点。
3. 发布节奏前置，用真实反馈驱动方向。
4. 围绕潜在需求迭代，而不是闭门做“理想流程”。
5. 面向“六个月后的模型能力”设计产品，而不是只贴合今天能力。
6. 安全上采用三层并行：模型内部研究、实验评测、真实世界观测。
7. 推动行业“race to the top”（向上竞争），例如开源安全沙箱能力，降低安全实践门槛。

B. 个人侧（工作方式）

1. 不回避 AI 工具，持续高频实操。
2. 尽量成为“AI 原生 + 跨职能通才”：懂工程，也懂产品、设计、业务与用户。
3. 先规划后执行（Plan 模式），减少返工。
4. 善用并行 agent，提高吞吐。
5. 根据任务选入口：终端、桌面、移动端、协作工具并行使用。
6. 保留人类审阅与关键决策，不把责任外包给模型。

底层工作原则（补充重点）：用常识（Use common sense）

这是 Boris 在结尾给出的最高频、最核心建议。
他认为很多失败不是能力不够，而是机械执行流程、失去判断力：
- 只因流程要求而做事，不问“这件事是否合理”；
- 只因惯性推进项目，不问“这个方向是否真有价值”；
- 面对明显异味信号仍继续投入。

因此，他把“用常识”与“第一性原理思考”放在一起：
- 不盲从流程；
- 不迷信工具；
- 以目标和现实反馈校正行动。

这也与前面的产品方法形成闭环：最小约束、快速试错、真实反馈、持续校正。

定锚金句（精选）

• “I have not edited a single line by hand since November.”
• “Coding is largely solved.”（限定在其当前工作流与任务类型）
• “The product is the model.”（产品设计要顺着模型能力演进）
• “Build for the model six months out.”
• “Use common sense.”

口径说明与不确定项（集中标注）

1. 关于 GitHub 提交占比：正文采用主持人引用外部报告的4%作为主口径；转录中出现的“44%”更可能是识别噪声。
2. 关于估值、收入等商业数字：多由主持人口播，嘉宾未逐条核验，不能作为确定事实。
3. “到今年年底”等表述均按对话语境理解为2025 年。
4. 生产率、token 消耗、运行时长等多为嘉宾实践观察或经验值，不等同于统一行业统计。

结论回看

这期最有价值的，不是“AI 会不会替代写代码”的口号，而是一套已经在高强度场景里跑出来的方法：
以最小约束释放模型能力，以快速反馈驱动产品演进，以安全分层保障落地，再用常识与第一性原理持续校正。

在这套框架下，“程序员是否消失”不是重点；重点是“谁能更快从执行者升级为建造者”，以及组织是否能把这种升级变成可持续能力。