开发过程跟踪器：本地服务管理（使用 CLI + TUI）
Source: Dev.to
请提供您希望翻译的正文内容（除代码块和 URL 之外的文字），我将为您翻译成简体中文并保持原有的 Markdown 格式。
我构建的内容
我构建了 Dev Process Tracker (devpt)，一个拥有 CLI 和 TUI 工作流的本地开发服务管理器。
它针对一种常见的实际情况而构建：多个本地服务、混合的启动方式，以及难以快速诊断的故障。
使用 devpt，我可以：
- 注册已知服务（
add） - 执行生命周期操作（
start、stop、restart） - 检查运行时状态（
ls、status） - 查看日志（
logs） - 切换到交互式工作流（
devpt）
Managed vs. Discovered（为何两者都重要）
- Managed – 你在
devpt中显式定义的服务（名称、工作目录、命令、预期端口） - Discovered – 当前本地 TCP 端口上正在监听的任何进程，即使它是由
devpt之外启动的
示例
- 你在 devpt 中注册一个前端，使用
npm run dev并监听 3100 端口。 - 另一个终端中仍有一个旧的
npm run dev进程在 3100 端口运行。
devpt ls --details 会显示两者，从而让你快速发现重复并停止陈旧的进程。
为什么不直接使用 PM2、Docker Compose 或 make 目标？
这些工具很有用，但它们解决的是问题的不同部分。
| 工具 | 优势 | devpt 填补的空白 |
|---|---|---|
| PM2 | 对受管 Node 进程的管理非常出色 | 缺乏对混合技术栈的本地进程广泛发现 |
| Docker Compose | 对容器化服务的支持极佳 | 许多团队运行混合本地栈（主机 + 容器） |
| make targets | 便捷的快捷方式 | 不是运行时清单或诊断界面 |
devpt 专注于 跨栈本地运行时可视化 + 生命周期控制 + 崩溃诊断，并将这些功能统一在一个界面中。
演示
仓库：
一天的工作流程
开始一天：已经在运行的内容？
./devpt ls --details
这会为你提供一个关于当前机器上所有监听服务的单一清单视图，既包括你显式使用 devpt 注册的服务，也包括在其他地方启动后被遗忘的进程。
启动本地堆栈
./devpt add frontend ./sandbox/servers/node-basic "npm run dev" 3100
./devpt add api ./sandbox/servers/python-basic "python3 server.py" 3300
./devpt start frontend
./devpt start api
在这里，devpt 管理的正是开发者每天实际运行的同类命令，而不是简化或合成的示例。
调查问题并恢复
./devpt status frontend
./devpt logs frontend --lines 60
./devpt restart frontend
./devpt stop api
当出现故障时，控制和诊断都集中在同一个地方。你可以查看崩溃状态、检查最近的日志，并在不切换工具或终端的情况下采取行动。
切换到交互模式
./devpt
相同的工作流也可以在 TUI 中使用，使其在一天中保持运行并在本地环境变化时进行交互变得十分实用。
Source:
我使用 GitHub Copilot CLI 的经验
我把 Copilot CLI 当作高速草稿和推理伙伴使用，然后手动约束其行为以符合项目需求。
示例 1：命令验证
提示
gh copilot suggest "add command validation for managed service commands and include tests for blocked patterns"对最终产品的影响
- 加速了初始验证/测试脚手架的搭建。
- 最终逻辑被手动收紧为项目安全的模式，并提供更清晰的 CLI 错误信息。
示例 2：崩溃诊断设计
提示
gh copilot suggest "show crash reason and recent log tail in status command for crashed services"对最终产品的影响
- 帮助塑造了 CRASH DETAILS 部分的设计。
- 最终输出和启发式规则被编辑，以降低噪声、提升信号。
示例 3：未奏效的情况
早期的一个建议推动了比实际需要更大范围的 TUI 重构。我拒绝了该方向，保持了 CLI‑first 的设计。
为什么放弃完整的状态重写
交互回归的风险对本次挑战的范围来说过高，所以我将重点放在：
- 聚焦的 UI 行为改进
- 不进行破坏性的状态模型重写
这种权衡让工具保持稳定的同时仍提升了可用性。
对我的工作流的整体影响
- 更快的实现草稿
- 更早发现边缘案例
- 在编写测试时实现更紧密的反馈循环
- 最终行为仍然经过人工审查
详细的提示层面证据记录于：
适用人群
devpt 适用于运行混合本地栈（Node、Python、Go、容器）的开发者，他们需要可靠的运行时可视化和快速的故障诊断。
它回答的核心问题： 实际在运行什么，我接下来应该怎么做？