前序

2026 年 7 月 2 日，晚上。

我刚迭代修复完 peaks-loop 处理长任务的能力——这是困扰了我两周的一个问题：当任务链条足够长（比如从 issue 分析到 PR 提交），LLM 很容易在中途"走丢"，要么忘记最初的目标，要么在某个子任务里陷入死循环、要不就是多个切片只完成一个切片就停下了，而不是 loop engineering ，是因为模型本身的设计和 Peaks Loop 本身的经济设计造成的，有可能LLM认为上下文过大，或者费用过高等因素自主停止下，我看到最多的答复是 “LLM认为这是单session不可能完成的任务”。

修复完代码后，我面临一个新的尴尬：我没有合适的验证场景。

peaks-loop 自己是用 TypeScript 写的，我平时做的全栈项目也都是 TypeScript 生态。这意味着，如果我只在 TS 项目上验证，本质上是在"用已知测试已知"——测不出跨语言的泛化能力，也测不出长任务编排在陌生代码库上的表现。

我需要一个真正的挑战。

然后我想到了 Dify——一个纯 Python 后端 + 前端的开源项目，代码量大、架构复杂、issue 列表活跃。更重要的是：我本人只会 TypeScript 和 JavaScript，是一名前端开发工程师。Python 对我来说约等于"能看懂语法，但完全谈不上熟练"。

如果 Peaks 能在 Dify 这种陌生语言、陌生架构的项目上独立完成贡献，那才算真正验证了它的能力。

---

实验设计：让 Peaks 自己挑 10 个 issue 进行小规模的 Loop Engineering 挑战

我坐在电脑前，对 Claude Code 说了一句话：

“用 peaks-solo 去 langgenius/dify 仓库，自己挑 10 个合适的 issue，逐个分析、修复、验证、提交 PR。不用担心费用问题，再全部完成后汇总通知我，期间决策你自己定”

为什么是 10 个？因为我想测试的不仅仅是“能不能修一个 bug”，而是多任务切片的编排能力——每个 issue 作为一个独立的 slice（任务切片），每个 slice 都要走完完整的分析 → 开发 → 验证 → commit → push → PR 全流程。这是一个典型的 Loop Engineering 场景：同一个流程在多个任务上循环执行，每个循环之间相互独立，但共享项目上下文和记忆。

部署完之后，我就去睡觉了。

---

第二天早上

醒来第一件事，打开 GitHub。

通知列表里躺着 10 条来自 peaks-loop[bot] 的 PR 创建通知——全部指向 langgenius/dify 仓库。10 个 issue，10 个 PR，全部提交成功。
而且我对这些 issue 的具体内容、修复方案、代码实现——一无所知。整个过程，我没有写一行 Python，没有读任何一段 Dify 的源码，没有参与任何一次决策。

所有的事情，都是 peaks 在我睡觉的时候独立完成的。

写稿的今天2026-07-05，我发现其中的一个PR已经被 Dify 的维护者 Review 并通过，合并进了主分支。
虽然改动很简单，但是我完全没有干预，更直白的说那段功能、代码是做什么，以及Python的语法我都不懂

---

Peaks 是怎么做到的？

要理解这件事为什么能发生，需要先理解 Peaks 的设计理念。

Peaks 把 AI IDE 里的"工程团队"建模成 13 个工作流技能 + 一组可执行的门禁。核心思想是：与其让一个 LLM 从头到尾干所有事（然后大概率在中途跑偏），不如把软件开发流程拆成有明确输入输出的阶段，每个阶段交给专门的"技能"去执行，中间用门禁（gates）来卡住不符合条件的输出。

具体到这次 10 个 issue 的任务，Peaks 内部经历了这样一个 Loop Engineering 流程：

Phase 0：项目认知建立

Peaks 首先在我fork完的 Dify 仓库在本地clone完成之后在项目里，扫描了项目结构、技术栈（识别出 Python + Flask + React）、测试框架、贡献指南。这些信息被写入 .peaks/memory/，成为后续所有决策的上下文基础。

Phase 1：Issue 筛选（peaks-rd 战略审计）

peaks-rd 从 Dify 的 open issues 中筛选出 10 个候选，评估标准包括：有明确复现步骤、影响范围可控、修复风险低、不涉及架构级改动。每个候选都产出一份 strategy.md，包含根因分析和影响面评估。

Phase 2～N：每个 Issue 的独立切片（Slice）

对于每一个被选中的 issue，Peaks 启动一个独立的 slice：

