一. 认知更新

        年初曾定下一个目标：让 AI 托管 60% 的日常编码工作。若想达成这一目标，便需为 AI 建立可消费的项目知识库（涵盖业务知识、编码规范等），这本身已是耗费精力的过程，且每次迭代都需动态维护。彼时 SDD（规范驱动开发）正值热潮，我还未深入使用 OpenSpec，又逢 OpenClaw 带火 Claude Code 与 Skill 技术，彼时仍笃信：AI 若要更聪明，知识库仍是绕不开的一环。直至在内网看到一句话：“没必要花大力气维护 PRD 和系分设计，最终都会体现在代码中，真正持续维护的是项目的上下文。”这让我意识到，真正决定 AI 协作效率的并非静态文档，而是项目运行中不断沉淀的上下文。

       大模型 Skill 技术的出现，使 Agent 能力实现了实质性的跃升。回想去年三月，为让 Agent 稳定运行，大量精力消耗在工具选择偏离预设、参数填充不可控、多轮对话意图识别偏差等琐碎问题上，不得不借助 few-shot、提示词扩写、知识库检索等手段反复调优，涉及动态规则与用户确认的场景更需设计繁杂的表单来兜底。如今 Skill 技术已从重塑了这一局面，AI 不再是被反复调教的工具，而成为可逐步融入开发流程的协作者，人与 AI 之间的协作方式正在被重新定义。

二. Harness Engineering 的发展历程

AI工程领域的核心概念经历了三次迭代，时间线如下：

2022年底~2024年初：Prompt Engineering（提示词工程）

• 概念：提示词工程专注于如何写好提示词，让模型输出最佳结果。其中用户是"绝对掌控者"，模型是被动执行者。

• 技巧：Few-shot prompting、Chain-of-Thought、角色扮演等手段。

• 缺点：大模型处理复杂 Agent 任务或者多轮对话开始出现幻觉。

2024年~2025年初：Context Engineering（上下文工程）

• 概念：上下文工程关注如何管理进入模型的上下文信息，核心焦点从写好一条指令扩展到了设计一个动态系统来组装上下文。

• 。用户从"直接发号施令者"转变为"情境构建者"。

• 技巧：RAG 知识库、系统提示词、Memory记忆系统等。

• 缺点：上下文窗口的扩大，并不等于 Agent 性能的线性提升。

2025年初~至今（2026年2月集中爆发）：Harness Engineering（驾驭工程）

• 概念：Harness Engineering 通过构建受控环境，让AI在约束下高效可靠地工作。相对于 Context Engineering，Harness Engineering 构建一个围绕模型的完整控制与迭代系统，OpenAI 发布的实践报告中将 Harness 的核心拆解为三个维度：上下文工程（Context Engineering）、架构约束（Architectural Constraints）和熵管理 / 垃圾回收（Entropy Management）。有个形象的比喻：

  想象AI是一匹拥有神力的独角兽，它力量强大但难以预测。驾驭工程不是去拔掉它的角，而是为它打造一套“黄金缰绳”和“水晶马车”。缰绳 （架构约束）引导它走正确的路，马车（上下文工程）提供舒适的承载空间，车上的镜子（反馈循环）随时照出它的状态，而车夫（熵管理）则负责清理它奔跑时留下的杂乱痕迹。

• 历程：

  • 2026年2月，Mitchell Hashimoto 在博客中首次命名“Harness Engineering”。

  • 2026年2月11日，OpenAI 在工程博客发布实践报告《Harness engineering: leveraging Codex in an agent-first world》，系统化了Harness Engineering理念。

三. Claude Code 及 Skills 为什么在 2026 年 2 月初爆火？

​        Claude Code 从 2025.02 诞生之初就在编程领域具备很强的竞争优势，随着 2026 年Harness Engineering（驾驭工程，OpenAI Codex 团队的实验和总结）的爆火，Claude Code 以及 Skills 作为成熟落地的产品，成为该范式的最佳案例。简单来说，Claude Code 是引爆点，Skills 是“弹药”，而 Harness Engineering 是提供“战术”的指挥官。

2026.02 年初 AI 开发范式爆发逻辑链

​ 从原理上讲 Claude Code 为什么那么强的原因是，Claude Code 回归了Agent的本质：用一个极简的 while 循环构建了稳定的"感知-执行-反馈"机制，将文件系统作为模型的“眼睛和双手”，让它能自主探索代码库、运行命令、观察结果、自我纠错，无需人类持续投喂上下文。更重要的是，它将工程重心从“让模型更聪明”转移到“让系统更可靠”，通过渐进式复杂度、上下文压缩、工作树隔离、子代理协作等 Harness 机制，把聪明的模型封装进靠谱的身体里，最终实现了从"能用"到"生产级可靠"的跨越。

四. 开发者怎么更好应用 Harness Engineering？

        Harness Engineering 将工程师从“代码的直接生产者”的角色转变为“智能体运行环境的设计者与系统架构师”。结合 Harness Engineering 的原理来讲，可从以下几点构造 Agent 运行环境：

1. 渐近式构建上下文。将 AGENTS.md 文件精简为一个仅有 100 行左右的“索引地图”，让它指向一个结构化的  docs/ 目录，作为唯一的真实信息来源。

如果持续维护迭代文档？比如使用 Claude Code 时，持续维护 CLAUDE.md 文件，该文件记录项目架构、核心约定和常用命令，过程中可结合 Claude-mem插件。

2. 设计架构强制约束与自反馈回路。定义好项目规范等约束规则，当 Agent 犯错时能根据约束规则自主修复。

3. 建立持续的“垃圾回收”与“熵减”机制。定期扫描文档漂移、模式违规和依赖问题。

4. 提升环境可观测性。让 Agent 在执行完某一步骤后，能完整监测到运行的日志和指标，实现自主调整。

从日常工作上讲：

• 日常重复且复杂性的工作交给 Agent 来做，可抽象为大大小小的 Skill。

• 去深入了解业务，将业务拆解为 Agent 能做的事情。构建 Agent 的过程需要以 Harness Engineering 的特性为指导，从而构建一个存在约束且受控的 Agent 运行环境。

五. 近期感受

       近期公司推行“功能改造成skill”的调整，力度不小。表面看是内部职责的重新划分，背后却透出一种对AI的普遍焦虑。结合近期看到的信息，这种焦虑似乎并非孤例：

• 业内普遍预期，未来一两年可能出现新一轮裁员潮，外包与应用软件开发领域首当其冲；

• 头部企业的招聘方向明显收窄，Java等传统开发岗位需求缩减，岗位资源向AI相关方向集中；

• “平台skill化”的趋势正在多个场景落地，原本作为系统功能承载的部分，正逐步被封装为可调用的技能单元。

三个信号叠加，指向的是开发模式、岗位结构与职业路径的现实调整。与其说这是技术演进的自然结果，不如说是在AI冲击下，组织与个人都在重新寻找位置。