每日工作日记 03 · 证据、成本和边界

这是《AI 做网站实践日记》12 篇正文之后的第三篇每日工作日记。

它不写 AI 多快，只写一个普通人在真实工作里怎样把 AI 用成系统。

本篇一句话

昨天我真正学到的不是“AI 能做更多事”。

而是：AI 做出来的东西，必须同时过三关：证据、成本和边界。

没有证据，完成只是聊天里的感觉。

没有成本意识，自动化会悄悄变成账单。

没有边界，能干活的 AI 很快就会变成会越界的 AI。

事实边界

2026 年 5 月 14 日，我主要处理了三类事。

第一类，是把前一天的每日工作日记放进公开网站的日记栏目，并留下页面、索引、站点地图、构建、检查和收据证据。

第二类，是把这次发布经验沉淀成日记写作和发布的 SOP、验证脚本、任务模板，防止以后又把“预览”误说成“完成”。

第三类，是处理 GitHub Actions 的预算提醒：我看到自动化检查已经接近预算上限，于是开始把 CI 也当成产品成本来管理。

这一天还发生了很多并行工作：多 AI 协作规则、来源核验、地方公共服务产品机会、JTG 文案整合、翻译功能修复、SEO 和联系入口、留言系统证据、以及一人 AI 公司的任务图运行时。

但如果把所有细节都写进来，读者只会看到一团很忙的雾。

所以这篇日记只写一个主线：

我开始把 AI 工作从“能生成”，推进到“能被证明、能算成本、能守边界”。

1. 上午：我以为自己在处理一篇日记

上午，我先看的是日记。

表面上看，这只是一篇文章。

一个 Markdown 文件。

一个网页路由。

一个日记索引。

一个站点地图。

一条上线后的访问路径。

但真正做完以后，我发现它不是一篇文章那么简单。

它更像一个小型生产系统。

一篇工作日记，不能只停在“写得像不像我”。

还要回答：

以前我容易把写作看成“输出文字”。

昨天我更清楚地看到：在 AI 时代，写作会自然长成一条生产线。

写作、整理、审稿、脱敏、集成、验证、发布、收据，全都要连起来。

否则，一篇文章很容易变成三种东西之一：

• 聊天里看起来完成了，文件里没有。
• 本地看起来完成了，用户找不到。
• 技术上能打开，公开内容里却夹着内部过程。

这三种都不是写作完成。

它们只是“生成完成”。

2. 下午：我又被“迭代”这个词纠正了一次

下午，我让 AI 继续处理每日工作日记。

这时候又暴露出一个老问题：

AI 很容易把“迭代”理解成“重写一篇”。

但我真正想要的不是替换。

我想要的是保留有价值的部分，再把它变得更清楚、更成人、更像一个真实工作者写出来的记录。

这件事对我很重要。

因为我写《AI 做网站实践日记》，不是为了写一堆技术流水账。

也不是为了证明自己多会用工具。

我想记录的是一个普通人怎样在真实工作中一点点建立判断力。

这个判断力里面有时间线。

有事件线。

有知识线。

也有人的犹豫、纠偏、误判和重新开始。

如果 AI 把这些都删掉，只留下一个“更工整”的版本，那不是迭代。

那是把活的经验磨成了没有温度的说明书。

昨天的一个关键动作，是把这条规则写进日记 SOP：

迭代不是替换。

迭代是保留可复用经验，再提高结构、语言、证据和可读性。

这句话不只适用于写作。

它也适用于网站。

适用于公司治理。

适用于一个人用 AI 做长期项目。

很多时候，AI 会给你一个“看起来更完整”的新版本。

但新版本如果丢了原来最真实的矛盾、时间线和证据，它就不一定更好。

它只是更顺。

而真实工作不是靠顺来判断的。

真实工作靠证据判断。

3. 傍晚：账单提醒我，自动化也有价格

傍晚，GitHub 发来预算提醒。

Actions 用量已经接近预算上限。

这件事一下子把我从“功能有没有跑通”拉回到“系统有没有成本意识”。

