日常开发工作流

这一章解决什么问题

前面的章节讲单个功能，这一章把它们串成一天真实的开发流程。

目标不是记住所有按钮，而是形成一套稳定习惯：打开项目、同步代码、定位问题、修改、运行检查、提交。

每天开始前

1. 打开项目

cd G:\llmProject\myOpenProject\Zed编辑器实战教程\app
zed .

如果是团队项目，优先打开仓库根目录，不要只打开里面某个子目录。这样 Git 面板、搜索、任务和语言服务更容易正常工作。

2. 看当前状态

打开终端：

git status
git pull

打开 Git 面板，确认工作区干净，或者知道有哪些未提交改动。

3. 启动项目

如果项目已经配置了任务，优先从任务启动；没有任务就用终端：

npm run dev

文档站、前端项目、后端项目都一样：先让项目跑起来，再开始改。

开发过程中

找文件

优先用 Ctrl+P。文件树适合浏览结构，快速打开文件还是命令更快。

查功能

不知道命令在哪里时，用 Ctrl+Shift+P 打开命令面板，输入关键词。比如：

• settings
• tasks
• git
• terminal
• agent

改代码

建议按这个顺序：

1. 先读相关文件
2. 用全局搜索找关联位置
3. 小步修改
4. 保存并观察错误提示
5. 运行项目或测试

不要一次性改很多无关文件。Zed 的 diff 很清楚，前提是你的改动边界也清楚。

用 AI

AI 更适合做这些事：

• 解释陌生代码
• 帮你整理重构思路
• 按已有风格补一段代码
• 根据 diff 写提交说明
• 帮你检查文档是否有遗漏

AI 不适合替你跳过验证。它改完以后，仍然要看 diff、跑项目、跑构建。

提交前检查

1. 跑检查

前端或文档项目：

npm run build

有测试就再跑：

npm test

如果项目有 .zed/tasks.json，也可以从任务里运行。

2. 看 diff

打开 Git 面板，逐个文件看：

• 有没有误改
• 有没有临时日志
• 有没有构建产物
• 有没有本机路径
• 有没有图片或链接缺失

文档站尤其要注意图片路径。破图通常不是页面问题，而是文件没放到公开目录，或者路径写错。

3. 暂存和提交

只暂存本次要交付的改动。提交说明建议写清楚结果，而不是写“update”。

示例：

docs: 补充 Windows 上手和任务配置教程

一个完整例子

假设你要给这个教程站新增一章：

cd G:\llmProject\myOpenProject\Zed编辑器实战教程\app
npm run dev

然后：

1. Ctrl+P 打开对应 Markdown 文件
2. 写内容
3. 修改侧边栏配置
4. 浏览器里检查导航是否出现
5. 跑 npm run build
6. Git 面板看 diff
7. 提交

把 Zed 用成主力编辑器的关键习惯

习惯	为什么重要
用 Ctrl+P 找文件	比点文件树快很多
用命令面板找功能	不需要记所有菜单位置
终端留给临时命令	保持灵活
任务沉淀固定命令	方便自己和团队复用
提交前看 diff	避免把无关东西交上去
AI 改完必须验证	避免看起来对、实际跑不通

本章小结

Zed 的日常工作流可以很简单：

打开项目 -> 找文件 -> 改代码 -> 运行检查 -> 看 diff -> 提交

把这条链路跑顺，比单独研究某一个高级功能更重要。