背景

使用公司现有前后端脚手架，从公司提供的 PRD 文档开始进行完整开发。整个过程推进得比较麻烦，也花了不少时间在需求拆解、项目结构理解以及开发流程摸索上。结果就是能看就是如果要交付还是有一段距离的，但是还可以进行完善。

项目难点

1. 按照项目约束开发
2. 在已有的脚手架上面开发
3. 前后端如何连接
4. 如何测试验证
5. 代码可维护

过程

技术栈 & 工具

• SpringBoot
• Vue
• MySQL
• Claude Code
• Codex CLI
• IDEA

后端

执行计划模型: minmax2.7

制作文档模型: gpt-5.4

整体效果: 执行效果很差，因为在做前端时大量需要返工

后端这部分我后来最大的感受是：Agent 不按照约束开发、遗忘性很高

我的流程大致如下：

1. 先把原始 PRD 精简成适合工程实现的上下文
2. 再写一份给 Agent 使用的执行规范文档
3. 基于规范把需求拆成最小可验证任务
4. 让 Agent 按任务逐个实现，而不是一次性生成整块业务
5. 每完成一个任务，就立即做接口级验证和错误沉淀
6. 最后再做联调和回归，而不是把测试放到最后收尾

这里最关键的，不是让 Agent “看懂需求”，而是先把需求变成它能够稳定执行的东西。

PRD 不能直接喂给 Agent

原始 PRD 更像产品文档，不是工程执行文档。它里面会混合业务目标、页面描述、角色规则、边界情况和例外说明。人看这些内容可以自己补全上下文，但 Agent 很容易把这些信息混在一起，最后生成一种“看似合理、实际偏题”的实现。

所以我的第一步不是让它写代码，而是先让它帮我做一次需求精简。精简后的内容只保留几类信息：

• 业务目标
• 核心流程
• 角色与权限边界
• 关键约束
• 异常场景和状态流转

这一步本质上是在做 Context Engineering。不是为了生成一份好看的文档，而是为了给后面的建模、接口设计和任务拆分提供干净的上下文。

规范文件不是“说明书”，而是 Agent 的执行契约

我后面补了一份 backend-plan-generation-specifications 文档，但我后来越来越觉得，它本质上不是普通项目文档，而是 Agent 的执行契约。

它的作用不是介绍项目，而是明确告诉 Agent：

• 应该怎么拆任务
• 应该遵循什么分层和编码规范
• 接口应该如何验证
• 错误出现后怎么记录和回看
• 什么状态才算真正完成

如果没有这层契约，Agent 很容易回到“想到哪写到哪”的模式；一旦有了这层契约，它才更像一个受约束的工程执行者，而不是一个自由发挥的代码生成器。

任务拆分不要按大模块，而要按最小可验证单元

这是我中途踩坑最多的一点。

如果我把一个完整业务域一次性交给 Agent，它很容易在长上下文里逐渐偏离，最后生成一堆彼此能拼起来、但实际很难联调通过的代码。表面上做了很多，实际上没有真正形成闭环。

所以后面我改成按最小可验证单元拆分任务。这个“最小单元”不一定是某个类，而更接近于：

• 一个接口
• 一个状态流转
• 一个后端能力点
• 一条前后端能走通的链路

每个任务都必须带上验收标准、依赖关系和测试入口。这样做的价值是，一旦任务失败，我能立刻知道是需求理解错了、设计错了，还是实现错了，而不是陷入“整个模块还没做完”的模糊状态。

Agent 的核心循环不是生成代码，而是“约束 -> 执行 -> 验证 -> 纠偏”

真正有效的部分，不是某一次 prompt 写得多漂亮，而是我有没有把后端开发变成一个固定循环：

• 先确认当前任务边界
• 再让 Agent 执行这个最小任务
• 写完后立即做接口级验证
• 如果失败，就回看错误模式并修正
• 如果通过，再更新状态进入下一个任务

这个流程看起来比“一次性生成整块代码”慢，但它能显著降低熵增。后端项目尤其如此，因为一旦权限、状态流转、数据约束写偏，后面每多生成一点代码，都是在放大错误。

Agent 需要“外脑”，不能只靠会话上下文

我后来越来越确认，Agent 自己的上下文记忆并不可靠。任务一长、会话一多，它就会开始重复犯同样的错误。你以为你已经提醒过它一次，但在下一轮执行里，它还是可能按旧习惯再来一遍。

所以除了 prompt 本身，我还需要给它配一套外部记忆系统，比如：

