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

开头先放仓库

https://github.com/luckychenxiaowen/sitemaker

纯Python标准库，MIT协议。觉得有用就点个Star。

---

这玩意干什么的

一句话：选类型、挑风格、配功能，生成完整的静态网站。

# 命令行一行出站
python feizhan.py -t company -s modern -p 2

# 或者启动可视化界面
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：

def generate_sections(website_type, features, custom_content):
    sections = []
    sections.append(hero_section)  # 每个网站都有

    if 'product' in features:
        sections.append(product_section)
    if 'pricing' in features:
        sections.append(pricing_section)
    if 'contact' in features:
        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 —— 每种风格独立完整CSS
style_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 solid rgba(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 20px var(--primary), 0 0 40px var(--primary);
}

HTTP服务端怎么嵌进去的

FeizhanServer 继承 http.server.SimpleHTTPRequestHandler：

class FeizhanServer(SimpleHTTPRequestHandler):
    def do_GET(self):
        if self.path == '/api/config':
            self._json(FeizhanAPI().get_config())
        elif self.path.startswith('/api/tree'):
            self._handle_tree()
        elif self.path == '/':
            self.path = '/src/ui/index.html'
        else:
            super().do_GET()  # 兜底：静态文件

    def do_POST(self):
        if self.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：

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

但HTML里写的是相对路径：

<!-- 浏览器解析为 /style.css → 404 -->
<link rel="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写代码确实快，但把架构想清楚这件事，还是得靠自己。