每日工作日记 02 · 把“能跑”拆成“能被证明” · AI 做网站实践日记

昨天我真正学到的，不是某一个工具怎么用，而是一个更硬的判断：

一人 AI 公司真正需要的，不是让 AI 多做一点；
而是把每一步做成可证明、可回滚、可复用的系统。

过去我容易把“看起来能跑”当成完成。昨天一整天，系统逼着我把这句话拆开：

能跑，是人的感觉；
能被证明，才是工程事实。

我现在越来越觉得，AI 老师最应该教的不是“哪个模型更强”，而是怎么把一个含糊的愿望，拆成可以执行、可以验收、可以复盘的动作。

很多人学 AI，第一阶段会兴奋于生成速度：几秒钟出文案，几分钟出页面，半小时改完一段代码。这个阶段当然重要，但它很容易让人误以为“生成完成”就是“工作完成”。

昨天我的感受正好相反：

AI 生成越快，
人越要慢下来定义证据。

这篇日记写给正在学习 AI 的成年人。不是讲工具新闻，也不是讲“AI 多厉害”。我想记录的是：一个人用 AI 做公司、做网站、做产品时，怎样从“让 AI 做事”，进入到“让 AI 做出来的东西能被证明”。

一、时间线

1. 从新机器开始

昨天的起点，是 Mac Studio 迁移后的工作台确认。

表面上只是换电脑。实际暴露的是一个更底层的问题：

路径变了，系统记忆不一定变；
机器换了，项目状态不一定换；
AI 会话继续了，执行入口不一定可靠。

以前的历史路径里有旧机器痕迹。现在新机器的真实工作区已经变了。

这不是一个小路径问题，而是“事实源”问题。

做技术的人很容易低估路径问题。路径看起来只是字符串，实际却是系统的坐标系。AI 如果不知道自己站在哪个目录、读的是哪个仓库、验证的是哪套环境，它后面所有“我看到了”“我改好了”“我跑通了”，都可能只是在旧地图上画线。

这件事给我的第一个提醒是：新机器不是新桌子，而是新运行时。真正要迁移的不是文件，而是入口、路径、验证方式和下一次 AI 会话能不能接住的上下文。

如果 AI 还拿旧路径执行，结果可能是：

文件看似存在，实际不是当前项目。
脚本看似通过，实际验证的是旧环境。
handoff 看似完整，实际不能让下一个窗口接上。

所以我现在看一个项目状态，至少会问三件事：

当前工作目录是不是真实项目？
当前文件是不是这次要交付的那份？
当前验证是不是跑在同一套环境上？

所以第一条知识出现了：

迁移完成，不等于工作系统完成。
路径可读，不等于入口可信。

2. 从注册邮件开始

接着是 JTG 的注册、邮箱验证、留言和支付准备链路。

这件事表面上是 auth。更准确地说，它是一条用户行动链：

用户想留言
→ 被要求注册 / 登录
→ 收到验证邮件
→ 点击确认链接
→ 回到网站
→ 恢复原来的留言意图
→ 成功完成评论动作

其中任何一环断掉，用户都不会说“auth 失败”。

用户只会觉得：

这个网站不好用。

昨天最大的提醒是：PR 通过、TypeScript 通过、CI 通过，都不能证明用户真的能完成这条链。

邮箱是否送达，是 provider 层。

确认链接是否正确，是配置层。

点击后能不能回到原页面，是产品体验层。

评论能不能写入，是数据库和权限层。

支付是否可准备，是另一个边界层。

这也是我昨天作为 AI 老师最想强调的一点：不要把一个用户动作误认为一个前端按钮。真实产品里的“注册成功”，至少横跨前端、后端、邮箱服务、数据库权限、跳转链接和用户心理预期。

从技术上看，CI 通过只能证明代码在某些静态检查和构建步骤里没有明显错误。它不能证明邮件真的送达，不能证明用户点击链接后知道下一步做什么，也不能证明数据库的 RLS 策略允许这个用户写入评论。

所以我开始把这类流程看成证据链，而不是功能点：

代码证据
服务证据
权限证据
界面证据
用户行为证据

少任何一层，都只能说“局部通过”，不能说“用户流程完成”。

第二条知识出现了：

用户流程不是代码函数；
用户流程是跨系统证据链。

3. 从连续 A 开始

昨天我多次回复 A。

这看起来像一个很简单的指令：继续。

但系统不能把 A 理解成万能授权。它只能被编译成：

继续低风险、本地、可逆、可验证的下一步。

它不能自动变成：

