6. 极低花费下使用手机完成AI编程——开发网站

项目最终目标：让没有编程技术的用户，最方便地创建并维护自己的博客网站。

这是什么：资源受限不是「机器差」，而是三本账同时吃紧——机器（2 核 2 GB 服务器 + 一台 16 GB 笔记本）、人的注意力（单人、没有 code review）、模型上下文（每次会话从零开始）。本章讲在这种条件下，怎么把 AI 编程管成一条可复现的流水线。

为什么用：AI 把产出放大十倍，也会把错误放大十倍。资源充足时你可以「先错了再改」；资源受限时没有冗余吸收返工，约束只能前置，验证只能机械。

如何用：下面按「为什么做 → 三本账 → 工具与额度 → 从零建站 → 流程 → 失效点」六层展开，每条都能落成一个文件或一个脚本。样本是本章作者自己的博客：48 个技术栈、327 章教程、388 个静态页，一台 2C2G ECS 对外，一台 16 GB 笔记本干活。

6.1 这是个什么站：一个特点鲜明的博客

先交代样本身份：青蛙编程网，一个个人编程教程博客。 但它不是「又一个博客」，与常见博客的差异本身就是资源策略的体现：

最后一条最关键：这个站既是博客，又是它自己教程的实验台。 本章讲的约束与验证，由站点自己的部署与体检流程验证——没有第二个项目可牺牲，就让项目自身互为实验品。

6.2 为什么做这个站：填「知道」和「做过」之间的空档

AI 把技术更迭的节奏从「几年一代」压到「几个月一代」，而真实工作环境的落地速度跟不上——依赖要过审、生产网无外网、线上不能试错。于是「知道」和「做过」之间空出一段：文章读了不少，真上手仍是零。填补方式就是业余时间 + 个人资源。

定位也要说清：这是一次「资源极限低」的探索，不是最佳实践合集。目标是探出「资源压到这么低，还能不能持续产出」的下限；文中每条做法都是被约束逼出来的取舍，资源一变就该重算（见 6.8）。

花钱的地方先记清楚：

首年合计约 1287 元，月均约 107 元。 失败的最大损失就是这一年，换来的是一批能带回工作的可运行经验——这笔账不难算。

6.3 先把「资源」拆成三本账

关键动作是把约束写成数字：内存预算表列到「argon2 每次哈希吃 19 MB」这一级，于是「能不能在服务器上装后台」不再是争论，而是查表。反向清单更值钱——明确不装上服务器的：本地大模型、OCR / PDF 解析、MySQL、Node 构建链。范围纪律比技术选型更值钱。

两台机器的分工也是硬边界：

一句话：笔记本负责「算」，服务器负责「服务」，两者只用 Git 交换产物。

6.4 工具与额度：省 token 靠分层，不靠少用

额度是免费 token 打底 + 一份 99 元/月包月。免费模型会下架、限流、改行为，所以规矩不能绑在某个模型上：规则写在 AGENTS.md，正确性交给脚本，换模型只换入口。

额度见底时的降级顺序是 opencode → openclaw → 千问，最后一档只接文档；代码一律等额度恢复，因为换工具重写一遍的返工成本远高于等半天。切换的执行是手工为主 + 龙虾自动为辅：人定额度档位（额度余量是外部状态，模型看不准也信不得），龙虾在前台自动分派碎活——人定额度档位，机器定任务去向。

6.4.1 第一层：前台与执行分开

龙虾费 token 是众所周知的。最初端到端让它读仓库、改文件、跑校验，回合多、上下文反复重传，token 消耗高到这个入口基本闲置。改成分层之后才留下来：

关键约束是上下文不跨界：仓库内容不进 IM（即时通讯软件，如飞书、微信、Telegram，下同）会话，IM 里的讨论也不回灌主力；两层之间只传「任务说明」（哪个文件、改成什么、验收标准）和「结果摘要」（diff 要点 + 退出码）。

代价也要记账：多一跳协调，任务说明写不清，主力就来回反问，省下的 token 又花在澄清上。所以这套方案的前提是「任务能写成验收标准」——需求还模糊时，直接在终端做反而更省。自动化本身不省资源，分层才省。

6.4.2 第二层：编程类 skill——把「怎么干」从对话搬进文件

没有 skill，每个会话都要用对话轮次重新交代「章节格式、校验怎么跑、产物放哪里」——同样的话每次重新生成、重新计费；装了 skill，agent 按需读文件。省 token 的机理两层：少花（读文件比对话解释便宜，文件不随会话重传）+ 少错（照标准步骤减少试错回合，试错才是 token 大头）。

skill 不必全自己写，公开来源按可信度排三档：

• 官方仓 anthropics/skills（约 19 个，质量稳）：webapp-testing（浏览器测试）、mcp-builder、docx / pptx 等文档四件套
• ClawHub 社区市场（安全清理后剩三千上下，鱼龙混杂）：多语言 code review / PR 审查类，可当「第二双眼睛」
• awesome 精选列表（人工筛过的索引）：先查列表再去市场搜

