所谓解耦
Created|Updated
|Word Count:159|Reading Time:1mins|Post Views:
软件设计,必有单元/片段,不管他们叫做系统、层次、模块、类型和方法,都是为了在一个抽象颗粒度上分割复杂度,让我们降低思考的难度,并且进行团队协作。
我们在进行系统交互的时候,要尽量设计单元交叉点通过薄的中间层交互。也就是放弃直接性,拥抱间接性。
间接性的实现,就是契约、接口或者门面/桥接模式。这些实践的使用,可以轻易让我们切换层次之间的实现,而使变动不扩散出去。
Author: magicliang
Copyright Notice: All articles on this blog are licensed under CC BY-NC-SA 4.0 unless otherwise stated.
Related Articles
2026-05-23
上下文换入换出:下一代 scaling
上一篇说裸模型像抽卡,因为它把概率输出直接暴露给用户。抽卡感解释的是一次任务里的波动;上下文问题解释的是长程任务为什么会累、会乱、会跑偏。 LLM 和人都有一个共同约束:它们都在上下文里工作。区别在于,模型的上下文 refill 是读写问题,人的上下文 refill 是注意力问题。机器可以把一段摘要重新塞进 message array,人却要重新把目标、材料、约束和下一步动作装回工作记忆。这个过程有磨损。 人也有 context window 把 LLM 说成统计模型是对的,但这种说法容易遮住它和人的相似工作形态。人从长期通识积累到领域学习,再到职业训练和反馈,很像预训练、继续预训练和后训练的分层。拥有推理能力以后,人也不是在真空中推理,而是在一个被任务材料填充出来的上下文里推理。 上下文质量决定注意力预算能不能被调动。APA 对 multitasking 的综述把任务切换带来的时间成本叫 switching costs。换到工程语境里,context switching 的问题不是“同时做两件事”这么简单,而是每次切换都要重新加载一组任务状态:目标是什么,做到哪里,哪些约束不...
2026-03-18
智能体记忆全景综述:从短时长时之分到向量库回归文件系统(2022-2026)
22 年以前,“LLM 应用"基本等同于"调一次 ChatComplete”。从 22 年底 ChatGPT 出来到 26 年这三年里,行业发现真正决定智能体上限的不是模型本身,而是模型周围那一圈用来承载历史、外部知识与可更新偏好的记忆系统。这篇综述沿着一条主线展开:以"信息来源"为轴的四层记忆世界观,把过去三年的代表性工作放进这四层里,并且回答一个 26 年才浮出水面的反向问题——为什么大家又在把向量数据库塞回到一个 markdown 仓库或一份 SQLite 单文件里。 一、把整片版图压成三句话 如果把过去三年关于智能体记忆的所有论文、产品和工程实践压成三句话,大致是这样: 第一,Agent 的记忆按"信息源"切是一个稳定的四层结构:训练数据(L1)、对话内数据(L2)、会话间数据(L3)、外部世界但与本会话无关的数据(L4)。每一层的写入主体不同,分别是训练管线、当前交互、Agent 自己、世界本身。围绕"是不是要再切出第五层"在 25-26 年有一些讨论,本文的判断是:Titans / ...
2026-05-23
AI 不会吞掉软件,只会吞掉入口
“AI 会吞掉所有软件”这个说法很有传播力,但技术上不够准确。更可能发生的事情是:软件本体继续存在,软件入口被 AI 重写。 计算器、数据库、编译器、PDF 库、浏览器、CAD、CI、权限系统、ERP 不太会因为 LLM 出现而消失。它们处理的是确定性状态、格式、权限、计算和副作用。LLM 不适合直接替代这些系统,却很适合成为它们上方的意图入口。 确定性系统不会消失 裸模型不是确定性程序。它可以写出计算器代码,但不应该代替计算器执行财务计算;它可以解释 PDF 结构,但不应该靠想象修改 PDF 二进制;它可以生成 SQL,但实际执行、回滚、审计和加锁的仍然是数据库。 这不是模型能力不够强时的临时现象,而是范式边界。真实软件世界需要可复现、可审计、可回滚、可授权。神经网络输出可以生成候选方案,却很难成为这些确定性承诺本身。 Claude Code Skills 的 PDF 示例很能说明问题。一个 PDF skill 会把操作流程写进 SKILL.md,再借助 pypdf、pdfplumber、脚本和参考资料处理文件。实际改 PDF 的不是模型“懂了 PDF”,而是模型调度了确定...
2018-10-26
checklist
写代码 checklist 注意位置 注意顺序 注意初始化 注意返回值 注意注释 注意防御性编程 注意数据库性能 上线 checklist 代码变更 check 代码 配置变更 check 配置 系统变更注意上线顺序 依赖中间件变更注意配置中间件 配置中心配了吗 交互所有细节都实现了吗? 配监控和埋点 数据库变更了吗? 安全检查
2026-05-23
Agent Teams 为什么有效
多 Agent 不是把同一个模型多开几份,也不是给系统加几个“人格”。它有效的地方,是把一个会互相稀释的上下文问题,拆成几个更窄、更干净、更容易验证的工作单元。 复杂任务不是信息越多越好。一个 Agent 同时负责需求、架构、编码、测试、文档和发布,很容易在同一个窗口里把角色、证据和目标搅在一起。Agent Teams 的价值,是让每个工作单元只面对一个足够小的世界。 注意力需要降维 考虑一个频谱分析的类比:复杂任务像一段混合信号,包含多个频率分量叠加。单 Agent 试图同时处理所有频率,相当于用一个宽带滤波器——信噪比低,各分量互相干扰。多 Agent 相当于用一组窄带滤波器,每个只提取自己负责的频段,互不干扰,最后再合成输出。 模型的注意力也有这个问题。任务越大,上下文里越容易同时出现目标、反例、日志、旧方案、失败尝试、代码片段和用户补充。它们都在争夺同一个窗口里的注意力。多 Agent 的第一层收益,就是把同一团上下文切成几个局部上下文。 flowchart TB U[用户目标] --> O[Orchestrator: 保持全局目标] O --&...

2019-12-31
代码大全
第 1 章 欢迎进入软件构建的世界 第 2 章 用隐喻来更充分地理解软件开发 第 3 章 三思而后行:前期准备 第 4 章 关键的“构建决策” 第 5 章 软件构建中的设计 第 6 章 可以工作的类 第 7 章 高质量的子程序 第 8 章 防御式编程 第 9 章 伪代码编程过程 第 10 章 使用变量的一般事项 第 11 章 变量名的力量 第 12 章 基本数据类型 第 13 章 不常见的数据类型 第 14 章 组织直线型代码 第 15 章 使用条件语句 第 16 章 控制循环 第 17 章 不常见的控制结构 第 18 章 表驱动法 第 19 章 一般控制问题 第 20 章 软件质量概述 第 21 章 协同构建 第 22 章 开发者测试 第 23 章 调试 第 24 章 重构 第 25 章 代码调整策略 第 26 章 代码调整技术 第 27 章 程序规模对构建的影响 第 28 章 管理构建 第 29 章 集成 第 30 章 编程工具 第 31 章 布局与风格 第 32 章 自说明代码 第 33 章 个人性格 第 34 章 软件工艺的话题 第 35 章 何处有更多的信息
Announcement
人生只是,守株待兔


