DEV
← 返回笔记 | 2026-05-27
工作流

2026 年 5 月：Trellis、Aegis 与轻量澄清

5 min read

2026 年 5 月左右，工作流重点从“流程完整”转向“能长期跑”。经历 Superpowers、GSD、gstack 和 CCG 改造以后，真正需要留下来的，是可接续的项目记忆、可控的边界纪律和不过度打扰的澄清方式。

这一阶段留下来的主线，是 Trellis、Aegis 和轻量澄清流程。

Trellis 解决接续问题

Trellis 官方文档把它拆成 specs、tasks 和 workspace 三层。Specs 存项目规范，tasks 存任务上下文，workspace 存会话记录。它的核心不是让 AI 神秘地“记住一切”，而是把上下文写进文件，再在每次任务里重新注入。

这点适合长期项目的真实开发方式。

项目一长，聊天记录会断，模型会换，工具入口也会换。如果没有文件化的任务和规范，很多信息只能靠重复解释。Trellis 的价值，是把项目记忆变成仓库里的东西，而不是只存在于某一次对话里。

在 Alb 项目里，.trellis 目录承担的就是这个作用。任务、spec、工作流和会话痕迹都能留下来。之后换模型或换入口，也不需要从零讲一遍项目方向。

Aegis 解决边界问题

Aegis 更像工程纪律层。

它提醒复杂任务前先确认目标、边界、影响面、baseline 和验证方式。尤其是涉及存储、权限、删除、迁移、部署、共享逻辑这些高风险改动时，不能只让 AI 直接冲。

这和早期使用重流程的动机一致，但比完整重流程更克制。它不要求所有任务都变成大计划，而是在真正有风险的地方把边界压住。

这代表流程从“完整”走向“有分寸”。

轻量澄清解决重复提问问题

grill-me 和 grill-with-docs 的思路提供了一个提醒：需求不清时，AI 应该先问清楚，而不是直接假装理解。

但每个项目都被问一大串问题也会变成负担。很多信息其实可以从当前文档、项目规则和代码里查到。于是轻量改造的方向变成：澄清只问关键问题，优先读现有材料，不把用户拖进流程里。

这套轻量澄清不是成熟外部框架，更像吸收社区思路以后改出来的个人工作习惯。

阶段主线

这一阶段的主线比较简单。

小任务直接做，保持短路径。任务变长，就用 Trellis 承载上下文。影响面变大，就用 Aegis 压住边界和证据。需求不清，就轻量澄清。前端视觉或第二视角需要更强模型时，再由 Codex 主导唤起 Gemini。

这不是最炫的流程，但更贴近真实开发节奏。

参考来源：