问题不能停在谁会写代码

Anthropic 那份 Claude Code 报告最容易被读成一句热闹判断：一大半会话都在写代码，业务专家也能靠 Agent 编程。

这句话没错，但它太浅。真正值得追的是另一个问题：如果一个经验丰富的软件工程师，和一个业务转型者，都已经熟练使用 Agent，谁的综合效率更高？

我的判断是：看任务类型。

如果任务是一次性业务产物，比如做一个分析脚本、整理一份报告、改一个表单流程、生成一个部门自动化工具，业务专家很可能更快。因为他知道什么结果有用，哪些字段不能错，哪些表达在业务里算外行话。

如果任务要长期运行，要接入系统，要处理失败，要多人维护，要从一次脚本沉淀成可复用能力，软件工程师通常更强。因为他知道代码写出来只是开头。后面还有测试、部署、回滚、监控、审计、迁移，还要被后来的人读懂。

Agent 把“写出代码”这件事变便宜了。它没有把“知道要写什么”和“知道怎么让它长期可用”变便宜。

业务专家的优势：目标函数清楚

业务专家最大的强项，是知道什么叫“做对”。这件事比术语更值钱。

一个法务知道合同里哪种措辞会埋雷。一个财务知道对账差异怎么分类。一个供应链负责人知道库存异常不是看一个数，而是看时点、批次、承诺交期和供应商历史。一个医生知道病历摘要里哪些信息不能省，哪些表达会误导后续判断。

这些东西很难从代码里长出来。Agent 可以生成实现，但它需要目标函数。业务专家手里握着这个目标函数。

所以业务专家熟练使用 Agent 后，优势很明显：

  • 能快速判断输出有没有业务意义。
  • 能提出真实边界条件，避免需求停在教材式表述。
  • 能发现“看起来对但不能用”的结果。
  • 能把组织里的隐性规则直接喂给 Agent。
  • 能用业务语言验收，不会只盯着程序是否跑通。

他的弱点也同样明显。

很多业务专家会把 Agent 当成一个聪明实习生，很少把它当成需要约束的执行系统。他会不断追加需求，让 Agent 修改，直到眼前结果看起来可用。但这个过程常常留下隐患：没有测试，没有版本，没有权限边界，没有数据口径，没有失败处理，没有维护责任。

他能让 Agent 很快做出一个“能用”的东西，但不一定知道这个东西什么时候开始变危险。

软件工程师的优势：知道复杂性会在哪里回来

经验丰富的软件工程师不一定懂业务，但他懂复杂性。

他知道一个需求不能直接变成代码。中间要经过输入输出、状态、边界、错误、权限、持久化、并发、可观测性、测试和部署。Agent 生成代码越快，这套工程判断越值钱。

一个业务专家可能会说：帮我做一个销售线索评分工具。

软件工程师会本能地拆：

  • 输入数据从哪里来，字段是否稳定？
  • 评分规则是硬规则、模型判断，还是两者混合？
  • 输出是建议、排序，还是自动触发动作？
  • 误判成本是什么？
  • 谁能改规则？
  • 结果是否需要解释？
  • 历史评分是否要保留？
  • 新版本规则上线后，旧结果怎么处理？

这些问题听起来慢，其实是在省后面的灾难。

软件工程师熟练使用 Agent 后，优势也很清楚：

  • 更会把模糊目标拆成可执行步骤。
  • 更会设计局部模型、状态机和接口。
  • 更会让 Agent 先写测试、再改实现。
  • 更会读错误日志，判断问题到底来自模型、输入、状态还是边界。
  • 更会把一次成功变成脚手架、模板、脚本、CI、文档和检查器。

他的弱点是容易做错方向。

不懂业务时，工程师会把问题工程化得很漂亮，但目标函数可能是错的。他会优化性能，却忽略业务口径。他会设计完备状态机，却漏掉真实流程里的审批人。他会把异常分类做得很干净，但不知道哪类异常在业务上必须立刻升级。

软件工程师最怕的不是不会写。更麻烦的是写得很稳，稳稳地解决了一个不重要的问题。

两边的 SWOT

把两类人放在同一张图里，差别会更清楚。

业务转型者的 Strength 是业务语义、场景直觉、验收判断、隐性规则和优先级感。他知道痛点在哪里，也知道一个结果能不能拿去给老板、客户、同事看。

