近期对于AI Coding落地的理解：不仅是模型，还需要软件工程

前言

最近很多人都在讨论 AI Coding。

有的人觉得 AI 已经可以替代大量程序员，有的人觉得 AI 也就写写 Demo，真正进到生产系统里还是不敢用。两边看起来都在讲自己的真实经验，但结论差异很大。

我觉得这里面有一个关键问题经常被忽略：

大家讨论的不是同一个工程环境。

如果一个团队需求不清楚、系统边界不清楚、测试不完整、部署靠人工、核心逻辑靠老员工口口相传，那么 AI 写出来的代码当然很难直接上线。不是 AI 完全不行，而是它拿不到足够的信息，也没有被放进一个可验证的工程闭环里。

反过来，有些 AI Native 公司可以做到 80% 甚至更高比例的代码由 AI 产出，也不代表它们的工程能力弱，只是模型更强。很多时候恰恰相反：

它们的软件工程能力更强。

所以这个问题表面上是：

为什么 AI 在有些公司只能写 Demo，在另一些公司却能写生产代码？

本质上其实是：

一个组织的软件工程体系，是否已经被结构化到可以让 AI 执行。

AI 问题最后会回到软件工程问题。

先解释一下什么是 AI Native

AI Native 这个词现在被用得很多，但不同语境下含义不完全一样。

我这里说的 AI Native，不是指“产品里加了一个 AI 功能”，也不是指“研发团队买了 Cursor、Copilot、Claude Code 之类的工具”。

我更倾向于这样理解：

AI Native 公司，是把 AI 当成组织生产方式的一部分，而不是当成某个外部工具。

也就是说，它不是在原来的流程里加一个 AI 助手，而是会反过来重新设计产品表达、工程结构、测试体系、交付流程和组织协作方式，让 AI 能够稳定参与生产。

传统公司常见的方式是：

这里最重要的变化不是“谁写代码”，而是“系统能不能描述清楚自己”。

完整工程本身就是一件极具专业度、难度和时间成本的事情。真正可上线的软件，不是把功能写出来就结束，而是要把需求、边界、异常、测试、发布、监控、回滚都纳入同一个工程闭环。

这件事以前主要是为了让人协作，现在开始变成让 AI 协作的前提。

先看一张图

我理解 AI Coding 能不能进生产，大概可以拆成五层：

很多公司的问题，是直接从 CEO/战略层跳到最底层：

“大家都用 AI 写代码。”

但中间几层如果没有补起来，AI 最后只会变成一个更快的代码生成器，而不是一个稳定的工程生产力。

可以用一个简化公式理解：

AI 有效产出
≈ 模型能力 × 上下文完整度 × 约束清晰度 × 验证强度

这里面模型能力当然重要，但它不是唯一变量。

更关键的是后面三个：

• 上下文是否完整
• 约束是否清楚
• 验证是否足够强

如果这三个很弱，模型越强，生成垃圾的速度也会越快。

为什么传统公司觉得 AI 只能写 Demo

很多研发对 AI Coding 的评价大概是这样的：

• 会写 Hello World
• 会生成 CRUD
• 会写单文件工具函数
• 项目稍微大一点就开始乱
• 改一个地方容易影响三个地方
• 代码看起来能跑，但不敢直接上线

这些反馈都很真实。

因为 Demo 和生产系统之间，差的不是几行代码，而是大量上下文。

Demo 通常只有：

输入 -> 输出

生产系统则是：

输入 -> 业务约束 -> 历史上下文 -> 隐含规则 -> 非功能要求 -> 输出

这两者的信息密度差很多。

举个登录的例子。

如果让 AI 写一个“登录页面”，在 Demo 场景下很简单。邮箱、密码、按钮、调用接口、跳转页面，十几分钟就能生成一个看起来不错的页面。

但真实生产系统里的登录，可能包括：

如果这些信息没有结构化表达，AI 只能根据通用经验猜。猜对了是运气，猜错了就是事故。

这也是为什么很多 CEO 会觉得：

“模型还不够强，再等等 GPT-6。”

但技术团队感受到的往往是：

“不是模型问题，是工程问题。”

模型当然还会进步，但真实生产系统里最难的不是生成代码，而是知道哪些代码不能生成、哪些地方不能改、哪些约束必须满足。

AI 真正困难的是：

它不知道系统边界。

AI 代码比例取决于系统可描述程度

我觉得可以用一个简单的关系来理解：