git push
merge
production release
读密钥
付款
专利披露
删除清理

这个边界非常重要。

一人 AI 公司最怕的不是 AI 不干活，而是 AI 太会干活，越过人类没有明确授权的地方。

这里有一个很技术、但很实用的概念：自然语言指令不能直接等于系统权限。

我说“A”或“继续”，在人类对话里是很自然的。但系统必须把它翻译成更小的执行合同：

scope：只能做哪一类事
risk：风险等级是什么
write：能不能写文件
external：能不能碰外部系统
stop：遇到什么必须停

这一步看似麻烦，其实是在保护人。因为 AI 不会天然理解“继续”里面隐藏的社会责任。对人来说，发一封邮件、发布一个页面、合并一段代码、触发一次付款，责任完全不同；对模型来说，它们都可能只是“下一步动作”。

第三条知识出现了：

自动继续不是自动授权。
执行效率必须被权限边界包住。

4. 从工作树隔离开始

昨天另一个反复出现的词，是 isolated worktree。

简单说，它就是给 AI 一个隔离工作区，让它只在指定范围里试改，避免污染主工作区、别人的分支、正在跑的任务和生产路径。

这件事后来也解释了为什么 Phase 1 文案测试不能直接改当前 dirty root：

当前 root 已有未清理变化。
继续在上面改，只会增加混乱。

正确做法是：

先确认当前状态
再开隔离工作区
只改 1 个文件
只做 1 处小变更
跑 validator
给我看 preview / diff
不自动 push / merge / 发布

如果用普通话讲，isolated worktree 就是“给 AI 一个临时样板间”。它可以在里面试装修、改颜色、摆家具，但不能直接动正在营业的店面。

这件事背后的技术价值有三个：

隔离变更：新改动不会混进旧改动。
降低回滚成本：不满意可以直接丢掉这个工作区。
支持并行协作：不同 AI 或不同任务不抢同一张桌子。

我以前会把隔离理解成“慢一步”。昨天以后，我更愿意把它理解成“并行的基础设施”。没有隔离，多个 AI 同时工作就是叠文件；有隔离，多个 AI 才可能像工程队一样分区施工。

第四条知识出现了：

隔离不是保守；
隔离是并行协作的前提。

二、事件线

昨天的事件看似分散，其实可以串成一条线：

Mac Studio 迁移
→ 旧路径漂移
→ 新入口校验
→ auth 用户链路拆解
→ 连续 A 权限编译
→ dirty tree 治理
→ isolated worktree
→ release gate 边界
→ handoff / entry kit / ledger
→ 回到主任务：JTG 不是泛 AI 工具站，而是可信行动解码器

这条线的核心，不是技术越来越复杂，而是“完成”的定义越来越严格。

以前的完成可能是：

我写了。
我跑了。
我看起来好了。

昨天以后，完成必须变成：

有可见结果。
有可追踪记录。
有验证证据。
有未授权边界说明。
有下一步可恢复入口。

这就是 Company OS 的价值。

它不是为了写更多文档，而是为了防止 AI 把“局部完成”伪装成“整体完成”。

我昨天真正意识到，Company OS 不是一个“管理系统”的名字，而是一套把 AI 输出降噪的算法。

它做的事情很朴素：

把聊天里的承诺，压缩成文件里的证据；
把模型的自信，压缩成 validator 的通过或失败；
把下一步行动，压缩成可恢复的入口。

这对一人公司尤其重要。大公司可以靠多人 review、流程、会议和部门边界来抵消错误；一个人没有这些缓冲，就必须把缓冲做进系统里。

三、知识线

1. 证据阶梯

昨天最重要的一条知识，是证据阶梯：

文件存在
< repo 状态清楚
< 脚本语法通过
< validator 通过
< 本地页面可预览
< 用户真实完成动作
< 生产数据可证明

越往上，证据越强。

这个阶梯其实可以看成一个简单的排序算法：同样都叫“完成”，证据强度不同，权重就不同。

聊天里说完成：权重最低
文件确实存在：权重上升
脚本跑过：再上升
页面可预览：继续上升
真实用户完成动作：接近产品证据
生产数据可证明：最高级别证据

很多 AI 协作混乱，根本原因是把低权重证据当成高权重证据。模型说“应该可以”，人听成“已经可以”；本地通过，团队听成“线上可用”；页面打开，自己误判为“用户流程完成”。

所以，AI 以后不能轻易说“完成”。它最多应该说：

已写入
已记录
已通过本地 validator
待我预览
待生产验证