安全闸门：公开 skill ≠ 可信任的 skill。 ClawHub 出过成规模恶意技能事件（Snyk 2026-02：抽样 36% 存在提示注入）。装任何一个公开 skill 前，人工读一遍 SKILL.md 与附带脚本，先在允许区的活上试跑——这一步归人工闸门，不交给模型自查。

6.4.3 第三层：代码生成器——批量产出交给脚本跑

内容源 md        确定性转换脚本         产物
（AI 写，花 token）→（进程跑，零 token）→（HTML / ZIP / 索引，零 token）

本项目的三件套，各管一段：

一批技术栈（8 章 / 30~60 文件）的 token 账：花 token 的只有 8 章内容源 + 生成器（写一次，之后摊薄到接近零）；零 token 的有导航登记、几十个 HTML 渲染、ZIP 打包、索引与 sitemap 更新——这些如果让 AI 逐页搬，每个文件都要读模板、生成、计费，且每次都可能引入不一致。

「AI 写生成器」特别划算的原因：生成器代码本身就是结构重复、规则明确的极致——正是模型擅长、人不爱干的活。写一次，跑无数次。

AI 的 token 只花两处：写 / 改生成器（一次性）+ 写内容源 md（每批真正的增量）；机械转换归零。生成器自己守四条工程要求：

• 产物字节确定：ZIP 固定时间戳、索引无时间戳，否则每批几百个假 diff
• 先 dry-run 后落盘：解析结果先打印，人工核对再写入
• 解析不了就警告，不硬造：生成器可以兜底，不能静默出错
• 目标是同构：产出与现有页面逐块对齐，否则批量生成变成风格漂移的批量来源

边界与「敢删工具」（6.6 第 ③ 条）是同一条纪律的两面：产出结构重复、规则明确才值得写生成器；反过来，几百行、零维护、替代每批 30~60 个文件逐页开销的生成器，正是该留的那种。

生成器的职责按改动大小划：负责前端代码的初次生成（新增技术栈 / 章节，30~60 文件）与前端大改动（全站导航调整、模板结构变化——改模板一处重跑，胜过直改几百个文件）；教程小改动（错字、表格、单页微调）则直接改前端产物，为几十个字跑一遍生成流程反而是浪费。判据是波及文件数：波及面大的走生成器，小的直改。

6.5 从零开始建一个站：省 token 的敏捷路线

前面回答「怎么省」，这一节回答「从零建站，顺序怎么排」。路线按批次时间轴走：

每一步的验收标准（做到什么程度算完成）：

• 第 0 批：开一个全新会话，AI 只读文件就能答对「什么能直接改、什么必须请示」
• 第 1 批：手机走流量能打开；随手改一个错字走完「改 → push → pull → 线上可见」一次
• 第 2 批：生成器独立产出一整个专题，与手做版逐块对齐，全站体检通过
• 第 3 批起：批次 = 一次会话能验证完，每批可结算、可中断，适合碎片时间

每一步的常见死法，对照自查：

两条顺序教训：工具选型是迭代的产出，不是迭代的前提（本站先搭 VitePress「全家桶」，263 章时峰值 1652 MB 跑不动，只能推倒换方案）；生成器不是第一个会话写出来的（第一个专题手做摸清结构，第二个才开始提炼——没有真实产物就没有模板）。

站点长大之后（本站 48 栈的现状）：重心完全移到内容，批次模板与风格指南的价值开始大于工具优化；站点功能（搜索、统计、后台）不是不能加，是加之前先查资源预算表；产物规模大了直改吃力，生成器从「全量构建」演化成「指定范围按需生成」——工具的每次演化都是真问题逼出来的，没有一次是提前设计的。

这条路线的敏捷内核一句话：每个批次结束时，线上都有一个能点开的东西，而且下一批比上一批更便宜。

6.6 七步闭环

三处值得展开。

① 禁区按风险划，不按目录划。 判据是「是否影响线上站点与后端」。于是页面产物（几百个 HTML）可以自由改，沙箱执行器（一个文件）必须请示——虽然前者文件多得多。

② 范围校验要能被断言。 「不要顺手改别的」写在提示词里等于没写。把它变成一个比对脚本：

import hashlib, pathlib, subprocess

REL = "docs/ai/harness/guardrails.md"

def tail(text: str) -> str:
    """H2 之后的全部内容；H1 与首个 H2 之间才是本次允许改的区域"""
    return text.split("\n## ", 1)[1] if "\n## " in text else ""

now = pathlib.Path(REL).read_text(encoding="utf-8")
old = subprocess.run(["git", "show", f"HEAD:{REL}"],
                     capture_output=True, text=True, encoding="utf-8").stdout

print("越界" if tail(now) != tail(old) else "范围 OK")

跑起来只有两种输出：

范围 OK

越界

