从harness看未来软件工程师的工作职责

![[从harness看未来软件工程师的工作职责/what-is-harness.png]]

先说结论

我现在更确定的一点是：AI 写得快，不等于系统交付得快。工程师的价值不会只剩“亲手敲代码”，但也不会自动消失，它会更多落在问题定义、执行环境、反馈回路和结果验证上。

这篇用 Harness 这个词来整理我的观察。说得简单一点：

Harness 就是把 AI 拴住、喂料、给工具、设规则、跑验证、收结果的一整套工程装置。

原始的软件工程里有 test harness，意思是为了自动测试，把测试数据、桩、驱动器、执行环境、结果校验包起来。放到 AI Coding 里，模型不是单独干活，模型外面那层让它可靠干活的系统，就是 harness。

所以行业里常说：

Agent = Model + Harness

模型只是其中一部分。真正让任务稳定完成的，是上下文边界、工具权限、执行流程、异常兜底、环境观测和结果验证。最大的误区，是把 AI 当成更快的外包程序员，只看代码行数，不看任务是否可控、结果是否可验。

未来的工程师的工作职责是什么？

https://simonwillison.net/2025/Jul/4/identify-solve-verify/

我花在 AI 编程的时间越多，对自己的职业生涯的担忧就越少，即使 AI 的编程能力越来越强。

因为，我发现 AI 编程只是流程的一部分，我的工作不仅仅是编写代码。

我的真正工作是，找出可以用代码解决的问题，然后解决它们，并验证解决方案是否有效。

AI 最终或许能够完全承担中间的编码部分，并帮助解决第一部分和最后一部分，但无论如何，仍然需要有人去发现问题、定义问题并确认问题已经得到解决。

这就是我的工作的80%内容。

程序员的工作不是编程

https://codeandcake.dev/posts/2025-12-12-your-job-isnt-programming

程序员的工作不是编程，而是通过抽象，来管理软件的复杂性。如果你做到了这一点，那么编程就很容易了。

如何考核和评价一名工程师的能力

The .claude/ Folder Is Your New Resume

https://x.com/heynavtoor/status/2036861280859124100

先问2个问题：

你这个月花在 Claude Code 上的钱是多少？
你是怎么花掉这个钱的？

看如下这个案例：一个开发，将自己的工作全部拆解为了 Skill，不再自己编码了，然后每个月出一个 Claude Code 的阶段性统计报表，包括：

每天的 token 消耗数
每天的 issue、commit、PR、代码行数

![[IMG-20260328143717000.png]]

如何站在老板的角度回答这些问题？

注意：不要站在打工人的角度去思考这些问题，没有意义。必须站在老板的角度去思考这些问题，找到一个能说得清楚的逻辑。

为什么AI提效了，但是我们的发布上线仍然这么慢？

为什么商业上没有突破？

Human在AI协作中的职责变更轨迹

我一开始对 harness 这个词也很模糊。感觉大家都在讨论，但有时候讨论的是 prompt，有时候讨论的是 MCP，有时候讨论的是测试，有时候又变成了一整套 Agent 平台。

后来我觉得可以按这个变化来理解：

Prompt -> Context -> Harness

Prompt 是告诉 AI 怎么说。Context 是让 AI 知道更多背景。Harness 是让 AI 在一个可控环境里把事情做完，并且能验证它到底有没有做对。

写代码不再是工作职责

最近基本没有手写任何代码了，全是 AI Coding。包括我面试应聘者，也很少问一些纯代码细节，因为这些越来越容易被 AI 解决，不再是最核心的竞争力。

更应该问的是：

他能不能把一个模糊问题拆成 AI 能执行的任务？
他能不能给 AI 足够准确的项目上下文？
他能不能设计验证方式，而不是看 AI 说“已经完成”就相信？
他能不能把一次失败沉淀成下一次不会再犯的规则、测试或流程？

写文档才是工作的重心

写 AGENTS.md、写各种 Skills、写项目规则、写验证脚本，这些会变成工作的核心部分。

这其实和以前写代码是类似的，只是在形式上，变成了更高层次的抽象。以前我们把业务规则写成代码，现在还要把项目知识、约束、执行流程和验收标准写成 AI 能使用的“操作系统”。

今后工程师的工作，就是如何驾驭 AI 去完成任务，也就是 harness。

这涉及几个具体的工作内容：

