AI 时代，开发将如何改变

从 Prompt Engineering 到 Harness Engineering，以及我的一些思考

李
李昇宰 · NHN AD
平台服务实验室 · 2026 年 6 月 · 约 7 分钟

写在前面

大家好。我是 NHN AD 平台服务实验室的李昇宰。在这篇文章里，我想分享从传统开发到 Harness Engineering 的变化，以及我对此的一些思考。

用手一块块垒砖

我的第一行代码始于 2018 年的大学。因为隶属软件融合学院，C 语言和 Python 是必修课。在遇到双重 for 循环打星号和指针之前，我甚至还产生过"我是不是编程天才？"的错觉。那个年代的编程，就是通过搜索和向学长们零零散散地请教，像一块块垒砖一样把程序搭建起来的活儿。

搜索 Java 双重 for 循环打星号 Main.java 12345 输入中… 靠搜索学习，一行一行亲手敲——像垒砖一样
用搜索查找方法、亲手敲代码的那个年代

但如今呢？开发者不再搜索，也不再一行行地写代码。每件事的开始和结束都有 AI 在场，开发者的角色也从"写代码的人"变成了"定义并解决问题的人"。事实上，自从进入 NHN AD 以来，我没有亲手写过哪怕一行代码。

如果不再亲手写代码，开发者该做什么？

把砖垒得更好的方法

我使用 AI 是从 2023 年、在 NHN Academy 学习那段时期开始的。那是个一打开 YouTube 和 Instagram，简历提示词、写作提示词、开发提示词满天飞的时期。我也顺着那股潮流，总是先写下这样的指令。

ChatGPT 你是一位有 10 年经验的资深 Java 开发者。 作为对 SQL 和整洁代码有深厚造诣的专家， 请编写代码并给出反馈… 当然可以。要我看哪段代码呢？
Prompt Engineering——对模型"说什么话"就是全部

这种方法论被称为 Prompt Engineering。关注的核心只有一个，那就是 "该对模型说什么话"。即赋予角色，并尽可能详尽地说明情境与诉求的方式。它直观且效果也不错，所以 NHN AD 的服务中也应用了 Few-Shot 和 ReAct 提示。

Instruction 角色·规则·示例 OpenAPI Schema 工具定义 Agent 解析 → 选择工具 工具调用 生成响应
Instruction 与 Schema 规定了 Agent 的行为 · 这是去除服务特化内容后的通用结构

我在这种方式里停留了很长时间。大部分代码都是亲手写的，遇到卡壳或难懂的概念时才去问 AI。

垒砖时代的终结

然而到了 2025 年，有一件事改变了我。那就是 Claude Code。它意味着从 GUI 到 CLI，以及从 Prompt Engineering 到 Context Engineering 的转变。

过去，所需的代码和文件都由我亲手填进去，再用提示词来控制模型。但自 Claude Code 之后，AI 直接访问文件系统和工具，自己读文件、改代码、跑测试。关注点也从 "该说什么话" 转移到了 "该放进什么信息"。

claude code — CLI › 读一下 docs/spec.md 把结构理清楚 ● Read docs/spec.md › 改一下 src/UserService.java 的 validate() 函数 ● Edit src/UserService.java › validate() ● Bash ./gradlew test ✓ passed ›
只要指明路径、文件与函数，Agent 就会自己读取、修改并验证

把核心要点、约束和记忆分别记录在文件里，再用 MCP 连接工具，让它在需要时只取所需的那一部分。那段时间，我脑海里同时盘旋着 "这下不需要开发者了吧，找工作可怎么办？" 和 "现在真能飞快地做出东西来了？"。差不多从这时起，我亲手敲代码的频率降低了，面试中也开始问起 Claude Code、Agent 与 Skill、Context Window，这是属于 Context Engineering 的时代。

面试官 Q 你用过 Claude Code 吗？ Q 子 Agent 和 Skill 你是怎么用的？ Q Context Window 你是怎么管理的？ 嗯，那个……
Claude Code、Agent 与 Skill、Context Window

死的砖块，活的设计

2026 年的当下，看起来是 Harness Engineering 的时代。骨架与 Context Engineering 相似，但以更精炼的方式设计系统本身。定义系统提示词，使用子 Agent，把确定性的部分和非确定性的部分分开管理。用 Rule 来约束 Agent 不让它跑偏，即使它无视指南，也强制让 lint、类型检查、编译以机械的方式把问题揪出来。

下面是我在工作中使用的结构。把任务按角色分给各个 Agent，验证中暴露的失误不止于当下修补，而是反馈到 Skill、记忆、Rule 中，让它不再重演。

计划 PM Agent task.md · spec 实现 后端·前端 ·基础设施 Agent 验证 QA·Reviewer lint·测试·CI 集成 Git Agent 提交 · PR 清理 GC Agent 迁移遗留物 把失误反馈到系统中 Skill · 记忆 · Rule · Agent 角色更新 发现失误 反馈
按角色划分的 Agent 分担计划→实现→验证→集成→清理，失误则反馈到 Skill·记忆·Rule · 这是去除公司内部实现后的通用结构
repo/
├─ .claude/
│   ├─ commands/   new-feature · new-bugfix · new-hotfix …
│   ├─ agents/     pm · 后端 · 前端 · 基础设施 · qa · reviewer · git · 清理
│   └─ skills/     把重复工作·诀窍固化下来
├─ ai/          Agent · Lambda · 批处理
├─ app/
├─ domains/     领域逻辑
├─ modules/     api-client · db-client · storage-client
├─ infra/       IaC · 部署
├─ docs/        spec · 设计记录
├─ scripts/
└─ .legacy/     迁移陈旧的产出物
文件夹示例——命令·Agent·Skill 与工作产出物在同一个仓库中一起管理 · 这是去除公司内部内容后的通用结构

如今，我既不再一行行写代码，也不再每次都重新写一长串提示词。只要把该做的事定义好，Agent 就会自己读取所需的文件、修改代码、跑测试来确认结果。我的角色收窄到了 定义要做什么，并验证其结果。

未来的旅程

我现在正在跑一个自动推进某个比赛项目的实验。每天一到约定的时刻，我笔记本上的 LaunchAgent 就会唤醒无头模式的 Claude，由它自己整理当天要做的事并执行，再回过头审视自己的结果，留下一份当日报告后休眠。即便我不插手，第二天还会重复同样的事。

LaunchAgent 每天约定的时刻 无头模式 Claude 整理待办 执行任务 读取·修改·执行 自我审视 再次确认结果 报告 · 结束 留下当日记录 第二天，不用插手也会重复同样的事
每天自己醒来，整理待办、执行、审视、留下报告的以天为单位的自动循环
自动推进比赛项目的仓库——每天生成 task、执行、自我验证、累积报告
每天生成并执行 task，之后自己验证并累积报告

结果就是，即便在我没有亲自提交的日子里，仓库中也按日期一点一点地积累着工作记录。

每天累积的按日提交——人和 Agent 一起作为 author 被记录下来
人和 Agent 一起作为 author 留下的、按日累积的提交

接下来，我打算打磨这套结构，尝试构建一个为 韩国电子政务标准框架（eGovFrame） 做贡献的系统。我认为，如果是一套设计良好的系统，它就能走到自己向他人编写的真实代码库留下贡献的那一步。我会在 电子政务框架开放社区 继续这段旅程。

谢谢大家。

参考