用 AI 客户端分析本地项目，先让它回答“入口在哪里、数据怎么流动、结论依据是什么”，再决定是否修改。不要第一句话就要求重构整个项目。把可访问目录、任务边界和交付格式说清楚，能够减少把无关文件当依据、漏掉关键依赖的情况。
使用墨刀 AI 客户端处理本地项目时，可以围绕一个任务整理材料与分析结果；涉及读写文件和执行命令的步骤，应以当前功能与本次授权范围为准。
先限定项目范围，再让 AI 建立理解
以订单管理项目为例，本次任务是“给订单列表补齐空状态”，需要读取订单页面、数据请求、相关组件和测试；不需要读取客户导出文件、密钥或全部历史日志。开始前列出可读目录、禁止访问文件和是否允许写入。将源码、文档、生成物分开，避免大量依赖和构建文件挤占有效上下文。
| 本次材料 | 分析用途 | 要得到的结果 |
|---|---|---|
| 订单页面与路由 | 找出列表入口和呈现逻辑 | 页面入口、空状态显示条件 |
| 请求封装与数据类型 | 分清无数据、加载中和请求失败 | 数据状态及对应文件位置 |
| 现有组件与样式约定 | 判断是否复用已有空状态组件 | 组件名称、可用属性与限制 |
| 相关测试和项目说明 | 确认验证办法 | 已有测试命令及缺失用例 |
先提出只读任务：只读取 src/orders、src/components 和 tests/orders，找出订单列表的入口、请求和状态处理。不要修改文件，不读取 .env。每条结论附文件路径和具体位置，未知项单独列出。路径是写法示例，应替换成实际项目路径。
要求分析结果同时给出证据和未知项
不要接受“项目用了组件化架构，建议优化体验”这样的摘要。可复查的结论应写成：订单列表由哪个文件渲染、哪个函数发起请求、什么条件显示加载、响应为空时走到哪个分支。若 AI 没找到权限或分页逻辑，应说“本次范围内未找到”，而不是推断项目没有这项规则。
- 找入口：从路由和页面文件定位用户实际看到的列表。
- 追数据：检查请求、响应类型、筛选和分页如何影响结果。
- 读约定：确认空状态组件、错误反馈和文案的已有写法。
- 列差异：指出当前行为与目标行为之间的差距，不顺手改无关模块。
- 提方案：给出最少需要修改的文件、影响范围和待确认问题。
把“没有数据”拆成四种可实现的状态
| 情况 | 页面应表达什么 | 实现前确认 |
|---|---|---|
| 首次进入且没有订单 | 解释这里将显示什么，并提供创建入口 | 用户是否有创建权限 |
| 筛选后没有结果 | 说明当前条件无匹配，提供清除筛选 | 清除哪些条件，是否保留排序 |
| 请求失败 | 显示失败和重试，保留用户输入 | 重试是否复用当前筛选/分页 |
| 无查看权限 | 说明无法查看并提供合适处理路径 | 权限由服务端校验，页面不泄露数据 |
这四种情况不能都显示“暂无数据”。让 AI 根据已有代码指出每种状态的判断位置，再请产品确认文案、研发确认条件。确认前先输出方案，不把未经确认的业务规则写进实现。
从只读分析转入修改
范围和行为确认后，再发出执行任务：按已确认方案只修改订单列表和相关测试。沿用现有空状态组件。完成后列出修改文件、每处变更原因、运行的检查及未通过项，不执行部署。如果项目使用 Git，先保存当前改动，在可回退的分支或副本上操作。
读取本地文件、写文件、运行命令是不同动作。根据当前客户端配置和授权范围决定允许哪一步；涉及删除、生产配置或数据库迁移，应单独确认实际操作。AI 能整理代码和建议，不能代替项目权限、业务确认或研发验收。
一份可复查的项目分析应长什么样
分析报告不必逐文件复述代码，可以按“发现—依据—影响—下一步”组织。下面是订单空状态任务的填写方式，路径和函数名需要替换成项目中实际找到的内容：
| 报告项 | 填写内容 |
|---|---|
| 发现 | 筛选无结果和首次无订单共用同一段文案 |
| 依据 | 列出渲染条件、数据加载位置和相关测试位置 |
| 影响 | 用户不能判断应该新建订单还是修改筛选 |
| 最小方案 | 保留已有组件，按筛选是否启用区分文案和动作 |
| 待确认 | 用户无创建权限时，空状态是否只提供帮助入口 |
如果 AI 只给出文件路径，但没有说明对应条件如何支持结论，仍需要继续追问；如果说“可直接复用组件”，就核对该组件是否允许传入按钮、是否已有无权限状态。证据越具体，后续修改越小。
长任务如何保持上下文准确
完成一轮分析后保存一份项目摘要，只保留已核实的入口、规则、限制、待确认项和下一步。继续工作时先提供摘要和本次差异，不反复投喂整个目录。代码变化后让 AI 重新核对受影响文件，避免沿用旧路径和旧判断。
把“已读取”“已推断”“已验证”分开记录。例如找到测试脚本是已读取，认为测试覆盖了空状态是推断，实际运行并查看结果才是验证。这个区分能让团队知道哪些结论可以直接使用，哪些仍需研发确认。
怎样验收分析与修改
先核对引用的路径是否真实、结论能否从文件中找到，再看差异是否只覆盖本次任务。运行项目已有的静态检查和相关测试；命令失败就记录输出和原因，不把“已经生成测试”写成“测试通过”。最后逐项检查首屏无数据、筛选为空、请求失败和无权限状态。
交付包保留任务说明、文件证据、方案选择、实际差异、验证命令与结果、未解决问题和回滚位置。另一位成员应能用这些材料复查，而不必重新询问整个聊天过程。
可以先在墨刀 AI 客户端选取一个已授权的订单模块，提交本文的只读分析任务，检查它返回的路径证据与未知项。确认分析可靠后，再把一个边界清楚的空状态改动拆成下一项任务。
