Trellis、Aegis 和轻量澄清为什么留下来了

经历过 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。

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

参考来源：

• Trellis 官方文档
• Trellis Overview
• Aegis 社区讨论
• Aegis GitHub 仓库
• 本地项目证据：Alb 的 AGENTS.md、.trellis/workflow.md、.trellis/spec 和 .trellis/tasks