今年最火的莫过于 harness engineering 了。 大家在工作编码中如何编排的,工作流实际上都有哪些变化。

今年最火的莫过于 harness engineering 了。 都在说 harness 驾驭 AI ,来说说自己的工作经验,自己在真实的工作中是如何驾驭 AI 的, 在工作或者编码中如何编排自己的工作的,工作流实际上都有哪些变化。 我先说说自己的 我认为 先的 claude code 、codex ...
今年最火的莫过于 harness engineering 了。 大家在工作编码中如何编排的,工作流实际上都有哪些变化。
今年最火的莫过于 harness engineering 了。 大家在工作编码中如何编排的,工作流实际上都有哪些变化。

今年最火莫过于 harness engineering 了。 都在说 harness 驾驭 AI ,来说说自己的工作经验,自己在真实的工作中是如何驾驭 AI 的,

在工作或者编码中如何编排自己的工作的,工作流实际上都有哪些变化。

我先说说自己的

我认为 先的 claude code 、codex 就是一个 harness Agent ; 先随着更新越来越强大,基本需要自己编排,类似工作流编排的越来越少的,但是少不代表不需要, 还是需要做一些工作的 例如

  1. 人工把控任务拆分: 仍然不要让他一次执行太大的任务,还是先拆分(虽然有 plan 模式和各种 skills 了,)、拆分后多 Agent 执行,不占用主 Agent 的上下文
  2. 上下文管理: 要给足和给清楚必要的上下文信息,流程过程以文档留存,面向 AI 编程。
  3. 约束边界清晰: 如果一个新的项目,首先要依据自己的经验给 AI 约束,例如技术栈明确、设计约束、研发机构约束等,这些现在还是需要编排好的。
  4. 其他: 前后端实现,先让 AI 完成统一的公共部分,例如 api 实现,审核后,编排前后端分别实现各自逻辑。 前端这块 UI UE 现在的 AI 还是做的比较差,必须清楚清晰的知道,甚至布局说明,@各个文件自己组合修改。

自己也整理一个 ai native 框架, https://github.com/chenguangwei/ai-native-collaboration

这个框架也存在不少问题,里面 skills 包含了太多(为了适应更多的人),造成了一些 AI 负担,自己使用过程中还是会发现不少问题,很多无法标准化和规范化,无法放入框架中。

我抛砖引玉,希望大家把自己实际工作中的经验分享出来。

来源: V2EX - 技术查看原文