AI Coding Workflows
把 prompt 试错流变成可追踪的交付链路
适合已经在用 Claude Code、Codex 或 agent tooling 的个人与团队，把需求、计划和执行接成一条系统链路。
- Spec before execution
- Review before merge
- Knowledge after delivery
AI 编码为什么会失控
AI 编码失控，通常始于输入失真
当上下文、requirements 和 review 都没有被显式治理，生成代码就只会越来越像一次性的猜测。
上下文从零推断
LLM 直接面对裸代码库，缺少结构化、带来源依据的输入。
需求没有显式化
requirements 不成文，Plan 和 Work 很容易越做越漂。
审查缺少结构
review 退化成一次性扫描，风险无法被稳定拦截。
问题无法复用
解决过的坑没沉淀，下一次还要再从头踩一遍。
4
根级 CLI 命令
47
内置 skills 源码资产
57
内置 agents 源码资产
三项核心能力
不是更多命令，而是一套稳定的交付控制面
运行时控制、Stage-0 地基和闭环沉淀一起成立，AI 编码才会从临时对话变成可管理的工程系统。
CLI 控制面
统一安装、检查与运行时维护，让环境准备成为标准动作。
Stage-0 地基
先做 host setup 和 graph bootstrap，再把 fact-backed context 交给后续阶段。
闭环沉淀
把 requirements、review 和 docs/solutions 变成资产，而不是留在聊天记录里。
它如何运转
工作流不是命令顺序，而是协作结构
同一套 runtime 先整理上下文，再约束执行、审查与沉淀。
真正的差距在 Context 与 Harness
Prompt 之上，决定上限的是 Context 与 Harness
不是再包一层 prompt，而是把输入质量和交付纪律一起工程化。
Layer 1
Prompt Engineering
写好提示词，让 AI 输出更准确
Layer 2
Context Engineering
管理上下文，让 AI 理解项目全貌
Layer 3
Harness Engineering
工程化编排，让 AI 可追踪、可审查、可沉淀
Spec-First
闭环如何成立
Stage-0 加六阶段，形成一条完整交付链
先完成宿主准备与 graph bootstrap，再进入从方向判断到知识沉淀的主工作流。
Foundation
先完成宿主准备，再把代码库变成 fact-backed context。
00
Stage-0
先完成宿主准备与 graph bootstrap，把代码库转成结构化、带来源依据的上下文输入。
01
Ideate
当方向还不清晰时，先基于代码库筛出更值得投入的机会。
02
Brainstorm
明确目标、约束与验收标准，产出可以继续执行的 requirements artifact。
03
Plan
拆解任务、识别风险、锁定决策点，让计划成为 Work 的一等输入。
04
Work
按计划实施并交付代码、测试与可发布产物，而不是边写边漂。
05
Review
用结构化审查拦截遗漏、缺陷与高风险改动。
06
Compound
把有效实践沉淀为可复用知识，写回 docs/solutions/。
Use Cases
为真实工程团队准备的 AI 工作台
适合开发者、AI Builder、团队负责人和内部平台团队，用同一套 workflow 串起规范、执行、审查和复用。
Developer Onboarding
让新成员接手项目时，不再从零重建上下文
通过 bootstrap、fact-backed context 和 solutions 文档，把代码库经验交给下一位执行者。
- Bootstrap project context
- Reuse prior decisions
- Shorten onboarding loops
Spec-Driven Delivery
先明确需求，再让 AI 进入编码与审查
适合 feature delivery、内部工具建设和跨成员协作，减少“边写边漂”的交付风险。
- Explicit requirements
- Traceable plans
- Structured review gates
Internal Platforms
给团队沉淀一套可重复的工程工作流
适合需要工程标准、workflow discipline 和 agent orchestration 的平台团队或负责人。
- Workflow reuse
- Shared engineering standards
- Agent-ready system design
Why It Feels Different
Spec-first 把隐性的工程过程变成显性的系统
它和普通 prompt-first 工具的差异，不在于调用了多少模型，而在于是否把需求、计划、评审与知识沉淀纳入系统。
从一次性生成，变成有阶段约束的工程执行
先显式 requirements，再进入 Plan、Work、Review 与 Compound，而不是让生成结果直接定义过程。
把看不见的中间决策，变成团队能检查的过程
Spec、plan、review report 和 solutions 都成为产物，而不是散落在聊天记录里的隐性上下文。
每次交付结束后，系统都会比上一次更强
通过 compound 和知识沉淀，把解决过的问题转成下次可以直接复用的工程资产。
工程质量来自制度化 workflow，而不是更多 prompt 技巧
真正稳定的 AI coding，不是即兴 orchestration，而是宿主准备、上下文地基与流程纪律一起成立。
Open Source
先从 GitHub 和文档理解产品
看源码、读文档、跑 Quick Start，再决定它是否适合你的团队。这才是 developer tools 应有的起步方式。
真实起步路径
先完成宿主准备，再进入主工作流
1
安装与检查
npm install -g spec-firstspec-first doctor2
初始化
spec-first init --claudespec-first init --codex3
宿主准备与引导
/spec:mcp-setup → /spec:graph-bootstrap$spec-mcp-setup → $spec-graph-bootstrap 完成 Stage-0 后，再进入 /spec:ideate、/spec:brainstorm、/spec:plan 等主工作流；Codex 中使用对应的 $spec-* 入口。