每日工作日记 04 · 从一堆日本文件，到一个能帮人的网站 · AI 做网站实践日记

这是《AI 做网站实践日记》12 篇正文之后的每日工作日记候选稿。
它写的是 2026 年 5 月中旬这几天，我怎样把自己在日本被大量表格、通知、文件弄得焦头烂额的经历，慢慢做成一个可以帮助更多外国人的网站。

本篇一句话

这几天，我最深的感觉不是“网站又多了几个页面”。

而是：我终于更清楚地看到，自己为什么要做这个网站。

不是为了证明 AI 多厉害。

不是为了做一个看起来很全的信息站。

而是因为我自己在日本生活、工作、创业时，真的被各种表格、通知、手续和窗口说明折腾过。

我知道那种感觉：

一张纸放在面前，字好像都能查。

但你不知道它到底要你做什么。

不知道先去哪一个窗口。

不知道有没有期限。

不知道这件事做错了，会不会影响签证、税务、租房、保险、公司手续。

所以，这个网站真正想做的事很朴素：

把我曾经吃过的翻译税、手续税、焦虑税，变成后来的人少走一点弯路的说明书。

事实边界

这几天的主线，可以压缩成四层。

层	已经发生的事	还不能说完成的事
代码层	Local Notice Decoder 的程序卡片、租房流程页、结构化数据和查询准备工作已经形成可验证代码	不能把代码通过说成产品闭环
生产层	合并请求 #372 进入主线，生产页面返回 HTTP 200	不能把 HTTP 200 说成商业验证
数据层	RAG / pgvector 的预处理、脱敏、dry-run 和 apply runner 已准备好	生产数据库写入仍停在授权边界
业务层	用户反馈入口和 intake gate 已准备	还没有 1 到 3 个真实用户反馈样本

所以这篇日记不写“我们完成了一个大版本”。

我更愿意诚实地写：

这几天，我们把一批真实高摩擦手续推过了工程和生产两道门，但数据闭环和业务闭环还没有真正关上。

这句话听起来不够漂亮。

但它更像真实工作。

1. 第一件事：我真的被日本表格和文件弄得焦头烂额过

这几天最用户可见的成果，是 Local Notice Decoder 和 procedure cards。

但它们不是从一个产品经理坐在白板前想出来的。

它们是从我自己的焦头烂额里长出来的。

我在日本见过太多这样的场景。

一张通知。

一个表格。

一个窗口给你的说明。

一个日文网页。

一封不知道该不该马上处理的信。

一张看起来很正式、但不知道要交给谁的表。

一个窗口工作人员说得很快，你只能一边点头，一边担心自己是不是漏听了关键条件。

一个税务、保险、住房或公司手续，表面上只是一页纸，背后却可能连着好几个机关。

这些东西表面上是信息，实际上是摩擦。

摩擦不只来自语言。

还来自顺序、机关、边界、时间点和责任分工。

比如：

这件事是市区町村管，还是法务局管？
是先确认通知日期，还是先看金额？
是自己要做，还是税理士、行政书士、房产公司能协助？
是现在必须处理，还是先保存证据、再问专业人士？

我以前在日本工作生活时，最怕的不是看见日文。

最怕的是：我看懂了字，却不知道下一步该不该动。

很多外国人在日本都会遇到这种时刻。

你不是不努力。

你不是不想守规则。

你只是站在一个陌生系统面前，不知道这张纸在整个流程里排第几步。

这就是我想做这个网站的原因。

不是把日本手续翻译成中文就结束。

而是把“下一步怎么判断”放到用户面前。

我希望以后有一个和我一样的外国人，收到一张日本文件时，不是先慌。

他可以先打开网站，看见这张文件大概属于哪一类、应该先看哪里、哪些事不能拖、哪些地方必须找专业人士。

这不是替他做决定。

这是先帮他把雾拨开一点。

2. 第二件事：AI 不能编我的经验

这几天还有一个很重要的小转折：我们把“真实经验段”的规则锁得更清楚了。

它背后的原则很重要：

真实经验段不能由 AI 编。

AI 可以整理结构。

AI 可以帮我把流程拆成卡片。

AI 可以把一个日本手续拆成“背景、机关、风险、下一步、边界”。

但 AI 不能替我说“我见过什么”。

如果一段经验不是我真实见过的，也不是我明确给出的匿名真实案例，它就只能是占位，不能装成我的声音。

这条规则看起来很小。

但对一个 Trust Gateway 来说，它是根。

因为用户不是来读一篇 AI 文案。

用户是在高摩擦场景里找可信的下一步。

一旦经验被编造，页面再漂亮，信任也会被掏空。

