Spec Coding的新一代体验：Aegis
20万star明星项目superpowers的升级版
如果你也遇到过“AI 写得很快，但任务最后还是要人重新收拾”的情况，Aegis 想解决的正是这个问题。
过去一年，AI coding agent 的能力进步非常快。它们能读代码、改文件、跑测试、写文档，甚至能跨多个步骤完成一个功能。
但很多团队真正遇到的瓶颈，已经不是“AI 会不会写代码”，而是：
· 它有没有先搞清楚任务边界？
· 它有没有读项目里的真实基线和约束？
· 它是不是一边修 bug，一边偷偷加了新的 fallback？
· 它说“完成了”的时候，有没有 fresh verification？
· 长任务压缩上下文或换会话后，它还能不能接得住？
· 架构漂移、ADR、旧逻辑退休这些事情，有没有被及时记录？
这就是我们做 Aegis 的原因。
Aegis 不是另一个 IDE，也不是新的 AI 模型。它是一个面向 AI coding agent 的 Method Pack：一套可安装、可触发、可验证的工作方法，让 agent 在真实工程任务里更稳、更清楚、更可审计。
GitHub：github.com/GanyuanRan/…
Gitcode: gitcode.com/m0_67899281…
一句话理解 Aegis
Aegis = 给 AI coding agent 用的工程纪律层。
它让 agent 在动手之前先判断任务类型、读取必要基线、明确影响面和验证方式；在完成之前拿出证据，而不是只说“应该好了”。
Aegis 当前的正式定位是：
Aegis Method Pack (runtime-ready)
这句话很重要。它意味着 Aegis 现在负责的是：
· skills 和 workflow discipline
· 多宿主可安装的方法包分发
· 任务 framing、debugging、planning、review、verification 等工作流
· runtime-ready 的 drafts / hints / projections
· evidence bundle、checkpoint、drift check 等可交接材料
它不负责：
· 最终 runtime core
· authoritative GateDecision
· authoritative PolicySnapshot
· 最终 completion authority
换句话说，Aegis 不冒充“最终裁判”。它先把 agent 的工作过程变得可靠。
AI Coding 真正缺的，不只是更强的模型
很多 AI coding 失败案例，看起来像“模型没写对”，但根因往往是流程问题。
比如一个登录 bug：
· 用户说“偶发跳回登录页”。
· Agent 直接打开 auth 文件开始改。
· 它可能补一个重试，或者加一个兜底刷新。
· 测试跑了一个局部用例，返回“已修复”。
· 结果线上还有另一个 consumer 仍然走旧 token owner。
这里真正缺的不是“更努力写代码”，而是：
1. 先定义问题：复现条件是什么？影响谁？验收标准是什么？
2. 再调查 owner：token 的 source of truth 是谁？producer / consumer 在哪里？
3. 再制定最小切片：改哪个 owner，退休哪个 fallback？
4. 最后验证：用什么命令、日志、测试证明真的覆盖了风险？
Aegis 把这些动作变成 agent 的工作纪律，而不是靠每次 prompt 临场发挥。
Aegis 怎么工作：先路由，再执行
Aegis 的入口不是“所有任务都走一套重流程”。相反，它很强调 fast path cheapness：简单任务就轻量处理，复杂任务才进入完整 workflow。
一次典型任务会先经过路由判断：
· 简单问答、版本状态、小文案：fast path
· bug、失败测试、异常行为：systematic-debugging
· 产品、架构、contract、跨模块不清：brainstorming
· 已批准需求，需要拆任务：writing-plans
· 多步骤、易丢上下文任务：long-task-continuation
· 完成、发布、交付前：verification-before-completion
这样做的好处是：Aegis 不会把简单问题复杂化，也不会让高风险任务裸奔。
Aegis 的 6 个核心亮点
1. Baseline-first：先看项目事实，再动手
Aegis 鼓励 agent 在非简单任务前先读项目的 authority source：README、AGENTS.md、ADR、current docs、架构文档、测试说明等。
这能减少一种常见错误：agent 只根据当前对话印象行动，却忽略仓库已经写明的边界和约束。
2. Evidence-before-claims：完成前必须有证据
Aegis 不鼓励 agent 轻易说“完成了”。
在 verification-before-completion 中，agent 需要说明：
· 跑了什么命令或检查
· exit status 是什么
· 覆盖了哪些范围
· 哪些范围没有覆盖
· 剩余风险是什么
这会显著降低“看起来好了”的假完成。
3. Debugging 不先猜修复，而是先找 owner
系统性 debugging 不应该从“我来改几行”开始，而应该先稳定症状、复现路径、真实 owner、数据流和回归证据。
Aegis 强调 root-cause-first，避免 bug fix 变成 fallback 堆叠。
4. Long-task continuation：长任务不中断
真实工程任务经常跨很多步骤：调研、计划、实现、测试、review、修复、发布。
Aegis 用 todo checkpoint、resume hint、drift check、evidence refs 等方式，让长任务在上下文压缩、会话重启或多 agent handoff 后仍然能接续。
5. Dual-track governance：修复和退休旧逻辑一起看
很多系统变复杂，不是因为新逻辑错，而是旧逻辑没有退休。
Aegis 要求在 bug fix、refactor、compat cleanup、governance cleanup 里同时看两条线：
· Repair Track：修了什么，证据是什么。
· Retirement Track：旧 owner、旧 fallback、旧路径如何处理。
这能减少“修一次，多一层历史包袱”的工程腐蚀。
6. ADR Auto Backfill：重要决策不要只留在聊天里
Aegis v1.4.3 强化了 completion-time ADR Backfill Check。
当一次任务产生了架构决策、兼容边界变化、baseline sync 问题或旧逻辑退休信号时，agent 会在完成前检查是否需要：
· 创建 ADR
· 修订 ADR
· supersede 旧 ADR
· 或明确跳过原因
这不是 runtime authority，而是方法包层面的 advisory signal。它的价值是提醒团队：重要决策不要只留在一次聊天记录里。
一个具体例子：修 bug 时 Aegis 会改变什么？
没有 Aegis 时，常见流程可能是：
用户：登录后偶发跳回登录页，帮我修一下。
Agent：我检查 auth 逻辑，做了一个 token refresh fallback，测试通过，完成。
有 Aegis 时，agent 更可能这样工作：
- 判断这是 bug / regression，进入 systematic-debugging。
- 先确认复现条件、影响范围和验收标准。
- 读取 auth 相关 baseline / docs / tests。
- 找 token producer、consumer、cache、refresh owner。
- 区分真实缺陷、架构漂移和历史 fallback。
- 做最小修复，并说明是否需要退休旧路径。
- 跑测试和必要回归。
- 完成前提供 Evidence Card。
- 如果产生架构决策，触发 ADR Backfill Check。
这不是为了让流程变慢，而是为了少返工。
为什么说 Aegis 适合团队使用？
个人使用 AI coding agent，最怕的是它“自信但没证据”。
团队使用 AI coding agent，更怕的是：
· 每个人 prompt 风格不同，agent 行为不稳定。
· 重要约束只在口头或聊天里，没有进入仓库事实源。
· review 只看 diff，没有看 baseline 和 ADR。
· 长任务跨会话后，新的 agent 不知道之前为什么这么做。
Aegis 的价值在于把这些东西变成可复用的 method layer：
· 让不同 agent 使用相似的问题定义方式。
· 让完成声明绑定证据。
· 让 review 关注 baseline/current authority。
· 让长任务有 checkpoint 和 resume state。
· 让重要架构信号进入 ADR backfill 检查。
对团队来说，这比“某一次 prompt 写得很好”更重要。
安装方式：让你的 Agent 自己装
Aegis 支持多种 AI coding host 的安装路径，例如 Codex、OpenCode、Claude Code、CodeBuddy、DeepSeek-TUI、Trae 等。
如果你使用的是 Codex / Claude / OpenCode 这类 agent，可以直接让它读取仓库并选择正确安装方式：
Please read the installation instructions in github.com/GanyuanRan/… carefully, identify the correct path for my AI coding host, install Aegis globally, restart or reload the host if needed, then run complete-install verification from the Aegis method-pack root with python scripts/aegis-doctor.py --write-config --json. Treat the install as complete only if the JSON output includes "ok": true, "workspaceSupport": "available", and "configStatus": "configured"; if the host uses a separate skill discovery directory, also verify it with --discovery-root <path>.
如果你已经安装过，也可以让 agent 更新到最新版本，并重新跑 doctor 验证。
Aegis 不是什么？
为了避免误解，这里也说清楚 Aegis 的边界。
Aegis 不是：
· 新 IDE
· 新模型
· 自动替你做最终架构裁决的 runtime core
· 让所有任务都变重的流程框架
· 用 prompt 假装拥有 completion authority 的系统
Aegis 是：
· agent-facing 的方法包
· workflow discipline
· evidence / baseline / verification 的执行习惯
· 面向未来 runtime core 的 runtime-ready 输入和投影
这也是它现阶段最实际的价值：不用等完整平台落地，你现在就可以先让 AI coding agent 工作得更稳。
适合谁尝试？
如果你符合下面任意一种情况，Aegis 值得试一下：
· 你经常让 AI agent 修 bug、写功能、重构或整理文档。
· 你遇到过 agent 说完成了，但后来发现没有验证充分。
· 你的项目有 ADR、baseline、架构约束或复杂兼容边界。
· 你希望团队里的 AI 使用方式更统一，而不是每个人各写各的 prompt。
· 你需要处理长任务、多步骤任务或跨会话任务。
最后
AI coding 的下一阶段，不只是“生成更多代码”。
更重要的是：让 agent 能够理解目标、尊重边界、保留证据、处理长任务，并在完成前知道自己还缺什么。
这就是 Aegis 想做的事情。
如果你也希望 AI coding agent 不只是快，而是更稳、更清楚、更可审计，欢迎试用 Aegis：
GitHub：github.com/GanyuanRan/…
也欢迎 star、提 issue，或者把你真实使用中的任务样本反馈给我们。
