一年已经过去一大半，半年总结一直没做，刚好趁着前段时候参加QECon演讲的一些思考，总结这篇文章，主要分为两个部分:
- 谈谈AI时代的后端开发
- QECon演讲PPT的内容
谈谈AI时代的后端开发：曾经被“忽略”或“轻视”的问题
做了多年的后端开发和全栈开发，在 AI 快速迭代的这两年中，感觉曾经被“忽略”或“轻视”的问题，在 AI 时代显得更加重要：
1. 极其严苛的输入验证与“防御性工程” 更加重要
- 以前：后端接口的输入大多来自前端，格式相对固定（如 JSON 表单），很多人写接口时，参数校验（Validation）只做表面功夫，甚至为了赶进度直接裸奔，全靠“前端做过校验了”来心理安慰。
- 现在：后端接口的调用者正在从人类变成 AI Agent (Tool Calling)，AI 的行为具有非确定性，它可能会传进奇奇怪怪的边界值、逻辑上矛盾的复合对象、甚至由于幻觉生成的脏数据或者操控AI直接攻击，所以现在的后端必须像对待“黑客攻击”一样对待 AI 的每一个请求，强类型校验和严格的 schema 定义成了重中之重。
2. 完美的软件契约：日志 (Logging) 与 链路追踪 (Tracing)
- 以前：日志往往是“出了 bug 才去捞一下”的口头禅，很多开发者的日志写得极其随意（例如 log.info("process success")），甚至链路追踪（Trace ID）也只是在大型微服务中才勉强推行。
- 现在：日志不仅是给人看的，更是给 AI 看的，如果一个系统没有标准的 OpenTelemetry 链路、没有结构化的异常上下文，AI 程序员在帮你修 Bug 或自动重试时就会变成“瞎子”，导致它不断生成错误的修复代码，陷入死循环，后端日志和监控的清晰度，直接决定了 AI 辅助运维和开发的效率上限。
3. API 接口的“机器可读性”
- 以前：写 Swagger / OpenAPI 文档是大家最讨厌的差事，很多开发者为了省事，字段描述（Description）直接留空，或者只写个 id: 用户id，只要前后端口头对齐了，文档烂点也能过。
- 现在：OpenAPI 文档成了 Agent 的必备“操作说明书”，Agent 是根据你接口的 description 来决定“什么时候该调用这个接口”以及“参数代表什么含义”的，如果你的文档描述模糊、没有写明业务边界，大模型就会频繁误调用，“文笔好、语义清晰”的接口文档，在 AI 时代直接等同于高可用性。
4. 极致的确定性隔离：状态机与幂等性
- 以前：网络抖动导致用户多点了一次按钮，大不了返回一个“请勿重复提交”，很多复杂的分布式事务和幂等控制，在非核心业务里经常被敷衍过去。
- 现在：AI 在执行任务（如自动帮用户订机票、转账、改数据）时，由于网络延迟或模型思考超时，极大概率会触发自动重试机制，AI 的重试行为比人类频繁和盲目得多，如果后端的分布式锁、状态机推进、以及接口幂等性没有做到 100% 的滴水不漏，系统就会瞬间产生大量重复订单或脏数据，现在是需要确定性的后端架构设计对抗 Agent 的非确定运行。
5. 高度抽象的领域驱动设计 (DDD) 与架构整洁度
- 以前：很多人觉得 DDD（领域驱动设计）太重、太务虚，为了快，习惯把所有业务逻辑都堆在 Service 层甚至 Controller 层，代码虽然像“面条”一样缠绕，但人类靠着记忆力还能勉强维护。
- 现在：这种“面条代码”成了 AI 的噩梦，AI 的上下文窗口（Context Window）是有限的，且它的推理成本随着代码量增加而暴增，如果你的代码耦合度极高，AI 修改一个地方就会导致别的地方崩溃，只有那些边界清晰、职责单一、符合 SOLID 原则的干净架构，AI 才能精准、低成本地进行重构和扩展。
6. 代码 Review 是一方面，自动化验证才是 Harness 工程
- 以前：Review 的时间大多耗在格式、命名、拼写、有没有漏掉判空上。代码是人一行行写的，量有限，这些低级问题也还盯得住。验证大多停在“有没有补一个测试”，人审过了，这轮就算结束。
- 现在：Cursor、Claude Code、GitHub Copilot 可以很快吐出成百上千行代码。格式和判空交给 Pre-commit、Linter，以及先用模型审一轮。人仍然要看业务意图有没有理解错、大并发下会不会死锁、新引入的库有没有漏洞。生成出来的代码常常注释完整、测试也配套，却可能在调用一个不存在的 API，或者在很隐蔽的边界上踩出竞态，这种看着能合进去的代码，最容易被放过去。Review 这一层还要留着，但它撑不住 Agent 的产出速度。
人审代码的标准还是要自己有，几本旧书仍然值得读：
- 《软件工程面向谷歌的实践》（Software Engineering at Google）：第 18–20 章讲 Code Review，包括什么样的 PR 算过关、质量和速度怎么平衡、Review 怎么在团队里变成习惯。
- 《软件设计的哲学》（A Philosophy of Software Design，John Ousterhout）：怎么认出代码里的复杂性，以及 Review 时怎么判断模块够不够深、接口够不够简单，模型很容易把实现写复杂，这本书刚好对着这个问题。
- 《编写可读代码的艺术》（The Art of Readable Code）：读不懂的代码，人维护不了，后面的模型也维护不了，用同一套可读性标准去要求生成的代码，仓库才不会很快烂掉。
另外 Harness 里我觉得最重要的是自动化验证，一次 Agent 执行要能在环境里跑完，留下 trace，用测试、契约和检查器判定结果对不对、路径偏没偏，失败要能归因，再回流成下一轮的反馈。