AI 代码生成比例 ≈ 系统可描述程度

或者说：

Code Generation Ratio ≈ Specification Completeness

系统越规范，AI 越容易发挥作用。

系统越依赖人脑默契，AI 越难稳定落地。

很多传统公司的真实情况是这样的：

这时候人都很难一次做对，更不用说 AI。

因为这里没有可执行约束。

很多人一听到结构化表达，就会想到写一大段 YAML。YAML 可以用，但不是唯一形式，也不是最适合所有团队的形式。

更落地的表达，往往是下面这些东西：

所以重点不是把一切写成 YAML，而是把信息从“人脑默契”变成“可读取、可执行、可验证”的工程资产。

大部分公司的短板不是 AI，而是软件工程基础

很多公司过去这些年都在讲敏捷、TDD、DDD、微服务、DevOps，但真正落地的时候，经常会走样。

这些东西在人主导的时代，有时候还能靠经验、责任心和加班撑住。但到了 AI 参与开发的时候，问题会被放大。

因为 AI 依赖可观察性。

它需要知道：

• 当前系统有哪些模块
• 这个模块的边界在哪里
• 哪些接口可以改，哪些不能改
• 哪些测试必须通过
• 哪些规则是业务核心约束
• 哪些历史代码不能轻易动
• 出问题后如何回滚

但很多企业的真实信息分布在：

• 飞书聊天记录
• Jira 或其他任务系统
• Confluence 文档
• 代码注释
• 老员工脑子
• 临时会议纪要
• 微信群

这些信息没有形成一个统一、可执行、可验证的上下文。

所以当你问 AI：

“帮我改一下订单逻辑。”

它真正需要知道的是：

• 订单状态机有哪些状态
• 支付、库存、履约、发票、售后之间怎么协作
• 取消订单会不会释放库存
• 优惠券是否退回
• 已部分发货的订单能不能取消
• 下游有没有异步消息
• 历史上为什么有一段特殊判断
• 哪些场景有合同测试
• 改完之后要跑哪些回归

如果这些信息拿不到，AI 只能在代码表面做模式匹配。

这就是为什么很多 AI 改代码看起来很努力，但结果不稳定。

不是它不会写语法，而是它没有完整系统地图。

Harness Engineering 的价值

这两年我觉得一个很值得关注的概念是 Harness Engineering。

很多人过去讲 Prompt Engineering，重点是怎么把提示词写好。这个当然有价值，但如果只停留在提示词层面，很容易变成玄学。

Harness Engineering 更像是：

把 AI 放进一个受约束、可执行、可验证的工程环境。

它关注的不是一句 prompt 写得多漂亮，而是 AI 执行任务时，周围有没有完整的支架。

可以简单理解成：

AI + Context + Tool + Verification + Feedback

也就是：

需求进入系统以后，AI 能拿到必要上下文，能调用合适工具，能生成变更，能自动跑测试和检查，能根据反馈继续修正，最后由人做关键判断。

核心不是生成。

核心是控制。

如果只是写：

帮我写一个支付模块。

这更像 Demo。

如果是：

在现有 payment-service 中增加分账能力。

约束：
1. 不允许修改 payment-core 模块的公开接口。
2. 必须复用现有 PaymentOrder、LedgerEntry、SettlementBatch 模型。
3. 分账比例来自 settlement_rule 表。
4. 金额计算使用 Money 类型，禁止使用 double。
5. 需要覆盖正常分账、部分退款、分账失败重试三个场景。
6. 单元测试覆盖率不低于 90%。
7. 必须通过 contract test、lint、安全扫描和回归测试。
8. 不允许修改账务历史表结构。

这就开始接近生产。

再往下，还需要把这些约束接到自动化流程里：

AI 在这个环境里才可能稳定工作。

所以 Harness Engineering 本质上是：

把软件工程变成机器可执行规则。

它不是 Prompt Engineering 的替代，而是 Prompt Engineering 的工业化版本。

一个大数据场景下的例子：指标口径变更

前面的登录和订单例子更偏业务系统。换到大数据场景，AI 面临的问题会更明显。

假设产品或运营提了一个需求：

“把用户活跃指标优化一下，之前的 DAU 不太准。”

这句话看起来很简单，但真正落到数据平台里，可能涉及一整条链路：

埋点 -> Kafka -> ODS -> DWD -> DWS -> ADS -> BI 报表 -> 业务决策