• 战术审计：产出 impl.json，明确改动方案
• 代码实现：修改代码（Python 代码由 LLM 生成，门禁验证语法正确性）
• 自验证：运行相关的测试套件，确保不引入回归
• commit & push：门禁全部通过后才执行 git 操作
• PR 提交：自动生成 PR 描述，包含改动说明和测试结果

每个 slice 的产物（代码改动、测试报告、PR 链接）都被记录在 .peaks/memory/ 中，供后续 slice 参考——但不是"记忆污染"，而是共享项目语境：后面的 slice 知道前面的改动已经被 PR 了，不会重复处理同一个问题。

---

关键机制：门禁（Gates）

这次实验中最让我安心的一点是：Peaks 在我睡觉时自动执行 git push，而我没有设置任何“保险栓”。

Peaks 的门禁解决了这个问题——不是靠“相信 AI 会听话”，而是靠在关键动作前强制执行可检查的条件。比如在 push 之前，门禁会检查：

• 所有修改的文件是否通过了 lint？
• 测试套件是否全部通过？
• commit message 是否符合规范？
• PR 描述是否包含必要的字段？
  任何一个条件不满足，操作就会被在 Agent 自己面前拦下，连 --dangerously-skip-permissions 都绕不过去。

---

为什么这件事值得注意？

第一，跨语言的泛化能力得到了验证。

一个只懂 TypeScript 的前端开发者，用 Peaks 让 AI 在 Python 项目上独立完成了 10 个 issue 的修复，其中 1 个被合并。这证明了 Peaks 的核心能力是流程编排和门禁约束，而不是某个特定语言的代码生成。

第二，长任务 + 多切片编排是可行的。

10 个 issue，每个都要走完整的开发流程，总耗时数小时，横跨我的睡眠时间。Peaks 没有在中途迷失方向，没有把不同 issue 的改动混在一起，没有在某个卡点上无限重试。Loop Engineering 的切片设计经受住了考验。

第三，“无人值守”不是口号。

我没有写任何脚本、没有配置 CI 触发器、没有守在屏幕前。整个过程只是一句自然语言指令 + 一个睡眠周期。

---

一个前端工程师的感慨

说实话，第二天早上看到那个被合并的 Python PR 时，我愣了好一会儿。

我不是 Python 开发者。我没有写过一行 Dify 的代码。我对那个 issue 的上下文一无所知。但 Peaks 替我完成了从问题理解到代码实现到 PR 合并的完整链路——在我不在场的时候。

这让我对"AI 编程助手"这件事有了新的理解：它不该只是"帮我更快地写代码"，而应该是"替我完成完整的工程任务"。

---

验证了什么？

这次实验验证了三件事：

1. Peaks 具备跨语言、跨项目的泛化能力——不依赖特定技术栈，核心是流程编排。
2. 多切片 loop engineering 是稳定的——10 个 issue 逐个完成，没有互相干扰，没有中途崩溃。
3. 门禁机制让无人值守成为可信的现实——AI 可以在你睡觉时工作，而你不必担心它乱来。

---

未来已来，但不止于此

坦白说，目前 peaks-loop 的能力主要聚焦在代码开发这条链路上——从 issue 到 PR 合并，正是它的"舒适区"。但也正因为这次 10 个 issue 的尝试，我更加清晰地看到了它的边界：它还不是一个通用的"数字员工"，而更像一个专注的"AI 程序员"。

不过，这个局限很快就会成为历史。peaks-loop 的 4.x 版本已经在路上了，而它的野心远不止于代码开发。在 4.x 的规划里，代码开发将只是 Peaks 能力图谱中的一小块拼图——它会被重新定位为"执行层"的一个原子技能，而更上层会引入任务规划、资源调度、多 Agent 协作、以及接入外部工具链的通用框架。

说白了，4.x 要让 Peaks 不仅能修 Bug，还能帮你做调研、写文档、分析数据、可以沉淀每次你独特操作完想沉淀下来的skill、甚至协调其他 AI 一起完成一个复杂项目——而你只需要说一句"帮我搞定这件事"。

当然，更多细节暂时还不能剧透。但可以确定的是，这次睡梦中完成的 10 个 PR，只是一个开始。

敬请期待。

如果你想现在就体验一把"AI 替你干活"的感觉，30 秒就能跑起来：

npm install -g peaks-loop
cd /path/to/your-project && claude

然后在 IDE 对话里对 AI 说：

“Peaks-solo 帮我从 xxx 仓库里挑一些合适的 issue，逐个修复并提交 PR”

剩下的，交给 Peaks。