③ 敢删工具。 本站最早用 VitePress 构建，263 章规模下峰值内存 1652 MB，2 GB 的服务器跑不动，只能本机构建再传。后来换成自研 Python 脚本，峰值降到 52 MB——然后把脚本也删了：产物直接入库、直接编辑，服务器 git pull 即部署，回滚即 git revert。判断标准很朴素：工具的维护成本超过它节省的成本，就该删。

人工闸门拦的是哪些动作——判据是「出了错能不能靠再跑一次校验 / git revert 恢复」：git commit / push（进入共享历史）、改写历史类（force-push、rebase 已推送分支）、生产服务器任何写操作、禁区代码（沙箱执行器）、门禁规则改动、批量删除、敏感信息写入、供应链引入（装公开 skill、加依赖）。人只出现在「写历史、碰线上、改规则、进外部代码」这四类位置上；其余一切，脚本是评审，Git 是后悔药。

6.7 敏捷：七步的来路

本项目不引入 Scrum，但七步几乎每一步都能对回敏捷的老结论，差别只在周期：敏捷团队两周一个 Sprint，单人 + AI 把同样的循环压到半天到一天。

一个「迭代」在这里叫「一批」：8 章 / 2~5k 行 / 30~60 文件，一次会话能覆盖；批内跑完 写作 → 生成 → 校验 → 提交 → 部署，不留半成品；同时只开一条战线（WIP = 1）。

仪式可以删，反馈不能丢：

原则：删仪式的前提是每一次反馈都有文件承接。 没有承接的删减，等价于取消反馈。

6.8 十个失效点

「假绿」值得单独说。本项目真实发生过一次：部署脚本静默跳过后端重启，代码已经 pull 到最新，进程还是在跑旧的——而所有健康检查依然返回 200。事后定的取证法是：

# 自检全绿 ≠ 新代码在跑：问一个只有新版才存在的端点
curl -s -o /dev/null -w '%{http_code}\n' http://127.0.0.1:8900/api/admin/analytics/events

401

401 = 新代码生效；404 = 旧进程还在跑。验收要证明「新东西在跑」，不是「服务活着」。

还有一类隐性失效点不属于技术：把自动化当免费。让 IM 机器人端到端干活（读仓库、改文件），实际回合变多、上下文重传，token 翻倍而产出不变——应分层（见 6.4.1）。

6.9 什么时候这套不成立

诚实地说，这套流程有明确的适用边界：

资源约束变了，流程也要跟着变。 第 5 章那句「Harness 的每个组件都编码了一个假设」在这里同样成立——假设是「这个模型 / 这台机器 / 这个人做不到」，假设不成立了，组件就该撤。

动手改

1. 给项目列一张资源账：机器多少、谁在维护、上下文怎么续——三项各写一个数字，再写一条由它推出的「不做清单」
2. 把花销也算成数字：服务器年费、模型月费、哪些设备算沉没成本不算项目支出。写不出来，说明「省钱」还只是感觉
3. 给自己站点的首页和常见博客各列一张对比表：站点形态、内容生产、运行资源、维护投入——差异最大的那一维，就是你的流程最该改的地方
4. 挑一条你反复叮嘱的规则（「不要改 X」「记得更新 Y」），把它变成校验脚本，报错里带修复方法
5. 如果接了 IM / 手机入口，先给它划边界：对话与调度一层、执行一层，仓库上下文不要进聊天窗口
6. 想从零建个站？按 6.5 的时间轴走：第 0 批只写规矩，第一批只求「手机能打开」，第二个专题手做、第三个才写生成器
7. 找一个「自检通过」的部署流程，补一条只有新版才成立的探针，确认它能区分新旧

小结

• 先交代样本身份：这是一个特点鲜明的个人教程博客——零框架、AI 批量生产、2C2G、单人业余，还是它自己教程的实验台
• 定位要诚实：资源极限低的探索探的是下限，不是最佳实践
• 资源要拆成三本账：机器、注意力、上下文；约束写成数字，成本也写成数字（首年约 1287 元）
• 工具按「吃不吃长上下文」分工：主力执行、辅助调度、兜底只写文档；额度降级 opencode → openclaw → 千问
• 省 token 三层：前台与执行分层（上下文不跨界）、skill 把「怎么干」搬进文件（公开 skill 装前人工审源码）、生成器让批量产出零 token
• 人定额度档位，机器定任务去向
• 从零建站按批次走：规矩 → 最小可上线 → 生成器化 → 流水线；工具选型是迭代的产出，不是前提
• 每批的敏捷内核：结束时线上有能点开的东西，下一批比上一批更便宜
• 禁区按风险划；人工闸门只拦「写历史、碰线上、改规则、进外部代码」
• 警惕假绿：验收要证明新代码在跑，不是服务活着
• 约束变了，流程要跟着改；这套流程不是终点，是一组可被推翻的假设

下一章：综合练习，把这七步在你的项目里搭起来 🐸