用 AI 写生产级代码：PAAD 的工程主导流程
能。用 AI 写生产级代码其实直截了当，需要工程纪律，前期会多花些 token，但换来的是质量更高、更少被打回返工的代码。总拥有成本下降——可惜很多公司还盯着单位成本。这是 Perl 社区知名作者 Ovid 的实践总结（dev.to），核心是一套叫 PAAD 的流程。
实验：不读代码写代码
作者常年飞各国做培训咨询，晚上在酒店独处时给自己出了道题：如果"英语是新的编程语言"，为什么还要读生成的代码？他想验证能不能在开发过程中完全不写、不看代码，产出经验丰富的工程师愿意接手的代码。
实验假设是自己会失败，但失败过程能学到东西分享给别人。假设错了——他没失败。一开始失败很多，但持续学习，最终成功。
第一个尝试是把 Perl 的 sqitch 数据库迁移工具移植到 Python。他写了极其详细的 prompt 和逐步规格，结果是一团糟。但实验规则是失败前不读代码；失败后找根因。他发现大代码库像一张图：叶子节点是图内没有依赖的节点，先移植叶子、从图里移除，就得到新的叶子集合（处理循环依赖的边角情况）。按图序移植——成功了。SQLite 迁移先跑通，然后请 Fosstodon 上的人评审（刻意不提 AI），收到 Python Twisted 作者 Glyph 的评审：指出一堆小问题，根源都是"不懂 Python"，但结论是"看起来不错"。
教训：需要理解一门语言的最佳实践并显式纳入流程；方向是对的。转 PostgreSQL 时崩了——因为专注 SQLite 移植，AI 在代码里到处埋了 SQLite 假设。修复不如重写，于是重来，但教训保留。
流程成型
过程逐步收敛为：遵循预定义流程；尝试写 AI 能力之外的代码；失败时理解根因；问自己"怎么向初级开发者解释这个"；把解释变成 agent 技能防止问题复发。技能越积越多，最终整理成插件 PAAD——AI 辅助编程的纵深防御：
- 写规格（spec）
- 评审规格
- 创建计划（工单）
- 确认计划与规格一致
- 实现
- 测试和 CI
- 评审
- 人工决策
这看起来就是你不用 AI 时也在做的事——这不是巧合。PAAD 最初为 Claude Code 创建，可装到 70 多种 agent 编码工具上。
为什么 PAAD 不同
很多人见过 AI 的失望之处：第一天像魔法，第一个月高效，之后发现 god object、全局可变状态、一堆安全洞、永远解不完的乱麻。因为 AI 聚焦你给它的任务并努力解决它，不天然看大局——充其量是个初级开发者。坏模式进入代码库后，预测机器用坏模式帮它做新预测：代码库的缺陷鼓励 AI 叠加缺陷。
真相很简单：人可能是资深开发者，但开始用 AI 时都是初级 AI 开发者。把 AI 当魔法仙尘撒在问题上指望问题消失——"prompt and pray"——是 AI 主导工程，长期不奏效。作者不教 AI 主导工程，教工程主导 AI：AI 能做任务，不能做工作；AI 解决你现在的问题，不会自动想大局；而且它是随机的。
随机（stochastic）意味着"可预测的随机性"——产出形状像你要的东西，但行为剧烈摆动。人类也随机，所以好开发者仍然写测试、要代码评审、要 CI/CD 兜底、QA 再抓一层。为什么 AI 没有这套纵深防御？大部分 AI slop 只是以 AI 速度累积的技术债，我们知道怎么管技术债，就知道怎么管 AI slop。PAAD 没有魔法：不是指望 AI 替我们干活，而是我们干活、让 AI 提速。今天作者常让 agent harness 在后台写软件，自己在开会、写演示、研究问题。
边界
PAAD 离不开工程纪律，你的专业判断仍然关键。它不主张把缰绳交给 AI。定义"生产级"就一句话：经验丰富的工程师拿起来说"这代码我能上手"——作者写了数十年代码，人工生成的代码也经常过不了这关，但流程是工程主导的，正确性、安全、可运维、可观测、性能、恢复都要考虑。