所谓解耦
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-20
Harness Engineering:长程 Agent 的工程化底座
微信公众号文章《Harness Engineering:让AI Agent长程运行的秘密武器》抓住了一个很重要的行业拐点:Agent 讨论正在从“模型有多强”转向“系统怎么让模型可靠工作”。这个判断是对的,但如果只把 Harness Engineering 理解成“给 Agent 做记忆和交接班”,还是太窄。 更准确的定义是:Harness Engineering 是围绕模型构建一套可执行的工作环境、状态系统、工具边界、验证机制和反馈循环,让 Agent 能跨越单个上下文窗口,持续推进真实任务,并在失败时留下可恢复的证据。 这不是 Prompt Engineering 的升级版,也不是 Context Engineering 的别名。Prompt 解决一次请求怎么说,Context 解决一次请求里放什么,Harness 解决的是任务生命周期怎么被系统托住。 一、为什么 2026 年突然轮到 Harness OpenAI 在 2026 年 2 月发布的 Harness Engineering 文章里披露了一个内部实验:团队从空 Git 仓库开始,用 Codex 构建并发布一个内部...
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 就是学会怎么给厨师备料。光会下指令不够——厨师面前得摆好食材、调料、菜谱、食客的过敏信息。你要设计一个动态备料系统,让厨师在需要的时候拿到需要的东西...

2026-07-01
AI 是放大器不是方向:读 Adam Bender 谈软件生态学的 10 倍时刻
引子:10 倍代码不等于 10 倍工程 Google 首席软件工程师 Adam Bender 在 Google I/O 2026 的一场演讲里抛出大多数人还没来得及思考的问题:当 AI 把代码产出速度推到现有工程流程无法承载的地步,开发者生态系统里什么会最先垮掉? 他的回答直白:今天构建软件的方式,在 10 倍速度下根本行不通。AI 时代的真正赢家不是产出最高的团队,而是基本功最扎实的那些人。AI 只负责放大,不负责方向。 这场演讲串起一个大多数人没听过的概念:软件生态学,对生产软件的社会技术生态系统进行整体性研究的学科。它要求不只看技术,还要看人、看文化、看组织里那些不成文的规则。 flowchart TB subgraph Eco["社会技术生态系统(软件生态学的研究对象)"] direction LR Culture["工程文化<br/>组织结构 · 激励机制"] Practice["工程实践<br/>审查 · 测试 · 发布"] ...
2026-02-07
变更日志(Changelog)规范
什么是变更日志 变更日志(Changelog)是一个按时间顺序记录项目所有重要变更的文件。它帮助用户、开发者和利益相关者了解每个版本中发生了什么变化,包括新功能、Bug 修复、破坏性变更等。 为什么需要变更日志 用户友好:让用户快速了解新功能、修复的问题和需要注意的变更 版本追溯:帮助定位问题首次出现或修复的版本 团队协作:统一团队对变更的理解和沟通 发布管理:辅助版本发布流程和发布说明的撰写 与 Git Log 的区别 特性 变更日志 Git Log 目标受众 用户、开发者、利益相关者 开发者 内容粒度 功能级别的高级描述 每次提交的详细记录 可读性 高度结构化、易于阅读 技术性强、包含实现细节 维护方式 手动维护或自动化生成 自动记录所有提交 版本关联 按版本组织 按时间顺序 Git Log 记录所有的代码提交,包括内部重构、测试调整等;而变更日志只记录对用户有意义的变更。 Keep a Changelog 规范 Keep a Changelog 是目前最广泛采用的变更日志规范,由 Olivier Lacan 创建。 变更类型分类 Ke...
2018-03-07
语义版本化问题
语义化版本 2.0.0 《语义化版本 2.0.0》,三段版本号语义: 版本格式:主版本号.次版本号.修订号(MAJOR.MINOR.PATCH),版本号递增规则如下: 主版本号(MAJOR):当你做了不兼容的 API 修改, 次版本号(MINOR):当你做了向下兼容的功能性新增, 修订号(PATCH):当你做了向下兼容的问题修正。 先行版本号及版本编译信息可以加到"主版本号.次版本号.修订号"的后面,作为延伸。例如 1.0.0-alpha、1.0.0-beta.1、1.0.0-0.3.7。 版本号的初始阶段 在主版本号为 0.x.y 的阶段,API 被认为是不稳定的,任何变更都可能发生。这个阶段的软件不应该被用于生产环境。1.0.0 的发布意味着公共 API 的正式定义,后续的版本号变更都基于这个公共 API 的变化来递增。 先行版本号(Pre-release) 先行版本号通过在修订号后面加上连字符和一系列以点分隔的标识符来表示。例如: 1.0.0-alpha < 1.0.0-alpha.1 < 1.0.0-beta < 1.0.0-b...
2026-05-23
Agent Teams 为什么有效
多 Agent 不是把同一个模型多开几份,也不是给系统加几个“人格”。它有效的地方,是把一个会互相稀释的上下文问题,拆成几个更窄、更干净、更容易验证的工作单元。 复杂任务不是信息越多越好。一个 Agent 同时负责需求、架构、编码、测试、文档和发布,很容易在同一个窗口里把角色、证据和目标搅在一起。Agent Teams 的价值,是让每个工作单元只面对一个足够小的世界。 注意力需要降维 考虑一个频谱分析的类比:复杂任务像一段混合信号,包含多个频率分量叠加。单 Agent 试图同时处理所有频率,相当于用一个宽带滤波器——信噪比低,各分量互相干扰。多 Agent 相当于用一组窄带滤波器,每个只提取自己负责的频段,互不干扰,最后再合成输出。 模型的注意力也有这个问题。任务越大,上下文里越容易同时出现目标、反例、日志、旧方案、失败尝试、代码片段和用户补充。它们都在争夺同一个窗口里的注意力。多 Agent 的第一层收益,就是把同一团上下文切成几个局部上下文。 flowchart TB U[用户目标] --> O[Orchestrator: 保持全局目标] O --&...
Announcement
人生只是,守株待兔
