Project Analyst 项目分析 Skill

Project Analyst：让 Agent 先看懂你的项目

AI Coding Agent 已经能够编写代码、修改文件、运行命令甚至自主完成一系列开发任务。 但在真实的软件工程中，还有一个经常被忽略的问题：

Agent 会写代码，不代表 Agent 已经真正理解当前项目。

当开发者第一次接手一个陌生代码仓库时，通常不会立即开始修改代码。 我们首先会查看目录结构、阅读 README、识别技术栈、寻找程序入口、检查配置文件，再逐步梳理模块关系、启动方式、Runtime、数据库和外部服务。 只有建立基本的项目认知之后，才适合进入真正的开发阶段。Project Analyst 正是围绕这个过程设计的。

一个面向“项目理解”的 Agent Skill

Project Analyst 是柯影智航中的项目分析 Skill。 当用户提出：

帮我快速了解一下这个项目，我准备接手继续开发。

Project Analyst 会引导 Agent 从当前工作区寻找证据，并逐步建立项目认知，而不是直接进入代码修改流程。 它重点关注几个方面：

它最终解决的不是“帮我解释几个文件”，而是：

帮助开发者和 Agent 快速建立一个陌生软件项目的工程认知。

从目录扫描走向工程分析

Project Analyst 并不把“扫描目录”本身当作项目分析。一个典型的软件项目可能同时存在：

Frontend
Backend
Database
Runtime
Configuration
Build System
External API
Deployment
Scripts
Tests
Documentation

这些内容之间存在实际的依赖和运行关系。因此 Project Analyst 更关注完整的分析链路：

用户提出项目分析需求
          ↓
识别当前工作区
          ↓
扫描项目结构
          ↓
识别技术栈
          ↓
寻找程序入口
          ↓
梳理启动 / Runtime 链路
          ↓
分析核心模块
          ↓
检查配置与基础设施
          ↓
寻找代码和配置证据
          ↓
区分事实 / 推断 / 未知
          ↓
生成项目分析结果

Project Analyst 希望让 Agent 不只是“读代码”，而是逐步形成对整个工程系统的理解。

证据，比看起来合理更重要

Project Analyst 设计中的一个重要原则是：没有足够证据，就不要把推测写成事实。 例如用户询问：当前生产环境使用的是什么数据库版本？ 如果项目中的配置、部署文件和文档都无法确认生产环境的真实版本，那么合理的回答应该是：当前项目证据不足，无法确认。 而不是根据依赖文件中的某个版本号直接推测生产环境。因此 Project Analyst 会尽量区分：已确认事实 能够从代码、配置、文档等项目内容中找到直接依据。 合理推断，根据多个工程线索能够形成判断，但仍然需要进一步验证。 未知，当前项目没有足够证据支持结论。 对于项目接手和技术审查而言，这种区别往往比生成一份内容丰富的报告更加重要。

Project Analyst 不负责所有开发任务

Skill 的能力边界同样重要。 例如：分析一下当前项目。 属于 Project Analyst 的典型任务。 而：帮我修复当前项目的登录问题。已经属于明确的代码修改任务。 Project Analyst 不应该因为自己拥有项目分析能力，就抢占所有和“项目”有关的任务。因此项目目前也在针对 Skill Routing 建立负向测试。 一个成熟的 Skill 不仅需要知道：什么时候应该工作。 还应该知道：什么时候不应该由自己工作。

建立可验证的 Skill

Project Analyst 当前已经建立第一组 Evaluation Cases，对典型行为进行验证。 目前测试范围包括弱触发项目分析、新开发者接手项目、架构分析、启动与 Runtime 链路分析、技术风险与证据判断、只读约束、信息不足处理以及负向路由。 我们希望逐渐验证：

一个 Agent Skill 能否从“写了一段 Prompt”，进一步成为一项行为稳定、边界明确并且可以持续测试的 Agent 能力。

因此，v0.1.1 并不意味着 Project Analyst 已经完成。相反，它代表这个 Skill 开始进入系统化验证阶段。