Anthropic 4D：AI 研发不只是写代码

在研发流程里，AI 最容易被看见的能力是写代码。

但一个变更从提出到稳定运行，要走过需求、研发、自测、测试、预发和生产，还要把生产反馈带回下一轮需求。

如果团队只问“AI 能不能写”，很容易忽略更重要的问题：它该参与到哪一步？人要提供什么上下文？结果凭什么放行？出了问题谁负责？

Anthropic 介绍的 4D AI Fluency Framework，提供了一套理解这些问题的协作框架。

4D 管的不是提示词，是协作

根据 Claude Academy 的行为指标页面，4D 包含四个维度、24 条具体行为。

• Delegation，合理分工： 决定哪些工作交给 AI，哪些判断必须留给人。
• Description，清楚说明： 把目标、上下文、限制和验收条件说清楚。
• Discernment，判断结果： 独立检查事实、逻辑、代码和运行证据。
• Diligence，承担责任： 守住数据、权限、合规和最终责任边界。

它们不是四个固定步骤。更好记的说法是：先分工、说清楚、认真验收、负责到底。

放进研发场景，就是先决定 AI 能建议、修改还是执行，以及哪些决定必须由人批准。

任务交给 AI 时，要写清目标、上下文、修改边界和验收条件。

AI 交付结果后，仍要用代码审查、测试和运行证据独立验收。

无论 AI 参与多少，数据、权限、上线审批和最终责任都不能失控。

把 4D 放进完整研发循环

AI 可以协助执行和分析，但每一环的确认、放行与处置仍由人负责。

生产不是终点。线上指标、故障和用户反馈会形成新的需求，再进入下一轮研发和验证。

这也是为什么研发流程更适合画成一个循环，而不是一条到“上线”为止的直线。

成品越完整，越不能跳过验收

Anthropic 的 AI Fluency Index 分析了 9,830 段 Claude 多轮对话。在其中，“继续迭代和改进”出现于 85.7% 的对话，“核对重要事实与主张”只有 8.7%。

当 AI 生成代码、应用或文档等成品时，用户更常说明目标和格式，却更少指出缺失背景、核对事实或质疑推理。

这项研究只观察到 24 条行为中的 11 条，结果是相关关系，也不是一项软件研发全流程研究。但它提醒我们：输出看起来越像成品，人越容易把“完成”误当成“正确”。

每个环节只问四个问题

一个环节准备放行时，团队可以快速检查：

1. 合理分工： AI 可以建议、修改还是执行？哪些决定必须由人批准？
2. 清楚说明： 目标、上下文、限制和验收条件是否完整？
3. 判断结果： 有什么可以复核的代码、测试或运行证据？
4. 承担责任： 谁批准进入下一环，出现问题由谁处置？

真正的 AI fluency，不是让 AI 写更多代码，而是让它进入研发循环之后，团队仍然掌握判断权和责任边界。