English

本页内容

常见工作流

这些例子用于日常仓库开发。默认你已经在 TUI 中运行：

cd /path/to/workspace
sigil

探索陌生仓库

从只读问题开始：

解释这个仓库的结构。指出主要入口、测试布局、配置文件和用户文档。

继续问一个聚焦问题：

解释 Sigil 如何处理这个请求。指出用户可见阶段、可能需要查看的文件，以及它会在哪里显示错误或批准。

好的信号：

给出目标、范围和验证期望：

更新 docs/zh-CN/quickstart.md，让首次运行路径对新用户更清晰。
这次只改文档。
编辑后检查链接，并运行可用的静态文档检查。

出现 approval 时，先检查 diff 再允许。运行结束后：

git diff

如果编辑范围太大，deny 并重新说明范围。

跨多个文件或需要持久分步骤的任务使用 /task：

/task add a troubleshooting section for terminal copy failures and link it from the TUI guide

先 review 生成的 task plan，再让 execution 继续。你可以指导下一步：

保持 docs-only，不要编辑 Rust code。同步更新英文和中文文档。

如果无需额外指导：

/task continue

贴出失败命令和相关输出：

cargo test 失败。断言显示 help text 缺少 Alt-D。
找出 help text 来源，解释可能原因，并在编辑前给出最小修复方案。

更安全的做法是先要求 inspect，再决定是否编辑：

先读取失败测试和实现。总结 root cause，等我确认后再改文件。

明确要求 review stance：

Review 当前 diff，重点看用户可见回归、过期文档和缺失验证。按严重程度列出发现，并带文件引用。

再决定是否修复：

只修复高严重程度的文档问题。不要触碰无关 Rust 改动。

使用：

/resume

从列表中选择 session。恢复会重建可见对话和 durable task state。中断工具会显示为 interrupted；Sigil 不会静默重放它们。

如果最新计划任务还没完成：

/task continue

或直接在 composer 中输入下一步指导。

在配置中启用：

[code_intelligence]
enabled = true
server_startup = "lazy"

在 TUI 中使用：

Alt-D

对 git changed source files 运行 diagnostics。LSP server 可用时，code intelligence 还可以提供 symbols、definitions、references、code actions 和 rename previews。

如果没有 LSP server，普通 chat 和文件工具仍可使用。见 Sigil 配置指南和排障。

当 Sigil 需要工具化访问外部系统或专门的本地能力时，使用 MCP。

典型流程：

好的 prompt 通常包含：

示例：

改进 docs/zh-CN/configuration.md，让新用户更容易理解。
保留 provider-specific advanced fields，但把常见路径放在完整 reference 前面。
必要时同步英文 mirror。
编辑后运行 docs link/path 检查。

Sigil 可以 inspect、edit 和 run commands，但你仍需要检查：