确定规范（Golden Principles），让 AI 遵循
将需求转述为 AI 能理解的信息
沉淀“地图导航模式”的领域知识库，提高任务完成质量
构建 AI 可观测性，让 AI 能进行自检，实现自动化
把验证前置，让结果能被自动检查，而不是靠人肉感受

工程师的工作职责：设计运行环境、构建反馈回路、把架构约束转化为可执行规则。

什么算 harness？

判断标准其实很简单：

它是否让 AI 的行为更可控、更可验证、更可复现？

如果是，它大概率就是 harness 的一部分。

比如：

代码上下文管理：让 AI 知道项目结构、模块边界、业务规则。
工具系统：允许 AI 调用 shell、测试、浏览器、数据库、MCP、设计稿、日志。
执行环境：sandbox、容器、临时分支、隔离目录。
约束规则：不能改哪些文件、必须保持哪些 API、必须遵守哪些样式。
验证系统：lint、typecheck、unit test、e2e test、视觉回归、性能检查。
评价系统：LLM judge、规则检查、golden cases、人工 review 队列。
流程编排：planner、coder、reviewer、tester，或者 generator、evaluator 这种分工。
记录与反馈：保存失败案例，生成复盘，把经验沉淀回规则或测试。

这里有一个很重要的变化：以前我们可能只关心“AI 能不能写出来”。现在更应该关心“AI 写出来以后，系统能不能抓住它的错误”。

什么不是 harness？

这个地方也要说清楚，不然很容易把任何 AI 相关的东西都叫 harness。

单独一个 prompt，通常不算完整 harness。它只是 harness 的一个零件。

一个 AGENTS.md 或 CLAUDE.md，也不是完整 harness。它只是上下文和规则层。

一个测试脚本，也不是完整 harness。它只是验证层。

一个 MCP 工具，也不是完整 harness。它只是工具层。

Cursor、Claude Code、Codex 这类工具本身，也不等于你的项目 harness。它们提供了基础能力，但你还需要围绕自己的项目补上规则、数据、测试、权限、流程和质量门禁。

这个判断对我很重要。因为如果把工具本身当成 harness，就会误以为“我已经接入 AI Coding 了”。实际上只是有了一个会写代码的执行者，还没有把它放进一套可靠的工程流程里。

AI Coding 里的 harness 应该包括什么？

如果后面要改造项目，我觉得可以先按这 8 层来想，不要一上来就做一个大而全的 Agent 平台。

第一层：任务入口。

需求模板、user story、验收标准、禁止事项。比如修改图表组件时，必须兼容旧配置，不得破坏已有 API。

第二层：项目知识。

架构说明、模块边界、术语表、业务规则、常见坑。这部分可以放在 AGENTS.md、docs/ai-context、rules 里。

第三层：工具权限。

AI 可以读文件、改文件、跑测试、查日志、启动 dev server、访问浏览器、调用 MCP，但这些权限要说清楚。

第四层：安全边界。

哪些目录不能改，哪些命令不能跑，哪些数据不能访问，是否必须走临时分支。这个不是形式主义，是为了防止 AI 在不该发挥的地方发挥。

第五层：执行流程。

不是让 AI 随便写，而是固定流程：理解需求、制定计划、小步修改、自测、汇报 diff、等待 review。

第六层：自动验证。

这是最重要的一层。至少要有：

typecheck
lint
unit test
build
关键页面 smoke test

对可视化项目，还应该加：

图表配置兼容测试
截图对比
数据 schema 测试
渲染异常检测

第七层：质量门禁。

AI 产物不能直接进入下一阶段。必须过测试、无类型错误、核心 demo 能跑、关键业务 case 不回归。

这就是我之前提到的 Adversarial Quality Gate 应该放的位置。它不是一句“注意质量”，而是一组明确的检查。

第八层：经验沉淀。

每次 AI 犯错后，不只是修 bug，而是沉淀：

新增测试
更新规则
补充反例
加入 checklist

这一步做多了，harness 才会越来越强。否则每次都是同一个人在同一个地方提醒同一个问题。

它不应该包括什么？

不要把 harness 做成一个万能大文档。

尤其不要塞这些东西：

过期的业务说明
没人维护的长篇架构史
和当前任务无关的背景故事
模糊口号，比如“代码要优雅”“注意质量”
无法自动验证的空规则

真正有用的是：

