AI 编程时代,开发者真正要负责什么

最近一次 AI 辅助开发里，我遇到了一个很典型的问题。

我们在做一个企业私有扩展，里面有一套 HR 核算功能：奖金规则、考勤补助规则、加班核对规则、分配矩阵等等。功能迁移后，页面能打开，规则也能编辑，计算也能跑。看上去问题不大。

一开始，AI 给出的实现方案是：把这些规则保存到私有扩展自己的 sidecar 数据库里。

这个方案并不是完全错误。它能工作，也符合“客户私有业务数据不要混进标准产品”的直觉。但是继续追问下去，就会发现这里有一个更深的问题：

这些规则到底是私有运行数据，还是标准规则引擎里的租户级配置数据？

这个问题，比“代码能不能跑”重要得多。

更有意思的是，这个判断不是 AI 一开始主动做对的。

当时人的第一反应其实很简单：这个方向好像不对。

但这种“不对”一开始并不是完整的架构论证，只是一种来自产品经验和系统直觉的警觉。于是我开始反复追问 AI：

规则引擎不是标准能力吗？

这些规则不是应该保存到规则引擎中的具体规则配置数据吗？

这样才能复用原来的标准规则引擎编辑能力。

AI 最初并没有立刻同意。它会继续解释为什么 sidecar DB 更符合私有数据边界，为什么客户私有业务事实不应该进入标准产品表。那些解释听起来都挺合理，也不是胡说。

但继续争论下去，关键差异才逐渐暴露出来：这不是“客户私有数据要不要隔离”的问题，而是“标准规则引擎能承载的租户级规则，是否应该绕开标准规则体系”的问题。

最后 AI 才修正判断，承认人的方向是对的：这些规则应该进入标准规则引擎的配置体系，只是通过租户、扩展命名空间和权限来区分归属，而不是被塞进 sidecar 的运行记录里。

这个过程本身，就是 AI 编程里非常重要的一课。

很多时候，人不是一开始就能说出完整答案。但人的架构直觉会先响一下警报。真正的能力，是不要轻易被 AI 的流畅解释压过去，而是沿着那个“不对劲”继续追问，直到问题被重新定义。

在这个案例里，AI 最初的判断逻辑大概是这样的：

既然这是某个客户的私有扩展，而不是标准产品能力，那规则数据就应该放在私有扩展自己的数据库里。标准产品只提供通用能力，客户私有数据不要进入 Core DB。

这个判断听起来很有架构意识。

但它漏掉了一个前提：规则引擎本身就是标准产品能力。

如果一条规则可以被标准规则引擎表达、编辑、版本化、回滚、测试和审计，那么它就不应该绕开规则引擎，变成 sidecar 里的一段普通 JSON。

否则短期看是“边界清晰”，长期看其实是在制造第二套规则系统。

于是开发者需要继续追问：

• • 这条数据是“客户私有业务事实”，还是“标准能力下的租户级配置”？
• • 现有标准规则引擎是否已经支持这种规则？
• • 如果支持，为什么要绕开它？
• • 如果绕开，后续规则编辑、版本管理、回滚、审计、执行日志由谁负责？
• • 用户未来在标准规则管理界面里，是否应该看到和维护这些规则？

这些问题，AI 不一定会主动问。

但开发者必须问。

表面上看，这只是一个数据库落点选择：

方案 A：保存到 private_s_company.extension_runs 方案 B：保存到 public.rules

但真正的问题不是“放哪张表”，而是“这件事属于哪个产品能力”。

如果保存到 sidecar 的运行记录表里，它本质上只是一个扩展内部的 JSON 数据。它能被 sidecar 读取，能参与计算，但很难自然复用标准产品已有的能力：

• • 规则列表
• • 规则详情编辑
• • DSL 校验
• • 版本管理
• • 规则回滚
• • 规则测试
• • 执行日志
• • 审计追踪
• • 后续统一规则管理 UI

而如果保存到标准规则表中，它就进入了平台的规则配置体系。

更合理的建模是：

规则引擎：标准产品能力 规则配置：租户级定制数据 规则命名空间：私有扩展命名空间 运行态数据：sidecar 私有数据

