核心工作流

LingXi 的显式工作流表层很小，当前核心就是两个前台能力：

1. task
2. vet

它们背后由同一个 memory 系统持续增强。

工作流主线

LingXi 当前最核心的前台工作方式是：

task → vet

task 负责把请求整理成可执行任务，vet 负责在实现前挑战任务质量。
这条工作流把最影响工程质量的两个前置环节做强，再让 memory 在后台持续积累判断。

task 在做什么

task 的职责是把粗糙请求变成工程师可直接开工的任务文档。

它会结合：

• 用户输入
• 仓库上下文
• 相关 memory

整理出一份结构化任务资产，核心内容通常包括：

• 目标
• 范围
• 约束
• 验收标准
• 功能要求
• 开发指导

LingXi 把这一步做得很严，是因为很多实现问题其实在动手前就已经埋下了：范围过大、约束缺失、验收模糊、方案过弱，都会让后续工作成本变高。

vet 在做什么

vet 的职责是在实现前挑战任务质量。

它会检查任务是否存在：

• 模糊表达
• 约束缺失
• 验收不可验证
• 范围漂移
• 风险隐藏
• 方案解释不足
• 开发指导过弱

输出会保持为结构化的 VetReport，帮助你在真正开工前就发现问题、修正问题。

Memory 如何参与工作流

LingXi 的工作流与 memory 系统协同运行。

当 task 起草任务时，LingXi 会检索当前仓库中最相关的工程记忆，把真正影响任务内容的判断写进 memory_refs。

当 vet 审查任务时，LingXi 会再次检索相关记忆，检查任务是否已经正确吸收这些标准。如果关键记忆被遗漏，vet 会把它视为明确的质量缺口。

这意味着 LingXi 的核心工作方式可以理解为：

task → vet

而是：

memory ↘
         task → vet
memory ↗

为什么工作流只有两步

LingXi 当前把显式工作流收敛到 task 和 vet，是因为这两步最直接决定工程工作开始时的质量。

这样设计有几个好处：

1. 产品边界清晰，用户更容易理解 LingXi 在帮什么忙
2. 前台交互更少，主流程更稳定
3. 可把更多精力投入到 memory、合同、状态安全和输出质量
4. 对真实工程场景更友好，因为很多场景真正需要的是“把任务写对”和“在开工前审得准”

运行方式

LingXi 在目标仓库中运行，核心 runtime 位于：

• .lingxi/（公共运行时根）
• .codex/config.toml、.codex/hooks.json、.codex/agents/（Codex adapter）
• .claude/settings.json、.claude/agents/、.claude/skills/（Claude Code adapter）

典型使用方式是：

1. 安装 LingXi 到目标仓库
2. 运行 bootstrap，生成 runtime 和 automation
3. 用 task 生成任务文档
4. 用 vet 做实现前质量挑战
5. 让后台 session-distill 持续沉淀工程判断

除了显式的 task → vet 主线，普通但有意义的仓库对话也会通过仓库级 hook（Codex 或 Claude Code）自动消费 memory。这条路径不会替代 task 和 vet，而是补足日常实现、调试和分析对话的判断上下文。

工作流的目标

LingXi 当前优先把这三件事做好：

1. 需求进入实现前足够清楚
2. 任务在开工前经得起挑战
3. 历史工程判断能持续复用

当这三件事成立时，整个项目的工程质量会比“直接让 AI 开始写”稳定得多。

下一步

• 什么是灵犀
• 记忆系统
• 快速开始