明确规则 + 可执行检查 + 失败反馈。

比如：

差规则：

注意不要破坏兼容性。

好规则：

所有已有 fixtures/configs/*.json 必须通过 render smoke test；新增字段必须有默认值；不得删除旧字段。

同样是“兼容性”，前者只能靠人提醒，后者可以被系统检查。这个差别就是 harness 的价值。

我现在怎么判断一件东西是不是 harness？

后面做项目改造时，可以用这 5 个问题判断：

它是否给 AI 提供上下文？
它是否给 AI 提供行动能力？
它是否限制 AI 乱来？
它是否能验证 AI 做得对不对？
它是否能把失败转化为下一次更稳定？

五个里面占两个以上，基本就是 harness 的组成部分。五个都占，就是比较完整的 harness。

对项目最实际的改造方向

目前最实际的做法，不是先做一个“大而全 Agent 平台”，而是先做一个 AI Coding Harness MVP。

大概可以长这样：

/ai
  /rules
    coding-rules.md
    chart-compatibility-rules.md
    visual-style-rules.md
  /tasks
    task-template.md
  /evals
    config-fixtures/
    visual-cases/
    regression-cases/
  /scripts
    ai-check.sh
    render-smoke-test.ts
    visual-regression.ts

然后规定 AI 每次改代码必须跑：

pnpm typecheck
pnpm lint
pnpm test
pnpm build
pnpm ai:render-smoke

这套东西的目标不是“让 AI 更聪明”，而是：

让 AI 每次犯错都被系统抓住。

这才是 harness 的本质。

将生成与评估分离

https://mp.weixin.qq.com/s/6UfclQF8kdhz85zaB_giTA

将执行者和评判者分离，是解决自评估失真的有力杠杆。

Separating the agent doing the work from the agent judging it proves to be a strong lever to address this issue.

一个进攻，一个防守。

这也解释了为什么 harness 不能只包含“生成”。如果 AI 既负责写代码，又负责宣布自己写得没问题，这个流程天然是不可靠的。

后面更合理的方式应该是：

generator 负责修改
evaluator 负责验证
reviewer 负责挑刺
gate 负责决定能不能进入下一步

人不一定每一步都亲自做，但人要设计这套流程，并且知道每一层什么时候可能失效。

TODOs

腾讯云harness实践，刚好是我需要的 https://mp.weixin.qq.com/s/JPhcyDc4JwRmnMQ-76A-FQ qq音乐harness https://mp.weixin.qq.com/s/yw3DvqKBIV5fIZkSG12zdA

资料

TODO：非常棒的Harness实战(Skill) https://www.bilibili.com/video/BV1ypdgBCE9B

【精】AI Harness工程实践反思：写了 52 天代码后，我们学到的 10 件事 https://mp.weixin.qq.com/s/1BOnzgdv2Qq7lF_frBJZ7w https://mp.weixin.qq.com/s/iqEacc5I8fvnmNNtbA7Tog

腾讯的Harness项目实战： https://zhuanlan.zhihu.com/p/2025587980832634840

Harness Engineering实践，如何驾驭AI这匹野马： https://mp.weixin.qq.com/s/MXU-0SuabZPVJriqr3VDTQ

Harness总结： https://www.bilibili.com/video/BV1Zk9FBwELs/

一个不懂技术的人员的开发体验： https://www.zhihu.com/question/7846282477/answer/2005297577525003253

Harness Engineering: https://openai.com/zh-Hans-CN/index/harness-engineering/ https://www.anthropic.com/engineering/harness-design-long-running-apps

【精】Harness 工程就是控制论： https://mp.weixin.qq.com/s/IISIthpTuztCT5uCGI9KdQ 原文：https://x.com/odysseus0z/status/2030416758138634583

Harness Engineering的本质是什么： https://www.zhihu.com/question/2016648624256340425/answer/2017950264284436048

我倾向于相信 Harness 会长期存在，但具体形态会随着模型能力的变化而演化。就像我们从 Makefile 演化到 CI/CD 再到 GitOps，底层逻辑没变——自动化验证和约束——但具体的工具和实践一直在变。

Harness Engineering is Cybernetics: https://x.com/odysseus0z/status/2030416758138634583

【D2 演讲实录】从上下文工程到 Harness Engineering https://mp.weixin.qq.com/s/ERSjcq9YURHvlsdTUv_Paw