以前我看 CI，主要看红灯绿灯。

红了，修。

绿了，过。

昨天我开始用另一种眼光看它：

每一次自动检查，都是一次机器劳动，也是一笔小账。

一笔小账不可怕。

可怕的是它每天重复。

更可怕的是它重复做同一件事。

我打开用量报表，看到一些工作流在重复构建、重复安装、重复证明同一个结论。

这时候，CI 不再只是“质量保障”。

它也变成了一个需要治理的系统。

我把这件事拆成三层：

于是我做了一件很小但很关键的事：

把重复构建拆出来。

一个检查只负责它真正要证明的事。

另一个检查复用已经构建好的结果。

这里面有一个很朴素的道理：

自动化不是越多越好。自动化要证明得刚刚好。

跑得太少，容易漏错。

跑得太多，容易烧钱。

跑错方向，最危险：你花了钱，却没有买到真正的确定性。

4. 晚上：一个点目录，让检查失败了

晚上，我把 CI 降本的小改动做成一个草稿合并请求。

检查大部分都通过了。

但中间还是失败了两次。

第一次失败，是因为合并请求缺少任务编号。

这听起来很琐碎。

但它背后的原则不琐碎：

任何改动都要能追溯到一个明确任务。

否则过两天再看，只能知道“有人改了 CI”，却不知道为什么改、改到什么边界、用什么标准判断成败。

第二次失败更有意思。

我本来想把构建产物上传给下一个检查复用。

结果上传时没有文件。

原因不是构建没生成。

原因是 .next 这个目录以点开头，上传工具默认不包含隐藏文件。

这件事很小。

但它特别像 AI 工作里的真实世界：

本地逻辑对。

意图也对。

成本方向也对。

偏偏被一个默认参数卡住。

于是我补了两个设置：

include-hidden-files: true
if-no-files-found: error

第一句，是让隐藏目录真的被上传。

第二句，是以后如果又没有文件，不要悄悄警告，要直接失败。

我很喜欢第二句。

因为它代表一种工程态度：

不要让关键证据以 warning 的形式悄悄消失。

很多问题不是没有信号。

而是信号太温柔。

它提醒了你一下，但没有拦住你。

然后你在后面更贵的地方付账。

5. 昨天真正的主线：把经验变成机器能执行的规则

昨天产出了很多 MNK 卡。

有的来自产品洞察，比如地方通知解读、公共服务资源图谱、日本行业信息源、企业压力通知。

有的来自工程治理，比如多 AI 证据优先、任务图运行时、分支范围门、同日回滚 SOP。

有的来自写作和表达，比如创始人文字指纹、用户可见语言、注意力保护式收尾。

如果只看标题，会觉得很散。

但把它们放在一起看，其实是在回答同一个问题：

一个人怎么管理一群 AI，而不是被一群 AI 的输出淹没？

昨天我得到的答案不是“多开几个窗口”。

也不是“让 AI 更努力”。

答案更像下面这张表：

这就是我昨天对“公司操作系统”更深一层的理解。

它不是一堆文档。

也不是一个后台页面。

它是一种把经验不断压缩成规则、脚本、任务和证据的方式。

李笑来经常强调长期复利。

昨天我对这件事的体感是：

AI 时代的复利，不是多生成几篇文章，而是每次踩坑之后，都让系统少踩一次。

6. 给正在学 AI 的成年人

如果你也在用 AI 做项目，我昨天这一天可以压缩成三个建议。

第一，不要只问“能不能做”

AI 大概率能做。

真正的问题是：

• 做完以后证据在哪里？
• 下次怎么复用？
• 出错时谁能发现？
• 成本会不会每天累积？
• 哪些动作必须人来授权？

这些问题比“能不能做”更重要。

第二，把账单当成反馈

账单不是坏消息。

账单是系统在告诉你：

哪里重复了。

哪里过度证明了。

哪里自动化开始从工具变成负担了。

如果你只在钱花完以后才看账单，那已经晚了。

更好的做法是把账单看成产品反馈。

成本上升，往往说明系统结构也需要整理。