我宁愿页面少一点“漂亮话”，也不愿它替我编故事。

做到才算。

我亲眼见过、亲身经历过、或者明确收集到的真实案例，才能进入经验段。

没有证据的地方，就留白、标注、等待补充。

这也是我自己的文字指纹：

不把知道当做到。

不把想象当经验。

不把 AI 的顺嘴一说，当成可以公开给用户看的事实。

3. 第三件事：合并请求进入主线，不等于闭环完成

这几天，合并请求 #372 进入主线。

生产页面也能访问。

这是一个重要节点。

但我现在越来越不愿意把这种节点直接叫“完成”。

因为我已经吃过太多次亏：

本地通过，不等于用户能打开。
页面能打开，不等于入口明显。
合并请求通过，不等于业务有反馈。
生产返回 200，不等于产品真的有用。

所以我现在会把完成分成四层：

完成层	我现在怎么理解
code_done	文件、构建、检查、类型、lint 通过
production_done	用户可访问的生产路由有证据
data_loop_done	数据真正进入系统，并能被后续查询使用
business_validated	真实用户看过、用过、反馈过

这几天，前两层已经过了。

第三层还停住。

第四层还没开始。

这不是失败。

这是把项目从“聊天里的完成感”拉回真实世界。

以前我会急着说：“已经差不多了。”

现在我更愿意说：“哪一层过了，哪一层还没过。”

这就是我这段时间最大的变化。

4. 第四件事：生产数据库不是 AI 自动可以碰的地方

数据闭环现在卡在一个很典型的边界上。

本地准备已经做了。

脱敏检查也做了。

dry-run 能跑。

apply runner 也准备好了。

但真正写入生产数据库这一步，没有被自动执行。

原因很简单：这一步需要生产授权。

AI 能不能做，和 AI 应不应该现在做，是两件事。

我现在越来越清楚地看到，一个人用 AI 建公司，最危险的不是 AI 不会干活。

最危险的是 AI 太会干活，以至于它把“能继续”误认为“被授权继续”。

所以我宁愿让它停住。

停在密钥、生产数据库、付款、发布、专利、用户联系这些硬边界前面。

这不是保守。

这是为了让系统以后可以长期跑。

一个能停住的 AI 系统，才可能被信任。

5. 第五件事：重复错误要变成 validator

这几天，我还把很多跨 AI 协作里的错误模式沉淀成 MNK、audit mirror 和 validator 候选。

这里面最重要的不是文件数量。

最重要的是一个观念：

重复错误不能只靠下次小心。

下次小心，是人的愿望。

validator，才是系统的记忆。

比如：

不把外部 AI 的审计结论直接当成事实。
不把“页面存在”说成“用户找得到”。
不把“本地 dry-run 通过”说成“生产数据已经写入”。
不把“工程评分很高”说成“真实用户已经验证”。
不用轮询假装系统在自动等待。

这些话如果只留在聊天里，过几天就会散掉。

所以我越来越在意把它们写进文件、脚本、检查和收据。

不是为了显得流程复杂。

是为了减少我自己的注意力税。

人的注意力应该放在判断上。

机器能记住的，就不要让我每天重新提醒。

6. 李笑来公开资料给我的几个借鉴

这几天我也重新看了李笑来的公开网站和 GitHub。

我不是要把别人的东西搬过来。

更不是把李笑来讲过的话包装成我的话。

我能借鉴的是结构和方法。

公开站给我的第一个启发，是把长期写作当成公开的工作台。

文章、书架、社区、动态、RSS、双语入口，这些不是装饰。

它们让一个人的长期积累有入口、有目录、有返回路径。

这对我的网站很重要。

因为《AI 做网站实践日记》也不应该只是一篇篇散文。

它应该有：

借鉴点	我这里怎么用
公开日记 / journal	把每天的真实工作、错误、证据写成可回看的记录
书架 / catalogue	把 12 篇主线日记、每日工作日记、术语表、证据页整理成系列
Community / readers	后面要接读者留言、真实反馈，而不是只让我自己闭门写
中英入口 / 翻译差异	面向外国人在日本的问题，必须尊重多语言读者
RSS / archive	内容要能被长期订阅、检索、引用，而不是只活在首页

GitHub 给我的第二个启发，是把知识变成工具。

我看到公开仓库里有面向 Markdown、插件市场、自学材料和 AI 工程工具的项目。

这些对我不是“崇拜对象”。

它们提醒我一件事：

真正有复利的知识，最后会长成工具、目录、脚本、检查器和协作规则。

这正好对应我这几天做的事。

日记不只是日记。

它要反过来生成 SOP。

网站不只是页面。

它要反过来生成 validator。

读者留言不只是评论。