这让语言变得不那么漂亮，但更真实。

2. 全链路思维

注册不是注册按钮。留言不是输入框。通知解码也不是翻译。

一个真正的用户流程，都应该拆成：

入口
身份
权限
来源
动作
反馈
失败处理
下一步

这正好迁移到 JTG：

用户上传日本通知
→ AI OCR / 读取文字
→ 判断通知类型
→ 找 SourceBlock
→ 解释对象、期限、费用、地点
→ 生成行动清单
→ 给日文询问模板
→ 标出不确定项
→ 必要时 human gate

这不是普通翻译。

这是把日本地方生活里的半离线信息，变成外国人能执行的 workflow。

这里我想多讲一点技术映射。

Local Notice Decoder 看起来是 OCR + 翻译，但真正难的是状态机：

输入：图片 / PDF / 邮件 / 网页
识别：文字、日期、金额、地点、机构
分类：健康检查、育儿、行政、活动、志愿者、房产
判断：和用户有没有关系
输出：行动清单、日文询问模板、不确定项
升级：高风险时进入人工确认

如果只做翻译，用户拿到的是“中文意思”。如果做 workflow，用户拿到的是“下一步怎么做”。这两者的商业价值完全不同。

3. 候选和落地要分开

昨天多次出现一个边界：

external AI output = candidate only
local validator evidence = landed evidence

这条对我很重要。

因为我现在会同时用多个 AI：Codex、Claude、ChatGPT，可能还有别的工具。

多 AI 不是让每个 AI 都说了算。真正的规则是：

外部 AI 可以给候选。
本地文件和 validator 才能证明落地。
我做最终边界裁决。

这也是一人 AI 公司的组织结构：

AI 多执行；
系统做证据；
人做裁决。

我现在越来越把不同 AI 看成不同的候选生成器，而不是不同的老板。

一个 AI 可以给我写文案，一个 AI 可以帮我审结构，一个 AI 可以跑本地文件，一个 AI 可以生成表格。但它们的输出都不能天然进入事实层。进入事实层之前，必须经过本地文件、validator、预览、收据这些东西。

这和写代码里的类型系统很像：外部 AI 输出是 candidate 类型，本地验证通过以后才可能变成 landed 类型。类型没变之前，不能拿它当真实状态用。

4. Release gate 失败不一定是坏事

昨天一个很反直觉的洞见是：

有些 FAIL 是系统在保护你。

如果 release gate 因为 hard boundary 没授权而失败，那不是坏事。

它说明系统没有把 A 错译成发布许可。

这和跑步很像。

真正保护身体的，不是每天都冲最快，而是知道什么时候降速、什么时候停、什么时候恢复。

系统也是一样。

没有刹车的自动化，不是效率，是风险放大器。

成熟系统里，失败不总是坏消息。一个 gate 在该失败的时候失败，说明它知道边界在哪里。

昨天我对“失败”的感觉也变了。以前看到 FAIL，会本能觉得哪里坏了。现在我会先问：

这是错误失败，还是保护性失败？
是代码没写对，还是权限没授权？
是流程断了，还是系统避免了越界？

能区分这三种失败，AI 协作才不会陷入“见红就修”的低级反射。

四、给读者的启发

如果你也是一个人做项目，或者正在用 AI 做自己的公司，昨天这一天至少给出 5 个可用原则。

1. 不要问“AI 能不能做”

先问：

这件事做错了会伤害谁？
需要什么证据才算完成？
哪些动作必须人类裁决？

2. 不要把“会话记忆”当系统记忆

聊天窗口会断，模型会换，路径会漂移，历史上下文会丢。

真正可靠的是：

文件
validator
receipt
ledger
handoff
preview

3. 不要把“局部 PASS”当整体完成

一个脚本 PASS，不等于用户能用。

一个 PR clean，不等于生产安全。

一个本地页面好看，不等于真实用户行动完成。

4. 不要让自动化越过授权边界

自动化适合重复动作，不适合替人承担责任。

所以系统要默认区分：

可以自动继续的事
必须由我裁决的事
绝对不能自动碰的事

5. 把学习变成可迁移资产

昨天每个小问题最后都被沉淀成 MNK：

M：以后怎么做
N：这次看到什么
K：能复用的知识结构

这就是李笑来式的学习：

不是看懂，
而是把一次经验变成下一次能调用的工具。

如果换成我自己的说法：

学习不是获得一个答案；
学习是获得一个下次能复用的处理器。

