笔记

关于"软件与机器交界处"的短篇工程写作:设计取舍、失败模式,以及我反复复用的模式。每一篇要么附带一个你能跑的东西,要么是我真修好过的某件事的复盘。不写趋势评论、不写创业感悟、不写没有实测数据的技术栈对比——过不了这条线的,我就不发。

你为一次重构付了钱,却看不出任何变化——轨迹一样,界面一样。我的回答:别审代码,拿着一份"弄坏它"的清单去试机器。你弄不坏它,就看见你买到的东西了。

伤到你的 bug 数不出来——它们正是你想象不到的那些。所以别数 bug,去数后果类。当你已经知道软件里有你还没找到的 bug,如何让一台机器仍然安全。

每次让 AI 审查它自己写的代码,它总能再找出新 bug。不用它,又会被生产力代际甩开。而这软件驱动的是一台物理机器——怎么权衡?这是我的答案。

每一个有物质后果的写操作,都该离开模型可及范围,过一个 agent 无法编写也无法绕过的授权层。治理是架构,不是一段小心的提示词——用一条托管支付流当范例。

"数据永不出你的机器",只有当你能指出它确实离开的那唯一一处、并证明别处都出不去,才是真的。信任靠把边界画精确赢来,不靠承诺更多。

报价很便宜,声称很容易。给你一个能跑的东西——在 mock 数据上、在你花掉一个凭据之前——把风险从你身上挪到我身上,那才是它该在的地方。

你只要"一个 HMI",别的什么都没定。我拆成里程碑防失控——每个阶段只用一封邮件驱动。在你那边,一个大风险变成一段段你只需看着完成的小阶段。

"技术归 AI、与人打交道归人"是反的。两者的失效方向恰好相反——质量不来自任何一方,而来自这一对互纠。这是我真实跑在客户往来上的审查协议。

当成本归零,价值不会消失——它迁移到新瓶颈:判断、验证,以及一个能为"会伤人的机器"被问责的人。这是模型结构上供不出来的东西。

新笔记先落在这里。想不依赖任何平台地收到它们:订阅 feed。