微服务的麻烦，不在“微”，而在“彼此有关”。一个服务改了字段名，另一个服务的调用就可能坏；一个接口多了鉴权，前端、测试、文档都要跟着变。过去我们靠会议、接口文档和人工记忆来同步这些变化。AI 进来以后，问题变成：能不能让工具同时看见这些相互依赖的部分？
微服务，就是把一个大系统拆成许多小服务，每个服务负责一块功能，通过接口互相通信。它的好处是团队能分开开发，坏处是接口一变，很多地方都要跟着动。
大白话说：微服务像一组分工明确的小店。每家店独立经营，但菜单、送货和收银规则一改，隔壁店也会受影响。
旧边界：一个仓库一个世界
传统开发工具常常把一个代码仓库当作一个世界。打开 A 仓库，就改 A；打开 B 仓库，就改 B。这个边界对人很方便，因为团队、权限、部署通常也是按仓库分的。但对一次跨服务修改来说，它可能是错的边界。
比如订单服务把 userId 改成 accountId，支付服务、数据同步任务、管理后台都要跟着调整。如果 AI 只能看到订单服务，它也许能把本仓库改得很漂亮，却不知道外面已经坏了。你再让它打开另一个仓库，它又缺少刚才修改的完整上下文。
这不是模型不聪明，而是它看到的世界被切碎了。上下文的边界决定了它能推理的边界。
新边界：一次变更一个世界
如果把相关仓库放在同一个工作目录，情况就变了。AI 可以同时搜索字段名、接口定义、调用方、测试和文档。它能看到“这里改了，那里也要改”。这时候真正的边界不再是仓库，而是一次变更影响到的范围。
工作目录，就是工具当前能读取和修改的文件范围。过去它常常等同于一个项目；在 AI 协作里，它更应该围绕“要解决的问题”来组织。
这不是鼓励把所有代码都扔进一个大坑。权限、性能和噪音仍然要控制。关键是你要知道边界是人为设置的，可以按任务调整。要改一个局部函数，给一个仓库就够；要改跨服务协议，就应该让工具看见协议两端。
同步修改的本质是降低来回成本
跨服务修改最贵的不是敲代码，而是来回确认。A 服务改完，B 服务报错；B 服务补完，测试环境又发现文档没更新；文档改完，客户端 SDK 又漏了字段。每一次来回都在消耗人的注意力。
当 AI 同时看到多个相关项目，它能把这些来回压缩到一次修改里：先找影响面，再改调用链，再跑测试，再根据错误继续补。这就是“懂下一层”带来的现实收益。你不是让 AI 更神，而是给了它更完整的可观察范围。
这里的基础知识包括文件系统、文本搜索、依赖关系、接口契约和测试反馈。它们听起来都不炫，但正是这些东西决定 AI 能不能从“写一段代码”升级为“完成一次变更”。基础越扎实，你越会给 AI 布置一个真实可完成的工作现场。