AI时代工程师价值：追求完全正确
不是模型，是 Harness。
今年二月，我在做一个 Go 语言的 AI Agent 框架迁移。
项目本身不复杂——把一个 Python 写的 Agent 框架用 Go 重写一遍。但我在开发过程中遇到了一堆问题：AI 生成的代码用的是旧版 API，报错信息它看不懂，异常处理写得一塌糊涂。我花了大量时间在"修 AI 写的 bug"上。
后来我看到毕玄的一篇文章，他把这些问题总结得非常精准：信息老、头疼医头、初级问题。
我突然意识到——问题不在于 AI 不够强，而在于我没有给它足够好的"环境"。
这个环境，就是 Harness。
01 当模型成为 CPU，谁是操作系统？
2026年，AI 编程已经不是新鲜事了。从 GitHub Copilot 到 Claude Code，从 Cursor 到 Windsurf，工具层出不穷。
但一个奇怪的现象是：同样的模型，在不同人手里效果天差地别。
有人用 Claude Code 一天写出完整项目，有人用同样的工具反复改 bug 改到崩溃。有人用 AI 辅助开发效率翻倍，有人发现自己在"给 AI 擦屁股"上花的时间比写代码还多。
差距在哪里？
llm = cpu, context = mem, Harness = os, agent = app
这个类比把 AI 编程的本质讲透了。模型是 CPU，负责计算；上下文是内存，存储信息；但真正让这一切运转起来的，是操作系统——Harness。
就像你买了一个顶级的 CPU，没有操作系统也什么都干不了。你有了最强的模型，没有好的 Harness，也一样抓瞎。
更关键的是，OpenClaw 还观察到一个现象：
喜欢算法谜题的工程师反而很难适应 Agent 工作流，而产品导向的工程师适应得更快。
为什么？
因为算法导向的工程师习惯"我写代码，AI 辅助"，而产品导向的工程师习惯"我规划，AI 执行"。后者更接近 Harness 的本质——花大量时间跟 Agent 做前期规划，挑战和完善方案，然后一键执行，转身去做下一件事。
02 Harness Engineering：被忽视的核心能力
那么，Harness 到底是什么？
用一句话概括：Agent = Model + Harness。
模型提供"智能"，Harness 提供"确定性"。
拆开来看，Harness 由五个部分组成：
1. 系统提示词：定义模型的角色和目标。这是"告诉 AI 它是谁、要干什么"的第一步。
2. 工具、技能、MCP：模型可以调用的外部能力。没有工具的 AI 就像没有手脚的人。
3. 基础设施：文件系统、沙箱、浏览器等运行环境。AI 需要一个能真正"干活"的地方。
4. 编排逻辑：子 Agent、任务拆分、模型路由。复杂任务需要拆解，不同任务可能需要不同的模型。
5. 钩子/中间件：压缩、续写、代码检查等确定性流程。这些是保证输出质量的"守门员"。
这五个部分，每一个都是工程师可以主动设计和优化的。
但现实中，大多数工程师是怎么做的？
他们打开 Claude Code 或 Cursor，输入一个模糊的需求，然后开始一轮又一轮的"对话式编程"。AI 写一行，他们改一行；AI 报一个错，他们粘贴报错信息让 AI 修。
这不是在用 AI，这是在被 AI 拖着走。
真正高效的工作流是这样的：
Intent → Spec → Plan → Harness → Execution
先明确意图（Intent），再细化规格（Spec），然后制定计划（Plan），接着搭建 Harness（环境、工具、规则），最后才是执行（Execution）。
前三步占用了大部分时间，但执行可能只需要几分钟。
这就是"追求完全正确"的本质——不是要求 AI 一次写对，而是通过精心的规划和设计，让 AI 在执行阶段能够"一次跑通"。
03 我是怎么踩坑的，又是怎么爬出来的
说回我那个 Go 语言迁移项目。
最开始，我就像前面说的那样——打开 AI 工具，输入需求，开始一轮轮对话。结果呢？AI 生成的代码各种问题：用了废弃的 API、异常处理缺失、日志格式不统一……
我花在修 bug 上的时间，比我自己从头写还多。
后来我换了个思路。
第一步，我先让它"学会"这个技术栈。
我创建了 tech-stack-selection-skill——一个专门用于技术选型决策的 AI 技能。它不是简单地给出推荐，而是引导 AI 进行结构化、量化的分析：框架选择、数据库选型、中间件对比、架构演进……
这样，AI 在写代码之前，已经"理解"了这个技术栈的边界和最佳实践。
第二步，我给它提供了"参考答案"。
我创建了 eino-skill——专门用于 CloudWeGo Eino 框架的 AI 编码助手。它包含了 Agent 开发、组件使用、Chain/Graph 编排、流式处理、人机协作等场景的最佳实践。
然后我建了一个 eino-skill-examples 仓库，包含 60+ 示例代码，全部用 AI 辅助生成并验证过。AI 在写新代码时，可以参考这些"正确答案"。
第三步，我参考了go-zero的"三层架构"。
在 hello-gozero 项目中，我设计了一个 AI 编程的标准结构：
-
ai-context/：做什么——需求和上下文 -
micro-skills/：怎么做好——技能和最佳实践 -
mcp-zero/：执行——工具和环境
这三层对应了 Harness 的核心要素：上下文、能力、基础设施。
结果？
同样的 AI 模型，写出来的代码质量完全不同。API 版本是对的，异常处理是完整的，日志格式是统一的。我只需要在关键节点 review，而不是每行代码都盯着看。
毕玄提到的那几个问题——信息老、头疼医头、初级问题——都在这个过程中被系统性地解决了。
维护技术栈，就是在解决"信息老"的问题。
架构师介入规划，就是在解决"头疼医头"的问题。
规范约束，就是在解决"初级问题"的问题。
04 追求完全正确，本质是交付确定性
回到开头那个问题：AI 时代工程师的价值是什么？
更准确的说法是：交付确定性。
但"取其上者得其中"，作为口号，还是要用"追求完全正确"。
这里有两层含义：
第一层，对 AI 来说，追求完全正确意味着精心设计 Harness。
不是指望 AI 自己变聪明，而是给它足够好的环境、工具、规则。就像一个优秀的工程师不需要最顶级的 CPU，但需要设计良好的系统架构。
第二层，对工程师来说，追求完全正确意味着角色转变。
从"写代码的人"变成"设计系统的人"。从"执行者"变成"规划者"。从"和 AI 比谁写代码快"变成"让 AI 执行我的规划"。
长期自主执行的能力，不是 AI 自己进化出来的，而是工程师设计出来的。
文件系统、Git、Ralph 循环、规划加自我验证——这些都是 Harness 的一部分。AI 在这个环境中可以自主运行，但它运行的轨道是人铺设的。
写在最后
AI 编程的终局，不是 AI 替代工程师，而是工程师变成"操作系统架构师"。
你的价值不在于写多少行代码，而在于你设计的 Harness 能让 AI 发挥多大的能力。
追求完全正确。
不是追求 AI 一次写对，而是追求你的 Harness 让 AI 一次跑对。
调研 & 撰写：AI(opencode+GLM)
主导 & 审校：dayday
创作时间：约 30 分钟
相关项目：
- tech-stack-selection-skill - 技术栈选型决策助手
- eino-skill - Eino 框架 AI 编码助手
- eino-skill-examples - 60+ 示例代码
- hello-gozero - 三层架构设计
- hello-agents-go - Go AI Agent 框架
参考资料：
- 模型不是关键，Harness 才是
- Brainstorming 之后，还缺什么？
- Harness engineering：智能体时代的 AI 编程驾驭之道
- AI Coding 的常见问题及为其制定的基本原则
全文完，感谢您的阅读。
