夜雨聆风
过去两年，很多团队对 AI Coding 的理解还停留在“帮我写几行代码”“补一个单测”“解释一下这个函数”。
这当然有价值，但我越来越觉得，这只是第一阶段。
真正的变化不是 AI 会不会写代码，而是：当 AI Agent 开始进入研发流程，甚至能够持续执行需求拆解、代码修改、测试验证、故障定位和变更总结时，我们的后端系统是否准备好了？
很多系统其实没有准备好。
它们对人类老员工是可维护的，对新人是半可维护的，但对 AI 来说，可能是高度不友好的。因为太多关键知识不在代码里，也不在文档里，而在人的脑子里、群聊里、历史事故复盘里、某个资深同学的经验判断里。
这就是后端架构下一阶段要面对的问题：系统不只要 Human Friendly，还要 AI Friendly。
AI Friendly 不是补一份 README
我不认为 AI Friendly 等于“文档写完整一点”。
这太轻了。
真正的 AI Friendly，是让 AI Agent 在有限上下文、有限权限、有限试错成本下，仍然能够理解系统边界、判断风险、修改代码、验证结果，并知道什么时候应该停下来交给人。
换句话说，过去我们建设的是“人类可维护系统”。
接下来要建设的是“智能体可维护系统”。
这件事对后端尤其重要。因为后端系统的复杂度从来不只在代码里。它在服务拓扑里，在数据所有权里，在接口兼容里，在异步消息里，在灰度策略里，在历史包袱里，也在那些“千万不能这么改”的业务不变量里。
AI 如果只能看到一个代码仓库，它就很容易做出局部正确、全局错误的修改。
比如，把应该放在 BFF 层的兼容逻辑塞进核心领域服务；把原本可以异步解耦的链路改成同步 RPC；看到一个表能查，就以为这个服务有权写；看到一个接口还存在，就以为它是推荐使用的新接口。
这些错误不是模型不聪明，而是系统没有把关键事实显式告诉它。
第一件事：把系统事实变成机器可读资产
技术组织过去沉淀了大量“经验资产”，但这些资产很多是人读的，不是机器读的。
AI Friendly 的第一步，是把这些经验变成结构化、可检索、可验证的系统事实。
我建议至少从六类事实开始。
第一类是架构事实。
AI 需要知道系统有哪些业务域，哪些服务属于核心链路，哪些是支撑系统，哪些是历史遗留模块，哪些服务可以承载新需求，哪些服务只应该维护不再扩展。
没有这张地图，AI 只能在局部代码里猜。
第二类是服务事实。
每个服务都应该有一张 Service Card，说明它的职责、上游、下游、数据库、缓存、消息、定时任务、外部依赖、负责人、发布方式、降级方式和告警入口。
这不是给新人看的欢迎文档，而是给 Agent 执行任务前装载上下文用的“服务身份证”。
第三类是领域事实。
后端系统最危险的地方，往往不是技术，而是业务不变量。
订单能不能从已取消回到已支付？支付成功后能不能重复扣款？库存扣减和订单确认之间如何补偿？会员权益是否允许跨租户共享？
这些东西如果不显式化，AI 写出来的代码可能语法正确、单测通过，但业务上是错的。
第四类是接口事实。
接口文档不应该只写 URL、参数和返回值。它还应该说明调用方是谁，是否幂等，能否重试，超时时间是多少，错误码如何解释，字段是否有兼容约束，移动端老版本是否还依赖某个行为。
第五类是数据事实。
表结构、字段含义、索引、枚举、唯一约束、分库分表规则、冷热数据策略、敏感字段、归档逻辑，这些都应该让 AI 能查到。
尤其是 status、type、source 这类字段，不写清楚就是在诱导 AI 猜。
第六类是运行事实。
AI 不能只看静态代码。它还要知道这个接口 QPS 多高、TP99 多大、错误率是否异常、是不是核心链路、最近是否发生过事故、哪个 consumer lag 经常上涨、哪个 Redis key 是热点。
静态代码告诉 AI“系统长什么样”。
运行事实告诉 AI“系统现在怎么样”。
第二件事：给 AI 一张真正可用的 Architecture Map
很多团队都有架构图，但通常是 PPT 里的图。
它可能在新人培训时出现一次，然后就再也没人维护。服务改了、链路变了、消息 topic 换了、数据库拆了，图还停留在两年前。
这对人类已经不太友好，对 AI 更是危险。
AI Friendly 的 Architecture Map 必须进入工程流程。它不是展示材料，而是系统事实的一部分。
它至少要回答几个问题。
哪些服务属于同一个业务域？哪些链路是核心交易链路？哪些调用是强依赖？哪些可以降级？哪些数据只能由某个服务写？哪些消息是领域事件，哪些只是技术同步？哪些服务是战略方向，哪些服务是历史债务？
这张图的价值不是好看，而是约束。
当 AI 要改一个需求时，它应该先知道这个改动落在哪个业务域、涉及哪些服务、是否穿过核心链路、是否改变数据所有权、是否引入新的同步依赖。
没有 Architecture Map，AI 是在迷宫里写代码。
有了 Architecture Map，AI 至少知道自己站在哪里。
第三件事：把团队经验封装成可调用的 Skill
很多资深工程师的价值，不只是会写代码，而是知道“这个地方不能这么改”。
比如，加字段要先兼容写，再兼容读，再回填，再切流量，最后清理旧字段。
比如，支付链路里任何重试都要先确认幂等键。
比如，消息消费失败不能直接吞掉，要区分可重试、不可重试和需要人工介入的异常。
这些经验如果只存在于人脑里，AI 就只能靠通用工程常识去猜。
但通用常识不等于本公司、本系统、本业务的真实约束。
所以，AI Friendly 的组织应该把高频工程经验沉淀成 Skill。
这里的 Skill 不是一句 prompt，而是一组可执行的工作流：什么时候加载哪些上下文，改哪些文件前要检查什么，必须跑哪些测试，哪些指标异常时要停止，最终变更说明必须包含哪些风险。
这一步很关键。
因为它意味着组织知识从“靠人传授”变成“可被 Agent 调用”。
第四件事：给 Agent 修一条受控轨道
我对无人值守开发一直保持谨慎乐观。
乐观在于，Agent 的确会承担越来越多重复、繁琐、跨文件的工程任务。
谨慎在于，不能把生产系统直接交给一个“权限很大、上下文不完整、失败成本很高”的执行者。
AI Friendly 不是让 AI 拥有无限权限，而是给它一条受控轨道。
这条轨道可以理解成 Harness。
它负责上下文装载、工具选择、权限控制、命令执行、测试验证、风险判断、人工升级和变更记录。
一个成熟的后端 Harness 至少要有几层。
上下文层：根据任务自动加载相关 Service Card、领域模型、接口契约、数据库 schema、最近变更和事故记录，而不是把整个代码库粗暴塞进去。
工具层：给 Agent 提供代码搜索、依赖分析、日志查询、测试执行、接口探测、配置读取等能力。
权限层：区分只读、可改测试代码、可改业务代码、可触发灰度、可访问生产数据等不同级别。
验证层：每次修改必须经过编译、单测、集成测试、契约测试、回归用例或线上探测。
停止层：当 AI 无法确认数据语义、影响核心链路、权限不足、测试无法闭环时，必须停止并请求人类判断。
我认为，未来技术管理者真正要建设的，不是“让大家都用某个 AI 编程工具”。
而是建设一套让 AI 安全工作的工程基础设施。
第五件事：测试体系要从守门员变成红绿灯
很多团队过去对测试的态度是：重要，但可以以后补。
在 AI Coding 时代，这个态度会变得非常危险。
因为 AI 的开发速度越快，验证体系就越重要。没有测试门禁，AI 只是把不确定性更快地推向系统。
测试不再只是防止人类手滑，它会成为 AI 的行为约束。
单元测试告诉 AI 函数级行为有没有被破坏。
集成测试告诉 AI 服务协作有没有被破坏。
契约测试告诉 AI 接口兼容有没有被破坏。
回归测试告诉 AI 老业务流程有没有被破坏。
线上探测告诉 AI 真实环境是否符合预期。
对技术管理者来说，这里有一个很现实的判断：如果一个系统没有足够的自动化验证，它就不适合做深度 AI Coding。
最多适合让 AI 写辅助代码，不能让它参与关键链路改造。
测试覆盖率本身不是目标。
真正的目标是让系统有能力回答一句话：这个变更安全吗？
第六件事：可观测性要成为 AI 的眼睛
人类排障时会看日志、指标、链路追踪、告警、发布记录和用户反馈。
AI 也需要这些。
如果一个 Agent 只能读代码，不能看运行态，它就不可能完成真正的故障定位和自愈。
后端系统要 AI Friendly，可观测性就不能只是给 SRE 和研发同学看的大盘。它还要能被 AI 检索、理解和引用。
比如，一个接口最近 24 小时错误率是否上升？某次发布后 TP99 是否变差？某个异常日志是否集中在一个租户？某个消息堆积是否和下游限流有关？某个数据库慢查询是否和新索引缺失有关？
这些问题如果能被工具化回答，AI 才能从“写代码助手”进化为“工程协作者”。
否则它只能在黑暗里修改系统。
这也是为什么我不赞成把 AI Coding 单独看成 IDE 能力。
它最终一定会进入研发平台、发布平台、监控平台、日志平台和故障管理平台。
第七件事：权限治理不能事后再补
AI Friendly 不能以牺牲安全为代价。
尤其是后端系统，里面有真实用户数据、交易数据、权限数据、财务数据和生产配置。
如果让 AI Agent 进入工程流程，权限分级必须前置设计。
哪些仓库可以读？哪些文件可以改？哪些环境可以执行命令？哪些日志需要脱敏？哪些数据只能看聚合结果？哪些操作必须人工审批？哪些变更必须留下完整审计？
这些都不能靠“大家自觉”。
未来的 Agent 不是一个工具按钮，而是一个新的工程执行主体。
既然是执行主体，就必须有身份、权限、审计和责任边界。
我的建议是，早期可以从低风险任务开始：文档更新、测试补齐、非核心服务的小改动、日志增强、告警规则建议、代码解释和影响面分析。
等上下文、测试、权限、审计都成熟后，再逐步进入更深的自动化改造。
给技术管理者的三阶段路线
如果一个团队现在想做后端架构 AI Friendly，我不建议一上来搞宏大的平台。
更现实的路线，是分三阶段推进。
第一阶段是 Copilot。
这个阶段，AI 主要帮助人类写代码、解释代码、补测试、生成文档。团队要做的是统一代码规范、补齐基础 README、整理服务入口、明确测试命令。
目标不是自动化，而是先让 AI 在局部任务上有效。
第二阶段是 Coworker。
这个阶段，AI 可以参与需求拆解、影响面分析、跨文件修改、测试生成、变更说明和风险提示。
团队要开始建设 Architecture Map、Service Card、领域不变量文档、接口契约和测试门禁。
目标是让 AI 不只会写代码，还能理解任务上下文。
第三阶段是 Operator。
这个阶段，AI 可以在受控 Harness 中执行更完整的工程流程，包括自动定位问题、生成修复方案、提交变更、跑测试、解释风险，甚至在低风险场景中触发灰度和回滚建议。
但这不是“放手让 AI 干活”。
恰恰相反，它要求组织有更强的工程治理能力：权限分级、审计记录、自动化验证、可观测反馈、人工审批和事故止损机制。
AI 越自主，系统越要可治理。
这是技术管理者必须想清楚的一点。
最后：AI Friendly 改变的是组织沉淀知识的方式
我认为，后端架构 AI Friendly 最终不是一个技术概念，而是一个组织能力概念。
过去，一个强团队依赖资深工程师的经验、默契和长期积累。
未来，一个强团队要把这些经验变成结构化资产，让 AI 可以读取、调用、执行和验证。
过去，文档主要是给新人看的。
未来，文档也是给 Agent 装载上下文用的。
过去，测试是研发流程的最后一道门。
未来，测试会成为 AI 执行任务时持续参考的红绿灯。
过去，架构治理依赖评审会议。
未来，一部分治理规则会直接进入工具、CI、权限和自动化流程。
这不是说人不重要了。
恰恰相反，人会更重要。只是人的价值会从“亲手做每一个改动”，转向“定义系统边界、沉淀组织经验、设计验证机制、控制风险半径”。
AI Coding 时代，后端架构真正的分水岭，不是谁用了更强的模型。
而是谁先把系统建设成 AI 看得懂、改得动、验得住、管得住。
这件事，越早开始，复利越大。
