一个下午，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层页面深度随便选。

生成的产物是标准HTML+CSS+JS静态文件，扔到任何地方都能跑——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列表，返回动态拼接的HTML：

defgenerate_sections(website_type,features,custom_content):sections=[]sections.append(hero_section)# 每个网站都有if'product'infeatures:sections.append(product_section)if'pricing'infeatures:sections.append(pricing_section)if'contact'infeatures: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 —— 只换颜色，布局完全相同css=f''' :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.SimpleHTTPRequestHandler：

classFeizhanServer(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.html'else:super().do_GET()# 兜底：静态文件defdo_POST(self):ifself.path=='/api/generate':self._handle_generate()

6个API路由：

• GET/api/config—— 返回所有可选的类型/风格/功能模块
• GET/api/status—— 返回当前生成状态和进度
• GET/api/tree?path=xxx—— 返回生成网站的目录结构
• GET/api/open?path=xxx—— 在资源管理器中打开文件夹
• GET/api/download?path=xxx—— 打包ZIP下载
• POST/api/generate—— 核心生成接口

前端就是纯HTML+CSS+原生JS，fetch调这些API，没有任何框架依赖。

踩过的坑

坑1：dict当key用

# 错误写法style=DESIGN_STYLES[style_config]# style_config已经是dict了!# 正确写法style=style_config# 直接就是dict，不用再查

Python的dict是unhashable的，不能当字典的key。这个错误报出来我才发现是传参方向搞反了——generate_html接收的style_config参数本身就是DESIGN_STYLES[style]查出来的dict，结果我拿它又去查了一次。

坑2：URL rewrite下的静态资源路径

服务端把/rewrite到了/src/ui/index.html：

ifself.path=='/':self.path='/src/ui/index.html'

但HTML里写的是相对路径：

<!-- 浏览器解析为 /style.css → 404 --><linkrel="stylesheet"href="style.css">

浏览器看到当前页面URL是http://localhost:8765/，相对路径style.css就解析成了http://localhost:8765/style.css，而实际文件在/src/ui/style.css。改成绝对路径就解决了。

坑3：Edit工具误删函数定义

用Edit工具替换代码段的时候，不小心把def main():这行也替换掉了。结果是main函数的函数体直接悬浮在模块级别，import的时候就报NameError: name 'main' is not defined。后来重写时特别注意了这个边界。

坑4：端口残留

测试过程中多次重启服务，Windows上HTTP服务进程有时候不会正常释放端口。netstat -ano一查发现3个进程同时在8765端口LISTENING，只能挨个taskkill /F /PID。

为什么没有用前端框架

这个决定可能有人会觉得奇怪——2026年了还写原生HTML+CSS+JS？

说实话，不是不想用。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小时

加起来至少两到三个工作日。

用WorkBuddy+AI，AI处理了绝大部分体力活——生成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/sitemaker

1400行Python，零依赖，MIT协议。看懂代码大概需要20分钟——每个函数都是独立可读的。有想法提Issue，有代码提PR。

2026年5月2日。AI写代码确实快，但把架构想清楚这件事，还是得靠自己。