AI编程新范式：Code Mode如何保障可扩展软件设计

过去大部分 AI 编程教程都在教“如何让 AI 写出能跑的代码”但真正放到团队协作和长期迭代里我们遇到的痛点往往不是“能否运行”而是“这次加一个新功能为什么其他模块也被带崩了为什么代码越来越难改”。在 Dex Horthy 发布的 AI That Works 第 72 期内容中核心话题转向了一个很务实的实践方向Code Mode 如何服务于可扩展软件。这已经不是单纯让 AI 生成函数而是把 AI 当作能深入到代码结构、模块边界、接口约束和人机协作流程中的工程工具。这篇文章我不打算替你复述第 72 期的节目内容而是结合这期的主题完整拆解 Code Mode 是什么、为什么它与“可扩展软件”高度匹配以及怎么用一套最小可运行项目来落地这类思路。1. Code Mode 到底是什么1.1 一个能改代码而不是只聊代码的AI工作模式我们先从最直观的体验切入。很多开发者第一次用 AI 编程助手时使用的是对话窗口。你可以问它“这段代码哪里有问题”“帮我解释一下某个函数”它也能给出答案。但如果你希望它“直接修改本地的 3 个文件并把接口调用方全部同步改掉”普通对话模式往往会显得很吃力。它更像一个知识顾问而不是和你并肩开发的协作者。Code Mode 是当前不少 AI 编程工具中出现的一种运行模式。进入该模式后AI 不再只处理自然语言对话而是会获得读取工程目录、检索文件、分析源码、执行命令、生成代码甚至自动补全测试的权限。你可以理解为AI 从一个“问答机器人”切换成了“驻场开发者”。当然不同产品的 Code Mode 实现方式并不一样。有些工具把它设计成一个专门的 Agent有些把它作为 IDE 插件的内置能力还有些把它与命令行工具绑定。但核心理念是一致的强调上下文从“聊天片段”变成“整个代码仓库”。输出从“代码片段”变成“可落地的改动”。反馈从“人工手动验证”变成“AI 主动运行测试或命令”。这篇文章里我们讨论的 Code Mode主要取其工程理念不限制在某个特定工具上。1.2 从对话式 AI 到工程式 AI如果我们把 AI 编程能力的发展粗略分几个阶段会更容易看清 Code Mode 的作用点。早期阶段AI 主要做“代码解释”和“代码生成”。开发者在网页或插件里输入题目AI 返回一段结果。这种方式适合算法练习和零散脚本但很难支撑多文件工程。后来出现“自动补全”和“AI 结对编程”。AI 可以基于当前文件、当前项目风格预测你下一个函数怎么写。它能提升打字效率但对一个模块该怎么拆分、一个公共接口要不要保留它并不真正参与决策。再往后就是“代理式开发”或者说 Agent 形态。AI 可以自己读取项目状态设计改造方案执行代码修改跑测试再根据反馈修复。Code Mode 正是这种形态在编程环节的集中体现。它和普通对话式 AI 最明显的区别在于有没有“工程上下文”。普通模式里AI 只能看到你复制给它的那几段代码而 Code Mode 可以基于文件树、源码索引、编译日志、测试结果形成对项目更完整的理解。对于可扩展软件设计来说这种全项目视野至关重要。原因很简单可扩展性从来不是某个函数写得漂亮而是整体结构经得起新增需求的压力。1.3 为什么 Code Mode 天然适合可扩展软件“可扩展软件”这个词在不同语境下有不同的含义。在架构层面它可能指系统能支持更高的并发量即 Scale Up / Scale Out但在代码结构层面它通常指我们能以较低成本增加新功能、新模块、新策略而不用大幅重写已有代码也就是所谓的 Extensible / Maintainable。Code Mode 要解决的恰恰是这种“结构层面的可扩展性”。当 AI 能读取完整的工程结构时它能比普通对话更精准地判断一个新增能力应该放在哪个模块、应该继承哪个基类、需要实现哪些接口方法、会不会破坏现有调用方。这种能力直接决定了 AI 是帮你扩容代码还是帮你的项目制造新的偶发复杂度。如果把软件开发比作装修房子普通对话模式像“你描述一个柜子AI 给你画一张柜子图”而 Code Mode 则像“AI 进入房子内部测量了墙体结构、水电管线再决定柜子应该挂在哪面墙上”。显然如果你想打造一套能长期演进的可扩展系统后者才是更有价值的工作方式。2. 可扩展软件最怕的不是技术而是结构腐化2.1 如何判断系统是否真正可扩展关于可扩展性很多团队有一个误区只要用了微服务、用了插件架构、用了设计模式就认为自己做了可扩展设计。但从工程实践角度看判断标准其实非常朴素。我们可以自己问三个问题新加一个业务能力时需要修改几个旧文件旧模块的修改是否会引发新模块的故障新人接手代码后能否快速找到扩展点如果答案不太理想——比如每加一个功能都要改十几个地方改完 Redis 缓存又影响了下游的定时任务——那么无论系统用了多时髦的架构它的实际结构可扩展性都很差。可扩展软件追求的理想状态是“对扩展开放对修改关闭”。新增行为通过新增代码完成而不是反复改动经过验证的旧逻辑。这种设计能降低回归风险也让多人并行开发成为可能。2.2 AI 参与开发后代码腐化速度反而可能加快这可能是最近一两年 AI 编程落地中最容易被忽视的问题。在引入 AI 之前团队里至少还有“人的惰性”在阻止代码无限膨胀。虽然有经验的开发者也会写出耦合严重的代码但他们会下意识地照顾可读性维护模块边界。而 AI 生成代码的模式是概率式的你给它一个指令它根据训练数据中最常见的写法返回结果。如果项目自身上下文不足没有严格约束它更倾向于生成“一次性但能跑”的代码而不是“结构更优但需要更多文件改动”的设计。举例来说如果你让 AI 增加一个第三方登录渠道它可能会直接在原有的 login 方法里加 if-else而不是先抽象出一个第三方授权接口。在小规模项目里这种写法没什么问题但当接入超过 5 个渠道时这个方法的复杂度会指数上升任何一个小调整都可能牵动所有登录逻辑。这背后的问题不是 AI 不够聪明而是我们缺少一种让 AI 遵循结构约束的工作模式。这正好对应了“Code Mode”存在的价值。2.3 用 Code Mode 反推 AI 遵守边界Code Mode 并不只是一个权限开关注定了解锁内容它也能让 AI 在动手前先“走查结构”。合理的设计应该是这样的当我们打算让 AI 新增一个模块时先不急着喊“帮我把功能写出来”而是给出当前项目的模块边界写明新增模块应该注册到哪里、遵循什么接口规范、改动范围限制在哪个目录。Code Mode 在读取这些约束后会更有机会生成符合预期的代码。这才是将 AI 用于可扩展软件建设的正确姿势——把人的架构决策前置把 AI 的限制执行后置。说得更直接一点可扩展软件的开发模式正在从“人写架构 人写代码”转向“人定架构 AI 大量实现代码 人 Review 边界”。Code Mode 是这个工作流的核心载体。3. 在 Code Mode 下做可扩展设计的常见套路3.1 先给 AI 一张“当前架构上下文图”如果你让一个不熟悉项目的新人直接修改代码你会给他讲解项目背景。同理使用 Code Mode 时团队也应当准备一份“可给 AI 读的架构说明”。这个文件不必写得非常文学化反而应该像接口文档一样清晰。下面的内容是一个常见的最小结构示意# 项目标记与扩展约束 ## 1. 项目定位 这是一个基于 Python 的批量文档处理框架输入为 JSON 文本 输出为结构化结果。 ## 2. 模块边界 - core/: 公共模型、接口定义、扩展注册逻辑 - plugins/: 具体解析器只允许通过注册器接入 - runner/: 负责任务编排与执行不绑定具体解析器 ## 3. 新增解析器的约束 - 必须实现 ParserInterface 中的 parse 方法。 - 不允许修改 runner/ 中的调度代码。 - 返回对象必须为 ParseResult。当 Code Mode 读取到这个文件后它的修改范围与生成策略都会受到引导。实际项目里这种文件不需要放在正式代码运行链路上但非常建议纳入版本库并放在 docs/architecture/ 目录下。AI Agent 具备读取项目文件的能力后它会自动找到这些约束。3.2 用接口和注册机制约束 AI 生成插件要让 AI 的产出具备可扩展性光靠口头约束不够必须提供结构性约束。最常用的方式就是“顶层接口 注册机制”。核心思路是业务逻辑不直接依赖某个具体实现而是依赖接口新增能力通过实现接口并注册来完成主流程只面向接口编程。后续的实战案例会详细展示这种写法。这里先说明一点它为什么适合 Code Mode 下的 AI 协作接口定义了方法签名AI 不容易“自由发挥”。注册机制明确了扩展入口AI 知道新增代码的挂载点。主流程与具体实现隔离AI 散落在各插件里的代码不会直接污染核心模块。3.3 让 AI 在每一次改动前回答高价值问题在引入 Code Mode 时我建议团队总结一套“AI 改动自查清单”并在任务描述或系统提示中写入。不一定每次都能 100% 遵守但会显著提升产出质量。一套很轻量的自查问题如下本次改动影响了哪些模块是否需要新增接口还是修改现有接口是否为了新需求修改了不该碰的旧类如果面临“改旧代码”和“新增子类/插件”两种选择选了哪个测试覆盖了哪些扩展场景当 AI 能基于项目文件树回答这些问题时它其实已经在用一个“可扩展软件工程师”的思路去处理任务了。4. 一个最小可运行示例搭建可扩展的插件化应用下面我们进入实战环节。为了避免陷入空泛的概念讨论我会构造一个小项目并通过类似 Code Mode 的任务描述实现一个插件化、可扩展的文本处理器。虽然我们不会在文章里真的调用某个具体 AI 工具但所有任务描述都可以直接“搬运”到支持 Code Mode 的 AI 工具中使用。4.1 项目需求与分析我们要实现一个文本处理框架它满足以下要求支持多种处理策略比如去除空白字符、统计词频、过滤敏感词。新增一种处理策略时不允许修改主流程。所有策略通过插件注册机制接入。可以通过命令行参数指定执行哪些策略。在这个需求里“处理策略”就是扩展点。我们把每种策略独立成插件主程序只负责加载插件并执行。项目结构设计如下text_processor/ ├── core/ │ ├── __init__.py │ ├── base.py │ └── registry.py ├── plugins/ │ ├── __init__.py │ ├── strip_plugin.py │ ├── word_count_plugin.py │ └── bad_word_plugin.py ├── main.py └── requirements.txt4.2 定义顶层接口第一步是写清楚“插件是什么、要做什么”。在很多可扩展框架里这一步最重要因为它是所有插件必须遵循的契约。代码如下# 文件路径text_processor/core/base.py from abc import ABC, abstractmethod class TextPlugin(ABC): 文本处理插件基类。 所有插件必须实现 name 和 process 方法。 property abstractmethod def name(self) - str: 返回插件唯一名称比如 strip、word_count。 abstractmethod def process(self, text: str) - str: 处理文本并返回结果。 参数 text: 原始文本。 返回值: 处理完成后的文本。 这里注意几点一我们使用 ABC 抽象基类强制子类实现 name 与 process。二name 字段会在注册和运行时作为插件标识使用。三process 统一返回字符串。这样主流程不需要了解子类内部逻辑拿到结果后统一打印即可。4.3 实现插件注册机制可扩展系统的核心通常不是插件本身而是负责发现和存储插件的“注册中心”。它解决了两个问题插件在哪儿、主流程如何拿到插件实例。注册中心代码如下# 文件路径text_processor/core/registry.py from typing import Dict, Type from core.base import TextPlugin class PluginRegistry: 插件注册中心。 使用方式: registry PluginRegistry() registry.register(StripPlugin) def __init__(self) - None: self._plugins: Dict[str, Type[TextPlugin]] {} def register(self, plugin_cls: Type[TextPlugin]) - None: 注册插件类。 这里只做两步操作 1. 实例化插件用于获取插件名。 2. 将插件类放入私有字典。 注意实例化只是为了拿 name也可以在后续运行时再实例化。 instance plugin_cls() name instance.name if name in self._plugins: raise ValueError(f插件 name 重复: {name}) self._plugins[name] plugin_cls def get_plugin(self, name: str) - TextPlugin: 根据插件名获取插件实例。 plugin_cls self._plugins.get(name) if plugin_cls is None: raise KeyError(f找不到插件: {name}) return plugin_cls() def available_names(self) - list[str]: 返回所有已注册插件名。 return list(self._plugins.keys())注册中心的设计决定了扩展是否方便。在这个实现中新增插件时只需要注册一个类主流程完全不需要改动。如果后续插件需要携带配置项我们也可以把初始化参数接进来但必须保持 register 接口稳定。4.4 实现三个具体插件有了接口和注册中心剩下的就是新增插件。这是“对扩展开放”最直接的体现。第一个插件实现简单的空白字符清理# 文件路径text_processor/plugins/strip_plugin.py from core.base import TextPlugin class StripPlugin(TextPlugin): property def name(self) - str: return strip def process(self, text: str) - str: return .join(text.split())第二个插件实现单词计数并将其格式化到结果文本中# 文件路径text_processor/plugins/word_count_plugin.py from collections import Counter from core.base import TextPlugin class WordCountPlugin(TextPlugin): property def name(self) - str: return word_count def process(self, text: str) - str: words text.split() counter Counter(words) result \n.join([f{word}: {count} for word, count in counter.items()]) return result第三个插件模拟“敏感词过滤”把指定词替换为星号# 文件路径text_processor/plugins/bad_word_plugin.py from core.base import TextPlugin class BadWordPlugin(TextPlugin): property def name(self) - str: return bad_word def process(self, text: str) - str: bad_words [error, exception] for word in bad_words: text text.replace(word, ***) return text你可能会问这三个插件实现逻辑都很简单真实项目里哪会这么容易确实真实插件的业务逻辑会复杂得多但可扩展设计带来的收益恰恰是无论插件的内部逻辑有多复杂它对主流程暴露出来的接口是稳定的。只要实现 class 并注册系统就能无缝加载。4.5 修改插件包的init为了让后续的 auto_import 和插件加载更简单我们把所有插件在 plugins/init.py 中统一导入并注册。这个文件同时也是一个“扩展入口”。当我们新增插件时在此处追加一行即可。# 文件路径text_processor/plugins/__init__.py from core.registry import PluginRegistry from plugins.strip_plugin import StripPlugin from plugins.word_count_plugin import WordCountPlugin from plugins.bad_word_plugin import BadWordPlugin def setup_registry() - PluginRegistry: registry PluginRegistry() registry.register(StripPlugin) registry.register(WordCountPlugin) registry.register(BadWordPlugin) return registry这个 setup_registry 函数可以理解为“装配根”。它不是运行时业务逻辑的一部分但负责把各个独立模块合到一起这也是可扩展系统里常见的“组合根”概念。4.6 编写主程序主程序只做三件事从插件目录完成注册。接收命令行参数中的插件名与待处理文本。按顺序执行插件。这里为了让代码易读我们不引入过多 CLI 框架直接通过 Python 的 sys.argv 读取入参。# 文件路径text_processor/main.py import sys from plugins import setup_registry def main() - None: registry setup_registry() if len(sys.argv) 3: print(用法: python main.py plugin_name1,plugin_name2 \text\) print(可选插件:, , .join(registry.available_names())) sys.exit(1) plugin_names sys.argv[1].split(,) text sys.argv[2] print(原始文本:, text) print( * 50) for plugin_name in plugin_names: try: plugin registry.get_plugin(plugin_name) except KeyError as exc: print(f[跳过] 插件不存在: {exc}) continue print(f执行插件: {plugin_name}) result plugin.process(text) print(result) print(- * 50) if __name__ __main__: main()4.7 运行项目并验证扩展效果在动手运行前需要确认当前终端能导入 core 与 plugins 包。最简单的方式是在项目根目录 text_processor/ 下执行命令因为 main.py 本身位于根目录。先运行单个插件cd text_processor python main.py strip hello world python预期输出原始文本: hello world python 执行插件: strip hello world python --------------------------------------------------再运行多个插件组合python main.py strip,bad_word,word_count some error message error exception case预期输出原始文本: some error message error exception case 执行插件: strip some error message error exception case -------------------------------------------------- 执行插件: bad_word some *** message *** *** case -------------------------------------------------- 执行插件: word_count some: 1 ...: 2 message: 1 case: 1从运行结果可以看出主流程没有直接依赖任何一个具体插件。想要增加第五个插件只需要实现 TextPlugin 接口并在 plugins/init.py 的 setup_registry 中注册即可。这和我们前面讲到的“对扩展开放、对修改关闭”是一致的。4.8 如果让 Code Mode 生成这个功能这个项目的代码全部写好之后你可以把任务描述给 AI 工具让它通过 Code Mode 自动扩展更多插件。任务描述可以设计成类似这样项目背景 项目根目录下是一个 text_processor 框架采用插件化设计。 - core/base.py 定义 TextPlugin 接口。 - plugins/__init__.py 的 setup_registry 负责注册所有插件。 - main.py 按插件名顺序执行处理。 任务 实现一个 MarkdownHeadingPlugin 插件功能是把类似 # 标题 的行提取出来并按行输出。 同时需要在 setup_registry 中注册该插件。 扩展约束 1. 不允许修改 core/base.py。 2. 不允许修改 main.py 的流程。 3. 新增代码放在 plugins/ 目录中。 4. 请先阅读 core/base.py 了解接口签名。这段任务描述体现了一个很好的 Code Mode 协作模式由人确定组件边界和修改范围由 AI 在固定范围内完成实现。这样即使 AI 对业务理解不够深入也不太容易把代码写到错误层级。5. 在 Code Mode 下开发可扩展模块的常见问题将 Code Mode 与可扩展软件开发结合并不是一个“开启开关即成功”的过程。很多问题会出现在实际工程里下面整理一些高频问题以及应对思路。问题现象常见原因排查思路AI 总是把代码写进主模块没有在任务描述中明确指定扩展目录和禁止改动文件Code Mode 对话中优先提供目录树、架构说明和禁止触碰的模块清单插件扩展后接口签名发生变化早期没有冻结公共接口所有对外接口必须先评审必须修改时同步更新所有实现与调用方AI 生成的插件没有实现完整方法抽象接口定义不严格或 AI 没读取 base 文件使用 ABC 并声明抽象方法任务中追加“实现所有抽象方法”插件 name 重复导致注册失败注册中心缺少去重提示在注册中心中给出清晰错误信息并在 README 中写明命名规范AI 为了“省事”直接修改旧类项目缺少“优先新增”的扩展引导在架构文档中写明设计原则宁可新增一个插件类也不要改旧类Code Mode 执行命令修改了环境权限过大没有限定工作区尽量在受控测试环境中运行避免直接对生产数据库或公共依赖执行破坏性命令新增插件后主程序无法导入plugins 包的init.py 未同步更新需要维护好“组合根”文件或采用自动扫描注册机制针对表格里几个重点问题再展开细说。先看“AI 总是把代码写进主模块”。这是集成 Code Mode 后最常见的问题。根本原因不是 AI 不遵循指令而是普通任务描述不够明确。你只说“增加一个格式化插件”它完全有可能在 main.py 里加一个 if 分支。解决思路是任务描述需要像写用户故事一样写清边界。例如“只新建 plugins/xxx.py并在 plugins/init.py 的 setup_registry 中注册”。再看“插件 name 重复导致注册失败”。在插件化框架里这种问题越早暴露越好。注册中心要能快速报错否则两个插件同名会静默覆盖。生产级方案还会把插件名和版本号结合起来但小型项目先保证唯一性即可。关键是在设计阶段就约定命名规则可以要求 AI 采用“模块名_动作”的格式减少冲突概率。还有一个容易被忽略的问题是“Code Mode 修改了不该动的配置文件”。当 AI 拥有读写权限后它可能会顺手格式化你的 requirements.txt甚至调整 IDE 配置。针对这个问题建议团队目录结构里做好区分代码、配置、脚本、文档分开并在 AI 的任务说明中强调只允许改动某个模块目录。6. 可扩展软件开发的工程级建议插件化示例只是结构上的演示真正把可扩展软件开发用于生产还需要关注下面几个层面的工程实践。6.1 通过目录约束减少 AI 的暴力修改可扩展系统最理想的状态是“新功能带来新目录、新文件而不是修改旧目录”。我在团队中比较推荐的做法是在仓库根目录的 AGENTS.md 或类似上下文文件中写清楚各目录的改动策略。示例内容# 各目录开发约定 - api/允许修改但必须保持路由前缀兼容。 - core/只允许新增模块级代码禁止修改经过冻结的稳定接口。 - plugins/允许自由新增插件但插件必须实现基类接口。 - tests/任何新增功能必须补充对应的 test_ 文件。 - scripts/不建议修改如有需要先找维护者对齐。这种约定既服务于人类开发者也服务于 Code Mode。只要 AI 工具能读取项目文件它就会把这些约束当作隐性上下文从而减少越界修改。6.2 让 AI 写插件之前先让它写测试很多 AI 生成的代码能通过语法检查却经不起边界条件考验。原因在于 AI 没有自动验证逻辑是否正确也没有跑完备的测试。如果我们希望 AI 实现可扩展模块可以刻意调整任务顺序让它先定义测试再实现业务代码。任务描述可以这样写请为一个文本插件编写测试用例 1. 至少覆盖空字符串输入。 2. 至少覆盖中文和英文混排。 3. 至少覆盖极端长度文本10000字符。 4. 测试先写随后实现满足测试的插件代码。这样 Code Mode 就不是直接生成一段看起来合理的代码而是先“锚定验收标准”再围绕标准去实现。对于可扩展系统来说这一点尤其重要因为插件最终会被插入大型流程质量问题会被放大。6.3 统一错误处理与日志追踪插件是独立开发的但运行在统一主流程里。如果每个插件对错误的处理方式不一致系统的可维护性会急剧下降。建议在接口设计阶段就规定清楚插件内部发现业务问题时应该抛出自定义异常还是返回特殊标记插件出现未捕获异常时主流程是继续执行后续插件还是终止每个插件的执行耗时、输入摘要、输出摘要是否写入日志在一个比较严肃的生产框架里接口定义可能不会像 demo 那样简单返回字符串而会返回一个上下文对象并在该对象中携带处理状态、日志、耗时等信息。6.4 控制扩展机制的复杂度可扩展设计很容易走向反面——过度抽象。常见表现是系统里大量使用动态代理、反射注册、事件总线、SPI 扫描。每新增一个小功能都要经过“定义接口 - 实现子类 - 自动装配 - 配置开关 - 监听回调”五道工序。这种设计表面看起来非常“可扩展”但实际学习成本极高而且排错困难。在 Code Mode 引入之后这个问题可能更加明显因为 AI 会按照设计模式惯用法生成复杂框架。但我们要时刻记住可扩展性不是越抽象越好而是让“最常见的扩展动作”变得足够简单。对大多数中后台项目来说新增一个模块类并注册已经足够。如果连类都不需要新增只需要通过配置切换行为那就应该使用配置驱动而不是引入插件系统。动手设计前先问一句当前可预见的扩展点是哪些这些点变化的频率有多高动态插件机制只有在扩展点频繁新增时才值得投入。6.5 为 AI 的修改设置隔离环境既然 Code Mode 允许 AI 执行命令、修改文件团队就应该为它设置类似“沙箱”的运行空间。这块不是限制发挥而是保护业务稳定性。更安全的实践方案是把 AI 的改动提交到临时 feature 分支通过 CI 运行全部单测、接口测试、代码规范检查再人工审查 diff。人工审查时应特别关注一个点AI 是否在解决一个小问题时悄悄改动了大量无关文件。如果把这类大而全的修改和不加验证地直接合并所谓可扩展架构也会很快腐化。7. 总结与上手建议回到开头提到的主题最让我觉得有价值的核心理念是AI 参与编程不该只停留在“生成片段”的层面而应该成为一种理解工程、维护边界、帮忙实现结构性重构的协作能力。Code Mode 给了 AI 这把钥匙但它能否真正服务于可扩展软件仍然取决于我们如何设计上下文、如何约束目录边界、如何定义扩展接口。至少从我自己落地这套流程的经验来看有几个非常见效的起步点值得分享给读者。第一如果你是从零开始做一个小项目不要急着写业务代码。先把项目目录结构、核心接口文件、注册机制搭出来。这样你在后续任何一次使用 Code Mode 时都能给它一个有明确扩展入口的代码库。第二如果你是负责老项目的开发者则可以先从“新增能力”开始尝试。挑一个不会影响核心链路的新功能口头约束 AI“只新增文件、不修改旧逻辑”并准备好代码审查清单。只要跑通几次这套工作流就会越来越顺手。第三如果你们团队正在考虑全面引入 AI Agent建议先在架构文档层面统一一份“可扩展开发协议”。比如“核心接口允许新增实现类不允许随意修改核心类接入新能力先搜索是否已有扩展点”。给 AI 制定边界其实也是给团队制定结构纪律。第四也是最实在的一点多在真实迭代中练习。因为可扩展性是一个通过“演进”才能证实的东西。你不需要一开始就规划出一个完美无瑕的插件宇宙只需要保证每一次新增功能时代码的改动面都比预期更小边界更清晰那么系统就会慢慢走向可扩展。进一步的学习方向上你可以继续探索这几个主题模块化架构中的依赖倒置原则、领域驱动设计中聚合与限界上下文的划分、ServiceLoader 与插件机制的底层实现、以及如何为 AI Agent 设计更严格的仓库上下文。这些主题和本文内容互相补充能帮你把“可扩展软件”从一个口号变成可执行、可落地、可长期维护的工程标准。Code Mode 仅仅是工具形态上的变化真正决定系统命运的仍然是我们对软件边界和演化方式的把控能力。