也就是说，这些规则不应该被当成“标准 HR 的公共规则”，也不应该被当成“sidecar 内部杂项 JSON”。它们应该是：

标准规则引擎中的租户级扩展规则

例如：

tenant_id = 当前租户 product = s-company-extension.hr rule_id = s_company.hr.epc_bonus_pool rule_id = s_company.hr.base_rate_table rule_id = s_company.hr.attendance_subsidy rule_id = s_company.hr.overtime_rule_config

这样既能复用标准规则引擎，又不会和标准 HR 规则混淆。

这类问题最麻烦的地方，不是 AI 写不出代码。

恰恰相反，AI 往往能很快写出一套能跑的代码。

真正危险的是：它可能给出一个看起来很专业、局部也说得通，但在系统演进上不对的方案。

比如：

客户私有规则属于私有业务事实，所以应该放到 sidecar DB。

这句话不能说错。

但它不完整。

更完整的说法应该是：

如果规则引擎已经支持这类规则，那么它首先应该作为租户级规则配置进入标准规则体系；只有规则引擎不支持的私有结构、运行态缓存、外部系统同步数据，才应该放到 sidecar DB。

这里差的不是代码能力，而是抽象层级。

AI 很容易在一个抽象层级上做出合理判断，但开发者要能把问题拉到更高一层，看清楚：

• • 这是功能实现问题，还是产品建模问题？
• • 这是数据隔离问题，还是能力复用问题？
• • 这是客户定制，还是租户级配置？
• • 这是绕开标准能力，还是扩展标准能力？

这些判断，决定的是系统未来半年、一年以后会不会变成一团乱麻。

很多人讨论 AI 编程时，会把重点放在：

• • AI 写代码快不快
• • 单元测试能不能过
• • 生成代码质量高不高
• • 能不能替代初级程序员

这些都重要，但还不是最核心的。

真正决定 AI 编程质量的，是开发者能不能承担这几类责任。

1. 判断问题属于哪个层级

AI 很擅长解决“明确的问题”。

但现实开发中，很多问题一开始并不明确。

“规则保存在哪里？”看似是数据库问题，实际是产品能力边界问题。

“页面数据为空”看似是前端问题，实际可能是接口契约问题。

“保存时报错”看似是校验问题，实际可能是状态字段复用了错误语义。

开发者必须有能力把现象拆开，判断它到底属于：

• • UI 展示问题
• • API 契约问题
• • 数据模型问题
• • 权限边界问题
• • 产品抽象问题
• • 架构演进问题

如果问题层级判断错了，AI 写得越快，偏得越远。

2. 守住系统原有能力，不轻易另起炉灶

AI 很容易为了完成当前任务，写一套局部实现。

能存 JSON，就写 JSON。

能加字段，就加字段。

能新建一张表，就新建一张表。

但成熟系统里，很多能力已经存在：规则引擎、权限系统、审计系统、版本系统、任务系统、配置系统。

开发者要做的不是让 AI “最快写完”，而是不断追问：

• • 这个能力系统里是不是已经有了？
• • 这次实现是在复用它，还是绕过它？
• • 如果绕过，是因为它真的不支持，还是我们没想清楚？
• • 绕过以后，谁来承担后续维护成本？

AI 编程中，最重要的工程纪律之一就是：

能复用标准能力，就不要创造影子系统。

3. 识别“能跑”和“正确”的区别

能跑，是最低要求。

正确，至少还包括：

• • 数据归属正确
• • 权限边界正确
• • 生命周期正确
• • 迁移路径正确
• • 后续可维护
• • 用户心智一致
• • 与产品长期方向一致

在这个案例里，把规则存在 sidecar 里，功能可以跑。

但它会导致规则编辑能力被割裂，版本管理被割裂，执行审计被割裂，未来统一规则中心也无法自然接入。

所以它是一个“能跑但不够正确”的方案。

这类问题，测试不一定能发现。

测试通常验证的是行为，而不是架构意图。

开发者必须补上这层判断。

4. 有能力反驳 AI，而不是被 AI 的流畅解释带走

