在 AI DevSpace 里把一个小想法跑起来：一次真实的 Python 时间服务体验

平时写代码，我最怕的不是需求难，而是“想验证一个小想法，却要先搭一整套环境”。装依赖、配端口、开服务器，一圈下来，想法本身反而被磨没了。今天在华为云 AI DevSpace 体验版里，我用一句话让 AI Shell 帮我把一个 Python 时间服务跑了起来，整个过程比我预想的要顺，也有一些值得记下来的细节。

一句话需求，AI 先去做检查

我给 AI Shell 的问题是：在 DevSpace 体验版里，用 Python 快速写一个返回当前时间的简单 Web 服务并在本地测试，给出步骤和代码要点，不要创建任何付费资源。

它没有直接贴一段代码了事，而是先按流程做了三件准备工作：检查 CodeArts 的 ACP 服务是否健康，确认沙箱路径，检查 8080 端口是否空闲。端口检查这一步很容易被新手忽略——如果端口已被占用，服务起不来，报错信息又往往不直观。先确认端口空闲，再写代码、再启动，这个顺序本身就是一个好习惯。

代码很小，但每一步都可验证

AI Shell 通过 CodeArts 在沙箱里生成了一个名叫 time-service 的项目，只用了 Python 标准库，没有引入任何第三方依赖。核心就是 http.server 模块：用 BaseHTTPRequestHandler 重写 do_GET，按路径分发到两个端点；用 datetime.now().isoformat() 返回当前时间；用 json.dumps 把结果转成 JSON。

服务启动后，它做了两次真实验证：先 curl 根路径，返回了 {“current_time”: “2026-11-13T22:05:40.770972”}；再 curl /health，返回 {“status”: “ok”}。同时用 ss 确认 8080 端口确实处于监听状态，进程就是刚启动的 python3。也就是说，回答里给出的不是“理论上能跑”的代码，而是已经跑通、返回结果都贴出来的代码。这对读者来说差别很大：照着做，基本不会卡在“为什么我跑不起来”上。

两个值得注意的体验细节

第一，体验版容器 3 小时后会释放，再次启动是全新容器，文件不会保留。所以像 time-service 这样的实验性代码，如果想留着，记得及时把文件拷出来或者提交到自己的代码仓，不要指望容器替你保存。

第二，AI Shell 在完成之后问我要不要创建 DevBridge 隧道、要不要提交到 GitCode 仓库。我的建议是：先不急着分享和提交。先在本地把接口跑通、把代码读一遍，确认没有多余内容，再决定要不要公开。把“跑通”和“发布”分成两步，小项目不容易出岔子。

给新手的三点小建议

一是先说清楚约束再提问。比如“只用标准库”“不要创建付费资源”“端口用 8080”，约束越明确，AI 生成的东西越贴合你的环境，返工越少。二是让 AI 每做一步就验证一步，端口、健康检查、curl 返回值，验证过的步骤才可信。三是别只看最终代码，把中间的检查命令也记下来，下次自己动手时，这些命令就是排错的起点。

这次体验让我对 DevSpace 的定位更清楚了：它不是一个只能看文档的“体验页”，而是一个能直接动手、能真实验证的开发空间。一个返回当前时间的小服务当然算不上什么大项目，但从提问、检查、生成、启动到验证的完整链路跑通一次，比读十页介绍更有用。下一个小想法，我打算直接在这里先跑起来再说。