当前这轮对话的约束是：只能做信息整理，不能修改或保存文件。所以我不能直接把文件写入仓库。
  但我先把完整 PRD 文档写好，你可以保存为：

  docs/prd-contextengine-ast-outline-unity.md

  下面是正文内容。


  ──────────────────────────────────────────────────────────────────────────────────────

  PRD：基于 ast-outline + Lightweight Unity Metadata Collector 重构 Chiron ContextEngine

  1. 文档信息

  | 项目 | 内容 |
  |---|---|
  | 文档名称 | Chiron ContextEngine 重构 PRD |
  | 目标模块 | cli/src/context-engine.mjs 及相关上下文构造流程 |
  | 方案关键词 | ast-outline、Unity Metadata Collector、C#、ContextEngine、repo-aware prompt |
  | 文档语言 | 中文 |
  | 状态 | Draft |
  | 目标用户 | Unity/C# 项目开发者、终端 AI 编程工具用户、Chiron 维护者 |


  ────────────────────────────────────────────────────────────────────────

  2. 背景

  Chiron 当前的 ContextEngine 主要通过本地启发式规则收集项目上下文，包括：

    • 根据固定 marker 文件判断项目类型
    • 根据固定源码扩展名判断是否为源码文件
    • 读取少量 key files
    • 基于 prompt 关键词匹配文件名 / 路径
    • 拼接有限的项目描述与相关文件内容

  该设计对 Node.js、Python、Rust、Go 等项目有一定效果，但对 Unity/C# 项目几乎无效。

  主要原因包括：

    1. 没有识别 .cs 源文件。
    2. 没有识别 Unity 项目标记，例如 Assets/、Packages/manifest.json、ProjectSettings/ProjectVersion.txt。
    3. 没有读取 Unity 项目关键配置。
    4. 相关文件检索只看文件名和路径，无法理解 C# 类、方法、字段和继承关系。
    5. 不理解 Unity 常见上下文，例如 MonoBehaviour、ScriptableObject、Prefab、Scene、Inspector 序列化字段等。
    6. 本地上下文输出对 Gemini / Claude 等后端模型帮助有限。

  因此，需要将 ContextEngine 从“浅层启发式扫描器”升级为“可插拔的本地上下文编排器”。


  ─────────────────────────────────────────────────────────────────────────────────

  3. 产品目标

  3.1 核心目标

  重构 Chiron 的 ContextEngine，让它能够在 Unity/C# 项目中生成高质量 repo-aware prompt context。

  具体目标：
    1. 通过 ast-outline 获取 C# 代码结构、符号、方法、依赖关系和语义检索结果。
    2. 通过轻量 Unity Metadata Collector 收集 Unity 项目配置与资源结构。
    3. 保留 Chiron 自身的 prompt workflow 能力，负责将代码上下文、Unity 元数据、git 状态和用户原始需求组合成高质量 prompt。
    4. 在没有安装 ast-outline 时，提供安全、可用的 fallback。
    5. 不将 Chiron 变成大型 IDE / LSP / Roslyn 工具，而是保持轻量 CLI 工具定位。


  ──────────────────────────────────────────────────────────────────────────────

  4. 非目标

  本次重构不追求：

    1. 完整替代 Roslyn / Rider / Visual Studio 的 C# 语义分析。
    2. 完整解析 Unity Scene / Prefab / .meta GUID 引用关系。
    3. 自动修改代码。
    4. 构建长期运行的本地索引服务。
    5. 强制用户安装 ast-outline。
    6. 将所有语言支持都改为复杂 adapter 架构。
    7. 完整实现 Unity Editor 内部状态读取。


  ────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────

  5. 用户画像

  5.1 Unity 独立开发者

  用户在 Unity 项目中使用 Gemini CLI / Claude Code / Codex 等终端 AI 工具，希望输入粗糙需求后，Chiron 能自动补充 Unity/C# 项目上下文。

  示例需求：

    • “角色跳跃有时候没反应，帮我修一下”
    • “Inventory UI 打开后按钮没反应”
    • “敌人受击逻辑有 bug”
    • “这个 ScriptableObject 配置为什么运行时没生效”

  5.2 Chiron 高级用户

  用户希望 Chiron 能在不同项目类型中自动收集上下文，但不想手动复制相关文件。

  5.3 Chiron 维护者

  维护者希望提升 repo-aware 能力，但不希望在 Chiron 内部从零实现 C# AST parser、语义搜索和依赖分析。


  ──────────────────────────────────────────────────────────────────────

  6. 当前痛点

  6.1 C# 源码不可见

  当前 SOURCE_EXTS 不包含 .cs，导致 Unity 脚本无法被优先识别为源码文件。

  6.2 Unity 项目无法识别

  当前 marker 中没有：

    • Assets/
    • Packages/manifest.json
    • ProjectSettings/ProjectVersion.txt
    • *.sln
    • *.csproj
    • *.asmdef

  导致 Chiron 无法判断项目是 Unity/C#。

  6.3 相关文件选择质量差

  当前相关文件选择主要依赖文件名和路径匹配。

  例如用户输入：

  “角色跳跃有时候没反应”

  实际相关文件可能是：

    • PlayerController.cs
    • CharacterMotor.cs
    • LocomotionState.cs
    • InputReader.cs
    • GroundDetector.cs

  但如果文件名不直接包含“jump”或“跳跃”，当前逻辑很可能找不到。

  6.4 缺少代码结构摘要

  当前 ContextEngine 可能直接读取文件前几千字符，但不能提供：

    • 类名
    • 方法名
    • 字段名
    • 继承关系
    • 行号范围
    • 方法级摘要
    • 接口实现
    • 反向依赖

  这会导致后端模型无法快速判断应该看哪里。

  6.5 Unity 非代码上下文缺失

  Unity bug 经常来自：

    • Inspector 引用缺失
    • Prefab override
    • Scene 配置
    • Layer / Tag 设置
    • Input System 配置
    • ProjectSettings
    • Packages/manifest.json
    • .asmdef

  当前 Chiron 基本不收集这些信息。


  ────────────────────────────────

  7. 方案概述

  采用双组件方案：

    1. ast-outline 负责代码智能。
    2. Lightweight Unity Metadata Collector 负责 Unity 项目元数据。
    3. Chiron ContextEngine 负责上下文编排与 prompt 生成。

  总体架构：

    • AstOutlineProvider
       • 检测 ast-outline 是否可用
       • 调用 ast-outline search
       • 调用 ast-outline digest
       • 调用 ast-outline show
       • 调用 ast-outline reverse-deps
       • 解析 JSON 输出

    • UnityMetadataCollector
       • 检测 Unity 项目
       • 读取 Unity 版本
       • 读取 package manifest
       • 读取 asmdef 列表
       • 列出重要 Unity 资源路径
       • 收集 Input System / URP / HDRP / Addressables 等信号

    • ContextComposer
       • 将用户原始 prompt、代码结构、Unity 元数据、git 状态组合成 prompt context
       • 输出自然语言上下文
       • 为后端 Gemini / Claude 提供高质量输入


  ────────────────────────────────────────────────────────────────────────────────

  8. 目标架构

  8.1 新 ContextEngine 职责

  重构后的 ContextEngine 不再直接承担所有代码理解任务，而是负责调度多个 provider：
  | 模块 | 职责 |
  |---|---|
  | ProjectSnapshot | 获取文件树、git 状态、根配置文件 |
  | AstOutlineProvider | 调用 ast-outline 获取代码结构和相关符号 |
  | UnityMetadataCollector | 收集 Unity 项目元数据 |
  | FallbackCodeSearchProvider | 在没有 ast-outline 时使用 ripgrep / 文件名检索 |
  | PromptContextComposer | 生成最终 prompt context |


  ───────────────────────────────────────────────────

  9. 功能需求

  9.1 检测 ast-outline

  系统应在运行时检测 ast-outline 是否可用。

  检测方式：

    • 执行 ast-outline --version
    • 或执行 ast-outline help
    • 超时时间建议 1 秒到 2 秒
    • 检测结果应缓存到本次进程生命周期内

  如果可用：

    • 使用 ast-outline 增强代码上下文

  如果不可用：

    • 回退到内置 fallback
    • 不应中断 Chiron 主流程
    • 在 debug 模式中提示用户可以安装 ast-outline


  ───────────────────────────────────────────────

  9.2 Unity 项目检测

  系统应通过多信号判断当前仓库是否为 Unity 项目。

  高置信度信号：

  | 信号 | 权重 |
  |---|---:|
  | ProjectSettings/ProjectVersion.txt | 高 |
  | Packages/manifest.json | 高 |
  | Assets/ | 中 |
  | Assets/**/*.cs | 中 |
  | *.sln | 低 |
  | *.csproj | 低 |
  | Assets/**/*.asmdef | 中 |

  判断规则：

    • 若存在 ProjectSettings/ProjectVersion.txt 和 Packages/manifest.json，直接判定为 Unity。
    • 若存在 Assets/ 且存在 .cs 文件，也可判定为 Unity/C#。
    • 若只存在 .csproj 或 .sln，判定为 C#/.NET，但不一定是 Unity。

  输出字段：

  | 字段 | 示例 |
  |---|---|
  | projectKind | unity |
  | language | csharp |
  | confidence | high |
  | signals | ["ProjectSettings/ProjectVersion.txt", "Packages/manifest.json", "Assets"] |


  ────────────────────────────────────────────────────────────────────────────────────────

  9.3 Unity 版本读取

  系统应读取：

  ProjectSettings/ProjectVersion.txt

  提取：

    • Unity Editor 版本
    • revision 信息，如存在

  示例输出：

  | 字段 | 示例 |
  |---|---|
  | unityVersion | 2022.3.18f1 |
  | unityRevision | 可选 |


  ──────────────────────────────

  9.4 Unity Packages 读取

  系统应读取：

  Packages/manifest.json

  提取：

    • package 名称
    • package 版本
    • 常见能力标签

  重点识别：

  | Package | 能力标签 |
  |---|---|
  | com.unity.inputsystem | Input System |
  | com.unity.render-pipelines.universal | URP |
  | com.unity.render-pipelines.high-definition | HDRP |
  | com.unity.addressables | Addressables |
  | com.unity.cinemachine | Cinemachine |
  | com.unity.netcode.gameobjects | Netcode for GameObjects |
  | com.unity.entities | DOTS / ECS |
  | com.unity.textmeshpro | TextMeshPro |

  输出示例：

  | 字段 | 示例 |
  |---|---|
  | packages | Input System, URP, Cinemachine |
  | rawPackageCount | 34 |


  ─────────────────────────────────────────────

  9.5 asmdef 收集

  系统应扫描：

  Assets/**/*.asmdef

  收集：

    • asmdef 文件路径
    • assembly 名称
    • references
    • includePlatforms
    • excludePlatforms

  用途：

    • 帮助模型理解模块边界
    • 帮助识别 Runtime / Editor 分离
    • 帮助分析跨 assembly 引用问题


  ──────────────────────────────────────────────

  9.6 Unity 资源路径收集

  系统应轻量列出以下资源路径，但默认不读取全文：

    • Assets/**/*.unity
    • Assets/**/*.prefab
    • Assets/**/*.asset
    • Assets/**/*.inputactions
    • Assets/**/Resources/**
    • Assets/**/AddressableAssetsData/**

  默认策略：

  | 类型 | 默认行为 |
  |---|---|
  | .unity | 仅列路径 |
  | .prefab | 仅列路径 |
  | .asset | 仅列路径，关键配置可读前几 KB |
  | .inputactions | 可读摘要 |
  | .meta | 默认忽略 |
  | Library/ | 必须忽略 |
  | Temp/ | 必须忽略 |
  | Obj/ / obj/ | 必须忽略 |
  | Build/ / Builds/ | 必须忽略 |


  ────────────────────────────────────────

  9.7 使用 ast-outline search 查找相关代码

  当用户输入 prompt 后，系统应构造搜索 query 并调用 ast-outline search。

  query 应包含：

    1. 用户原始 prompt。
    2. 从 prompt 中提取的英文/中文关键词。
    3. Unity 领域补充词。

  例如用户输入：

  “角色跳跃有时候没反应”

  可扩展为：

    • 原始文本：角色跳跃有时候没反应
    • 英文补充：jump, grounded, input, Rigidbody, CharacterController
    • Unity 生命周期补充：Update, FixedUpdate
    • 输入系统补充：InputAction, Input System

  要求：

    • 默认取 top 5 到 top 8
    • 优先 JSON 输出
    • 超时建议 5 秒
    • 失败时回退到 ripgrep


  ───────────────────────────────────────────────────────────────────

  9.8 使用 ast-outline digest 获取结构摘要

  对搜索命中的文件或目录，系统应调用 digest 或 outline 获取结构摘要。

  目标是获取：

    • 文件路径
    • 类名
    • namespace
    • 基类
    • interface
    • 字段
    • 方法签名
    • 方法行号范围
    • doc comments，如有

  使用场景：

    • 给模型提供代码形状
    • 避免直接塞完整 .cs 文件
    • 帮助模型判断需要展开哪个方法


  ────────────────────────────────────────────────────────────────────────

  9.9 使用 ast-outline show 展开关键方法

  当搜索结果或 digest 中出现高相关 symbol 时，系统可调用 show 展开方法体。

  触发条件：

    • 方法名与 prompt 高相关
    • 方法名为 Unity 生命周期方法，并与任务相关
    • 方法所在文件为 git modified
    • 方法包含搜索命中行
    • 方法名为 TryJump、CheckGrounded、TakeDamage、OpenInventory 等明显业务方法

  默认限制：

    • 最多展开 2 到 4 个方法
    • 单个方法最大字符数限制
    • 总上下文 token 预算限制
    • 超时失败不阻断流程


  ───────────────────────────────────────────────

  9.10 使用 ast-outline reverse-deps 分析影响范围

  当任务类型为：

    • refactor
    • bug fix
    • modify existing behavior
    • rename
    • API change

  且相关文件明确时，系统可调用 reverse-deps。

  输出给模型：

    • 哪些文件可能依赖当前文件
    • 修改时需要注意的影响范围
    • 是否需要同步检查 UI、Camera、Input、Combat 等模块


  ─────────────────────────────────────────────────────

  10. Unity 任务类型增强

  系统应在 prompt composer 中加入 Unity 任务类型判断。

  10.1 Gameplay Debug

  触发词：

    • 跳跃
    • 移动
    • 攻击
    • 受击
    • 敌人
    • 玩家
    • 手感
    • 卡住
    • 碰撞
    • 触发器

  注入检查项：

    • Update 与 FixedUpdate 职责划分
    • Rigidbody 操作是否在物理更新中
    • grounded 检测是否稳定
    • LayerMask 是否正确
    • Collider / Trigger 设置是否正确
    • Animator 状态机是否阻断逻辑


  ───────────────────────────────────

  10.2 UI Debug

  触发词：

    • UI
    • 按钮
    • 面板
    • Canvas
    • TMP
    • Inventory UI
    • 点击没反应

  注入检查项：

    • EventSystem 是否存在
    • Button listener 是否绑定
    • Canvas sorting order
    • Raycast Target
    • Graphic Raycaster
    • Time scale 是否影响 UI
    • 输入系统是否正确路由到 UI


  ─────────────────────────────

  10.3 Serialization / Prefab

  触发词：

    • Inspector
    • Prefab
    • 引用丢失
    • MissingReferenceException
    • SerializedField
    • ScriptableObject
    • 配置没生效

  注入检查项：

    • [SerializeField] 字段是否被改名
    • 是否需要 [FormerlySerializedAs]
    • Prefab override 是否覆盖运行配置
    • Scene 引用是否为空
    • ScriptableObject 是否引用了正确 asset


  ─────────────────────────────────────────

  10.4 Performance

  触发词：

    • 卡顿
    • 掉帧
    • GC
    • 性能
    • Instantiate
    • Destroy
    • GetComponent
    • FindObjectOfType

  注入检查项：

    • Update() 中是否频繁分配
    • 是否频繁 GetComponent
    • 是否频繁 Instantiate / Destroy
    • 是否需要对象池
    • 是否使用 LINQ 导致 GC
    • 是否需要 Profiler 验证


  ───────────────────────────────────

  11. Prompt Context 输出格式

  最终生成的 context 应包含以下部分：

    1. 项目摘要
    2. Unity 元数据
    3. Git 状态
    4. 相关代码结构
    5. 展开的关键方法
    6. 依赖影响范围
    7. Unity-specific 注意事项
    8. 用户原始请求
    9. 对后端模型的执行约束

  建议结构：

    • Project Summary
    • Unity Metadata
    • Relevant Code from ast-outline
    • Expanded Methods
    • Git Context
    • Unity Debugging Notes
    • User Request
    • Instructions for the coding agent


  ─────────────────────────────────────

  12. 示例输出

  用户输入：

  “角色跳跃有时候没反应，帮我修一下”

  ContextEngine 应生成类似内容：

  项目是 Unity/C# 项目。Unity 版本为 2022.3.x。项目使用 Input System、URP、Cinemachine。

  根据 ast-outline 检索，最相关的代码包括：

    1. Assets/Scripts/Player/PlayerController.cs
       • class PlayerController : MonoBehaviour
       • 方法：Awake、Update、FixedUpdate、TryJump、CheckGrounded
       • 相关原因：匹配 jump / grounded / Rigidbody / input

    2. Assets/Scripts/Input/PlayerInputReader.cs
       • class PlayerInputReader : MonoBehaviour
       • 方法：OnJump、ReadMovement
       • 相关原因：输入系统相关

    3. Assets/Scripts/Player/GroundDetector.cs
       • class GroundDetector : MonoBehaviour
       • 方法：IsGrounded、CheckGround
       • 相关原因：grounded 检测相关

  请重点检查：

    • 跳跃输入是否在 Update 中读取，但物理逻辑在 FixedUpdate 中执行。
    • grounded 检测是否受 LayerMask、Raycast 长度、Collider 设置影响。
    • Rigidbody 的 velocity / AddForce 使用是否正确。
    • Input System 是否存在输入被消费或未启用的问题。
    • 修改时保留现有 Inspector 字段，不要随意重命名 serialized field。
    • 修改后给出 Unity Editor 内的验证步骤。


  ────────────────────────────────────────────────────────────────────

  13. Fallback 方案

  当 ast-outline 不可用时，系统应回退到轻量本地检索。

  Fallback 包含：

    1. 文件树扫描
    2. .cs 文件内容 grep
    3. git changed files 加权
    4. Unity metadata collector 仍然运行
    5. 简单方法名 regex 提取

  Fallback 不要求达到 ast-outline 精度，但必须优于当前 ContextEngine。

  最低要求：

    • 能识别 Unity 项目
    • 能识别 .cs
    • 能搜索 Assets/**/*.cs
    • 能读取 Unity 版本和 packages
    • 能输出相关文件列表
    • 能注入 Unity debug checklist


  ─────────────────────────────────────────────────────────────────

  14. 配置项

  建议新增环境变量：

  | 环境变量 | 默认值 | 说明 |
  |---|---|---|
  | CHIRON_CONTEXT_PROVIDER | auto | auto / builtin / ast-outline |
  | CHIRON_AST_OUTLINE_PATH | ast-outline | 自定义 ast-outline 可执行文件路径 |
  | CHIRON_AST_OUTLINE_TIMEOUT_MS | 5000 | 单次 ast-outline 调用超时 |
  | CHIRON_UNITY_METADATA | auto | 是否启用 Unity metadata collector |
  | CHIRON_CONTEXT_MAX_FILES | 8 | 最大相关文件数 |
  | CHIRON_CONTEXT_MAX_METHODS | 4 | 最大展开方法数 |
  | CHIRON_CONTEXT_DEBUG | false | 输出上下文收集调试信息 |


  ─────────────────────────────────────────────────────────

  15. 安全与隐私

  15.1 本地处理原则

    • Unity metadata collector 只读本地文件。
    • ast-outline 只在本地执行。
    • 不应默认上传任何文件到远程服务。
    • 上传行为仅发生在后端模型调用阶段，例如 Gemini backend。

  15.2 敏感文件处理

  必须默认忽略：

    • .env
    • .env.*
    • Library/
    • Temp/
    • Obj/
    • obj/
    • Build/
    • Builds/
    • UserSettings/
    • .git/
    • *.csproj.user
    • *.suo
    • *.pdb
    • *.dll
    • *.exe

  15.3 Unity 资源读取限制

  默认不读取大型 .unity / .prefab 文件全文。

  只允许：

    • 列路径
    • 读取小型配置文件
    • 在用户明确提到 prefab / scene 时读取有限头部内容


  ────────────────────────────────────────────────────

  16. 性能要求

  | 指标 | 目标 |
  |---|---|
  | 无 ast-outline 冷启动 | 小于 1 秒 |
  | 有 ast-outline 热路径 | 小于 3 秒 |
  | 单次 ast-outline search 超时 | 5 秒 |
  | Unity metadata collector | 小于 1 秒 |
  | 相关文件数量 | 默认不超过 8 |
  | 展开方法数量 | 默认不超过 4 |
  | 输出 context 大小 | 应可控，避免超过后端 prompt 预算 |


  ────────────────────────────────────────────────────────

  17. 错误处理
  17.1 ast-outline 未安装

  行为：

    • 不报错
    • 使用 fallback
    • debug 模式提示安装建议

  17.2 ast-outline 调用失败

  行为：

    • 捕获 stderr
    • 不影响主流程
    • fallback 到 grep
    • debug 模式输出失败原因

  17.3 Unity 配置文件解析失败

  行为：

    • 跳过损坏文件
    • 保留文件路径信息
    • debug 模式记录 JSON parse error

  17.4 大项目扫描超时

  行为：

    • 降级为文件树 + git changed files
    • 限制扫描深度
    • 限制文件数量
    • 输出“context may be partial”提示给后端模型


  ─────────────────────────────────────────────────

  18. 验收标准

  18.1 Unity 项目识别

  给定一个标准 Unity 项目，ContextEngine 应识别为：

    • projectKind = unity
    • language = csharp
    • unityVersion 非空
    • packages 可解析

  18.2 C# 相关文件检索

  用户输入：

  “角色跳跃有时候没反应”

  若项目中存在：

    • PlayerController.cs
    • CharacterMotor.cs
    • GroundDetector.cs

  且文件内容包含 jump / grounded / Rigidbody 相关逻辑，则输出相关文件中应至少包含其中一个核心文件。

  18.3 ast-outline 可用时

  当系统安装 ast-outline 时：

    • 应调用 ast-outline search
    • 应能输出结构化 symbol 摘要
    • 应优先使用 ast-outline 结果

  18.4 ast-outline 不可用时

  当系统未安装 ast-outline 时：

    • Chiron 不应失败
    • 应回退到 fallback
    • 仍应识别 Unity 项目
    • 仍应输出 .cs 相关文件

  18.5 Prompt 质量

  最终 prompt context 应明确包含：

    • Unity/C# 项目身份
    • Unity 版本
    • 关键 packages
    • 相关 .cs 文件
    • 相关类 / 方法
    • Unity-specific 检查项
    • git changed files，如有


  ─────────────────────────────

  19. 测试计划

  19.1 单元测试

  测试模块：

    • detectAstOutlineAvailable
    • UnityMetadataCollector.detectProject
    • readUnityVersion
    • readUnityManifest
    • collectAsmdefs
    • composeUnityContext
    • fallbackSearchCSharpFiles

  19.2 Fixture 测试

  创建 fixture：

    • fixtures/unity-basic
    • fixtures/unity-input-system
    • fixtures/unity-urp
    • fixtures/unity-asmdef
    • fixtures/dotnet-non-unity

  验证：

    • Unity detection
    • manifest parsing
    • relevant files search
    • context output snapshot

  19.3 Mock ast-outline 测试

  通过 fake ast-outline binary 或 mock exec 结果测试：

    • search JSON parsing
    • digest JSON parsing
    • show JSON parsing
    • timeout handling
    • command failure fallback

  19.4 集成测试

  运行：

    • chiron-enhance "角色跳跃有时候没反应"
    • 验证输出包含 Unity/C# 上下文
    • 验证未安装 ast-outline 时仍可运行
    • 验证安装 ast-outline 时输出更丰富


  ─────────────────────────────────────

  20. 实施阶段

  Phase 1：Unity metadata collector

  目标：

    • 支持 Unity 项目识别
    • 支持 Unity 版本读取
    • 支持 package manifest 读取
    • 支持 .cs fallback 搜索

  价值：

    • 即使没有 ast-outline，Unity 项目也不再是空上下文。


  ───────────────────────────

  Phase 2：AstOutlineProvider

  目标：

    • 检测 ast-outline
    • 调用 search
    • 调用 digest
    • 解析 JSON 输出
    • 集成到 findRelevantFiles

  价值：

    • 显著提升 C# 代码相关文件选择质量。


  ──────────────────────────────────────

  Phase 3：Method-level Context

  目标：

    • 基于 search / digest 结果调用 show
    • 展开关键方法
    • 控制 token budget

  价值：

    • 后端模型能看到真正相关的方法体，而不是整个文件。


  ────────────────────────────────────────────────────

  Phase 4：Dependency Impact

  目标：
    • 对 refactor / bugfix 任务调用 reverse-deps
    • 输出影响范围

  价值：

    • 降低修改破坏其他模块的风险。


  ──────────────────────────────────────────────

  Phase 5：Prompt Composer 优化

  目标：

    • 重写 buildNaturalContext
    • 增加 Unity-specific prompt checklist
    • 增加 debug 输出
    • 增加 context quality report

  价值：

    • 输出更稳定、更可解释、更适合 LLM 后端。


  ───────────────────────────────────────────

  21. 风险与应对

  21.1 依赖外部二进制

  风险：

    • 用户未安装 ast-outline
    • Windows PATH 问题
    • 首次索引慢

  应对：

    • 可选依赖
    • fallback
    • debug 提示
    • 配置 CHIRON_AST_OUTLINE_PATH


  ────────────────────────────────

  21.2 ast-outline 输出格式变化

  风险：

    • JSON schema 变化导致解析失败

  应对：

    • 检查 schema 字段
    • 容错解析
    • fallback 到 text 模式或内置检索
    • 测试覆盖常见输出格式


  ───────────────────────────────────
  21.3 Unity 项目过大

  风险：

    • Assets/ 文件数量巨大
    • .unity / .prefab 文件过大
    • 扫描耗时

  应对：

    • 默认忽略大型目录
    • 限制扫描深度
    • 限制文件大小
    • 优先 git changed files
    • 优先 Assets/Scripts/**/*.cs


  ───────────────────────────────

  21.4 过度注入 Unity checklist

  风险：

    • prompt 变啰嗦
    • 对简单任务干扰模型

  应对：

    • checklist 按任务类型注入
    • 限制长度
    • debug 模式展示注入原因
    • 用户可通过 env 关闭


  ────────────────────────────

  22. 成功指标

  22.1 定量指标

  | 指标 | 目标 |
  |---|---|
  | Unity 项目识别准确率 | 大于 95% |
  | C# 相关文件召回率 | 明显高于当前版本 |
  | 平均 context 构造耗时 | 小于 3 秒 |
  | 未安装 ast-outline 时成功运行率 | 100% |
  | 输出 prompt token 增量 | 可控，不超过预算 |

  22.2 定性指标

    • Unity 用户能明显感知 Chiron “知道这是 Unity 项目”。
    • 后端模型能更快定位相关 .cs 脚本。
    • 对常见 Unity bug，prompt 中能自动提示生命周期、Inspector、Prefab、Layer 等风险。
    • Chiron 不再表现得像只适配 Node/Python 项目。


  ──────────────────────────────────────────────

  23. 推荐最终形态

  最终的 ContextEngine 应该从当前的：

  “用少量硬编码规则猜项目和相关文件”

  升级为：

  “本地上下文编排器”

  即：

    • 使用 ast-outline 获取代码结构与相关 symbol
    • 使用 Unity metadata collector 获取项目语义
    • 使用 git context 获取当前工作状态
    • 使用 prompt composer 生成面向 LLM 的结构化上下文
  一句话总结：

  Chiron 不需要自己成为 C# / Unity 代码智能引擎；它应该把 `ast-outline` 作为代码导航层，把 Unity metadata collector 作为项目语义层，然后专注于生成高质量 prompt context。