昨天的 Mac 迁移、auth 链路、A 权限、worktree 隔离，都不是孤立事件。它们最后都应该变成处理器：下次遇到类似问题，系统能自动先问路径、先查证据、先隔离、先预览，而不是重新靠情绪和记忆判断。

五、昨天给 JTG 的真正启发

JTG 的方向又清楚了一点。

我不是要做一个“日本生活 AI 问答站”。那太泛，也太容易变成 AI 胡说。

我真正要做的是：

把外国人在日本遇到的高摩擦信息，拆成可验证来源、可理解解释、可执行动作、可询问日文、可升级人工确认。

这和昨天的工程经验是同一件事。

工程里，我要把“能跑”拆成“能被证明”。

产品里，我要把“看懂一点日文”拆成：

这是什么
和我有没有关系
什么时候截止
我要准备什么
我该问谁
我下一步做什么
哪里不确定
哪里不能让 AI 乱判断

这就是 JTG 的文字指纹：

事实 → 判断 → 边界 → 下一步

这也是我作为 AI 老师最想传给读者的一个底层方法。

不要先问“AI 能不能替我回答”。先把问题拆成：

事实层：原文到底说了什么？
判断层：它和谁有关？
边界层：哪里不能由 AI 乱判断？
行动层：下一步最小动作是什么？

这个框架既能用在日本通知，也能用在代码、合同、邮件、产品需求和个人学习里。它的价值不在于复杂，而在于可重复。

六、今天的结论

昨天的一天，不是普通的 Mac 迁移日，也不是普通的 AI 协作日。

它更像是把一人 AI 公司的底层操作系统重新校准了一遍：

路径要真实。
授权要真实。
证据要真实。
完成要真实。
用户行动要真实。

这件事看起来慢，但它会变快。

因为未来每一个 AI 窗口、每一个工作区、每一个页面、每一个用户流程，都可以沿着同一条规则继续：

先确认事实，
再隔离执行，
再本地验证，
再给人看，
最后才进入发布或合并。

我今天真正想留下的一句话是：

AI 时代，不缺生成；
缺的是把生成变成证据，把证据变成流程，把流程变成信任。

这就是昨天的日记，也是 JTG 接下来要长出来的样子。

七、背后的技术：这篇日记怎么进网站

这篇日记不是把 HTML 文件直接丢到服务器上。

它会进入网站现有的日记系统：

Markdown 内容文件
→ 日记 registry 登记 slug / title / order
→ Next.js 生成日记页面
→ 目录页显示最新每日工作日记
→ sitemap 收录新 URL
→ 正式页面外层套 NoCopyArticle

这里有几个技术点值得记录。

第一，正文用 Markdown 存放。这样我以后改文章，不必每次手写页面组件；内容和页面结构是分开的。

第二，slug 是固定的：

daily-20260513-can-run-to-can-prove

URL 一旦发布，就不要随便改。文章可以迭代，入口要稳定。

第三，网站会用同一套日记渲染器显示正文、表格、代码块和引用。这样每篇日记不需要单独设计一套页面，风格会更统一。

第四，日记正文外层已有 NoCopyArticle。它会拦截复制、剪切和右键菜单，给公开文字加一层基本保护。

但我也要把边界讲清楚：

不能复制 ≠ 绝对防盗。
它只是提高直接复制的摩擦，
不是 DRM，
也不能阻止截图、手打、开发者工具或恶意抓取。

所以它的意义不是“锁死文字”，而是表达一个态度：这些日记是我的真实工作记录，不是随手可搬运的素材库。

第五，发布前要跑本地检查。至少要证明：

新内容文件存在
registry 能读到新日记
TypeScript 不报错
构建能通过
sitemap 有新路径

这和整篇日记的主题是一致的：

不是把文章放上去就算发布；
是要让入口、页面、保护、索引和验证一起成立。

本篇方法卡

主题：把“能跑”拆成“能被证明”

适用场景：
- AI 写代码
- AI 做网站
- 多 AI 协作
- 用户注册 / 留言 / 支付链路
- JTG Local Notice Decoder

最小动作：
1. 先确认真实路径和当前状态
2. 把用户流程拆成跨系统证据链
3. 把 A 编译成有限授权，不扩权
4. 用 isolated worktree 隔离试改
5. 用 validator / receipt / ledger 证明进展
6. 没有人类授权，不进入发布、合并、付款和生产变更

本篇金句

能跑，是人的感觉；能被证明，才是工程事实。

用户流程不是代码函数；用户流程是跨系统证据链。

自动继续不是自动授权。

隔离不是保守；隔离是并行协作的前提。