如果让 AI 直接改 SQL，它大概率能写出一段能跑的 SQL。

但能跑不代表能上线。

因为这里真正难的是口径、血缘、成本和稳定性。

先把问题拆开

一个“DAU 口径调整”至少要问清楚：

这些问题不澄清，AI 写得越快，风险越大。

因为指标不是一段 SQL，而是一种业务契约。

更落地的表达，不一定是 YAML

在大数据团队里，真正能让 AI 稳定工作的输入，可能更像下面这些材料。

1. 指标定义表

2. 口径变更记录

3. 数据质量规则

4. 下游血缘清单

这些东西比一大段 YAML 更容易被团队接受，也更符合日常工作方式。

AI 可以基于这些材料去做几类事情：

• 修改 SQL
• 更新调度配置
• 生成回刷脚本
• 补充数据质量规则
• 生成新旧口径对比报告
• 更新指标文档
• 找出下游影响范围
• 给发布 Checklist 生成待办项

但前提是这些材料真实存在，而且格式相对稳定。

AI 在这里真正应该做什么

一个比较合理的 AI 执行链路可能是：

读取指标定义
-> 分析血缘影响
-> 修改 DWD/DWS/ADS SQL
-> 增加数据质量规则
-> 生成回刷计划
-> 跑样本分区验证
-> 输出新旧口径对比
-> 人工确认
-> 灰度切换报表

这和“帮我改一下 DAU SQL”完全不是一个量级。

后者是 Demo。

前者才是工程。

为什么大数据场景更能说明问题

大数据系统里，很多风险不是代码编译失败，而是结果悄悄错了。

服务端接口错了，可能很快报 500；数据口径错了，可能一个月后才发现经营分析偏了、运营策略错了、模型训练数据污染了。

所以数据工程里的 AI Native，不是让 AI 多写几段 SQL，而是让 AI 进入更完整的数据工程闭环：

数据源 -> 元数据 -> 血缘 -> 口径 -> 质量 -> 调度 -> 成本 -> 发布 -> 反馈

这里每一层都需要专业判断，也都需要时间沉淀。元数据要治理，血缘要可信，质量规则要持续维护，历史任务要梳理，下游依赖要有人负责。

这也是为什么完整工程很难。

不是因为大家不会写 SQL，而是因为让 SQL 变成稳定的数据产品，本身就是复杂工程。

原来的业务系统例子也可以保留

如果换回业务系统，订单取消也是一个很典型的例子。

产品可能只说：

“用户下单后，增加一个取消订单功能。”

但订单取消不是一个按钮，而是一组业务约束。

至少要说清楚：

• 哪些订单状态允许取消
• 支付前取消和支付后取消是否不同
• 是否需要释放库存
• 优惠券是否返还
• 积分是否返还
• 已发货是否允许取消
• 部分发货是否允许取消
• 取消后是否触发退款
• 退款失败怎么办
• 是否通知商家
• 是否通知履约系统
• 是否写审计日志

如果这些都没有，AI 生成的代码可能只是：

order.status = "cancelled"
order.save()

这就是 Demo。

如果系统里已经有明确的状态机、领域边界、事件规范、合同测试，AI 才有机会在可控范围里实现它。

所以这个例子和大数据指标变更本质是一样的：

AI 不是不能写代码，而是不能在没有边界、没有上下文、没有验证的情况下稳定写生产代码。

被筛选的不是程序员，而是软件建模能力

这也是我觉得很多讨论容易跑偏的地方。

大家经常问：

AI 会不会替代程序员？

这个问题太大，也太粗。

更具体一点，未来被压缩的可能是低约束、低上下文、低复杂度的编码工作。但真正被放大的，是抽象能力、系统建模能力、约束设计能力和工程判断力。

以前评价一个工程师，可能更容易看：

• 写代码快不快
• bug 多不多
• 算法熟不熟
• 框架会不会
• 能不能独立完成模块

这些能力仍然重要，但未来可能不够了。

因为代码会越来越便宜。

约束会越来越贵。

以前工程师主要写代码：

Coder

现在优秀工程师越来越像：

Architect

未来可能更接近：

System Designer
AI Supervisor

这不是说所有人都不写代码了，而是说写代码不再是唯一核心动作。

工程师要能把一个系统描述成 AI 可以理解和执行的结构。

比如在数据平台里，不只是写一个任务，而是要定义：

这背后考验的不是语法，而是建模。

