所谓解耦
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
AI 不会吞掉软件,只会吞掉入口
“AI 会吞掉所有软件”这个说法很有传播力,但技术上不够准确。更可能发生的事情是:软件本体继续存在,软件入口被 AI 重写。 计算器、数据库、编译器、PDF 库、浏览器、CAD、CI、权限系统、ERP 不太会因为 LLM 出现而消失。它们处理的是确定性状态、格式、权限、计算和副作用。LLM 不适合直接替代这些系统,却很适合成为它们上方的意图入口。 确定性系统不会消失 裸模型不是确定性程序。它可以写出计算器代码,但不应该代替计算器执行财务计算;它可以解释 PDF 结构,但不应该靠想象修改 PDF 二进制;它可以生成 SQL,但实际执行、回滚、审计和加锁的仍然是数据库。 这不是模型能力不够强时的临时现象,而是范式边界。真实软件世界需要可复现、可审计、可回滚、可授权。神经网络输出可以生成候选方案,却很难成为这些确定性承诺本身。 Claude Code Skills 的 PDF 示例很能说明问题。一个 PDF skill 会把操作流程写进 SKILL.md,再借助 pypdf、pdfplumber、脚本和参考资料处理文件。实际改 PDF 的不是模型“懂了 PDF”,而是模型调度了确定...
2026-02-07
API 兼容性设计
在软件工程中,API 兼容性是一个至关重要但又经常被忽视的问题。良好的兼容性设计能够确保系统的平滑演进,避免因 API 变更导致的客户端崩溃和服务中断。本文将从多个维度探讨 API 兼容性设计的最佳实践。 什么是 API 兼容性 API 兼容性分为两种类型: 向前兼容:旧版本的客户端能够与新版本的服务端正常通信。即服务端升级后,旧客户端仍能正常工作。 向后兼容:新版本的客户端能够与旧版本的服务端正常通信。即客户端升级后,旧服务端仍能提供服务。 在实际项目中,我们通常更关注向前兼容,因为服务端的升级往往不可控,而客户端的更新节奏各异。 破坏性变更的分类 破坏性变更是指会导致现有客户端无法正常工作的 API 变更。主要分为三类: 1. 接口签名变更 123456789// 变更前public interface UserService { User getUser(String userId);}// 变更后 - 破坏性变更public interface UserService { User getUser(String userId,...
2026-03-27
Harness Engineering 完整指南:从 Prompt Engineering 到实践落地的三级跃迁
2020 年我们学会了跟模型说话(Prompt Engineering),2025 年我们学会了给模型喂信息(Context Engineering),2026 年我们学会了给模型搭脚手架(Harness Engineering)。这三个 Engineering 不是并列关系,而是严格的超集关系:PE ⊂ CE ⊂ HE。本文从"为什么上一个不够"的视角,系统梳理这条演进路径上的每一次范式跃迁,并给出从 Anthropic 实证到工程落地的完整方案。 一个类比秒懂三级跃迁 在讲技术之前,先用一个所有人都能理解的类比。 想象你要指挥一个完全失忆的天才厨师做一桌满汉全席: Prompt Engineering 就是学会怎么跟厨师下达指令。你发现说"做道好吃的"不行,得说"用中火煎三分钟,翻面后加酱油 15 毫升"。这是措辞的艺术。 Context Engineering 就是学会怎么给厨师备料。光会下指令不够——厨师面前得摆好食材、调料、菜谱、食客的过敏信息。你要设计一个动态备料系统,让厨师在需要的时候拿到需要的东西...
2018-05-09
Convention over Configuration over Programming
什么是 Convention over Configuration over Programming 在软件工程中,有一条重要的设计哲学层级: Convention over Configuration over Programming 约定优于配置,配置优于编程。 这条原则的核心思想是:能用约定解决的问题,就不要引入配置;能用配置解决的问题,就不要写代码。 它反映了软件设计中对复杂度管理的追求——越是高层次的抽象,使用成本越低,出错概率也越小。 三个层次的含义 Programming(编程) 编程是最灵活但成本最高的方式。开发者需要编写具体的代码逻辑来实现功能。每一行代码都是潜在的 bug 来源,都需要测试、维护和 review。编程适合处理那些真正需要定制化逻辑的场景。 Configuration(配置) 配置是介于约定和编程之间的中间层。通过外部化的配置文件(如 XML、YAML、properties 等),开发者可以在不修改代码的情况下改变程序行为。配置降低了修改成本,但引入了配置管理的复杂度——配置项越多,理解和维护系统的难度就越大。 Convention(约定) ...
2026-05-23
上下文换入换出:下一代 scaling
上一篇说裸模型像抽卡,因为它把概率输出直接暴露给用户。抽卡感解释的是一次任务里的波动;上下文问题解释的是长程任务为什么会累、会乱、会跑偏。 LLM 和人都有一个共同约束:它们都在上下文里工作。区别在于,模型的上下文 refill 是读写问题,人的上下文 refill 是注意力问题。机器可以把一段摘要重新塞进 message array,人却要重新把目标、材料、约束和下一步动作装回工作记忆。这个过程有磨损。 人也有 context window 把 LLM 说成统计模型是对的,但这种说法容易遮住它和人的相似工作形态。人从长期通识积累到领域学习,再到职业训练和反馈,很像预训练、继续预训练和后训练的分层。拥有推理能力以后,人也不是在真空中推理,而是在一个被任务材料填充出来的上下文里推理。 上下文质量决定注意力预算能不能被调动。APA 对 multitasking 的综述把任务切换带来的时间成本叫 switching costs。换到工程语境里,context switching 的问题不是“同时做两件事”这么简单,而是每次切换都要重新加载一组任务状态:目标是什么,做到哪里,哪些约束不...
2026-05-23
裸模型为什么像抽卡
大模型写代码有一种很危险的爽感:同一个问题,上一轮胡说八道,下一轮突然给出一段漂亮实现。失败的时候像差一点,成功的时候像中奖了。 这种体验很像抽卡。不是因为使用 AI 等同于赌博,而是因为裸模型的反馈结构具备几个相似特征:结果有波动,高分样本偶尔出现,用户很难提前判断下一轮是不是高分,于是自然产生“再试一次”的冲动。 把这种冲动看清楚,比单纯争论模型聪不聪明更重要。很多 AI coding 的燃尽感,不来自模型太弱,而来自人把自己的注意力押在一次又一次低可见度的重试上。工程工作被悄悄改造成了抽卡循环。 flowchart LR A[一次任务] --> B[裸模型采样] B --> C{输出质量} C -->|低分| D[补 prompt / 换模型 / 重试] C -->|高分| E[强奖励: 这次出货了] D --> B E --> F[提高下一轮期望] F --> D D --> G[隐藏成本: review / 归因 / 修复 / 焦虑] ...
Announcement
人生只是,守株待兔