• 任务状态
• 进度摘要
• 错误模式记录
• request-test
• rules、hooks、skills 这类工程约束

这些东西的意义不是增加形式感，而是把“人的经验”从聊天记录里抽出来，沉淀成 Agent 下次还能继续遵守的环境规则。

换句话说，不要期待提醒一次就能解决问题；更可靠的方式，是把错误变成规则，把经验变成工作流。

测试不是收尾，而是判断 Agent 是否还在轨道上的反馈装置

我对这部分最大的反思是：Agent 写完代码，不代表任务完成；能通过真实接口验证，才算真正进入可交付状态。

所以我后面更倾向于把测试前置成“任务的一部分”，而不是开发完成后的附属步骤。尤其是在后端开发里，如果没有接口级验证、真实环境回归和联调检查，Agent 很容易产出一种“看起来完整、实际上不可用”的假完成状态。

测试在这里不只是用来查 bug，更重要的是持续告诉 Agent：它现在有没有偏离业务语义、工程规范和真实运行环境。

总结

Agent 在后端开发里最适合扮演的，不是一个可以自由发挥的程序员，而是一个在明确边界、明确验收、明确反馈循环下持续执行的工程代理。

真正决定质量的，不是它一次生成了多少代码，而是我有没有把需求、约束、任务拆分、验证方式和错误沉淀组织成一套可以重复运行的范式。

一套更可执行的流程是：

1. 先从 PRD 中提炼需求，与 AI 一起完成需求分析并明确目标，
2. 再沉淀业务架构、技术架构、业务流程、权限设计、领域建模、功能模块设计和数据库表设计等关键文档；这一步是让自己审核明确需求
3. 随后构建适合自己的 Agent 工作流（Hooks、Skills、Rules、ECC、Superpowers），按最小可验证单元拆分任务，单个模块结合 TDD，整体过程结合 SDD，最后通过联调与 E2E 回归测试完成闭环。

这套流程并不完美，但它至少让我逐渐从“和 Agent 反复对话”转向“用工程化方式驱动 Agent 持续交付”。

前端

模型: gpt-5.4

整体效果: 👍

和后端相比，前端这部分反而让我更快摸到一套相对有效的范式。因为前端的页面结构、交互链路和回归结果更容易被直接观察出来，所以哪些方法真的有效、哪些只是“看起来合理”，在执行过程中会暴露得更快。

前端一开始的问题，不是“不会做”，而是上下文组织方式不对

我最开始沿用的是类似后端 plan.json 大一统的思路，想把约束、规范、流程、任务信息都放进一个文件里，让 Agent 一次性读取后再执行。

但实际效果很差。文件一大，里面什么都有，Agent 虽然“看过”，执行时却不一定真的遵守。它会把需求、项目约束、接口映射、测试流程和错误处理混在一起，最后输出一种结构上很完整、但落地时经常跑偏的结果。

前端项目尤其明显，因为一个页面真正落地时，往往会同时牵涉：

• 页面组件
• 路由入口
• 接口封装
• 权限判断
• 国际化文案
• E2E 测试链路

如果这些内容都堆在一个计划文件里，信息密度一高，低质量模型很容易顾此失彼。

索引式按需加载，比大而全的单文件更接近真实开发

后来我借鉴了 Skills 的思路，先做了一个 doc/README.md 作为文档索引，把 PRD、架构说明、任务规范、接口资料、错误模式记录拆开管理，让 Agent 默认先读索引，再按当前任务按需进入对应目录。

这一步的价值很大，因为它开始把不同类型的信息分层了：

• PRD 负责回答“要做什么”
• 架构文档负责回答“应该改哪里”
• 规范文档负责回答“应该怎么改”
• 执行记录和错误模式负责回答“之前踩过什么坑”

和“一份文件塞下所有东西”相比，这种按需加载的方式更像真实工程里的检索过程，也更适合前端这种跨页面、跨路由、跨接口的开发场景。

只拆文档还不够，还要把约束变成 Rules 和 Skills

不过我后面也发现，光有索引式文档还不够。文档只是把信息分开了，但并没有强制 Agent 真的按这些信息去执行。

所以我又把其中一部分稳定规则下沉成 rules，例如项目约定、目录结构、接口封装方式、权限和路由规则；再把执行顺序、E2E 测试要求、Git 提交前提、错误处理机制下沉成 skills。

这样做之后，plan.json 本身就不需要再承担所有职责了。它只需要聚焦当前页面或当前功能的实现范围、受影响文件、依赖关系和验收标准，而不是继续充当“万能总控文档”。