他的 Weakness 是工程结构弱。容易低估权限、数据一致性、失败恢复、长期维护和系统边界。Agent 能帮他补代码，但不一定能补工程纪律。

他的 Opportunity 是巨大。过去他只能提需求，现在他可以直接生成原型、脚本、分析工具和流程自动化。很多小工具不再需要排进研发队列。

他的 Threat 是自动化碎片化。每个部门都生成一堆局部工具，短期提效，长期没人维护。等数据口径冲突、权限越界、脚本失效时，组织才发现自己多了一层影子 IT。

软件工程师的 Strength 是系统化能力。拆解、抽象、测试、工程边界、可维护性、自动化验证，这些都是 Agent 时代的放大器。

他的 Weakness 是业务语义不足。没有业务校准时，很容易把 Agent 用成代码加速器，最后离真正的问题越来越远。

他的 Opportunity 是从“写代码的人”升级成“把业务问题系统化的人”。Agent 替他写更多实现，他可以花更多精力定义模型、流程、验证和工具链。

他的 Threat 是停留在实现层。如果还把价值绑定在“我比别人更会写代码”，那优势会被快速压缩。Agent 时代，单纯会实现的人会越来越便宜。

谁更强，取决于任务生命周期

如果只看第一天，业务专家很强。他可以迅速把自己的问题讲给 Agent，得到一个脚本、页面、表格、自动化流程。

如果看第一周，软件工程师开始追上来。他会补测试，补输入校验，补日志，补异常，补文档，把东西做得更稳。

如果看三个月，差距通常会拉开。真正消耗组织成本的，经常是版本演化、协作维护、边界变更、数据迁移和事故处理，而不是第一版代码。

所以比较不能只问“谁更会用 Agent”。要问任务处在哪个阶段：

  • 探索阶段：业务专家占优。
  • 原型阶段：两者接近，业务专家目标更准，工程师结构更稳。
  • 产品化阶段：软件工程师占优。
  • 跨系统集成阶段：软件工程师明显占优。
  • 业务验收阶段：业务专家重新占优。

这不是职业高低，是能力位置不同。

真正的胜负手：学习速度

最有意思的是，中级业务熟练度可能已经足够让 Agent 编程成功。这意味着业务专家不必成为资深工程师，也能做出很多东西。

反过来，软件工程师也不必成为行业专家，才有资格进入一个领域。他要做的是用 Agent 快速补业务语义。

进入一个陌生领域时，工程师不应该先写系统。更好的顺序是：

  • 让 Agent 整理角色、流程、对象、状态、异常和验收标准。
  • 找真实材料，让 Agent 抽取业务词汇和判断规则。
  • 把不确定点整理成访谈问题，去问业务专家。
  • 把业务回答改成测试用例、反例和验收清单。
  • 再让 Agent 写代码。

这套方法会让软件工程师的短板快速收窄。因为他的强项不在于记住行业知识，而在于把知识变成结构。

业务专家也可以补工程能力，但路径更长。工程纪律靠几句 prompt 补不齐。状态边界、测试设计、部署风险、权限模型、数据一致性，这些东西需要踩过坑才会有感觉。

所以在两者都熟练使用 Agent 的前提下，长期看我更看好经验丰富的软件工程师。

但有一个前提：他愿意承认自己不懂业务，并把 Agent 当成业务学习和建模工具，不只当代码生成器。

结论：中心从代码移到校准

Agent 编程把一个旧分工打散了。

过去业务专家负责提需求，软件工程师负责实现。现在两边都能直接推动实现。真正的差别移到了更上层：谁能校准目标，谁能控制复杂性，谁能验证结果，谁能沉淀资产。

业务专家拥有业务校准。软件工程师拥有工程校准。

前者决定东西有没有用。后者决定东西能不能长期用。

如果只能选一个人做一次性工具，选业务专家。如果要做可复用、可维护、可扩展的系统，选软件工程师。如果要做最强组合，让业务专家给判断，让软件工程师建结构，让 Agent 承担执行。

以后“会不会写代码”会越来越不重要。

重要的是：你能不能把混乱的问题，校准成一个可以被机器执行、被人验证、被系统维护的结构。