ai-sdlc-framework/ai-sdlc

解决的问题

AI代理在小型绿地项目中表现出色，但在成熟代码库上却会失败。README中引用的研究表明，在成熟代码库上，使用AI工具的开发者实际上会慢19%，重构减少，稳定性下降，只有3%的开发者信任AI输出。根本原因是，随着代码的增长，没有人协调代理的工作方式——每个决策都被推迟到最糟糕的时刻，由上下文最少的行动者做出。AI-SDLC通过将承载决策前置给人类操作员，并让AI确定性执行明确规定的契约，扭转了这一局面。

工作原理

AI-SDLC是一个“决策引擎”，用结构包裹AI代理。它有五个支柱：

1. Definition-of-Ready (DoR) 门 — 拒绝调度操作员尚未真正决定的任何任务。决策目录按影响力排序未解决的问题，并附有建议和反对论据。
2. 会话层级 — cli-hierarchy up 启动一个规划器、一个调度会话和最多五个执行器，每个都是自己tmux中的Claude Code会话。调度遍历依赖图，并将已批准的任务传递给在隔离的git工作树中运行步骤0-13管线（开发代理→审查者→证明→PR）的执行器。
3. 跨工具链审查 — 来自不同工具链（例如，Claude vs Codex）的审查者并行验证更改。DSSE证明带有harness字段，并且强制执行独立性：如果Claude实现，Claude不能成为审查者。审查者串通在机械上不可能。
4. 操作员界面 — 操作员通过cli-hierarchy（status、attach、brief、down）和决策目录工作，进行监控而非输入。
5. 声明式治理 — Pipeline、Decision、AgentRole、QualityGate、AutonomyPolicy、AdapterBinding等资源作为JSON Schema资源存在。质量门运行咨询性→软强制性→硬强制性，合规姿态从欧盟AI法案、NIST AI RMF、ISO 42001中推导默认值。

安装通过Claude Code插件进行，然后执行ai-sdlc init、ai-sdlc doctor，并像/ai-sdlc execute AISDLC-42这样调度。该框架与代理无关（Claude Code、Codex、Cursor、Copilot、Aider或OpenAI兼容API）。

适用对象

希望使用AI代理进行软件开发但需要治理、可靠性和问责制的团队。它适用于成为“决策管家”的操作员——构建未解决的问题、解决它们并监控管线——而框架处理输入和橡皮图章。它针对的是不受约束的AI导致质量和稳定性倒退的成熟代码库。

亮点

• 成本不对称 — 操作员在拥有完整上下文的预先决定便宜且大多正确；执行中的AI决定昂贵且经常错误。
• DoR门 — 防止操作员实际决定之前调度。
• 跨工具链审查 — 通过构造强制审查者独立性，使串通成为不可能。
• DSSE证明 — 密封每个更改，合并遵循governance.allowMerge规则。
• Kubernetes风格的API成熟度 — 带JSON Schema、RFC流程和一致性测试套件的v1alpha1规范。
• 多SDK — TypeScript、Python、Go，以及Claude Code插件和MCP服务器。
• 声明式治理 — 质量门和合规姿态（欧盟AI法案、NIST AI RMF、ISO 42001）作为资源。