这个变化很关键。因为它意味着我不再要求 Agent 从一个超大文件里自己提炼规则，而是把规则、流程和任务入口分开，让它在不同层面接受约束。

前端任务更适合按“页面闭环”来拆，而不是按技术点堆砌

从前端项目的执行结果来看，按页面拆任务比按技术点拆任务稳定得多。

比如一个登录注册页面的计划文件，不只是写“改一个 Vue 文件”，而是把与这个页面闭环直接相关的内容一起纳入：页面组件、接口封装、路由配置、登录态处理、权限初始化、国际化文案，以及对应的 E2E 测试文件。

这样拆分的好处是，每个任务天然就是一个可验证闭环。它不是做完某个局部逻辑就算结束，而是要真正走通“页面展示 -> 用户操作 -> 接口交互 -> 状态变化 -> 路由跳转”的完整链路。

这比“先改组件、再改接口、最后再想怎么联调”要稳很多，因为前端很多问题不是单点错误，而是链路断裂。

前端的反馈闭环，核心不是截图，而是真实 E2E

前端这里我另外一个很深的感受是：页面能打开，不代表任务完成；样式看起来差不多，也不代表功能真正可用。

真正有价值的反馈，还是来自真实 E2E。比如登录、注册、训练首页、消息中心、个人中心这些页面，只有真正用浏览器把流程跑一遍，才能知道页面跳转是否自然、状态是否更新、接口是否可用、权限链路有没有断。

而且 E2E 不只是“通过”或“不通过”这么简单。前端这边我后来还沉淀了 ERROR_PATTERNS.md 和后端阻塞文档，用来区分：

• 是前端实现问题
• 是后端接口返回不符合预期
• 还是测试账号、环境数据、本地约束导致的假失败

这一步很重要，因为它能避免 Agent 在错误方向上持续扩散修改。

Harness Engineering 很重要，但它并不能抹平模型能力差距

前端这部分给我最大的反思，反而不是文档结构本身，而是模型能力的影响比我一开始想象中更大。

一开始我用 minmax 2.7 去跑这套索引式加载、规则约束和执行计划，整体效果并不理想；后面换成 gpt5.4 之后，效果明显好了很多。也正因为这个对比，我越来越觉得，“Harness Engineering 可以缩小模型差距”这句话如果理解得太绝对，其实是有问题的。

更准确地说，它可以减少混乱、降低熵增、提升稳定性，但它并不能抹平模型本身的理解能力、检索能力和执行能力差异。高能力模型通常更能吃透这些上下文组织方式，也更能真正利用 rules、skills 和工作流；低能力模型即使接入了同样的 harness，也可能只是“形式上接入”，并没有稳定转化成执行质量。

换句话说，Harness Engineering 更像放大器，而不是补锅器。它能把好模型放得更稳，也能让一般模型少犯一些错，但很难把一个本身理解能力不足的模型直接拉到同样的工程表现。

前端这部分让我真正确定的一点

如果说后端让我确认了“Agent 需要强约束”，那么前端则让我更进一步确认：约束不仅要存在，还要分层；上下文不仅要完整，还要可检索；验证不仅要有，还要落到真实链路。

所以前端这套我后来更认可的范式是：

• 用索引管理上下文，而不是把所有信息堆进一个大文件
• 用 rules 固化项目约束
• 用 skills 固化执行流程
• 用页面级 plan.json 承接当前任务
• 用 E2E、错误模式和 blocker 文档构成反馈闭环

这套方法未必能保证每次都一次成功，但至少它让我从“不断补 prompt”转向“不断优化 Agent 的运行环境”，这也是我在前端部分真正觉得开始有手感的地方。

AI 协作中的失控风险

在这次实践里，我越来越强烈地感受到，AI 的问题很多时候并不是“不会输出”，而是“太容易持续输出”。如果没有边界、停机条件和验收标准，协作过程就很容易从提效工具，逐渐变成新的复杂度来源。

1. 没有明确终点的提问，很容易把协作拖入无限循环。比如让 AI 反复审核同一份文档或同一段实现，即使前面的问题已经修复，它往往仍会继续给出新的风险、优化项或补充建议。表面上看是在持续改进，实际上却缺少一个清晰的“完成定义”，最后容易演变成反复返工、范围不断膨胀的过程。
2. AI 很容易制造“文档膨胀”。随着对话轮次增加，规范、方案、计划、检查项会变得越来越长，看起来信息更完整了，但人的阅读成本也在快速上升。很多内容只是形式上更全面，并没有真正提高执行质量，反而会把关键信息淹没在冗长上下文里。
3. AI 输出的“专业感”并不等于可落地性。它很擅长组织术语、包装结构、给出看似严密的表达，让人产生一种方案已经足够成熟的错觉。但真正需要审查的，仍然是几个更朴素的问题：它是否真实对应需求、是否符合当前架构、是否能够验证、以及长期维护成本是否可接受。否则很容易接受一套表面漂亮、实际难以落地的方案。