AI 最大的迷惑性之一，是它很会解释。

哪怕方案有偏差，它也能讲出一套完整理由。

如果开发者没有自己的判断框架，很容易被“听起来对”的解释说服。

这次真正让方案回到正确方向的，不是 AI 主动发现了问题，而是人持续追问：

规则引擎不是标准能力吗？

这些规则不是应该保存到规则引擎中的具体规则配置数据吗？

这样才能复用原来的标准规则引擎编辑能力。

这些追问非常关键。

更真实地说，这不是一次“提问然后 AI 立刻采纳”的过程，而是一轮来回争论。AI 一开始会维护自己的方案，人也未必能马上把反驳讲完整。真正起作用的是人的持续判断：我仍然觉得这里不对，所以继续问，继续拆分概念，继续要求 AI 解释“标准规则引擎”和“私有 sidecar 数据”之间的边界。

直到问题被重新表述为：

如果标准规则引擎支持租户级规则配置， 那么客户定制规则就应该复用标准规则体系； 只有规则引擎不支持的私有结构和运行态数据， 才应该放到 sidecar DB。

到这里，AI 才承认原来的判断不够准确。

AI 编程不是把需求扔给 AI，然后等待代码落地。更像是一个高强度的技术评审过程：

AI 提方案 人判断边界 AI 改实现 人继续校正抽象 AI 补测试和迁移 人确认长期方向

开发者的价值，不是每一行代码都亲手写，而是知道什么时候该说：

不，这个方向不对。

这次最终的方案变成了：

规则配置数据：   保存到标准产品 public.rules   通过 tenant_id + product + rule_id namespace 区分租户和扩展归属  规则执行能力：   复用标准 RuleEngine  sidecar 私有数据：   只保存导入记录、核算台账、流水线、通知、运行结果等运行态数据  兼容迁移：   旧的 sidecar 规则记录首次访问时迁入 public.rules

这比最初方案更好。

不是因为 AI 一开始就想对了，而是因为开发者不断校正问题定义。

这也说明，AI 编程里的“高级开发者能力”会越来越重要。

过去，高级开发者和初级开发者的差距，可能体现在谁更熟悉框架、谁写代码更快、谁踩坑更多。

现在，这些差距会被 AI 部分抹平。

但新的差距会变得更明显：

• • 谁能定义问题
• • 谁能判断边界
• • 谁能识别抽象层级
• • 谁能坚持复用系统能力
• • 谁能发现 AI 方案里的隐性长期成本
• • 谁能把一次 bug 修复变成系统设计的改进

AI 会让“写代码”变快。

但它也会放大“判断错误”的代价。

因为一旦方向错了，AI 可以非常快地帮你把错误方向实现完整。

我越来越觉得，AI 编程时代的开发者，不只是 prompt 工程师，也不只是代码审核员。

更准确的角色是：

系统设计的校准者 产品抽象的守门人 工程质量的最终责任人

AI 可以生成代码、补测试、改文档、跑命令、修 lint。

但它不会天然知道一个系统为什么长成现在这样，也不会天然知道哪些边界是团队过去踩坑后沉淀下来的。

这些需要开发者告诉它、纠正它、约束它。

所以，AI 编程对开发者能力的要求不是降低了，而是迁移了。

从“我能不能写出这段代码”，迁移到：

我能不能判断这段代码是否应该存在？ 我能不能判断它应该属于系统的哪个位置？ 我能不能判断它复用了正确的能力，还是创造了新的债务？ 我能不能在 AI 给出流畅解释时，仍然坚持追问？

这才是 AI 编程真正拉开的差距。

AI 编程并不意味着开发者可以少思考。

恰恰相反，它要求开发者更会思考。

因为代码生产速度越快，架构判断就越重要；局部实现越容易，系统边界就越不能含糊。

未来优秀的开发者，不一定是写代码最多的人。

而是那个在 AI 快速推进时，仍然能看清楚方向的人。

能问出那个关键问题的人。

能在“看起来都对”的方案里，判断哪个才是长期正确的人。

AI 负责加速。

开发者负责校准。

这两者合在一起，才是真正高质量的 AI 编程。