安装 npx skills add https://github.com/doubleuuser/rlm-workflow --skill rlm-workflow skills.sh https://skills.sh/doubleuuser/rlm-workflow/rlm-workflow GitHub https://github.com/doubleuuser/rlm-workflow 在麻省理工学院的论文《递归语言模型》展示了一种通过使用子代理将信息从上下文窗口移动到聊天外的信息存储中，从而将有效上下文长度增加到1000万个标记的方法后，针对如何在开发工作流中将其付诸实践出现了许多不同的见解。有些甚至走向将整个会话上下文存储在数据库中，以便后续检索，从而保留对所做更改的推理。rlm-workflow是另一种看法，这次有一个稍微不同的角度：重要信息，如需求、代码库分析和实施计划，应该在聊天中根本不传递。聊天实际上就是命令行接口，应仅用于调用和命令，而不是传递信息。rlm-workflow是基于从需求到实施计划、测试和手动QA的常规看板工作流进行建模的。该工作流是顺序的和阶段性的；每个阶段输出一个markdown文档，并将前一个阶段的文档作为输入。每个阶段以满足前一阶段定义的标准为门槛，并且在一个阶段结束时，其输出文档被锁定。用户首先在RLM文件夹中创建00-requirements.md文档，然后在聊天中调用工作流。它将一直运行，直到手动QA阶段，在该阶段等待用户批准后继续。在完成RLM运行后，代理会更新DECISIONS.md，这是之前实施的需求、它们的原因和链接到相应RLM文档的账本。它还会更新STATE.md，这是应用程序当前状态的概述。为了实用，这就是你的代码库的样子： rlm/00-my-first-requirements/ - 00-requirements.md（用户创建） - 01-as-is.md - 02-to-be.md - 03-implementation-summary.md - 04-manual-qa.md（测试用例是预定义的；用户在文档中输入通过/失败和备注） + /addenda/ 如果需要 总结： 1. 规格从不通过聊天传递，因此不会遭受上下文腐烂 2. 工作总是基于被锁定的文档进行，因此不能遭受退化 3. 工作流是自我文档的；它也很容易被人读懂；还可以用于为非技术利益相关者生成信息 4. 不需要将代码库建立索引到数据库中。rlm文档提供逐步披露并指引模型朝着正确的方向。应该显著减少标记的使用。 5. 在我简单的测试中，工作流改善了复杂需求的质量和成功时间 使用rlm-workflow进行辅助工程的好处包括通过工作流和全局文档改善可追踪性、减少标记使用、减少上下文腐烂、提高准确性和代码质量，以及提高速度，因为减少了返工的需求。聊天会话怎么办？忘掉它们。指令无关紧要，只有结果才重要。