第三，让失败变硬

昨天那个 .next 上传失败，给我一个很好的提醒。

如果关键证据没有生成，不要只是 warning。

要 fail。

因为 warning 很容易被忙碌的人忽略。

fail 才会逼你停下来，把问题处理掉。

这不是追求严厉。

这是保护注意力。

本篇方法卡

如果我要把昨天的方法交给另一个正在学 AI 的人，我会写成这样：

AI 工作三问

1. 证据
   - 它真的完成了吗？
   - 证据在文件、URL、检查、收据里的哪一层？

2. 成本
   - 它每次运行花多少时间和钱？
   - 有没有重复证明同一件事？

3. 边界
   - 哪些动作可以自动继续？
   - 哪些动作必须由人明确授权？

这三问比“AI 给我写了什么”更重要。

因为写出来只是开始。

能被证明、能长期负担、能守边界，才接近真正的工作。

本篇金句

AI 时代，不缺生成。

缺的是证据、成本意识和边界感。

不要让关键证据以 warning 的形式悄悄消失。

自动化不是越多越好。自动化要证明得刚刚好。

每次踩坑之后，都要让系统少踩一次。

写作依据

这篇日记参考了 2026 年 5 月 14 日的工作材料：

• 每日工作日记发布 SOP。
• 每日工作日记验证器和任务模板收据。
• GitHub Actions 成本优化草稿合并请求收据。
• 一人 AI 公司任务图运行时材料。
• 多 AI 证据优先、注意力保护、用户可见语言、HTTP 200 不等于用户流程完成等知识卡。

这些材料只提炼成读者能理解的方法，不展开内部口令、后台信息或不适合公开的执行细节。

章末小结

昨天真正完成的，不只是一些网页和检查。

更重要的是，我又给自己的 AI 公司补了一组仪表盘：

证据仪表盘。成本仪表盘。边界仪表盘。

这三个词以后会继续提醒我：生成只是开始，能被证明、能长期负担、能守住边界，才接近真正的工作。

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

这篇日记上线时，背后不是“把一段文字贴到网页上”这么简单。

它至少经过了五步。

第一，正文先变成 Markdown 内容文件。

Markdown 的好处是朴素：文字、标题、表格、代码块、引用，都能用纯文本表达。这样以后改字、审稿、做版本记录，都不会被复杂排版绑住。

第二，它进入日记 registry。

registry 可以理解成目录卡片：标题是什么，网页地址是什么，顺序排第几，内容文件是哪一个。没有这张卡片，页面本身可能存在，但读者在目录里找不到它。

第三，网站详情页读取这张卡片，再把 Markdown 渲染成网页。

所以这里有两层证据：内容文件证明文字存在；详情页证明用户可以阅读。

第四，站点地图要加入这个地址。

这一步不是给人看的，而是给搜索引擎和网站索引看的。一个页面如果只存在，但不进入索引，它就像房间已经装修好，却没有门牌。

第五，日记正文外层仍然有基础防复制组件。

它会拦截复制、剪切和右键菜单，给公开文字加一层摩擦。但这不是绝对防盗。截图、手动转写、浏览器开发工具或恶意抓取，仍然不是它能彻底阻止的事。

所以这件事的正确说法是：

不能复制 ≠ 绝对防盗。

它只是提高随手复制的成本，不是承诺内容永远不会被拿走。

发布前，我更关心的是四个问题：

• 详情页能不能打开。
• 日记目录能不能看到。
• 站点地图有没有收录。
• 构建和检查有没有通过。

不是把文章放上去就算发布。

能被页面、目录、站点地图、构建和线上 URL 同时证明，才算这篇日记真的进入了网站。

英文缩写与中文对照、类比说明

这篇里出现了一些英文缩写和工程词。

它们不是为了显得专业。

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

谁在行动。

证据在哪里。

成本怎么产生。

边界由谁批准。

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

这张表不是为了让读者背缩写。

它只服务这篇日记的主线：

不要被英文缩写吓住。
真正要看懂的是：
证据在哪里，
成本怎么产生，
边界由谁批准。