所以回头看，和 AI 协作最需要防范的，不只是代码错误，而是上下文失控、目标漂移和文档熵增。也正因为如此，我才会越来越重视 Harness Engineering 这类方法，它的核心价值并不是“让 AI 更会说”，而是尽量让整个协作过程不至于持续失控。

Harness Engineering

Harness Engineering 这个概念最开始对我最大的影响，因为阅读 OpenAI 文章其中的"其中没有一行代码是人工编写的"打动了我，我也想实现这样的效果，想探索一种针对所有项目的范式框架，但是反而没给我方法，反而是让我一度陷入了新的执念。

因为它强调四个核心组件：

1. 上下文工程（Context Engineering）
2. 架构约束（Architecture Constraints）
3. 反馈循环（Feedback Loop）
4. 熵管理（Entropy Management）

我当时下意识会觉得，既然这是一个相对完整的方法论，那我在实践里是不是也应该把这四件事都显式做出来，否则就不算真正理解或使用了 Harness Engineering。

这个想法在后端阶段让我有些钻牛角尖。我一边还没有真正把需求吃透、目标边界也没有完全厘清，一边就想把约束、规范、流程、错误处理、任务拆分、测试机制全部一股脑塞进同一个体系里。表面上看，好像越来越“工程化”了；但实际结果并不好，尤其在后续前后端对接时，返工非常多。

现在回头看，我觉得问题可能并不只是“有没有实现四个核心组件”，而是我把 Harness Engineering 误解成了一套必须先搭完整、再开始开发的框架。可在真实项目里，如果需求本身还不够清晰，目标还不够稳定，那么过早固化大量规则和流程，反而会把错误理解提前沉淀下来，最后导致后续联调不断返工。

到了前端阶段，因为已经吃过后端的亏，我反而慢慢放开了。不再执着于“是否完整落地四个核心组件”，而是更偏向根据实际问题来设计协作环境：哪些上下文必须可检索，哪些规范必须固化成 rules，哪些执行步骤适合沉淀成 skills，哪些错误值得写进错误模式文档，哪些问题应该直接 blocker 停下来。

这一阶段的方法更像 SDD（规范驱动开发），但它又并不是完全脱离 Harness Engineering。相反，我后来意识到，自己其实已经在局部使用它了，只是没有再刻意追求“概念完整度”。比如：

• 用文档索引和分层资料做上下文工程
• 用 rules、项目约束和执行规范做架构约束
• 用 E2E、联调和 blocker 文档做反馈循环
• 用错误沉淀、任务收口和避免上下文膨胀来控制熵增

所以我现在更真实的疑惑，不是“要不要用 Harness Engineering”，而是它到底应该怎样被实践。

如果从这次开发的体感出发，我现在更倾向于把它理解成一组持续校准的原则，而不是一套必须一次性完整实现的模板。它未必要求我在项目一开始就把四个核心组件全部显式搭好，而是要求我在推进过程中不断追问：

• 当前上下文是否足够干净，能让 AI 正确检索和执行？
• 当前约束是否已经从口头提醒变成稳定规则？
• 当前反馈是否足够及时，能在偏航早期就暴露问题？
• 当前协作过程是在降低混乱，还是只是在制造更多文档和流程？

这样理解之后，Harness Engineering 对我来说就不再是一个必须证明“我已经做齐四件事”的概念，而更像一个观察和修正协作系统的框架。

至于它是否真的对 AI 有效，我现在的阶段性答案是：有效，但前提是它服务于具体问题，而不是为了概念完整而设计。它更像是在降低失控概率、提升协作稳定性，而不是直接决定模型上限。真正更可行的实践方式，也许不是先实现一套完美的 Harness Engineering，再开始开发；而是在开发过程中，先让需求、目标和闭环跑起来，再把那些真正反复出问题的地方，逐步沉淀成上下文、约束、反馈和熵管理机制。

所以很想知道有没有完整践行 Harness Engineering 的范式？

文件

关于我在实践过程中文件想要可以发我邮箱