手写业务代码，不是怀旧，是责任边界 | 道化天下企服

先把结论说完：AI 我们天天在用，但核心业务代码不让它写。

不是因为情怀，也不是不信任新工具。是因为这三件事绕不过去：责任、可维护、可审计。

这篇讲清楚我们的边界在哪，以及 AI 在我们这儿到底干什么活。

一、为什么核心业务代码坚持手写

系统出了资损，客户找的是人，不是模型。写这段代码的人，必须能当场解释：这一行为什么这么写、这个分支为什么存在。

「AI 生成的」不是解释，是借口。

AI 很擅长「怎么写」——语法、模式、样板。但真正的难点在另一侧：这个月的对账口径为什么变了、这笔退款为什么走这条分支、这个客户为什么不能走标准流程。

这些知识在业务里、在会议里、在客户的抱怨里，不在语料里。所以「为什么」必须由人先想清楚，代码才有人写对。

AI 一天能产出几千行代码，看起来很划算。问题在半年后：没人读得懂、没人敢改、没人说得清哪些是死代码。

技术债还能排期还，理解债是还不掉的——它直接表现为「一个小改动要三天」「不敢动，动就炸」。

金额计算、分账结算、退款冲正、权限判定、状态机流转 —— 这些地方出错不是「体验问题」，是资损和合规问题。

生成式模型输出的是「概率上最像的下一段」，不是「这里必须绝对正确」。这两件事在核心链路上不能混。

财税、工单、结算类系统，逻辑要能逐行解释，改动要能回溯原因。审计问「为什么这样算」，答案不能是「模型觉得应该这样」。

我们交付源码、部署文档和设计说明，能力要留在客户团队里。对方要接手的东西，必须是人能读懂、能改、能讲给别人听的。

一段没人能解释的代码，不叫交付，叫托管。

AI 真正的价值，是把「不需要判断」的部分做掉，让人把精力留给判断。

判断标准只有一句：可验证、可回滚、不承担业务责任的环节，交给 AI。

而且 AI 的产出一律不进主干：人读 → 测试覆盖 → 代码评审，三步走完才算数。

这一条很少被拿出来讲，但我们认为它比「提效 30%」重要得多。

工程师真正累的往往不是难题，是杂事：改一天命名、对一天格式、整理一天报表。这种事最消耗人，也最没有成就感。交给 AI，人才能去做那件值得做的事。

以前写一个模块，思路、样板、测试、文档全压在一段连续专注里，容易拖到深夜。现在 AI 先把草稿跑出来，人在清醒的时段做判断和复核——同样的产出，少熬几个小时。

一天做十件杂事，比做一件难事更让人疲惫。把杂事压缩掉，情绪成本会明显下降。这不是玄学，是每天都能感觉到的差别。

把 AI 当产量机器，让人变成 24 小时审核机器、盯着输出点通过 —— 那不是提效，那是把人变成流水线的一环。

这种项目我们不接，这种活法我们也不推荐。技术应该让人少熬一点夜，而不是让人多审一点稿。