一个下午，1400行Python，零依赖实现了一个网站生成器

一个下午1400行Python零依赖实现了一个网站生成器开头先放仓库https://github.com/luckychenxiaowen/sitemaker纯Python标准库MIT协议。觉得有用就点个Star。这玩意干什么的一句话选类型、挑风格、配功能生成完整的静态网站。# 命令行一行出站python feizhan.py-tcompany-smodern-p2# 或者启动可视化界面python feizhan.py--ui支持5种网站类型公司官网/产品众筹/作品集/博客/论坛10种CSS风格12个功能模块自由组合1-3层页面深度随便选。生成的产物是标准HTMLCSSJS静态文件扔到任何地方都能跑——EdgeOne Pages、GitHub Pages、Vercel、自建Nginx。技术架构整个项目只有一个核心文件feizhan.py约1400行。结构是这样的用户输入类型/风格/功能/层级 │ ▼ generate_website() │ ┌────┼────┐ ▼ ▼ ▼ HTML CSS JS三个生成器各干各的generate_html()—— 根据features列表动态拼接section区块导航也是动态生成的generate_css()—— 字典映射到10套完整CSS不是换几个变量generate_js()—— 通用的平滑滚动、表单提交、菜单切换再加上一个FeizhanServer继承了SimpleHTTPRequestHandler处理6个API路由。为什么不用框架故意的。两个原因。第一降低使用门槛。不装Flask、不装Jinja2、不装任何东西Python 3.10直接跑。这对开源项目冷启动很重要——你让用户先 pip install 五个包一半人已经跑了。第二这本来就是个不需要框架的场景。HTML生成用f-string模板足够CSS生成就是字典映射到字符串JS生成更简单。引入框架反而增加复杂度。动态模板引擎怎么做的generate_sections()是这个项目的核心。它接收一个features列表返回动态拼接的HTMLdefgenerate_sections(website_type,features,custom_content):sections[]sections.append(hero_section)# 每个网站都有ifproductinfeatures:sections.append(product_section)ifpricinginfeatures:sections.append(pricing_section)ifcontactinfeatures:sections.append(contact_section)# ... 12个模块逐个判断return\n.join(sections)导航也是同样逻辑——generate_nav_items()先根据层级放基础导航首页、关于、服务再遍历features追加对应的导航项产品→#products、价格→#pricing……。这说起来没什么技术含量但实际写的时候就发现坑了——features列表和导航项的key不是一一对应的。比如intro和about都映射到同一个#about锚点article映射到 #articles、topic映射到 #topics。映射关系搞错一处页面上的锚点就全乱了。10种CSS风格怎么实现差异化这是第一版最大的坑也是v2重写的重点。第一版的generate_css()长这样简化# v1 —— 只换颜色布局完全相同cssf :root {{ --primary:{style[primary_color]}; --bg:{style[bg_color]}; --text:{style[text_color]}; }} // ... 后面几百行布局代码完全相同 ... 结果就是选「毛玻璃」和选「赛博朋克」几乎看不出区别——因为布局代码一模一样只是换了个色。v2直接改成了字典映射# v2 —— 每种风格独立完整CSSstyle_css_map{modern:/* 渐变柔和阴影 */ ...,minimal:/* 超大留白无边框 */ ...,bento:/* 圆角卡片网格hover动画 */ ...,brutalist:/* 粗边框直角硬阴影 */ ...,glass:/* backdrop-filter: blur(10px) */ ...,neumorphic:/* box-shadow内外阴影凸凹 */ ...,gradient:/* 多色渐变流动色彩 */ ...,dark:/* 深色背景高对比 */ ...,cyber:/* 霓虹glow扫描线切角边框 */ ...,nature:/* 自然绿色有机圆角 */ ...,}每种风格大概300-400行CSS真的是从头写到尾。举个具体的例子glass风格的header/* glass风格——真的毛玻璃 */.header{background:rgba(15,23,42,0.6);backdrop-filter:blur(24px);-webkit-backdrop-filter:blur(24px);border-bottom:1px solidrgba(255,255,255,0.06);}cyber风格的边框/* cyber风格——切角发光 */.btn-primary{background:var(--primary);clip-path:polygon(10px 0,100% 0,calc(100% - 10px)100%,0 100%);box-shadow:0 0 20pxvar(--primary),0 0 40pxvar(--primary);}HTTP服务端怎么嵌进去的FeizhanServer继承http.server.SimpleHTTPRequestHandlerclassFeizhanServer(SimpleHTTPRequestHandler):defdo_GET(self):ifself.path/api/config:self._json(FeizhanAPI().get_config())elifself.path.startswith(/api/tree):self._handle_tree()elifself.path/:self.path/src/ui/index.htmlelse:super().do_GET()# 兜底静态文件defdo_POST(self):ifself.path/api/generate:self._handle_generate()6个API路由GET/api/config—— 返回所有可选的类型/风格/功能模块GET/api/status—— 返回当前生成状态和进度GET/api/tree?pathxxx—— 返回生成网站的目录结构GET/api/open?pathxxx—— 在资源管理器中打开文件夹GET/api/download?pathxxx—— 打包ZIP下载POST/api/generate—— 核心生成接口前端就是纯HTMLCSS原生JSfetch调这些API没有任何框架依赖。踩过的坑坑1dict当key用# 错误写法styleDESIGN_STYLES[style_config]# style_config已经是dict了!# 正确写法stylestyle_config# 直接就是dict不用再查Python的dict是unhashable的不能当字典的key。这个错误报出来我才发现是传参方向搞反了——generate_html接收的style_config参数本身就是DESIGN_STYLES[style]查出来的dict结果我拿它又去查了一次。坑2URL rewrite下的静态资源路径服务端把/rewrite到了/src/ui/index.htmlifself.path/:self.path/src/ui/index.html但HTML里写的是相对路径!-- 浏览器解析为 /style.css → 404 --linkrelstylesheethrefstyle.css浏览器看到当前页面URL是http://localhost:8765/相对路径style.css就解析成了http://localhost:8765/style.css而实际文件在/src/ui/style.css。改成绝对路径就解决了。坑3Edit工具误删函数定义用Edit工具替换代码段的时候不小心把def main():这行也替换掉了。结果是main函数的函数体直接悬浮在模块级别import的时候就报NameError: name main is not defined。后来重写时特别注意了这个边界。坑4端口残留测试过程中多次重启服务Windows上HTTP服务进程有时候不会正常释放端口。netstat -ano一查发现3个进程同时在8765端口LISTENING只能挨个taskkill /F /PID。为什么没有用前端框架这个决定可能有人会觉得奇怪——2026年了还写原生HTMLCSSJS说实话不是不想用。React或者Vue写UI确实更爽。但这里有个取舍加了框架就要加构建工具链webpack/vite就要加npm依赖就要增加项目的复杂度。这个项目的UI不复杂——4步向导每步就是一个div的显示/隐藏切换几个fetch请求。原生JS写完全够用。用框架反而会让项目的零依赖这个卖点没了。类似的考虑还有没引入任何CSS预处理器的原因。LESS/SASS确实好用但纯CSS写10套风格虽然累点但用户拿到代码不用编译就能改。这种零摩擦的体验对开源项目来说比开发体验更重要。和传统开发方式的对比不用AI的话这样一个项目从头写设计数据结构类型/风格/模块定义—— 1小时写HTML生成器逻辑 —— 2小时写10套CSS —— 至少4小时每套调试都得花时间写UI界面 —— 3小时写HTTP服务端 —— 1小时写文档、README、LICENSE —— 2小时加起来至少两到三个工作日。用WorkBuddyAIAI处理了绝大部分体力活——生成CSS样式代码、补全12个模块的section模板、写API路由的样板代码、生成README骨架。我把精力全放在了架构决策上5×10×12的矩阵设计、三种交互方式的接口定义、风格差异化的标准。但有一点AI帮不上忙——它不知道10种风格应该长什么样。这个判断来自我对CSS设计趋势的理解不是它从训练数据里能猜出来的。第一版AI生成的10种风格之所以全都一样就是因为它只知道换颜色这个模式不知道每种风格需要独立的布局逻辑。后面想做什么Prompt模式—— 支持自然语言输入。比如「帮我做一个SaaS公司官网要暗黑风格有定价页和博客」自动匹配类型和模块行业预设模板—— SaaS、电商、教育、金融等行业的默认配置在线Demo—— 部署到EdgeOne Pages免下载直接用社区模板市场—— 开放PR让大家贡献新的CSS风格和功能模块仓库https://github.com/luckychenxiaowen/sitemaker1400行Python零依赖MIT协议。看懂代码大概需要20分钟——每个函数都是独立可读的。有想法提Issue有代码提PR。2026年5月2日。AI写代码确实快但把架构想清楚这件事还是得靠自己。