不懂代码的人用 AI 重写自家老软件：责任边界要提前写清
一、被改变的是责任分布，不是难度
据公开报道，有做养猪设备的公司，老板本人不懂代码，带着一名非技术出身的实习生，用 AI 把卖了十年的自家软件重写了一遍。这家公司的经营状况与技术选择都不在本篇讨论范围，也不据此推断它的技术栈、代码规模与维护方式。它值得拿出来谈，是因为这类事接下来会越来越多，而多数讨论都停在“能不能写出来”这一层。
能不能写出来这个问题确实被 AI 改掉了。剩下的问题一个都没被改掉：业务规则的正确性、数据的一致性、并发下的行为、上线与回滚、故障时的响应。这些东西不会因为代码是谁生成的而消失，它们只会换一个更不容易被发现的位置藏着。所以自助开发真正改变的是责任分布：过去“谁会写代码”和“谁对系统负责”绑在一起，现在这两件事可以被拆开，拆开了就必须显式指定由谁承接，否则等于没指定。
先说清立场：我们不支持把非专业开发者挡在工具外面，也不认为他们写出来的东西天生低质。恰恰相反，业务规则最完整的表述通常就在业务方脑子里，专业侧常常才是那个理解不深的一方。要划的是一条边界——哪些系统可以自助，哪些必须有人承接。
二、三类系统与承接边界
把系统分成三类，不是按技术复杂度，而是按出错之后谁会承担损失。
| 系统类别 | 典型形态 | 出错影响面 | 能否自助 | 专业侧承接方式 |
|---|---|---|---|---|
| 个人效率工具 | 一次性脚本、表格整理、本地小助手 | 只影响使用者本人，结果可自行核对 | 可以，无需审批 | 不提供承接，只给依赖与安全基线建议 |
| 部门内小工具 | 组内看板、录入表单、内部报表 | 影响本部门工作质量，一般可人工兜住 | 可以自助，但要登记 | 登记入口与数据源，做一次性安全检查 |
| 核心系统 | 涉及订单、库存、价格、结算、客户数据 | 影响外部客户与账务，错误不可自行发现 | 不应自助上线 | 由专业侧承接架构、数据模型、发布与故障响应 |
这张表的重点在最后一列：前两类不是“随便搞”，而是承接方式不同——不需要评审架构，但需要知道数据从哪来、存在哪。第三类的关键判断标准也不是技术难度，而是错误的可发现性：核心系统里最危险的一类缺陷，是运行完全正常、界面毫无异常、数据却已经在悄悄变形。非专业开发者没有任何手段能发现这类问题，能发现的人必须事先被写进责任表。
三、把核心系统交给非专业人员的四条硬风险
这四条不是能力问题，是注意力问题——他们不会往这些方向想，因为业务里没有对应的概念。
- 数据模型没有约束，也没有迁移方案：字段类型靠约定，唯一性靠人小心，历史数据怎么搬过去没有想过。第一版跑得顺，等到有人误录或接口重放，脏数据就永久留在库里
- 并发与幂等没人考虑：业务方脑子里的流程是线性的，一个人一步一步操作。真实系统里会双击提交、会重试、会有两个人同时改同一条记录，重复出库与重复计价都从这里来
- 安全边界靠默认值：默认配置往往是公开的、可列的、能越权的；页面藏起来的按钮后面接口仍然敞开；凭证直接写在配置里。这些在演示时看不出任何异常
- 故障时没人看得懂日志：出错之后手上只有界面截图，没有请求标识、没有时间窗、没有关联键。这种状态下的排障只能靠猜，而猜的过程里业务还在损失
这四条之所以要单列，是因为它们决定第四节那四项最低护栏为什么不可谈判。
四、业务方坚持要上生产时的四项最低护栏
如果业务方判断这个系统值得上，专业侧要给的不是劝退，是一条明确的底线。四项护栏，缺一就不该有生产流量，这一条要写在评审结论里。
- 代码进版本库并有人评审。版本库的作用不是给程序员方便，是让“现在跑的是哪一份”有答案；评审不必逐行，但数据模型、接口鉴权和发布脚本三处必须有人点头
- 关键数据走只读视图或既有服务接口，不允许直连生产库。这条护栏的收益最大：它把最不可逆的一类风险（写坏生产数据）从自助系统的能力范围里拿掉，同时让业务方仍然能拿到需要的数据
- 上线前必须跑一次真实的备份恢复演练。不是“确认有备份”，而是把备份拉到新环境恢复出来并核对关键表，让人知道恢复要多久、恢复完会丢多少
- 故障响应有指定承接人与升级路径。写清第一响应人是谁、多久内到位、什么情况必须升级到专业侧、升级后由谁接手；没有这一条，前一条护栏在半夜不起作用
四项都能落到文档字段上，可以直接当验收条款用：代码位置、数据访问方式、恢复演练记录与耗时、承接人与升级触发条件。
五、把脑子里的规则变成可回归的东西
业务方自助开发最大的价值恰恰在这里：重写是一次逼着把规则显式化的机会。可操作的产出是三件套。
- 规则清单：一条业务事实一行，写清适用条件与例外。凡是从老系统里“看数据猜出来的规则”，要标成待确认，由业务负责人逐条签字
- 样例数据：每条规则至少配一组正例和一组反例，用真实历史数据脱敏后固化下来
- 验收用例：把样例跑成可重复执行的对照，重写后的系统必须逐条对上；对不上的要么改实现，要么承认老系统里有隐藏规则
两个坑在这一步一定会出现。一个是隐藏规则与缺省行为的差异：老系统某个字段留空时会自动按某个值算，新系统留空就是不参与计算，界面看不出来，结果差出去很远。老系统里那些“从来就是这么算的”表述，多数对应一条没人写下来的默认值。另一个是数据口径变更导致历史报表对不上：新系统按更干净的方式重算了一遍，趋势图上的拐点会让人以为业务出问题，其实只是口径换了。处理办法是把口径变更当作一次有记录的变更来发布，写清哪些历史数字因此不可比，而不是悄悄把历史刷成一致。
六、维护的现实、合同含义与一条务实建议
维护阶段真正的成本在人身上。写这套东西的实习生或业务负责人一旦离开，接手者面对的是没有测试、命名随意、结构靠感觉的代码，接手成本比想象中高得多；生成代码“能读”和“能改”是两件事，能读不代表改一处不会连带影响三处。依赖升级同样不会被 AI 替我们免掉：运行时的安全补丁、被弃用的接口、许可证变更，这些都要有人定期处理，而自助系统往往从来没有人排这个日程。
合同层面要把责任切分写清。业务方自研部分与专业方承接部分，各自对什么负责、边界在哪个接口上、出问题按什么顺序响应，都要写明。验收口径是最容易被含糊掉的一条：只写“界面符合预期”是不够的，必须落到数据层与规则层——关键写入的约束在哪、对账口径是什么、规则清单里的用例是否逐条通过。验收条款里出现不了数据字段，等于把质量责任留给了口头承诺。
洹拓接这类项目时会给一条务实建议，也写在本文最后：把自助开发的范围明确限定为原型与内部工具，一旦要正式投产，由专业侧做一次架构与安全重排——不是把业务方的代码推倒重写，而是把数据模型、访问边界、发布与回滚、故障响应这四件事重新搭一遍，业务规则和验收用例原封不动搬过来。这样业务方保留了他们最值钱的部分，也就是对规则的理解，专业侧补上他们不该独自承担的部分。责任边界提前写清，从来不是对自助开发的限制，而是让它能长期跑下去的前提。