部分成立:AI 让“耦合”从代码模块之间转移到了 context 与工具之间,内聚的对象变成了喂给 AI 的那份上下文。
AI根据立正公开的文章和视频整理,不是他本人回复。重要的判断,请回到出处核对。
AI 把耦合点从模块搬到了 context
传统上高内聚低耦合说的是代码模块:一个模块内部职责集中,模块之间接口清晰、改动互不牵连。放到 AI 场景里,这个原则仍然成立,但耦合发生的位置变了。当 AI 通过调用工具、多步决策去介入业务流程时,真正决定它稳不稳的是它接进来的数据、工具和记忆怎么组织——分层管理、渐进式加载、持续提炼,让 AI 每次只拿到该拿的那部分,不多不少1。这其实就是把“低耦合”翻译成了:不要让所有 context 一股脑塞进去,也不要让某个环节的改动牵连整个系统。
内聚的对象是 context,不是模型
“高内聚”在 AI 里对应的不是把功能塞进一个模型,而是让同一件事的相关信息聚在一起、有明确归属。把 context 分成工作记忆、项目记忆、组织记忆三层,规定什么保留原始形态、什么提炼成精华、什么定期清理,本质就是在给 AI 划职责边界1。反过来,如果 context 散落各处、没有组织方式,AI 效果差往往不是模型不行,而是输入本身是乱的3。所以对 AI 来说,这条原则 make sense 的前提是:你确实在维护一份可被 AI 消费的 context,而不是每次临时拼 prompt。
复杂度要有理由,不是越分层越好
AI推演这条原则容易被误用成“架构越复杂越专业”。AI 架构的关键不是更复杂,而是复杂得有理由:如果任务高度结构化、单次模型调用就能完成,就不一定需要 agentic workflow4。同理,低耦合不等于把系统拆得越碎越好——拆到什么程度,取决于任务复杂度、延迟、成本和人类介入的需要4。判断标准是:这次拆分是否让某部分改动时不必动其他部分,是否让 AI 更容易找到它需要的那份 context。如果拆分只是增加了协调成本,那它没有带来低耦合的好处。
现有材料谈的是团队级 context 架构与 AI 产品分层,没有专门讨论“高内聚低耦合”这一软件工程术语本身,上面的对应是 AI 推演。
出处
- 1你团队的 AI 效果不好,问题不在模型,在 Context
讲 context 三层记忆、渐进式加载和规范注入,是理解 AI 场景下耦合点转移的核心材料。
- 2AI Agents的第一性原理定义|Define AI Agents
解释 agentic AI 的工具调用与多步决策,帮助理解耦合为何发生在工具与数据之间。
- 3AI Native 的组织形态:当执行成本下降,组织必须重写
说明 AI 效果差常出在 context 质量而非模型,适合核对“内聚对象是 context”这一判断。
- 4AI产品的六个层次
强调架构复杂要有理由、单次调用够用就不必上 agent,适合核对拆分边界。
你也有想问的?
卡住的时候,问问立正:回答只从立正讲过、写过的东西里来,每一段都能点回原文。
问类似的问题也可以接着问:
别人还问了
- 我现在遇到一个问题,就是国内使用 Claude 的限制(之前我一直在用 Claude,但是10/1的时候被封禁了)。
现在我主要用 codex,但是发现同样的 Harness 架构,codex 的效果其实没有那么好。我该怎么解决呢?
我也很针对性地找了很多解决方案,但中转站有点太贵了,没办法提供这么高的消耗量
把积累放在模型和 harness 之上,用同一套上下文与验收标准去跑 Codex,效果差距往往来自工作流而非工具本身。
- 换工作的时候,长期来看,考虑的优先级应该是什么
长期看,优先级是行业与增长空间、公司平台和业务、直属老板,最后才是薪资;薪资差距超过三成时才需要单独权衡。
- 我想学 LLM,但不知道如何开始,你可以给我建议吗?
学 LLM 最有效的起点不是先啃完理论,而是选一个真实小任务,边做边补概念,让卡住的地方告诉你该学什么。
- 什么场景/团队/项目用MCP/Skills什么时候不用
MCP 和 Skills 不是按场景二选一,而是先看结果、再看它是否真省 context:官方 MCP/CLI 简单但结果杂乱、几轮就撑满窗口时,才值得自己做成 Skill。
- 如何用 AI 辅助 产品设计
用 AI 做产品设计,关键不是让 AI 画图或写代码,而是把 AI 放进产品运行过程里承担任务,并把自己的判断标准写成 AI 能读的上下文。
- 什么是创意?创意也是对现有元素的组合排列吗?是的话,在这种情况下,怎么判断一个点子是否是真正创新的创意?最后如何获得创意?
创意可以看成对现有元素的重新组合,但判断它是否真创新,要看它是否解决了一个此前没被满足的真实需求;获得创意的路径是靠近真实问题、快速交给现实修正,而不是坐在房间里凭空想点子。