2026 年，AI 能在几分钟内生成成千上万行代码，Claude Code、OpenAI 内部实验都在证明：“让 AI 写 90% 以上代码”已经不是未来时，而是正在发生的现实。很多程序员的直觉担忧也随之冒出来：

“如果我熟练用 Harness Engineering，把写代码这件事都交给 Agent 了，那我自己还有什么价值？”

这篇文章想谈的，就是这个问题：当你真正会用 Harness Engineering 驾驭 AI 之后，你的价值到底在哪里、怎么放大、怎么刻意升级。

---

一、角色变化：从“写代码的人”到“系统与环境的设计者”

Harness Engineering 的核心前提是：
代码主要由 Agent 来写，人类工程师主要设计“让 Agent 安全高效干活的环境”。

在这种模式下，工程师的重心从：

• 亲自实现每个接口、每个类
  转向：
• 设计系统结构、约束规则、质量关卡和反馈闭环

如果用一个比喻：
以前你是“上手拧螺丝的工人”，现在你更像“设计产线和工艺的工程师”。

这不是把价值抹掉，而是把价值整体上移：代码变成可替代劳动力，系统与环境设计变成核心竞争力。

---

二、价值迁移的四个具体方向

1. 从“写怎么做”到“定义做什么”

AI 在“怎么写代码”上会越来越强，但“到底要做什么”和“什么绝对不能做”，仍然必须由人来决定。

你真正负责的是：

• 定义业务问题
  • 这不是一句“做个用户管理”，而是：
    • 哪些人被算作用户？
    • 权限边界在哪里？
    • 错误场景怎么处理？
    • 性能、安全、合规各自的底线是什么？
• 定义红线边界
  • 哪些操作技术上虽然能做，但业务/法律/品牌层面不能做？
  • 哪些数据永远不能暴露给 Agent？

AI 能帮你实现解法，但**“题目本身”和“评分规则”**得由你来写。

2. 从“写业务逻辑”到“设计系统结构和约束”

当你熟练 Harness 之后，你不再主要靠“写出优雅代码”体现价值，而是靠：

• 设计合理的模块和依赖关系
  • 比如：UI → 应用服务 → 领域 → 基础设施 的分层
  • 哪个模块可以依赖谁，哪个模块绝对不能被依赖
• 把经验写成硬约束
  • 用目录结构、命名规范、Linter 规则、架构测试（如 ArchUnit）、CI Gate，把架构原则“刻死”在环境里
  • 让 Agent 和新人从语法层面就写不出违背架构的代码

这意味着：你的价值不在“我能写出多优雅的一行代码”，而在“我让 10 个 Agent 写出十万行代码都不会乱”。

3. 从“手动排错”到“设计反馈闭环”

传统模式下，质量保障很多依赖人：

• 人看 PR
• 人盯测试
• 人查日志排错

在 Harness 模式下，你更像一个“反馈系统设计师”：

• 你设计测试策略：哪些必须单测、哪些需要集成/端到端、哪些需要压测
• 你把这些测试和静态检查接到 CI，在每次 Agent 提交后自动执行
• 你设计“错误自动回流”：
  • 测试失败 / Linter 报错 / 运行日志 → 自动整理成文本上下文 → 喂回 Agent，让它自己修正

你不再靠“自己 debug 每一个坑”来体现价值，而是通过设计一个能自己找错、自己改错的系统来体现价值。

4. 从“个人效率”到“系统可扩展性”

以前大家聊工程师价值，总是绕不开“个人效率”：我一个人能顶几个人干活。

Harness 之后，更重要的是：

• 你能否把自己的经验变成可复制的规则和模板？
• 你能否设计出一个流水线，在 AI 和新人加入时几乎不需要额外 hand-hold？
• 你能否让同样一个模型、同样一个团队，在你的 Harness 下实现更高的成功率、更少的回滚？

能把单点能力放大成系统能力的人，在这个时代会变得特别稀缺。

---

三、写代码还重要吗？重要，但角色变了

很多人会问：既然 AI 都能写了，我还要不要继续打磨编码能力？

答案是：要，但定位要变。

1. 编码变成“系统直觉的来源”，不是唯一产出

你过去写过的代码、踩过的坑，会转化成：

• 对系统结构的敏感度：
  • 一看到某个依赖关系就知道“这里以后肯定出问题”
• 对错误模式的嗅觉：
  • 一看异常堆栈/日志大概就知道哪一层设计有问题

这些直觉，正是你在设计 Harness 规则时所依赖的东西。

2. 你仍然会写代码，但更多是“高杠杆代码”

在 Harness 模式下，你写的通常是：

• 规则代码：自定义 Linter 规则、架构测试、CI 脚本
• 工具代码：统一的脚本、SDK、CLI 工具、模拟器、Fake 服务
• 框架代码：通用模块/基建库，让业务逻辑尽量薄、可由 Agent 填充

这些代码的特点是：写一次，影响面非常大。

---

四、如果你已经在学 Harness，该刻意升级什么？

假设你已经能让 Agent 帮你写功能、过测试、跑 CI，接下来可以刻意锻炼的，是这四种能力：

1. 问题拆解能力

• 把模糊需求拆成：
  • 领域概念和边界
  • 可以自动验证的行为规格（输入输出）
  • 一组可维护的测试用例
• 会写“Agent 也看得懂”的规格文档，让 Agent 照着做不容易误解

2. 架构与约束设计能力

• 对常见业务问题有一套默认架构模板（Web / 数据 / AI 工作流等等）
• 知道哪些约束要写死进环境（Linter/CI），哪些可以放宽给 Agent 探索
• 能把“这次踩的坑”变成一条条具体规则，而不是一句"下次注意"

3. 反馈闭环与观测设计能力

• 设计出一条完整的链路：
  • 写代码 → 跑测试 → 部署 → 观测 → 回滚 / 调参
• 对系统的指标敏感，能定义清晰的 KPI 和 SLO（错误率、延迟、成功率等），然后让 Agent 带着这些目标工作

4. 跨职能沟通与决策能力

• 能听懂和翻译业务语言，把“模糊诉求”变成明确约束
• 在多种方案之间做取舍：成本、风险、可维护性、长期演进路线

这些组合起来，就是一个成熟的 Harness 设计者 / Agent 时代的技术负责人的价值曲线。

---

五、回到最初的问题：程序员的价值在哪里？

如果你还停留在“我写的代码比 AI 好看”这个层面，确实会越来越难受。

但当你真的掌握 Harness Engineering，你的核心价值会变成：

1. 定义问题和边界的人：清楚地说出要做什么、不该做什么
2. 设计系统和环境的人：搭好结构、约束和工具，让 AI 和新人都走在正确的轨道上
3. 设计反馈闭环的人：让系统自己发现和修正错误，而不是靠你一个个救火
4. 对整体负责的人：对业务、技术和风险的综合结果负责，而不仅仅是一段代码的实现

换句话说，“只会写代码的程序员”会被 AI 吃掉，
但“会让 AI 和系统为自己工作的人”，会变得比现在更值钱。

---