它要反过来成为 business validation。

SEO 也不只是关键词。

它应该是结构化内容、清楚标题、稳定链接、来源边界和读者问题的长期组合。

如果说这几天有什么技术借鉴，我会把它们压缩成五句话：

方向	借鉴	我的落点
美学	克制、留白、清楚层级	日记页不要堆装饰，先让人读得下去
网站工程	稳定 URL、索引、RSS、归档	日记要能被找到、回看、订阅、引用
参考资料	公开来源和可验证链接	不写无来源的“听说”
读者留言	Community 不是热闹，是反馈回路	留言要进入真实用户验证
SEO	不是骗搜索，而是把问题讲清楚	每篇文章回答一个真实高摩擦问题

本段参考的公开入口：lixiaolai.com、github.com/xiaolai。这里写的是借鉴，不是引用原话。

这里我也提醒自己一句：

借鉴不是复制。

迭代不是替换。

真正可借鉴的，是把长期积累做成系统的耐心。

7. 给读者的用处

如果你也是一个普通人，正在用 AI 做网站、做产品、做公司，我这几天最大的经验只有一句：

不要问 AI “做完了吗”。要问它“哪一层完成了，证据在哪里，下一层为什么还没完成”。

这三个问题，会立刻把很多漂亮的完成感拆开。

拆开以后，你会看到真实项目的样子：

问题	作用
哪一层完成了？	防止把局部成功说成整体完成
证据在哪里？	防止聊天记忆替代 proof-of-work
下一层为什么没完成？	防止硬边界被 AI 自动越过

这几天，我不是在学一个新工具。

我是在学一种更慢、但更可靠的工作方式：

先让 AI 做事。

再让证据说话。

最后让边界决定能不能继续。

8. 本篇术语表

日记里出现了一些英文或英文缩写。

它们只是因为 AI 协作里很多事必须说清楚：

谁在行动。

证据在哪里。

成本怎么产生。

边界由谁批准。

下面这张表，把这些词翻译成中文，并用一句普通人能懂的类比说明。

缩写 / 词	英文全称	中文译名	一句话解释	类比说明
AI	Artificial Intelligence	人工智能	能根据输入生成文字、代码、图像或行动建议的程序	一个很快的实习生，能干活，但需要任务说明和验收
JTG	Japan Trust Gateway	日本信任入口	我正在做的网站方向：把日本生活里的高摩擦信息转成可信行动清单	外国人在日本生活的说明书入口
LND	Local Notice Decoder	本地通知解码器	把日本通知、表格、文件拆成用户能理解的步骤和边界	收到一张难懂通知时，先帮你看它属于哪类事
PR	Pull Request	合并请求	把一组代码或内容改动提交出来，等审查后再进入主线	装修前先交图纸，不是直接砸墙
CI	Continuous Integration	持续集成检查	每次改动后自动跑测试、构建和规则检查	工厂质检线，过了说明基础检查合格，不等于用户满意
SOP	Standard Operating Procedure	标准操作流程	把重复发生的事固定成步骤	麦当劳汉堡手册，不靠某个人临场发挥
MNK	Method / Note / Knowledge	方法、笔记、知识卡	把一次经验沉淀成以后可复用的知识资产	错一次以后写进错题本
RAG	Retrieval-Augmented Generation	检索增强生成	先从资料库找相关内容，再让 AI 回答	开卷考试，不让 AI 只靠记忆猜
pgvector	PostgreSQL vector extension	PostgreSQL 向量扩展	让数据库能按语义相似度找资料	不是按字面搜“表格”，而是找意思相近的文件
dry-run	dry run	试跑 / 空跑	模拟执行，确认会发生什么，但不真正写入生产	演习，不按下真正的提交按钮
validator	validator	验证器 / 检查器	用脚本检查规则是否被满足	安检门，不能只靠人说“应该没问题”
SEO	Search Engine Optimization	搜索引擎优化	让页面结构、标题、内容和链接更容易被搜索理解	不是喊口号，而是把路牌写清楚
RSS	Really Simple Syndication	内容订阅源	让读者或工具订阅网站更新	报纸投递员，有新文章就送到订阅者那里

结尾

以前我以为，AI 时代最重要的是速度。

现在我越来越觉得，速度只是第一层。

真正重要的是闭环。

能写出来，是开始。

能被用户看到，是下一步。

能进入数据系统，是再下一步。

能被真实用户验证，才算靠近产品。

这几天，我看到的不是一个网站突然完成。

我看到的是：一个普通人用 AI 做长期项目时，必须一点点学会区分“能跑”“能证明”“能闭环”。

这三个词，可能会成为我后面很多工作的尺子。