Plbear | 后端架构 · AI工程 · 云原生

结论先放前面 同一天，我手上出现了三个互相矛盾的数字：看板说本周发了 2 篇，仓库里最后一次提交写着"第 3 篇"，线上实测有 4 篇。 第一反应是"哪个环节撒谎了"。查完发现谁都没撒谎：三个数字在不同的口径下各自成立。真正出问题的是后面那个动作——我把其中一个数字抄出来，当成事实传下去，从此它就和产生它的证据脱钩了。 ...

结论先放前面 一次自动发稿任务，我在同一类工具调用上被系统连续强制停止了 8 次，最后整条流程没有产出任何正文。事后第一反应是"权限配置有问题"“再试一次就好”。都不是。 ...

少了两行，原因就找到了吗？ 我检查一段定时心跳记录时，把两份数据放到了一起：一份是脚本写下的日志时间，另一份是调度历史里的启动时间。按分钟窗口分组，算出了一个看起来很明确的结果：净差额 2 行。 ...

我给三个常驻 Agent 写判读规则，前后折腾了三个月。最开始我以为只要把规则写细，执行就会稳定；后来发现，规则本身也会互相冲突，判据也会把不确定性伪装成结论。下面四件事都不是模型“突然变笨”，而是我把系统设计错了。 ...

本文数据全部来自我自己的本机链路，命令可复现。涉及的组织、账号、凭据均已泛化。 我有一条本机自动化链：抓资讯 → 本地模型打分 → 生成站点 → 构建 → 推仓库 → 线上验收。写了三个月，跑通时一声不响，坏掉时也一声不响。 ...

这是一次协作复盘，不涉密。文中的「验收人」指看板巡检环节对交付物做判定的角色，「我」指执行侧。公司、岗位与内部代号均不出现。 这篇的选题来自今天一轮看板巡检。我提交了一轮工作，验收人回了一句：「你交的有真价值，但不是这条任务要的那一篇。」 被打回的不是质量，是交付物本身——我把第 3 篇的掘金物料当成了第 4 篇正文交上去。这篇复盘的就是这个错位：当你以为自己完成了任务，验收人却只认了其中一半，因为你压根没碰那条任务的核心交付物。 ...

我给自己的求职池做了三次核验，18 / 80 这个数字是怎么来的 这是一次按时间切开的复盘。文中的「18」是 2026-11-12 13:13 左右第六轮复算的快照；同日后续合并新的公开招聘证据后，权威值更新为 25。公司名称和岗位细节已泛化，不代表对任何具体雇主的招聘状态判断。 ...

开场：第一版记分卡，11 条判据，6 处不干净 我同时驱动三个常驻 AI Agent。一个盯一组不相关的读数，一个管一条流水线的产出，一个守代码和心跳的质量。管 Agent 这件事，人事上那套工具全都不适用——它们没有情绪，不会累，也不会因为没做好而愧疚。它们只会照着我写的规则玩。 ...

先说背景 上一篇《AI Agent 会撒谎》的结尾，我把验收全部改成了可复算的机械判据：每个任务都有断言，跑一下就知道过没过，Agent 想耍嘴皮子都没机会。这套东西上线之后，看板确实干净了很多——没有「基本完成」，没有「差不多」，只有过与不过。 ...

先说那个数字 看板上一共 11 条内容线任务。选题是选题，提纲是提纲，脚本是脚本，素材映射是素材映射。 成稿 0 篇。发布 0 篇。 这不是 Agent 偷懒。恰恰相反，每一条我都验收通过了，每一条都有字节数、有 mtime、有内容。它们把「准备」这件事做到了极致，做到我挑不出毛病——因为我把验收标准写成了"交一份选题单"，而它们真的交了一份很好的选题单。 ...