北京
八年前Meta就有万亿参数模型了。但2024年的AI用户面临一个更实际的问题：每天产生几十份HTML文档，却无处可管。
一位开发者统计了自己的日常产出：Claude artifacts约20份/天，ChatGPT canvas约10份/天，Cursor和CodeBuddy报告5-8份/天。这些文件散落在十几个文件夹里，双击只能查看，改个错别字就得重新跑原始提示词，历史版本更是无从找起。
他试过现有方案，全部失效：VS Code预览插件只能看不能改；本地HTTP服务器没有编辑功能；笔记软件导入会丢失CSS动画和交互；Notion则直接拒绝HTML附件。于是他在localhost:9901搭建了一个专用工作台，命名为DocCenter。
整个后端只有一个server.py文件，零requirements.txt，唯一外部依赖是aiohttp。前端是纯JavaScript，无构建步骤。这不是炫技，而是三个刻意选择的结果。
第一，选aiohttp而非FastAPI。工作台不是产品，是每天自用的笔记本工具。冷启动速度和内存占用比漂亮的OpenAPI文档重要100倍。作者同时运行着dashboard（9900）、heartbeat（4011）、cockpit（8088）三个服务，无法接受每个服务吃掉80MB内存。
第二，选原生JS而非React。零构建等于零心智负担。修bug不需要npm install → npm run build → refresh，而是edit → Cmd+Shift+R。整个web/目录只有8个文件，唯一嵌入的第三方依赖是marked.min.js（Markdown渲染，MIT协议），平放在web/vendor/里。
第三，选iframe而非单页应用路由。被编辑的HTML文件是完整页面，自带CSS动画、JS交互、外部字体。把提取进SPA会丢失全部运行时上下文。iframe保留每份文档的完整运行环境，DocCenter只在前注入一小段saver-runtime.js，提供编辑工具栏和自动保存功能。保持源文件运行时不受污染，这是v1.0至今的硬规则。
架构分三层：浏览器端是web/app.js（侧边栏树）和iframe（用户HTML + 注入的saver-runtime.js）；中间层是server.py，处理静态文件、树形结构/配置、HTML读写三个模块；底层是文件系统，按项目组织，支持快照和版本历史。
核心交互设计围绕一个洞察：AI生成的文档需要"浏览-编辑-保存"闭环，但不能破坏原始输出。点击侧边栏文件，iframe加载完整页面；点击编辑，saver-runtime.js接管，提供所见即所得修改；保存时可选覆盖原文件、新建副本或放弃修改。所有操作通过HTTP JSON与后端通信，不涉及任何云端同步。
这个工具的定位很明确：不是取代AI平台，而是填补它们留下的空白。Claude和ChatGPT负责生成，DocCenter负责后续的整理、修补和归档。作者把代码开源在GitHub，项目名html-doc-center，建议部署平台包括dev.to、Hashnode、Medium和X长帖。
技术圈有个老说法：程序员最恨的两件事，别人的代码不写文档，以及自己不得不写文档。AI时代版本更新：程序员最恨的两件事，AI生成的代码找不到，以及找到了改不了。DocCenter试图解决的是后半句。
特别声明：以上内容(如有图片或视频亦包括在内)为自媒体平台“网易号”用户上传并发布，本平台仅提供信息存储服务。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.
