夜雨聆风
最近两周看了一圈海外工程社区和技术媒体，关于软件质量的讨论有一个明显变化：大家不再只问“AI 能不能写代码”，而是在问“AI 写得越来越快以后，质量体系怎么办”。
这个问题很现实。
因为 AI 带来的不是单点提效，而是整个 PDLC 的节奏变化。需求可以更快拆，代码可以更快写，测试可以更快生成，发布也可以更频繁。表面看是效率提升，背后却可能把风险成倍推到下游。
我的判断是：AI 时代的软件质量，不能再靠最后测试兜底。PDLC 必须从“交付流程”升级成“质量闭环”。
## 一、真正的问题不是 AI 写错代码，而是质量责任后移
过去很多团队的质量模式，本质是：
- 产品提需求；
- 开发写代码；
- 测试找问题；
- 发布后靠监控和客服发现漏网之鱼；
- 出事故再复盘。
这套模式在人工开发时代已经很吃力。到了 AI 时代，它会更危险。
原因很简单：AI 把“产出速度”放大了，但没有天然放大“理解能力”和“责任能力”。
Hacker News 上有人问现代 AI 开发工作流怎么搭，讨论热度很高。很多人的实践已经不只是 Copilot 补全，而是 Claude Code、Codex、Cursor、脚本、CI、评审工具混在一起。问题是，工具越多，质量边界越容易变模糊。
Stack Overflow 最近写到 AI Agent 的“confused deputy”风险：Agent 拿着权限执行自然语言请求，如果身份、授权和业务规则没有重新绑定，它可能不是绕过安全模型，而是暴露出过去靠人肉判断补上的漏洞。
6 月 8 日，多家技术媒体转述 Tricentis 2026 质量报告：60% 的组织仍在发布未经充分测试的代码；32% 的受访者把原因指向领导层对速度优先的压力，30% 指向 AI 生成代码量太大、测试跟不上。Dice 的分析也把问题说得更直接：AI 让软件产出更快，但验证、治理和 QA 流程没有同步跟上。
这些材料放在一起看，结论很清楚：
**AI 不只是让代码变多，它会把组织原来没写清楚的质量责任、权限边界和验收标准全部放大。**
## 二、PDLC 的质量重心，要从“测试阶段”前移到“规格阶段”
AI 时代最容易犯的错，是让 AI 同时写实现和测试，然后看到测试通过就放心。
这其实很危险。
如果测试也是根据实现生成的，它可能只是在证明“代码符合代码自己的想法”，而不是证明“系统符合真实需求”。
所以 PDLC 的第一道质量门，不应该是测试，而应该是规格。
一个需求进入开发前，至少要讲清楚五件事：
- 目标：这次到底解决谁的什么问题；
- 边界：哪些场景不做，哪些系统不碰；
- 规则：核心业务规则、异常路径、权限约束是什么；
- 验收：什么结果算完成，哪些指标能证明完成；
- 风险：影响哪些上下游，失败后如何回滚。
AI 很擅长补全，但不擅长替组织承担模糊性。你给它一句“优化下结算流程”，它可以写一堆代码；但如果结算口径、账期、异常单、权限、灰度、回滚都没说清楚，它越能干，越可能把错误扩散得更快。
我更倾向于把 AI PDLC 的核心理解成：用标准化规格提高使用下限。
不是指望每个工程师都成为顶级 AI 玩家，而是通过 SDD、模板、案例库、知识召回、质量门，把“有人 3 分钟解决、有人 2 小时绕圈”的差距压下来。上限仍然取决于个人能力，但组织至少要把下限托住。
## 三、质量不是一个点，而是一个面
很多团队讨论质量，容易停留在“这次代码有没有 bug”。
但真实的软件质量不是一个点。
点，是这次改了哪几行代码。
链，是它影响了哪些上下游。
面，是业务场景、数据路径、权限模型、灰度范围、监控指标、回滚方案、用户反馈和复盘沉淀。
如果开发只看点，测试只看用例点，组织就会漏掉影响面。
所以我建议把 PDLC 质量拆成六道门：
第一道，需求质量门。验收标准、非目标、业务规则、权限边界必须清楚。
第二道，设计质量门。影响面、数据一致性、上下游契约、性能容量、失败模式要讲清楚。
第三道，编码质量门。lint、typecheck、单测、异常处理、安全扫描尽量自动化。
第四道，评审质量门。写代码的人或 Agent 不应该单独判断自己完成，至少要有 maker-checker 分离。
第五道，发布质量门。灰度、特性开关、回滚、监控、告警和值守必须配套。
第六道，复盘质量门。每次线上问题都要问：这个坑能不能变成规则？能不能写进 SOP？能不能变成测试？能不能加入回归集？
这六道门合起来，才是 AI 时代 PDLC 的质量闭环。
## 四、Agent 越强，权限和现场感越重要
最近 Stack Overflow 那篇 Agent 安全文章给我的启发是：很多系统过去不是没有规则，而是规则没有真正写进系统。
比如客服、运营、开发、测试、发布经理，很多时候会靠经验判断：这个请求像不像异常？这个账号能不能改？这个发布是不是太危险？这个指标波动是不是业务问题？
过去这些判断藏在人身上。现在让 Agent 接手，如果没有把身份、权限、上下文、审计、回滚写进系统，它就可能拿着合法权限做出错误动作。
所以 AI PDLC 里有一个很重要的原则：
**不要只给 Agent 工具，也要给 Agent 边界。**
它能读什么代码？能不能改生产配置？能不能访问真实数据？能不能发起发布？什么情况下必须停下来问人？什么风险需要第二个 Agent 或人工复核？
这些问题不写清楚，AI 提效就会变成权限风险。
同时，人不能完全离开现场。
不要只看 dashboard，也不要只看 Agent 总结。每周抽几个 PR、几个失败任务、几个线上异常，自己下去看真实代码、日志、用户路径和运行结果。
因为所有指标都会漏东西。工程负责人必须保留现场感，否则很容易被漂亮的自动化报表骗过去。
## 五、组织要从“多做测试”升级成“Right Check”
质量治理不是简单多加几张 checklist。
真正要做的是 Right Check：在正确的位置做正确的检查。
需求阶段检查验收标准。设计阶段检查影响面。编码阶段检查边界和异常。评审阶段检查业务逻辑和上下游契约。发布阶段检查灰度、回滚、监控。上线之后检查指标、客诉、复盘和规则沉淀。
这背后还有一个管理问题：谁有权拦截？
很多事故不是没人知道流程，而是流程没有权力。
CR 没做，也上线了。监控没配，也上线了。回滚没验，也上线了。Checklist 没过，也上线了。
这说明问题不在文档，而在闸门。
AI 时代的质量体系，必须回答清楚十个问题：
- 谁定义需求验收？
- 谁识别技术风险？
- 谁确认影响面？
- 谁维护自动化用例？
- 谁保障测试数据和环境？
- 谁有权拦截高风险发布？
- 谁负责灰度和回滚？
- 谁盯线上业务指标？
- 谁推动事故复盘？
- 谁把复盘结果沉淀成规则？
如果答案是“大家一起负责”，基本等于没人负责。
## 六、普通团队可以从四件事开始
第一，建立 AI PDLC 的规格模板。
不要一上来追求大而全。先把每个需求的目标、边界、验收、风险、回滚写清楚。模板越具体，AI 输出越稳定。
第二，把高频问题沉淀成知识库。
Web VIBE、Agent 修 bug、测试用例生成、发布失败、线上回滚，这些场景都会反复出现。每次不要只解决一次，要记录触发条件、解决路径、验证方式和注意事项，让下次能被召回。
第三，把质量门接进工具链。
类型检查、单测、集成测试、关键业务冒烟、安全扫描、截图验证、SQL 校验、灰度检查，能自动化的逐步自动化。质量门不一定一次建完，但必须持续加。
第四，建立复盘到规则的机制。
复盘不是写检讨。复盘的产物应该是规则、测试、SOP、监控、告警、脚本、知识库。否则事故只是被记录，没有被消化。
## 结尾
AI 时代，软件质量不会因为模型变强自动变好。
相反，模型越强，组织越要把质量体系讲清楚。
因为 AI 会放大一切：放大好流程，也放大坏流程；放大清晰规格，也放大模糊需求；放大工程能力，也放大组织懒惰。
未来真正有竞争力的团队，不是单纯写代码最快的团队，而是能把需求、设计、代码、测试、评审、发布、监控、复盘串成闭环的团队。
一句话：
**AI 写代码越快，PDLC 的质量门越要前置。**
不要把质量留给最后一个测试同学，也不要留给最后一次上线祈祷。
把质量写进流程、工具、权限、数据和复盘里，才是 AI 时代真正靠谱的软件工程。
## 参考来源
- Stack Overflow Blog, AI agents are a confused deputy with the keys to your kingdom, 2026-06-17
- Hacker News, Ask HN: What is your (AI) dev tech stack / workflow?, 2026-06-05
- Hacker News, Show HN: Command Center, the AI coding env for people who care about quality, 2026-06-08
- Augment Code, How AI Changes the SDLC: A Six-Stage Guide, 2026-06
- Automation.com, Report: 60% of Global Organizations are Shipping Untested Code as AI Accelerates Software Development, 2026-06-08
- Dice, How IT Leaders Can Rebuild Trust in AI-Generated Code, 2026-06-08