你能不能把复杂业务拆成稳定边界。

你能不能定义清楚什么可以变，什么不能变。

你能不能让测试体系覆盖真正的风险。

你能不能把隐含知识沉淀成显性规则。

这些能力，才是 AI 时代更稀缺的工程能力。

国内很多公司的短板在产品和组织

很多时候，AI 落不下去，不只是研发的问题。

产品能力和组织能力同样关键。

软件开发本质上不是写代码，而是压缩信息熵。

一个模糊需求进入系统时，里面有大量不确定性。好的产品和技术团队，要把这些不确定性逐步压缩成可以执行、可以验证、可以交付的东西。

但很多公司的需求表达仍然是：

这种情况下，AI 没有办法执行。

因为它拿到的不是需求，而是情绪。

更好的表达应该是：

这才是 AI 可以参与的表达。

所以我觉得很多公司真正要补的，不只是 AI 工具，而是结构化能力。

产品要能把“我要高级”变成场景、指标、边界和验收标准。

研发要能把“帮我做一下”变成领域模型、接口契约、测试和发布约束。

管理者要能把“大家都用 AI”变成流程、基座、工具链和评价体系。

否则全员 AI Coding 很容易变成全员生成更多不可维护代码。

未来软件公司可能会分层

未来几年，软件公司在使用 AI 开发上可能会出现几层差异。

第一层是现在最多的。

团队使用 AI 工具补代码、写测试、解释代码、生成脚本、做局部重构。效率会提升，但整体开发模式没有本质变化。

第二层会开始把 AI 放进工程体系。

AI 不只是一个编辑器里的助手，而是被接入到需求拆解、代码生成、测试修复、文档更新、发布检查等流程中。

第三层更进一步。

代码本身不再是最核心资产，代码更像是某种编译产物。

真正的资产是：

• 数据
• 工作流
• 领域规则
• 用户反馈
• 产品抽象
• 工程约束
• Harness

这种公司才有机会达到 90% 甚至更高比例的 AI 代码产出。

但这并不意味着工程要求降低。

恰恰相反，它要求软件工程更严格。

一个可能有争议的判断

很多 CEO 现在推动的是：

全员 AI Coding。

这个方向没有错，但我觉得更底层的目标应该是：

全员结构化。

因为没有结构，AI 越强，制造垃圾的速度越快。

过去软件行业二十年，很多工程实践本质上是在解决一个问题：

如何让人更好地协作。

比如：

• 敏捷
• TDD
• DDD
• DevOps
• CI/CD
• Code Review
• 架构治理
• 可观测性

未来十年，可能要解决另一个问题：

如何让 AI 更好地协作。

而答案不是简单等一个更大的模型。

更大的模型会提高上限，但如果工程系统本身混乱，它也只是更快地撞墙。

真正需要补的是：

• 更清晰的产品抽象
• 更稳定的领域模型
• 更明确的工程边界
• 更完整的测试体系
• 更可执行的开发约束
• 更自动化的验证反馈
• 更成熟的组织协作方式

这些东西以前叫工程最佳实践。

在 AI 时代，它们会变成新的生产资料。

甚至可以说，它们正在变成 AI 时代的软件编译器。

最后

所以回到一开始的问题：

为什么同样是 AI，有些公司只能生成 Demo，而另一些 AI Native 公司已经可以让 AI 写大部分代码？

我的理解是：

差距不只在模型。

更大的差距在于软件工程体系本身。

AI Native 公司不是跳过了软件工程，而是把软件工程推到了更极致。

它们不是让 AI 在混乱里自由发挥，而是把需求、架构、规则、测试、工具、反馈都结构化，让 AI 在一个可控环境里执行。

这对传统公司反而是一个很现实的提醒：

不要只盯着“买哪个 AI 工具”。

更重要的是问自己：

• 产品需求能不能结构化
• 领域模型是否清晰
• 系统边界是否明确
• 测试能不能兜住风险
• 发布能不能自动验证
• 文档和上下文能不能被机器读取
• 组织知识是否还只存在于少数人脑子里

这些问题不解决，AI Coding 很容易停留在 Demo 和局部提效。

这些问题逐步解决，AI 才可能真正进入生产系统。

代码会越来越便宜，但好系统不会自动变多。

未来真正稀缺的，可能不是会不会让 AI 写代码，而是有没有能力把一个复杂系统描述清楚，并让它持续、稳定、可验证地演进。